Notes on Using Sun DiskSuite on Glued Solaris Machines

Notes on Using Sun DiskSuite package on Glued Sun Machines

The data in these pages is based on experiences mirroring a pair of internal system disks on Sun Enterprise 220R, SunFire 280R, and SunFire V440 systems, running Solaris 2.7 through 2.9.

Contents

• Prelimary steps, considerations, etc.
• Generic Disksuite References
• Disksuite Database replica management
• Mirroring Boot Disk on Glue Solaris

Prelimary Steps and Considerations

There are some preliminary notes and comments about the Disksuite package which is relevant to its use on Glue, as follows.

• First off, certain problems may require one to go into single-user mode to resolve. This is particulary true if you are mirroring the system disks or have only 2 disks containing disksuite metadb replicas. Glued Sun systems password protect single-user mode, so you should make sure you know how to get into single-user mode on your box. Contact Glue staff if you need assistance or the password.

  The single-user password is essential for a two disk mirror, because if a disk fails you will not have a majority of state replicas available, and the system will not reboot in such a case until the replicas on the failed disk are deleted. This can either be done before the system reboots, or from single-user mode. You want to be sure you can access single-user mode if needed.

  Alternatively, at least on Solaris 8 and 9, you can add the line

  set md:mirrored_root_flag=1
  to the file /etc/system, which will override the default behavior and allow the system to boot with exactly 1/2 of the database replicas. This setting is recommended for a two disk mirrored configuration.
• Solaris 2.7 systems only
  Because DiskSuite did not come bundled with the OS for Solaris 2.7 (it is bundled with Solaris 8 and 9), it had to be installed separately, after the fact by Glue staff. Due to some quirks in how the package was rdisted down to the clients, there are certain symbolic links and/or pseudo-devices in the /dev and /devices trees that appearing to be missing on Solaris 2.7 clients. This does not appear to be a problem on Solaris 8 or 9 boxes. At least the /dev/md/admin and /dev/md/dsk/dN and /dev/md/rdsk/dN special files are needed. The directory tree and links under /dev/md/shared may also be needed. These all resolve to device special files in /devices/pseudo which are not normally present on Glued Solaris 2.7 systems, but I am not sure if they must exist prior to running things or if they will get created. There are about a thousand symlinks, and another thousand devices, missing. The script /group/pcs/project/PNCE-Unix/disksuite/disksuite-create-metadevices.pl might be of help in setting these up.
• aSolaris 2.7 systems only
  The directory /etc/opt/SUNWmd must exist on Solaris 2.7 systems, and its contents might have to be there as well. This also appears to be missing on Solaris 2.7 clients. Solaris 8 and 9 clients use /dev/lvm instead of the above, and that does seem to be present on Glued clients of the above OSes. A sample tarball for /etc/opt/SUNWmd is available at /group/pcs/project/PNCE-Unix/disksuite/etc-opt-SUNWmd.tar.
• Solaris 2.7 systems store some Disksuite data in the directory /etc/opt/SUNWmd. Solaris 8 and 9 systems store similar data in /etc/lvm. You will likely be editting the file md.tab within there, and the metadisk commands seem to alter md.cf and md.ctlrmap as well. I do not know how important any of these files (or the other files in that directory) are to the functioning of disksuite; I believe for the most part they are not that critical, with the critical information being stored in the metadb replicas. The md.tab file is created manually, and usually has useful comments. Anyway, I recommend copying all of the files in this directory to the servers config tree, as it is better to have stuff that is not needed than to need stuff you do not have in an emergency. I doubt symlinks will work. I usually update the copies after add/ing/deleting/reconfiguring any metadb replicas or metadevices.
• The important data for describing the metadevices are contained in metadb DB replicas. You should reserve some room on each disk available for these. In some cases you may be able to put them on a slice which will contain a filesystem as well, but in general the slice has to be empty when the DB replica is put on it (you can later add a filesystem to it). (/vicepN filesystems should not be software mirrored.) You need to choose where the DB replicas are to be located. Physics typically puts them on slice 6 or 7 of the internal disks, as a dedicated slice where possible, but otherwise on a slice that contains /usr/afs or /export/data/SOMETHING.
• In addition to the locations of the DB replicas, you will need to come up with a naming scheme for the mirrors and submirrors. Each slice to be mirrored will need a distinctly named disksuite submirror device on each of the disks being mirrored, and in addition the redundant mirrored device also needs to be named. The metadevice names should be of the dN or dMN where M and N are digits, and M cannot be 0 (e.g. d01 is not allowed).

  You probably want to come up with a reasonable naming scheme. And ideally your naming scheme should make it obvious what slice the mirror metadevice refers to, and what disk and slice each submirror refers to. Physics uses the following:

  • submirrors have the form dMN where M is the slice/partition number + 1 and N is the disk number. So M runs from 1 to 8 (the plus 1 eliminating the problematic 0 value), and N is generally 0 or 1. E.g., the submirror for disk c0t0d0s4 would be called d50, and for c0t1d0s2 would be d31.
  • mirrors have the form dM where, as above, M is the slice/partition number +1. E.g., d5 is the mirror consisting of d50 on disk 0 (c0t0d0s4 to be precise), and d51 on disk 1 (c0t1d0s4).
  Other than convenience, however, there is nothing special about the naming.

After the above, you should be at the "normal" beginning point for using DiskSuite. The procedure from here will vary greatly depending on what is desired. Additional information on metadb DB replica management is available, as are pages detailing the following typical metadisk configurations:

• Mirroring the system boot disk (e.g. root(/), /usr, swap, etc.)

Useful Disksuite References

• SlackSite page on mirroring with DiskSuite
• SlackSite page on other stuff you can do with DiskSuite (logging, striping, RAID5)
• Sun Online Documentation for Solstice DiskSuite 4.2.1
• SunHelpDesk doc on mirroring system disks with Disksuite
• Brandon Hutchinson's page about Mirroring with Disksuite

In addition, the purpose of mirroring the system drives is to ensure that the system stays up, so it is useful to be cognizant of the recovery procedure should a disk fail. In particular, there are some small tricks involved when one of a set of mirrored system disks fails. Also, familiarity with the recovery procedure may affect choices made during the initial setup, and recovery can be made easier by proper documentation during the setup. The following references may be of use:

• Slacksite page on recovering from a failed boot disk under DiskSuite
• Physics page on DiskSuite Bootdisk failure and recovery (Glue-specific)