HA Frage

  • Hi


    ist es möglich HA zwischen 2 Mastern zu haben ohne die Checks zu 'loadbalancen'? Mein 2ter Master soll wirklich nur in Notfall 'anspringen'.


    Greetz

  • du möchtest also einen cold standby?

    Da wirst du auf programme wie heartbeat zurückgreifen müssen, die sobald der master nicht mehr erreichbar ist, den anderen hochfährt.

    Linux is dead, long live Linux

  • hmm dies wäre ein feature request wert... schade, dass icinga es nicht selbst regeln kann

  • Das sieht das aktuelle Cluster-Design nicht vor, dass sich Instanzen unterschiedlich verhalten in der HA-Zone. Ein Cold-Standby mit Quorum und Co können Tools wie Corosync/Pacemaker deutlich besser. Da braucht man das Rad nicht neu erfinden.

  • hast du zuällig nen Link zu einem guten Howto der sowas in Verbindung mit Icinga2 beschreibt?

  • Ich habe bisher keinerlei solcher Setups in Kundenumgebungen oder in der Community gesehen, dort läuft alles HA-enabled oder standalone. Ich denke aber dass man sich an den Icinga1-Setups damit orientieren kann, inkl. retention.dat -> icinga2.state file auf einem DRBD/NFS Device und was man halt sonst noch so braucht. Finde ich den Aufwand dafür allerdings nicht gerechtfertigt im Vergleich zum active/active out-of-the-box.

  • Problem ist, bei uns sind die beiden Master nicht gleichwertig... Der 'normale' Master ist Bare Metal. Der secondery Master ist ne VM und wirklich nur für Übergang/Notbetrieb gedacht.

  • Ja, das übliche Gschmarri mit den Leuten die ned 2x Geld ausgeben wollen und was Gscheites bauen ;-) Hast du vor diese Kisten dann auch gleich zu provisionieren, oder willst du /etc/icinga2 eh auf ein DRBD/shared Device legen?

  • Die Konfiguration nicht händisch mit vim & co pflegen, sondern verwalten zu lassen. Etwa von Config Management Tools wie Puppet, oder exportiert aus einer CMDB, oder gar mit dem Director?

  • Der Director schickt das per REST API und Config-Packages an den Icinga 2 Knoten. Wenn du ein active/passive Failover erreichen möchtest, musst da dahingehend komplett /var/lib/icinga2/api/packages verfügbar machen. Im besten Fall komplett /var/lib/icinga2 da du dabei auch die CA und dessen private key brauchst. Was dahingehend noch problematisch sein könnte - bei einem Schwenk müssen auch alle Child-Zonen davon wissen. Das heisst du wirst eigentlich immer einen Knoten offline haben, ausser du adaptierst die zones.conf auf allen Knoten beim Schwenk. Von dem her gesehen ist active/active auch im Design des Clusters die erste Wahl. active/passive hatten wir damals diskutiert, aber du hast hier immer zwei Wege wie du es dann machen kannst/musst. Das verwirrt zusehends die User, und da haben wir uns dagegen entschieden, das anzubieten.