Planning for Availability

This section describes LVM features that can improve the availability and redundancy of your data. It addresses the following topics:

Increasing Data Availability Through Mirroring




	NOTE: Mirroring requires an optional product, HP MirrorDisk/UX.

Mirroring means storing identical copies of data in logical volumes, preferably on separate disks. This redundancy has several advantages:

If you mirror the root file system and swap, the operating system can tolerate a root disk failure because critical data is available on more than one LVM disk.
If you mirror the logical volumes used by a particular application, the application continues to run even if a disk fails.
If an I/O channel fails, LVM can recover the data from the duplicate source.
Mirroring speeds read-intensive applications by enabling the hardware to read data from the most convenient LVM disk.
You can back up one copy of the data while another copy continues to run.

Mirroring maps one logical extent to two or more sets of physical extents. The number of logical extents remains constant, but the number of used physical extents (and therefore, occupied disk space) changes depending on the number of mirrored copies. Mirroring increases data protection and system availability, but consumes twice as much disk space (or as many times more as there are mirror copies), so use disk mirroring for volatile, mission-critical data only.

Mirrored logical volumes must belong to the same volume group; you cannot mirror across volume groups.

This section contains the following information:

To learn more about basic mirroring tasks, see Disk and File Management Tasks on HP-UX published by Prentice Hall PTR, 1997.

Mirror Write Behavior Control

Three policies govern how mirrored logical extents are written to physical extents: the allocation policy, the scheduling policy for disk writes, and the synchronization policy for crash recovery. These policies can be set using HP SMH, the lvcreate command, or the lvchange command.

Allocation Policy

Mirrored extents can be allocated on physical volumes by strict or nonstrict, contiguous or noncontiguous policies. By default, the allocation policy of mirrored logical volumes is set to strict, noncontiguous.

Strict and Nonstrict Allocation

Strict allocation requires logical extents to be mirrored to physical extents on different physical volumes. Nonstrict allocation allows logical extents to be mirrored to physical extents that may be on the same physical volume. The -s y and -s n options to the lvcreate or lvchange commands set strict or nonstrict allocation.




	CAUTION: Using nonstrict allocation can reduce the redundancy created by LVM mirroring because a logical extent can be mirrored to different physical extents on the same disk. Therefore, the failure of this one disk makes both copies of the data unavailable.

Contiguous and Noncontiguous Allocation

Contiguous allocation has three characteristics: the physical extents are allocated in ascending order, no gap exists between physical extents within a mirror copy, and all physical extents of a mirror copy reside on a single physical volume. Noncontiguous allocation allows logical extents to be mapped to nonconsecutive physical extents. The -C y and -C n options to the lvcreate or lvchange commands set contiguous or noncontiguous allocation.




	NOTE: When the logical volumes allocated from the root volume group are mirrored, each must be set up with contiguous allocation.

Scheduling Policy

The LVM scheduler converts logical I/O requests into one or more physical I/O requests, then schedules them for processing at the hardware level. Scheduling occurs for both mirrored and nonmirrored data.

Two I/O scheduling policies are available: parallel and sequential.

Parallel Scheduling

The parallel scheduling policy is used by default with mirroring for maximum I/O performance. Parallel scheduling causes mirror operations to write simultaneously to all copies. LVM optimizes reads by reading from the physical volume with the fewest outstanding I/O operations. The -d p option to the lvcreate or lvchange command sets the scheduling policy to parallel for a logical volume.

Sequential Scheduling

The sequential scheduling policy causes mirror write operations to proceed sequentially; that is, LVM waits for one mirror write to complete before it begins the next mirror write. Likewise, LVM mirrors are read in a predefined order. On a practical level, sequential policy is used only for extreme caution in maintaining consistency of mirrors. The -d s option to the lvcreate or lvchange command sets the scheduling policy to sequential for a logical volume.

Synchronization Policy

You can maintain consistency of mirrored data by enabling or disabling two features of your logical volume: the Mirror Write Cache and Mirror Consistency Recovery.

Synchronization Using Mirror Write Cache

The Mirror Write Cache (MWC) provides a fast resynchronization of data following a system crash or failure, but at a potential performance cost for routine system use.

