Aruba Networks PowerConnect W Clearpass 100 Software Deployment Manual
High availability deployment guide technote
Hide thumbs
Also See for PowerConnect W Clearpass 100 Software:
- Deployment manual (518 pages) ,
- Manual (22 pages) ,
- Installation manual (12 pages)
Table of Contents
Advertisement
Quick Links
Advertisement
Table of Contents
Related Manuals for Aruba Networks PowerConnect W Clearpass 100 Software
Summary of Contents for Aruba Networks PowerConnect W Clearpass 100 Software
- Page 1 Amigopod High Availability Deployment Guide...
- Page 2 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.
-
Page 3: Table Of Contents
Table of Contents Introduction ............................4 Audience ............................4 Document Overview ......................... 4 About High Availability ........................5 Terminology & concepts ........................5 Network architecture ........................5 Operating a High Availability cluster ....................6 Normal cluster operation ......................6 Failure detection ........................... 7 Database replication ........................ -
Page 4: Introduction
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 in- depth information about the features and functions of the Amigopod appliance, refer to the Amigopod Deployment Guide. -
Page 5: About High Availability
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. -
Page 6: Operating A High Availability 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. -
Page 7: Failure Detection
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. -
Page 8: Primary Node Failure
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 •... -
Page 9: Secondary Node Failure
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. -
Page 10: Cluster Status
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. -
Page 11: Technical Considerations
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. -
Page 12: Configuring High Availability
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. -
Page 13: Prepare Secondary Node
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. -
Page 14: Cluster Initialization
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. -
Page 15: Cluster Deployment
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. -
Page 16: Recovering From A Temporary Outage
• 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. Failure Mode Maintenance Software failure –... -
Page 17: Performing Scheduled Maintenance
This procedure assumes that the primary node has failed and has been replaced. 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. -
Page 18: Destroying A Cluster
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. - Page 19 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.