Dynamisches Clustering mit Linux und Wackamole

Es wird sich nie verhindern lassen, dass einzelne Server ausfallen. Findige Admins halten Ersatz bereit, um im Ernstfall schnell reagieren zu können. Noch schneller sind automatische Lösungen: Hochverfügbarkeitstechniken sorgen dafür, dass ein Cluster aus mehreren Servern nach außen hin störungsfrei erscheint, auch wenn einzelne Komponenten ausfallen. Wackamole[1] zeigt, dass diese Techniken gar nicht so schwierig zu implementieren sind.

Loadbalancer vs. Cluster

Allerdings hat der Begriff Cluster verschiedene Bedeutungen. Cluster Computing kann neben Hochverfügbarkeit auch der Lastverteilung oder der parallelen Datenverarbeitung dienen. Der Kasten "Cluster-Techniken" erläutert einige gängige Cluster und ordnet sie nach den technologischen Prinzipien.

Diese Techniken und Prinzipien lassen sich unter verschiedenen Gesichtspunkten betrachten. Tabelle 1 zeigt eine Einteilung anhand der stattfindenden Kommunikation. Cluster, die sich intern auf Gruppenkommunikation (Group Communication) verlassen, bestehen aus einer Clustersoftware (Middleware) auf jedem Clusternode. Mit der Middleware informieren sich die Nodes gegenseitig über ihren jeweiligen Status und ihre Mitgliedschaften. Solche Cluster benötigen keine Hardware wie Loadbalancer oder Content Switches.

Hardware-Loadbalancer arbeiten dagegen vor einer Gruppe von Servern, die untereinander meist nicht geclustert sind, und verteilen Requests auf diese Rechner. Bei vielen Produkten prüft die externe Hardware regelmäßig die Server (Health-Checks), ermittelt deren Erreichbarkeit sowie näherungsweise deren Auslastung. Dagegen kommuniziert bei Mod_backhand ein Apache-Modul Speicherbelegung und Systemlast aktiv an den Loadbalancern.

Wenn die zusätzliche Hardware nicht selbst redundant ausgelegt ist, sind Loadbalancer ein neuer Single Point of Failure im Netz. Ein Cluster besteht dagegen aus mehreren Rechnern (einer Gruppe), die in manchen Fällen nach außen hin als ein einziges hochverfügbares System erscheinen. Mit Wackamole und anderen Clustern, die auf Gruppenkommunikation basieren, müssen sich alle beteiligten Server über die Gruppe im Klaren sein. Ihre gemeinsame Aufgabe ist es, einen bestimmten Service hochverfügbar anzubieten.

Der Benutzer merkt in der Regel nicht, dass er gerade mit einem Cluster verbunden ist. Das ist durch zwei verschiedene, weitgehend unabhängige Mechanismen verwirklicht: Die Server müssen Status- und Mitgliedschaftsinformationen intern kommunizieren (etwa per Spread[2]) und nach außen hin als ein einziges System erscheinen (das leistet Wackamole).

Jeder mit jedem: Gruppenkommunikation

In modernen Clustern mit mehreren aktiven Komponenten kommen meist Algorithmen zum Einsatz, die sich am Extended Virtual Synchrony Model EVS[3] orientieren. Das gilt sowohl für den hier vorgestellten Spread-Daemon als auch für kommerzielle Produkte wie zum Beispiel die Rainfinity Rainwall[5]. Dieses Modell spiegelt die Notwendigkeit wider, dass alle Clusternodes zu jeder beliebigen Zeit den gleichen Wissensstand bezogen auf Cluster-Mitgliedschaft und Status benötigen.

Zum Beispiel könnte ein Cluster aus drei Computern A, B und C bestehen. Zwischen A und C tritt ein Netzproblem auf, nicht aber zwischen B und C. In diesem Fall darf es unter keinen Umständen passieren, dass A denkt, C hätte den Cluster verlassen und A und B seien die verbleibenden aktiven Nodes. B und C würden jedoch glauben, dass der Cluster weiterhin aus A, B und C besteht.