Provision and enable a replica

Provisioning a replica duplicates specific components and services from the primary server to the replica. Enabling a replica activates most of its duplicated services and components, and instructs agents and infrastructure nodes how to communicate in a failover scenario.

1. Configure infrastructure agents to connect orchestration agents to the primary server.
   1. In the console, click Node groups, and in the PE Infrastructure group, select the PE Agent > PE Infrastructure Agent group.
   2. If you manage your load balancers with agents, on the Rules tab, pin load balancers to the group.

      Pinning load balancers to the PE Infrastructure Agent group ensures that they communicate directly with the primary server.

   3. On the Classes tab, find the puppet_enterprise::profile::agent class and specify these parameters:

      Parameter	Value
      manage_puppet_conf	Specify true to ensure that your setting for server_list is configured in the expected location and persists through Puppet runs. This is the default value.
      pcp_broker_list	Hostname for your primary server. Hostnames must include port 8142, for example ["PRIMARY.EXAMPLE.COM:8142"].
      primary_uris	Hostname for your primary server, for example ["PRIMARY.EXAMPLE.COM"]. This setting assumes port 8140 unless you specify otherwise with host:port.
      server_list	Hostname for your primary server, for example ["PRIMARY.EXAMPLE.COM"]. This setting assumes port 8140 unless you specify otherwise with host:port.

   4. Remove any values set for pcp_broker_ws_uris.
   5. Commit changes.
   6. Run Puppet on all agents classified into the PE Infrastructure Agent group.
2. On the primary server, as the root user, run puppet infrastructure provision replica <REPLICA NODE NAME> --enable

   The default replica --enable command adds the replica to your PE Agent node group's server list, which causes all Puppet.conf files to include the new server. However, if you include the --skip-agent-config flag, the replica is added to the server list of the PE Infrastructure Agent node group (which is a child of the PE Agent node group); this, by extension, impacts only the Puppet.conf files on your infrastructure nodes (including compilers).

   In installations with compilers, use the --skip-agent-config flag with --enable if you want to:

   • Upgrade a replica without needing to run Puppet on all agents.
   • Add disaster recovery to an installation without modifying the configuration of existing load balancers.
   • Manually configure which load balancer agents communicate with in multi-region installations. See Managing agent communication in multi-region installations.

3. Copy your secret key files from the primary server to the replica.

   The secret key files are located at:

   • /etc/puppetlabs/orchestration-services/conf.d/secrets/keys.json
   • /etc/puppetlabs/orchestration-services/conf.d/secrets/orchestrator-encryption-keys.json
   • /etc/puppetlabs/console-services/conf.d/secrets/keys.json
   If you do not copy your secret key files onto your replica, the replica generates new secret key files when you promote it. This prevents you from accessing LDAP, and prevents services from accessing encrypted information in PE databases.
4. Verify that the contents of the global layer Hiera file on the new replica, located at /etc/puppetlabs/puppet/hiera.yaml, match the contents of the global layer Hiera file on the primary server.
   • If necessary, update hiera.yaml on the replica to match hiera.yaml on the primary server.
   • If you use code to manage the contents of hiera.yaml on the primary server, ensure that the new replica is also classified to manage the contents of its own hiera.yaml file.
5. Optional: Verify that all services running on the primary server are also running on the replica:
   1. From the primary server, run puppet infrastructure status --verbose to verify that the replica is available.
   2. From any managed node, run puppet agent -t --noop --server_list=<REPLICA HOSTNAME>. If the replica is correctly configured, the Puppet run succeeds and shows no changed resources.
6. Optional: Deploy updated configuration to agents by running Puppet, or wait for the next scheduled Puppet run.

   If you used the --skip-agent-config option, you can skip this step.

   If you use the direct Puppet workflow, where agents use cached catalogs, you must manually deploy the new configuration by running:

   puppet job run --no-enforce-environment --query 'nodes {deactivated is null and expired is null}'

7. Optional: Perform any tests you feel are necessary to verify that Puppet runs continue to work during failover. For example, to simulate an outage on the primary server:
   1. Prevent the replica and a test node from contacting the primary server. For example, you might temporarily shut down the primary server or use iptables with drop mode.
   2. Run puppet agent -t on the test node. If the replica is correctly configured, the Puppet run succeeds and shows no changed resources. Runs might take longer than normal when in failover mode.
   3. Reconnect the replica and test node.

Related information

• Generate a token using puppet-access
• Configure settings with Hiera
• Back up your infrastructure
• Running Puppet on nodes