Clustering in PingAccess

PingAccess provides clustering features that allow a group of PingAccess servers to appear as a single system.

Server clustering can facilitate high availability of critical services and can also increase performance and overall system throughput. However, availability and performance are often at opposite ends of the deployment spectrum. You might need to make some configuration tradeoffs that balance availability with performance to accommodate specific deployment goals.

Settings in the configuration file could affect the features documented here. For more information, see the Configuration file reference guide.

Components of a PingAccess Cluster

PingAccess clusters are made up of three types of nodes:

The Administrative Node: Provides the administrator with a configuration interface.
The Replica Administrative Node: Provides the administrator with the ability to recover a failed administrative node using a manual failover procedure. For more information, see Manually promoting the replica administrative node.
The Engine Nodes: Handle incoming client requests and evaluate policy decisions based on the configuration replicated from the administrative node.

You can configure any number of engine nodes in a cluster, but you can configure only one administrative node and one replica administrative node in a cluster. State information is not shared between engine nodes.

Configuration information from the administrative console and API is replicated to all of the engine nodes and the replica administrative node from the administrative node, as is the license file on the administrative node. Engine nodes do not require a license to function, but some default templates look different depending on the information in the license.

You should manage incoming traffic to the engine nodes using load balancers or other mechanisms. PingAccess clusters do not dynamically manage or load-balance request traffic to individual engine nodes. eoc1564006721359

Node failure implications

Node failure within a PingAccess cluster can have short-term or long-term implications for your environment, depending on the state of your network and the type of node or nodes that failed. The following table describes some common node issues and recommends what kind of action to take.

Node issue	Result	Recommendation
Administrative node failure	The engine nodes can function using their stored configurations but cannot update their configurations.	Fail over to the replica administrative node until the administrative node can be restarted.
Replica administrative node failure	The engine nodes and administrative node can function normally, but you won’t be able to fail over to the replica administrative node if something happens to the administrative node.	Restart the replica administrative node as soon as possible.
Administrative and replica node failure	The engine nodes can function using their stored configurations, but cannot update their configurations. No failover option is available.	Restart the administrative node as soon as possible, or restart the replica administrative node and fail over to it.
One or more engine nodes cannot reach the administrative node	Affected engine nodes can function using their stored configurations, if any but cannot update their configurations. If the administrative node performs key rolling, the affected engine nodes cannot recognize the new PingAccess internal cookie.	Restore access to the administrative node as soon as possible.

Node issue

Result

Recommendation

Administrative node failure

The engine nodes can function using their stored configurations but cannot update their configurations.

Fail over to the replica administrative node until the administrative node can be restarted.

Replica administrative node failure

The engine nodes and administrative node can function normally, but you won’t be able to fail over to the replica administrative node if something happens to the administrative node.

Restart the replica administrative node as soon as possible.

Administrative and replica node failure

The engine nodes can function using their stored configurations, but cannot update their configurations. No failover option is available.

Restart the administrative node as soon as possible, or restart the replica administrative node and fail over to it.

One or more engine nodes cannot reach the administrative node

Affected engine nodes can function using their stored configurations, if any but cannot update their configurations. If the administrative node performs key rolling, the affected engine nodes cannot recognize the new PingAccess internal cookie.

Restore access to the administrative node as soon as possible.

Cluster properties

Use the run.properties and bootstrap.properties files to configure your environment.

In a cluster, you can configure each PingAccess node to serve as either an administrative node, a replica administrative node, or an engine node in the run.properties file. The run.properties file for the administrative node also contains server-specific configuration data.

At startup, a clustered PingAccess engine node checks its local configuration and then makes a call to the administrative node to check for changes. You can configure how often each engine node in a cluster checks the administrative node for changes in the engine run.properties file.

Information needed to bootstrap an engine node is stored in the bootstrap.properties file on each engine node.

bootstrap.properties
Property	Description
`engine.admin.configuration.host`	Defines the host where the administrative console is available. The default is `localhost`.
`engine.admin.configuration.port`	Defines the port where the administrative console is running. The default is `9000`.
`engine.admin.configuration.userid`	Defines the name of the engine.
`engine.admin.configuration.keypair`	Defines an elliptic curve key pair that is in the JSON Web Key (JWK) format.
`engine.admin.configuration.bootstrap.truststore`	Defines the trust store, in JWK format, that is used for communication with the administrative console.

You can tune the cache using the EHCache Configuration Properties, pa.ehcache.*, listed in the Configuration file reference guide.

Cluster node status

The administrative console provides two important visual elements which communicate the current status of the replica administrative node and the engine nodes:

A status indicator, which communicates whether the node is healthy.
A Last Updated field, which communicates the date and time that the node was last updated.

You can find this information on the Administrative Nodes page and the Engines page.

Status indicators use the value for <admin.polling.delay> as an interval to measure node health. A node’s status can be green (good status), yellow (degraded status), or red (failed status):

Green (good status): The node contacted the administrative node on the last pull request.
Yellow (degraded status): The node contacted the administrative node between 2 and 10 intervals.
Red (failed status): The node has either never contacted the administrative node or it has been more than 10 intervals since the nodes communicated.

Using multiple network interface cards to route traffic

PingAccess binds to all network interfaces by default to support routing traffic over multiple network interfaces. The default bind address PingAccess uses is 0.0.0.0. To prevent PingAccess from binding to all network interfaces, you can edit one or more of the following parameters in the conf/run.properties file:

admin.bindAddress=0.0.0.0
clusterconfig.bindAddress=0.0.0.0
engine.http.bindAddress=0.0.0.0
agent.http.bindAddress=0.0.0.0

Specify a new bind address for the parameter that you want to modify.