Deploying cluster servers
A PingFederate cluster consists of multiple nodes, each of which is likely running on a dedicated host system.
In a cluster, there are two types of nodes: engine nodes and admin console nodes. Engine nodes service end-user traffic, and multiple nodes are recommended to ensure high availability for your deployment. Only one admin console node can be active in a given cluster. This node provides the user interface and administrative API that you can use to configure the cluster. Additionally, the admin console node manages the following runtime functions:
-
Performing periodic configuration archive backup
-
Cleaning expired persistent authentication sessions
-
Cleaning expired access grants
-
Updating connections from metadata URLs, including PingOne SP connections if configured, and sending email notifications
-
Performing automatic rotation of signing certificates if enabled
|
Additional steps are required to set up failover for provisioning. If you are grouping servers exclusively to provide for provisioning failover, skip these steps and refer to Deploy provisioning failover. |
These steps describe how to configure and deploy clustered PingFederate servers by editing the <pf_install>/pingfederate/bin/run.properties file on each node.
Steps
-
Install PingFederate on each server in a cluster.
-
Edit the clustering properties of each node in the
<pf_install>/pingfederate/bin/run.propertiesfile. Refer to Clustering properties for information about each property. -
(Optional) Edit configuration files in each node that control the cluster protocol and runtime state-management service. Learn more in Runtime state-management architectures and Runtime state-management services.
-
(Optional) If outbound provisioning is configured for your site and you want to provide failover capabilities, identify and configure the provisioning failover nodes. Learn more in Deploy provisioning failover.
-
Start or restart PingFederate on all nodes.
-
Sign on to the admin console.
-
If you haven’t done so, import your PingFederate license. Learn more in License management.
-
On the System > Server > Cluster Management page, click Replicate Configuration to push the license information from the console node to all engine nodes.
Result
After you set up the clustered environment, you can start configuring PingFederate through the admin console. When PingFederate detects a change, it prompts you to replicate the configuration to all engine nodes.
Clustering properties
The <pf_install>/pingfederate/bin/run.properties file contains the following properties for configuring cluster nodes:
| Property | Description | ||||
|---|---|---|---|---|---|
|
Controls the operational mode of the PingFederate server. PingFederate supports the following modes:
|
||||
|
Defines a unique index number for the server in a cluster. The index number is used to identify peers and optimize inter-node communication. The allowed range is If no value is set for the node index, the system assigns an auto-generated value in the range of This property has no default value. If you specify an index number, you can configure instances of the Cluster Node Authentication Selector and place them in authentication policies to customize authentication requirements based on the runtime node servicing a request. |
||||
|
Sets the password that each node in the cluster must use to authenticate when joining the cluster. This prevents unauthorized nodes from joining a cluster. You can leave this value blank, but all nodes in the cluster must have the same value. You can also use the
All nodes in a cluster must share the same value, blank or otherwise. If you use an obfuscated or utility-generated value, engine nodes must contain the relevant key material from the console node’s |
||||
|
Indicates whether to encrypt network traffic sent between nodes in a cluster. The possible values are When set to
All nodes in a cluster must have the same value for this property. If you use an obfuscated or utility-generated value, learn more in Configuring cluster encryption and authentication. |
||||
|
The key length PingFederate uses when deriving the symmetric key from All nodes in a cluster must have the same value set for this property. The default value is |
||||
|
Defaults to You can use this property to increase performance (particularly with UDP) and improve security by segmenting cluster-communication traffic onto a private network or VLAN.
|
||||
|
Specifies the port associated with the This is the port used by other cluster members during their discovery process, usually via the The default value is |
||||
|
Indicates the bind port of a server socket that’s opened on the given node and used by other nodes as part of the cluster’s failure-detection mechanisms. If set to |
||||
|
Indicates the transport protocol used for cluster communication. Values are Use UDP when IP multicasting is enabled in the network environment and the majority of cluster traffic is point-to-full-group. You must also configure both the Use TCP for geographically dispersed servers or when multicast isn’t available, for example, when using routers that don’t support multicast messaging. TCP might also be appropriate if your cluster configuration employs more point-to-point or point-to-few messaging than point-to-group. You must also configure the
|
||||
|
Defines the IP address shared among nodes in the same cluster for UDP multicast communication; required when UDP is set as the transport protocol. The valid range is All nodes in a cluster must have the same value set for this property. The default value is 239.16.96.69. |
||||
|
Defines the port in conjunction with the All nodes in a cluster must have the same value set for this property. The default value is |
||||
|
Designates a static list of PingFederate servers to be contacted for cluster membership information when discovering, joining, and rejoining the cluster. This value is required when TCP is set as the transport protocol. The value is a comma-separated list of host names (or IP addresses) and their cluster bind ports, for example, When using static discovery, add at least one node for the cluster to know in advance. This property should contain all nodes in the cluster (including itself) to increase the likelihood of new members finding and joining the cluster. When using dynamic discovery, leave this property blank and enable dynamic discovery in the |
||||
|
Indicates whether runtime state-management services should use the adaptive clustering architecture. The default value is |
||||
|
The default value is |
||||
|
The multicast address and port this node listens on for diagnostic messages. The default values are |
||||
|
Defines the tags associated with this node. Configuration is optional. When configured, PingFederate considers this property when processing requests. For example, you can use tags to determine the datastore location that this PingFederate node communicates with. You can also use tags in conjunction with authentication selectors and policies to define authentication requirements. Node tags only apply to engine nodes (CLUSTERED_ENGINE). If you configure a node tag for the admin node (CLUSTERED_ADMIN), it won’t appear in the Cluster Management overview. You can specify one tag. node.tags=north You can also specify a list of prioritized, space-separated tags. node.tags=1 123 234 Tags can’t contain spaces. |