Vor einiger Zeit mussten wir auf schmerzliche Art feststellen, dass bei der Clustersoftware “unmanaged” nicht gleich “unmanaged” ist, sich der Cluster also je nach genutzter Variante unterschiedlich verhält.
Ausgangssituation
Das aufgetretene Problem sei anhand folgender beispielhaften Konfiguration erklärt:
Zwei Server stellen aktiv/passiv ein Dateisystem via DRBD zur Verfügung, auf dem ein Apache WebServer sowie ein JBoss ApplicationServer installiert ist, der über eine virtuelle IP angesprochen werden kann – Ja, das lässt sich alles anders lösen, ist aber wie man so schön sagt “historisch gewachsen”.
Im Großen und Ganzen sah es also so aus:
|
1 2 3 4 5 6 7 8 |
Master/Slave Set: master-slave_drbd [rsc_drbd] Masters: [ server02 ] Slaves: [ server01 ] Resource Group: group_jboss rsc_drbd_fs rsc_apache rsc_jboss rsc_ha_ip |
Vorhaben
Aus verschiedensten Gründen – beispielsweise Konfigurationsänderungen – muss der Apache von Zeit zu Zeit neu gestartet werden, meist reicht ein “graceful” / “reload” aus, manchmal ist allerdings ein harter “restart” notwendig.
Um zu verhindern, dass ein Neustart des Apaches den Cluster dazu veranlasst, die virtuelle IP oder den JBoss mit neu zu starten oder zu schwenken, wurde die Resource Group auf unmanaged gesetzt und anschließend der JBoss neugestartet. Nachdem der Apache wieder gestartet ist, wird die Resource Group wieder in die Kontrolle des Cluster übergeben.
|
1 2 3 |
pcs resource unmanage group_jboss apachectl restart pcs resource manage group_jboss |
Erwartetes Ergebnis
Vorausgesetzt es liegen keine Probleme mit der JBoss Konfiguration vor, sollte dieser sauber neustarten ohne die restlichen Komponenten des Clusters zu beeinflussen.
Dementsprechend nahezu keine Nichtverfügbarkeit.
Eingetretenes Ergebnis
Nachdem erfolgreichen Neustart des Apache und dem wieder “managed” setzen der Resource Group beendet der Cluster die Ressourcen in der Gruppe, schwenkt das DRBD auf den bis dato passiven Knoten und starte die Group auf diesem.
Dementsprechend teils mehrminütige Nichtverfügbarkeit durch Stop / Start des JBoss.
Ursache
Grund für dieses zunächst merkwürdig anmutende Verhalten ist der Umstand, dass der Cluster bei einer auf “unmanaged” stehenden Ressource zwar keine direkt diese Ressource betreffenden Aktionen durchführt, sehr wohl aber ihren failcount im Auge behält und ggf. darauf reagiert.
Dies ist genau hier passiert; der Cluster hat erkannt, dass der Apache nicht mehr läuft und hat dann versucht das DRBD zu schwenken. Was zunächst fehlschlägt, da der zugehörige Mount sowie darauf zugreifende Prozesse noch laufen.
Erst als mit dem wieder “managed” setzen der Resource Group diese gestoppt werden konnte, erfolgt der Schwenk.
Lösung
Bei Arbeiten an Ressourcen, die normalerweise von Pacemaker gesteuert werden ist davon abzusehen, einzelne Ressourcen oder Resource Groups aus der Kontrolle zu nehmen, da diese Abhängigkeiten zu anderen Ressourcen aufweisen könnten.
Der bessere Weg ist, den Cluster als Ganzes auf “unmanaged” zu setzen. Auf Clusterebene heißt der entsprechende Schalter “maintenance-mode”.
|
1 2 |
pcs property set maintenance-mode=true ( Deaktivierung über pcs property set maintenance-mode=false ) |
Mit über 15 Jahren Erfahrung als System Engineer und System Architekt bin ich die “Allzweckwaffe” im Kampf gegen Bugs und Performanceprobleme. Den Rest meiner Arbeitszeit verwende ich zur Verbesserung unseres Monitoringsystems und des Netzwerks in unseren Rechenzentren.
