Jerry Jelinek's Weblog: Jerry Jelinek's Weblog

Solaris Volume Manager has had support for a feature called "disksets" for a long time, going back to when it was an unbundled product named SDS. Disksets are a way to group a collection of disks together for use by SVM. Originally this was designed for sharing disks, and the metadevices on top of them, between two or more hosts. For example, disksets are used by SunCluster. However, having a way to manage a set of disks for exclusive use by SVM simplifies administration and with S10 we have made several enhancements to the diskset feature which make it more useful, even on a single host.

If you have never used SVM disksets before, I'll briefly summarize a couple of the key differences from the more common use of SVM metadevices outside of a diskset. First, with a diskset, the whole disk is given over to SVM control. When you do this SVM will repartition the disk and create a slice 7 for metadb placement. SVM automatically manages metadbs in disksets so you don't have to worry about creating those. As disks are added to the set, SVM will create new metadbs and automatically rebalance them across the disks as needed. Another difference with disksets is that hosts can also be assigned to the set. The local host must be in the set when you create it. Disksets implement the concept of a set owner so you can release ownership of the set and a different host can take ownership. Only the host that owns the set can access the metadevices within the set. An exception to this is the new multi-owner diskset which is a large topic on its own so I'll save that for another post.

With S10 SVM has added several new features based around the diskset. One of these is the metaimport(1M) command which can be used to load a complete diskset configuration onto a separate system. You might use this if your host died and you physically moved all of your storage to a different machine. SVM uses the disk device IDs to figure out how to put the configuration together on the new machine. This is required since the disk names themselves (e.g. c2t1d0,c3t5d0,...) will probably be different on the new system. In S10 disk images in a diskset are self-identifying. What this means is that if you use remote block replication software like HDS TrueCopy or the SNDR feature of Sun's StorEdge Availability Suite to do remote replication you can still use metaimport(1M) to import the remotely replicated disks, even though the device IDs of the remote disks will different.

A second new feature is the metassist(1M) command. This command automates the creation of metadevices so that you don't have to run all of the separate meta* commands individually. Metassist has quite a lot of features which I won't delve into in this post, but you can read more here. The one idea I wanted to discuss is that metassist uses disksets to implement the concept of a storage pool. Metassist relies on the automatic management of metadbs that disksets provide. Also, since the whole disk is now under control of SVM, metassist can repartition the disk as necessary to automatically create the appropriate metadevices within the pool. Metassist will use the disks in the pool to create new metadevices and only try to add additional disks to the pool if it can't configure the new metadevice using the available space on the existing disks in the pool.

When disksets were first implemented back in SDS they were intended for use by multiple hosts. Since the metadevices in the set were only accessible by the host the owned the set the assumption was that some other piece of software, outside of SDS, would manage the diskset ownership. Since SVM is now making greater use of disksets we added a new capability called "auto-take" which allows the local host to automatically take ownership of the diskset during boot and thus have access to the metadevices in the set. This means that you can use vfstab entries to mount filesystems built on metadevices within the set and those will "just work" during the system boot. The metassist command relies on this feature and the storage pools (i.e. disksets) it uses will all have auto-take enabled. Auto-take can only be enabled for disksets which have the single, local host in the set. If you have multiple hosts in the set than you are really using the set in the traditional manner and you'll need something outside of SVM to manage which host owns the set (again, this ignores the new multi-owner sets). You use the new "-A" option on the metaset command to enable or disable auto-take.

Finally, since use of disksets is expected to be more common with these new features, we added the "-a" option to the metastat command so that you can see the status of metadevices in all disksets without have to run a separate command for each set. We also added a "-c" option to metastat which gives a compact, one-line output for each metadevice. This is particularly useful as the number of metadevices in the configuration increases. For example, on one of our local servers we have 93 metadevices. With the original, verbose metastat output this resulted in 842 lines of status, which makes it hard to see exactly what is going on. The "-c" option reduces this down to 93 lines.

This is just a brief overview of some of the new features we have implemented around SVM disksets. There is lots more detail in the docs here. The metaimport(1M) command was available starting in S9 9/04 and the metassist command was available starting in S9 6/04. However, the remote replication feature for metaimport requires S10.