![]() |
![]() |
When failover occurs, HACMP calls the Tivoli Storage Manager startserver script on the standby node. The script verifies the devices, breaking the SCSI reserves, and starts the server.
On fallback, the stopserver script runs on the standby node, which causes the Tivoli Storage Manager server to halt. Then the startserver script runs on the production node.
HACMP handles taking over the TCP/IP address and mounting the shared file system on the standby node or production node, as appropriate. By default, the startserver script will not start the Tivoli Storage Manager server unless all the devices in the VerifyDevice statements can be made available. However, you can modify the startserver script to start the server even if no devices can be made available.
Both failover and fallback act like a Tivoli Storage Manager server has crashed or halted and was then restarted. Any transactions that were in-flight at the time are rolled back, and all completed transactions are still complete. Tivoli Storage Manager clients see this as a communications failure and try to reestablish connection based on their COMMRESTARTDURATION and COMMRESTARTINTERVAL settings.
The backup-archive client can usually restart from the last committed transaction. The agents will usually result in the backup in progress as a failed backup. If they can restart, they must do so from the beginning of the processing. The clients and agents will behave as they normally do if the server was halted and restarted while they were connected. The only difference is that the server is physically restarted on different hardware.
If you do not want automatic fallback to occur, you can configure the resource as a cascading resource group without fallback. For more information on configuring resource groups, see High Availability Cluster Multi-Processing for AIX Planning Guide (SC23-4277).