|
SUNWmd
(Required) SUNWmdg
(Optional GUI) SUNWmdn
(Optional SNMP log daemon) 106627-19
(obtain latest revision) The packages should be installed in the same order as listed above. Note that a reboot is necessary after the install as new drivers will be added to the Solaris kernel.
For DiskSuite 4.2.1, install the following packages:
SUNWmdu
(Commands) SUNWmdr
(Drivers) SUNWmdx
(64-Bit Drivers) SUNWmdg
(Optional GUI) SUNWmdnr
(Optional log daemon configs) SUNWmdnu
(Optional log daemon)
For Solaris 2.6 and 7, to make life easier, be sure to update your PATH
and MANPATH
variables to add DiskSuite's directories. Executables reside in /usr/opt/SUNWmd/sbin
and man pages in /usr/opt/SUNWmd/man
. In Solaris 8, DiskSuite files were moved to "normal" system locations (/usr/sbin
) so path updates are not necessary.
In this example we will be mirroring two disks, both on the same controller. The first disk will be the primary disk and the second will be the mirror. The disks are:
Disk 1: c0t0d0 Disk 2: c0t1d0
The partitions on the disks are presented below. There are a few items of note here. Each disk is partitioned exactly the same. This is necessary to properly implement the mirrors. Slice 2, commonly referred to as the 'backup' slice, which represents the entire disk must not be mirrored. There are situations where slice 2 is used as a normal slice, however, this author would not recommend doing so.
The three unassigned partitions on each disk are configured to each be 10MB. These 10MB slices will hold the DiskSuite State Database Replicas, or metadb
s. More information on the state database replicas will be presented below. In DiskSuite 4.2 and 4.2.1, a metadb
only occupies 1034 blocks (517KB) of space. In SVM, they occupy 8192 blocks (4MB). This can lead to many problems during an upgrade if the slices used for the metadb
replicas are not large enough to support the new larger databases.
Disk 1: c0t0d0s0: / c0t0d0s1: swap c0t0d0s2: backup c0t0d0s3: unassigned c0t0d0s4: /var c0t0d0s5: unassigned c0t0d0s6: unassigned c0t0d0s7: /export Disk 2: c0t1d0s0: / c0t1d0s1: swap c0t1d0s2: backup c0t1d0s3: unassigned c0t1d0s4: /var c0t1d0s5: unassigned c0t1d0s6: unassigned c0t1d0s7: /export
The database state replicas serve a very important function in DiskSuite. They are the repositories of information on the state and configuration of each metadevice (A logical device created through DiskSuite is known as a metadevice). Having multiple replicas is critical to the proper operation of DiskSuite.
Here we will create our state replicas using the metadb
command:
# metadb -a -f /dev/dsk/c0t0d0s3 # metadb -a /dev/dsk/c0t0d0s5 # metadb -a /dev/dsk/c0t0d0s6 # metadb -a /dev/dsk/c0t1d0s3 # metadb -a /dev/dsk/c0t1d0s5 # metadb -a /dev/dsk/c0t1d0s6
The -a
and -f
options used together create the initial replica. The -a
option attaches a new database device and automatically edits the appropriate files.
Each mirrored meta device contains two or more submirrors. The meta device gets mounted by the operating system rather than the original logical device. Below we will walk through the steps involved in creating metadevices for our primary filesystems.
Here we create the two submirrors for the /
(root
) filesystem, as well as a one way mirror between the meta device and its first submirror.
# metainit -f d10 1 1 c0t0d0s0 # metainit -f d20 1 1 c0t1d0s0 # metainit d0 -m d10
The first two commands create the two submirrors. The -f
option forces the creation of the submirror even though the specified slice is a mounted filesystem. The second two options 1 1
specify the number of stripes on the metadevice and the number of slices that make up the stripe. In a mirroring situation, this should always be 1 1
. Finally, we specify the logical device that we will be mirroring.
After mirroring the root partition, we need to run the metaroot
command. This command will update the root entry in /etc/vfstab
with the new metadevice as well as add the appropriate configuration information into /etc/system
. Ommitting this step is one of the most common mistakes made by those unfamiliar with DiskSuite. If you do not run the metaroot
command before you reboot, you will not be able to boot the system!
# metaroot d0
Next, we continue to create the submirrors and initial one way mirrors for the metadevices which will replace the swap, and /var
partitions.
# metainit -f d11 1 1 c0t0d0s1 # metainit -f d21 1 1 c0t1d0s1 # metainit d1 -m d11 # metainit -f d14 1 1 c0t0d0s4 # metainit -f d24 1 1 c0t1d0s4 # metainit d4 -m d14 # metainit -f d17 1 1 c0t0d0s7 # metainit -f d27 1 1 c0t1d0s7 # metainit d7 -m d17
/etc/vfstab
The /etc/vfstab
file must be updated at this point to reflect the changes made to the system. The / partition will have already been updated through the metaroot
command run earlier, but the system needs to know about the new devices for swap and /var
. The entries in the file will look something like the following:
/dev/md/dsk/d1 - - swap - no - /dev/md/dsk/d4 /dev/md/rdsk/d4 /var ufs 1 yes - /dev/md/dsk/d7 /dev/md/rdsk/d7 /export ufs 1 yes -
Notice that the device paths for the disks have changed from the normal style /dev/dsk/c#t#d#s#
and /dev/rdsk/c#t#d#s#
to the new metadevice paths, /dev/md/dsk/d#
and /dev/md/rdsk/d#
.
The system can now be rebooted. When it comes back up it will be running off of the new metadevices. Use the df
command to verify this. In the next step we will attach the second half of the mirrors and allow the two drives to synchronize.
Now we must attach the second half of the mirrors. Once the mirrors are attached it will begin an automatic synchonization process to ensure that both halves of the mirror are identical. The progress of the synchonization can be monitored using the metastat
command. To attach the submirrors, issue the following commands:
# metattach d0 d20 # metattach d1 d21 # metattach d4 d24 # metattach d7 d27
With an eye towards recovery in case of a future disaster it may be a good idea to find out the physical device path of the root partition on the second disk in order to create an Open Boot PROM (OBP) device alias to ease booting the system if the primary disk fails. In order to find the physical device path, simply do the following:
# ls -l /dev/dsk/c0t1d0s0
This should return something similar to the following:
/sbus@3,0/SUNW,fas@3,8800000/sd@1,0:a
Using this information, create a device alias using an easy to remember name such as altboot
. To create this alias, do the following in the Open Boot PROM:
ok nvalias altboot /sbus@3,0/SUNW,fas@3,8800000/sd@1,0:a
For more information on creating OBP device aliases, refer to the following document: TechNote: Modifying the CD-ROM nvalias on an Ultra 10 (IDE based) System".
It is now possible to boot off of the secondary device in case of failure using boot altboot
from the OBP.
For more information on DiskSuite, including configuring metatrans devices for filesystem transaction logging, see the second part of this document, Additional Solstice DiskSuite Topics.
DiskSuite provides the capability to do file system logging for UFS file systems. Logging enables a quicker and cleaner startup of disk partitions following a crash or irregular shutdown. Changes made to the filesystem are kept in a log which is then reapplied to the filesystem during a disk checking procedure. Using logging devices helps to ensure both data integrity as well as quicker startup times. DiskSuite logging devices are known as metatrans devices.
A metatrans device is identical to any other kind of meta device. In order to configure the device it is assumed that there is a free slice on each disk. Logging devices should be approximately 1MB in size for each 100MB of file system space that will be logged. Creating logging devices greater than 64MB, however, is usually a waste of disk space.
Using our previous example setup, lets assume that slice 3 of each disk is not being used for a metadb
. Again, creating the metatrans mirror is identical to creating any other kind of mirror.
# metainit d13 1 1 c0t0d0s3 # metainit d23 1 1 c0t1d0s3 # metainit d3 -m d13 # metattach d3 d23
Remember, it is necessary to reboot after creating the individual submirrors and before attaching them using metaattach
.
Next, we will actually configure our partitions to utilize the new logging devices. In this example we are going to add transaction logging to our /export
and /var
file systems.
# metainit -f d64 -t d4 d3 # metainit -f d67 -t d7 d3
Warning: According to the DiskSuite documentation, the root (/
) file system cannot utilize metatrans devices.
In addition, any 'system' file system, such as /usr
, /var
, etc. must have logging disabled before any kind of Solaris upgrade or installation.
Finally, we must udpate /etc/vfstab
to point to the new meta devices for /var
and /export
, as in the following example:
/dev/md/dsk/d64 /dev/md/rdsk/d64 /var ufs 1 yes - /dev/md/dsk/d67 /dev/md/rdsk/d67 /export ufs 1 yes -
After the vfstab
file is updated, it is necessary to reboot the system in order to begin using the new devices.
Creating a RAID 5 metadevice with DiskSuite is extremely simple. Unlike creating mirrors which involves several steps, creating a RAID 5 device consists of running a single command. If hot spare disks are desired, the hot spare pool must have been previously created. Refer to the following example of creating a hot spare pool and a RAID 5 device:
# metainit hsp001 c2t2d0s0 c3t2d0s0 c1t2d0s0 # metainit d30 -r c1t1d0s0 c2t0d0s0 c2t1d0s0 c2t3d0s0 c3t1d0s0 -i 64k -h hsp001
The -r
signifies that this will be a RAID 5 device. Next are the list of slices which will be part of the RAID 5 device. The -i
option specifies the interleave size to be used, in this case, we are using 64 Kbytes. Finally, -h
specifies the hot spare pool to be used with this metadevice.
Creating a striped metadevice:
# metainit d10 1 2 c0t1d0s2 c0t2d0s2 -i 32k
Creating a concatenation of 2 slices:
# metainit d25 2 1 c0t1d0s2 1 c0t2d0s2
Creating a concatenation of 4 slices:
# metainit d25 4 1 c0t1d0s2 1 c0t2d0s2 1 c0t3d0s2 1 c0t4d0s2
The definitive source of information on Solstice DiskSuite is Sun Microsystem's documentation. The following three volumes comprise the DiskSuite documentation set:
These documents, and much more, can be browsed online or downloaded as pdf
files at http://docs.sun.com.
Another excellent reference is Jeannie Kobert's Guide to High Availability: Configuring boot/root/swap, part of Sun's new Blueprints series of books. This book uses a cookbook approach to setting up high availability configurations using both DiskSuite and Veritas Volume Manager. While background information and theory is missing from this work, if you need to quickly get a server mirrored using DiskSuite or Volume Manager, this book will walk you through it, step by step.