Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Example 2: Logical Device With VxVM

To illustrate what has been presented, the following paragraphs describe a method to access a replicated set of data created using an enterprise class subsystem: the StorEdge SE99x0 systems. ShadowImage is used to replicate the LUNs. The data to access is configured as a volume, using VERITAS Volume Manager 3.5 patched at the latest level.

The primary volume is called labvol. It is part of the disk group labdg, and is a RAID 0 stripe of five LUNs:

VxVM disk group


VxVM volumes

labvol, RAID 0

VxVM device name







This example covers the trickiest situation, accessing the primary and secondary data from the same host. In this situation, the primary and secondary LUNs are both visible from the same host. Because they are physically different, VxVM assigns them distinct device names:

VxVM device name

VxVM disk name





















ShadowImage is set up so that LUNs are paired, under the consistency group LAB, as follows:

Primary Disk --> Secondary Disk

HDS99100_0 --> HDS99100_10

HDS99100_1 --> HDS99100_11

HDS99100_2 --> HDS99100_12

HDS99100_3 --> HDS99100_13

HDS99100_4 --> HDS99100_14

As described in the previous section, to access the replicated data, you must insure that every layer of the I/O stack is correctly set up. In this example, the steps are:

To Ensure Consistent and Accessible Replicated Disks in the Physical Layer

  • Suspend the replication:

  • Before accessing the replicated LUNs, stop (suspend) the replication and make sure every LUN is in a suspended (psus) state:

    root@storage103 # pairsplit -g LAB 
    root@storage103 # pairevtwait -g LAB -s psus -t 1800

    Of course, pairsplit must be issued when all the LUNs are already synchronized (state PAIR). Failing to do so will result in corrupted secondary devices.

To Detect the Replicated Disks in the Driver Layer

  • Scan the disks and verify that they are all visible and accessible from the secondary host.

  • This is achieved using the VxVM command, vxdiskconfig, which scans the I/O buses for new devices and reads the private region of every disk:

    root@storage103 # vxdiskconfig

    At this stage, the private region of the cloned disks has the same entries as the primary disks, in particular for the diskname and diskid parameters.

To Reconstruct the Replicated Logical Groups and Volumes in the LVM Layer

Modify the primary disk group configuration to reflect the new devices, and apply the modified configuration to a newly created disk group.

  1. Save the disk group configuration of the primary data:

  2. root@storage103 # vxprint -g labdg -m > labdg.vxprint

    This command dumps the whole configuration of the disk group labdg into a file. This file contains more information than necessary. The information of concern is subdisks, plexes, and volumes, which can be extracted by running:

    root@storage103 # i=´grep -n "sd " labdg.vxprint | cut -d: -f1 | head -1´ 
    root@storage103 # more +$i labdg.vxprint > labdg_S.vxprint.tmp 
    root@storage103 # mv labdg_S.vxprint.tmp labdg_S.vxprint

    The file labdg_S.vxprint is the file to push in the disk group configuration of the replicated disks to re-create the volumes.

  3. Clean the cloned disk to re-initialize the disk ID of each cloned disk:

  4. root@storage103 # vxdisksetup -f -i \ 
    9910_0_S=HDS9910_10 \ 
    9910_1_S=HDS9910_11 \ 
    9910_2_S=HDS9910_12 \ 
    9910_3_S=HDS9910_13 \ 
  5. Create the new disk group and populate it with the cloned disks:

  6. root@storage103 # vxdg init labdg_S 9910_0_S 9910_1_S 9910_2_S 9910_3_S 9910_4_S 
  7. Modify labdg_S.vxprint to reflect the disk configuration of the replicated disk group by replacing every occurrence of the primary diskname and device name by the corresponding diskname and device name of the secondary disks.

    1. To ease this process, first create a file containing the device name of primary and secondary disks:

    2. root@storage103 # cat paires.txt 
      HDS99100_0 HDS99100_10 
      HDS99100_1 HDS99100_11 
      HDS99100_2 HDS99100_12 
      HDS99100_3 HDS99100_13 
      HDS99100_4 HDS99100_14 
    3. The string replacement is done by using the following Bourne Shell loop:

    4. root@storage103 # while read pdev sdev 
       pname=´vxdisk list | grep -w $p| awk '{print $3}'´ 
       sname=´vxdisk list | grep -w $s| awk '{print $3}'´ 
       cat labdg_S.vxprint | sed -e "s/$pname/$sname/g" -e "s/$pdev/$sdev/g"\ 
        > labdg_S.vxprint.tmp 
      mv labdg_S.vxprint.tmp labdg_S.vxprint
      done < paires.txt 

      At this stage, the file labdg_S.vxprint reflects the configuration of the new disk group.

  8. Apply the volume configuration file to the new disk group:

  9. root@storage103 # vxmake -g labdg_S -d labdg_S.vxprint
  10. Start the new disk group:

  11.  # vxvol -g labdg_S init active labvol1

To Make the Replicated File System Consistent in the File System Layer

  1. Check consistency of the file system:

  2. root@storage103 # fsck /dev/vx/rdsk/labdg_S/labvol1

    The fsck lists the corrupted files. Action must be taken to recover them. This operation makes sense in case of a crash. During a crash, some files might be corrupted (files in creation and modification mode).

  3. Mount the file system:

  4. root@storage103 # mount /dev/vx/rdsk/labdg_S/labvol1 /mnt/LAB_S

To Make the Data Ready for the Application in the Application Layer

At this stage, you can consider the replicated data accessible. Some application specific actions might take place, such as modifying configuration files, links, or other cleanup or recover processes.

  • + Share This
  • 🔖 Save To Your Account