Clustering

A3 clusters provide load balancing and failover. There are some basic rules when using A3 clustering:

• Servers that form a cluster should always be installed using odd numbers, that is 3, 5, 7.
• Servers should not be installed on the same platform. Where possible they should use separate independent power sources and be connected to separate switches.
• Servers must all be on the same LAN segment (Layer 2 connectivity).
• Vmotion should not be used on a live system as it might suspend all cluster operation for a minute or more.

Each server in a cluster is referred to as a member. Cluster installation is straightforward:

1. Install the first member using the New Deployment option. This member is referred to as the primary.
2. Install subsequent members using the Join Cluster option (instead of New Deployment).
   1. Provide the address of the primary, and the administrator name and password used to install the primary.
   2. During the initial network configuration, the IP addresses of the registration and Isolation networks must be set to values that are different from any other member. For example, if the primary's registration network IP address is 10.100.100.1, then an additional member's IP address can be 10.100.100.2.
3. Clusters must be managed using the VIP (virtual IP) address instead of individual member addresses. The VIP address is the IP address assigned to the first A3 server installed in the cluster.
4. Configure network devices, including Extreme NetworksAPs configured through ExtremeCloud IQ, to use the VIP address of the cluster as their RADIUS server.

You can monitor and manage clusters from multiple A3 administration pages:

• The Status page displays informational graphs for each member.
• The Cluster State option on the Status page displays a column for each member's services.
• The System Configuration > Cluster page shows the cluster members and their states.

During normal operation network devices and APs send their RADIUS requests to the VIP address of the cluster. The acting primary then distributes the requests to one of the members.

If a cluster member fails, the primary stops using that member and sends an alert to the administrator.

If the cluster primary fails, one of the other members is automatically elected as the new primary. When the original primary again becomes active on the network, it thinks that it is still the primary. The other cluster members then vote on which of these two will become the new primary.

When advised to restart any A3 service, the administrative interface for each cluster member must be used individually to perform the operation. Restart services in each member one at a time, waiting for all services to completely restart.

The best way to shut down all members is to shut down the non-primary members first, then shut down the primary last. Restart the cluster devices using the opposite process (start the primary first, then the cluster members). For example, if there are three members named 1, 2, and 3 with 1 as the primary, then you should shut down using the order 3, 2, 1, and restart should in the order 1, 2, 3.

For each shutdown or restart step, make sure that operation has completed before starting the next step.

Note

Do not take a snapshot of a running member. This will temporarily cause it to halt and result in service disruption and a corrupt snapshot. To make an appropriate snapshot, stop the VM first.