Chapter 11 Creating RAID-1 Volumes (Mirrors) During Installation (Planning)

This chapter describes the requirements and guidelines that are necessary to create mirrored file systems with the custom JumpStart or Solaris Live Upgrade installation methods.

This chapter describes the following topics.

• System Requirement

• Volume Name Requirements and Guidelines

• State Database Replicas Guidelines and Requirements

• Mirror and Submirror Requirements and Guidelines

• How Booting Into Single-User Mode Affects RAID-1 Volumes

For additional information about planning to create mirrored file systems with the Solaris Live Upgrade installation method, see General Guidelines for Creating Mirrored File Systems.

For instructions about how to create mirrored file systems with the custom JumpStart installation method, see filesys Profile Keyword (Creating Mirrored File Systems) and metadb Profile Keyword (Creating State Database Replicas).

System Requirement

To create mirrored file systems on specific slices, the disks that you plan to use for mirroring must be directly attached and available to the system during the installation.

Volume Name Requirements and Guidelines

The custom JumpStart installation method automatically assigns volume names to RAID-0 submirrors during the installation. You can optionally assign a name to RAID-1 volumes (mirrors) with the filesys JumpStart keyword.

Observe the follwoing rules when assigning names for volumes.

• Volume names must begin with the letter d followed by a number, for example, d0.

• Instead of specifying the full volume name, such as /dev/md/dsk/d1, you can often use an abbreviated volume name, such as d1.

To simplify the administration of volumes, consider using the following standard naming conventions.

• Use ranges for each particular type of volume. For example, assign numbers 0–20 for RAID-1 volumes, and 21–40 for RAID-0 volumes.

• When you use Solaris Live Upgrade to create mirrors, use a naming relationship for mirrors. You can name mirrors with a number that ends in zero (0), and submirrors that end in one (1) and two (2). Examples are mirror d10, submirrors d11 and d12, and mirror d20, submirrors d21 and d22.

  When you use the custom JumpStart installation method to create mirrors, the submirrors are automatically assigned a name that corresponds to the name of the mirror.

• Use a naming method that maps the slice number and disk number to volume numbers.

• Solaris Volume Manager has 128 default volume names from 0–127. The following list shows some example volume names.

  • Device /dev/md/dsk/d0 — block volume d0

  • Device /dev/md/dsk/d1 — block volume d1

For detailed information about Solaris Volume Manager naming requirements, see Solaris Volume Manager Administration Guide.

State Database Replicas Guidelines and Requirements

You should distribute state database replicas across slices, drives, and controllers, to avoid single points of failure. You want a majority of replicas to survive a single component failure. If you lose a replica, when a device fails, for example, the failure might cause problems with running Solaris Volume Manager software or when rebooting the system. Solaris Volume Manager software requires at least half of the replicas to be available to run, but a majority (half plus one) to reboot into multiuser mode.

For detailed instructions about creating and administering state database replicas, see Solaris Volume Manager Administration Guide.

Selecting Slices for State Database Replicas

Before selecting slices for state database replicas, consider the following guidelines and recommendations.

• You should create state database replicas on a dedicated slice of at least 4 Mbytes per replica. If necessary, you could create state database replicas on a slice that is to be used as part of a RAID-0 or RAID-1 volume. You must create the replicas before you add the slice to the volume.

• By default, the size of a state database replica is 4 Mbytes or 8192 disk blocks. Because your disk slices might not be that small, you can resize a slice to hold the state database replica. For information about resizing a slice, see “Administering Disks (Tasks)” in System Administration Guide: Basic Administration.

• You can create state database replicas on slices that are not in use. The part of a slice that is reserved for the state database replica should not be used for any other purpose.

• You cannot create state database replicas on existing file systems, or the root (/), /usr, and swap file systems. If necessary, you can create a new slice (provided a slice name is available) by allocating space from swap and then put state database replicas on that new slice.

• When a state database replica is placed on a slice that becomes part of a volume, the capacity of the volume is reduced by the space that is occupied by the replica or replicas. The space that is used by a replica is rounded up to the next cylinder boundary and this space is skipped by the volume.

Choosing the Number of State Database Replicas

Before choosing the number of state database replicas, consider the following guidelines.

