High Availability (HA)

Similar to all other enterprise applications, Avantra should be configured to be highly available if your business operations and practices dictate that it should be so. High availability configurations are crucial in ensuring the uninterrupted operation of these critical systems and services. Having a proper HA setup can minimize downtime by redundantly distributing workloads and data across multiple components, making it possible to withstand hardware failures, software glitches, or unexpected outages.

HA in Avantra

A HA setup in Avantra must take into account a few different components:

  1. The Avantra server database

  2. The Avantra server itself and the services running on that server

  3. How remote agents and WebUI users address the Avantra server (DNS and/or floating IP)

  4. The routes that agents take when routing traffic to the Avantra Server


The Avantra server database usually takes the form of a PostgreSQL database but can also be an Microsoft SQL database. Both of these DBMS offerings provide comprehensive standard methods of providing a highly available database service. We recommend setting up your database to be highly available and allow the Avantra services to contact the database via that method.


For PostgreSQL you can review their comprehensive documentation on "High availability and load balancing" on their website here.


For Microsft SQL you can review their comprehensive documentation on "Always on availability" aka high availability on their website here.

Hyperscaler Cloud SQL

Additionally, if you are using a hyperscaler cloud SQL instance such as Google Cloud SQL, then you can opt to have these database highly available across mutliple sub-zones with backups kept in a geographically different zone. These are a particularly good option for a highly available Avantra database.

Avantra services

Avantra services in a highly available setup take the form of an active/passive-standby configuration. The important thing is that there cannot be more than one set of Avantra services running on the database at any one time. For this reason, we support a highly available setup in a STONITH or Fencing configuration (STONITH stands for shoot-the-other-node-in-the-head) which protects the Avantra data from being corrupted by rogue nodes or concurrent access.

Our recommended approach is to run Avantra on Linux but for a highly available environment, we recommend the use of Red Hat Enterprise Linux owing to the comprehensive documentation and support provided by Red Hat for their high-availability add-on Pacemaker. You can read the Red Hat Enterprise Linux 9 High availability cluster configuration documentation https://access.Red Hat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_high_availability_clusters/index[here^].

When running Avantra in a HA environment, the key considerations are:

  • Mirror or replicate changes to the Avantra installation directory (usually /opt/avantra) as this contains certain assets that should persist between nodes e.g. SLR reports, automation payloads, Agent Update bundles and other configuration files.

  • Ensure that the DNS hostname used by remote agents to contact the Avantra server is aware of the HA configuration and will be routed to the right node in the event of a HA failover.

If you are using a Microsoft environment, you can use Failover Clustering to achieve a similar set up to what has been mentioned above. More information can be found on this here.

Addressing the Avantra server

While this might be self-evident, it is important to remember (even when not using a HA setup) that the hostname that end users (for the WebUI) and the remote agents use to contact the Avantra server remain constant even in a load balancing, HA or DR scenario. For this reason, we recommend ensuring that you use a DNS alias on top of whatever configuration you are using.

For example, in a non-HA setup, you should ensure that there is a DNS alias referring to the actual host of the Avantra services and this alias should be how remote agents and users refer to the Avantra server. Similarly, if you’re using a HA configuration with a load balancer, the alias should refer to the load balancer so that any underlying change to the destination node is transparant to the end user.

The fully qualified DNS alias should be configured in the Avantra server under the following configuration items (found in the Administration → Settings menu):

  • Avantra Master

    • Network.masterhost

  • Avantra UI

    • xanguihost

Agent routes

For more complex and locked down network environments it is common to require a number of hops for an Agent monitoring a remote system to contact the Avantra Server. This can sometimes require NAT traversal or require network edge nodes through which communication can flog. For this reason, each Avantra agent can be configured to act as a so called Gateway for other agents so that they can communicate back to the Avantra server.

In addition to this, you can configure multiple backup routes that communications from an agent can take if a primary route fails and this is important for a HA environment. In the event that the network edge nodes on your routes are unavailable, you will want an alternative route available for the traffic to take. For this reason, we recommend architecting an alternative route to each network segment that the communication can use in the event of the primary route failure.

For more information on complex route configuration, please see The Route Configurator.