The MWC keeps track of where I/O writes are occurring on the volume group, and periodically records this activity in an ondisk data structure. An extra disk write is required for every mirrored write not already recorded on the physical volume. This slows down runtime I/O write processing and degrades performance when you access the disk at random; when writing to an area of the disk that is already recorded, the performance is not impaired. Upon system reboot after crash, the operating system uses the MWC to resynchronize inconsistent data blocks quickly.

The frequency of extra disk writes is small for sequentially accessed logical volumes (such as database logs), but increases when access is more random. Therefore, logical volumes containing database data or file systems with few or infrequently written large files (greater than 256K) must not use the MWC when runtime performance is more important than crash recovery time.

The -M option to the lvcreate or lvchange command controls the MWC.

Synchronization Using Mirror Consistency Recovery

When the Mirror Consistency Recovery is enabled, LVM does not impact runtime I/O performance. However, following a system crash, for any logical volumes using Mirror Consistency Recovery, the entire data space resynchronizes when you activate the volume group. Synchronization can be performed in the background without interfering with reboot or access; however, during this time I/O performance and redundancy are degraded.

Synchronization with No Mirror Consistency Mechanism

When Mirror Consistency Recovery is disabled, the operating system's runtime behavior is identical to that of the previous approach. However, following a crash, LVM does not perform any resynchronization of data. This approach is useful for swap volumes and for volumes used by an application (such as a database) with its own means of maintaining or recovering consistent data, such as transaction log files. However, database log files themselves can be configured as a mirrored logical volume to use the MWC.

The -c option to the lvcreate or lvchange command controls the use of the Mirror Consistency Recovery.

Synchronizing a Mirrored Logical Volume

The data in a mirrored copy or copies of a logical volume can become out of sync, or “stale.” For example, mirrored data becomes stale if LVM cannot access a disk as a result of disk power failure. Under such circumstances, for each mirrored copy to re-establish identical data, synchronization must occur. Usually, synchronization occurs automatically, but sometimes it must be done manually.

Automatic Synchronization

If you activate a volume group that is not currently active, either automatically at boot time or later with the vgchange command, then LVM automatically synchronizes the mirrored copies of all logical volumes with the Mirror Consistency Recovery policy enabled. It replaces data in physical extents marked as stale with data from nonstale extents. Otherwise, no automatic synchronization occurs and manual synchronization is necessary.

LVM also automatically synchronizes mirrored data in the following cases:

When you increase the number of mirror copies of a logical volume using the –m option of lvmerge, the newly added physical extents are synchronized.
When a disk comes back online after experiencing a power failure.

Manual Synchronization

If you look at the status of a logical volume using lvdisplay -v, you can verify if the logical volume contains any stale data. You can then identify which disk contains the stale physical extents. Manually synchronize the data in one or more logical volumes using either the lvsync command or all logical volumes in one or more volume groups using the vgsync command. For more information, see lvdisplay(1M), vgsync(1M), and lvsync(1M).

Parallel Synchronization

By default, the lvsync command synchronizes logical volumes serially. In other words, it acts on the logical volumes specified on the command line one at a time, waiting until a volume finishes synchronization before starting the next. Starting with the September 2007 release of HP-UX 11i Version 3, you can use the –T option to synchronize logical volumes in parallel. With the –T option, lvsync spawns multiple threads to simultaneously synchronize all logical volumes belonging to the same volume group, often reducing the total synchronization time.




	TIP: The vgchange, lvmerge, and lvextend commands support the `–s` option to suppress the automatic synchronization of stale extents. If you are performing multiple mirror-related tasks, you can suppress the extent synchronization until you have finished all the tasks, then run lvsync with `–T` to synchronize all the mirrored volumes in parallel. For example, you can use vgchange -s with lvsync -T to reduce the activation time for volume groups with mirrored logical volumes. For another example, see “Mirroring the Boot Disk”.

Increasing Disk Redundancy Through Disk Sparing




	NOTE: Version 2.x volume groups do not support disk sparing. Disk sparing requires the optional product HP MirrorDisk/UX. MirrorDisk/UX is not available for shared LVM environments within a high availability cluster across more than two nodes. You cannot configure sparing within these environments. In such cases, HP recommends that you use hardware mirroring through RAID devices, which can support their own form of sparing.

