Automated environments

To maintain identically configured PingDataGovernance Server instances behind your load balancer, use DevOps principles of Infrastructure-as-Code (IaC) and Automation. For more information about using server profiles to scale upward by installing a new, identically configured instance of PingDataGovernance Server, see (Optional) Configuring PingDataGovernance using server profiles.

Non-automated environments

For customers without infrastructure and configuration automation, PingDataGovernance supports intra-cluster communication to maintain consistent configuration more easily among PingDataGovernance Server instances behind your network load balancer. You enable intra-cluster communication by running setup using peer setup options such as --peerHostName and --peerPort.


The clustering model is deprecated and will be removed in a future release. For more information, contact Ping Professional Services.

In this model, the server instances are joined into a topology configuration that automatically enables the grouping of servers as well as the mirroring of configuration changes. To mirror shared data across a topology, this model uses a primary/secondary architecture. All writes and updates are forwarded to the primary server, which forwards them to all other servers.
  • Changes to clustered configurations are not allowed in mixed-version clusters. This applies to configuration in the cn=Cluster,cn=config subtree and only applies to servers with matching cluster names. Consider this when updating multiple servers in a cluster.
  • To make clustered configuration changes in a mixed-version cluster, choose one of the following options:
    • Update each server to the same version.
    • Temporarily split up the cluster by changing the cluster-name property on the server instance configuration objects.
  • After you have updated all the servers to the same version, you can again make clustered configuration changes and those changes will mirror across the topology.