Primary (Active) HySecure Cluster Manager Node Failure

The node can fail because of following reasons:

1. Host crash because of hardware failure or virtual machine corruption

2. Network lost from production network When Primary HySecure Cluster Manager Node fails, following is the cluster behaviour:

   1. It takes 18 seconds (default value, configuration value) for the secondary (standby) Cluster Manager to detect that the primary Cluster Manager is not available
   2. The secondary Cluster Manager assigns the Virtual IP Address of the cluster to its own NIC card and sends a gratuitous ARP so that the router can start redirecting connections from remote users to this host and not the primary host
   3. The secondary Cluster Manager becomes the Active Cluster Manager
   4. User sessions are preserved and users do not need to re-login.
   5. Configuration database of the secondary Cluster Manager node is put in use.
   6. configuration changes to HySecure configuration will be stored on secondary Cluster Manager database
   7. All user connections handled by the HySecure Gateway module on the failed primary Cluster Manager node are terminated and user or the application must initiate reconnect of the connection.

When Primary HySecure Cluster Manager is available again (restart, connect back to network), following is the behaviour of the cluster

1. The Primary HySecure Clusters, after reboot or reconnection of network, detects that Secondary HySecure cluster manager node is Active and so the Primary HySecure Cluster node assumes the standby role
2. If there were configuration changes on Secondary HySecure Cluster Manager node, the Primary Cluster Manager node will take the new configuration from Secondary (Active node)
3. The Primary Cluster Manager will continue to be in standby mode until the secondary node is available and is playing the role of Active Cluster Manager.
4. No impact on the user sessions or application connections Important Precautions a. If HySecure configuration is updated on Secondary HySecure Cluster Manager node (while in (Active state) while the primary Cluster Manager was not available, it is highly recommended to take the user settings and system backup before getting the primary Cluster Manager up again. b. When Primary Cluster Manager is to be brought back up again after significant down time, it is recommended to bring the Primary Cluster Manager up again during off hours. In certain scenarios, the Primary Cluster Manager can assume the case of Active Cluster Manager, forcing its outdated user session information to be pushed to the Secondary Cluster Manager which had latest user session information data. This will lead to user sessions getting wiped out and users will have to re-login and reconnect their applications.