Sun Enterprise Server Alternate Pathing 2.0.1 User's Guide

Chapter 4 Using AP Boot Devices

This chapter describes how you can alternately path the boot disk.

Placing the Boot Disk Under AP Control

To allow for unattended system boot, even if the controller for the boot disk fails, you can place your the boot disk under AP control.

To Place a Boot Disk under AP Control
  1. Create an AP pathgroup for the boot disk.

    This process is described in Chapter 3, Using Metadisks and Disk Pathgroups.

  2. Use apboot(1M) to define the new AP boot device.

    apboot modifies /etc/vfstab and /etc/system. For example:


    # apboot mc2t0d0

    where mc2t0d0 is the metadisk name of the boot disk. apboot examines /etc/vfstab and replaces the physical device name of the disk (for example, /dev/dsk/c2t0d0* or /dev/dsk/c1t0d0*) with the metadisk name (for example, /dev/dsk/mc2t0d0*). It also edits /etc/system so that the kernel drivers required for AP boot disk usage are loaded at the proper time.

    Do not manually replace the physical devices in /etc/vfstab with metadisks for the boot disk. Instead, use apboot to ensure that all required changes are made.

  3. Set the OpenBoot(TM) PROM (OBP) devalias variable boot-device to the physical path most likely to be used for booting.

    For example:


    # setenv boot-device \ /sbus@68,0/SUNW,soc@0,0/SUNW,pln@a0000000,78cab4/ssd@0,2
    

  4. Define a devalias for the alternate boot device path as a convenience in case you need to perform a manual boot.

At this point, reboot the system to begin using the AP boot device.

Normally, the file systems that are mounted as part of the boot process are split across two separate disks (because of disk space requirements). If you place the boot disk under AP control (using apboot(1M)), you must manually edit the /etc/vfstab file to also place other file systems that are mounted during the boot process under AP control. In the /etc/vfstab file, you must change the device to mount and device to fsck paths for all other mount points that you want to place under AP control.

If you want to create a new AP database copy after you have placed the boot disk under AP control, and that database copy is to be located on a partition controlled by a controller port that does not control any of the current AP database partitions, you must first remove the boot disk from AP control. Make sure that the new AP database has been created. Then, place the boot disk under AP control again. Failure to follow this procedure may cause the database to become inaccessible during boot.

To Alternately Path a Mirrored Boot Disk

Mirroring the boot disk is primarily a function of your disk management software. The purpose of this procedure is to notify AP about a mirrored boot disk. When you use mirrored boot disks that are also alternately pathed, you have four potential physical paths to the boot disk, two for each side of the mirror. (At least, this is the recommended configuration if you want to maximize protection against controller failure.) Once you perform the following procedure, AP will assure that the appropriate physical path is active, even if you boot using a different boot device path than the one that was active previously. Furthermore, on the Sun Enterprise 10000 server (which supports automatic switching of the boot device path at boot time), all four paths are available as alternates should an automatic switch be required at boot time.

  1. Place the boot disk under AP control, as described in "To Place a Boot Disk under AP Control", above.

  2. Create an AP pathgroup for the mirror of the boot disk.

    This process is described in Chapter 3, Using Metadisks and Disk Pathgroups.

  3. Notify AP about the boot disk mirror. For example:


    # apboot -m mc3t0d0

    In this example, mc3t0d0 is the metadisk for the mirror of the boot disk.

  4. Create a mirror of your boot disk (using the two metadisks) with your disk management software.

To Remove a Mirrored Boot Disk From AP Control
  1. Use apboot(1M) to undefine the AP mirrored boot device, for example:


    # apboot -u mc3t0d0

To Remove the Boot Disk From AP Control
  1. Use apboot(1M) to specify an appropriate physical device node, for example:


    # apboot c2t0d0

In the above command, c2t0d0 is the physical device node of an alternate path for the boot disk (as currently specified in /etc/vfstab). apboot also edits the /etc/system file to remove force loading of AP kernel driver modules, since they are no longer needed when the boot disk is not an AP device.


Caution - Caution -

If you place the boot disk under AP control, and later decide to remove the AP package (using pkgrm(1M)), you must first use apboot(1M) to remove the boot disk from AP control. If you do not first remove the boot disk from AP control, the system on that disk becomes unbootable.


AP Boot Sequence

This subsection briefly describes the flow of events that occur when the Sun Enterprise 10000 server is booted on an alternately pathed boot disk. This sequence of events illustrates how auto switching of the boot disk controller is achieved during the boot process, if such a switch is necessary. The boot sequence proceeds as follows:

  1. By default, the system is booted from the device specified by the OBP devalias boot-device. Note that this device may be different from the last active alternate for the boot disk.

  2. OBP stores the path to the boot disk on the SSP.

  3. If a failure occurs, it is detected after about one minute. Then, the AP Reboot Host program is executed.


    Note -

    One or two minutes may pass before action is taken, so do not immediately enter new commands if you notice that the boot process has failed. If you attempt a manual recovery from a boot failure, be aware that the automatic reboot recovery process will still be executing and may override your manual recovery command.


  4. AP Reboot Host retrieves the path stored earlier by OBP, and communicates the path to the AP SSP daemon.

  5. The AP SSP daemon looks up the alternate path for the boot disk in the AP SSP database, and retries the boot process with the other alternate path.

  6. After the reboot succeeds, AP determines the alternate from which the system was booted, and makes it the active alternate.

Using Single-User Mode

Normally, when the Sun Enterprise server is fully booted, you use the AP command versions located in /usr/sbin. However, if your server comes up in single-user mode because the boot process did not fully complete, you can use the commands in /sbin. The command versions under /sbin do not rely on the AP daemon services (which are not available in single-user mode). If the system enters single-user mode because of a problem related to AP, you may be able to resolve the problem by using the /sbin commands to perform needed AP operations.

Two AP-related problems may cause the system to come up in single-user mode:

These situations arise only with respect to disks, not networks. In either case, you may be able to use the AP commands under /sbin to resolve the problem.