• A minimum of 3 state database replicas are recommended, up to a maximum of 50 replicas per Solaris Volume Manager disk set. The following guidelines are recommended:

  • For a system with only a single drive: put all three 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.

• Additional state database replicas can improve the mirror's performance. Generally, you need to add two replicas for each mirror you add to the system.

• If you have a RAID-1 volume that is to be used for small-sized random I/O (for example, for a database), consider your number of replicas. For best performance, ensure that you have at least two extra replicas per RAID-1 volume on slices (and preferably on disks and controllers) that are unconnected to the RAID-1 volume.

Distributing State Database Replicas Across Controllers

If multiple controllers exist, replicas should be distributed as evenly as possible across all controllers. This strategy provides redundancy if a controller fails and also helps balance the load. If multiple disks exist on a controller, at least two of the disks on each controller should store a replica.

Mirror and Submirror Requirements and Guidelines

When you are working with RAID-1 volumes (mirrors) and RAID-0 volumes (single-slice concatenations), consider the following guidelines.

Custom JumpStart and Solaris Live Upgrade Guidelines

The custom JumpStart installation method and Solaris Live Upgrade support a subset of the features that are available in the Solaris Volume Manager software. When you create mirrored file systems with these installation programs, consider the following guidelines.

• The term RAID-0 volume can refer to disk stripes or disk concatenations. The custom JumpStart and Solaris Live Upgrade installation methods only enable you to create single-slice concatenations. You cannot create RAID-0 stripe volumes during the installation or upgrade.

• The custom JumpStart installation method enables you to create up to two submirrors for each mirror. The Solaris Live Upgrade installation method enables you to create up to three submirrors for each mirror. Two submirrors usually provide sufficient data redundancy for most applications, and the disk drive costs are less expensive. Three submirrors enable you to take a submirror offline and perform a backup while maintaining the two remaining submirrors for continued data redundancy.

• If you create mirrored file systems with the custom JumpStart installation method, you do not need to create the file systems that you are mirroring before you create the mirror.

Guidelines for Selecting Disks and Controllers

When you choose the disks and controllers that you want to use to mirror a file system, consider the following guidelines.

• Use components that are on different controllers to increase the number of simultaneous reads and writes that can be performed.

• Keep the slices of different submirrors on different disks and controllers. Data protection is diminished considerably if slices of two or more submirrors of the same mirror are on the same disk.

• Organize submirrors across separate controllers, because controllers and associated cables tend to fail more often than disks. This practice also improves mirror performance.

• Use the same type of disks and controllers in a single mirror. Particularly in old SCSI storage devices, different models or brands of disk or controller can have widely varying performance. Mixing the different performance levels in a single mirror can cause performance to degrade significantly.

Guidelines for Selecting Slices

When you choose the slices that you want to use to mirror a file system, consider the following guidelines.

• Any file system, including root (/), swap, and /usr, can use a mirror. Any application, such as a database, also can use a mirror.

• Make sure that your submirror slices are of equal size. Submirrors of different sizes result in unused disk space.

• If you have a mirrored file system in which the first submirror attached does not start on cylinder 0, all additional submirrors you attach must also not start on cylinder 0. If you attempt to attach a submirror starting on cylinder 0 to a mirror in which the original submirror does not start on cylinder 0, the following error message is displayed:

  can't attach labeled submirror to an unlabeled mirror

  You must ensure that all submirrors you plan to attach to a mirror either all start on cylinder 0, or that none of them start on cylinder 0.

  Starting cylinders do not have to be identical across all submirrors, but all submirrors must either include or not include cylinder 0.

How Booting Into Single-User Mode Affects RAID-1 Volumes

If a system with mirrors for root (/), /usr, and swap is booted into single-user mode, the system indicates that these mirrors are in need of maintenance. When you view these mirrors with the metastat command, these mirrors, and possibly all mirrors on the system, appear in the “Needing Maintenance” state.

Though this situation appears to be potentially dangerous, do not be concerned. The metasync -r command, which normally occurs during boot to resynchronize mirrors, is interrupted when the system is booted into single-user mode. After the system is rebooted, the metasync -r command runs and resynchronizes all mirrors.

If this interruption is a concern, run the metasync -r command manually.

For more information on the metasync, see the metasync(1M) man page, and Solaris Volume Manager Administration Guide.