Today we’ll look at redundancy and bundling/clustering of storage as a start of a robust storage approach. Before I go any further, please note I am not a “storage admin” – I have a pretty broad exposure to the basic technologies and techniques, but the specifics of individual appliances, vendors, etc is beyond my purview 🙂
One of the oldest robustifiers is RAID – a Redundant Array of Inexpensive Disks. The basic theory is that you have a series of identical disks, and data is mirrored and/or striped across them to both accelerate writes and reads, and to provide a small level data safety: if one drive in a mirrored set dies, a replacement can be swapped-in, and no data will be lost (though performance will be degraded as the array is rebuilt).
Another robustifier is logical volume management. Under Linux, the tool is called LVM2. A logical volume manager collects varied partitions (whether from LUNs or DAS, standalone or RAID), and presents them as a unified partition (or “volume”) to the OS. One of the benefits of LVM is that as new storage is added, the volumes can be expanded transparently to the system – that also means that any applications that are running on the system can be “fixed” (if, for example, they are running low on space) without the need to stop the application, shut off the server, add storage, start the server, figure out where to mount the new storage, and then start the application again.
Robustifiers have as their main goal to make system more reliable, reduce downtime, and overall make a system more performant. As such, they are one part of an overall strategy to improve application/system responsiveness and reliability.
Next time we’ll look at how to figure out how to balance types of storage, specifically in the context of a couple applications with which I am familiar.