I will be astonished if anyone has the time to read this book and help, but I do desperately need assistance. Believe it or not, I have actually tried to abbreviate this question. If you have the time, please read it and give me your thoughts. It would be most appreciated.
** Environment **
Switching:
(2) MDS 9222i fibre channel fabric switches
Storage:
(1) StorageTek 6140, 1 fully populated 4TB tray
Storage to be divided equally between NTFS and VMFS vdisks/volumes
(1) StorageTek SL48 tape library
Hosts:
(1) Win2003R2 file server (gets the NTFS volume)
(4) ESX4.0 bare metal hosts cluster (get the VMFS volume)
All hosts have 2 NICs and 2 FC HBAs. Each HBA pair is jumpered to a different switch. Windows host has FC multipathing driver installed.
Applying LAN concepts to the SAN, concerns such as purpose, security, and availability drive segmentation. In the above case, the array will likely be in only one VSAN, but that's only because its disparate functions are served from a single physical tray. Otherwise, I'd put a designated VMware data source (which we don't have) in the same VSAN with VMware hosts. As it happens, all I can do is segment host and device types as best I can.
My initial thinking about installing the above equipment was to create VSAN200 for the array; VSAN300 for the file server; VSAN400 for all VMware hosts; and VSAN500 for the tape library. Both initiators for each host would reside in the same VSAN, though on separate switches, whether ISL'd or not. IVR zoning would then be employed to allow the FC tape library to talk to all VSAN hosts and all hosts on different VSANs to talk to the array. In my thinking, ISLing the switches would just keep me from duplicating the config. However, I have two stumbling blocks to what I thought was a straightforward setup.
First, it was strongly suggested that I completely forgo use of ISLs and instead maintain two physical switches, isolating their respective virtual fabrics but also creating for each host HBA pair non-intersecting VSANs, one on each isolated switch. To me, this seemed to be expectant of an ultimate ISL and, thus, contradictory. Contradictions aside, though, it was an idea that at least got me thinking my next point represented some kind of standard.
An instructor at a recent training venue suggested that in addition to the recommended "single-initiator-per-zone
-law" (SIZL) it is advisable to also place redundant host initiators into different VSANs, just in case one VSAN goes down. I can see why this might be ideal, but I've got to say that it really adds bulk to the config. Following this logic, the scaled-down environment I've represented above would generate the following:
(1 VSAN/HBA) (7 nodes) (2 HBAs/node) = 14 VSANs
...add to that 14 zonesets, etc., etc.
Questions
1. Should I ISL these switches or keep them isolated? They currently represent my "core".
2. What would you say my VSANs and zoning should look like?
Thanks!
