HPE Storage Users Group

Just a quick and simple question from me;

In terms of service times is is better to have all 6 host ports cabled and used in zoning or would cabling 4 be better or worse. We don't believe bandwidth will be an issue, however will the array in terms of host port queues and service times benefit from having more ports used with a smaller amount of IO vs less host ports used with more? I hope that makes sense?

I'm not sure what the best practice would be?

Each path from a host to a storage port creates a initiator entry on the array and you only have a limited number of initiators to play with depending on the array model and firmware version. It's a case of balancing zoning simplicity versus overall scalability. Just my personal opinion but in most cases I would look to give your hosts just what they need to get the job done. So if they are physical servers give them a couple of ports, if they are hypervisors with many guests give them 4 ports.

If you just want to keep it simple and aren't worried about many hosts attaching then you can zone in the rest, but as you add more ports this may cause more complexity and will burn more of your available initiator entries. If you're not bandwidth constrained more ports will have minimal impact on service times as most of the measurable delay should be from disk.

There might be more in the latest best practice guide http://h20195.www2.hp.com/V2/GetPDF.asp ... 524ENW.pdf

I highly recommend cabling up all the 3PAR host ports available to you from day 1 and evenly distributing your hosts across them from the beginning... try to keep it even and symmetrical... storage Feng Shui.

Its better to have 8 ports at 10% utilization vs 4 ports at 20%, or 2 ports at 80%.
Ports have 2 limiting factors, GB/s is the one everyone pays attention to, but they also have limits to how many IO/s each port/card can do... this is often not published either. Someone already mentioned the limit of how many initiators per port you have, and I would like to go further to point out that each storage port has a limit of how many queued IO it can support - see the graph below, taken from the 3PAR-ESX5 best practices doc:



This is the total queue depth per "target port"... each host connected to a port may have a per Lun queue depth of 32 or 64.

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

Thanks Richard, that I think you've understood what I was refering too which was in terms of queue depths on each host port and how the array handles that. In terms of initiators that isn't the issue at the moment however we do have unknown IO workloads coming from both physical and virtual environements. What I want to ensure is that service times are as good as they can be;

Richard can you take your explanation further in terms of the following extract;
Its better to have 8 ports at 10% utilization vs 4 ports at 20%, or 2 ports at 80%

That was my base understanding in the way that the array services each queue, but I can't find anything specifically outlining that theory / understanding.

Thanks for the quick response guys

The first T800 I installed came with 16 front end ports, of which I only cabled up 8... over time our host counts grew and to the point where I was concerned that we might be saturating some ports, and needed to bring the extra 8 ports online and redistribute hosts across all 16... rebalancing hosts to even out the initiators per port is an inconvenience to sysadmins and san admins that could have been avoided.

Of course that depends on your situation... our SAN storage has traditionally been managed like a Utility service... as new apps pop up, we connect them to an existing array and carve out space. This year we are trying something new, and doing "purpose built arrays" where we design and a dedicate an entire array to VMware. I imagine if your requirements are static parameters, you can probably make an informed decision that only 4 of x ports will be needed.

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