HPE Storage Users Group

We are currently rebuilding a new estate, and i'm now checking if the 3par was set up correctly in the first place. I've been reading about how many hosts you can have connected to host port, and what the recomended way of setting the ports up is.

If i have a 7400 4 node, and i give 1 host 4 links, 1 on each node lets say port 1 on each. Shouldn't all 2 ports go to 1 switch and 2 go to another? and if so i've been reading that you should pair up node pairs. i.e 0 and 1 and 2 and 3. If so surely having a connection to a node pair is another SPOF. I mean as the controllers fit in the same chassis, surely if there was a fault with the chassis it could cause both nodes to fail? so i would think you should pair 0 with 2 and 1 with 3. Is the only reason they recomend the earlier one is for persistant ports?

Also in the same line. I have 4 RCIP over ethernet and i have 2 set for sync and 2 set for async. Is it recomended to have the 2 sync ports split over 0 and 2?

As I currently have the sync ports on nodes 0 & 1 and the async on 2 and 3, once again this doesn't look like the safest option to me, or is there a reason why you shouldn't split them like i think?

For the FC ports... typical standard SAN setup is to have a SAN-A and a SAN-B, 2 different SAN networks, which implies 2 separate sets of switches. It is advisable to have every NODE connected to both SAN-A and SAN-B, and DO NOT put all of NodeX on switch 1 and all of NodeY on switch 2.

For persistent ports... they want the same port on each node pair on the same SAN... a good example that allows port persistence to work is Node0,Node1,Node2,Node3 all have port 1:1 on SAN-A switch 1, and all have port 1:2 on SAN-B switch 2... and both switches need to have NPIV enabled. A BAD example that would cause port persistence to fail would be the opposite, Node0 port 1:1 on SAN-A but Node1 port 1:1 on SAN-B.

I will let someone else address the RC links, as I do not use RC very much.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

Agree with Richard regarding the ports, all the nodes first ports should go to one fabric and the second set of ports to the other fabric.

Then when assigning hosts, I don't think it really matters which nodes you assign the hosts to as long as you balance them, but you're going to want to assign a host to two of the nodes, not a single port from 4 nodes. Otherwise if you were to map a host to all the first ports on the nodes, they would all be going to a single fabric switch which would be a single point of failure.

So either map a host to nodes 0 and 2 or 1 and 3, a single port on each node would be ok, but you'd want to pick the first ports from 2 nodes and then the second ports from the other two nodes to make sure you were straddling both fabrics.

I probably haven't explained it very well sorry.

With regards to the remote copy ports, I don't think there is a rule as to how the links are set up, I can see arguments for using nodes 0 and 1 for sync and 2 and 3 for async, and also for using nodes 0 and 2 and 1 and 3. All you need to try and make sure is that the links are resilient, so if you have two links using different switches, making sure the 2 links for sync are going to different switches etc.

We are currently have all port 1 going to one switch and all port 2 going to another switch as suggested above. But now i've checked i can see this has been setup wrong, as we have hypervisors that have been set to using just port 1. So if that switch was to fail we would lose that hypervisor. 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.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

I understand that all port 1's go to san-a and all port 2's go to san b. But I thought to use port persistance you had to have they same ports used on the node pair. So in your example

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.

surely to use peer persitance that hypervisor needs to be zoned to port 1 on the node pair, and in its current setup the node pairs aren't zoned?

Surely if i'm not clear, i'm just trying to fully understand this.

As I (think to) understand it:

1) Best practice guide simply suggests uneven (last digit) ports to fabric A, even ports to fabric B

2) persistent Ports requirement: port pair that can take over for each other must be in same fabric, is automatically met with 1)

3) If you use WWN-Zoning, you do NOT neet to zone your hosts to both ports in a persistent ports pair, as the second ports takes over the other ports wwn (and thus, all zonings) in case of port failover

4) peer persistence is something completely different, hosts have to be zoned to the second array (on whatever ports you want) for it to work. Hosts have to be on ESX-persona, see primaries and secondaries, and ESX must be newer than a certain version etc.

_________________
When all else fails, read the instructions.

Indeed, people often get confused between peer persistence and persistent ports.

All odd ports go to one fabric and all even ports to the other fabric.

In a 2 node system with 2 ports per controller you zone all ports to the server, it's only when you add an additional card in, or have 4 nodes that you start to pick and choose which ports get presented to which servers. As a start, you will normally have a minimum of 4 ports per server, these ports will be split across the nodes.

Because we are zoning by wwpn (port bead zoning is not recommended for 3par), as long as you follow the rules about all odds going to one fabric and all evens going to the other, then persistent ports will sort itself out.

This is not entirely true, ifyou have a 2 node system with just 4 ports, in that case you would zone all the ports.

Clear as mud yet?

If port 1 from each node is on SAN-A.... your zone tells SAN-A to allow your host's WWN to talk to the storage WWN... port persistence will move that WWN from port to port automatically, the zone will remain as is.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.