HP StorageWorks SAN Virtualization Services Platform administrator guide (5697-0204, January 2010)

avoid going over all the back-end LUNs in the pool to find the best match (for example, the smallest
contiguous free area that is greater than or equal to the required capacity) in order to save time
(at least for PiT expansions time is a critical factor). When additional virtual disks are configured,
a back-end volume is selected at random, and the algorithm seeks to find a contiguous free space.
This applies to the temporary volumes used to support PiTs, snapshots, thin provisioning, and so
on, too.
• One tradeoff of this simple general purpose pool construction approach is that it uses back-end
volumes and back-end paths in quantities that can run out before achieving the maximum capacity
or maximum number of arrays. The maximum number of back-end volumes supported in SVSP v3
is 1024 (512 in versions before v3). The maximum number of back-end paths supported to each
back-end volume is eight. The maximum number of back-end paths per DPM is 4K (these correspond
to a data structure called physical storage containers (PSCs).
Building storage pools using stripe sets
The capacity-optimized pools described above are a good starting point, but it may not be the best
choice for all situations. One issue is that the use of the multiple paths to the back-end volumes is “hit
or miss.” It is usually much better than a construction that uses a small number of paths, but the use
of the multiple paths is not deterministic. Storage pools that are built using stripe sets spread the I/O
for a single virtual disk across the many paths and back-end volumes used to build these performance
pools. As a result, a front-end virtual disk that is created from a pool built with stripe sets will be
sequentially spread across all the members of the stripe set in 1-MB chunks.
Build a stripe set using the same guidelines as those for building a general purpose or capacity-based
storage pool. That is, the volumes should be of the same RAID type, with similar capacity and
performance characteristics. The size of a stripe set is based on the size of its smallest member times
the number of members. This means that unless all members are of exactly the same size there will
be capacity that is not accessible. The stripe sets should be constructed of at least as many volumes
as there are paths from a single DPM to the array. One or more stripe sets are used to create the
pool.
Stripe sets can both improve performance or degrade performance so it is important to understand
the following guidelines:
• Sequential I/O or transactional I/O—If the I/O stream is largely sequential, it may make more
sense to use a pool over a stripe set. If the I/O stream is largely transactional, a stripe set will
probably perform better.
• SVSP does not allow another back-end LU to be added to a stripe set.
• SVSP does allow the addition of a stripe set to a pool, but SVSP will not rebalance. A best practice
in this area is to add capacity to the HP EVA and present additional volumes to the SVSP, because
the HP EVA will rebalance.
Storage pool size considerations
When comparing small pools to large pools, the large pools have an advantage. Because there are
fewer, they are easier to manage, and since the pool free space in the same pool is used for snapshots,
asynchronous mirroring, and thin provisioning, there is a likelihood of stranded capacity. Small pools,
however, may allow the administrator to better partition the storage for various user groups, or to
have a pool per back-end array to ease troubleshooting.
Using thinly provisioned virtual disks
In general, a thin volume has similar performance characteristics to those of a regular volume; however,
when additional capacity is required by a thin volume, additional time is needed to complete the
Configuration best practices116