Logical Volume Manager
The set of operating system commands, library subroutines, and other tools that allow you to establish and control logical volume storage is called the Logical Volume Manager (LVM). The LVM controls disk resources by mapping data between a more simple and flexible logical view of storage space and the actual physical disks.LVM Configuration Data
The data that describes the components of the LVM is not kept in one place. It is important to understand that this descriptive data on volume groups, logical volumes, and physical volumes is kept in several places.1 Object Data Manager (ODM) Database
The ODM database is the place where most of the AIX V3 system configuration data is kept. The ODM database contains information about all configured physical volumes, volume groups, and logical volumes. This information mirrors the information found in the VGDA. For example, the process of importing a VGDA involves copying the VGDA data for the imported volume group into the ODM. When a volume group is exported, the data held in the ODM about that volume group is removed from the ODM database.The ODM data also mirrors the information held in the Logical Volume Control Block.
Volume Group Descriptor Area (VGDA)
The VGDA, located at the beginning of each physical volume, contains information that describes all the logical volumes and all the physical volumes that belong to the volume group of which that physical volume is a member. The VGDA is updated by almost all the LVM commands. The VGDA makes each volume group self-describing. An AIX system can read the VGDA on a disk, and from that, the system can determine what physical volumes and logical volumes are part of this volume group.Each disk contains at least one VGDA. This is important at vary on time. The time stamps in the VGDAs are used to determine which VGDAs correctly reflect the state of the volume group. VGDAs can get out of sync when, for example, a volume group of four disks has one disk failure. The VGDA on that disk cannot be updated while it is not operational. Therefore, you need a way to update this VGDA when the disk comes online, and this is what the vary on process will do.
The VGDA is allocated when the disk is assigned as a physical volume (with the command mkdev). This just reserves a space for the VGDA at the start of the disk. The actual volume group information is placed in the VGDA when the physical volume is assigned to a volume group (using the mkvg or extendvg commands). When a physical volume is removed from the volume group (using the reducevg command), the volume group information is removed from the VGDA.
Volume Group Status Area (VGSA)
The VGSA contains state information about physical partitions and physical volumes. For example, the VGSA knows if one physical volume in a volume group is unavailable.Both the Volume Group Descriptor Area and the Volume Group Status Area have beginning and ending time stamps that are very important. These time stamps enable the LVM to identify the most recent copy of the VGDA and the VGSA at vary on time.
The LVM requires that the time stamps for the chosen VGDA be the same as those for the chosen VGSA.
Logical Volume Control Block (LVCB)
The LVCB is located at the start of every logical volume. It contains information about the logical volume and takes up a few hundred bytes.The following example shows the use of getlvcb command to display the information held in the LVCB of logical volume hd2:
# getlvcb -TA hd2 AIX LVCB intrapolicy = c copies = 1 interpolicy = m lvid = 00011187ca9acd3a.7 lvname = hd2 label = /usr machine id = 111873000 number lps = 72 relocatable = y strict = y type = jfs upperbound = 32 fs = log=/dev/hd8:mount=automatic:type=bootfs:vol=/usr:free=false time created = Tue Jul 27 13:38:45 1993 time modified = Tue Jul 27 10:58:14 1993
Disk Quorum
Each physical disk in a volume group has at least one VGDA/VGSA. The number of VGDAs contained on a single disk varies according to the number of disks in the volume group as shown in the following example:- Single PV in a volume group
- Two VGDAs on one disk.
- Two PVs in a volume group
- Two VGDAs on the first disk, one VGDA on the second disk.
- Three or more PVs in a volume group
- One VGDA on each disk.
When a volume group is created onto a single disk, it initially has two VGDA/VGSA areas residing on the disk. If a volume group consists of two disks, one disk still has two VGDA/VGSA areas, but the other disk has one VGDA/VGSA. When the volume group is made up of three or more disks, then each disk is allocated just one VGDA/VGSA.
The Figure 37 shows that the quorum is lost when enough disks and their VGDA/VGSA areas are unreachable so that a 51% majority of VGDA/VGSA areas no longer exists.
Figure 37: Disk Quorum
When a quorum is lost, the volume group varies itself off so that the disks are no longer accessible by the Logical Volume Manager (LVM). This prevents further disk I/O to that volume group so that data is not lost or assumed to be written when physical problems occur. Additionally, as a result of the vary off, the user is notified in the error log that a hardware error has occurred and service must be performed.
This has implications when you want to use disk mirroring in order to ensure high availability. In a two disk mirrored system, if the first disk fails, then you have lost 66 percent of your VGDAs, and the entire volume group becomes unavailable. This defeats the purpose of mirroring. For this reason, three or more (and generally an odd number) disk units provide a higher degree of availability and are highly recommended where mirroring is desired.
| Note |
|---|
| There is the ability to turn off disk quorum protection on any volume group. Turning off quorum protection allows a volume group to remain online even when a quorum or majority of its VGDAs are not online. This would allow the volume group to remain online in the situation described previously. This capability provides for a less expensive mirroring solution but does carry the risk of data loss as, after a disk failure, data is accessible but no longer mirrored. |
Disk Mirroring
Disk mirroring is the association of two or three physical partitions with each logical partition in a logical volume. When the data is written onto the logical volume, it is also written to all the physical partitions that are associated with the logical partition. Therefore, mirroring of data increases the availability of data.AIX and the logical volume manager provide a disk mirroring facility at a logical volume level. If mirroring is established, this can be done when a logical volume is created.
The mklv command allows you to select one or two additional copies for each logical volume. Mirroring can also be added to an existing logical volume using the mklvcopy command.
The following mirroring factors can further improve the data availability:
- The number of copies of data: Three copies of the data are more reliable than keeping only two copies.
- Location of the copies: Allocating the copies of a logical partition on different physical volumes is more reliable than allocating the copies on the same physical volume. This is because one of the most common error modes for disk subsystems is the loss of an individual physical disk. Copies can also be located across different disk adapters to further enhance isolation from failures.
The mirrorvg Command
The mirrorvg command mirrors all the logical volumes on a given volume group. This same function may also be accomplished manually if you run the mklvcopy command for each individual logical volume in a volume group. As with mklvcopy, the target physical drives to be mirrored with data must already be members of the volume group. This command only applies to AIX Version 4.2.1 or later.The following is the syntax for the mirrovg command:
mirrorvg [ -S | -s ] [ -Q ] [ -c Copies] [ -m ] VolumeGroup [ PhysicalVolume .. ]By default, mirrorvg attempts to mirror the logical volumes onto any of the disks in a volume group. The mirrorvg command mirrors the logical volumes using the default settings of the logical volume being mirrored. If you wish to violate mirror strictness or affect the policy by which the mirror is created, you must execute the mirroring of all logical volumes manually with the mklvcopy command.
| Note |
|---|
| The mirrorvg command may take a significant amount of time before completing because of complex error checking, the number of logical volumes to mirror in a volume group, and the time to synchronize the new mirrored logical volumes. |
The following examples show the use of the mirrorvg command:
- To triply mirror a volume group, run the following command:
mirrorvg -c 3 workvg
The logical partitions in the logical volumes held on workvg now have three copies. - To get default mirroring of rootvg, run the following command.
mirrorvg rootvg
The rootvg volume group now has two copies of data.
Note Problems may occur when you attempt to place a disk back into the original system if the disk is removed from a volume group, updated, and then returned. There is no way to control which copy of the data will be used to resynchronize the other copy.
If any LVM information is changed while the disk is in your backup system, those changes will not be known to your primary system even if the backup is used to resync the primary disk. LVM changes include: Creating, removing, or expanding any file system, paging spaces, and other logical volume. - To replace a failed disk drive in a mirrored volume group, run the
following commands:
unmirrorvg workvg hdisk7 reducevg workvg hdisk7 rmdev -l hdisk7 -d
Replace the failed disk drive with a new one, and name it hdisk7 by executing the following commands:
extendvg workvg hdisk7 mirrorvg workvg
Note By default in this example, mirrorvg will try to create two copies for the logical volumes in workvg. It will try to create the new mirrors onto the replaced disk drive. However, if the original system had been triply mirrored, there may be no new mirrors created onto hdisk7, as other copies may already exist for the logical volumes. - The following command will sync the newly created mirrors:
mirrorvg -S -c 3 workvg
The -c flag specifies the minimum number of copies that each logical volume must have after the mirrorvg command finishes executing. The -S flag returns the mirrorvg command immediately and performs a background syncvg of the volume group. It will not be apparent when the mirrors are synced, but they will be immediately used by the system when ready. - To create an exact mapped volume group, run the following command:
mirrorvg -m datavg hdisk2 hdisk3
The -m flag allows mirroring of logical volumes in the exact physical partition order that the original copy is ordered.
Rootvg Mirroring
When the rootvg mirroring has completed, the following three tasks must be performed.- Run the bosboot command.
- Run the bootlist command.
- Reboot the system.
| Note |
|---|
| Do not reboot the machine if the bosboot command has unsuccessfully created a boot disk. The problem should be resolved and the bosboot command run to successful completion. The bosboot command requires some space in the /tmp file system and the file system where the target image is to reside if there is such an image. |
Non-rootvg Mirroring
When this volume group is mirrored, the quorum gets deactivated. For the deactivation of the quorum to take effect, all open logical volumes must be closed. Then vary off and vary on the volume group for the changes to take effect.If the re-vary on of the volume group is not performed, although the mirroring will work correctly, no quorum changes will have taken effect.
Rootvg and Non-rootvg Mirroring
The system dump devices - primary(/dev/hd6) and secondary (/dev/sysdumpnull) - should not be mirrored. On some systems, the paging device and the dump device are the same device. However, most users want the paging device mirrored. When mirrorvg detects that a dump device and the paging device are the same, the logical volume will be mirrored automatically.If mirrorvg detects that the dump and paging devices are different logical volumes, the paging device is automatically mirrored, but the dump logical volume is not. The dump device can be queried and modified with the sysdumpdev command.
* Source Article from : Internet
