High Availability

NetXMS 6.2 has no built-in server clustering. High availability is achieved with an active/passive (cold standby) setup: a second server host with the same NetXMS version is prepared in advance, and the server process runs on only one host at a time.

Architecture

A typical setup consists of:

  • Two server hosts — both with NetXMS installed (same version) and configured with the same database connection parameters in netxmsd.conf.

  • A database available to both hosts — either a shared database server or a replicated database (for example, PostgreSQL streaming replication with a primary on one site and a replica on the other).

  • An external switchover procedure — manual, or driven by cluster software such as Pacemaker, that starts netxmsd on the standby host when the active host fails.

Only one netxmsd process may work with a database at any given time. On startup the server writes a lock into the database (the DBLockStatus, DBLockInfo, and DBLockPID entries of the configuration table) and refuses to start if the database is already locked by another instance.

This setup protects against server host failure. It does not protect against database failure — use database-level replication or clustering for that.

Stale Database Lock

If the active server crashes, its lock stays in the database. A server started on the same host removes the lock automatically when the process that set it is no longer running. A server started on a different host does not, unless that host is configured as a peer:

# netxmsd.conf on the standby host
PeerNode = 10.0.0.1

PeerNode takes a comma-separated list of addresses or host names of the other server hosts. When the database is locked by one of them, the server first checks whether netxmsd is still running there — by querying the agent on that host for Process.Count(netxmsd) (netxmsd.exe on Windows) or, if the agent cannot be reached, by trying to connect to the client port — and removes the lock only if the peer server is not running.

Without PeerNode, remove the lock manually with nxdbmgr unlock after making sure the other server is stopped.

Switchover Procedure

  1. Confirm which host is active: netxmsd must be running only on that host.

  2. Stop netxmsd on the active host (systemctl stop netxms-server) and make sure the process has exited.

  3. If the database is replicated, make the database on the standby site writable (for PostgreSQL, promote the replica with pg_promote()), and switch the former primary to replica mode.

  4. Start netxmsd on the standby host.

For a failover after the active host has failed, start from step 3. When the failed host is repaired, resynchronize its database replica (for PostgreSQL, with pg_rewind) before it can serve as the standby.

Data Directory Synchronization

The server data directory contains the server key file, uploaded files, images, and the compiled MIB file. Keep it identical on both hosts, for example with shared storage or periodic rsync.

Agent Configuration

MasterServers is an access control list, not a connection list — it must name both server hosts so that whichever one is active is authorized:

MasterServers = 10.0.0.1, 10.0.0.2

Agents connecting through agent tunnels need one ServerConnection entry per server host:

ServerConnection = netxms1.example.com
ServerConnection = netxms2.example.com

Senders of syslog messages and SNMP traps target a fixed address; use a virtual IP address or a DNS update managed by the switchover procedure for such traffic.