Determining the fan-out ratio: Port queue depth, IOPS and throughput

Determining the optimum number of hosts that a storage administrator should connect per storage port is more complicated than it seems.

When it comes to fan-out ratios, what is the optimum number of hosts that a storage administrator should connect per storage port?

This should be a fairly simple question. But it's not, once you take into consideration clustered hosts, virtual machines and number of LUNs per server. How do these affect the number of hosts we should connect?

First, we should define the term fan-out ratio. Fan-out ratio represents the number of hosts that are connected to a single port of a storage array. In determining how many hosts to connect to a particular storage port, there are three things to consider: port queue depth, IOPS and throughput.

Port queue depth – Since a port can only service one request at a time, additional requests are placed in the port queue to be serviced when the current one is complete. Once the port queue depth is reached, any further requests are rejected until space in the queue becomes available. When a host is attached to a storage port, the maximum port queue depth for an HBA can be calculated by the following formula:

Max. port queue depth of the HBA = HBA setting * number of LUNs on HBA

What is IOPS – This is the maximum number of IO operations that a port can service per second. In order to guarantee that a port will not be saturated, you would need to add up the maximum IOPS for all hosts connected to a storage port and ensure that this does not exceed the allowed figure.

What is throughput – Most storage ports today have a maximum bandwidth of 4Gbps. The same rules for non-saturation of a port apply here as to queue depth and IOPS: Add up the figures for each host on the port and the total should not exceed 4Gbps.

To guarantee that no traffic on a port will be rejected, you'll need to perform significant analysis to ensure that none of the three figures above will be exceeded. Although you'll be able to guarantee service levels, you'll also likely have an infrastructure that is overengineered and underutilised, and therefore more expensive to run than is necessary.

In practice, it is highly unlikely that all hosts will be performing at their maximum level at any one time. It is therefore prudent to oversubscribe ports to ensure a balance between cost and performance.

A common rule of thumb (one I use if no other information is available) is to limit the number of hosts per storage port to ten (this can be increased to 20 if hosts are connected to more than one port and are using dynamic multi-pathing software).

Another option is to divide the storage on the array among the attached hosts and allocate hosts to ports based on capacity. The theory here is that the hosts with the largest data requirement will need more throughput and you should therefore configure fewer "large" hosts per port.

Whichever method you choose, once you've completed this initial seeding, port monitoring should be used to ascertain which ports are least utilised, and therefore where the next batch of hosts should be connected in order to minimise the impact to the array and the existing hosts.

About the author: Steve Pinder is a principal consultant at GlassHouse Technologies (UK) Ltd. He has more than 11 years experience in backup and storage technologies and has been involved in many deployments for companies of varying size, with responsibilities ranging throughout the sales and deployment lifecycle. Prior to working for GlassHouse, he was an IT contractor concentrating on backup and network management roles.

Read more on Storage fabric, switches and networks