Previous  |  Next  >  
Product: Volume Manager Guides   
Manual: Volume Manager 4.1 Administrator's Guide   

Guidelines for Configuring Storage

The following general guidelines help you understand and plan an efficient storage management system.

Guidelines for Protecting Your System and Data

A disk failure can cause loss of data on the failed disk and loss of access to your system. Loss of access is due to the failure of a key disk used for system operations. VERITAS Volume Manager can protect your system from these problems.

To maintain system availability, data important to running and booting your system must be mirrored. The data must be preserved so it can be used in case of failure.

The following are suggestions for protecting your system and data:

  • Perform regular backups to protect your data. Backups are necessary if all copies of a volume are lost or corrupted. Power surges can damage several (or all) disks on your system. Also, typing a command in error can remove critical files or damage a file system directly. Performing regular backups ensures that lost or corrupted data is available to be retrieved.
  • Place the disk containing the root file system (the root or boot disk) under VERITAS Volume Manager control. Mirror the root disk so that an alternate root disk exists for booting purposes. By mirroring disks critical to booting, you ensure that no single disk failure leaves your system unbootable and unusable. For more information, see Rootability.
  • Use mirroring to protect data against loss from a disk failure. See Mirroring Guidelines for details.
  • Use the DRL feature to speed up recovery of mirrored volumes after a system crash. See Dirty Region Logging (DRL) Guidelines for details.
  • Use striping to improve the I/O performance of volumes. See Striping Guidelines for details.
  • Make sure enough disks are available for a combined striped and mirrored configuration. At least two disks are required for the striped plex, and one or more additional disks are needed for the mirror.
  • When combining striping and mirroring, never place subdisks from one plex on the same physical disk as subdisks from the other plex.
  • Use logging to prevent corruption of recovery data in RAID-5 volumes. Make sure that each RAID-5 volume has at least one log plex. See RAID-5 Guidelines for details.
  • Leave the VERITAS Volume Manager hot-relocation feature enabled. See Hot-Relocation Guidelines for details.

Mirroring Guidelines

Refer to the following guidelines when using mirroring.

  • Do not place subdisks from different plexes of a mirrored volume on the same physical disk. This action compromises the availability benefits of mirroring and degrades performance. Using the vxassist or vxdiskadm commands precludes this from happening.
  • To provide optimum performance improvements through the use of mirroring, at least 70 percent of physical I/O operations should be read operations. A higher percentage of read operations results in even better performance. Mirroring may not provide a performance increase or may even result in performance decrease in a write-intensive workload environment.

  • Note   Note    The operating system implements a file system cache. Read requests can frequently be satisfied from the cache. This can cause the read/write ratio for physical I/O operations through the file system to be biased toward writing (when compared to the read/write ratio at the application level).
  • Where possible, use disks attached to different controllers when mirroring or striping. Most disk controllers support overlapped seeks. This allows seeks to begin on two disks at once. Do not configure two plexes of the same volume on disks that are attached to a controller that does not support overlapped seeks. This is important for older controllers or SCSI disks that do not cache on the drive. It is less important for modern SCSI disks and controllers. Mirroring across controllers allows the system to survive a failure of one of the controllers. Another controller can continue to provide data from a mirror.
  • A plex exhibits superior performance when striped or concatenated across multiple disks, or when located on a much faster device. Set the read policy to prefer the faster plex. By default, a volume with one striped plex is configured to prefer reading from the striped plex.

For more information, see Mirroring (RAID-1).

Dirty Region Logging (DRL) Guidelines

Dirty Region Logging (DRL) can speed up recovery of mirrored volumes following a system crash. When DRL is enabled, VERITAS Volume Manager keeps track of the regions within a volume that have changed as a result of writes to a plex.


Note   Note    Using Dirty Region Logging can impact system performance in a write-intensive environment.

For more information, see Dirty Region Logging (DRL).

Striping Guidelines

Refer to the following guidelines when using striping.

  • Do not place more than one column of a striped plex on the same physical disk.
  • Calculate stripe-unit sizes carefully. In general, a moderate stripe-unit size (for example, 64 kilobytes, which is also the default used by vxassist) is recommended.
  • If it is not feasible to set the stripe-unit size to the track size, and you do not know the application I/O pattern, use the default stripe-unit size.

  • Note   Note    Many modern disk drives have variable geometry. This means that the track size differs between cylinders, so that outer disk tracks have more sectors than inner tracks. It is therefore not always appropriate to use the track size as the stripe-unit size. For these drives, use a moderate stripe-unit size (such as 64 kilobytes), unless you know the I/O pattern of the application.
  • Volumes with small stripe-unit sizes can exhibit poor sequential I/O latency if the disks do not have synchronized spindles. Generally, striping over disks without synchronized spindles yields better performance when used with larger stripe-unit sizes and multi-threaded, or largely asynchronous, random I/O streams.
  • Typically, the greater the number of physical disks in the stripe, the greater the improvement in I/O performance; however, this reduces the effective mean time between failures of the volume. If this is an issue, combine striping with mirroring to combine high-performance with improved reliability.
  • If only one plex of a mirrored volume is striped, set the policy of the volume to prefer for the striped plex. (The default read policy, select, does this automatically.)
  • If more than one plex of a mirrored volume is striped, configure the same stripe-unit size for each striped plex.
  • Where possible, distribute the subdisks of a striped volume across drives connected to different controllers and buses.
  • Avoid the use of controllers that do not support overlapped seeks. (Such controllers are rare.)

