Articles in this section

High-Availability (HA) with Automatic Failover

 Overview

JetPatch supports a High-Availability (HA) configuration with automatic failover. 

Upon JetPatch Manager Console failure, a load balancer automatically switches to a standby server with replicated data.

Note:

JetPatch is designed to allow critical functionality to remain operational even when the Manager Console is down during an automatic failover:

  • The JetPatch Connector running on all endpoints is independent of manager status — execution and monitoring of agent and patch management operations continue normally.
  • The primary activity unavailable during failover is changing policies and remediation plans, until the standby server becomes active (typically a few minutes).
  • Endpoint connector logs are not lost, as they are independent of manager logs.

Note: For database high availability, use standard third-party high availability solutions for the PostgreSQL database.

Otherwise, see our set up guide.

 

intiguahadiagram__1_.png

How It Works

Two JetPatch Manager Consoles are configured as Active and Standby:

Component Role
Active Server Handles all client requests during normal operation.
Standby Server Receives regular data backups from the Active server via rsync over SSH. Can be down during normal operation.
Load Balancer (NGINX) Monitors both servers. Upon Active server failure: attempts to stop and restart it once. If unsuccessful, automatically starts the Standby server and redirects all traffic to it.

Deployment Steps

Step 1: Set Up Both Servers

Completely set up two JetPatch Manager Consoles. Designate one as Active and one as Standby.

Step 2: Prepare the NGINX Server

  • The NGINX server must have a hostname that is resolvable and reachable from the Active/Standby endpoints.
  • NGINX service must be installed and always running on the Active, Standby, and Load Balancer servers.
  • If using a different load balancer, it must have the ability to run the dr.py Python script.

Step 3: Install rsync on the Active Server

SSH into the Active server and run:

yum install -y rsync

Step 4: Configure the Standby Server

  • Place the contents of disaster-recovery_py3 in:
/usr/share/intigua
  • Install rsync:
yum install -y rsync
  • Establish a trusted SSH connection to the Active server:

ssh-keygen

ssh-copy-id root@<active>

where <active> is the Active server's resolvable name or IP address. 

You will be prompted for the Active Server's root password.

  • Create the configuration directory:
mkdir /etc/intigua
  • Configure synchronization (from /usr/share/intigua):
./sync.py --src=<active> --createconfig
  • Copy intigua-sync to /etc/init.d.
  • Start synchronization:
service intigua-sync start
  • (Optional) Test synchronization:
./sync.py --src=<active>
  • Verify the script is running and that its output shows data being synchronized.

Step 5: Configure the NGINX Server

  • Establish a trusted SSH connection to the Active server:

ssh-keygen

ssh-copy-id root@<active>

  • Establish a trusted SSH connection to the Standby server:
ssh-copy-id root@<standby>
  • Start the monitor script in a screen session:

yum install screen -y

screen

./dr.py --master=<active> --slave=<standby> --monitor

  • where <active> and <standby> are the respective servers' resolvable names or IP addresses.

Tip:

Useful screen session commands:

Detach: Ctrl+a d

Resume: screen -r

List sessions: screen -ls

Note: You can also run dr.py without an NGINX server (Python 3 only). On the standby server, run: ./dr.py --master=[main-server] --slave=[standby-server] --monitor --standby

Step 6: Configure JetPatch Connectors

  1. Navigate to the NGINX server's address in a browser and log in as Administrator.
  2. Configure the JetPatch Connector management services Communication setting to the NGINX server's hostname (not IP address).
  3. Deploy this setting to all endpoints.
  4. Direct all users to the NGINX server's address.
Note: Endpoint readiness may take up to 24 hours to reflect properly after reconfiguration.

Restore the HA Cluster After an Active Server Fault

After a failure is resolved and the previously Active server is ready to rejoin the cluster, run the following on the Load Balancer server:

  • Run the init command:
./dr.py --master=<active> --slave=<standby> --init
  • Wait for the service to start, then run the monitor command:
./dr.py --master=<active> --slave=<standby> --monitor

Note:

For versions prior to 5.0: wait 2 minutes after --init for the Tomcat service to start before running --monitor.

If --init fails with "Already in DR mode. Nothing to do.": run --init again. If the problem persists, contact support.

If running dr.py from the Standby server, use --standby flag:

./dr.py --master=[main] --slave=[standby] --init --standby

./dr.py --master=[main] --slave=[standby] --monitor --standby

Upgrade the Manager Software When HA Is Enabled

When upgrading to a new version (e.g., RPM upgrade), you must shut down the DR script before upgrading to avoid a split-brain situation.

  1. Shut down the dr.py process using the Linux kill command and the process PID.
  2. Upgrade the Active (primary) server first. See the upgrade procedure.
  3. Upgrade the Standby server.
  4. Restore the DR script as described in the section above.

Related articles

Comments

0 comments

Please sign in to leave a comment.