El empleo en la “Vieja Economía”, la “Nueva Economía” y los Servicios de Apoyo.

The SAN is primarily responsible for the flow of data between devices. Managing this device communication is of utmost importance for the effective, efficient, and also secure use of the storage network. Zoning plays a key role in the management of device communication. Zoning is used to specify the devices in the fabric that should be allowed to communicate with each other. If zoning is enforced, devices that are not in the same zone cannot communicate. In addition, zoning provides protection from disruption in the fabric. Changes in the fabric

delivery to devices when there is a change within their zone. (This also reduces the

processing overhead on the switch by reducing the number of RSCNs being delivered.) Thus, only devices in the zones affected by the change are disrupted. Based on this fact, the best practice is to create zones with one initiator and one target with which it communicates, so that changes to initiators do not affect other initiators or other targets, and disruptions are minimized (one initiator and one target device per zone). In addition, the default zone setting (what happens when zoning is disabled) should be set to No Access, which means that devices are isolated when zoning is disabled.

Zones can be defined by either a switch port or device worldwide name (WWN). Although it takes a bit more effort to use WWNs in zones, it provides greater flexibility. If necessary, a device can be moved to anywhere in the fabric and maintain valid zone membership. For more information about how to use zoning for a security storage network, see section 2.11, “Security” on page 72.

Below, we describe the zoning best practices and guidelines to establish communication between your storage subsystem and your ESXi hosts.

The suggested SAN configuration is composed of a minimum of two redundant fabrics with all host ports. The IBM Storwize V7000/V3700 ports themselves are evenly split between the two fabrics to provide redundancy if one of the fabrics goes offline (either planned or unplanned).

In each fabric, create a zone with just the four IBM Storwize V7000/V3700 WWPNs, two from each node canister. Assuming that every host has a Fibre Channel connection to each fabric, then in each fabric, create a zone with the host WWPN and one WWPN from each node canister in the IBM Storwize V7000/V3700 system.

Figure 2-19 on page 47 shows how to cable devices to the SAN. See this example as we describe the zoning.

Figure 2-19 SAN cabling and zone diagram for IBM Storwize V7000/V3700 and a couple of ESXi hosts

First of all, create a cluster zone for your V7000/V3700 consisting only of all node ports in a single zone (per fabric). For example:

RED ZONE

򐂰 Node_Canister1_port_1 + Node_Canister1_port_3 + Node_Canister2_port_1 + Node_Canister2_port_3

BLUE ZONE

򐂰 Node_Canister1_port_2 + Node_Canister1_port_4 + Node_Canister2_port_2 + Node_Canister2_port_4

Second, create a zone from the host to the clustered system. For example: RED ZONES

򐂰 ESX Server 1 port A with both nodes canisters port 1s 򐂰 ESX Server 2 port A with both nodes canisters port 3s BLUE ZONES

As a best practice, create the host zones with a single initiator. Do not group multiple initiators from the same host or additional hosts into the same zone. Use one host initiator port per zone.

VMware ESXi has a maximum of 256 SCSI devices per ESXi host with a maximum number of paths per host of 1024. The number of SCSI devices per host is limited if the number of paths hits 1024 paths. For example, eight paths per SCSI device would yield 128 SCSI devices possible on a host (1024/8). As a result, the recommendation is to limit the number of paths to any one volume to no more than four paths. This will allow for the maximum number of 256 SCSI devices to attach to the ESXi host.

The same concept applies for the SAN Volume Controller (SVC). Figure 2-20 shows how to cable devices to the SAN. Refer to this example as we describe the zoning.

Figure 2-20 SAN cabling and zone diagram for IBM SAN Volume Controller and two ESXi hosts

First of all, create a cluster zone for your SVC consisting only of all node ports in a single zone (per fabric). For example:

RED ZONE

򐂰 Node_1_port_1 + Node_1_port_3 + Node_2_port_1 + Node_2_port_3 BLUE ZONE

Second, create a zone from the host to the clustered system. For example: RED ZONES

򐂰 ESX Server 1 port A with both nodes port 1s 򐂰 ESX Server 2 port A with both nodes port 3s BLUE ZONES

򐂰 ESX Server 1 port B with both nodes port 2s 򐂰 ESX Server 2 port B with both nodes port 4s

There must be a single zone for each host port. This zone must contain the host port, and one port from each SVC node that the host will need to access. Although there are two ports from each node per SAN fabric in a usual dual-fabric configuration, ensure that the host accesses only one of them.

Now, if your ESXi host has four (or more) host bus adapters, it takes a little more planning because eight paths are not an optimum number. You must instead configure your zoning (and SVC host definitions) as though the single host is two or more separate hosts.

Figure 2-21 shows how to cable devices to the SAN. Refer to this example as we describe the zoning.

Therefore, in this case your zoning should look like this: RED ZONES

򐂰 ESX Server 1 port A with both nodes port 1s 򐂰 ESX Server 1 port C with both nodes port 3s 򐂰 ESX Server 2 port A with both nodes port 1s 򐂰 ESX Server 2 port C with both nodes port 3s BLUE ZONES

򐂰 ESX Server 1 port B with both nodes port 2s 򐂰 ESX Server 1 port D with both nodes port 4s 򐂰 ESX Server 2 port B with both nodes port 2s 򐂰 ESX Server 2 port D with both nodes port 4s

During volume assignment, alternate which volume is assigned to one of the “pseudo-hosts”, in a round robin fashion (a pseudo-host is nothing more than another regular host definition in the SVC host configuration. Each pseudo-host contains two unique host WWPNs, one WWPN mapped to each fabric).

Be careful not to share the volume to more than two adapters per host so you do not over-subscribe the number of datapaths per volume, per host.

Sample of pseudo-hosts with two WWPNs per host: 򐂰 ESX_Server1_AB

򐂰 ESX_Server1_CD 򐂰 ESX_Server2_AB 򐂰 ESX_Server2_CD

Sample of how to host map the volumes:

򐂰 volume1 shared to ESX_Server1_AB and ESX_Server2_AB 򐂰 volume2 shared to ESX_Server1_CD and ESX_Server2_CD 򐂰 volume3 shared to ESX_Server1_AB and ESX_Server2_AB 򐂰 volume4 shared to ESX_Server1_CD and ESX_Server2_CD

You can also find zoning guidelines regarding the storage subsystems on their specific IBM Redbooks publications, as follows:

򐂰 Implementing the IBM Storwize V7000 V6.3, SG24-7938

򐂰 Implementing the IBM System Storage SAN Volume Controller V6.3, SG24-7933

򐂰 Implementing the IBM Storwize V3700, SG24-8107

򐂰 Implementing the IBM Storwize V3500, SG24-8125

Note: A pseudo-host is not a defined function or feature of the SVC. If you need to define a

pseudo-host, you are simply adding another host ID to the SVC. Instead of creating one host ID with four WWPNs, you would define two hosts with two WWPNs. This is now the reference for the term,

pseudo-host

Note: For the examples, it was assumed that the Storwize V7000 and the Storwize V3700

are not being used to virtualize any external storage subsystem, meaning that they both are using internal disks. Therefore, no additional zoning is needed. For external disk zoning, we suggest that you check the SVC guidelines for configuring and servicing external storage subsystems at the IBM SAN Volume Controller Information Center: