6.3 Software Versus Hardware

RAID arrays are commonly implemented by host software or by a dedicated hardware array controller. Of course, the hardware RAID vendors will tell you that their hardware controllers are better, and software companies will tell you that their software products are better; although they accomplish the same function, they do have some substantial differences.

6.3.1 Software

In software-based array management, the underlying physical disks are visible to the administrator, and the RAID functions are implemented via a virtual device driver. The bonus is flexibility: the RAID functionality can use any available drive, regardless of packaging or location. Arbitrary location of disks can be useful if you are trying to build an array that is resistant to systematic faults (e.g., fire or flood). One of the common criticisms of such a design is that it is slower than controller-based RAID, especially for the parity computations involved in RAID 5. While it is true that software-based arrays tend to be slower than hardware-based arrays, it is not a function of parity computational performance; a typical array controller is equivalent to a 66 MHz Intel 486 processor, which can perform eight parity computations in about fifteen cycles. A modern high-performance workstation microprocessor can complete two parity computations in every clock cycle, and has a clock rate eight times higher! In addition, the load imposed on the system for the parity computation is trivial.

6.3.2 Hardware

In a hardware-based array, the array management is handled by a dedicated processor. This has a substantial effect in reducing host overhead, because a software array implementation has to manage two sets of I/O operations: the logical operation and the operations on the member disks. The member disk operations can be quite substantial, since each SCSI I/O requires a nontrivial amount of processor time. However, the most significant reason for using controller-based RAID implementations is that they have an architectural advantage for using nonvolatile memory to cache the RAID 5 write log. The controller can commit the logical write into memory and acknowledge it to the host before it is committed to disk, providing a huge latency advantage. They also perform internal optimizations that get around the slow parts of RAID 5, such as coalescing read-write-modify operations into full-stripe operations. This provides a substantial improvement in cases where the system is dominated by sequential RAID 5 writes .

The benefit of NVRAM caches in controller-based arrays is to accelerate writes. Don't bother attempting to accelerate reads by putting lots of NVRAM in a controller-based array.

If you are not using RAID 5, the benefit of controller-based NVRAM caching is to enable fast writes; the controller can write data into NVRAM, acknowledge the write, and complete the write at its leisure. For such an application, 16 MB of cache should be plenty. For RAID 5, you may need 64-128 MB in order to completely cache stripes effectively.

6.3.2.1 RAID overlap

While controller-based RAID implementations are superior for RAID 5 writes, they are less valuable for other RAID levels, especially since the host processor overhead for running RAID 0 or RAID 1 is very small. It is possible to combine host and controller-based arrays, to great effect. For example, taking a set of hardware RAID 5 arrays and striping them together with a software RAID 0 implementation gives good data reliability (from the RAID 5 level) and excellent read performance (from the RAID 0 overlap).