Storage > Disk

Intelligent Storage

New RAID controllers offer highly advanced and virtualized storage solutions for the System i platform

RAID Optimization

The pervasive RAID implementations in the industry today include RAID 0, 1, 5, 6 and 10 (RAID 1 + RAID 0). RAID 0 and RAID 1 are provided on the System i platform as part of i5/OS storage management. RAID 1 on i5/OS isn't generally implemented as defined by the industry; rather, i5/OS uses mirroring functionality to provide a more robust level of disk protection. i5/OS mirroring allows for granularity that enables redundancy either at a device level, adapter level, I/O processor level, I/O drawer or tower level, or I/O bus level. i5/OS mirroring also provides a significant performance advantage over a traditional RAID 1 implementation by enabling applications to achieve parallelism by distributing the read operations across two controllers and their disks. Even in the mirroring environment, the System i RAID controller cache is leveraged to improve performance for both reads and writes. This is unique in the industry, as most RAID controllers require RAID arrays to be created to take advantage of the available RAID controller cache.

The intelligent RAID controllers on the System i platform enable various levels of RAID protection such as RAID 5 and RAID 6 with integrated management and automatic optimization of RAID arrays. They provide this capability without defeating the RAID 0 advantage created by i5/OS storage management.

Several RAID optimizations are inherent to the intelligent storage adapters; many are found only on the System i and IBM System p* platforms. Some critical performance-enhancing functions that differentiate the System i and System p adapters from competitive industry standard RAID adapters are:

XOR on the Fly -
RAID 5 and 6 protection is based on XORing data to create parity. To update parity when a disk is written with new data a number of XOR operations are required. The System i RAID controllers employ various hardware functions to generate and manage the RAID array parity. Most RAID controllers employ XOR engines that work on data in a memory buffer, thus requiring the memory buffer to already be populated with the two sets of data from which an XOR product is to be generated. This buffer is typically the write cache and when the data is destaged to the disk several read operations must occur to read what will be considered old data and old parity. In most RAID controllers this data is read into a buffer and then a hardware XOR engine or processor reads new data and moves old data out of the buffer, XORs it and stores the product into a third buffer. These operations reduce the memory bandwidth given the number of accesses and decrease the memory available for other functions such as write cache; both outcomes impact performance.

XOR on the Fly removes the need for separate buffers for old data and old parity given that the hardware direct-memory access (DMA) engine will synchronize reading data from the disk with reading data from the data buffer and then storing a product in the buffer to be used again in another XOR operation or sent directly to the disk to be written. This saves memory space and bandwidth, reducing response time for operations that require memory bandwidth such as cached writes.

RAID 5 and 6 without striping - In all other environments (e.g., Windows*, UNIX*, etc.) a RAID subsystem stripes data when implementing RAID 5 and 6. The System i RAID controllers understand that they're being used by i5/OS and don't stripe or re-stripe the data among the drives in the RAID array. This has a number of benefits:

1. No extra time is required to calculate the striping. This reduces synchronous overhead for all disk reads and writes, thus improving disk subsystem response times.
2. The actual disk that the i5/OS storage management requested the data to be saved on is maintained. This enables the RAID controller to stop RAID and place the data at the logical block address (LBA) on which the system requested it be stored. The RAID controller intermixes parity to avoid long seeks/accesses when data is written to disk. When RAID is stopped the parity information must be removed and data must be moved back to its specified LBA. This allows for seamless migration from a RAID 5 or 6 environment to an i5/OS mirrored environment when the user desires greater availability and/or possibility higher levels of subsystem performance.
3. The System i RAID controllers use this scheme to create an efficient and flexible RAID definition that provides the capability to add one drive at a time to an array, thus allowing incremental storage growth. Many RAID implementations require a minimum number of disks or the addition of a complete RAID array when adding disk to the RAID controller.

Next page: >>