If a disk containing mirrored data fails, replace the disk as soon as possible, as described in “Replacing a Bad Disk”. Before you replace the disk, the data in your logical volume does not have an extra mirrored copy unless you have set up more than one mirror copy. Even with multi–way mirroring, your level of security is reduced because of the loss of one mirror copy.

To prevent this possibility, you can use one or more spare disks within each of your volume groups to serve as substitute devices in the event of disk failure. With this configuration, LVM automatically reconfigures the volume group so that the spare physical volume takes the place of a failed device without any intervention required. That is, a copy of the data from all the logical volumes currently on the failed disk is created on the substitute physical volume. This process is referred to as automatic sparing, or sparing. Sparing occurs while the logical volume remains available to users. You can then schedule the replacement of the failed disk at a time of minimal inconvenience to you and your users. At that time, you copy the data from the spare disk back to the original disk or its replacement and return the spare disk to its role as a standby empty disk.

For sparing to occur, the following conditions must be met:

All logical volumes in the volume group must have been configured with strict mirroring so that mirrored copies are maintained on separate disks because LVM copies the data onto the spare from an undamaged disk rather than from the defective disk itself.
At least one physical volume must be available as a standby spare; if your last spare is already in use as a result of a prior disk failure, it cannot serve as a currently available spare.
The available spare must be at least as large as the failed disk.

The spare physical volume disk space is not available for extent allocation for any other purpose than in the event of serving as a substitute disk in the event of disk failure. Therefore, its physical extents are not included in the counts shown under total PE or free PE in the output of the pvdisplay and vgdisplay commands.




	NOTE: If it is important to maintain comparable performance in the event of disk failure, configure a spare physical volume to each bus. However, if more than one disk on the same bus fails, even with this strategy, performance will be impacted.

The pvdisplay and vgdisplay commands provide information on whether a given physical volume is an empty standby spare or currently holding data as a spare in use, along with information on any physical volume that is currently unavailable but had data spared.

Increasing Hardware Path Redundancy Through Multipathing

Your hardware might provide the capability for dual cabling (dual controllers) to the same physical volume. If so, LVM can be configured with multiple paths to the same physical volume. If the primary link fails, an automatic switch to an alternate link occurs. Using multipathing increases availability.




	NOTE: As of HP-UX 11i Version 3, the mass storage stack supports native multipathing without using LVM pvlinks. Native multipathing provides more load balancing algorithms and path management options than LVM. HP recommends using native multipathing to manage multipathed devices instead of using LVM's alternate links. For backward compatibility, you can use existing pvlinks. However, you must use legacy device special files for physical volumes and disable native multipathing for those legacy device special files using the scsimgr command. For more information, see the white paper LVM Migration from Legacy to Agile Naming Model, available at http://docs.hp.com.

Setting Up Multipathing to a Physical Volume

To use an alternate link, you can create a volume group with vgcreate, specifying both the primary link and the alternate link device file names. Both links must represent paths to the same physical volume. (Do not run pvcreate on the alternate link; it must already be the same physical volume as the primary link.) When you indicate two device file names, both referring to the same disk using vgcreate, LVM configures the first one as the primary link and the second one as the alternate link.

For example, if a disk has two cables and you want to make one the primary link and the other an alternate link, enter the following command:

# vgcreate /dev/vg01 /dev/dsk/c3t0d0 /dev/dsk/c5t0d0

To add an alternate link to a physical volume that is already part of a volume group, use vgextend to indicate the new link to the physical volume. For example, if /dev/dsk/c2t0d0 is already part of your volume group but you want to add another connection to the physical volume, enter the following command:

# vgextend /dev/vg02 /dev/dsk/c4t0d0

If the primary link fails, LVM automatically switches from the primary controller to the alternate controller. However, you can also tell LVM to switch to a different controller at any time using the pvchange command. For example:

# pvchange -s /dev/dsk/c2t1d0

After the primary link has recovered, LVM automatically switches back from the alternate controller to the original controller unless you previously instructed it not to by using pvchange as follows:

# pvchange -S n /dev/dsk/c2t2d0




	NOTE: You can also disable the automatic switchback by using the `-p` option to pvchange to disable proactive polling. For more information, see pvchange(1M).

View the current links to a physical volume using vgdisplay with the -v option.