When using a replica administrative node, you must define a key pair to use for the CONFIG QUERY listener that includes both the administrative node and the replica administrative node. You can do this either by using a wildcard certificate or by defining subject alternative names in the key pair that include the replica administrative node's DNS name. If you use a replica administrative node in your configuration, configure the replica administrative node before defining the engine nodes, or the bootstrap.properties files generated for the engine nodes will not include information about the replica administrative node.

In addition to the configuration below, the Replica Administrative node includes a status indicator that indicates the health of the node and a read-only Last Updated field that indicates the date and time of the last update. The status indicator can be green (good status), yellow (degraded status), or red (failed status).

The status is determined by using the value for admin.polling.delay as an interval to measure health:
Green (good status)
The replica administrative node contacted the primary administrative node on the last pull request.
Yellow (degraded status)
The replica administrative node contacted the primary administrative node between 2 and 10 intervals.
Red (failed status)
The replica administrative node has either never contacted the primary administrative node, or it has been more than 10 intervals since the nodes communicated.
Note:

If you are configuring a replica administrative node in the environment, that must be done before you configure the engines.

  1. Click Settings and then go to Clustering > Administrative Nodes.
  2. In the Host field in the Replica Administrative Node section, enter the host and port for the replica administrative node.
    This name and port pair must match either a subject alternative name in the key pair or be considered a match for the wildcard specified if the key pair uses a wildcard in the common name.
  3. If applicable, specify an HTTP Proxy for the engine. Click + Create to create an HTTP proxy.
  4. If applicable, specify an HTTPS Proxy for the engine. Click + Create to create an HTTPS proxy.
  5. Specify the Replica Administrative Node Trusted Certificate to use for cases where a TLS-terminating network appliance, such as a load balancer, is placed between the engines and the admin node.
  6. Click Save & Download to download the <replicaname>_data.zip file for the replica administrative node.
    PingAccess automatically generates and downloads a public and private key pair into the bootstrap.properties file for the node. The Public Key is indicated in this window.
  7. Copy the downloaded file to the replica administrative node's <PA_HOME> directory and unzip it.
  8. If the replica administrative node is running on a Linux host, execute the command chmod 400 conf/pa.jwk.
  9. Edit <PA_HOME>/conf/run.properties on the replica administrative node and change the pa.operational.mode value to CLUSTERED_CONSOLE_REPLICA.
  10. Start the replica administrative node.
  11. Verify replication has completed by monitoring the <PA_HOME>/log/pingaccess.log file and looking for the message "Configuration successfully synchronized with administrative node".