In this scenario, the administrator has a scheduled maintenance period and switches operations that run on the production server to the designated recovery server.
Follow these steps to perform the Planned Failover, Resync and Failback operations:
Planned Failover - the Failover Operation
Perform the following steps for a planned failover:
-
Use PowerHa Stop Cluster Services to unmanage the resource groups.
Stop now, on system restart or both select [now]
Stop Cluster Services on these nodes select [both nodes]
Select an Action on Resource Groups select [Unmanage Resource Groups]
-
On the production server stop your application.
-
On the production server, use rtumnt to unmount the protected file systems, transfer any current LFC data to the recovery server.
-
On the production server verify that the synchronization of data has successfully completed.
Example:
Sync: transferring current LFC to Recovery ServerWaiting for synchronization of data to complete.All data has been synchronized to the Recovery Server.
-
On the production server, use rtstop to unmount the protected file systems, transfer any current LFC data to the recovery server and unload the Assure MIMIX for AIX production server drivers.
/usr/scrt/bin/rtstop -FSC<PrimaryContextID>
-
On the production server verify that the synchronization of data has successfully completed.
Example:
All data has been synchronized to the Recovery Server.Stopping scrt_lca..............Unloading Assure MIMIX DR for AIX Production Server Drivers
-
On the recovery server execute the failover command to initiate the failover process:
/usr/scrt/bin/rtdr -C <Primary Context ID> failover
Answer “y” to the “Do you wish to” questions:
scsetup: You have requested failover processing. scsetup: Do you wish to continue? [y|n] !!! RESET WARNING !!! You have requested an LCA reset. All outstanding sealed LFCs will be dumped. Do you wish to do this? [y|n]
On the recovery server verify that the failover process completed.
Example:
--- Failover Context ID <Failover ContextID> is enabled. ---
Note: At this point the configured recovery server has become the new production server and the configured production server has become the new recovery server. -
On the new production server start your application.
Note: At this point your application is running on the new production server and replication is not active. Perform the resync operation to start replication.Planned Failover - the Resync Operation
A resync operation is required when the Production Volumes and Recovery Replica Volumes diverge. This occurs after a failover to the recovery server.
When the application is started on the recovery server the updates to the Replica Volumes result in a divergence from the data on the production server.
-
On the new recovery server, execute the resync command to start replication on the new recovery server.
/usr/scrt/bin/rtdr -C <Primary Context ID> resync
Answer “y” to the “Do you wish to” questions:
scsetup: You have requested failover processing. scsetup: Do you wish to continue? [y|n] !!! RESET WARNING !!! You have requested an LCA reset. All outstanding sealed LFCs will be dumped. Do you wish to do this? [y|n]
-
On the new recovery server verify that the resync process completed.
Example:
-- Failover Context ID <Failover ContextID> is enabled and ready for re-sync. ---
-
On the new production server, execute the resync command to start replication on the new production server.
/usr/scrt/bin/rtdr -C <Primary Context ID> resync
-
On the new production server verify that the resync process completed.
Example:
--- System re-sync is activated. ---
Note: At this point your application is running on the new production server and data is being replicated to the new recovery server. To return the production and recovery server back to their original roles, perform the failback operation.Planned Failover - the Failback Operation
-
Before performing the failback operation, ensure that you stop your application on the new production server.
-
On the new production server, use rtumnt to unmount the protected file systems, transfer any current LFC data to the recovery server.
/usr/scrt/bin/rtumnt -C<FailoverContextID>
-
On the new production server verify that the protected file systems are unmounted and synchronization of data has successfully completed.
Example:
Determining Filesystems to unmount...Unmounting /dev/lvFS_1_C1 from /FS_1_C1...Sync: transferring current LFC to Recovery ServerWaiting for synchronization of data to complete.All data has been synchronized to the Recovery Server.
-
On the new production server, use rtstop to unmount the protected file systems, transfer any current LFC data to the recovery server and unload the Assure MIMIX for AIX production server drivers.
/usr/scrt/bin/rtstop -FSC<FailoverContextID>
-
On the new production server verify that the synchronization of data has successfully completed.
Example:
No mounted filesystemsSync: transferring any current LFC data to Recovery ServerWaiting for synchronization of data to complete.All data has been synchronized to the Recovery Server.Stopping scrt_lca................Unloading Assure MIMIX DR for AIX Production Server Drivers
-
On the new recovery server execute the failback command to start the failback process. Wait for failback to successfully complete before performing failback on the new production server.
/usr/scrt/bin/rtdr -C <Primary Context ID> failback
-
On the new recovery server verify that the failback process completed.
Example:
Assure MIMIX DR for AIX Production Server Drivers are already loaded for Context ID 1.Starting scrt_lca
fsck -fp -y /dev/rlvFS_1_C1
The current volume is: /dev/lvFS_1_C1Primary superblock is valid.Mounting /FS_1_C1...
--- Primary Context ID <1> is enabled. ---
-
On the new production server execute the failback command to start the failback process. Wait for failback to successfully complete before starting your application.
/usr/scrt/bin/rtdr -qC <Failover Context ID> failback
-
On the new production server verify that the failback process completed.
Example:
Assure MIMIX DR for AIX Recovery Server Drivers are already loaded for Context ID 1.Starting scrt_aba
--- Primary Context ID <1> is enabled. ---
Note: At this point the production and recovery servers have been returned back to their original roles and replication is active. -
On the production server start your application.
-
Use PowerHa Start Cluster Services to manage the resource groups.
Start now, on system restart or both select [both]Start Cluster Services on these nodes select [both nodes]
Manage Resource Groups select [Automatically]