- Introduction
- Hardware Configuration
- System Disk Partitioning
- Two-Disk Configuration
- Three-Disk Configuration
- Four-Disk Configuration
- Comparison of Solaris Volume Manager Software and VERITAS Volume Manager
- Runbook for Creating the Solaris Volume Manager Software State Database
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Runbook for Creating the Solaris Volume Manager Software State Database
In runbooks, the following disk names are assumed.
| primary mirror | c0t0d0 |
| secondary mirror | c0t1d0 |
| backup system disk | c0t2d0 |
| hot spare disk | c0t3d0 |
These names are placeholders for the real disk names. In most cases, the logical disk names will be different.
As a first step for each of the presented configurations, the Solaris Volume Manager software state database replicas must be created. Providing more than one replica protects the configuration against losing the definition of the volumes.
Solaris Volume Manager software has the following behavior with respect to loss of replicas:
The system panics when more than half of the replicas break.
The system does not boot unless more than half of the replicas are available. The system administrator must remove broken replicas in single-user mode to restore the majority.
Ideally, three replicas are created, each on a different disk, connected to a different host bus adapter. In this runbook, we assume that only the system disks are under control of Solaris Volume Manager software, and this ideal replica configuration is not always possible.
Be aware that the optimal replica configuration may be different from the one presented here, in the case that the data disks are also under control of Solaris Volume Manager software and can contain state database replicas.
Replica creation for the two-disk configuration (and disabling the quorum rule).
metadb -a -f -c 2 c0t0d0s7 metadb -a -c 2 c0t1d0s7 echo set md:mirrored_root_flag=1 >> /etc/system
Replica creation for the three-disk and four-disk configuration. (Do not create unnecessary multiple copies per disk.)
metadb -a -f c0t0d0s7 metadb -a c0t1d0s7 metadb -a c0t2d0s7
Runbook for the Two-Disk Configuration
Copy the VTOC to the mirror disk. It is not necessary to make this disk bootable because the bootblock from the first submirror is copied to the second submirror during the resync operation. Use the prtvtoc command as follows.
prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2
Create the state database replicas as described in the previous runbook.
Create the volumes, as follows.
metainit -f d10 1 1 c0t0d0s0 metainit -f d11 1 1 c0t0d0s1 metainit -f d13 1 1 c0t0d0s3 metainit d20 1 1 c0t1d0s0 metainit d21 1 1 c0t1d0s1 metainit d23 1 1 c0t1d0s3 metainit d0 -m d10 metainit d1 -m d11 metainit d3 -m d13
Make the system boot from the mirror, as follows.
metaroot d0
Replace the remaining partitions with volumes in /etc/vfstab, as follows.
cp /etc/vfstab /etc/vfstab.tmp cat /etc/vfstab.tmp | \ sed s,/dev/dsk/c0t0d0s1,/dev/md/dsk/d1, | \ sed s,/dev/dsk/c0t0d0s3,/dev/md/dsk/d3, | \ sed s,/dev/rdsk/c0t0d0s3,/dev/md/rdsk/d3, > /etc/vfstab
Document the physical device name of the two disks in the mirror, as shown in the underlined portion of the following example for the disk c0t1d0.
ls -l /dev/rdsk/c0t1d0s0 lrwxrwxrwx 1 root other 68 Nov 30 15:43 /dev/rdsk/c0t1d0s0 -> ../../devices/ssm@0,0/pci@18,700000/pci@2/SUNW,isptwo@4/sd@1,0:a,raw
Halt the system, as follows.
init 0
Create an OBP alias for the bootable disks. Beware that for disks on certain controllers, the sd driver name must be replaced by disk. Verify this, using the OBP show-disks command before entering the nvalias commands.
ok nvalias bootdisk /ssm@0,0/pci@18,700000/pci@2/SUNW,isptwo@4/sd@0,0:a ok nvalias mirrdisk /ssm@0,0/pci@18,700000/pci@2/SUNW,isptwo@4/sd@1,0:a ok setenv boot-device bootdisk mirrdisk ok boot
Attach the submirrors, as follows.
metattach d0 d20 metattach d1 d21 metattach d3 d23
Runbook for the Three-Disk Configuration
Copy the VTOC and the boot block to the contingency disk, as shown here.
prtvtoc /dev/rdsk/c0t0d0s2| fmthard -s - /dev/rdsk/c0t2d0s2 /usr/sbin/installboot /usr/platform/´uname -i´/lib/fs/ufs/bootblk /dev/rdsk/c0t2d0s2
Create the state databases and volumes as described in the runbook for the two-disk configuration.
Perform a full backup of the file systems to the backup system disk and modify system files so that the disk becomes bootable from partitions.
newfs /dev/rdsk/c0t2d0s0 mount /dev/dsk/c0t2d0s0 /mnt ufsdump 0f - / | (cd /mnt; ufsrestore rf - ) cat /etc/vfstab | \ sed s,/dev/md/dsk/d0,/dev/dsk/c0t2d0s0, | \ sed s,/dev/md/dsk/d1,/dev/dsk/c0t2d0s1, | \ sed s,/dev/md/dsk/d3,/dev/dsk/c0t2d0s3, | \ sed s,/dev/md/rdsk/d0,/dev/rdsk/c0t2d0s0, | \ sed s,/dev/md/rdsk/d1,/dev/rdsk/c0t2d0s1, | \ sed s,/dev/md/rdsk/d3,/dev/rdsk/c0t2d0s3, > /mnt/etc/vfstab cat /etc/system | grep -v rootdev > /mnt/etc/system umount /mnt newfs /dev/rdsk/c0t2d0s3 mount /dev/dsk/c0t2d0s3 /mnt ufsdump 0f - /var | (cd /mnt; ufsrestore rf - ) umount /mnt
Put the preceding commands in a script /usr/local/system-backup, make the script executable, and execute from cron, as shown here. Note that this is the most rudimentary implementation. You may want to refine this by using a combination of full and incremental ufsdump and more sophisticated update schemes.
10 1 * * 0 /usr/local/system-backup
Create an OBP alias for the contingency disk, as described earlier.
Runbook for the Four-Disk Configuration
Copy the VTOC and boot block to the fourth disk. This disk must also be made bootable for the unlikely situation that the hot spare actually kicks in and later becomes the only surviving disk in the mirror.
prtvtoc /dev/rdsk/c0t0d0s2| fmthard -s - /dev/rdsk/c0t3d0s2 /usr/sbin/installboot /usr/platform/´uname -i´/lib/fs/ufs/bootblk /dev/rdsk/c0t3d0s2
Create the state database replicas and volumes, configure the contingency disk as described in the previous runbook.
Configure the hot spare pools. Each mirror gets its own hot spare pool with a partition of the corresponding size, as follows. Putting all spare partitions in the same pool is simpler, but correct behavior then depends on the order of the partitions in the pool.
metahs -a hsp000 c0t3d0s0 metaparam -h hsp000 d10 metaparam -h hsp000 d20 metahs -a hsp001 c0t3d0s1 metaparam -h hsp001 d11 metaparam -h hsp001 d21 metahs -a hsp003 c0t3d0s3 metaparam -h hsp003 d13 metaparam -h hsp003 d23
Use of the SUNBEsdm Package
With this article, we provide the SUNBEsdm package. The package contains a script sdmsetup that greatly reduces the manual work to implement the runbooks mentioned in this article. The SUNBEsdm package is not supported by Sun, and is only provided, here, to demonstrate our example.
Take care to minimize the risk of running the script sdmsetup. This script does not modify your system, but rather generates the commands to be executed, allowing for inspection prior to execution.
The prerequisites for sdmsetup are as follows:
Solstice DiskSuite 4.2.1 software must be installed.
No state database or volume must already exist.
A free slice must exist to be used as state database.
A free slice must exist to be used as dump device (optional).
All currently mounted file systems must correspond to entries in /etc/vfstab.
All used disks must be of the same geometry.
Slice 2 on all disks must cover the entire disk.
A README file in the package contains detailed instructions for the usage of the script.
Ordering Sun Documents
The SunDocsSM program provides more than 250 manuals from Sun Microsystems, Inc. If you live in the United States, Canada, Europe, or Japan, you can purchase documentation sets or individual manuals through this program.
Accessing Sun Documentation Online
The docs.sun.com web site enables you to access Sun technical documentation online. You can browse the docs.sun.com archive or search for a specific book title or subject. The URL is http://docs.sun.com/
To reference Sun BluePrints OnLine articles, visit the Sun BluePrints OnLine Web site at: http://www.sun.com/blueprints/online.html