Chapter 8 Creating RAID-1 Volumes (Mirrors) During Installation (Overview)

This chapter discusses the advantages of creating RAID-1 volumes (mirrors) for the root (/) file system. This chapter also describes the Solaris Volume Manager components that are required to create mirrors for file systems. This chapter describes the following topics.

• Why Use RAID-1 Volumes?

• How Do RAID-1 Volumes Work?

• Overview of Solaris Volume Manager Components

• Example of RAID-1 Volume Disk Layout

For additional information specific to Solaris Live Upgrade or JumpStart, see the following references:

• For Solaris Live Upgrade: General Guidelines When Creating RAID-1 Volumes (Mirrored) File Systems in Solaris 10 11/06 Installation Guide: Solaris Live Upgrade and Upgrade Planning

• For JumpStart:

  • filesys Profile Keyword (Creating RAID-1 Volumes) in Solaris 10 11/06 Installation Guide: Custom JumpStart and Advanced Installations

  • metadb Profile Keyword (Creating State Database Replicas) in Solaris 10 11/06 Installation Guide: Custom JumpStart and Advanced Installations

Why Use RAID-1 Volumes?

During the installation or upgrade, you can create RAID-1 volumes to duplicate your system data over multiple physical disks. By duplicating your data over separate disks, you can protect your data from disk corruption or a disk failure.

The Solaris custom JumpStart and Solaris Live Upgrade installation methods use the Solaris Volume Manager technology to create RAID-1 volumes that mirror a file system. Solaris Volume Manager provides a powerful way to reliably manage your disks and data by using volumes. Solaris Volume Manager enables concatenations, stripes, and other complex configurations. The custom JumpStart and Solaris Live Upgrade installation methods enable a subset of these tasks, such as creating a RAID-1 volume for the root (/) file system. You can create RAID-1 volumes during your installation or upgrade, eliminating the need to create them after the installation.

• For guidelines, see Custom JumpStart and Solaris Live Upgrade Guidelines.

• For detailed information about complex Solaris Volume Manager software and components, see Solaris Volume Manager Administration Guide.

How Do RAID-1 Volumes Work?

Solaris Volume Manager uses virtual disks to manage physical disks and their associated data. In Solaris Volume Manager, a virtual disk is called a volume. A volume is a name for a group of physical slices that appear to the system as a single, logical device. Volumes are actually pseudo, or virtual, devices in standard UNIX® terms.

A volume is functionally identical to a physical disk in the view of an application or a file system (such as UFS). Solaris Volume Manager converts I/O requests that are directed at a volume into I/O requests to the underlying member disks. Solaris Volume Manager volumes are built from slices (disk partitions) or from other Solaris Volume Manager volumes.

You use volumes to increase performance and data availability. In some instances, volumes can also increase I/O performance. Functionally, volumes behave the same way as slices. Because volumes look like slices, they are transparent to end users, applications, and file systems. Like physical devices, you can use Solaris Volume Manager software to access volumes through block or raw device names. The volume name changes, depending on whether the block or raw device is used. The custom JumpStart installation method and Solaris Live Upgrade support the use of block devices to create mirrored file systems. See RAID Volume Name Requirements and Guidelines for Custom JumpStart and Solaris Live Upgrade for details about volume names.

When you create RAID-1 volumes ) with RAID-0 volumes (single-slice concatenations), Solaris Volume Manager duplicates data on the RAID-0 submirrors and treats the submirrors as one volume.

Figure 8–1 shows a mirror that duplicates the root (/) file system over two physical disks.

Figure 8–1 Creating RAID-1 Volumes on the Root (/) File System on Two Disks

Figure 8–1 shows a system with the following configuration.

• The mirror that is named d30 consists of the submirrors that are named d31 and d32. The mirror, d30, duplicates the data in the root (/) file system on both submirrors.

• The root (/) file system on hdisk0 is included in the single-slice concatenation that is named d31.

• The root (/) file system is copied to the hard disk named hdisk1. This copy is the single-slice concatenation that is named d32.

Overview of Solaris Volume Manager Components

The custom JumpStart installation method and Solaris Live Upgrade enable you to create the following components that are required to replicate data.

• State database and state database replicas (metadbs)

• RAID-1 volumes (mirrors) with single-slice concatenations (submirrors)

This section briefly describes each of these components. For complete information about these components, see Solaris Volume Manager Administration Guide.

