| Earlier we discussed how RAID 5 uses parity data to sustain the loss of a single disk. We also mentioned the read-modify-write bottleneck that RAID 5 presents to the IO system. So why do people choose to use RAID 5 when we have solutions such as RAID 1/0? A big problem with RAID 1/0 (or any mirroring solution) is the drop in overall usable capacity. The maximum usable space in a mirror configuration will be 50 percent for a two-way mirror. Any additional mirror copies will cause a proportional drop in usable space all the way down to a 32-way mirror providing 3.125 percent of usable space. Consequently, RAID 5 is becoming increasingly popular because it proportionally increases the usable space with every disk you add to a stripe set. However, this is at the cost of performance, with the ready-modify-write bottleneck offsetting gains in storage against a loss in performance. Due to its inherent depleted performance characteristics, it is advisable to use RAID 5 for data that is not going to change very much. Archive data is a classic example. We could create volumes utilizing RAID 1/0 for our highly volatile data and separate RAID 5 volumes to store older, less volatile data for long- term storage. We gain the capacity benefits of RAID 5 while still providing redundancy in our volume configuration, and the performance penalty doesn't come into play because the data is relatively static . Because RAID 5 uses parity data, we need at least two data blocks in order to calculate parity. This means that, in theory, a RAID 5 volume needs at least three disks in order to create the volume. In practice, VxVM will also attach a log plex to a RAID 5 volume. This is good practice because we are now logging changes to data and parity before it is written to disk. If we didn't perform RAID 5 logging and we had a double failure of a RAID 5 disk and the system crashed, there would be no way of knowing whether data and/or parity were actually written to disk. This would mean the data and/or the parity would be corrupt. In the event of just a disk failure, the recovery of the lost data from the parity would be in jeopardy because the parity is in itself corrupt. We can specify the nolog or noRAID 5log option when we create a RAID 5 volume. Because we are not expecting lots of volatile activity in a RAID 5 volume, I don't mind the extra IO to the RAID 5 log. VxVM will size the RAID 5 log according to the size of the volume. Again, it is a good idea to use ordered allocation in order to tightly control where the data and the log plex will reside (see the logdisk option). Here, I am creating a 4GB RAID 5 volume with three columns (the minimum) and storing my log plex on disk ora_disk1 (= c0t4d0 ):
root@hpeos003[] vxassist -g ora1 -o ordered make archive 4G layout=RAID 5 ncol=3  logdisk=ora_disk1 ora_disk3 ora_disk2 ora_disk4 root@hpeos003[] vxprint -g ora1 -ht archive V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE DC NAME PARENTVOL LOGVOL SP NAME SNAPVOL DCO v archive - ENABLED ACTIVE 4194304 RAID - RAID 5 pl archive-01 archive ENABLED ACTIVE 4194304 RAID 3/16 RW sd ora_disk3-06 archive-01 ora_disk3 13034848 2097152 0/0 c4t12d0 ENA sd ora_disk2-02 archive-01 ora_disk2 7791968 2097152 1/0 c0t5d0 ENA sd ora_disk4-04 archive-01 ora_disk4 9539584 2097152 2/0 c4t13d0 ENA pl archive-02 archive ENABLED LOG 1440 CONCAT - RW sd ora_disk1-04 archive-02 ora_disk1 3495330 1440 0 c0t4d0 ENA root@hpeos003[]
Now that we have built various types of redundancy into our volumes, we should see what happens when we experience a disaster. |
