The following diagram illustrates the data flow during failover:
In this configuration:
The HA probe lost contact with the primary hub and initiated a failover. The probe will initiate a failback when contact with the primary hub is reestablished.
All connections to the primary hub are unavailable. Any remote monitoring done from the primary hub (such as through the RSP probe) ceases.
On the HA secondary hub, the HA probe activates:
The data_engine probe, which now sends QoS data to the database.
Queues for remote hubs.
The NAS probe. If the HA probe’s NAS AO option is enabled, the auto-operator allows the secondary NAS to email notifications when thresholds are met. However, the messages are not stored in the database. They are stored locally with the secondary NAS.
The service_host probe, which runs the Admin Console web app.
Remote monitoring probes (such as RSP). This ensures that the secondary hub can continue the remote monitoring that was being done by the primary hub.
Robots that were managed by the primary hub and local secondary hubs now send data to the HA hub.
The UMP server cannot send requests to the HA hub, and thus receives no data.
The database does NOT have current alarm information. The information is stored locally stored by the secondary NAS, which will send the replicated information to the primary NAS when failback occurs.
The database does NOT have current alarm information because the nis-bridge on the secondary NAS is disabled. The information is not lost; it is stored locally stored by the secondary NAS, which will send tHAData he replicated information to the primary NAS when failback occurs.
Admin Console is available if service_host and admin_console are deployed on the HA hub. It can be accessed at: