Solaris 10 Administration: Explination about RAID levels in solaris 10

        Describing RAID and Solaris™ Volume Manager Software
The Solaris Volume Manager software can be run from the command line or a graphical user interface (GUI) tool to simplify system administration tasks on storage devices.

The Solaris Volume Manager software lets you manage large numbers of disks and the data on those disks.

Logical Volume

The Solaris Volume Manager software uses virtual disks called logical volumes to manage physical disks and their associated data.
Historically, a logical volume is functionally identical to a physical slice.
However, a logical volume can span multiple disk members.
The Solaris Volume Manager software converts I/O requests directed at a volume into I/O requests to the underlying member disks.

You can create the Solaris Volume Manager software volumes from slices (disk partitions)

To create more storage capacity as a single volume, you can use the Solaris
Volume Manager software to make the system treat a collection of many small slices as one large slice or device.
After creating a large volume from these slices, you can immediately begin by using it just as any other slice or device.

Note – In earlier versions of the Solaris OS, the Solaris Volume Manager
software was known as Solstice DiskSuite™ software, and logical volumes were known as metadevices. Most of the associated command-line tools begin with the preﬁx meta. Logical devices are located under the /dev/md directory.

The State Database

Before creating volumes, state database replicas must exist on the Solaris Volume Manager software system.

The state database stores information on disk about the state of the Solaris Volume Manager software conﬁguration.

The state database records and tracks changes made to your conﬁguration.

The Solaris Volume Manager software automatically updates the state database when a conﬁguration or state change occurs.

For example, creating a new volume is a conﬁguration change, while failure of a submirror is a state change.

The state database is a collection of multiple, replicated database copies.

Each copy (called a state database replica) ensures that the data in the
database is always valid.

The state database tracks the location and status of all known state database replicas.

During a state database update, each replica state database is updated.

The updates take place one at a time to protect against corrupting all updates if the system crashes.

If a system loses a state database replica, Solaris Volume Manager must determine which state database replicas still contain non-corrupted data.

It determines this information by a majority consensus algorithm.

This algorithm requires that a majority (half + 1) of the state database replicas be available and in agreement with each other before any of them are
considered non-corrupt.

Because of the majority consensus algorithm, you should create at least 3 state database replicas when you set up your disk conﬁguration.

A consensus can be reached as long as at least two of the three state database replicas are available.

If a state database replica becomes corrupt because its underlying slice encountered an error, you must repair or replace the slice, and then recreate the replica.

If all state database replicas are lost, you could lose all data that is stored on your Solaris Volume Manager software volumes.

You should create enough state database replicas on separate drives and across controllers to prevent complete data loss.

Recommendations for State Database Replicas

To avoid single points-of-failure, you should distribute state database replicas across slices, drives, and controllers.

A majority of replicas must survive a single component failure.

When working with state database replicas, consider the following:

You should create state database replicas on a dedicated slice of at
least 4 Mbytes per replica.

You can put replicas on unused slices, and then use them on RAID-0,
RAID 1, or RAID 5 volumes.

You cannot create state database replicas on any slices in use.

A minimum of 3 state database replicas are recommended.

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 ﬁve or more drives: put one replica on each
        drive.

Make sure that you have at least two extra replicas per mirror.

You can add additional state database replicas to the system at any
time. The additional state database replicas help to ensure the Solaris
Volume Manager software’s availability.

Hot spares and hot spare pools provide additional physical slices for automatic recovery from RAID 1 mirror or RAID 5 volume failures.

Hot Spares

A hot spare is a slice (not a volume) that is functional and available, but
not in use.

A hot spare is on reserve to substitute for a failed slice in a submirror or RAID 5 volume.

A hot spare must be ready for immediate use in the event of a slice failure in the volume with which it is associated.

Hot Spare Pools

A hot spare pool is a collection of slices.

Note – Hot spares do not apply to RAID 0 volumes or to one-way mirrors.
For automatic substitution to work, redundant data must be available.