Specifications

www.ibm.com/support/techdocs 19

Summary of Best Practices for Storage Area Networks

the host workload can be tailored to use multiple threads or spread the work across

multiple volumes.

The XIV Storage architecture was designed to perform under real-world customer

production workloads, with lots of I/O requests at the same time. Queue depth is an

important host bus adapter (HBA) setting because it essentially controls how much

data is allowed to be “in flight” onto the SAN from the HBA. A queue depth of 1

requires that each I/O request be completed before another is started. A queue

depth greater than one indicates that multiple host I/O requests might be waiting for

responses from the storage system. So, the higher the host HBA queue depth, the

more parallel I/O goes to the XIV Storage System.

The XIV Storage architecture eliminates the legacy storage concept of a large

central cache. Instead, each component in the XIV grid has its own dedicated

cache. The XIV algorithms that stage data between disk and cache work most

efficiently when multiple I/O requests are coming in parallel - this is where the queue

depth host parameter becomes an important factor in maximizing XIV Storage I/O

performance.

A good practice is starting with a queue depth of 64 per HBA, to ensure exploitation

of the XIV’s parallel architecture. Nevertheless the initial queue depth value might

need to be adjusted over time. While higher queue depth in general yields better

performance with XIV one must consider the limitations per port on the XIV side.

Each HBA port on the XIV Interface Module is designed and set to sustain up to

1400 concurrent I/Os (except for port 3 when port 4 is defined as initiator, in which

case port 3 is set to sustain up to 1000 concurrent I/Os). With a queue depth of 64

per host port as suggested, one XIV port is limited to 21 concurrent host ports given

that each host will fill up the entire 64 depth queue for each request.

Generally there is no need to create a large number of small LUNs except when the

application needs to use multiple LUNs to allocate or create multiple threads to

handle the I/O. However, more LUNs might be needed to utilize queues on the host

HBA side and the host Operating System side. However, if the application is

sophisticated enough to define multiple threads independent of the number of LUNs,

or the number of LUNs has no effect on application threads, there is no compelling

reason to have multiple LUNs.