Destroying A Cluster; Cluster Troubleshooting - Aruba Networks PowerConnect W Clearpass 100 Software Deployment Manual

Use this procedure to make the current primary node the secondary node:
1. Log into the current secondary node of the cluster.
2. Click Cluster Maintenance, and then click the Swap Primary Server command link.
3. A progress meter is displayed while the primary node is switched.
NOTE
The cluster's virtual IP address will be temporarily unavailable while the swap takes place.
4. The swap 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.
5. Perform any required maintenance on the new secondary node.

Destroying a cluster

The Destroy Cluster command link is used to shut down a cluster and return to
independent nodes.
Immediately after the cluster is destroyed, both nodes will have the same database and
configuration state. However, changes on one node will no longer be replicated to the
other node as the cluster is no longer functioning.
NOTE Avoid using this command when you are accessing the cluster using its virtual IP address,
as the virtual IP address will no longer be available when the cluster has been destroyed.

Cluster troubleshooting

When building a cluster, use the recommended values for the downtime threshold, keep-
alive rate and configuration sync rate. You should only change these values if you have a
specific requirement and have verified that different values can be used to meet that
requirement.
To avoid unexpected fail-over of the cluster, ensure that the network connection to the
nodes of the cluster is always available. Use high quality network equipment, including
cables, and secure physical access to the servers to prevent accidental dislodgement of
cables.
If network access to the cluster is intermittent, this may indicate a possible hardware
failure on the current primary node. In this situation, you may either use the Swap Primary
Server command to make the secondary node the new primary node, or you can cause the
cluster to fail-over to the secondary by disconnecting the primary node.
Brief network outages are permissible and will not cause fail-over, provided that the
network outage is shorter than the downtime threshold of the cluster.
During a fail-over from the primary to the secondary node, the network services provided
by the cluster will be unavailable. The time that the cluster will be offline is bounded by
18| High Availability Deployment Guide Amigopod |Technical Note