JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 10 1/13 Installation Guide: Planning for Installation and Upgrade     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information


Part I Overall Planning of an Oracle Solaris Installation or Upgrade

1.  Where to Find Oracle Solaris Installation Planning Information

2.  Oracle Solaris Installation and Upgrade Roadmap

3.  System Requirements, Guidelines, and Upgrade Information

4.  Gathering Information Before an Installation or Upgrade

Part II Understanding Installations Related to ZFS, Booting, Oracle Solaris Zones, and RAID-1 Volumes

5.  ZFS Root File System Installation Planning

6.  SPARC and x86 Based Booting (Overview and Planning)

7.  Upgrading When Oracle Solaris Zones Are Installed on a System

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

Why Use RAID-1 Volumes?

How Do RAID-1 Volumes Work?

Overview of Solaris Volume Manager Components

State Database and State Database Replicas

RAID-1 Volumes (Mirrors)

RAID-0 Volumes (Concatenations)

Example of RAID-1 Volume Disk Layout

9.  Creating RAID-1 Volumes (Mirrors) During Installation (Planning)



Overview of Solaris Volume Manager Components

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

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 MB (8192 disk sectors) of disk storage by default. Replicas can be stored on the following devices:

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, this setup could make the system more vulnerable to a single point of failure.

For more detailed information about the state database and state database replicas, see Solaris Volume Manager Administration Guide.

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 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.

For information about planning for RAID-1 volumes, see RAID-1 and RAID-0 Volume Requirements and Guidelines.

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 JumpStart installation method and 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 JumpStart installation method enables you to create a mirror that consists of up to two submirrors. Live Upgrade enables you to create a mirror that consists of up to three submirrors, although 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.

For information about planning for RAID-1 volumes, see RAID-1 and RAID-0 Volume Requirements and Guidelines.