Dynamic discovery is well suited for environments where traffic volume may spike and
require additional resources during the peak period to handle the increased traffic.
This elastic scaling capability helps you to bring additional PingFederate engine nodes
online with no additional configuration changes after the initial setup. PingFederate
provides five dynamic discovery choices: AWS_PING
,
S3_PING
, SWIFT_PING
,
NATIVE_S3_PING
, and DNS_PING
.
With AWS_PING
, you scale your PingFederate infrastructure using
Amazon Elastic Compute Cloud (Amazon EC2) instances in the Amazon Web Service (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. It is
worth noting that permissions to ec2:Describe*
actions must either
be enabled in the AWS Identity and Access Management (IAM) role assigned to the EC2
instance or be associated with the access_key that you provide
as part of the dynamic discovery configuration. Furthermore, you may also use a
combination of tags and filters, in which
case only EC2 instances that satisfy both criteria are returned.
With S3_PING
, SWIFT_PING
, and
NATIVE_S3_PING
, you have 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 reach out and 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 AWS SDK and provides a more 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
are running in AWS but not 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 about DNS_PING
, see http://www.jgroups.org/manual4/index.html#_dns_ping.
Dynamic discovery configuration is maintained in the tcp.xml file, located in the <pf_install>/pingfederate/server/default/conf directory. No effort is required to maintain the pf.cluster.tcp.discovery.initial.hosts property in the run.properties file.
You must manually configure or synchronize the dynamic discovery properties in the tcp.xml file on each node. The tcp.xml file is not synchronized automatically across the nodes in a cluster; it is also not part of the Replicate Configuration process. PingFederate servers must be restarted if running.
After the initial setup, your nodes are ready to be deployed, undeployed, and redeployed as traffic volume changes.
It is worth mentioning that discovery mechanisms are separated from runtime state-management architectures. Discovery mechanisms determine how to find nodes to retrieve cluster information for the purpose of joining and rejoining such cluster. Runtime state-management architectures determine to and from which nodes session-state information is shared and fetched.
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 additional information, see Runtime state-management architectures.