Dies ist ein Bericht darüber, wie man eine Sonntag verbringen will!
Heute Morgen installierte mein automatisches Update (cron-apt) einen neuen Kernel auf allen meinen Hosts und virtuellen Maschinen. Natürlich erfordert ein neuer Kernel einen Neustart, also begann ich mit dem Unvermeidlichen. In der Regel ist das ja keine große Sache. Da ich genügend Zeit hatte, noitierte ich all die unnötigen, kleinen Dinge, die ich nach den Neustarts manuell tun musste. Wie „üblich“ geriet mein corosync-Cluster in Schwierigkeiten, als der erste Knoten neu gestartet wurde. Der eigentliche Spaß begann jedoch, als ich den zweiten Clusterknoten neu startete. Als er startete entschied es sich, dem Cluster nicht wieder beizutreten, und nahm meine Website und meinen Mailserver offline.
Nach einiger Analyse stellte sich heraus, dass das gfs2 auf einem drbd-Device permanente Kernel-Softlocks verursachte. Beide Maschinen waren also so gut wie unbrauchbar. Die Situation beruhigte sich leicht, als ich einen Knoten ausgeschaltet liess. Dennoch blieb der Cluster in einem hängenden Zustand mit dem heruntergefahrenen Knoten UNCLEAN und die Dienste starteten nicht.
Nach ein paar erfolglosen Versuchen, das drbd-Dateisystem wieder hoch zu bringen, beschloss ich, den Cluster ganz zu stoppen und eine alte Kopie der Website und des E-Mail-Servers wieder hochzufahren, immer noch mit einem kworker, der einen Prozessorkern voll auslastet.
Schließlich war ich wieder online in einem nicht-redundanten Modus! (Ist es jemals schon redundant gewesen?)
Zeit, den zweiten Knoten zu aktivieren und die Clusterdienste zu deaktivieren. Beide Maschinen liefen wieder (fast) OK. Nach einigen Versuchen und Fehlern gelang es mir, auf das drbd-Dateisystem im schreibgeschützen Modus auf dem zweiten Knoten zu mounten und somit die Dateien davon zu kopieren. Details finden Sie in meinem How-To.
Fazit: Auch wenn Sie glauben, ein redundantes System zu betreiben betreiben, müssen Sie
- Automatische Sicherungen erstellen
- Failover-Tests regelmäßig ausführen