This section provides a step-by-step example of how data replication was configured for an NFS application by using Sun StorEdge Availability Suite 3.1 software.
Figure 6–7 illustrates the cluster configuration used in the example configuration. The secondary cluster in the example configuration contains one node, but other cluster configurations can be used.
Table 6–1 summarizes the hardware and software required by the example configuration. The operating environment, Sun Cluster software, and volume manager software must be installed on the cluster nodes before you install Sun StorEdge Availability Suite 3.1 software and patches.
Table 6–1 Required Hardware and Software
Hardware or Software |
Requirement |
---|---|
Node hardware |
Sun StorEdge Availability Suite 3.1 software is supported on all servers using the Solaris operating environment. For information about which hardware to use, see the Sun Cluster 3.x Hardware Administration Manual. |
Disk space |
Approximately 11 Mbytes. |
Operating environment |
Solaris 8 or Solaris 9 releases that are supported by Sun Cluster software. All nodes must use the same version of operating environment. For information about installation, seeInstalling the Software. |
Sun Cluster software |
Sun Cluster 3.1 4/04 software. For information about installation, see Chapter 2, Installing and Configuring Sun Cluster Software and How to Install Sun Cluster Software on a Single-Node Cluster. |
Volume manager software |
Solstice DiskSuite/Solaris Volume Manager or VERITAS Volume Manager (VxVM). All nodes must use the same version of volume manager software. Information about installation is inInstalling and Configuring Solstice DiskSuite/Solaris Volume Manager Software and SPARC: Installing and Configuring VxVM Software. |
Sun StorEdge Availability Suite 3.1 software |
For information about how to install the software, see the Sun StorEdge Availability Suite 3.1 Point-in-Time Copy Software Installation Guide and the Sun StorEdge Availability Suite 3.1 Remote Mirror Software Installation Guide. |
Sun StorEdge Availability Suite 3.1 software patches |
For information about the latest patches, see http://sunsolve.sun.com. |
This chapter describes how disk device groups and resource groups were configured for an NFS application. The following table lists the names of the groups and resources that were created for the example configuration.
Table 6–2 Summary of the Groups and Resources in the Example Configuration
Group or Resource |
Name |
Description |
---|---|---|
Disk device group |
devicegroup |
The disk device group. |
Replication resource group and resources |
devicegroup-stor-rg |
The replication resource group. |
lhost-reprg-prim, lhost-reprg-sec |
The logical hostnames for the replication resource group on the primary cluster and the secondary cluster. |
|
devicegroup-stor |
The HAStoragePlus resource for the replication resource group. |
|
Application resource group and resources |
nfs-rg |
The application resource group. |
lhost-nfsrg-prim, lhost-nfsrg-sec |
The logical hostnames for the application resource group on the primary cluster and the secondary cluster. |
|
nfs-dg-rs |
The HAStoragePlus resource for the application. |
|
nfs-rs |
The NFS resource. |
With the exception of devicegroup-stor-rg, the names of the groups and resources are example names that can be changed as required. The replication resource group must have a name with the format devicegroup-stor-rg.
This section describes how to configure a disk device group on the primary cluster and the secondary cluster. This example configuration uses VxVM software. For information about Solstice DiskSuite/Solaris Volume Manager software, see Chapter 3, Installing and Configuring Solstice DiskSuite/Solaris Volume Manager Software.
The following figure illustrates the volumes that were created in the disk device group.
The volumes defined in this section must not include disk label private areas, for example, cylinder 0. The VxVM software manages this constraint automatically.
Create a disk group that contains four volumes, volume 1 through volume 4.
For information about configuring a disk group by using the VxVM software, see Chapter 4, SPARC: Installing and Configuring VERITAS Volume Manager.
Access nodeA as superuser.
nodeA is the first node of the primary cluster. For a reminder of which node is nodeA, see Figure 6–7.
Configure the disk group to create a disk device group.
nodeA# /usr/cluster/bin/scconf -a -D type=vxvm,name=devicegroup \ ,nodelist=nodeA:nodeB |
The disk device group is called devicegroup.
Start the disk device group.
nodeA# /usr/cluster/bin/scswitch -z -D devicegroup -h nodeA |
Synchronize the disk device group with the Sun Cluster software.
nodeA# /usr/cluster/bin/scconf -c -D name=devicegroup,sync |
Create the file system for the disk device group.
nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol01 < /dev/null nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol02 < /dev/null nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol03 < /dev/null nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol04 < /dev/null |
Enable remote access between the nodes in the primary cluster and secondary cluster by adding the following entities to the /.rhosts file on nodeA and nodeB.
nodeC + + root |
Follow the procedure in How to Configure a Disk Device Group on the Primary Cluster, with these exceptions:
This section describes how the file systems were configured for the NFS application.
On nodeA and nodeB, create a mount point directory for the NFS file system.
For example:
nodeA# mkdir /global/mountpoint |
On nodeA and nodeB, configure the master volume to be mounted automatically on the mount point.
Add or replace the following text to the /etc/vfstab file on nodeA and nodeB. The text must be on a single line.
/dev/vx/dsk/devicegroup/vol01 /dev/vx/rdsk/devicegroup/vol01 \ /global/mountpoint ufs 3 no global,logging |
For a reminder of the volumes names and volume numbers used in the disk device group, see Figure 6–8.
On nodeA, create a volume for the file system information that is used by Sun StorEdge Availability Suite 3.1 software.
nodeA# /usr/sbin/vxassist -g devicegroup make vol05 120m disk1 |
Volume 5 contains the file system information that is used by Sun StorEdge Availability Suite 3.1 software.
On nodeA, resynchronize the device group with the Sun Cluster software.
nodeA# /usr/cluster/bin/scconf -c -D name=devicegroup,sync |
On nodeA, create the file system for volume 5.
nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol05 |
On nodeA and nodeB, create a mount point for volume 5.
For example:
nodeA# mkdir /global/etc |
On nodeA and nodeB, configure volume 5 to be mounted automatically on the mount point.
Add or replace the following text to the /etc/vfstab file on nodeA and nodeB. The text must be on a single line.
/dev/vx/dsk/devicegroup/vol05 /dev/vx/rdsk/devicegroup/vol05 \ /global/etc ufs 3 yes global,logging |
Mount volume 5 on nodeA.
nodeA# mount /global/etc |
Make volume 5 accessible to remote systems.
Create a directory called /global/etc/SUNW.nfs on nodeA.
nodeA# mkdir -p /global/etc/SUNW.nfs |
Create the file /global/etc/SUNW.nfs/dfstab.nfs-rs on nodeA.
nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs |
Add the following line to the /global/etc/SUNW.nfs/dfstab.nfs-rs file on nodeA:
share -F nfs -o rw -d "HA NFS" /global/mountpoint |
Repeat the procedure in How to Configure the File System on the Primary Cluster for the NFS Application, with these exceptions:
Replace nodeA with nodeC.
Do not use nodeB.
This section describes how a replication resource group was created on the primary cluster and on the secondary cluster.
Access nodeA as superuser.
Register SUNW.HAStoragePlus as a resource type.
nodeA# /usr/cluster/bin/scrgadm -a -t SUNW.HAStoragePlus |
Create a replication resource group for the disk device group.
nodeA# /usr/cluster/bin/scrgadm -a -g devicegroup-stor-rg -h nodeA,nodeB |
The name of the disk device group.
The name of the replication resource group.
Specifies the cluster nodes that can master the replication resource group.
Add a SUNW.HAStoragePlus resource to the replication resource group.
nodeA# /usr/cluster/bin/scrgadm -a -j devicegroup-stor \ -g devicegroup-stor-rg -t SUNW.HAStoragePlus \ -x GlobalDevicePaths=devicegroup \ -x AffinityOn=True |
The HAStoragePlus resource for the replication resource group.
Specifies the extension property that Sun StorEdge Availability Suite 3.1 software relies on.
Specifies that the SUNW.HAStoragePlus resource must perform an affinity switchover for the global devices and cluster file systems defined by -x GlobalDevicePaths=. Therefore, when the replication resource group fails over or is switched over, the associated device group is switched over.
For more information about these extension properties, see the SUNW.HAStoragePlus(5) man page.
Add a logical hostname resource to the replication resource group.
nodeA# /usr/cluster/bin/scrgadm -a -L \ -j lhost-reprg-prim -g devicegroup-stor-rg -l lhost-reprg-prim |
Where lhost-reprg-prim is the logical hostname for the replication resource group on the primary cluster.
Enable the resources, manage the resource group, and bring the resource group online.
nodeA# /usr/cluster/bin/scswitch -Z -g devicegroup-stor-rg nodeA# /usr/cluster/bin/scswitch -z -g devicegroup-stor-rg -h nodeA |
Verify that the resource group is online.
nodeA# /usr/cluster/bin/scstat -g |
Examine the resource group state field to confirm that the replication resource group is online for nodeA and nodeB.
Repeat the procedure in How to Create a Replication Resource Group on the Primary Cluster, with these exceptions:
Replace nodeA with nodeC.
Do not use nodeB.
Replace references to lhost-reprg-prim with lhost-reprg-sec.
This section describes how application resource groups were created for an NFS application. The procedures in this section are specific to the application. The procedures cannot be used for another type of application.
Access nodeA as superuser.
Register SUNW.nfs as a resource type.
nodeA# scrgadm -a -t SUNW.nfs |
If SUNW.HAStoragePlus has not been registered as a resource type, register it.
nodeA# scrgadm -a -t SUNW.HAStoragePlus |
Create an application resource group for the devicegroup.
nodeA# scrgadm -a -g nfs-rg \ -y Pathprefix=/global/etc \ -y Auto_start_on_new_cluster=False \ -y RG_dependencies=devicegroup-stor-rg |
Is the name of the application resource group.
Specifies a directory into which the resources in the group can write administrative files.
Specifies that the application resource group is not started automatically.
Specifies the resource groups that the application resource group depends on. In this example, the application resource group depends on the replication resource group.
If the application resource group is switched over to a new primary node, the replication resource group is automatically switched over. However, if the replication resource group is switched over to a new primary node, the application resource group must be manually switched over.
Add a SUNW.HAStoragePlus resource to the application resource group.
nodeA# scrgadm -a -j nfs-dg-rs -g nfs-rg \ -t SUNW.HAStoragePlus \ -x FileSystemMountPoints=/global/mountpoint \ -x AffinityOn=True |
Is the name of the HAStoragePlus resource for the NFS application.
Specifies that the mount point for the file system is global.
Specifies that the resource is of the type SUNW.HAStoragePlus.
Specifies that the application resource must perform an affinity switchover for the global devices and cluster file systems defined by -x GlobalDevicePaths=. Therefore, when the application resource group fails over or is switched over, the associated device group is switched over.
For more information about these extension properties, see the SUNW.HAStoragePlus(5) man page.
Add a logical hostname resource to the application resource group.
nodeA# /usr/cluster/bin/scrgadm -a -L -j lhost-nfsrg-prim -g nfs-rg \ -l lhost-nfsrg-prim |
Where lhost-nfsrg-prim is the logical hostname of the application resource group on the primary cluster.
Enable the resources, manage the application resource group, and bring the application resource group online.
Bring the HAStoragePlus resource for the NFS application online.
nodeA# /usr/cluster/bin/scrgadm -a -g nfs-rg \ -j nfs-rs -t SUNW.nfs -y Resource_dependencies=nfs-dg-rs |
Bring the application resource group online on nodeA .
nodeA# /usr/cluster/bin/scswitch -Z -g nfs-rg nodeA# /usr/cluster/bin/scswitch -z -g nfs-rg -h nodeA |
Verify that the application resource group is online.
nodeA# /usr/cluster/bin/scstat -g |
Examine the resource group state field to determine whether the application resource group is online for nodeA and nodeB.
Create the application group resource as described in Step 1 through Step 6 of How to Create an Application Resource Group on the Primary Cluster, with the following exceptions:
Replace nodeA with nodeC.
Ignore references to nodeB.
Replace references to lhost-nfsrg-prim with lhost-nfsrg-sec.
Ensure that the application resource group does not come online on nodeC.
nodeC# /usr/cluster/bin/scswitch -n -j nfs-rs nodeC# /usr/cluster/bin/scswitch -n -j nfs-dg-rs nodeC# /usr/cluster/bin/scswitch -n -j lhost-nfsrg-sec nodeC# /usr/cluster/bin/scswitch -z -g nfs-rg -h "" |
The resource group remains offline after a reboot, because Auto_start_on_new_cluster=False.
If the global volume is mounted on the primary cluster, unmount the global volume from the secondary cluster.
nodeC# umount /global/mountpoint |
If the volume is mounted on a secondary cluster, the synchronization fails.
This section describes how data replication was enabled for the example configuration. This section uses the Sun StorEdge Availability Suite 3.1 software commands sndradm and iiadm. For more information about these commands, see the Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
Access nodeA as superuser.
Flush all transactions.
nodeA# /usr/sbin/lockfs -a -f |
Confirm that the logical hostnames lhost-reprg-prim and lhost-reprg-sec are online.
nodeA# /usr/cluster/bin/scstat -g |
Examine the state field of the resource group.
Enable remote mirror replication from the primary cluster to the secondary cluster.
This step enables replication from the master volume of the primary cluster to the master volume of the secondary cluster. In addition, this step enables replication to the remote mirror bitmap on volume 4.
If the primary cluster and secondary cluster are unsynchronized, run this command:
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
If the primary cluster and secondary cluster are synchronized, run this command:
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -E lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
Enable autosynchronization.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
This step enables autosynchronization. When the active state of autosynchronization is set to on, the volume sets are resynchronized if the system reboots or a failure occurs.
Verify that the cluster is in logging mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -P |
The output should look like this:
/dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, state: logging |
In logging mode, the state is logging, and the active state of autosynchronization is off. When the data volume on the disk is written to, the bitmap file on the same disk is updated.
Enable point-in-time snapshot.
nodeA# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devicegroup/vol02 |
This step enables the master volume of the primary disk to be copied to the shadow volume on the same disk. In this example, the master volume is volume 1, the shadow volume is volume 2, and the point-in-time bitmap volume is volume 3.
Attach the point-in-time snapshot to the remote mirror set.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03 |
This step associates the point-in-time snapshot with the remote mirror volume set. Sun StorEdge Availability Suite 3.1 software ensures that a point-in-time snapshot is taken before remote mirror replication can occur.
Access nodeC as superuser.
Flush all transactions.
nodeC# /usr/sbin/lockfs -a -f |
Enable remote mirror replication from the primary cluster to the secondary cluster.
nodeC# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
The primary cluster detects the presence of the secondary cluster and starts synchronization. Refer to the system log file /var/opt/SUNWesm/ds.log for information about the status of the clusters.
Enable independent point-in-time snapshot.
nodeC# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devicegroup/vol02 |
Attach the point-in-time snapshot to the remote mirror set.
nodeC# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03 |
This section describes how data replication was performed for the example configuration. This section uses the Sun StorEdge Availability Suite 3.1 software commands sndradm and iiadm. For more information about these commands, see the Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
In this procedure, the master volume of the primary disk is replicated to the master volume on the secondary disk. The master volume is volume 1 and the remote mirror bitmap volume is volume 4.
Access nodeA as superuser.
Verify that the cluster is in logging mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -P |
The output should look like this:
/dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, state: logging |
In logging mode, the state is logging, and the active state of autosynchronization is off. When the data volume on the disk is written to, the bitmap file on the same disk is updated.
Flush all transactions.
nodeA# /usr/sbin/lockfs -a -f |
Copy the master volume of nodeA to the master volume of nodeC.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -m lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
Wait until the replication is complete and the volumes are synchronized.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -w lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
Confirm that the cluster is in replicating mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -P |
The output should look like this:
/dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, state: replicating |
In replicating mode, the state is replicating, and the active state of autosynchronization is on. When the primary volume is written to, the secondary volume is updated by Sun StorEdge Availability Suite 3.1 software.
In this procedure, point-in-time snapshot was used to synchronize the shadow volume of the primary cluster to the master volume of the primary cluster. The master volume is volume 1 and the shadow volume is volume 2.
Access nodeA as superuser.
Quiesce the application that is running on nodeA.
nodeA# /usr/cluster/bin/scswitch -n -j nfs-rs |
Put the primary cluster in to logging mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
When the data volume on the disk is written to, the bitmap file on the same disk is updated. No replication occurs.
Synchronize the shadow volume of the primary cluster to the master volume of the primary cluster.
nodeA# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devicegroup/vol02 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devicegroup/vol02 |
Synchronize the shadow volume of the secondary cluster to the master volume of the secondary cluster.
nodeC# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devicegroup/vol02 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devicegroup/vol02 |
Restart the application on nodeA.
nodeA# /usr/cluster/bin/scswitch -e -j nfs-rs |
Resynchronize the secondary volume with the primary volume.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
This section describes how the replication configuration was confirmed in the example configuration.
Verify that the primary cluster is in replicating mode, with autosynchronization on.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -P |
The output should look like this:
/dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, state: replicating |
In replicating mode, the state is replicating, and the active state of autosynchronization is on. When the primary volume is written to, the secondary volume is updated by Sun StorEdge Availability Suite 3.1 software.
If the primary cluster is not in replicating mode, put it in to replicating mode, as follows:
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
Make a directory on a client machine.
Mount the directory to the application on the primary cluster, and display the mounted directory.
Mount the directory to the application on the secondary cluster, and display the mounted directory.
Unmount the directory to the application on the primary cluster.
client-machine# umount /dir |
Take the application resource group offline on the primary cluster.
nodeA# /usr/cluster/bin/scswitch -n -j nfs-rs nodeA# /usr/cluster/bin/scswitch -n -j nfs-dg-rs nodeA# /usr/cluster/bin/scswitch -n -j lhost-nfsrg-prim nodeA# /usr/cluster/bin/scswitch -z -g nfs-rg -h "" |
Put the primary cluster in to logging mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
When the data volume on the disk is written to, the bitmap file on the same disk is updated. No replication occurs.
Bring the application resource group online on the secondary cluster.
nodeC# /usr/cluster/bin/scswitch -Z -g nfs-rg |
Access the client machine as superuser.
You see a prompt like this:
client-machine# |
Mount the directory that was created in Step 2 to the application on the secondary cluster.
client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /dir |
Display the mounted directory.
client-machine# ls /dir |
Ensure that the directory displayed in Step 3 is the same as that displayed in Step 4.
Return the application on the primary cluster to the mounted directory.
Take the application resource group offline on the secondary cluster.
nodeC# /usr/cluster/bin/scswitch -n -j nfs-rs nodeC# /usr/cluster/bin/scswitch -n -j nfs-dg-rs nodeC# /usr/cluster/bin/scswitch -n -j lhost-nfsrg-sec nodeC# /usr/cluster/bin/scswitch -z -g nfs-rg -h "" |
Ensure that the global volume is unmounted from the secondary cluster.
nodeC# umount /global/mountpoint |
Bring the application resource group online on the primary cluster.
nodeA# /usr/cluster/bin/scswitch -Z -g nfs-rg |
Put the primary cluster in to replicating mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
When the primary volume is written to, the secondary volume is updated by Sun StorEdge Availability Suite 3.1 software.
This section describes how a switchover was provoked and how the application was transferred to the secondary cluster. After a switchover or failover, you must update the DNS entry and configure the application to read and write to the secondary volume.
Put the primary cluster into logging mode.
nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync |
When the data volume on the disk is written to, the bitmap file on the same disk is updated. No replication occurs.
Confirm that the primary cluster and the secondary cluster are in logging mode, with autosynchronization off.
On nodeA, run this command:
nodeA# /usr/opt/SUNWesm/sbin/sndradm -P |
The output should look like this:
/dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devicegroup, state: logging |
On nodeC, run this command:
nodeC# /usr/opt/SUNWesm/sbin/sndradm -P |
The output should look like this:
/dev/vx/rdsk/devicegroup/vol01 <- lhost-reprg-prim:/dev/vx/rdsk/devicegroup/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devicegroup, state: logging |
For nodeA and nodeC, the state should be logging, and the active state of autosynchronization should be off.
Confirm that the secondary cluster is ready to take over from the primary cluster.
nodeC# /usr/sbin/fsck -y /dev/vx/rdsk/devicegroup/vol01 |
Switch over to the secondary cluster.
nodeC# scswitch -Z -g nfs-rg nodeC# scswitch -Z -g nfs-rg -h nodeC |
For an illustration of how the DNS maps a client to a cluster, see Figure 6–6.
Start the nsupdate command.
For information, see the nsupdate(1M) man page.
Remove the current DNS mapping between the client machine and the logical hostname of the application resource group on the primary cluster.
> update delete client-machine A > update delete IPaddress1.in-addr.arpa TTL PTR client machine |
Is the full name of the client. For example, mymachine.mycompany.com.
Is the IP address is of the logical hostname lhost-nfsrg-prim, in reverse order.
Is the time to live, in seconds. A typical value is 3600.
Create the new DNS mapping between the client machine and the logical hostname of the application resource group on the secondary cluster.
> update add client-machine TTL A IPaddress2 > update add IPaddress3.in-addr.arpa TTL PTR client-machine |
Is the IP address is of the logical hostname lhost-nfsrg-sec, in forward order.
Is the IP address is of the logical hostname lhost-nfsrg-sec, in reverse order.
Configure the secondary volume to be mounted to the mount point directory for the NFS file system.
client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /xxx |
The mount point was created in Step 1 of How to Configure the File System on the Primary Cluster for the NFS Application.
Confirm that the secondary cluster has write access to the mount point.
client-machine# touch /xxx/data.1 client-machine# umount /xxx |