Solstice Disk Suite 完全使用手册

Installing DiskSuite

 

The DiskSuite packages have moved around a bit with each release of Solaris. For Solaris 2.6 and Solaris 7, the DiskSuite packages are located on the Easy Access CD. With Solaris 8, DiskSuite moved to the "Solaris 8 Software" cdrom number two, in the EA directory. Starting the Solaris 9, DiskSuite is now included with the operating system.

 

At the time of this writing, Solaris 8 is the most commonly deployed version of Solaris, so we'll use that as the basis for this example. The steps are basically identical for the other releases.

 

1.After having completed the installation of the Solaris 8 operating system, insert the Solaris 8 software cdrom number two into the cdrom drive. If volume management is enabled, it will automatically mount to /cdrom/sol_8_401_sparc_2 (depending on the precise release iteration of Solaris 8, the exact path may differ in your case):

 

 

CODE:[Copy to clipboard]# df -k

Filesystem            kbytes    used   avail capacity  Mounted on

/dev/dsk/c0t0d0s0    6607349  826881 5714395    13%    /

/proc                      0       0       0     0%    /proc

fd                         0       0       0     0%    /dev/fd

mnttab                     0       0       0     0%    /etc/mnttab

/dev/dsk/c0t0d0s4    1016863    8106  947746     1%    /var

swap                 1443064       8 1443056     1%    /var/run

swap                 1443080      24 1443056     1%    /tmp

/vol/dev/dsk/c0t6d0/sol_8_401_sparc_2

                      239718  239718       0   100%    /cdrom/sol_8_401_sparc_2

2.Change to the directory containing the DiskSuite packages:

 

 

CODE:[Copy to clipboard]# cd /cdrom/sol_8_401_sparc_2/Solaris_8/EA/products/Disksuite_4.2.1/sparc/Packages

