Answers to Chapter Review Questions

     
A1:

The Spare Disk may not have the same performance characteristics as the original disk. In a similar vein, the original disk may have hardware characteristics, e.g., hardware RAID, that improve its high availability features. Both these reasons facilitate un-relocating the affected subdisks. The performance/high availability argument also holds true for the interface used by the disks, e.g., Fibre-Channel against SCSI.

When un-relocating affected subdisks, a significant amount of IO is required to move the data back to its original location. As such it is not necessarily a good idea to un-relocate affected subdisks as soon as the replacement disk has been installed. It may be wise to wait until a quiet time during the day to schedule the un-relocating of affected subdisks.

A2:

Changing from a RAID 5 to a mirrored volume requires a convert operation. A convert operation changes the resilience of a volume. The convert operation does not copy data; it only changes the way data is referenced. A relayout operation changes the underlying structure of a volume and involves copying data at the disk level in order to change the structure of the underlying volume. A realyout is used to transform non-layered volumes .

A3:

This is a concat-mirror volume; the volume layout contains a single plex comprised of one or more concatenated subvolumes. Each subvolume comprises two concatenated plexes (mirrors) comprised of one or more subdisks. If you have two subdisks in the top-level plex, then a second subvolume is created, which is used as the second concatenated subdisk of the plex. Additional subvolumes can be added and concatenated in the same manner. In the VEA interface, the GUI term used for a layered, concatenated layout is Concatenated Pro.

A4:

There are a number of solutions:

  1. You can perform a backup of the affected volumes using a standard backup tool such as fbackup , tar , cpio , and so on, although these will require a filesystem to be used in the affected volumes.

  2. If possible, you could perform a make_[tapenet]_recovery and include the affected volume in the System Recovery backup, although this will require a filesystem to be used in the affected volumes.

  3. The VxVM specific solution would be to take a snapshot of the affected volumes:

    1. Before the application backup:

      1. vxassist “g <dg> snapstart <volume>

      2. When the snapshot volume is in the SNAPDONE state.

      3. vxassist “g <dg> snapshot <volume> <SnapshotVolumeName>

      4. Should the application upgrade fail, we can perform a reverse-resync from the snapshot volume:

        1. umount /<original filesystem> (if applicable )

        2. vxassist “g <dg> -o resyncfromreplica snapback <SnapshotVolumeName>

        3. When in SNAPDONE state, we can mount (if applicable) the original filesystem(s).

A5:

The key to this question is the fact that we are tuning DMP in order to send a specific number of blocks via each interface. The kernel parameter involved is dmp_pathswitch_blks_shift . The default for this parameter is 10 = 2 10 blocks = 1MB of data sent via one interface before sending the next 1MB of data via the next interface in the DMP configuration. Sending only 16KB via each interface would necessitate re-configuring the dmp_pathswitch_blks_shift parameter to = 4 (2 4 = 16 block = 16KB).



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net