7914DS3KPlanning_090710.fm
Draft Document for Review March 28, 2011 12:24 pm
58
IBM System Storage DS3500: Introduction and Implementation Guide
The array configuration is crucial to performance. You must take into account all the logical
drives inside the array, because all logical drives inside the array will impact the same
physical disks. If you have two logical drives inside an array and they both are high
throughput, then there can be contention for access to the physical drives as large read or
write requests are serviced. It is crucial to know the type of data that each logical drive is used
for and try to balance the load so contention for the physical drives is minimized. Contention is
impossible to eliminate unless the array only contains one logical drive.
Number of drives
In the transaction intense environment, it is more important to ensure that there are enough
disk drives configured to perform the I/Os demanded by the host application, than to focus on
the amount of possible storage space on the storage subsystem.
Use Table 3-2 on page 49 to determine what drive type, speed and capacity is best suited for
your workload and environment needs.
Transaction intensive workload
In a transaction intense environment, you want to have higher drive numbers involved.
This can be done by creating larger arrays with more disks. The storage subsystems can
have a maximum of 30 drives per RAID 5 array/logical drive and 96 drives for a full subsystem
RAID 10 array.
With a RAID 10 array, the logical drive size can be configured to encompass the entire array,
although operating system limitations on maximum logical drive size might restrict the
usefulness of this capability. Though there are circumstances where this model can work well,
it is best that smaller arrays be used to better balance the drive usage and access patterns
across the controllers and to avoid contention and intermixed IO patterns.
Configuring multiple LUNs striped across a single large array can be used to make use of all
the capacity. However, with this layout, consideration should be given to the workload types
for which these LUNs will be used, so as not to mix throughput and transaction based IO on
the same array.
Another factor to consider is congestion when accessing the drives on the back-end loops.
This situation can be avoided by using multiple arrays.
Generally, an array of 8 to 16 disks provides the best performance for RAID 5 workloads that
are OLTP based.
For large size databases, consider using the host volume management software to spread
the workload evenly across multiple arrays/LUNs to evenly balance the workload on all. Build
the volume across sets of logical drives laid out per the RAID type in the previous discussion.
In using multiple arrays, you will also be able to increase the controllers which are involved in
handling the load, therefore getting full use of the storage subsystems resources.
For example: If needing to build a database that is 1 TB in size, you can use five 300 GB
drives in a 4+1 parity RAID 5 single array/logical drive; or you can create two RAID 5 arrays of
8+1 parity using 73 GB drives, giving two 584 GB logical drives on which to build the 1 TB
database. In most cases the second method for large databases will work best, as it brings
twelve more disks into play for handling the high host application transaction workload.
Best practice: For high transaction environments requiring highest redundancy and
protection, logical drives should be built on arrays with 8 to 12 disks when using RAID 5. or
RAID 10. Spreading the arrays evenly across the two controllers in a dual controller
environment will give you the best balance of the workload.
Summary of Contents for DS3500
Page 2: ......
Page 5: ...iii Draft Document for Review March 28 2011 12 24 pm 7914edno fm ...
Page 789: ......
