Storage system configuration rules

Follow these rules when you are planning the configuration of storage systems for use with SAN Volume Controller clusters.

See the following Web site for the latest support information:

www.ibm.com/storage/support/2145

All SAN Volume Controller nodes in a cluster must be able to connect to the same set of storage system ports on each device. A cluster that contains any two nodes that cannot connect to the same set of storage-system ports is considered degraded, and a system error is logged that requires a repair action. This rule can have important effects on a storage system such as an IBM® System Storage® DS4000® series controller, which has exclusion rules that determine to which host bus adapter (HBA) worldwide node names (WWNNs) a storage partition can be mapped.

A storage-system logical unit (LU) must not be shared between the SAN Volume Controller and a host.

You can configure certain storage controllers to safely share resources between the SAN Volume Controller cluster and direct attached hosts. This type of configuration is described as a split controller. In all cases, it is critical that you configure the controller and SAN so that the SAN Volume Controller cluster cannot access logical units (LUs) that a host or another SAN Volume Controller cluster can also access. This split controller configuration can be arranged by controller logical unit number (LUN) mapping and masking. If the split controller configuration is not guaranteed, data corruption can occur.

Besides a configuration where a controller is split between a SAN Volume Controller cluster and a host, the SAN Volume Controller cluster also supports configurations where a controller is split between two SAN Volume Controller clusters. In all cases, it is critical that you configure the controller and SAN so that the SAN Volume Controller cluster cannot access LUs that a host or another SAN Volume Controller cluster can also access. This can be arranged by controller LUN mapping and masking. If this is not guaranteed, data corruption can occur.

Attention: Avoid configuring a storage system to present the same LU to more than one SAN Volume Controller cluster. This configuration is not supported and is likely to cause undetected data loss or corruption.

Unsupported storage systems

When a storage system is detected on the SAN, the SAN Volume Controller attempts to recognize it using its Inquiry data. If the device is not supported, the SAN Volume Controller configures the device as a generic device. A generic device might not function correctly when it is addressed by a SAN Volume Controller cluster, especially under failure scenarios. However, the SAN Volume Controller cluster does not regard accessing a generic device as an error condition and does not log an error. Managed disks (MDisks) that are presented by generic devices are not eligible to be used as quorum disks.

Split storage system configuration rules

The SAN Volume Controller cluster is configured to manage LUs that are exported only by RAID storage systems. Non-RAID storage systems are not supported. If you are using SAN Volume Controller to manage solid-state drive (SSD) or other JBOD (just a bunch of disks) LUs that are presented by non-RAID storage systems, the SAN Volume Controller cluster itself does not provide RAID functions; so these LUs are exposed to data loss in the event of a disk failure.

If a single RAID storage system presents multiple LUs, either by having multiple RAID configured or by partitioning one or more RAID into multiple LUs, each LU can be owned by either the SAN Volume Controller cluster or a direct-attach host. LUN masking must also be configured, to ensure that LUs are not shared between SAN Volume Controller nodes and direct-attach hosts.

In a split storage system configuration, a storage system presents some of its LUs to a SAN Volume Controller cluster (which treats the LU as an MDisk) and the remaining LUs to another host. The SAN Volume Controller cluster presents virtual disks (VDisks) that are created from the MDisk to another host. There is no requirement for the multipathing driver for the two hosts to be the same. Figure 1 shows that the RAID controller could be an IBM DS4000, for example, with RDAC used for pathing on the directly attached host, and SDD used on the host that is attached with the SAN Volume Controller. Hosts can simultaneously access LUs that are provided by the SAN Volume Controller cluster and directly by the device.

Note: A connection coming from a host can be either a fibre-channel or an iSCSI connection.
Figure 1. Storage system shared between SAN Volume Controller node and a host
This figure depicts a shared disk controller system.
It is also possible to split a host so that it accesses some of its LUNs through the SAN Volume Controller cluster and some directly. In this case, the multipathing software that is used by the storage system must be compatible with the SAN Volume Controller multipathing software. Figure 2 is a supported configuration because the same multipathing driver is used for both directly accessed LUNs and VDisks.
Figure 2. IBM System Storage DS8000® LUs accessed directly with a SAN Volume Controller node
ESS LUs accessed directly and through the SAN Volume Controller
In the case where the RAID storage system uses multipathing software that is compatible with SAN Volume Controller multipathing software (see Figure 3), it is possible to configure a system where some LUNs are mapped directly to the host and others are accessed through the SAN Volume Controller. An IBM TotalStorage® Enterprise Storage Server® (ESS) that uses the same multipathing driver as a SAN Volume Controller node is one example. Another example with IBM DS5000 is shown in Figure 3.
Figure 3. IBM DS5000 direct connection with a SAN Volume Controller node on one host
DS5000 direct connection and SAN Volume Controller node on one host
Library | Support | Terms of use | Feedback
© Copyright IBM Corporation 2003, 2009. All Rights Reserved.