keepalived ist eine einfache Lösung einen HA-Cluster z.B. unter Linux zu betreiben (https://www.keepalived.org/). Jedoch kennt dieser von Haus keinen Weg für einen manuellen failover. Es folgt eine Auflistung verschiedener Möglichkeiten dennoch das Ziel zu erreichen.
1. Dienst anhalten
Wenn man in der keepalived Konfiguration einen Dienst überwacht kann man diesen schlichtweg stoppen. Der Cluster schwenkt logischerweise sinngemäß. Aber halt, das ist nicht ganz ideal wie folgende Beispiele zeigen:
- Wenn man schwenkt weil man Updates einspielen will hat man ein Problem wenn man den vermeintlich überwachten Dienst für die finalen Tests starten möchte. Das geht zwar, jedoch schwenkt dann keepalived zurück. Der „Test“ ist somit die laufende Produktion. So lange alles gut geht: Toi, toi, toi 😉 Falls nicht: Ooops.
- Ich habe einige Dienste am Laufen die einiges an Zeit brauchen um sich zu beenden. Zuletzt läuft zwar noch der Netzwerkport und der Dienst steht logischerweise auch noch in der Prozesstabelle – aber Anfragen werden nicht mehr beantwortet. In genau dieser Zeitspanne hat man dann also eine Produktionsausfall. Anmerkung dazu: Die meisten keepalived Skripte die ich kenne prüfen schlichtweg auf das vorhanden sein des Programms in der Prozesstabelle und/oder ob am zugehörigen Port jemand lauscht. Ob vernünftige Antworten auf Anfragen kommen wird meistens nicht überwacht. Das ist zugegebener Maßen aber auch nicht wirklich einfach zu überwachen: Was ist wenn der Dienst, warum auch immer, gerade einfach mal etwas länger braucht um die Antwort zu liefern wie sonst? Wie lange soll die Prüfung warten und ab wann schwenken? In der Zeitspanne die hier gewartet wird könnte der Dienst bereits wieder weg sein. Kurzum: Prozess- und Portüberwachung macht Sinn, „sinnvolle“ Antworten nur bedingt. Das sollte genau abgewogen sein ob und in wie weit das sinnvoll ist. Das wäre aber ein anderes Thema. Zurück zum Ausgangspunkt: Auch diese Variante ist alles andere als toll.
Zusammengefasst: Als Test mag Dienst stoppen ausreichend sein, wirklich praktikabel für Updates und der gleichen ist das allerdings nicht.
2. keepalived Priorität
Ein anderer Weg ist in der keepalived Konfiguration die Priorität eines Nodes anzupassen. Man muss letztendlich nur dafür Sorge tragen, dass der Node welcher die Rolle übernehmen soll die höchste Prio hat. Aber mal ehrlich: Will man das so? Im keepalived was ändern und diesen neu starten für einen manuellen failover? Nein, das will man sicherlich nicht!
3. Eigenes Skript
Zu guter Letzt könne man ein Skript erstellen welches den weight anpasst. Also Skript starten und z.B. falls die Datei /etc/keepalived.myweight existiert die Wichtung um den in der Datei angegebenen Wert ändern. Ja, das geht. Nur müsste man so ein Skript noch schreiben. Und ob der Aufwand so wirklich lohnt… 😉
dummy-Netzwerkkarte
Es geht aber auch ganz anders ohne großartig irgendwas an Software schreiben zu müssen. Der Kernel bringt hierfür bereits alles passende mit: Die Netzwerkkarte „dummy“. Details z.B. per „modinfo dummy“ bzw. in der zugehörigen Kerneldokumentation. Sobald das Modul geladen ist kann die Netzwerkkarte dummy0 entsprechend mit einer beliebigen und nirgends sonst wo verwendeten IP belegt werden. Ich habe hier einen SLES am laufen, dort kann das via Yast2 entsprechend erledigt werden. Aber auch bei Debian/Ubuntu kann man dummy-Karten mit den üblichen Werkzeugen anlegen. Einfach mal in die Doku rein schauen, das sollte sich finden lassen.
Zu Letzt muss noch die keepalived.conf angepasst werden:
track_interface {
em1
dummy0
}
Die Liste meiner track_interface Karten wurde einfach um dummy0 erweitert. Jetzt reicht ein einfaches ifdown dummy0 oder ip link set dummy0 down und keepalive schwenkt auf den anderen Node. Ein ifup dummy0 bzw. ip link set dummy0 up und schon kommt er wieder zurück. Ganz ohne irgendwelche zusätzlichen Skripten.