Nach der ganzen Geschichte mit IBM geht es nun endlich mal wieder mit etwas Sinnvollem weiter. Ein ClusterFS gehört nicht zu den Dingen die jeder braucht oder unbedingt haben muss wenn er einen Rootserver hat. Cluster Dateisysteme sind relativ komplex und gerade in Bezug auf OCFS2 gibt es noch einige lustige Bugs und Probleme, nur wie findet man diese? An dieser Stelle werde ich ein wenig aus dem Nähkästchen plaudern. In diesem Fall hatten wir mit einem der Cluster Setups Probleme (währendessen andere ohne Probleme funktionieren). Nehmen wie aktuell einmal das bereits behandelte Szenario des DRBD/OCFS2 Webclusters.
Der Setup funktionierte auf Anhieb und die geplante mehrtägige Testphase wurde auf Wunsch des Kunden verkürzt da aktuell einige Überlasten zu verzeichnen waren und aus diesem Grund dringend umgeschaltet werden musste. Natürlich haben wir davon abgeraten, dies übereilt zu tun da insb. auch am Portal selbst einige Anpassungen zu machen sind (IP- Adressen für die Sessionverwaltung müssen dank LBL aus einer anderen Variable gezogen werden etc.).
Nun, den Cluster in Betrieb genommen, hierbei war darauf zu achten das auch Temp und Session Dateien mit auf dem ClusterFS liegen damit diese beiden Servern zur Verfügung stehen, was zwar nicht erforderlich ist, da der aktuell eingesetzte LBL (Loadbalancer) Pound ein passendes Sessionmanagement hat und so die Nutzer immer wieder auf den passenden Server leitet.
Die ersten Stunden verliefen absolut ruhig, alles lief genau so wie es sollte. Die Last wurde sauber verteilt und alle Server waren absolut im grünen Bereich.
Innerhalb weniger Sekunden stieg der Load der Web Nodes auf über 200 während sich die CPUs langweilten. Das Portal selbst war noch absolut schnell abrufbar, allerdings hingen einige Prozesse fest.
Prozesse finden
ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN | grep D |
Dieser nette kleine Befehl zeigt uns wartende Prozesse und worauf diese warten. Es handelte sich um einige OCFS2 Lock Waits.
flock() oder wie ärgere ich den Cluster
OCFS2 mag in aktueller Version ein flock() überhaupt nicht, dies soll zwar langfristig gefixt werden aber das wird wohl noch ein wenig dauern. Auf flock wurde ab sofort verzichtet und nun sah auch schon alles besser aus.
The return of the Load
Wenige Stunden später war sie wieder da, die Last staut sich wenige Sekunden an und dann flacht alles wieder ab und ist wieder normal wie vorher. Währenddessen merken nur Nutzer die auf diesen Prozess warten etwas davon, alles andere ist wie gewohnt performant. Wieder Prozesse analysiert, wieder sind es PHP Prozesse. Nun möchte man natürlich wissen um welche Datei es sich handelt:
Den Schuldigen finden
./debugfs.ocfs2 -R "fs_locks" -n /dev/drbd0 > /root/lock.log |
Der komische Aufruf mit ./ hat einen Grund, die in Portage enthaltenen ocfs2-tools sind zu alt für diese Auswertungen, aus diesem Grund wurden diese von Hand kompiliert aber mit dem Hintergedanken die vorhandenen nicht zu überschreiben. Nach kurzer Zeit haben wir eine LOG Datei welche wir nun in Ruhe auswerten können. Um den Fehler zu lokalisieren sollten wir die Augen nach “Busy” offen halten. Den wenn es wirklich ein Lockung Problem ist, wie zum Beispiel mit flock() taucht dies an dieser Stelle auf. Dort erfahren wir aber immer noch nicht um welche Datei es sich eigentlich handelt, nur die Lockres. Diese Logres lässt sich mit folgendem Befehl auflösen:
./debugfs.ocfs2 -R "findpath <W000000000000000249c04fccb0d3fb>" /dev/drbd0 |
Es sollte nun die betroffene Datei angezeigt werden.
Kein Schuldiger
In unserem Fall war es aber kein offensichtlicher Fehler sondern ein Bug in OCFS. Ein Kernel Upgrade auf 2.6.27 sollte genau das fixen, allerdings gibt es da einen anderen lustigen Bug das DRBD auf Anhieb nicht mehr funktioniert. Aber für all dies gibt es ja Lösungen.