• Zoning
• Fault Tolerance Topology
See References for Information on SANs on page 52 for links to sources for more information on SAN topologies.
High Availability Topology
The goal of a SAN designed for high availability is to function continuously, even if any of its individual components fail. High availability is achieved through the use of redundant components and paths from the host servers through the SAN switches to the storage arrays.
SANs that are designed for high availability may contain dual fabrics. Each server and storage array interfaces to two separate SAN switches that provide completely separate paths from the server to the storage array. Each server has at least one HBA connected to each SAN switch.
Operationally, the SAN may allow each fabric to share the I/O load or one fabric may be active and the other passive. In this second case, there is a switchover to the second fabric in the event that there is an I/O or a path failure in the first fabric. High availability SANs offer fault resilience by being able to continue functioning after the failure of a component, path, device, or SAN switch. An added benefit of using a second SAN fabric is that maintenance of the SAN is easier: if necessary, the second fabric operates while the first fabric is being repaired.
A high availability (HA) SAN features dual paths to all components.
Zoning
The nodes on a SAN can be grouped into zones. When a SAN is configured in this way, the nodes outside a zone are not visible to the nodes inside the zone. In addition, the SAN traffic within each zone is isolated from the other zones.
Within a complex SAN environment, SAN switches provide zoning. This zoning defines and configures the necessary security and access rights for the entire SAN. Zoning defines which servers can access which LUNs to prevent device-sharing conflicts among the servers.
Typically, zones are created for each group of servers that access a shared group of storage LUNs. There are multiple ways in which zones may be used. Here are some examples:
• Zoning by operating system. If the SAN is being accessed by heterogeneous servers running Solaris, Linux, Windows, or UNIX, the servers may be grouped by operating system, and SAN zones may be defined for each group of servers. This prevents access of these LUNs by other groups or by other classes of servers.
• Backups. Another use of zones is to allow common server access for backups. SAN designs often have a backup server with tape services that require SAN- wide access to host servers individually for backup and recovery processes. These backup servers need to be able to access the servers they back up. A SAN zone may be defined for the backup server to access a particular host to perform a backup or recovery process when the backup server is ready to perform backup or recovery processes on that host.
• Security. Zoning also provides security. Zones defined for testing can be managed independently within the SAN and do not interfere with the activity going on in the production zones.
• Multiple Storage Arrays. Zones are also useful when there are multiple storage arrays. Through the use of separate zones, each storage array can be managed separately from the others, with no concern for access conflicts between servers.
Fault Tolerance Topology
The ability for the entire SAN environment to sustain and recover from a failure is an essential design goal. This section discusses ways of making your SAN fault tolerant.
• Redundant SAN components. At the hardware level, redundant SAN components are required. This includes HBAs, SAN switches, and storage array access ports. In some cases, multiple storage arrays are part of a fault tolerant SAN design.
• Redundant I/O paths. From an operational viewpoint, I/O paths from the server to the storage array must also be redundant and dynamically switchable in the event that a failure occurs of a port, device, cable, or path.
• I/O Configuration. The key to providing fault tolerance is within the configuration of each server’s I/O system.
• With multiple HBAs, the I/O system can perform I/O operations across any of the HBAs to the assigned LUNs.
• In the event of a HBA, cable, or SAN switch port failure, the path is no longer available and an alternate path is required.
• If there is a failure in the primary path between the SAN switch and the storage array, then an alternate path at that level is required.
• In the event that a SAN switch fails, the entire path from server to storage array is disabled, so a second fabric with a complete alternate path is required.
• Mirroring. From a server application perspective, protection against LUN failure allows the application to sustain faults in its access of storage. This is often accomplished through the use of mirroring.
Mirroring designates a second non-addressable LUN that captures all writes to the primary LUN. With this technique, mirroring provides fault tolerance at the LUN level. LUN mirroring can be implemented at the server, SAN switch, or storage array level.
• Duplication of SAN environment. For extreme high availability requirements, SAN environments may be duplicated to provide disaster recovery on a site basis. This requires duplication of the SAN environment at different physical locations. The two resultant SAN environments may share operational workloads or the second SAN environment may be a failover-only site.