================================================================================ SRDF symrdf list pd symdg -type RDF1 create [dg name] symdg list symrdf -g [dg name] query ================================================================================ BCV #Assume zoned LUNs, if not, zone/mask, ioscan -funC disk #must have gatekeeper zoned too #Load ECC/Symcli on host #Configure License keys on host (BASE (symcli), TimeFinder) symlmf (data kept in /usr/emc/API/symapi/config/symapi_licenses.dat) XXXX-XXXX-XXXX-XXXX #Verify communication to Symmetrix symmask -sid XXXX refresh symcfg discover symcfg list ioscan -fnC disk insf -e #Make gatekeeper symgate define dev sympd list symdev list symbcv list export SYMCLI_DG=mybcvdg export SYMCLI_SID=2674 export SYMCLI_NOPROMPT=1 symcli -def symdg create -type REGULAR mybcvdg #symdg create -type RDF1 mybcvdg #symdg create -type RDF2 mybcvdg symld -sid 661 -g mybcvdg add dev 087 DEV087 symld -sid 661 -g mybcvdg add dev 088 DEV088 symld -sid 661 -g mybcvdg add dev 089 DEV089 symbcv -sid 661 -g mybcvdg associate dev 095 BCV095 symbcv -sid 661 -g mybcvdg associate dev 096 BCV096 symbcv -sid 661 -g mybcvdg associate dev 097 BCV097 symld -g mybcvdg list symmir -g mybcvdg query symmir -v establish -full -g mybcvdg -noprompt **OR** symmir -v establish -full DEV087 BCV dev 095 -g mybcvdg -noprompt symmir -v establish -full DEV088 BCV dev 096 -g mybcvdg -noprompt symmir -v establish -full DEV089 BCV dev 097 -g mybcvdg -noprompt symmir -g mybcvdg query symmir -g mybcvdg verify symmir -g mybcvdg verify -i 60 -c 3 PAUSE...look... symmir -g mybcvdg -noprompt -instant split symmir -g mybcvdg -bg query ================================================================================ # If there are multiple BCV groups off the same standard, # you must move the BCVs between the groups. # GRP1 and GRP2, using the same STDs (same type as well) # See EMC knowledgebase notes below # GRP1 is a BCV1, GRP2 is a BCV2, GSTD is a "standard" group symld -g GSTD moveall GRP1 #do the establish and then the split symld -g GSTD moveall GRP2 #repeat as needed ================================================================================ Add devices to the Device Groups (symld) Add BCV's to the Device Groups (symbcv) Initialize the BCV pairings (symmir) I have created the text files below with detailed commands for these steps. Verify Groups symmir -g pbcv1vg query -summary symmir -g mybcvdg query -summary Here are the files for the clone commands. I think you can use the scripts from EP to run these, just edit the "-sid 662" to say "-sid 661". I need to create the mask/unmask scripts that we will use as part of our pre-NJS recovery testing, maybe next week. We will need to complete these changes and test the TimeFinder commands before we begin Replication. Starting the replication of data will require us to reconfigure TimeFinder on lasasp1. We will need to remove the existing TimeFinder Device Groups on the prod and reporting boxes, then recreate them as RDF1 type. The changes below must be made after EMC loads the BIN file (enabling replication), before the next NJS process is run. We will also need to do the same steps on the DR boxes too... The simple way to do this: 1. symdg export pbcv1vg -f pbcv1vg.txt (this creates a text file detailing the group) 2. edit the first line of the text file, change the first digit from a "0" to a "1" (this changes the group type from regular to RDF1) 3. symdg delete pbcv1vg -force (delete the group) 4. symdg import pbcv1vg -f pbcv1vg.txt (recreate the group) Repeat these steps for the mybcvdg Device Group. In CC, we will change the digit from a "0" to a "2" (this changes the group type from regular to RDF2) ================================================================================ sympd list symdg list symdg create testdg symld -g testdg add dev 26 symbcv -g testdg associate dev 1A4 symbcv -g testdg full establish symbcv -g testdg establish symdg show testdg symmir -g testdg associate symmir -g testdg -full establish symmir -g testdg verify symmir -g testdg query symdg show testdg symdev list symmir -g testdg detach BCV001 symmir -g testdg detach DEV001 symmir -g testdg detach BCV001 symmir -g testdg remove BCV001 symmir -g testdg cancel BCV001 symbcv -g testdg disassociate BCV001 symbcv -g testdg disassociate pd symdg list -v symdg delete testdg symbcv -g testdg disassociate pd BCV001 symbcv -g testdg disassociate dev BCV001 symbcv -g testdg disassociate dev 001 symbcv -g testdg disassociate ldev BCV001 symbcv -g testdg disassociate ld BCV001 symbcv -g testdg split symmir -g testdg split symbcv -g testdg disassociate ld BCV001 symmir -g testdg detach BCV001 symdg show testdg symdg delete testdg symdg -force delete testdg symdg list #for i in arch data rlog software #do # echo $i # symvg vg2dg wolverine-$i wolv-$i -nobcv -dgtype REGULAR #done ================================================================================ "What is symmir verify checking when there is multi BCV?" spacer spacer spacer spacer ID: emc41208 Usage: 10 Date Created: 02/01/2002 Last Modified: 08/10/2005 Knowledgebase Solution Question: What is symmir verify checking when there is multi BCV? Environment: EMC SW: Solutions Enabler SYMCLI TimeFinder Problem: symmir -g Groupname verify gives incorrect results when there are multiple BCVs associated with the STD devices and the STD devices and BCV devices are not in the same Device Group Change: User moves the STD devices between multiple Device Groups so they can perform incremental TimeFinder establishes with different sets of BCV devices Fix: The "symmir -g GroupName verify" command is working as designed - but you need to know what it is doing to understand the results. THE PROBLEM: Symmir verify sometimes gives confusing results in a multi-bcv environment, especially when moving the standard devices between device groups. What is it doing? WHAT "SYMMIR VERIFY" DOES: Verify is used to check the state of STD / BCV pairs and return both a message and return code. It determines the devices that make up the STD / BCV pair in one of three ways. ========================================================================== 1) Using verify on the entire group (not specifying device or pair info) example: symmir -g GRP1 verify ========================================================================== Verify finds all the STD devices in the device group and asks the Symmetrix which BCV device is PAIRed with each particular STD device. The Symmetrix will tell verify only the last PAIRed BCV device. Verify will then attempt to find the PAIRed BCV device in the group. If the BCV is associated with this device group - it has found a PAIR and will check the PAIR state. If the BCV device is not associated with this device group, it is NOT considered a pair and verify will NOT report it's PAIR state, regardless of what state it is in. This will be demonstrated in the examples below. ========================================================================== 2) Using verify on some members of the device group (not specifying pair info) example: symmir -g GRP1 verify DEV001 DEV002 ... ========================================================================== Verify uses the supplied list of STD devices and asks the Symmetrix which BCV device is PAIRed with each particular STD device. The Symmetrix will tell verify only the last PAIRed BCV device. Verify will then attempt to find the PAIRed BCV device in the group. If the BCV is associated with this device group - it has found a PAIR and will check the PAIR state. If the BCV device is not associated with this device group, it is NOT considered a pair and verify will NOT report it's PAIR state, regardless of what state it is in. This will be demonstrated in the Examples below. ========================================================================== 3) Using verify on some/all members of the device group and explicitly stating the pair) example: symmir -g GRP1 verify DEV001 BCV ld BCV001 DEV002 BCV ld BCV002 ... symmir -g GRP1 verify DEV001 BCV pd c10t0d0 ... symmir -g GRP1 verify DEV001 BCV dev 330 ... ========================================================================== Verify uses the supplied list of STD devices and the supplied BCV devices as pairs. The BCV devices specified on the command MUST be associated with the device group, or else this form of the command will fail. The specified BCV device MUST also have actually been paired with this STD at some time or again the command will fail. Verify will return the state based on the user-supplied pairs. See the examples below, the result may not always be what you expect. ========================================================================== EXAMPLES ========================================================================== EXAMPLE ENVIRONMENT: The customer is using Multi-BCV by keeping different sets of BCV devices in their own device groups and moving the STD devices into each group as needed. Let's discuss two device groups, GRP1 and GRP2. STD devices DEV001, DEV002 get paired with BCV001, BCV002 in GRP1 and BCV001, BCV002 in GRP2. After a split, the STD devices are moved between the groups. ==================================================== = STEP 1: (STD devices are in GRP1) ==================================================== GRP1: DEV001, DEV002, BCV001, BCV002 GRP2: BCV001, BCV002 symmir -g GRP1 establish; Wait for the sync symmir -g GRP1 split ==================================================== = STEP 2: (STD devices are in GRP2) ==================================================== GRP1: BCV001, BCV002 GRP2: DEV001, DEV002, BCV001, BCV002 symld -g GRP1 moveall GRP2; Move the STD devices to GRP2 symmir -g GRP2 establish; Wait for the sync symmir -g GRP2 split ==================================================== STEP 3: (STD devices are back in GRP1) ==================================================== GRP1: DEV001, DEV002, BCV001, BCV002 GRP2: BCV001, BCV002 symld -g GRP2 moveall GRP1; Move the STD devices to GRP1 At this point, the actual pairing of STD/BCV is with BCV's in GRP2. So GRP1 has STDs and a set of BCVs that are NOT part of the actual pair (as known to the Symmetrix). symmir -g GRP1 query -multi shows Device Group (DG) Name: GRP1 DG's Type : REGULAR DG's Symmetrix ID : 000185700020 Standard Device BCV Device State ------------------------- ------------------------------------ ------------ Inv. Inv. Logical Sym Tracks Logical Sym Tracks STD <=> BCV ------------------------- ------------------------------------ ------------ DEV001 000 0 N/A 340 0 Split 0 BCV001 330 * 0 Split DEV002 001 0 N/A 341 0 Split 0 BCV002 331 * 0 Split ========================================================================== = EXAMPLES: User does not supply pair info on the command line. ========================================================================== ====================================================== = Example 1: symmir -g GRP1 verify ====================================================== USER EXPECTATION: should say None are synched (we split them) ACTUAL: symmir -g GRP1 verify None of the devices in group 'GRP1' are in the 'Synchronized or Restored' state. RC = 5 WHAT VERIFY IS DOING: Even though it is giving the expected response, it is not for the reason you think, which is why you will think it is broken later when we use the "-split" argument. Remember, it is looking at the STD devices, asking the Symmetrix for their PAIRed BCV device. Since NONE of the PAIRed BCV devices are in the group - it is not finding any pairs and therefore is returning the "NONE". The fact is that the STD devices could actually be synchronized with a different set of BCVs, and it would still return NONE because it didn't find any STD/BCV pairs in the members of this group. ====================================================== = Example 2: symmir -g GRP1 verify -split ====================================================== USER EXPECTATION: should say All are split (we split them) ACTUAL: symmir -g GRP1 verify -split None of the devices in group 'GRP1' are in the 'Split' state. RC = 26 WHAT VERIFY IS DOING: Now you think this is the incorrect answer - and want to call EMC Support. Since the group has no PAIRs - this is the proper response. See explanation in Example 1 above. ========================================================================== = EXAMPLES: User explicitly specifies pair info on the command line. ========================================================================== ====================================================== = Example 3: symmir -g GRP1 verify DEV001 BCV ld BCV001 DEV002 BCV ld BCV002 ====================================================== USER EXPECTATION: should say None are synched (we split them) ACTUAL: symmir -g GRP1 verify DEV001 BCV ld BCV001 DEV001 BCV ld BCV002 None of the devices in the list are in the 'Synchronized or Restored' state. RC = 5 Notice subtle change in output ... "in the list" instead of "in the group" WHAT VERIFY IS DOING: Verify is explicitly checking DEV001 <==> BCV001 and DEV002 <==> BCV002. Since these are not synced - you get the correct response. And this time for the reason you thought. ====================================================== = Example 4: symmir -g GRP1 verify -split DEV001 BCV ld BCV001 DEV002 BCV ld BCV002 ====================================================== USER EXPECTATION: should say All are split (we split them) ACTUAL: symmir -g GRP1 verify -split DEV001 BCV ld BCV001 DEV001 BCV ld BCV002 All of the devices in the list are in the 'Split' state. RC = 0 Notice subtle change in output ... "in the list" instead of "in the group" WHAT VERIFY IS DOING: Verify is explicitly checking DEV001 <==> BCV001 and DEV002 <==> BCV002. Since these are split - you get the correct response. And this time for the reason you thought. However, verify can't please everyone. If the STD devices were currently synchronized with a different set of BCV devices - you would still get the same response. Since you told verify to check this particular pair state and this pair state is 'Split'. Fix: If you upgrade to Solutions Enabler SYMCLI 5.0.2.0 or higher, the behavior of verify has been enhanced to assist users that move the STD devices between device groups. With Solutions Enabler SYMCLI V5.0.2.0, if you run "symmir -g dg1 verify -split" against a group with BCV's that were not the last BCV paired - you will get All devices in group 'dg1' are in the 'Split' state. But not all of their paired BCV devies are associated with the device group. And the command will set return code to 0. ================================================================================ How to manage multiple BCV's to 1 standard device" spacer spacer spacer spacer ID: 1.0.171723970.2847564 Usage: 19 Date Created: 09/14/2000 Last Modified: 09/08/2005 Knowledgebase Solution Question: How to manage multiple BCV's to 1 standard device Environment: EMC SW: Solutions Enabler SYMCLI 4.1 Environment: Enginuity: 5x66 Environment: EMC SW: TimeFinder Environment: This statement does not apply:EMC SW: Solutions Enabler SYMCLI 4.0.2 Environment: This statement does not apply:EMC SW: Solutions Enabler SYMCLI 4.0.1 Environment: This statement does not apply:EMC SW: Solutions Enabler SYMCLI 4.0 Environment: This statement does not apply: Microcode: 5x65 Environment: This statement does not apply: Microcode: 5x64 Root Cause: With the release of Solutions Enabler 4.1 and Enginuity 5x66 a method is needed to manipulate more than 1 BCV to 1 standard volume. Fix: New with Solutions Enabler 4.1 is the symmir -f dfile, option. This enables you to use a 'flat' file or device file, which consists of the 3 digit Symmetrix volume first separated by a space then the 3 digit BCV volume. symmir -sid xxxx -f dfile The contents for example: 018 044 019 045 01a 046 01b 047 To establish different BCV's you create a new device file with a different name. The contents for example: 018 086 019 087 01a 088 01b 089 IMPORTANT NOTE... You need to use the 3 digit Symmetrix and ensure you do not abbreviate these numbers to 1 or 2 digits. Errors such as "Device must be a bcv for this function" will be the error. By using device files you can also easily copy these files from 1 host to another. The -sid (which is the Symmetrix id, or last 4 digits of the Symmetrix serial number if unique from any other Symmetrix you are connected to), must also be used. Please refer to the EMC Solutions Enabler TimeFinder Component Product Guide. To continue to use device group, there are 3 recommended methods (but none as easy as using the -f option). 1) Create device groups for each group of BCV's and move the standard volumes from 1 group to another (the standards would be in their own group as well, you are moving the standard group between the two BCV groups). Use symld -g xxxx moveall yyyy 2) Create 1 group with all the BCV's and explicitly name the standard devices to BCV's. 3) Create a script which creates the device group each time, executes the commands and then deletes it. ================================================================================ Need to su - to root first symrdf -g name query to query the status of the devices in the SRDF group. name = dpspdb or dpstdb or dpsplnx or dpstlnx To go from sync to async: symrdf g name set mode async change the node to async symrdf g name enable enable consistency To go from async back to sync: symrdf g name disable disable consistency symrdf g name set mode sync change the node to sync To turn off/on SRDF: symrdf g name split to split the two arrays from transmitting data. symrdf g name establish to reestablish the SRDF data going between arrays ================================================================================