Cluster protocol architecture
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. 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
-
Static discovery is suitable for a small cluster with about five to six engine nodes. Configuration requires no external component. You must configure each node 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
-
Dynamic discovery is well-suited for environments where traffic volume may spike and require additional resources during peak hours. Instead of configuring a static list of known nodes ahead of time, configure new nodes to pull cluster membership information from a centralized repository. Because safe storage and ready accessibility of the information by all nodes is crucial, 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, maintaining a static discovery list requires no coordination effort.
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 failures by establishing TCP connections with other nodes at their cluster failure detection ports and sending occasional network messages. When a node detects a failure, it propagates the condition to other nodes, sharing new membership information across the cluster.
If you deploy any networking devices, such as a firewall, between nodes, you must configure them 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. |