Icinga 2 HA-Cluster Konfiguration bei zwei Zonen

  • Guten Morgen Zusammen,

    ich darf mal wieder mit Icinga spielen, ich weiß aber noch nicht so recht was genau ich anstelle.


    Wir haben derzeit einen Master und einen Satellite an einem Standort (DC1) in zwei Zonen (Master-Zone + Checker-Zone) laufen.

    Nun kam der Gedanke auf, die alte Nagios Konfiguration an einem anderen Standort zu Icinga zu migrieren.

    Dabei soll am anderen Standort (DC2) ebenfalls ein Master stehen welcher alles Prüft was dort vorhanden ist. Gleichzeitig sollen aber auch die Master von beiden Standort wenn möglich ein HA-Cluster bilden, so dass ein Master alles übernimmt wenn der andere ausfällt.


    Nun meine Frage:

    Aus dem Forum habe ich schon rausgelesen dass das möglich und auch Standortübergreifend kein Problem ist. Was mir aber noch nicht so klar ist was ich mit der Datenbank mache.

    Ich habe kein DB-Cluster auf welches ich zugreifen kann. Wenn ich es richtig verstehe wäre es somit nur möglich, dass jeder Master seine eigene lokale DB-Instanz hat und beschreibt aber werden dann die Configs trotzdem synchronisiert und ein Master übernimmt wenn der andere ausfällt? Wenn ja wie genau müsste ich das konfigurieren?


    Gruß David

  • Jeweils eine lokale MySQL DB sowie Icinga Web 2 oben drauf, und im ido-mysql feature dann enable_ha=false auf allen Knoten.


    https://www.icinga.com/docs/ic…-availability-with-db-ido

  • dnsmichi in deinem Link geht es aber auch darum dass die Master alle in der selben Zone sind.


    Ich würde gern zwei Master in unterschiedlichen Zonen haben um den Mastern entsprechende Checks zuweisen zu können.

    Gleichzeitig soll aber auch ein Master die Funktion des anderen übernehmen wenn dieser ausfällt, sprich seine Checks übernehmen.

    Beide Master haben Icinga2-web installiert.


    Ich kann soweit alles einrichten, dass beide Standorte unabhängig von einander agieren aber mir fehlt irgendwie die Verbindung zwischen den beiden Masterzonen um daraus ein HA-Cluster zu bauen.

    Funktioniert das überhaupt so wie ich mir das denke?


    Ich hab das mal so aufgemalt wie ich mir das vorstelle.

  • Mit dem Zonen-Konzept und HA innerhalb einer Zone wird dein Konstrukt nicht funktionieren. Wäre es zB nicht sinnvoller, die jetzigen Master in Satelliten umzubauen als "Checker", und oben drüber noch eine Master-Zone zu setzen, welche dann die IDO Datenbank befüllt?

  • Ja das habe ich auch schon überlegt, wollte ich aber eigentlich vermeiden. Ich denke ich gehe den einfachen Weg und mache aus dem Master in DC2 einen Satelliten.


    Wie ist das mit Icinga2-Web? Ich meine mich zu erinnern dass in Icinga2-Web wenn es auf einem Satelliten installiert ist nur angezeigt wird was der Satellit überprüft. Ist das noch so?

  • Was ist denn die Best-Practice Methode wenn ich in DC1 und DC2 eine Weboberfläche für Icinga benötige, die User in DC2 aber nur sehen wollen was auch in DC2 anliegt?!


    Ich würde einen Satelliten (Raspberry Pi 3) in DC3 installieren. Die Frage ist ob ich dort eine eigene Weboberfläche installiere oder sollte ich die des Masters in DC1 einfach mitnutzen? Kann man die Ansicht Rechtemäßig einschränken so das bestimmte Benutzer nur Hosts/Services aus DC2 sehen?

  • Ich würde einfach die bestehende Oberfläche mitbenutzen, das Einschränken, der Ansichten, sollte auch ohne Probleme möglich sein.


    Was den Satelliten in DC3 angeht, nutze bitte keine Raspberry Pi, diese sind nicht für solche Aktivitäten ausgelegt und die SDCards in kürzester Zeit zerstört.

    Besser wäre ein NUC, oder irgendwas das eine SSD hat und auch etwas mehr Power mitbringt

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Danke für den Hinweis,


    Wir haben bereits zwei Raspberries als Satelitten laufen und eigentlich bisher sehr gute Erfahrung damit gehabt (beide laufen jetzt seit über einem Jahr problemlos). Grundsätzlich hast du natürlich recht aber solange es läuft... :)


    Das Problem beim mitbenutzen der Oberfläche aus DC1 ist leider, dass DC2 nicht mehr darauf zugreifen kann wenn z.B. die Verbindung zwischen beiden Standorten weg ist. Das wäre auch das einzige Argument was für eine zweite Weboberfläche spricht.


    EDIT: Wenn ich das aber richtig sehe benötige ich für Icingaweb2 auch eine Datenbank. Wenn diese nicht lokal auf dem Satelitten/Master in DC2 installiert ist bringt mir "nur" das Webinterface an der stelle bei einem Leitungsausfall auch nicht viel oder?



    Kurzum: Ich bin jetzt noch mehr verwirrt als vorher und weiß gar nicht mehr was besser ist :) Ich glaube ich schlafe noch mal ne Nacht drüber.

    The post was edited 2 times, last by DazDavid ().

  • Genau dieser Informationsfluss zwischen den Datenbanken und Icinga2, IcingaWeb2 ist mir auch noch nicht klar.


    Wir haben:

    • Das Icinga2 Cluster Protocol, welches dafür sorgt dass
      • Konfigurationen innerhalb der Baumstruktur verteilt werden
      • Checks auf Mastern / Satelliten geplant und dann auf Clients ausgeführt werden können
      • Ereignisse wie Statusänderungen und Check-Results wieder bis an die Wurzel des Baumes hochlaufen
      • Hierzu gehört auch der "Replay des Backlogs" im Falle temporärer Netzwerkunterbrechungen zwischen Endpunkten.
    • Das funktioniert alles super ohne irgend eine SQL-Datenbank.
    • Dann haben wir die Icinga2- Datenbank, in die Icinga2 z. B. Historien zu Checks schreibt.
      • Wir wissen, dass Icinga2 selbst dort nur hereinschreibt aber nie selbst liest.
      • Also können wir diese DB für die Funktion des Kerns vergessen - die DB sammelt nur Informationen für weitere Tools.
      • Knipse ich das Featurew IDO_xxx auf einem Master und einem Satellite an, dann landen die Informationen des Satellite in beiden Datenbanken, es erfolgen zwei physisch verschiedene Schreibzugriffe gleichen Inhalts. Daraus ergibt sich, dass diese (Teil-)Information in den beiden Datenbanken nicht auseinander laufen kann.
      • Darüber hinaus werden nur auf auf den Master die Daten der weiteren Satelliten geschrieben.
    • Dann haben wir die Icingaweb2- Datenbank, in der sich Icingaweb2 Dinge wie Benutzer, Gruppen und deren Rechte merkt.
      • Mehr als Benutzer, Gruppen und Rechte steht hier nicht drinn, hier kann also auch nichts auseinander laufen.
      • Und, Ja: Ohne diese IcingaWeb2- Datenbank funktioniert Icingaweb2 definitiv nicht.
      • Für die Anzeige von Informationen greift IcingaWeb2 auch auf die Icinga2-Datenbank zu.
    • Dann haben wir die Icingaweb2-Director Datenbank, in der grundlegende Konfigurationsdaten wie Zonen und Endpunkte abgespeichert sind. Eine Synchronisation zwischen zwei Director-Datenbanken scheint mir nicht möglich, hier läuft mit Sicherheit ein Datenbestand auseinander.
    • Wie gesagt, der Icinga2-Kern funktioniert ohne die hier abgelegten Informationen, aber die in Post #2 vorgeschlagene Lösung kann mit "jeweils noch einen IcingaWeb2-Director obendrauf" meiner Meinung nach nicht funktionieren.
      • Was auch keiner gesagt hat, aber wichitg ist zu wissen.

    Hab ich das soweit richtig verstanden ?

    The post was edited 1 time, last by sru ().

  • zu deinem Punkt, dass ein Abgleich zwischen 2 Director Datenbanken nicht möglich ist:


    Das geht schon, über einen Cluster, macht meiner Meinung nach aber nicht sonderlich viel Sinn.

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • sru sehr gute Zusammenfassung. Ich würde den Director nur auf einer Instanz am Laufen haben, und im besten Fall auch nur ein Icinga Web 2 auf einem dedizierten Host (oder via Load-Balancer/HA-Proxy dann jeweils nur eine aktive Instanz).

  • @sru danke für die sehr ausführliche und hilfreiche Zusammenfassung.


    Das Thema "Director" scheint relativ neu zu sein, zumindest habe ich bisher nichts davon gehört.


    Grundsätzlich leite ich aber aus deiner/eurer Ausführung folgende Lösung für mich ab (siehe Zeichnung im Anhang).

    DC1 und DC3 existieren bereits in dieser Konfiguration. Hinzukommt nun ein System in DC3 welches sowohl eine Icinga2DB als auch eine Icingaweb2 mit eigener DB benötigt, die Configs selbst werden aber ausschließlich auf dem Master in DC1 verwaltet.

    Eine Ausfallsicherheit habe ich in diesem Fall zwar nicht, das ist aber auch nur optional und kann ja relativ einfach mit einem zweiten Satellite an DC3 realisiert werden.


    So wäre das eine geeignete Lösung für uns, es wäre nur schön wenn das noch mal jemand bestätigen könnte, nicht das ich einen Denkfehler habe :)

  • In der Kiste "DC2" steht unten drinn:

    icingaweb2 nur für "DC3", das ist sicher ein Typo und der Titel der Kiste muss "DC3" lauten ?


    Hinzukommt nun ein System in DC3 welches

    Also hast du die Titel der Kisten DC2 und DC3 vertauscht ?


    Ansonsten bin ich einverstanden.


    Hinweis:

    Derzeit nur maximal zwei Endpunkte pro Zone konfigurieren, sonst gibt es Performanceprobleme !

    The post was edited 1 time, last by sru ().

  • sru : Oh, da hat sich ein Fehler eingeschlichen... Der Titel der Kiste ist richtig, aber das DC3 im Text unten muss DC2 lauten genauso wie das DC3 in dem Zitat DC2 lauten muss...


    Gut, dann werde ich das mal so aufbauen und schauen ob alles klappt wie gedacht aber ich bin optimistisch.


    Vielen Dank für den Hinweis mit der Performance und überhaupt... DANKE!!!

  • Hi, ich noch mal :)

    Also ich habe alles soweit wie besprochen aufgesetzt und es läuft fest zu meiner Zufriedenheit.

    Ich hatte allerdings eine Sache außer Acht gelassen und ich weiß nicht so recht wie ich das am elegantesten löse:


    Admins in DC2 haben ihr eigenes Webinterface und sehen nur was an ihrem Standort geprüft wird. Nun sollen dort aber auch noch eine Hand voll Hosts angezeigt werden, welche vom Master in DC1 geprüft werden.


    Ich dachte an ein Attribut "check_source" oder sowas aber bin nicht so richtig fündig geworden.

    Wenn das selbe Configfile in zwei Zonen liegt meckert Icinga das an mit "Host re-defined" an.


    Ich habe jetzt als Workaround für die betreffenden Hosts die Configs aus Zone 1 in Zone 2 kopiert und dort den Hostnamen mit einem Leerzeichen leicht abgewandelt, so dass Icinga das nicht mehr als identisch ansieht. Das funktioniert auch soweit, abgesehen davon dass ich in DC1 nun zwei mal den gleichen Host habe, einmal mit und einmal ohne Leerzeichen.


    Gibt es einen eleganteren Weg das Problem zu lösen?