3.Add the required packages (we're taking everything except the Japanese-specific package):

 

 

CODE:[Copy to clipboard]# pkgadd -d .

 

The following packages are available:

  1  SUNWmdg      Solstice DiskSuite Tool

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  2  SUNWmdja     Solstice DiskSuite Japanese localization

                  (sparc) 4.2.1,REV=1999.12.09.15.37

  3  SUNWmdnr     Solstice DiskSuite Log Daemon Configuration Files

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  4  SUNWmdnu     Solstice DiskSuite Log Daemon

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  5  SUNWmdr      Solstice DiskSuite Drivers

                  (sparc) 4.2.1,REV=1999.12.03.10.00

  6  SUNWmdu      Solstice DiskSuite Commands

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  7  SUNWmdx      Solstice DiskSuite Drivers(64-bit)

                  (sparc) 4.2.1,REV=1999.11.04.18.29

 

Select package(s) you wish to process (or 'all' to process

all packages). (default: all) [?,??,q]: 1 3 4 5 6 7

 

Processing package instance ; from ;

.

.

.

postinstall: configure driver

 

                (This may take a while.)

 

Installation of ; was successful.

 

The following packages are available:

  1  SUNWmdg      Solstice DiskSuite Tool

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  2  SUNWmdja     Solstice DiskSuite Japanese localization

                  (sparc) 4.2.1,REV=1999.12.09.15.37

  3  SUNWmdnr     Solstice DiskSuite Log Daemon Configuration Files

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  4  SUNWmdnu     Solstice DiskSuite Log Daemon

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  5  SUNWmdr      Solstice DiskSuite Drivers

                  (sparc) 4.2.1,REV=1999.12.03.10.00

  6  SUNWmdu      Solstice DiskSuite Commands

                  (sparc) 4.2.1,REV=1999.11.04.18.29

  7  SUNWmdx      Solstice DiskSuite Drivers(64-bit)

                  (sparc) 4.2.1,REV=1999.11.04.18.29

 

Select package(s) you wish to process (or 'all' to process

all packages). (default: all) [?,??,q]: q

 

*** IMPORTANT NOTICE ***

        This machine must now be rebooted in order to ensure

        sane operation.  Execute

               shutdown -y -i6 -g0

        and wait for the "Console Login:" prompt.

# eject cdrom

# shutdown -y -i6 -g0

4.Once the system reboots, apply any DiskSuite patches. At the time of this writing, the latest recommended DiskSuite patch available from sunsolve.sun.com is 106627-18 (DiskSuite 4.2) or 108693-13 (DiskSuite 4.2.1). Note that the patch installation instructions require that a reboot be performed after the patch is installed.

 

 

Mirroring the operating system

 

In the steps below, I'm using DiskSuite to mirror the active root disk (c0t0d0) to a mirror (c0t1d0). I'm assuming that partitions five and six of each disk have a couple of cylinders free for DiskSuite's state database replicas.

 

Introduction

 

First, we start with a filesystem layout that looks as follows:

 

 

CODE:[Copy to clipboard]Filesystem            kbytes    used   avail capacity  Mounted on

/dev/dsk/c0t0d0s0    6607349  826881 5714395    13%    /

/proc                      0       0       0     0%    /proc

fd                         0       0       0     0%    /dev/fd

mnttab                     0       0       0     0%    /etc/mnttab

/dev/dsk/c0t0d0s4    1016863    8106  947746     1%    /var

swap                 1443064       8 1443056     1%    /var/run

swap                 1443080      24 1443056     1%    /tmp

We're going to be mirroring from c0t0d0 to c0t1d0. When the operating system was installed, we created unassigned slices five, six, and seven of roughly 10 MB each. We will use slices five and six for the DiskSuite state database replicas. The output from the "format" command is as follows:

 

 

CODE:[Copy to clipboard]# format

Searching for disks...done

 

 

AVAILABLE DISK SELECTIONS:

       0. c0t0d0 ;

          /pci@1f,4000/scsi@3/sd@0,0

       1. c0t1d0 ;

          /pci@1f,4000/scsi@3/sd@1,0

Specify disk (enter its number): 0

 

selecting c0t0d0

[disk formatted]

...

partition>; p

Current partition table (original):

Total disk cylinders available: 5266 + 2 (reserved cylinders)

 

Part      Tag    Flag     Cylinders        Size            Blocks

  0       root    wm       0 - 3994        6.40GB    (3995/0/0) 13423200

  1       swap    wu    3995 - 4619        1.00GB    (625/0/0)   2100000

  2     backup    wm       0 - 5265        8.44GB    (5266/0/0) 17693760

  3 unassigned    wu       0               0         (0/0/0)           0

  4        var    wm    4620 - 5244        1.00GB    (625/0/0)   2100000

  5 unassigned    wm    5245 - 5251       11.48MB    (7/0/0)       23520

  6 unassigned    wm    5252 - 5258       11.48MB    (7/0/0)       23520

  7 unassigned    wm    5259 - 5265       11.48MB    (7/0/0)  23520

DiskSuite Mirroring

 

Note that much of the process of mirroring the root disk has been automated with the sdsinstall script. With the exception of the creation of device aliases, all of the work done in the following steps can be achieved via the following:

 

 

CODE:[Copy to clipboard]# ./sdsinstall -p c0t0d0 -s c0t1d0 -m s5 -m s6

1.Ensure that the partition tables of both disks are identical:

 

 

CODE:[Copy to clipboard]# prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2

2.Add the state database replicas. For redundancy, each disk has two state database replicas.

 

 

CODE:[Copy to clipboard]# metadb -a -f c0t0d0s5

# metadb -a c0t0d0s6

# metadb -a c0t1d0s5

# metadb -a c0t1d0s6

Note that there appears to be a lot of confusion regarding the recommended number and location of state database replicas. According the the DiskSuite reference manual:

 

State database replicas contain configuration and status information of all metadevices and hot spares. Multiple copies (replicas) are maintained to provide redundancy. Multiple copies also prevent the database from being corrupted during a system crash (at most, only one copy if the database will be corrupted).

 

State database replicas are also used for mirror resync regions. Too few state database replicas relative to the number of mirrors may cause replica I/O to impact mirror performance.

 

At least three replicas are recommended. DiskSuite allows a maximum of 50 replicas. The following guidelines are recommended:

 

For a system with only a single drive: put all 3 replicas in one slice.

 

For a system with two to four drives: put two replicas on each drive.

 

For a system with five or more drives: put one replica on each drive.

 

In general, it is best to distribute state database replicas across slices, drives, and controllers, to avoid single points-of-failure.

 

Each state database replica occupies 517 KB (1034 disk sectors) of disk storage by default. Replicas can be stored on: a dedicated disk partition, a partition which will be part of a metadevice, or a partition which will be part of a logging - device.

 

Note - Replicas cannot be stored on the root (/), swap, or /usr slices, or on slices containing existing file systems or data.

 

Starting with DiskSuite 4.2.1, an optional /etc/system parameter exists which allows DiskSuite to boot with just 50% of the state database replicas online. For example, if one of the two boot disks were to fail, just two of the four state database replicas would be available. Without this /etc/system parameter (or with older versions of DiskSuite), the system would complain of "insufficient state database replicas", and manual intervention would be required on bootup. To enable the "50% boot" behaviour with DiskSuite 4.2.1, execute the following command:

 

 

CODE:[Copy to clipboard]# echo "set md:mirrored_root_flag=1" >;>; /etc/system

3.Define the metadevices on c0t0d0 (/):

 

 

CODE:[Copy to clipboard]# metainit -f d10 1 1 c0t0d0s0

# metainit -f d20 1 1 c0t1d0s0

# metainit d0 -m d10

The metaroot command edits the /etc/vfstab and /etc/system files:

 

 

CODE:[Copy to clipboard]# metaroot d0

Define the metadevices for c0t0d0s1 (swap):

 

 

CODE:[Copy to clipboard]# metainit -f d11 1 1 c0t0d0s1

# metainit -f d21 1 1 c0t1d0s1

# metainit d1 -m d11

Define the metadevices for c0t0d0s4 (/var):

 

 

CODE:[Copy to clipboard]# metainit -f d14 1 1 c0t0d0s4

# metainit -f d24 1 1 c0t1d0s4

# metainit d4 -m d14

4.Edit /etc/vfstab so that it references the DiskSuite metadevices instead of simple slices:

 

 

CODE:[Copy to clipboard]#device           device          mount   FS      fsck    mount   mount

#to mount         to fsck         point   type    pass    at boot options

#

fd               -                /dev/fd fd      -       no      -

/proc            -                /proc   proc    -       no      -

/dev/md/dsk/d1   -                -       swap    -       no      -

/dev/md/dsk/d0   /dev/md/rdsk/d0  /       ufs     1       no      logging

/dev/md/dsk/d4   /dev/md/rdsk/d4  /var    ufs     1       no      logging

swap             -                /tmp    tmpfs   -       yes     -

5.Reboot the system:

 

 

CODE:[Copy to clipboard]# lockfs -fa

 

# sync;sync;sync;init 6

6.After the system reboots from the metadevices for /, /var, and swap, set up mirrors:

 

 

CODE:[Copy to clipboard]# metattach d0 d20

# metattach d1 d21

# metattach d4 d24

The process of synchronizing the data to the mirror disk will take a while. You can monitor its progress via the command:

 

 

CODE:[Copy to clipboard]# metastat|grep -i progress

7.Capture the DiskSuite configuration in the text file md.tab. With Solaris 2.6 and Solaris 7, this text file resides in the directory /etc/opt/SUNWmd; however, more recent versions of Solaris place the file in the /etc/lvm directory. We'll assume that we're running Solaris 8 here:

 

 

CODE:[Copy to clipboard]# metastat -p | tee /etc/lvm/md.tab

8.In order for the system to be able to dump core in the event of a panic, the dump device needs to reference the DiskSuite metadevice:

 

 

CODE:[Copy to clipboard]# dumpadm -d /dev/md/dsk/d1

9.If the primary boot disk should fail, make it easy to boot from the mirror. Some sites choose to alter the OBP "boot-device" variable; in this case, we choose to simply define the device aliases "sds-root" and "sds-mirror". In the event that the primary boot device ("disk" or "sds-root" should fail, the administrator simply needs to type "boot sds-mirror" at the OBP prompt.

 

Determine the device path to the boot devices for both the primary and mirror:

 

 

CODE:[Copy to clipboard]# ls -l /dev/dsk/c0t0d0s0 /dev/dsk/c0t1d0s0

lrwxrwxrwx   1 root     root          41 Oct 17 11:48 /dev/dsk/c0t0d0s0 ->; ../..

/devices/pci@1f,4000/scsi@3/sd@0,0:a

lrwxrwxrwx   1 root     root          41 Oct 17 11:48 /dev/dsk/c0t1d0s0 ->; ../..

/devices/pci@1f,4000/scsi@3/sd@1,0:a

Use the device paths to define the sds-root and sds-mirror device aliases (note that we use the label "disk" instead of "sd" in the device alias path):

 

 

CODE:[Copy to clipboard]# eeprom "nvramrc=devalias sds-root /pci@1f,4000/scsi@3/disk@0,0

devalias sds-mirror /pci@1f,4000/scsi@3/disk@1,0"

# eeprom "use-nvramrc?=true"

Test the process of booting from either sds-root or sds-mirror.

 

Once the above sequence of steps has been completed. the system will look as follows:

 

 

CODE:[Copy to clipboard]# metadb

        flags           first blk       block count

     a m  p  luo        16              1034            /dev/dsk/c0t0d0s5

     a    p  luo        16              1034            /dev/dsk/c0t0d0s6

     a    p  luo        16              1034            /dev/dsk/c0t1d0s5

     a    p  luo        16              1034            /dev/dsk/c0t1d0s6

 

# df -k

Filesystem            kbytes    used   avail capacity  Mounted on

/dev/md/dsk/d0       6607349  845208 5696068    13%    /

/proc                      0       0       0     0%    /proc

fd                         0       0       0     0%    /dev/fd

mnttab                     0       0       0     0%    /etc/mnttab

/dev/md/dsk/d4       1016863    8414  947438     1%    /var

swap                 1443840       8 1443832     1%    /var/run

swap                 1443848      16 1443832     1%    /tmp

Trans metadevices for logging

 

UFS filesystem logging was first supported with Solaris 7. Prior to that release, one could create trans metadevices with DiskSuite to achieve the same effect. For Solaris 7 and up, it's much easier to simply enable ufs logging by adding the word "logging" to the last field of the /etc/vfstab file. The following section is included for those increasingly rare Solaris 2.6 installations.

 

The following two steps assume that you are have an available (<=64MB) slice 3 available for logging.

 

1.Define the trans metadevice mirror (c0t0d0s3):

 

 

CODE:[Copy to clipboard]# metainit d13 1 1 c0t0d0s3

# metainit d23 1 1 c0t1d0s3

# metainit d3 -m d13

# metattach d3 d23

2.Make /var use the trans meta device for logging:

 

 

CODE:[Copy to clipboard]# metainit -f d64 -t d4 d3

Edit vfstab as follows:

 

 

CODE:[Copy to clipboard]/dev/md/dsk/d64 /dev/md/rdsk/d64 /var ufs 1 no -

Ensure that no volumes are syncing before running the following:

 

 

CODE:[Copy to clipboard]# sync;sync;sync;init 6

 

 

Disksuite examples

 

Here are some quick examples on doing a few other DiskSuite tasks:

creating a striped metadevice:

 

 

CODE:[Copy to clipboard]# metainit d10 1 2 c0t1d0s0 c0t2d0s0 -i 32k

creating a mirror of two slices:

 

 

CODE:[Copy to clipboard]# metainit d60 1 1 c0t2d0s0

# metainit d61 1 1 c0t3d0s0

# metainit d6 -m d60

# metattach d6 d61

creating a concatenation of 2 slices:

 

 

CODE:[Copy to clipboard]# metainit d25 2 1 c0t1d0s0 1 c0t2d0s0

creating a concatenation of 4 slices:

 

 

CODE:[Copy to clipboard]# metainit d25 4 1 c0t1d0s0 1 c0t2d0s0 1 c0t3d0s0 1 c0t4d0s0

creating a concatenation of 2 stripes:

 

 

CODE:[Copy to clipboard]# metainit d0 2 4 c2t0d0s6 c2t1d0s6 c2t2d0s6 c2t3d0s6 -i 64k 2 c3t0d0s6 c3t1d0s6 -i 64k

creating a raid5 metadevice from three slices:

 

 

CODE:[Copy to clipboard]# metainit d45 -r c2t3d0s0 c3t0d0s0 c4t0d0s0

 

 

 

__________________________________

 

 

Replacing a failed bootdisk

In the following example, the host has a failed bootdisk (c0t0d0). Fortunately, the system is using DiskSuite, with a mirror at c0t1d0. The following sequence of steps can be used to restore the system to full redundancy.

 

System fails to boot

 

When the system attempts to boot, it fails to find a valid device as required by the boot-device path at device alias "disk". It then attempts to boot from the network:

 

 

CODE:[Copy to clipboard]screen not found.

Can't open input device.

Keyboard not present.  Using ttya for input and output.

 

Sun Ultra 30 UPA/PCI (UltraSPARC-II 296MHz), No Keyboard

OpenBoot 3.27, 512 MB memory installed, Serial #9377973.

Ethernet address 8:0:20:8f:18:b5, Host ID: 808f18b5.

 

 

 

Initializing Memory

Timeout waiting for ARP/RARP packet

Timeout waiting for ARP/RARP packet

Timeout waiting for ARP/RARP packet

...

Boot from mirror

 

At this point, the administrator realizes that the boot disk has failed, and queries the device aliases to find the one corresponding to the disksuite mirror:

 

 

CODE:[Copy to clipboard]ok devalias

sds-mirror               /pci@1f,4000/scsi@3/disk@1,0

sds-root                 /pci@1f,4000/scsi@3/disk@0,0

net                      /pci@1f,4000/network@1,1

disk                     /pci@1f,4000/scsi@3/disk@0,0

cdrom                    /pci@1f,4000/scsi@3/disk@6,0:f

...

The administrator then boots the system from the mirror device "sds-mirror":

 

 

CODE:[Copy to clipboard]ok boot sds-mirror

The system starts booting off of sds-mirror. However, because there are only two of the original four state database replicas available, a quorum is not achieved. The system requires manual intervention to remove the two failed state database replicas:

 

Starting with DiskSuite 4.2.1, an optional /etc/system parameter exists which allows DiskSuite to boot with just 50% of the state database replicas online. For example, if one of the two boot disks were to fail, just two of the four state database replicas would be available. Without this /etc/system parameter (or with older versions of DiskSuite), the system would complain of "insufficient state database replicas", and manual intervention would be required on bootup. To enable the "50% boot" behaviour with DiskSuite 4.2.1, execute the following command:

 

 

CODE:[Copy to clipboard]# echo "set md:mirrored_root_flag=1" >;>; /etc/system

 

 

 

CODE:[Copy to clipboard]Boot device: /pci@1f,4000/scsi@3/disk@1,0  File and args:

SunOS Release 5.8 Version Generic_108528-07 64-bit

Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.

WARNING: md: d10: /dev/dsk/c0t0d0s0 needs maintenance

WARNING: forceload of misc/md_trans failed

WARNING: forceload of misc/md_raid failed

WARNING: forceload of misc/md_hotspares failed

configuring IPv4 interfaces: hme0.

Hostname: pegasus

metainit: pegasus: stale databases

 

Insufficient metadevice database replicas located.

 

Use metadb to delete databases which are broken.

Ignore any "Read-only file system" error messages.

Reboot the system when finished to reload the metadevice database.

After reboot, repair any broken database replicas which were deleted.

 

Type control-d to proceed with normal startup,

(or give root password for system maintenance): ******

 

single-user privilege assigned to /dev/console.

Entering System Maintenance Mode

 

Oct 17 19:11:29 su: 'su root' succeeded for root on /dev/console

Sun Microsystems Inc.   SunOS 5.8       Generic February 2000

 

# metadb -i

        flags           first blk       block count

    M     p             unknown         unknown         /dev/dsk/c0t0d0s5

    M     p             unknown         unknown         /dev/dsk/c0t0d0s6

     a m  p  lu         16              1034            /dev/dsk/c0t1d0s5

     a    p  l          16              1034            /dev/dsk/c0t1d0s6

o - replica active prior to last mddb configuration change

u - replica is up to date

l - locator for this replica was read successfully

c - replica's location was in /etc/lvm/mddb.cf

p - replica's location was patched in kernel

m - replica is master, this is replica selected as input

W - replica has device write errors

a - replica is active, commits are occurring to this replica

M - replica had problem with master blocks

D - replica had problem with data blocks

F - replica had format problems

S - replica is too small to hold current data base

R - replica had device read errors

 

 

# metadb -d c0t0d0s5 c0t0d0s6

metadb: pegasus: /etc/lvm/mddb.cf.new: Read-only file system

 

# metadb -i

        flags           first blk       block count

     a m  p  lu         16              1034            /dev/dsk/c0t1d0s5

     a    p  l          16              1034            /dev/dsk/c0t1d0s6

o - replica active prior to last mddb configuration change

u - replica is up to date

l - locator for this replica was read successfully

c - replica's location was in /etc/lvm/mddb.cf

p - replica's location was patched in kernel

m - replica is master, this is replica selected as input

W - replica has device write errors

a - replica is active, commits are occurring to this replica

M - replica had problem with master blocks

D - replica had problem with data blocks

F - replica had format problems

S - replica is too small to hold current data base

R - replica had device read errors

 

# reboot -- sds-mirror

Check extent of failures

 

Once the reboot is complete, the administrator then logs into the system and checks the status of the DiskSuite metadevices. Not only have the state database replicas failed, but all of the DiskSuite metadevices previously located on device c0t0d0 need to be replaced. Clearly the disk has completely failed.

 

 

CODE:[Copy to clipboard]pegasus console login: root

Password:  ******

Oct 17 19:14:03 pegasus login: ROOT LOGIN /dev/console

Last login: Thu Oct 17 19:02:42 from rambler.wakefie

Sun Microsystems Inc.   SunOS 5.8       Generic February 2000

 

# metastat

d0: Mirror

    Submirror 0: d10

      State: Needs maintenance

    Submirror 1: d20

      State: Okay        

    Pass: 1

    Read option: roundrobin (default)

    Write option: parallel (default)

    Size: 13423200 blocks

 

d10: Submirror of d0

    State: Needs maintenance

    Invoke: metareplace d0 c0t0d0s0 ;

    Size: 13423200 blocks

    Stripe 0:

        Device              Start Block  Dbase State        Hot Spare

        c0t0d0s0                   0     No    Maintenance 

 

 

d20: Submirror of d0

    State: Okay        

    Size: 13423200 blocks

    Stripe 0:

        Device              Start Block  Dbase State        Hot Spare

        c0t1d0s0                   0     No    Okay        

 

 

d1: Mirror

    Submirror 0: d11

      State: Needs maintenance

    Submirror 1: d21

      State: Okay        

    Pass: 1

    Read option: roundrobin (default)

    Write option: parallel (default)

    Size: 2100000 blocks

 

d11: Submirror of d1

    State: Needs maintenance

    Invoke: metareplace d1 c0t0d0s1 ;

    Size: 2100000 blocks

    Stripe 0:

        Device              Start Block  Dbase State        Hot Spare

        c0t0d0s1                   0     No    Maintenance 

 

 

d21: Submirror of d1

    State: Okay        

    Size: 2100000 blocks

    Stripe 0:

        Device              Start Block  Dbase State        Hot Spare

        c0t1d0s1                   0     No    Okay        

 

 

d4: Mirror

    Submirror 0: d14

      State: Needs maintenance

    Submirror 1: d24

      State: Okay        

    Pass: 1

    Read option: roundrobin (default)

    Write option: parallel (default)

    Size: 2100000 blocks

 

d14: Submirror of d4

    State: Needs maintenance

    Invoke: metareplace d4 c0t0d0s4 ;

    Size: 2100000 blocks

    Stripe 0:

        Device              Start Block  Dbase State        Hot Spare

        c0t0d0s4                   0     No    Maintenance 

 

 

d24: Submirror of d4

    State: Okay        

    Size: 2100000 blocks

    Stripe 0:

        Device              Start Block  Dbase State        Hot Spare

        c0t1d0s4                   0     No    Okay        

Replace failed disk and restore redundancy

 

The administrator replaces the failed disk with a new disk of the same geometry. Depending on the system model, the disk replacement may require that the system be powered down. The replacement disk is then partitioned identically to the mirror, and state database replicas are copied onto the replacement disk. Finally, the metareplace command copies that data from the mirror to the replacement disk, restoring redundancy to the system.

 

 

CODE:[Copy to clipboard]# prtvtoc /dev/rdsk/c0t1d0s2 | fmthard -s - /dev/rdsk/c0t0d0s2

fmthard:  New volume table of contents now in place.

 

# installboot /usr/platform/sun4u/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0

 

# metadb -f -a /dev/dsk/c0t0d0s5

 

# metadb -f -a /dev/dsk/c0t0d0s6

 

# metadb -i

        flags           first blk       block count

     a        u         16              1034            /dev/dsk/c0t0d0s5

     a        u         16              1034            /dev/dsk/c0t0d0s6

     a m  p  luo        16              1034            /dev/dsk/c0t1d0s5

     a    p  luo        16              1034            /dev/dsk/c0t1d0s6

o - replica active prior to last mddb configuration change

u - replica is up to date

l - locator for this replica was read successfully

c - replica's location was in /etc/lvm/mddb.cf

p - replica's location was patched in kernel

m - replica is master, this is replica selected as input

W - replica has device write errors

a - replica is active, commits are occurring to this replica

M - replica had problem with master blocks

D - replica had problem with data blocks

F - replica had format problems

S - replica is too small to hold current data base

R - replica had device read errors

 

# metareplace -e d0 c0t0d0s0

d0: device c0t0d0s0 is enabled

 

# metareplace -e d1 c0t0d0s1

d1: device c0t0d0s1 is enabled

 

# metareplace -e d4 c0t0d0s4

d4: device c0t0d0s4 is enabled

Once the resync process is complete, operating system redundancy has been restored.

 

Performing maintenance when booted from cdrom

 

Introduction

If the system has to be booted from a cdrom or from the network ("boot cdrom" or "boot net" in order to perform maintenance, the operator needs to adjust for the existence of a mirrored operating system. Because these alternate boot devices do not include the drivers necessary for disksuite, they cannot be used to operate on state database replicas and Disksuite metadevices. This raises subtle issues addressed below.

 

Typically, the administrator is often under pressure while performing these types of maintenance. Because simple mistakes at this stage can render the system unusable, it is important that the process be well documented and tested prior to using it in production. Fortunately, this process is simpler than that for Veritas volume manager because there are no "de-encapsulation" issues to address.

 

Booting from cdrom with DiskSuite mirrored devices

 

In the example below, the server pegasus has two internal disks (c0t0d0 and c0t1d0) under Disksuite control. The operating system is mirrored between the two devices, with slices five and six on each disk employed for state database replicas. Assume that the administrator has forgotten the root password on this server, and needs to boot from cdrom in order to edit the shadow file.

 

1.Insert the Solaris operating system CD into the cdrom drive and boot from it into single-user mode:

 

 

CODE:[Copy to clipboard]ok boot cdrom -s

 

Initializing Memory

Rebooting with command: boot cdrom -s

Boot device: /pci@1f,4000/scsi@3/disk@6,0:f  File and args: -s

SunOS Release 5.8 Version Generic_108528-07 64-bit

Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.

Configuring /dev and /devices

Using RPC Bootparams for network configuration information.

Skipping interface hme0

 

INIT: SINGLE USER MODE

#

2.Fsck and mount the root disk's "/" partition in order to edit the /etc/shadow file:

 

 

CODE:[Copy to clipboard]# fsck -y /dev/rdsk/c0t0d0s0

 

# mount /dev/dsk/c0t0d0s0 /a

3.Remove the encrypted password from the /a/etc/shadow file:

 

 

CODE:[Copy to clipboard]# TERM=vt100; export TERM

 

# vi /a/etc/shadow

For example, if the entry for the root user looks like the following:

 

 

CODE:[Copy to clipboard]root:NqfAn3tWOy2Ro:6445::::::

Change it so that is looks as follows:

 

 

CODE:[Copy to clipboard]root::6445::::::

4.Comment out the rootdev entry from the /a/etc/system file:

 

 

CODE:[Copy to clipboard]# vi /a/etc/system

For example, change the line:

 

 

CODE:[Copy to clipboard]rootdev:/pseudo/md@0:0,0,blk

to

 

 

CODE:[Copy to clipboard]* rootdev:/pseudo/md@0:0,0,blk

5.Update the /a/etc/vfstab file so that it references simple disk slices instead of disksuite metadevices. Note that you only have to change those enties that correspond to operating system slices.

 

For example, one would change the following /a/etc/vfstab file:

 

 

CODE:[Copy to clipboard]#device             device             mount   FS      fsck    mount   mount

#to mount           to fsck            point   type    pass    at boot options

#

fd                  -                  /dev/fd fd      -       no      -

/proc               -                  /proc   proc    -       no      -

/dev/md/dsk/d1      -                  -       swap    -       no      -

/dev/md/dsk/d0      /dev/md/rdsk/d0    /       ufs     1       no      logging

/dev/md/dsk/d4      /dev/md/rdsk/d4    /var    ufs     1       no      logging

swap                -                  /tmp    tmpfs   -       yes     -

to:

 

 

CODE:[Copy to clipboard]#device             device             mount   FS      fsck    mount   mount

#to mount           to fsck            point   type    pass    at boot options

#

fd                  -                  /dev/fd fd      -       no      -

/proc               -                  /proc   proc    -       no      -

/dev/dsk/c0t0d0s1   -                  -       swap    -       no      -

/dev/dsk/c0t0d0s0   /dev/rdsk/c0t0d0s0 /       ufs     1       no      logging

/dev/dsk/c0t0d0s4   /dev/rdsk/c0t0d0s4 /var    ufs     1       no      logging

swap                -                  /tmp    tmpfs   -       yes     -

6.Unmount the root filesystem, fsck it, and return to the ok prompt:

 

 

CODE:[Copy to clipboard]# cd /; umount /a; fsck -y /dev/rdsk/c0t0d0s0

 

# stop-a

ok

7.Boot from c0t0d0 into single user mode. It is important to boot just to single user mode so that DiskSuite does not start automatically:

 

 

CODE:[Copy to clipboard]ok boot -sw

8.When prompted for the root password, just press the ENTER key. Once at the shell prompt, clear the metadevices that referenced the filesystems that you updated in the /a/etc/vfstab file above:

 

 

CODE:[Copy to clipboard]# metaclear -f -r d0 d1 d4

Now would be an appropriate time to create a new password for the root account, via the passwd root command

 

9.Exit from single user mode and continue the boot process.

 

 

CODE:[Copy to clipboard]# exit

Removing Disksuite

 

Introduction

 

There are many circumstances in which it may be necessary to remove the operating system from Disksuite control. For example, the process of upgrading the operating system from one release to another requires that the Solaris filesystem be simple slices, not metadevices. Prior to upgrading the operating system, the administrator must first remove Disksuite from the system, while preserving the data in the underlying slices.

 

Typically, the administrator is often under pressure while performing these types of maintenance. Because simple mistakes at this stage can render the system unusable, it is important that the process be well documented and tested prior to using it in production. Fortunately, this process is simpler than that for Veritas volume manager because there are no "de-encapsulation" issues to address.

 

Removing Disksuite step-by-step

 

In the example below, the server pegasus has two internal disks (c0t0d0 and c0t1d0) under Disksuite control. The operating system is mirrored between the two devices, with slices five and six on each disk employed for state database replicas:

 

 

CODE:[Copy to clipboard]# metadb

        flags           first blk       block count

     a m  p  luo        16              1034            /dev/dsk/c0t0d0s5

     a    p  luo        16              1034            /dev/dsk/c0t0d0s6

     a    p  luo        16              1034            /dev/dsk/c0t1d0s5

     a    p  luo        16              1034            /dev/dsk/c0t1d0s6

 

# df -k

Filesystem            kbytes    used   avail capacity  Mounted on

/dev/md/dsk/d0       6607349  845208 5696068    13%    /

/proc                      0       0       0     0%    /proc

fd                         0       0       0     0%    /dev/fd

mnttab                     0       0       0     0%    /etc/mnttab

/dev/md/dsk/d4       1016863    8414  947438     1%    /var

swap                 1443840       8 1443832     1%    /var/run

swap                 1443848      16 1443832     1%    /tmp

1.Using the Disksuite metaroot command, change the root device to a simple slice. This will update the /etc/system and /etc/vfstab files:

 

 

CODE:[Copy to clipboard]# metaroot /dev/dsk/c0t0d0s0

2.Detach the metadevices from c0t1d0:

 

 

CODE:[Copy to clipboard]# metadetach d0 d20

# metadetach d1 d21

# metadetach d4 d24

3.Edit the /etc/vfstab to reference the physical disk slices (eg. /dev/dsk/c0t0d0s4) rather than the Disksuite metadevices (eg. /dev/md/dsk/d4).

 

4.If the system is using a DiskSuite metadevice for crash dumps, use the dumpadm command to send crash dumps to a simple disk slice (eg. swap):

 

 

CODE:[Copy to clipboard]# dumpadm -d /dev/dsk/c0t0d0s1

5.Reboot the system, hopefully mounting the simple slices from c0t0d0 for /, /var, and swap:

 

 

CODE:[Copy to clipboard]# reboot

The server should come back up mounting the physical disk slices. Verify this with df -ak

 

6.Remove the now unused Disksuite metadevices:

 

 

CODE:[Copy to clipboard]# metaclear d20 d21 d24

# metaclear -r d0 d1 d4

7.Delete the state database replicas. You can determine their location with the command "metadb -i":

 

 

CODE:[Copy to clipboard]# metadb -d -f c0t0d0s5 c0t0d0s6 c0t1d0s5 c0t1d0s6

8.Confirm that there are no remaining metadevices or state database replicas present. The commands "metadb -i" and "metastat" shouldn't return anything.

 

At this point, the operating system is no longer under Disksuite control. The disk c0t1d0 is unused, and the system would not survive the failure of c0t0d0 if it were to die now. However, the system is now ready to be upgraded. Because operating system upgrades are not completely reliable, it is recommended that the administrator duplicate the disk c0t0d0 to c0t1d0 prior to starting the upgrade. This ensures an easy recovery if there are problems during the upgrade.

 

To ensure high availability, the administrator must remember to mirror the operating system again once the upgrade is completed.