On this page

How it works

Three nodes hold the same data and vote. One Webserver is active, the other waits with an up-to-date copy, and a witness makes sure only one of them can ever be active.

What a Webserver outage means. Probes and integrators keep monitoring and alerting on their own. What stops with the Webserver is the UI and API, application roll-ups and SLA timelines, the intake of Sentinel discovery data, scheduled reports and downtimes. A cluster keeps those running.

The nodes

   users / API clients            probes - agents - integrators
            \                          /
       virtual IP or load balancer   (health check: GET /ha/health)
            |                 |
      node 1 (ACTIVE)     node 2 (standby)      witness
      serves, schedules   live copy of the      votes, holds a copy,
      talks to components data, forwards        serves nothing
            \______ cluster channel (TLS, shared key) ______/
  • Active node: the only one that writes, runs scheduled jobs and talks to the components.
  • Standby: holds an up-to-date copy. Its ports stay open: a request that reaches it is passed to the active node, so users are never sent to a dead end.
  • Witness: a third vote. With only two nodes, neither could tell “the other one is down” from “I am cut off”, and both could end up active. The witness holds a copy of the data but runs no web server and needs no license.
  • Failover: when the active node stops answering, the others elect a new one. Typically 4 to 6 seconds; a planned stop hands the role over in about one second.
  • Sessions survive: users stay logged in, API keys and component tokens stay valid.

A node that is cut off from the majority stops accepting changes and answers 503 until it is back in contact. This is what prevents two active Webservers.

The role does not move back on its own: when a failed node returns, it becomes a standby.

What is copied

Copied to every node Not copied
All settings, users, monitors, applications, history and SLA data Generated reports and exports
Component certificates, user images, discovery files (within seconds) Logs
Session signing keys and the component secret (_sharedInternal) The TLS certificate and the license file (install them on each node)
AdvertiseAddress and the Webserver-Front replication material (set them on each Webserver)

Requirements

  • 3 servers that reach each other on the cluster port (one TCP port of your choice, e.g. 7001).
  • Clocks synchronised (NTP).
  • A virtual IP, a load balancer or a DNS name in front of the two Webservers.
  • A cluster license.
  • The same TLS certificate on both Webservers, valid for the shared name.
  • The components’ firewalls open to both Webservers: each one calls the components from its own IP.

Disk: every node, witness included, holds the data plus one snapshot of it.

See also

Translations

Configuration