Amigopod 3.7
| Deployment Guide
High Availability Services |
351
SMTP settings for email receipts ( See
“Email Receipt Options”
in the Guest Management chapter)
SNMP server settings ( See
“SNMP Configuration”
in the Administrator Tasks chapter)
The set of currently installed plugins ( See
“Plugin Manager”
in the Administrator Tasks chapter)
Web Login pages ( See
“Web Logins”
in the RADIUS Services chapter)
Certain configuration items are not replicated. These are:
HTTP Proxy settings (
“HTTP Proxy Configuration”
in the Administrator Tasks chapter)
Network interface configuration (
“Network Interfaces”
in the Administrator Tasks chapter)
RADIUS dictionary entries ( See
“Dictionary”
in the RADIUS Services chapter)
SSL certificate settings ( See
“SSL Certificate”
in the Administrator Tasks chapter)
Subscription IDs in Plugin Manager ( See
“Managing Subscriptions”
in the Administrator Tasks chapter)
System hostname ( See
“System Hostname”
in the Administrator Tasks chapter)
Primary Node Failure
If the cluster’s primary node fails, the cluster status will be displayed on the secondary node as:
The secondary node is running, but the primary node is down or stopped.
While the primary node is down, the cluster is in a failed state and cannot deliver network services. If the
primary node recovers within the downtime threshold, the cluster will automatically return to the normal
state and network service will be restored.
An automatic failover will be initiated after the primary node has been offline for the
downtime threshold
,
which is 30 seconds by default.
Once failover has occurred, the cluster status will be displayed on the secondary node as:
The secondary node has taken over the cluster services because the primary node is down.
In the failover state, the secondary node will assume control of the cluster and will take over the cluster’s IP
address. This will restore network service for clients of the cluster. Replication will stop as there is no
longer a primary node.
While the primary node is offline, the cluster will no longer be fault-tolerant. A subsequent failure of the
secondary node will leave the cluster inoperable.
See
“Recovering From a Temporary Outage”
in this chapter for instructions on recovering a cluster in
this state.
The secondary node has taken over the cluster services. The primary node is back online, but the
cluster needs to be recovered.
In this state, the primary node was offline for a period of time greater than the downtime threshold, and
then recovered. The cluster has failed over to the secondary node.
In this state, the cluster is not fault-tolerant. A subsequent failure of the secondary node will leave the
cluster inoperable.
Recovering the cluster is required for replication to resume and return the cluster to a fault-tolerant state.
See
“Recovering From a Temporary Outage”
in this chapter for instructions on recovering a cluster in this
state.
Secondary Node Failure
If the cluster’s secondary node fails, the cluster status will be displayed on the primary node as:
The primary node is running, but the secondary node is down or stopped.
Summary of Contents for Amigopod 3.7
Page 1: ...Amigopod 3 7 Deployment Guide...
Page 14: ...14 Amigopod 3 7 Deployment Guide...
Page 30: ...30 Management Overview Amigopod 3 7 Deployment Guide...
Page 108: ...108 RADIUS Services Amigopod 3 7 Deployment Guide...
Page 132: ...132 Operator Logins Amigopod 3 7 Deployment Guide...
Page 240: ...240 Guest Management Amigopod 3 7 Deployment Guide...
Page 332: ...332 Administrator Tasks Amigopod 3 7 Deployment Guide...
Page 336: ...336 Administrator Tasks Amigopod 3 7 Deployment Guide...
Page 345: ...Amigopod 3 7 Deployment Guide Hotspot Manager 345...
Page 362: ...362 High Availability Services Amigopod 3 7 Deployment Guide...
