Topics:
Maintaining Data Consistency
Hot Relocation
Managing Spare Disks
Replacing a Disk
Unrelocating a Disk
Recovering a Volume
Protecting the VxVM Configuration
Accessing the Technical Support Website
Atomic-copy resynchronization involves the sequential writing of all blocks of a volume to a plex.
This type of resynchronization is used in:
Adding a new plex (mirror)
Reattaching a detached plex (mirror) to a volume
Online reconfiguration operations:
- Moving a plex
- Copying a plex
- Creating a snapshot
- Moving a subdisk
Read-writeback resynchronization is used for volumes that were fully mirrored prior to a system failure.
In this type of resynchronization:
- Mirrors marked ACTIVE remain ACTIVE, and volume is placed in the SYNC state
- An internal read thread is started. Blocks are read from the plex specified in the read policy, and the data is written to the other plexes.
- Upon completion, the SYNC flag is turned off
Impact of Resynchronization
Resynchronization takes time and impacts performance.
To minimize this performance impact, VxVM provides the following solutions:
- Dirty region logging (DRL) for mirrored volumes
- RAID-5 logging for RAID-5 volumes
- FastResync for mirrored and snapshot columes
Dirty Region Logging
For mirrored volumes with logging enabled, DRL speeds plex resynchronization. Only regions that are dirty (different from the primary) need to be resynchronized after a crash.
VxVM selects an appropriate log size based on volume size
If you resize a volume, the log size does not change. To resize the log, you must delete the log and add it back after resizing the volume.
RAID-5 Logging
- For RAID-5 volumes, logging helps to prevent data corruption during recovery
- RAID-5 logging records changes to data and parity on a persistent device (log disk) before committing the changes to the RAID-5 volume.
- Logs are associated with a RAID-5 volume by being attached as log plexes.
Hot Relocation
Hot relocation is a feature of VxVM that enables a system to automatically react to I/O failures on redundant (mirrored or RAID-5) VxVM objects and restore redundancy and access to those objects. VxVM detects I/O failures on objects and relocates the affected subdisks. The subdisks are relocated to disks designed as spare disks or to free space within the disk group. VxVM then reconstructs the objects that existed before the failure and makes them redundant and accessible again.
How is Space Selected?
- Hot relocation attempts to move all subdisks from a failing drive to a single spare destination disk
- If no disks have been designated as spares, VxVM 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 disk space and free space is used.
- Free space that you exclude from hot relocation is not used.
Managing Spare Disks
VEA:
Actions -> Set Disk Usage
vxdiskadm:
- “Mark a disk as a spare for a disk group”
- “Turn off the spare flag on a disk”
- “Exclude a disk from hot-relocation use”
- “Make a disk available for hot-relocation use”
CLI:
To designate a disk as a spare:
vxedit –g diskgroup set spare=onoff diskname
To exclude/include a disk for hot relocation:
vxedit –g diskgroup set nohotuse=onoff diskname
To force hot relocation to only use spare disks:
Add spare=only to /etc/default/vxassist
Disk Replacement Tasks
1) Replace the failed/failing disk
2) Logical Replacement
- Replace the disk in VxVM
- Start disabled volumes
- Resynchronize mirrors
- Resynchronize RAID-5 parity
Adding a New Disk
1) Connect the new disk
2) Get the OS to recognize the disk:
Sun –
devfsadm
prtvtoc /dev/dsk/device_name
HP-UX
ioscan –fC disk
insf –e
3) Get VxVM to recognize that a failed disk is now working again:
vxdctl enable
4) Verify that VxVM recognizes the disk:
vxdisk list
Note: In VEA, use the Actions -> Rescan option to run disk setup commands appropriate for the OS. This option ensures that VxVM recognizes newly attached hardware.
Unrelocating a Disk
VEA:
Select the disk to be unrelocated
Select Actions -> Undo Hot Relocation
vxdiskadm:
“Unrelocate subdisks back to a disk”
CLI:
vxunreloc [-f] [-g diskgroup] [-t tasktag] [-n disk_name] orig_disk_name
- orig_disk_name = Original disk before relocation
- -n disk_name = Unrelocates to a disk other than the original
- -f = Forces unrelocation if exact offsets are not possible
Viewing Relocated Subdisks: CLI
When a subdisk is hot-relocated, its original disk media name is stored in the sd_orig_dmname field of the subdisk record files. You can search this field to find all the subdisks that originated from a failed disk using the vxprint command:
vxprint –g diskgroup –se ‘sd_orig_dmname=”disk_name”’
For example, to display all the subdisks that were hot-relocated from datadg01 within the datadg disk group:
vxprint –g datadg –se ‘sd_orig_dmname=”datadg01”’
Recovering a Volume
VEA:
Select the volume to be recovered
Select Actions -> Recover Volume
CLI:
vxreattach [-bcr] [device_tag]
- Reattaches disks to a disk group if disk has a transient failure, such as when a drive is turned off and then turned back on, or if the Volume Manager starts with some disk drivers unloaded and unloadable.
- -r attempts to recover stale plexes using vxrecover
vxrecover [-bnpsvV] [-g diskgroup] [volume_namedisk_name]
i.e. vxrecover –b –g datadg datavol
Note: the vxrecover command only works on a started volume. A started volume displays an ENABLED state in vxprint –ht.
Note: use the –s argument to start a disabled volume
Configuration Backup and Restore
Backup:
vxconfigbackup [diskgroup]
Precommit:
vxconfigrestore –p diskgroup
Commit:
vxconfigrestore-c diskgroup
Bt default, VxVM configuration data is automatically backed up to the files:
/etc/vx/cbr/bk/diskgroup.dgid/dgid.dginfo
/etc/vx/cbr/bk/diskgroup.dgid/dgid.diskinfo
/etc/vx/cbr/bk/diskgroup.dgid/dgid.binconfig
/etc/vx/cbr/bk/diskgroup.dgid/dgid.cfgrec
Configuration data from a backup enables you to reinstall private region headers of VxVM disks in disk group, re-create a corrupted disk group configuration, or re-create a disk group and the VxVM objects within it.
And that is the end of the “Fundamentals” book.
Custom Search
