Example: Configuring an SRDF Replication Group for Sun Cluster
This example completes the Sun Cluster specific steps necessary to set up SRDF replication in your cluster. The example assumes that you have already performed the following tasks:
-
Completed pairing LUNS for replication between arrays.
-
Installed the SRDF software on your storage device and cluster nodes.
This example involves a four-node cluster where two nodes are connected to one symmetrix and the other two nodes are connected to the second symmetrix. The SRDF device group is called dg1.
Example 5–15 Creating Replica Pairs
Run the following command on all nodes.
# symcfg discover
! This operation might take up to a few minutes.
# symdev list pd
Symmetrix ID: 000187990182
Device Name Directors Device
--------------------------- ------------ --------------------------------------
Cap
Sym Physical SA :P DA :IT Config Attribute Sts (MB)
--------------------------- ------------- -------------------------------------
0067 c5t600604800001879901* 16D:0 02A:C1 RDF2+Mir N/Grp'd RW 4315
0068 c5t600604800001879901* 16D:0 16B:C0 RDF1+Mir N/Grp'd RW 4315
0069 c5t600604800001879901* 16D:0 01A:C0 RDF1+Mir N/Grp'd RW 4315
...
|
On all nodes on the RDF1 side, type:
# symdg -type RDF1 create dg1 # symld -g dg1 add dev 0067 |
On all nodes on the RDF2 side, type:
# symdg -type RDF2 create dg1 # symld -g dg1 add dev 0067 |
Example 5–16 Verifying Data Replication Setup
From one node in the cluster, type:
# symdg show dg1
Group Name: dg1
Group Type : RDF1 (RDFA)
Device Group in GNS : No
Valid : Yes
Symmetrix ID : 000187900023
Group Creation Time : Thu Sep 13 13:21:15 2007
Vendor ID : EMC Corp
Application ID : SYMCLI
Number of STD Devices in Group : 1
Number of Associated GK's : 0
Number of Locally-associated BCV's : 0
Number of Locally-associated VDEV's : 0
Number of Remotely-associated BCV's (STD RDF): 0
Number of Remotely-associated BCV's (BCV RDF): 0
Number of Remotely-assoc'd RBCV's (RBCV RDF) : 0
Standard (STD) Devices (1):
{
--------------------------------------------------------------------
Sym Cap
LdevName PdevName Dev Att. Sts (MB)
--------------------------------------------------------------------
DEV001 /dev/rdsk/c5t6006048000018790002353594D303637d0s2 0067 RW 4315
}
Device Group RDF Information
...
# symrdf -g dg1 establish
Execute an RDF 'Incremental Establish' operation for device
group 'dg1' (y/[n]) ? y
An RDF 'Incremental Establish' operation execution is
in progress for device group 'dg1'. Please wait...
Write Disable device(s) on RA at target (R2)..............Done.
Suspend RDF link(s).......................................Done.
Mark target (R2) devices to refresh from source (R1)......Started.
Device: 0067 ............................................ Marked.
Mark target (R2) devices to refresh from source (R1)......Done.
Merge device track tables between source and target.......Started.
Device: 0067 ............................................ Merged.
Merge device track tables between source and target.......Done.
Resume RDF link(s)........................................Started.
Resume RDF link(s)........................................Done.
The RDF 'Incremental Establish' operation successfully initiated for
device group 'dg1'.
#
# symrdf -g dg1 query
Device Group (DG) Name : dg1
DG's Type : RDF2
DG's Symmetrix ID : 000187990182
Target (R2) View Source (R1) View MODES
-------------------------------- ------------------------ ----- ------------
ST LI ST
Standard A N A
Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair
Device Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE
-------------------------------- -- ------------------------ ----- ------------
DEV001 0067 WD 0 0 RW 0067 RW 0 0 S.. Synchronized
Total -------- -------- -------- --------
MB(s) 0.0 0.0 0.0 0.0
Legend for MODES:
M(ode of Operation): A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy
D(omino) : X = Enabled, . = Disabled
A(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off
#
|
Example 5–17 Displaying DIDs Corresponding to the Disks Used
The same procedure applies to the RDF1 and RDF2 sides.
You can look under the PdevName field of output of the dymdg show dg command.
On the RDF1 side, type:
# symdg show dg1
Group Name: dg1
Group Type : RDF1 (RDFA)
...
Standard (STD) Devices (1):
{
--------------------------------------------------------------------
Sym Cap
LdevName PdevName Dev Att. Sts (MB)
--------------------------------------------------------------------
DEV001 /dev/rdsk/c5t6006048000018790002353594D303637d0s2 0067 RW 4315
}
Device Group RDF Information
...
|
To obtain the corresponding DID, type:
# scdidadm -L | grep c5t6006048000018790002353594D303637d0 217 pmoney1:/dev/rdsk/c5t6006048000018790002353594D303637d0 /dev/did/rdsk/d217 217 pmoney2:/dev/rdsk/c5t6006048000018790002353594D303637d0 /dev/did/rdsk/d217 # |
To list the corresponding DID, type:
# cldevice show d217 === DID Device Instances === DID Device Name: /dev/did/rdsk/d217 Full Device Path: pmoney2:/dev/rdsk/c5t6006048000018790002353594D303637d0 Full Device Path: pmoney1:/dev/rdsk/c5t6006048000018790002353594D303637d0 Replication: none default_fencing: global # |
On the RDF2 side, type:
You can look under the PdevName field of output of dymdg show dg command.
# symdg show dg1
Group Name: dg1
Group Type : RDF2 (RDFA)
...
Standard (STD) Devices (1):
{
--------------------------------------------------------------------
Sym Cap
LdevName PdevName Dev Att. Sts (MB)
--------------------------------------------------------------------
DEV001 /dev/rdsk/c5t6006048000018799018253594D303637d0s2 0067 WD 4315
}
Device Group RDF Information
...
|
To obtain the corresponding DID, type:
# scdidadm -L | grep c5t6006048000018799018253594D303637d0 108 pmoney4:/dev/rdsk/c5t6006048000018799018253594D303637d0 /dev/did/rdsk/d108 108 pmoney3:/dev/rdsk/c5t6006048000018799018253594D303637d0 /dev/did/rdsk/d108 # |
To list the corresponding DID, type:
# cldevice show d108 === DID Device Instances === DID Device Name: /dev/did/rdsk/d108 Full Device Path: pmoney3:/dev/rdsk/c5t6006048000018799018253594D303637d0 Full Device Path: pmoney4:/dev/rdsk/c5t6006048000018799018253594D303637d0 Replication: none default_fencing: global # |
Example 5–18 Combining DID instances
From the RDF2 side, type:
# cldevice combine -t srdf -g dg1 -d d217 d108 # |
Example 5–19 Displaying the Combined DIDs
From any node in the cluster, type:
# cldevice show d217 d108 cldevice: (C727402) Could not locate instance "108". === DID Device Instances === DID Device Name: /dev/did/rdsk/d217 Full Device Path: pmoney1:/dev/rdsk/c5t6006048000018790002353594D303637d0 Full Device Path: pmoney2:/dev/rdsk/c5t6006048000018790002353594D303637d0 Full Device Path: pmoney4:/dev/rdsk/c5t6006048000018799018253594D303637d0 Full Device Path: pmoney3:/dev/rdsk/c5t6006048000018799018253594D303637d0 Replication: srdf default_fencing: global # |
How to Recover EMC SRDF Data after a Primary Room's
Complete Failure
This procedure performs data recovery when a campus cluster's primary room fails completely, the primary room fails over to a secondary room, and then the primary room comes back online. The campus cluster's primary room is the primary node and storage site. The complete failure of a room includes the failure of both the host and the storage in that room. If the primary room fails, Sun Cluster automatically fails over to the secondary room, makes the secondary room's storage device readable and writable, and enables the failover of the corresponding device groups and resource groups.
When the primary room returns online, you can manually recover the data from the SRDF device group that was written to the secondary room and resynchronize the data. This procedure recovers the SRDF device group by synchronizing the data from the original secondary room (this procedure uses phys-campus-2 for the secondary room) to the original primary room (phys-campus-1). The procedure also changes the SRDF device group type to RDF1 on phys-campus-2 and to RDF2 on phys-campus-1.
Before You Begin
You must configure the EMC replication group and DID devices, as well as register the EMC replication group before you can perform a manual failover. For information about creating a Solaris Volume Manager device group, see How to Add and Register a Device Group (Solaris Volume Manager). For information about creating a Veritas Volume Manager device group, see How to Create a New Disk Group When Encapsulating Disks (Veritas Volume Manager).
Note –
These instructions demonstrate one method you can use to manually recover SRDF data after the primary room fails over completely and then comes back online. Check the EMC documentation for additional methods.
Log into the campus cluster's primary room to perform these steps. In the procedure below, dg1 is the SRDF device group name. At the time of the failure, the primary room in this procedure is phys-campus-1 and the secondary room is phys-campus-2.
-
Log into the campus cluster's primary room and become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
-
From the primary room, use the symrdf command to query the replication status of the RDF devices and view information about those devices.
phys-campus-1# symrdf -g dg1 query
Tip –A device group that is in the split state is not synchronized.
-
If the RDF pair state is split and the device group type is RDF1, then force a failover of the SRDF device group.
phys-campus-1# symrdf -g dg1 -force failover
-
View the status of the RDF devices.
phys-campus-1# symrdf -g dg1 query
-
After the failover, you can swap the data on the RDF devices that failed over.
phys-campus-1# symrdf -g dg1 swap
-
Verify the status and other information about the RDF devices.
phys-campus-1# symrdf -g dg1 query
-
Establish the SRDF device group in the primary room.
phys-campus-1# symrdf -g dg1 establish
-
Confirm that the device group is in a synchronized state and that the device group type is RDF2.
phys-campus-1# symrdf -g dg1 query
Example 5–20 Manually Recovering EMC SRDF Data after a Primary Site Failover
This example provides the Sun Cluster-specific steps necessary to manually recover EMC SRDF data after a campus cluster's primary room fails over, a secondary room takes over and records data, and then the primary room comes back online. In the example, the SRDF device group is called dg1 and the standard logical device is DEV001. The primary room is phys-campus-1 at the time of the failure, and the secondary room is phys-campus-2. Perform the steps from the campus cluster's primary room, phys-campus-1.
phys-campus-1# symrdf -g dg1 query | grep DEV DEV001 0012RW 0 0NR 0012RW 2031 O S.. Split phys-campus-1# symdg list | grep RDF dg1 RDF1 Yes 00187990182 1 0 0 0 0 phys-campus-1# symrdf -g dg1 -force failover ... phys-campus-1# symrdf -g dg1 query | grep DEV DEV001 0012 WD 0 0 NR 0012 RW 2031 O S.. Failed Over phys-campus-1# symdg list | grep RDF dg1 RDF1 Yes 00187990182 1 0 0 0 0 phys-campus-1# symrdf -g dg1 swap ... phys-campus-1# symrdf -g dg1 query | grep DEV DEV001 0012 WD 0 0 NR 0012 RW 0 2031 S.. Suspended phys-campus-1# symdg list | grep RDF dg1 RDF2 Yes 000187990182 1 0 0 0 0 phys-campus-1# symrdf -g dg1 establish ... phys-campus-1# symrdf -g dg1 query | grep DEV DEV001 0012 WD 0 0 RW 0012 RW 0 0 S.. Synchronized phys-campus-1# symdg list | grep RDF dg1 RDF2 Yes 000187990182 1 0 0 0 0 |
- © 2010, Oracle Corporation and/or its affiliates