Amigopod 3.7
| Deployment Guide
High Availability Services |
359
6. Recovery is complete. The secondary node is now the new primary node for the cluster. The cluster is
back in a fault-tolerant mode of operation.
The Recover Cluster command will only work if the node that failed is brought back online with the same
cluster configuration. This is normally the case in all temporary outages. See
“Recovering From a
Hardware Failure”
in this chaper, in this case, for a description of how to recover the cluster.
Recovering From a Hardware Failure
If the failed node has been replaced, the cluster configuration will no longer be present on that node. To
recover the cluster, first ensure that the replaced node is ready to rejoin the cluster, then destroy the cluster
and recreate it.
Use the following procedure to rebuild the cluster:
1. This procedure assumes that the primary node has failed and has been replaced.
2. Configure the network settings, subscription IDs and hostname for the replacement primary node.
3. Ensure that the replacement primary node and the secondary node are both online.
4. Log into the secondary node. (Due to failover, this node will be assigned the cluster’s virtual IP address.)
5. Click Cluster Maintenance, and then click the
Destroy Cluster
command link.
6. A progress meter is displayed while the cluster is destroyed. The virtual IP address of the cluster will be
unavailable until the cluster is reinitialized.
7. Click the
Create New Cluster
command link.
8. Recreate the cluster.
See
“Cluster Setup”
in this chapter for a description of the process. Note that
the new cluster’s primary node must be the former cluster’s secondary node that you are presently
logged into.
9. When the cluster is initialized, the database and configuration is replicated to the replacement primary
node.
10. Recovery is complete. The cluster’s virtual IP address is now available, and the secondary node is now
the new primary node for the cluster. The cluster is back in a fault-tolerant mode of operation.
A similar procedure can be used to rebuild the cluster in the event of a secondary node suffering a hardware
failure.
Performing Scheduled Maintenance
Routine maintenance tasks such as a server reboot or shutdown may occasionally be required for a server
that is part of a cluster.
These tasks may be performed by ensuring that the server is the secondary node in the cluster. If the
secondary node goes offline, the primary node will be unaffected and the cluster will continue to provide
network services without interruption. When the secondary node comes back online, the cluster will be
automatically rebuilt and replication will resume.
The
Recover Cluster
action is available from
either
node, and will make that node the new primary node for the
cluster. To return the primary node back to its original status as the primary node in the cluster, you can use the
Swap Primary Servers
command.
See
“Performing Scheduled Maintenance”
in this chaper for an explanation.
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...