PingFederate Server

Dynamic cluster discovery

Instead of configuring a static list of known PingFederate nodes in advance, dynamic cluster discovery lets you configure new nodes to pull cluster membership information from a centralized repository.

Dynamic discovery is well-suited for environments where traffic volume could spike and require additional resources during peak hours. Because safe storage and ready accessibility of the information by all nodes is crucial, PingFederate supports identity and access management (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.

For information about configuring dynamic cluster discovery, see Enabling dynamic discovery for clustering.

Dynamic cluster discovery protocols

In addition to the static cluster discovery protocol, TCPPING, PingFederate supports the following dynamic discovery protocols:

  • NATIVE_S3_PING

  • DNS_PING

  • AWS_PING

  • SWIFT_PING

The S3_PING discovery method has been deprecated because of the Amazon Web Services (AWS) deprecation of the SigV2 signing method. When deployed in AWS, the recommended discovery method is NATIVE_S3_PING. See the JGroups documentation for alternatives when deployed in other environments.

NATIVE_S3_PING and SWIFT_PING enable the flexibility to use both public and private cloud storage. PingFederate maintains cluster membership information in a centralized repository, a bucket in Amazon Simple Storage Service (Amazon S3) or a container in an OpenStack infrastructure.

PingFederate contacts the repository for a list of nodes. If PingFederate receives at least one node, a cluster exists, and it joins the cluster and updates the repository with its information, including its IP address. If PingFederate receives no node, it forms a new cluster and updates the repository with its information so that the next node can find the new cluster. When PingFederate shuts down, it removes itself from the list and pushes an update to the repository.

NATIVE_S3_PING uses the AWS SDK and provides a stable connection by using built-in security features, such as obtaining credentials through IAM server instance profiles. This protocol is the recommended dynamic discovery mechanism when you’re running in AWS but aren’t using Kubernetes.

DNS_PING uses DNS A or SRV records to perform discovery. This protocol is the recommended dynamic discovery mechanism when using Kubernetes. For more information, see the JGroups documentation about the DNS_PING protocol.

AWS_PING lets you scale your PingFederate infrastructure using Amazon EC2 instances in the AWS cloud, in one or multiple regions. PingFederate queries AWS for a list of eligible EC2 instances. If PingFederate receives at least one node, a cluster exists, and it joins that cluster. If PingFederate receives no node, it forms a new cluster.

You must enable permissions to ec2:Describe* actions in the AWS IAM role assigned to the EC2 instance or associate them with the access_key parameter that you provide as part of the dynamic discovery configuration. You can also use a combination of tags and filters, in which case only EC2 instances that satisfy both criteria are returned.

Discovery mechanisms versus runtime state-management architectures

Discovery mechanisms are separate from runtime state-management architectures. Discovery mechanisms determine how to find nodes to retrieve cluster information for the purpose of joining and rejoining a cluster. Runtime state-management architectures determine which nodes session-state information is shared to and fetched from.

PingFederate supports adaptive clustering and directed clustering runtime state-management architectures. When opting for dynamic discovery, consider enabling adaptive clustering whenever possible. If multiple regions are involved, configure multi-region support for adaptive clustering as well. For more information and configuration steps, see Adaptive clustering.

Regardless of the chosen runtime state-management architecture, all nodes must still be able to communicate with other nodes for clustering-protocol messages. For more information, see Runtime state-management architectures.