|
|
United States-English | |
|
|
 |
|
VERITAS Volume Manager 3.1 Administrator's Guide: for HP-UX 11i and HP-UX 11i Version 1.5 > Chapter 3 Volume Manager Operations
Hot-Relocation |
|
|
Hot-relocation allows a system to automatically react to I/O failures on redundant (mirrored or RAID-5) Volume Manager objects and restore redundancy and access to those objects. The Volume Manager detects I/O failures on objects and relocates the affected subdisks. The subdisks are relocated to disks designated as spare disks and/or free space within the disk group. The Volume Manager then reconstructs the objects that existed before the failure and makes them redundant and accessible again. When a partial disk failure occurs (that is, a failure affecting only some subdisks on a disk), redundant data on the failed portion of the disk is relocated. Existing volumes on the unaffected portions of the disk remain accessible.
The hot-relocation feature is enabled by default. No system administrator action is needed to start hot-relocation when a failure occurs. The hot-relocation daemon, vxrelocd, monitors Volume Manager for events that affect redundancy and performs hot-relocation to restore redundancy. The vxrelocd daemon also notifies the system administrator (via electronic mail) of failures and any relocation and recovery actions. See the vxrelocd(1M) manual page for more information on vxrelocd. The vxrelocd daemon starts during system startup and monitors the Volume Manager for failures involving disks, plexes, or RAID-5 subdisks. When a failure occurs, it triggers a hot-relocation attempt. A successful hot-relocation process involves:
A spare disk must be initialized and placed in a disk group as a spare before it can be used for replacement purposes. If no disks have been designated as spares when a failure occurs, Volume Manager automatically uses any available free space in the disk group in which the failure occurs. If there is not enough spare disk space, a combination of spare space and free space is used. The free space mentioned in hot-relocation is always the free space not excluded from hot-relocation use. Disks can be excluded from hot-relocation use by using the Storage Administrator interface: vxdiskadm or vxedit. The system administrator can designate one or more disks as hot-relocation spares within each disk group. Disks can be designated as spares by using the Storage Administrator interface, vxdiskadm, or vxedit. Disks designated as spares do not participate in the free space model and should not have storage space allocated on them. When selecting space for relocation, hot-relocation preserves the redundancy characteristics of the Volume Manager object that the relocated subdisk belongs to. For example, hot-relocation ensures that subdisks from a failed plex are not relocated to a disk containing a mirror of the failed plex. If redundancy cannot be preserved using any available spare disks and/or free space, hot-relocation does not take place. If relocation is not possible, the system administrator is notified and no further action is taken. From the eligible disks, hot-relocation attempts to use the disk that is "closest" to the failed disk. The value of "closeness" depends on the controller, target, and disk number of the failed disk. A disk on the same controller as the failed disk is closer than a disk on a different controller; a disk under the same target as the failed disk is closer than one on a different target. Hot-relocation tries to move all subdisks from a failing drive to the same destination disk, if possible. When hot-relocation takes place, the failed subdisk is removed from the configuration database and Volume Manager ensures that the disk space used by the failed subdisk is not recycled as free space. For information on hot-relocation, see Chapter 4 “Disk Tasks” Hot-relocation is turned on as long as the vxrelocd procedure is running. Leave hot-relocation turned on so that you can take advantage of this feature if a failure occurs. Disabling this feature (because you do not want the free space on some of your disks used for relocation) prevents the vxrelocd procedure from starting at system startup time. You can stop hot-relocation at any time by killing the vxrelocd process (this should not be done while a hot-relocation attempt is in progress). See “vxrelocd Command” for more information. VxVM hot-relocation allows the system to automatically react to I/O failures on a redundant VxVM object at the subdisk level and take necessary action to make the object available again. This mechanism detects I/O failures in a subdisk, relocates the subdisk, and recovers the plex associated with the subdisk. After the disk has been replaced, Volume Manager provides the vxunreloc utility, which can be used to restore the system to the same configuration that existed before the disk failure. The vxunreloc utility allows you to move the hot-relocated subdisks back onto a disk that was replaced due to a disk failure. When the vxunreloc utility is invoked, you must specify the disk media name where the hot-relocated subdisks originally resided so that when vxunreloc moves the subdisks, it moves them to the original offsets. If you try to unrelocate to a disk that is smaller than the original disk that failed, the vxunreloc utility does nothing except return an error. The vxunreloc program provides an option to move the subdisks to a different disk from where they were originally relocated. It also provides an option to unrelocate subdisks to a different offsets if the destination disk is large enough to accommodate all of the subdisks. If the vxunreloc utility cannot replace the subdisks back to the same original offsets, a force option is available that allows you to move the subdisks to a specified disk without using the original offsets. See the vxunreloc(1M) manual page for more information. The following examples demonstrate the use of the vxunreloc program. Assume that disk01 failed and all the subdisks were relocated. After disk01 is replaced, use vxunreloc to move all the hot-relocated subdisks back to disk01, as follows:
The vxunreloc utility provides the -n option to move the subdisks to a different disk from where they were originally relocated. Assume that disk01 failed, and that all of the subdisks that resided on it were hot-relocated to other disks. After the disk is repaired, it is added back to the disk group using a different name, e.g, disk05. If you want to move all the hot-relocated subdisks back to the new disk, use the following command:
Assume that disk01 failed and the subdisks were relocated and that you want to move the hot-relocated subdisks to disk05 where some subdisks already reside. Use the force option to move the hot-relocated subdisks to disk05, but not to the exact offsets:
If a subdisk was hot-relocated more than once due to multiple disk failures, it can still be unrelocated back to its original location. For instance, if disk01 failed and a subdisk named disk01-01 was moved to disk02, and then disk02 experienced disk failure, all of the subdisks residing on it, including the one which was hot-relocated to it, will be moved again. When disk02 is replaced, a vxunreloc operation for disk02 does nothing to the hot-relocated subdisk disk01-01. However, a replacement of disk01, followed by a vxunreloc operation, moves disk01-01 back to disk01 if the vxunreloc utility is run immediately after the replacement. After the disk that experienced the failure is fixed or replaced, the vxunreloc program can be used to move all the hot-relocated subdisks back to the disk. When a subdisk is hot-relocated, its original disk media name and the offset into the disk, are saved in the configuration database. When a subdisk is moved back to the original disk or to a new disk using the vxunreloc utility, the information is erased. The original dm name and the original offset are saved in the subdisk records. To print all of the subdisks that were hot-relocated from disk01 in the rootdg disk group, use the following command:
To move all the subdisks that were hot-relocated from disk01 back to the original disk, use the following command:
The vxunreloc utility provides -n option to move the subdisks to a different disk from where they were originally relocated. For example, when disk01 failed, all the subdisks that resided on it were hot-relocated to other disks. After the disk is repaired, it is added back to the disk group using a different name, for example, disk05. To move all the hot-relocated subdisks to the new disk, use the following command:
The destination disk should have at least as much storage capacity as was in use on the original disk. If there is not enough space, the unrelocate operation will fail and none of the subdisks will be moved. When the vxunreloc program moves the hot-relocated subdisks, it moves them to the original offsets. However, if there some subdisks existed which occupied part or all of the area on the destination disk, the vxunreloc utility will fail. If failure occurs, you have two choices: (1) move the existing subdisks somewhere else, and then re-run the vxunreloc utility, or (2) use the -f option provided by the vxunreloc program to move the subdisks to the destination disk, but allow the vxunreloc utility to find the space on the disk. As long as the destination disk is large enough so that the region of the disk for storing subdisks can accommodate all subdisks, all the hot-relocated subdisks will be "unrelocated" without using the original offsets. A subdisk that was hot-relocated more than once due to multiple disk failures will still be able to be unrelocated back to its original location. For instance, if disk01 failed and a subdisk named disk01-01 was moved to disk02,and then disk02 experienced disk failure, all the subdisks residing on it, including the one which was hot-relocated to it, will be moved again. When disk02 is replaced, an unrelocate operation for disk02 will not do anything to the hot-relocated subdisk disk01-01. However, a replacement of disk01 followed by the unrelocate operation moves disk01-01 back to disk01 when the vxunreloc program is run, immediately after the replacement. Internally, the vxunreloc program moves the subdisks in three phases.The first phase is creates as many subdisks on the specified destination disk as there are the number of the subdisks to be unrelocated. When the subdisks are made, the vxunreloc program fills in the comment field in the subdisk record with the string UNRELOC as an identification. The second phase is the actual data moving. If all the subdisk moves are successful, the third phase proceeds to clean up the comment field of the subdisk records. Making the subdisk is a all-or-none operation. If the vxunreloc program cannot make all the subdisks successfully, no subdisk is made and the vxunreloc program exits. The operation of the subdisks move is not all-or-none. One subdisk move is independent of another, and as a result, if one subdisk move fails, the vxunreloc utility prints an error message and then exits. But, all of the subsequent subdisks remain on the disk where they were hot-relocated and will not be moved back. For subdisks that made their way back home, the comment field in their subdisk records is still marked as UNRELOC because the cleanup phase is never executed. If the system goes down after the new subdisks are made on the destination, but before they are moved back, the vxunreloc program can be executed again after the system comes back. As described above, when a new subdisk is created, the vxunreloc program sets the comment field of the subdisk as UNRELOC. When the vxunreloc utility is re-executed, it checks the offset, the len, and the comment fields of the existing subdisks on the destination disk to determine if it was left on the disk at a previous execution of the vxunreloc program, which then uses it as it sees fit. Do not manually modify the string UNRELOC in the comment field. If one out of a series of subdisk moves fails, the vxunreloc program exits. Under this circumstance, you should check the error that caused the subdisk move to fail and determine if the unrelocation can proceed. When you re-execute the vxunreloc utility to resume the subdisk moves, it uses the subdisks created at a previous run. The cleanup phase is done with one transaction. The vxunreloc program resets the comment field to a NULL string for all the subdisks marked as UNRELOC that reside on the destination disk. This includes clean up for those subdisks that were unrelocated in any previous invocation of the vxunreloc program, that was not successfully completed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
