koopa79 wrote:
So i've been looking at using persistant ports and i'm currently thinking of setting up the zoning to have the following zoned to a hypervisor.
node 0 port 1
node 1 port 1
node 2 port 2
node 3 port 2
So am i right in thinking this is valid setup and would allow for peer persistance?
Close... I would suggest:
node 0 port 1 (SAN-A)
node 1 port 2 (SAN-B)
node 2 port 1 (SAN-A)
node 3 port 2 (SAN-B)
--- Call that group SET1, zone hypervisor1 to SET1.
node 0 port 2 (SAN-B)
node 1 port 1 (SAN-A)
node 2 port 2 (SAN-B)
node 3 port 1 (SAN-A)
--- Call that group SET2, zone hypervisor2 to SET2.
Why? port persistence will still work, since both Node0 and Node1 have port 1 on the same switch. The big difference is that when you do use port persistence, your 1 hypervisor wont be double teaming a single port and will be spreading its traffic to 2 separate ports on the same Node. This could get ugly if you have 1 busy hypervisor with 2 8gb HBAs pounding a single storage port.
Somewhere up the chain it was mentioned to zone the host to a node pair, I neglected to address that with this suggestion: Since you have 4 nodes, I recommend 4 paths from your hosts to storage... 2 host HBAs, one on SAN-A, one on SAN-B, zoned to see 2 nodes. In my sets example above that would be Hypervisor1-HBA1 zoned to see 1:1:1 and 3:1:1, and HBA2 zoned to see 0:1:2 and 2:1:2. Why? It distributes the workload evenly across all 4 nodes, and in such a way that a single host can not max out/saturate the storage ports...
Assuming the clients and storage all run at 8gb speeds, zoning 1 host with 2 HBAs to 2 storage ports would allow 1 host to put 2 storage ports at 100% util. In an environment where the ports are shared by other hosts, this creates a bully/victim situation. By zoning 1 hba to 2 storage ports, the worst case is that 1 host will bring 4 ports to 50% util... the likely hood of 2 hosts both going rogue at the same time, and being assigned to the same "set" of ports is much much slimmer.