State Database and State Database Replicas

The state database is a database that stores information on a physical disk. The state database records and tracks changes that are made to your configuration. Solaris Volume Manager automatically updates the state database when a configuration or state change occurs. Creating a new volume is an example of a configuration change. A submirror failure is an example of a state change.

The state database is actually a collection of multiple, replicated database copies. Each copy, referred to as a state database replica, ensures that the data in the database is always valid. Having copies of the state database protects against data loss from single points of failure. The state database tracks the location and status of all known state database replicas.

Solaris Volume Manager cannot operate until you have created the state database and its state database replicas. A Solaris Volume Manager configuration must have an operating state database.

The state database replicas ensure that the data in the state database is always valid. When the state database is updated, each state database replica is also updated. The updates occur one at a time to protect against corruption of all updates if the system crashes.

If your system loses a state database replica, Solaris Volume Manager must identify which state database replicas still contain valid data. Solaris Volume Manager determines this information by using a majority consensus algorithm. This algorithm requires that a majority (half + 1) of the state database replicas be available and in agreement before any of them are considered valid. Because of this majority consensus algorithm, you must create at least three state database replicas when you set up your disk configuration. A consensus can be reached if at least two of the three state database replicas are available.

Each state database replica occupies 4 Mbytes (8192 disk sectors) of disk storage by default. Replicas can be stored on the following devices:

• A dedicated local disk slice

• Solaris Live Upgrade only:

  • A local slice that will be part of a volume

  • A local slice that will be part of a UFS logging device

Replicas cannot be stored on the root (/), swap, or /usr slices, or on slices that contain existing file systems or data. After the replicas have been stored, volumes or file systems can be placed on the same slice.

You can keep more than one copy of a state database on one slice. However, you might make the system more vulnerable to a single point of failure by placing state database replicas on a single slice.

RAID-1 Volumes (Mirrors)

A RAID-1 volume, or mirror, is a volume that maintains identical copies of the data in RAID-0 volumes (single-slice concatenations). After you configure a RAID-1 volume, the volume can be used just as if it were a physical slice. You can duplicate any file system, including existing file systems. You can also use a RAID-1 volume for any application, such as a database.

Using RAID-1 volumes to mirror file systems has advantages and disadvantages:

• With RAID-1 volumes, data can be read from both RAID-0 volumes simultaneously (either volume can service any request), providing improved performance. If one physical disk fails, you can continue to use the mirror with no loss in performance or loss of data.

• Using RAID-1 volumes requires an investment in disks. You need at least twice as much disk space as the amount of data.

• Because Solaris Volume Manager software must write to all RAID-0 volumes, duplicating the data can also increase the time that is required for write requests to be written to disk.

RAID-0 Volumes (Concatenations)

A RAID-0 volume is a single-slice concatenation. The concatenation is a volume whose data is organized serially and adjacently across components, forming one logical storage unit. The custom JumpStart installation method and Solaris Live Upgrade do not enable you to create stripes or other complex Solaris Volume Manager volumes.

During the installation or upgrade, you can create RAID-1 volumes (mirrors) and attach RAID-0 volumes to these mirrors. The RAID-0 volumes that are mirrored are called submirrors. A mirror is made of one or more RAID-0 volumes. After the installation, you can manage the data on separate RAID-0 submirror volumes by administering the RAID-1 mirror volume through the Solaris Volume Manager software.

The custom JumpStart installation method enables you to create a mirror that consists of up to two submirrors. Solaris Live Upgrade enables you to create a mirror that consists of up to three submirrors. Practically, a two-way mirror is usually sufficient. A third submirror enables you to make online backups without losing data redundancy while one submirror is offline for the backup.

Example of RAID-1 Volume Disk Layout

The following figure shows a RAID-1 volume that duplicates the root file system (/) over two physical disks. State database replicas (metadbs) are placed on both disks.

Figure 8–2 RAID-1 Volume Disk Layout

Figure 8–2 shows a system with the following configuration.

• The mirror that is named d30 consists of the submirrors that are named d31 and d32. The mirror, d30, duplicates the data in the root (/) file system on both submirrors.

• The root (/) file system on hdisk0 is included in the single-slice concatenation that is named d31.

• The root (/) file system is copied to the hard disk named hdisk1. This copy is the single-slice concatenation that is named d32.

• State database replicas are created on both slices: hdisk0 and hdisk1.