After a switchover was performed (either manually or automatically), perform either one of the following post-switchover recovery procedures.
For details on how to replace hardware, refer to "Chapter 9 Hardware Maintenance".
When using the storage affinity switchover method, confirm the HBA status of servers on ESC, before recovering them using Resource Coordinator VE.
When the HBA status before switchover is "unknown", delete the server.
When the HBA status is displayed as "access path inheritance is required" (yellow icon) after switchover, perform access path inheritance.
For details, refer to the ESC users guide.
When performing "Failback"
Perform the following operations.
Replace failed server hardware to recover.
Perform "Failback" to keep the configuration created before server switchover.
When using the storage affinity switchover method, after performing failback operations, confirm the HBA status of servers on ESC and perform the same corrective actions as performed after switchover. After performing the corrective actions, for a spare server that had an agent registered, restore the zoning of spare servers and host affinity configurations for storage units following the reference procedures.
When performing "Takeover"
Perform the following operations.
Replace failed server hardware to recover.
Perform "Takeover" to keep the configuration created by a server switchover.
When using storage affinity switchover methods and a spare server that had an agent registered, restore the zoning of spare servers and host affinity configurations for storage units following the reference procedures.
Information
For a server takeover procedure, server hardware can be replaced either before or after the "Takeover" operation.
Use the following procedures to restore the zoning of spare servers and host affinity configurations for storage units in the storage affinity switchover methods.
Check the zoning and host affinity configurations for spare servers using the zoning and host affinity information displayed in "WWN Settings" of Resource Details.
Use the storageadm zone info command to confirm the zoning and host affinity configurations.
Use the storageadm zone add/delete command to confirm the zoning of spare servers and host affinity configurations.
For details on how to use the storageadm zone command, refer to the "ETERNUS SF Storage Cruiser User's Guide".
Note
When the failed server is a VM host, that VM host will be placed into VM maintenance mode. After restoring the failed server and executing "Failback" or "Takeover", in order to use the failed server, release the VM maintenance mode if necessary.
Failback
Use the following procedure to return to a pre-switchover configuration.
For details on the conditions for server failback, refer to "Conditions for Server Failback" in "9.3 Server Switchover Conditions" of the "ServerView Resource Coordinator VE Setup Guide".
In the RC console server resource tree, right-click the physical OS or VM host that was switched over to the spare server, and select [Spare Server]-[Failback] from the popup menu.
The [Failback] dialog is displayed.
Click <OK>.
The spare server is stopped and the server OS is switched back to the primary server.
Note
When using the backup and restore switchover method, do not start up the original spare server during or after the failback operation.
As the primary server and spare server both run the same system image, having the two servers running together will cause conflicts of IP addresses and other information. This can adversely affect the applications switched back to the spare server.
If it becomes necessary to start the spare server, for maintenance or other tasks, ensure that it does not start up from the same system image as that of the primary server. This can be done by turning off the primary server first, or by stopping the spare server at its BIOS screen (before startup of the OS).
When using the backup and restore switchover method, and it is necessary to transfer newly generated data from the spare server to the primary server, back up the spare server before performing the failback.
Refer to "Backing up a System Image" in "8.2 Backup" and apply the backup instructions to the spare server.
Unless there is a need to keep the data that was generated on the spare server while active, backup of the spare server can be skipped. In that case, a system image backed up prior to failure will be restored to the primary server.
When using PRIMERGY BX servers, the maintenance LED of a primary server is automatically deactivated after a server failback.
When the spare server is using I/O virtualization, the spare server will be powered on after failback.
Takeover
Use the following procedure to keep the configuration created by a server switchover:
In the RC console server resource tree, right-click the physical OS or VM host that was switched over to the spare server, and select [Spare Server]-[Takeover] from the popup menu.
The [Takeover] dialog is displayed.
Click <OK>.
The spare server continues operating as the primary server and the server that functioned as the primary server before switchover becomes a spare server.
If the spare server was originally shared by multiple primary servers, all those servers will now use the original primary server as their spare server.
Example
Status before switchover
Application 1: Server A (active) - Server B (spare)
Application 2: Server C (active) - Server B (spare)
Status after a fault in Server A triggered a switchover of Application 1
Application 1: Server A (fault) - Server B (active)
Application 2: Server C (active) - Server B (*1)
Status after replacing Server A and letting Server B take over Application 1
Application 1: Server B (active) - Server A (spare)
Application 2: Server C (active) - Server A (spare)
*1: At this point, manual switchover or Auto-Recovery from Server C to Server B becomes impossible.
Note
Once server switchover has taken place, Auto-Recovery and manual server switchover cannot be performed until either failback or takeover has been executed.
Perform either failback or takeover to enable switchover to be performed again.
When the managed server is a PRIMERGY Partition Model, set the PSA-MMB IP address after deployment. For details, refer to the PRIMERGY Partition Model manual.
