Ask the Expert

Using RAID 1 and RAID 5 in a virtual server environment

In a virtual server environment should we put OS and applications on RAID 1 or RAID 5?

    Requires Free Membership to View

On the 3PAR storage-area network (SAN) we use at my firm, RAID 1 and RAID 5 are effectively the same from a performance point of view, especially on read operations. On write operations, there's some additional I/O to the physical disks as the SAN responds back about write requests before actually writing the data to disk.

On 3PAR SANs, most operations don't actually hit the disk, but instead hit the cache, so RAID 1 and RAID 5 are largely interchangeable. The exception tends to be when you have a very large write operation that fills up the cache. At that point, RAID 1 would give a performance benefit as it requires half the number of writes RAID 5 does. But we have few servers which have that level of writes and have universally found RAID 5 to be more efficient.

Given the above, we store our virtual machines (OS and applications) on the SAN in RAID 5 as it uses less space and this performs well for us.

However, our hypervisors are stored on server local storage, avoiding the SAN entirely. One of the major benefits to this is that if the connection to the SAN dies, the system continues to run. This is particularly important with VMware, where if the SAN connection goes down, the virtual machines continue to run in read-only mode.

On SANs that aren't wide-striped, or that lack hardware RAID 5 calculations, there may be related performance impacts, however. RAID 5 is less secure from a data protection standpoint, and if you lose the parity drive and another drive you lose the data. However, the 3PAR system recovers very quickly from a drive failure by automatically redistributing the data. In effect, all of the spare space on the SAN is used as a hot spare. So to lose a logical unit number (LUN), you would have to lose two drives in rapid succession.

BIO: Lukas Oberhuber is chief technology officer at Forward Internet Group.

This was first published in March 2010

 

COMMENTS powered by Disqus  //  Commenting policy