Durch seine außerordentlichen Bedienschwierigkeiten ist der Cluster-Manager Pacemaker Gegenstand des Unmuts vieler Admins. Und zweifellos ist Pacemaker nicht das Nonplusultra, wenn es um die Wartung von hochverfügbaren Clustern geht. Das ist zum Teil der Geschichte geschuldet, die Pacemaker durchlaufen hat: Zwischen der ersten Version im Jahre 1999 und Heartbeat 2 blieb kein Stein auf dem anderen. Und als Heartbeat 2 endlich fertiggestellt war, zeigte sich die Software instabil und nur über das Einbauen von XML-Snippets überhaupt bedienbar. Der direkte Nachfolger Pacemaker wies dieses Manko zwar nicht mehr auf, doch hat sich das Prinzip Heartbeat von diesem Bedienbarkeits-GAU nicht vollständig erholt.
Und es ist nicht so, dass die Entwicklung von Pacemaker besonders gut verlaufen wäre: Die ersten Versionen des Kommunikationsstacks Corosync waren so kaputt, dass sie ganz im Stile von Heartbeat 2 Nutzer eher vergrault denn angelockt haben. Und obwohl Pacemaker bereits mehrere Jahre auf dem Buckel hat, tun sich immer wieder Bugs auf, die das Vertrauen in den Pacemaker-Stack schwinden lassen.
Admins stehen also vor einem vertrackten Problem: Indem sie sich Pacemaker ins Haus holen, lösen sie zwar vermeintlich das HA-Problem, installieren aber auch eine “Black Box” in ihrem Setup, die augenscheinlich tut, was sie will. Keine Hochverfügbarkeit ist allerdings auch keine echte Alternative. Wie sehr der Pacemaker-Schuh drückt, manifestiert sich darin, dass einige Unternehmen diesen Weg mittlerweile trotzdem gehen und auf HA verzichten. Denn die Probleme, die Pacemaker bei vielen Installationen verursacht, wiegen die Vorteile nicht auf; im Gegenteil: Oft produziert Pacemaker mehr Schaden als Nutzen.
Es stellt sich die Frage, ob sich das Thema Hochverfügbarkeit nicht anders ebenso sinnvoll erledigen lässt, ohne dabei überhaupt den Pacemaker-Stack in Anspruch zu nehmen. Einige Lösungen schwirren umher, viele davon gehören ohne Zweifel zur
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.