Managing and scaling IP SAN.
Addressing Network Storage Needs with Native IP SAN
With the availability of the iSCSI (Internet SCSI) standard from the Internet and Engineering Task Force (IETF), a number of iSCSI products have been introduced into the market. The early applications have been the iSCSI-FC (Fibre Channel) gateways and switches, which address the server fan-in economic challenge of the FC SAN and the connectivity among FC SAN islands across the wide area network (WAN). The availability of the software iSCSI drivers across major server operating systems, including Windows, Linux, Solaris, HP-UX and the forthcoming drivers for AIX and Mac OS X, in conjunction with the iSCSI storage arrays offers the IT organization the potential to implement IP SANs to address many of their data storage needs.
[FIGURE 1 OMITTED]
The performance and storage pooling benefits of the SAN, as demonstrated by the FC SANs, are broadly accepted. IP SAN offers similar benefits at much lower total cost of ownership (TCO) by leveraging the commodity Ethernet switches and the abundant IP network administration knowledge base. Many IT organizations that are planning or implementing PC server and storage consolidation projects are now considering or deploying IP SAN, both for the economic benefits and to avoid the need to acquire and manage a second and different network environment, i.e. FC SAN. The most notable applications are Web, e-mail, and CIFS/NFS file services.
Disk-to-disk backup, near-line archive, and remote disaster recovery sites are the other key applications where the native iSCSI storage arrays are being considered and applied. In these cases, IP SAN is used as auxilliary storage to the more expensive FC SAN. IP SAN's cost-performance offers a much better fit and value than even the FC SAN with the serial-ATA (S-ATA) disk arrays. The increasing number of iSCSI disk array offerings, known as "bricks," will accelerate this trend.
Learning From the Evolution of FC SAN
As iSCSI disk arrays and IP SANs proliferate, there are a few lessons to learn from the FC SAN evolution and recent trends.
As the FC disk array grew in size, the high-end, monolithic, FC storage subsystems (e.g., the Symmetrix DMX, the Hitachi Lightning, etc.) were endowed with switched internal fabric for increased performance, virtualization for simplified volume management, and advanced features such as snapshot and remote replication. The same trend also occurred among the mid-range modular FC SAN storage subsystems, albeit in a slightly different form. To address the challenges and overheads of managing zoning, LUN masking, and the large number of host-LUN mapping and routes on the application hosts, the out-of-band (or asymmetric) virtualization appliance and the in-band (or symmetric) SAN volume controllers were introduced. In essence, virtualization has moved beyond the hosts and into the fabric.
The other interesting development has been the introduction of NAS heads to front-end the FC SAN for file sharing. This movement leverages the dynamic scalability of FC SAN storage to address the capacity limitation of the conventional monolithic NAS design.
The complexity of FC SAN management aside, the common themes among these trends are:
* A key benefit of the SAN is its ability to scale, by extending the fabric and attaching more devices
* SAN management becomes unwieldy as the number of "components" within the SAN escalates
* Moving intelligence (i.e., storage resources virtualization and data movement) into the fabric to simplify host and data management
A Scalable, Highly Available, Managed IP SAN
The FC SAN development trends and benefits to the user IT organizations can be realized by a native IP SAN, and without the complexity of the FC SAN management. The native IP SAN is constructed by connecting the iSCSI disks, iSCSI JBODs (Just a Bunch of Disks), or the increasingly available iSCSI RAID arrays (known as "bricks") to one or more storage services controllers (also called SAN volume controllers or virtualization appliances by some vendors), which in turn are connected to the application hosts via iSCSI again.
All network interconnects among these iSCSI devices are implemented with point-to-point, switched gigabit Ethernet/IP networks. The use of switched Ethernet breaks the limitation of internal busses and loops of the conventional storage arrays. One can extend and expand the switched network easily and quickly while riding the price/performance improvement trends of Ethernet. The switched IP/Ethernet network can be configured with redundant paths. In the event of a switch failure, the network automatically re-routes the data paths. This is transparent to the application hosts and the storage controllers. Thus, the need for additional, multi-pathing software and source-route configurations are obviated.
[FIGURE 2 OMITTED]
As shown in Figure 1, separating the storage controllers and the storage elements enables both to be scaled and/or repurposed with the network, either independently or together, to meet various application storage requirements.
Clustered Storage Services Controllers
The storage services controller (SSC) is a specialized IP server executing policy-based volume management and intelligent resource management. The SSCs of a Native IP SAN operate as a loosely coupled, active-active cluster, which is presented to the application hosts as a single storage system with a single virtual IP address. At any point in time, one member of the cluster serves as the primary SSC and hosts the virtual IP address that represents the cluster.
When an application host initiates an iSCSI session to the virtualized storage system (via the virtual IP address of the cluster), the primary SSC designates a member of the cluster to service the data-path to the storage elements that comprise the volume to be accessed by the requesting application host. The primary SSC then issues an iSCSI re-direct command to the application host, instructing it to connect to the physical IP address of the designated SSC servicing the data-path (Figure 2).
[FIGURE 3 OMITTED]
[FIGURE 4 OMITTED]
As any of the cluster members can assume the responsibility of another failed SSC, the same iSCSI re-direct mechanism for the initial iSCSI session establishment is used to reestablish the data-path to the storage elements through one of the remaining functional SSCs. Similarly, as additional SSCs are added to the cluster, or as a member of the cluster is consistently overloaded, the storage traffic can be re-directed through other cluster members. Thus, linear I/O performance scaling is achieved by expanding the cluster size.
[FIGURE 5 OMITTED]
In short, high-end FC SAN storage subsystem capabilities such as N-1 levels of fault tolerance and high availability, load balancing and I/O bandwidth scaling become available in even an entry level native IP SAN.
True Single Storage Pool and Global Sparing
The back-end iSCSI disks/JBODs/arrays form a single pool of storage behind the SSCs. The SSCs offer up virtualized volumes to the application hosts. DHCP is employed to manage the IP addresses of the iSCSI storage elements and the SSCs.
As the single pool of storage is shared among the virtualized volumes, an SSC can transparently extend a virtual volume from the application host that's using the virtual volume. Similarly, any iSCSI disk in the free storage pool can act as a spare for any of the virtual storage devices/volumes in the IP SAN.
When the storage pool runs short of free storage, additional storage elements can be attached to the back-end Storage Delivery Network (SDN). As shown in Figure 3, the new storage elements, when powered up, acquire IP addresses, announce themselves and are automatically configured into the storage pool by the SSCs. There are no interruptions to the storage services delivered to the application hosts as the expansion of the storage pool is dynamic and transparent to the application hosts.
Extending IP SANs to Multi-Dialect and Multi-Site Storage Infrastructure
With a cluster of SSCs, a pool of IP-addressable disks, and a flexible network interconnect, the resulting IP SAN not only offers fully virtualized block level storage, but provides the foundation to deliver storage services within the network infrastructure.
As with the introduction of NAS heads in front of FC SANs, it is natural, if not more so than FC SAN, to position NAS heads in front of IP SANs, as both utilize the IP network for interconnects. Taking this trend one step further, by incorporating a clustered file system and network file service protocols (e.g. CIFS and NFS) on the clustered SSCs, the IP SAN becomes multi-dialect with both block and file storage and sharing services (Figure 4).
As opposed to FC SANs that are largely islands due to distance constraints, the multi-dialect IP SANs at geographically dispersed sites can easily be connected over the wide area IP networks and managed centrally (Figure 5). Additional storage services such as data replication for disaster recovery, streaming content distribution, data migration for archival and information life-cycle management can all be made available on the SSCs. Thus, an easily scalable, highly flexible, distributed IP storage service infrastructure will become available as part of the network infrastructure and managed as an overlay service, just as voice-over-IP service is spreading like wildfire today.
Peter Wang is founder CTO, and the "father of IP SAN" at Intransa Inc. (San Jose, CA)
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Storage Networking; Storage area networks|
|Publication:||Computer Technology Review|
|Date:||Nov 1, 2004|
|Previous Article:||The network-centric file management appliance: overcoming the challenges of enterprise file services.|
|Next Article:||Distributed backup is the key to ILM.|