The Basics of SAN Implementation, Part II Page 2 - EnterpriseStorageForum.com

The Basics of SAN Implementation, Part II Page 2

Implementing Integrated SANs

Until now, customers preparing SAN implementations have been faced with two broad choices: a standards-based multi-vendor solution that forces the customer to select each piece and then attempt to integrate a total solution, or an integrated proprietary SAN solution from a single vendor. A third option is rapidly evolving: an integrated open standards SAN.

The open integrated SAN has the potential to provide the needed interoperability with the advantages of the multi-vendor market competition, even though implementing a SAN is clearly not a plug-and-play solution. This allows customers to pick and choose the individual SAN components that best meet their unique needs. Thus, the open standards concept based on inter-vendor product testing and certification is critical to the growth of SANs.

Depending on the size of the installation, the SAN hardware opportunity is not limited to Fibre Channel switches, routers and the Fibre cabling. These components will complement Fibre-ready disk array and tape libraries. On the software side, traditional backup applications will be used in first-generation SAN applications, but will be SAN aware to take advantage of the LAN-free and server-free backup applications.

Now, let's look at how to implement SANs for clusters in a variety of configurations. This would include consolidations and those with SAN appliances.

Implementing SANs for Clusters

Dual fabrics are separate storage networks between the servers and the storage enclosures. The use of two separate fabrics ensures that no component within the storage subsystem (Host Bus Adapter (HBA), cable, or RAID controller) is a single point of failure for the cluster. Dual fabrics effectively double throughput from the server to the storage, while also protecting the system against component failures. Implementing a switched SAN adds a significant number of capabilities to the cluster:

  • Backup over SAN: Servers share tape backup devices and perform backup operations over the SAN rather than over the network.
  • Many-to-one cluster configurations: Cluster consolidation with up to 10 clusters sharing a single storage system and optional tape backup device(s).
  • Mixed storage and cluster consolidation configurations: Multiple clusters and stand-alone servers with heterogeneous supported operating systems sharing the same storage system and optional tape backup device(s).
  • Multipathing: Redundant, active HBA-to-controller connections.
  • One-to-many cluster configurations: One cluster with multiple storage systems.

Several different storage technologies, including logical unit number (LUN) masking and Fibre Channel switch zoning, enable these configurations for clusters. Because various operating systems claim all accessible disks, zoning and LUN masking techniques ensure that each server or cluster attached to the SAN does not see or have access to disks belonging to other servers or clusters.

Storage and Cluster Consolidation

In the storage environment, consolidation relates to multiple servers using resources within a single enclosure. Consolidation examples include:

  • Cluster consolidation: Shared storage for multiple clusters coexists within the same Fibre Channel enclosure attached to a SAN.
  • SAN-consolidated backup: Tape backup changers and autoloaders accessed by multiple servers over a storage area network.
  • Storage consolidation: Two or more servers each have dedicated RAID volumes inside a single storage enclosure.

    With clusters, all of these configurations should be tested, documented, and supported simultaneously on the same SANs. Each storage enclosure should support stand-alone nodes and cluster pairs. The cluster pairs should be running the same operating system on both nodes, but clusters can coexist in the same SAN, and even share the same storage enclosure.

    Integrating the SAN Appliance Implementation

    A SAN appliance implementation should enhance the availability and capabilities of the SAN. The SAN appliance is a central point of intelligence for the SAN that enables storage replication, snapshots, and virtualization in an integrated appliance rather than distributing the implementation of these features across a variety of different hardware components and software tools. Furthermore, by off-loading the processing required to execute these solutions from the servers and storage devices, the SAN appliance is appropriate for high-performance configurations and mission-critical data connected to stand-alone servers and clusters.

    A SAN appliance usually sits logically "between" the host servers and the storage, but adds only minimal latency to the overall storage system. The SAN appliance should be able to assign "virtual" storage units to each host server. The host server is unaware of the specific physical disk, array, or enclosure that it is actually using since the SAN appliance should be able to "map" the storage to any available target ID and LUN.

    Each redundant pair of SAN appliances should be able to virtualize up to four storage systems. As with the SAN-attached configurations, each redundant pair of SAN appliances should be able to support up to 10 cluster pairs or a combination of up to 20 clustered and nonclustered hosts.

    Partitioning can be useful for separating logical data units or for enforcing quotas. When configuring an active/active cluster in which separate disk resources must be available for both servers, the creation of multiple RAID volumes is a requirement.

    A SAN appliance can be configured to provide data replication either locally (over a Fibre Channel network), remotely (over an IP network), or both. This process is transparent to the cluster nodes and the applications.

    For combined local and remote mirroring, also referred to as three-way mirroring, the source RAID volume is replicated to two different targets: one locally using Fibre Channel (packetized SCSI over Fibre Channel) and one remotely using an IP network. The availability of a local copy of the storage protects the cluster from a complete failure of the primary storage system. The SAN appliance can detect the failover of the primary storage system and make the failover to the local replica instantly, without interfering with the cluster's operations. If both copies of the local storage fail, all I/Os are routed to the remote storage.


    Page 2 of 4

    Previous Page
    1 2 3 4
    Next Page

    Comment and Contribute

     


    (Maximum characters: 1200). You have characters left.

     

     

Storage Daily
Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date