Basic Root Disk Mirroring With Solaris Volume Manager

Hello again!

Solaris Volume Manager (SVM - Used to be called Solaris Disk Suite - SDS - pretty much only the name changed) is an excellent OS standard software RAID management tool used by a lot of IT shops. Even shops that use Veritas Volume Manager software for serious storage management, still use SVM to take care of the base disks.

The reason most shops utilize SVM to manage the root disks is that it's easier to manage than Veritas for this limited purpose. Another reason is that, in coordination with its ease of use, it's integrated into Solaris. The thinking around this is generally: Why not use Solaris' tool to manage our Solaris OS root disk(s)? If you've ever had to deal with Sun support, you know another reason why using their product on their product is a good thing :)

Setting up RAID groups, and managing them, is generally very simple and doesn't require rebooting the machine, etc, when you want to add new disk (with some exceptions). One of the exceptions to this rule is when you use SVM to set up management of your root disks.

Managing your root disks with SVM is a two-part process. Generally, it's used for mirorring the root disk for quick failover and is configured right after installation. Configuring it after is also easy, but I like to get my necessary reboots completed before I hand over product to a customer.

The process is fairly simple and is accomplished like this:

1. The two disks that will be used for mirroring have to be formatted "exactly" alike. The easiest way to do this is to partition one root disk and then either use the output from "prtvtoc" to seed "fmthard" or, more simply, use Solaris' "format" command to format the initial disk and then "select" the same layout from the list of available partition setups when formatting the second disk (labeling the first makes its partition table a selectable option!)

2. Meta Databases need to be created on both disks. The first needs to be forced, and any additional do not. We're using slice 7 for our example here:

metadb -a -f /dev/dsk/c0t0d0s7
metadb -a /dev/dsk/c0t1d0s7

3. Next, the metadevices need to be setup. For each slice that we want to mirror, we need to create two stripe-concat metadevices, as such (shown for only two, here, but done for every slice we want to mirror - which should be every slice on the disk except slice 2!):

metainit -f d10 1 1 c0t0d0s0
metainit -f d20 1 1 c0t1d0s0

metainit -f d11 1 1 c0t0d0s1
metainit -f d21 1 1 c0t1d0s1

4. Next, the metadevice that will be composed of the two mirrors needs to be created. You can do this by attaching one of the mirrors to the new metadevice. Note that, you can do this all at once, normally, but for the root disk, you can only attach one mirror slice at this point for each slice, as such:

metainit d0 -m d10
metainit d1 -m d11

5. The root partition is special in that SVM actually has a command to change its value to the metadevice value (d0) in /etc/vfstab. It also adds some information in /etc/system for you. That command is:

metaroot d0

6. Now, sadly enough you'll need to edit your /etc/vfstab to reflect the new metadevices. So for the entry for metadevice d1, you'd change:

/dev/dsk/c0t0d0s1 to /dev/md/dsk/d1
/dev/rdsk/c0t0d0s1 to /dev/md/rdsk/d1

7. Once that's completed and all commands have returned successfully (you can check that all's well by running "metastat -p") you will need to reboot. I would suggest actually shutting your machine down to init level 0 so that you can change your alternate boot device to the secondary (mirror) disk from the default of "net." This way, once you're set up, if your primary disk fails your system will automatically boot off of the mirror.

8. Now to the final step. You need to attach that second mirror slice to your mirror metadevice, as such:

metattach d0 d20
metattach d1 d21

Again, as long as you receive no errors, you should be all set. It will take SVM a little while to sync up the two disk (the actual mirroring process from the first disk to the second). You can check on the status by running "metastat" on its own. I personally prefer to run a command line loop to keep me up to date, like:

while true;do metastat -t|grep -i sync;sleep 60;done

then, when all the sync's are complete, I'll know right away. It's always nice to know when you can stop worrying :)

, Mike

linux unix internet technology