The vxassist command automatically applies and enforces many of these rules when it allocates space for striped plexes in a volume.

For more information, see Striping (RAID-0).

RAID-5 Guidelines

Refer to the following guidelines when using RAID-5.

In general, the guidelines for mirroring and striping together also apply to RAID-5. The following guidelines should also be observed with RAID-5:

  • Only one RAID-5 plex can exist per RAID-5 volume (but there can be multiple log plexes).
  • The RAID-5 plex must be derived from at least three subdisks on three or more physical disks. If any log plexes exist, they must belong to disks other than those used for the RAID-5 plex.
  • RAID-5 logs can be mirrored and striped.
  • If the volume length is not explicitly specified, it is set to the length of any RAID-5 plex associated with the volume; otherwise, it is set to zero. If you specify the volume length, it must be a multiple of the stripe-unit size of the associated RAID-5 plex, if any.
  • If the log length is not explicitly specified, it is set to the length of the smallest RAID-5 log plex that is associated, if any. If no RAID-5 log plexes are associated, it is set to zero.
  • Sparse RAID-5 log plexes are not valid.
  • RAID-5 volumes are not supported for sharing in a cluster.

For more information, see RAID-5 (Striping with Parity).

Hot-Relocation Guidelines

Hot-relocation automatically restores redundancy and access to mirrored and RAID-5 volumes when a disk fails. This is done by relocating the affected subdisks to disks designated as spares and/or free space in the same disk group.

The hot-relocation feature is enabled by default. The associated daemon, vxrelocd, is automatically started during system startup.

Refer to the following guidelines when using hot-relocation.

  • The hot-relocation feature is enabled by default. Although it is possible to disable hot-relocation, it is advisable to leave it enabled. It will notify you of the nature of the failure, attempt to relocate any affected subdisks that are redundant, and initiate recovery procedures.
  • Although hot-relocation does not require you to designate disks as spares, designate at least one disk as a spare within each disk group. This gives you some control over which disks are used for relocation. If no spares exist, VERITAS Volume Manager uses any available free space within the disk group. When free space is used for relocation purposes, it is possible to have performance degradation after the relocation.
  • After hot-relocation occurs, designate one or more additional disks as spares to augment the spare space. Some of the original spare space may be occupied by relocated subdisks.
  • If a given disk group spans multiple controllers and has more than one spare disk, set up the spare disks on different controllers (in case one of the controllers fails).
  • For a mirrored volume, configure the disk group so that there is at least one disk that does not already contain a mirror of the volume. This disk should either be a spare disk with some available space or a regular disk with some free space and the disk is not excluded from hot-relocation use.
  • For a mirrored and striped volume, configure the disk group so that at least one disk does not already contain one of the mirrors of the volume or another subdisk in the striped plex. This disk should either be a spare disk with some available space or a regular disk with some free space and the disk is not excluded from hot-relocation use.
  • For a RAID-5 volume, configure the disk group so that at least one disk does not already contain the RAID-5 plex (or one of its log plexes) of the volume. This disk should either be a spare disk with some available space or a regular disk with some free space and the disk is not excluded from hot-relocation use.
  • If a mirrored volume has a DRL log subdisk as part of its data plex, you cannot relocate the data plex. Instead, place log subdisks in log plexes that contain no data.
  • Hot-relocation does not guarantee to preserve the original performance characteristics or data layout. Examine the locations of newly-relocated subdisks to determine whether they should be relocated to more suitable disks to regain the original performance benefits.
  • Although it is possible to build VERITAS Volume Manager objects on spare disks (using vxmake or the VEA interface), it is recommended that you use spare disks for hot-relocation only.

See Administering Hot-Relocation for more information.

Accessing Volume Devices

As soon as a volume has been created and initialized, it is available for use as a virtual disk partition by the operating system for the creation of a file system, or by application programs such as relational databases and other data management software.

Creating a volume in a disk group sets up block and character (raw) device files that can be used to access the volume:

/dev/vx/dsk/diskgroup/volume block device file for volume
/dev/vx/rdsk/diskgroup/volume character device file for volume

The pathnames include a directory named for the disk group. Use the appropriate device node to create, mount and repair file systems, and to lay out databases that require raw partitions.

 ^ Return to Top Previous  |  Next  >  
Product: Volume Manager Guides  
Manual: Volume Manager 4.1 Administrator's Guide  
VERITAS Software Corporation
www.veritas.com