HP StorageWorks SAN Virtualization Services Platform Best Practices Guide (5697-0935, May 2011)

In SVSP, there needs to be zoning that keeps a good conversation flow among the initiators and
targets of these devices.
TargetInitiator
DPMHost
Storage arraysDPM
Storage arraysVSM server
VSM serverVSM server
DPMVSM server
VSM serverDPM
Alternatively, you want to prohibit any communication between these devices:
TargetInitiator
VSM serverHost
SVSP back-end LUHost
HostHost
ArrayArray
Figure 5 (page 15) shows the original zoning used with SVSP, which has since been changed. It
is useful to describe the issues that arose because of this type of zoning:
• The front-end DPM ports could see all the host ports, creating many paths, which would prevent
you from achieving full front-end scaling.
• The back-end DPM ports could see all the array ports. This prevents you from achieving full
scale and could allow for unwanted array-to-array communication, also compromising array
scalability.
• The VSM data mover needs to be able to address the back end arrays. It is very important to
ensure servers are not allowed to communicate with these LUNs through the VSM. The
recommendation is that the LUNs be masked so that they are used by the VSM as well as
zoned for protection.
• Hosts could see other hosts.
• DPMs and VSM servers could see unnecessary traffic and state change notifications. This is
mostly historical, however there is no need for observing these notifications, and with many
operating systems in the SAN, this is a safety net.
• Presenting a LUN from an array to a server caused all LUNs from all arrays to be seen. While
this is similar to the current method of performing selective host presentation, it was more
critical to data integrity.
14 Fabric topology