Latest revision as of 12:52, 11 May 2017

Overview

Swivel can be made to be resilient in a number of ways. Specific appliances are used for each setup and need to be specified at time of purchase. This document looks at the differing approaches. Configuration is carried out during the Networking setup of the appliances through the CMI. See also Swivel Deployment.

Prerequisites

Swivel 3.x

Types of Swivel Appliance resilience

Standalone

This is where there is no resilience and there is a single instance of Swivel.

Active/Active

This is a pair of Swivel appliances named Primary Master and Standby Master that are able to provide authentication. They are usually deployed at a single site. Resilience is provided by MySQL clustering using database replication. Note user data is replicated, not the Swivel configuration. Additional features include:

• A Virtual IP Address to allow a floating IP address to be attached to a Swivel appliance, which in the event of failure, can move to a second Swivel appliance on the same subnet. The VIP is bound to ETH0.

• Appliance Synchronisation and formerly Session Sharing allows a Single Channel TURing image request to be made from one Swivel server and an authentication request such as using RADIUS from another Swivel server.

• RADIUS Proxy from a Swivel server by RADIUS, this can be configured to make a request when a single channel authentication is made but no image has been requested, see PINsafe RADIUS Proxy

• Replication interface: Information is usually transferred across a dedicated network interface, on hardware appliances, a cross over cable is used on ETH1, and this provides the maximum resilience since there are no network devices between the appliances that can fail. Replication traffic may also be directed to run of ETH0 instead, with the loss of some resilience capability.

DR

The DR appliances are deployed at Disaster Recovery sites. They are not intended for use as day to day authentication. Resilience is provided by MySQL, the DR acting as a MySQL slave.

Active/Passive

This refers to one of two solutions:

• An older version of the Swivel HA solution using disk replication, where only one instance of a Swivel pair is active. It is limited to two Swivel servers at one site only. This solution is being phased out by the Active/Active solution and is no longer offered for sale. To verify which appliance version you have see Appliance_General_FAQ

• Enterprise HA, where by an appliance pair is Active/Passive and a second appliance pair is Active/Passive and uses MySQL across sites.

Types of Third Party resilience

External Database

An external database can be used with multiple Swivel servers connecting to the Database. This database should be clustered to provide resilience in itself.

Load Balancers

Load balancers may be deployed to provide resilience.

VM resilience

Additional tools may be deployed such as VMware VMotion to bring up another Swivel instance in the event of a failure

Testing

Known Issues

Troubleshooting

To check the HA VIP status see VIP Status

Heartbeat will not start see Heartbeat issues