This document discusses procedures to access AIX FlashCopy, MetroMirror or GlobalMirror volume groups
This subject is fairly well documented in appendix A of the IBM System Storage DS8000 Series: Copy Services in Open Environments Redbook, SG24-6788-02, available at http://www.redbooks.ibm.com/redbooks/pdfs/sg246788.pdf . And the recreatevg command is covered in the Information Center at http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds4/recreatevg.htm . However, there are some details that are not covered that this note discusses.
There are two phases to accessing a VG copy:
- Configuring the LUNs (depending on the multi-path code, these could be hdisks, vpaths or something else if OEM storage is used)
- Accessing the VG
Step 1 is usually accomplished via first assigning the LUNs to a host from the storage side and then running cfgmgr at the host. Step 2 is then accomplished by either importing the VG with importvg, or by running recreatevg against the LUNs if another copy (this could also be the original VG) of the VG resides on the host. Using recreatevg is necessary if a copy of the VG already resides on the host, as the disks will have duplicate PVIDs, LV names, and file system mount points, none of which LVM allows. AIX does allow duplicate PVIDs on a system, but this is designed to be a temporary situation.
One thing that is not documented in the redbook is that if there is a LUN varied on in a VG with PVIDa, then one cannot configure another hdisk/vpath on the system with the same PVID using cfgmgr.
So to configure the disks in such a situation, one must varyoff the VG with the duplicate PVID, and then run cfgmgr. Another approach to this is to configure the LUN on AIX before the copy of data is placed on the LUN (which creates the duplicate PVID). Once the LUN is configured on AIX (at this point it won't have a PVID as the LUN has just been created), then subsequent FlashCopies (or whatever disk subsystem method is used to create the copy) will not require the LUN to be configured again.
Another thing that's not necessary, yet is documented in the redbook, is clearing and setting a new PVID on the LUNs with:
# chdev -l <hdisk#> -a pv=clear
# chdev -l <hdisk#> -a pv=yes
These commands are run by the recreatevg command, so they can be skipped.
For example, say we have an existing VG, existingvg, defined on the system, and we are creating a FlashCopy of it, flashcopyvg. The steps to do so would be as follows:
- Create target LUNs on the storage and assign them to the host
- Configure the LUNs on the host with # cfgmgr (assume we're using SDDPCM on a DS8000 which results in one hdisk for each LUN)
- Make a note of the new hdisks (I'll assume they are hdisk10, hdisk11 and hdisk12)
- Initiate the FlashCopy. If the file systems are not unmounted, see the information below on ensuring consistency of the file systems and data structures via using disk subsystem consistency groups and JFS2 freeze/thaw.
- Run recreatevg to clean up the duplicate PVIDs, LV names, etc., using: # recreatevg -y flashcopyvg hdisk10 hdisk11 hdisk12
- Varyon the VG with # varyonvg flashcopyvg
Note that here we actually configured the new hdisks prior to creating the FlashCopy, so they'll have no PVID. If we already did the FlashCopy, we'd have to varyoff existingvg prior to step 2.
Later, if the customer chooses to update the copies to match the VG again, the procedure would be:
- Varyoff flashcopyvg # varyoffvg flashcopyvg
- Export flashcopyvg with # exportvg flashcopyvg This removes information about flashcopyvg from the ODM on AIX, but doesn't change any information on the disks in the VG.
- Create the new copy with FlashCopy. If the application is not quiesced and the file systems are not unmounted, see the information below on ensuring consistency of the file systems and data structures via using disk subsystem consistency groups and JFS2 freeze/thaw.
- Run recreatevg, e.g., using: # recreatevg -y flashcopyvg hdisk10 hdisk11 hdisk12 Running recreatevg will create a new VG from the FlashCopy volumes (in this case it will be called flashcopyvg) with new LV names, and it will also change the PVIDs of the disks to unique PVIDs and load the ODM with this information. Note that one does not need to run importvg as the recreatevg loads the ODM with the VG information. See the recreatevg man page at http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds4/recreatevg.htm for more details such as how to specify the new LV names or change the mount points of any file systems.
- Varyon the VG with # varyonvg flashcopyvg
Step 2 is necessary since we're going to re-run the recreatevg, and we can't have the VG already defined in the ODM.
Also note that one may make multiple copies of the VG using the above procedures.
Regarding ensuring file system and data consistency, the reason that it is preferable to unmount the file systems, is that otherwise data may reside in file system cache and may not be written to disk. If the application is running, we want to make sure that the FlashCopy (or whatever disk subsystem mirroring method is used) data is a point in time image, and is consistent. This also requires an application that is written to recover in the event of a system crash. If the application doesn't support recovery in the event of a system crash, then one must stop the application prior to initiating the FlashCopy, and in such a case one should also unmount the file systems prior to the FlashCopy to flush file system cache to the file systems. It is possible to create a FlashCopy of VGs used by a running application which supports recovery after a system crash, and to do so it's recommended that:
- Put the application in a hot backup or quiesced mode if the application supports it. This speeds recovery of the application once it's started on the FlashCopy.
- Use disk subsystem consistency groups for the disks in the VG
- Freeze the JFS2 file systems using the chfs command (see the chfs man page at http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds1/chfs.htm ) if using JFS2 (and preferably use JFS2 as there's no similar function in JFS)
- Preferably have one file system log per file system
- Initiate the FlashCopy
- Thaw the JFS2 file system
- Turn off the hot backup or quiesce mode of the application
- Use the above procedures to get the new VG activated on the system
- Run logredo against the file systems
- Run fsck against the file systems
- Use the application to verify the consistency of the application data
For more details on ensuring file system and data consistency, see
Other Information :
|Category :||Backup and Recovery|
|Organization :||Advanced Technical Sales|
Techdocs Technical Support Information