PingFederate’s cluster-protocol services manage discovery, cluster messaging, connectivity failure detection, membership, and merging of split clusters. Nodes in the cluster must be able to communicate with one another over both the cluster bind port and the cluster failure detection port.

Important:

This communication requirement remains true regardless of the chosen cluster discovery method or runtime state-management architecture.

Cluster discovery

PingFederate supports two cluster discovery methods.

Static discovery
The static discovery method is suitable for a small cluster with about five to six engine nodes. Configuration requires no external component. Each node must be configured with at least one expected node in a cluster. In practice, the initial discovery list should contain all nodes known in advance in the cluster (including itself) to increase the likelihood of new members finding and joining the cluster.
Dynamic discovery
The dynamic discovery method is well suited for environments where traffic volume may spike and require additional resources during the peak period to handle the increased traffic. Instead of configuring a static list of known nodes ahead of time, new nodes are configured to pull cluster membership information from a centralized repository. Because it is crucial that the information is safely stored and readily accessible by all nodes, PingFederate supports IAM roles for Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), and OpenStack Swift. The dynamic discovery method requires only a one-time setup. Once configured, no coordination effort is required to maintain a static discovery list.

Regardless of the discovery method, as individual nodes join and leave the cluster, the cluster-protocol service synchronizes the new membership information across all nodes.

Failure detection

The failure detection mechanism detects network connectivity issues and updates the cluster with the new membership information. The mechanism does so by establishing TCP connections with other nodes at their cluster failure detection ports and sending network messages occasionally. When a node detects a failure, it propagates such condition to other nodes. As a result, the new cluster membership information is shared across the cluster.

Important:

If any networking devices, such as a firewall, are deployed between nodes, they must be configured to allow inbound TCP connections to the cluster failure detection ports and not to terminate these connections based on their potentially low volumes of network activities.