Icinga Web in distributed environments

Icinga Web on a dedicated host

Requirements

  • Central database server or cluster with a virtual IP address (VIP)
  • Icinga 2’s IDO feature is writing to the database on the central server

Setup

  • Store the Icinga Web database in the central database server
  • Modify the IDO database resource to point to the central database server
  • Enable the Icinga 2 REST API and allow connection from the Icinga Web host
    • Edit the command transports configuration and point to the Icinga 2 master with the REST API

Icinga Web with two HA masters

Decide whether you want to install Icinga Web 2 locally on each master instance, or put it on a dedicated host (see above).

The recommended setup is to use a central database server with a VIP and described below.

HA with local Icinga Web

Requirements

  • Every master has a local Icinga Web 2 installation
  • Icinga 2 has the IDO feature enabled with enable_ha = true, only one instance actively writes to the central database

Setup

  • Set the IDO database resource to the central database server
  • Configure the command transport to send commands to this instance locally
  • Configure the Director to use the local REST API for deployments

HA with central Icinga Web

Requirements

  • Icinga Web runs on either one of the masters, or on its own dedicated host
  • Icinga 2 has the IDO feature enabled with enable_ha = true, only one instance actively writes to the central database

Setup

  • Set the IDO database resource to the central database server
  • Configure the command transport to send commands to both instances with fallback mode
  • Configure the Director to use the primary master’s REST API for deployments
2 Likes

Oh, I have something like this :smiley:

I am running two icingawebservers behind haproxy. they are also in an icinga2-ha-cluster. As for the web-part I installed nginx on both of the servers and they sync there files via dedicated network-share with an lsyncd daemon-setup.
One of the webservers is in a “simulated hot-stand-by-mode” as it checks the availability of its counterpart via curl (baked into a systemd-timer script). if it’s not answering http request, it will start itself for as long as the “primary-master” ist not available.

Would you mind adding that into a new #howto and let others learn from your expertise? Thanks :kissing_heart:

I just did a thing there: howto of said implementation

:smile:

1 Like