Deploying An Ssl Certificate; Normal Cluster Operation; Failure Detection; Database Replication - Aruba Networks PowerConnect W Clearpass 100 Software Deployment Manual

There should be no routers, gateways, firewalls, or network address translation (NAT) between the two nodes.
Having nodes in different physical locations is not recommended and is not a supported configuration for the
cluster.

Deploying an SSL Certificate

Special consideration needs to be given to deployments that require SSL access to the cluster.
The Common Name (CN) of an SSL certificate must match the hostname of the site being visited.
Certificates that do not meet this requirement may still be used to secure the connection, but a browser
security warning is displayed. In modern browsers this warning is intended to deter users from what may be
a potentially serious "man in the middle" attack. Non-technical visitors should not be expected to analyze
and interpret these messages.
Where SSL access is a requirement, the recommended approach is to issue the certificate for the hostname
of the cluster's virtual IP address, and install the same certificate on both nodes.
This approach ensures that all operator and visitor access to the cluster is secured with a certificate that
matches the hostname and IP address, avoiding any unnecessary browser security warnings.
When using this approach, the administrator will receive browser security warnings about the certificate hostname
mismatch if he accesses each node individually.

Normal Cluster Operation

When the cluster is operating normally, the cluster status will be:
The cluster is running normally.
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. This takes place at the Keep Alive Rate specified in the cluster configuration, which by default is
once every 2 seconds.
If several consecutive keep-alive tests have failed, the cluster determines that a failure has occurred. A
cluster failover may then take place, depending on which node has failed. See
this chapter for information about a primary node failure, or
about a secondary node failure.
To avoid any network service interruptions, it is important that the nodes maintain an uninterrupted
network connection.

Database Replication

Database replication occurs continuously in a normally operating cluster. All database modifications,
including new guest accounts, changes to existing guest accounts, RADIUS roles, NAS servers, and RADIUS
accounting information, are replicated from the primary node to the secondary node. The replication delay
will depend on the volume of database updates and system load but is generally only a few seconds.
ClearPass Guest 3.9 | Deployment Guide
"Primary Node Failure"
"Secondary Node Failure"
High Availability Services |
in
for information
427