Amigopod High Availability Deployment Guide
Copyright © 2011 Aruba Networks, Inc. Aruba Networks trademarks include Airwave, Aruba Networks®, Aruba Wireless Networks®, the registered Aruba the Mobile Edge Company logo, Aruba Mobility Management System®, Mobile Edge Architecture®, People Move. Networks Must Follow®, RFProtect®, Green Island®. All rights reserved. All other trademarks are the property of their respective owners.
Table of Contents Introduction ........................................................................................................................................ 4 Audience .......................................................................................................................................... 4 Document Overview ......................................................................................................................... 4 About High Availability ..........................
1 Introduction This technical note describes the process of setting up a high-availability cluster of Amigopod Visitor Management Appliances. Audience This document is intended for network administrators and system integrators deploying an Amigopod-based visitor management solution. Basic familiarity with the Amigopod Visitor Management Appliance is assumed. For indepth information about the features and functions of the Amigopod appliance, refer to the Amigopod Deployment Guide.
2 About High Availability Terminology & concepts A cluster consists of a primary node and a secondary node, configured so that a failure of either node will not prevent the cluster as a whole from performing its normal functions. The primary node is the active server in a cluster. The cluster’s network services are always delivered by the primary node. The secondary node is the backup server in a cluster.
Diagram 1: Network architecture of high availability cluster The key points to note about this architecture are: • The RADIUS and web server protocols (HTTP and HTTPS) are supported by the cluster. • The cluster has three IP addresses: each node has its own IP address, and there is a virtual IP address for the cluster which will always be assigned to the primary node in the cluster.
In this state, the primary node is assigned the cluster IP address and is responsible for delivering network services to clients. Each node is also continuously performing failure detection, database replication and configuration replication, as explained below. Failure detection Failure detection is accomplished using a keep-alive test. The primary and secondary nodes verify that each is able to communicate with the other node by sending network requests and answering with a response.
The configuration items that are replicated include: • Configuration for installed plugins • Fields defined in Guest Manager • Forms and views defined in Guest Manager • Guest self-registration pages • Instances of reports that have previously been run • LDAP authentication servers and translation rules • Network login access configuration • Operator login configuration • Operator logins • Operator profiles • Print templates defined in Guest Manager • Publicly-accessible web server i
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 fail-over will be initiated after the primary node has been offline for the downtime threshold, which is 30 seconds by default.
Cluster status The current status of the cluster is shown at the top of each page that is related to High Availability Services. Refer to this table for an explanation of each possible status, and the recommended action to take, if any. Status Description This system is not part of a high availability cluster. To create a new cluster and make this server the primary node, use the Create New Cluster command. To join a cluster and make this server the secondary node, use the Join Cluster command.
The primary node is running, but a problem has been detected. Check the detailed status information. The primary node is running, but the secondary node is reporting a problem. Check the detailed status information. The cluster is recovering from a failure. Check the detailed status information. The cluster is currently being initialized. Check the detailed status information. Status call timed out. Server may be down. This message may be displayed if the node cannot be contacted.
3 Configuring High Availability Check plugin versions Deploying a High Availability cluster requires the following plugin versions: • High Availability Services 0.9.14 or later To verify you have the correct plugin versions installed, navigate to Administrator > Plugin Manager > List Available Plugins and check the version number in the list. Use the Check for Plugin Updates link to download and install updated plugins.
If you have not already set a unique hostname for this server, you can do so here. Each node in the cluster must have a unique hostname. You must enter a shared secret for this cluster. The shared secret is used to authenticate the messages sent between the nodes in the cluster. The downtime threshold parameter explained in section 0 may be specified on this form. Click the Save and Continue button to prepare the primary node.
Click the Prepare Node button to save and verify the settings for the secondary node. Cluster initialization To complete the setup of the cluster, return to the primary node after preparing the secondary node and click the Confirm Node Settings button. The Cluster Initialization form is displayed. Select the checkbox and click the NOTE Initialize Cluster button to proceed.
particularly if you are rebuilding the cluster. If in doubt, it is recommended that you perform a complete backup of both nodes prior to initializing the cluster. Several status messages and a progress meter will be displayed while the cluster is initialized, which may take several minutes depending on the amount of data to be replicated.
• A hardware failure is a fault that to correct requires rebuilding or replacing one of the nodes of the cluster. The table below lists some system failure modes and the corresponding cluster maintenance that is required.
This procedure assumes that the primary node has failed and has been replaced. NOTE 1. Configure the network settings, subscription IDs and hostname for the replacement primary node. 2. Ensure that the replacement primary node and the secondary node are both online. 3. Log into the secondary node. (Due to fail-over, this node will be assigned the cluster’s virtual IP address.) 4. Click Cluster Maintenance, and then click the Destroy Cluster command link. 5.
Use this procedure to make the current primary node the secondary node: NOTE 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. 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 downtime threshold. This can be used to calculate the expected availability of the cluster. The Restart Cluster Services and Stop Cluster Services command links on the Cluster Maintenance page may be used to test fail-over conditions by simulating a cluster failure. NOTE Avoid using these commands when you are accessing the cluster using its virtual IP address, as the virtual IP address may become unavailable. The View Log Files command link allows the internal state of the cluster to be viewed.
