In der Praxis setzt man auf „Computer-Cluster“, um die Eigenschaften eines einzelnen Servers in den Dimensionen Verfügbarkeit und Performance zu optimieren. Ein Computer-Cluster, oder kurz Cluster, besteht aus mehreren Servern, die kooperativ eine Aufgabe lösen. Zielpunkt der Bemühungen ist, dass sich die Server des Clusters von außen wie ein einzelner großer Rechner verhalten. Prominente Vertreter des Clusterings sind Google® und heise.de. Generell gibt es zwei konkurrierende Konzepte: Hochverfügbarkeit und Lastenausgleich.

	Hochverfügbarkeit	Lastenausgleich
Server-Ausfall verkraftbar	ja	ja
Server-Software ohne Modifikation betreibbar	fast immer	selten
Performance-Steigerung mit jedem neuen Server	nein	ja
konkurrierender Datenzugriff	nein	ja
Session-Fail-Over möglich	nein	ja

Wenn ein kritischer Dienst nur auf maximal einem Server des Clusters gleichzeitig läuft, spricht man von Hochverfügbarkeit. Die anderen Rechner des Clusters sind passiv und warten, um im Fehlerfall einen hochverfügbaren Dienst zu übernehmen. Diesen Vorgang bezeichnet man als „Fail-Over“. Vorteil dieses Ansatzes ist, dass die meisten Applikationen nicht für den Einsatz im Cluster angepasst werden müssen und somit einen Fail-Over „nativ“ unterstützen. Dank des Konfigurationsdatei-Ansatzes, wie er unter UNIX und Linux üblich ist, muss meistens nur gewährleistet sein, dass die Konfigurationsdateien und Work-Daten zwischen den Servern des Clusters untereinander geteilt werden. Zusammen mit einer Software, die den Fail-Over koordiniert, wie zum Beispiel Heartbeat [1], lassen sich die meisten Dienste wie Webserver und Datenbankserver hochverfügbar implementieren.

Nachteil des Hochverfügbarkeits-Ansatzes ist, dass die Performance nicht mit der Anzahl der Server im Cluster skaliert. Das heißt, dass der Hochverfügbarkeits-Cluster nur die Verfügbarkeit eines Dienstes sicherstellt, aber nicht, dass alle Server des Clusters gleichmäßig ausgelastet werden. Weiterhin bedeutet ein „Fail-Over“ normalerweise auch eine Unterbrechung der Verfügbarkeit – wenn auch nur für einen festen Zeitraum. Hochverfügbare Cluster sind in den meisten Fällen auch nicht ohne „Single-Point-Of-Failure“. Das bedeutet, es gibt im Cluster eine nicht-redundante Ressource, die, falls sie ausfällt, auch den Ausfall des kompletten Clusters nach sich zieht. In der Abbildung ist es das „Shared Device“. Um dieses Problem zu beheben, kann man auf DRBD [2] zurückgreifen. DRBD stellt kostengünstig ein virtuelles Shared Device auf Basis der lokalen Festplatten der Server zur Verfügung.

Beim Lastenausgleich ist das grundlegend anders: Alle Server sind gleichzeitig aktiv und beantworten so parallel die Anfragen an den Cluster. Dadurch spricht man hier von einem „Active-Active“-Cluster. Das wird durch eine im Cluster installierte Komponente realisiert. Der Load-Balancer sorgt für eine gleichmäßige Verteilung der Anfragen an die dahinter liegenden Server. Die Performance skaliert bei diesem Cluster-Typus daher mit der Anzahl seiner Rechner. Fällt ein Rechner des Clusters aus, spricht der „Load-Balancer“ diesen nicht mehr an. Dadurch erbt ein Active-Active-Cluster die Hochverfügbarkeits-Eigenschaft des Fail-Over-Clusters. Da alle Dienste des Clusters parallel aktiv sind, muss im Falle eines Server-Ausfalls kein Dienst neu gestartet werden. Darauf aufbauend kann man „Session-Replikation“ implementieren. Das bedeutet, Clients würden den Ausfall eines Servers im Extremfall nicht mehr bemerken.

Grundsätzlich kann man bei der Lastverteilung feststellen, dass der Load-Balancer der „Bottle-Neck“ ist. Daher bieten namhafte Hersteller Hardware-Appliances für genau diesen Zweck an. Weiterhin ist der Load-Balancer ein Single-Point-of-Failure, also insgesamt eine kritische Komponente des Clusters. In einem folgenden Abschnitt werden Open-Source-Softwarelösungen zum Load-Balancing vorgestellt. Der Tribut für die Vorteile des Active-Active-Clusters ist eine komplexere Struktur sowie meist notwendige Anpassungen der verwendeten Software.

Auf funktionaler Ebene ergeben sich in der Praxis für einen Active-Active-Cluster eine ganze Reihe von Herausforderungen. Alle Server des Clusters müssen in Abhängigkeit von einer Client-Session das gleiche Ergebnis zurückliefern. Das bedeutet, dass die Work-Daten der Server geteilt werden müssen. Der klassische Lösungs-Ansatz ist, ein gemeinsames NAS-System zu implementieren oder ein Cluster-Dateisystem wie GPFS [3], Lustre [4] oder GFS [5] zu verwenden. Letzteres Dateisystem wird offiziell von der Firma RedHat unter der GPL weiterentwickelt und ist erst kürzlich offiziell in den Linux-Kernel aufgenommen worden. Auf diese Weise sind die Work-Daten des Clusters für alle zugänglich und konkurrierender Daten-Zugriff wird möglich. Im Falle von TYPO3 würden in einem Cluster-Dateisystem oder einem NAS die Daten der Instanz gespeichert werden, also typo3conf/, fileadmin/ und so weiter.

Wie schon beim hochverfügbaren Cluster, entstehen auch bei der Lastenverteilung Kosten, da ein „Shared-Storage“ notwendig wird. Das ist ein Festplattensystem, das von mehreren Rechnern geteilt wird und auf das zeitgleich von mehreren Rechnern aus zugegriffen werden kann.

Um der oben genannten funktionalen Anforderung an einen TYPO3-Cluster gerecht zu werden, müssen mehrere Komponenten installiert sein. Das betrifft sowohl das verwendete Datenbanksystem als auch die Work-Daten, wie zum Beispiel statischer Content, Bilder, Stylesheets und so weiter.

Um eine gemeinsame Dateibasis der Cluster-Server zu erhalten, gibt es mehrere Strategien. Falls verlangt wird, dass die Dateien im Cluster stets absolut synchron sind, greift man auf ein Cluster-Dateisystem oder ein NAS zurück. Falls die Anforderungen an den Cluster weniger hoch sind, kann man auch auf eine asynchrone Dateireplikation zurückgreifen. Hierfür gibt es eine Vielzahl von Tools und Möglichkeiten, wie z. B. „mirdir“ [6] oder das bekannte und effizient arbeitende „rsync“ [7].

Für die Bereitstellung der Datenbank müssen mehrere Dinge beachtet werden, denn TYPO3 ist mitunter ein sehr Datenbank-intensives CMS. Durch die zum Teil hohe Anzahl von Datenbank-Anfragen kann sich eine nicht-lokale Datenbank allein schon durch die Latenz des Netzwerks sehr negativ auf die Performance des Clusters auswirken. Daher muss eine Lösung gefunden werden, bei der möglichst auf jedem Server lokal ein Datenbankserver läuft. Dies ist mit dem Active-Active-Cluster der MySQL-Datenbank [8] perfekt abbildbar, genauso wie mit einer Oracle RAC-Instanz [9] auf jedem Cluster-Knoten.

Gegen die Verwendung der MySQL-Datenbank sprechen die vielen BLOBs (Binary Large Objects) in der Datenbank einer TYPO3-Instanz. Der MySQL-Cluster speichert seine Datenbanken komplett im Hauptspeicher, wodurch der Haupt-Speicherbedarf auf den Cluster-Knoten sprichwörtlich explodiert. Effizienter arbeitet hier eine Oracle RAC-Instanz, jedoch ist die Installation von TYPO3 darauf komplizierter.

Für die Performance des Clusters ist die Load-Balancing-Software von besonderer Wichtigkeit. In hausinternen Tests sind allerdings große Unterschiede in den Implementierungen der Load-Balancing-Software offenbar geworden.

Eine häufig verwendete Load-Balancing-Software ist Pound [10]. Pound wird schon seit 2002 entwickelt und hat eine große Benutzer-Community. Pound ist unter der GPL lizenziert und wird häufig in Verbindung mit Ruby-On-Rails- oder auch JSF-Clustern eingesetzt. Gegen Pound spricht sein Threading-Modell: Pro Anfrage wird ein „clone()“ des aktuellen Prozesses durchgeführt. Das sorgte bei unseren Tests für eine rasche Saturierung der Cluster-Server. Ein großes Plus von Pound ist hingegen, dass auch SSL-Verbindungen lastverteilt werden können. Besonders in letzter Zeit hat Pound signifikante Verbesserungen erfahren, wie zum Beispiel Online-Rekonfiguration, gewichtete Lastverteilung und einiges mehr.

Komponente	Aufgaben des Active-Active-TYPO3-Clusters
Load-Balancer	1.) Anfrage-Verteilung; 2.) Verwaltung des Mappings; 3.) Client -> Server
Server	Anfrage-Beantwortung
NAS, Cluster FS	1.) Datenverteilung; 2.) Verwaltung konkurrierender Datenzugriffe
Cluster DB	gemeinsame Datenbasis

Eine weitere Load-Balancing-Software ist balance [11]. Balance wird von der deutschen Firma Inlab GmbH entwickelt. Es gibt einen Nicht-GPL-Ableger von balance namens BalanceNG. Diese Version wird von der Inlab offiziell unterstützt. In unseren Tests hatte sich balance immer durch seine Performance und Effektivität hervorgetan. Balance konnte bei unseren letzten Tests immer mindestens 75 Prozent mehr Anfragen pro Sekunde verarbeiten als Pound.

Verglichen mit balance ist Pound allerdings konfigurierbarer, wodurch es als Load-Balancing-Software interessant bleibt. So ist statische Last-Verteilung auf Basis des URIs, Headers und so weiter möglich. So wird Pound zu einem sehr mächtigen und flexiblen Tool zur HTTP-Anfrage-Lastverteilung.

Nachdem die Komponenten des TYPO3-Clusters kurz erläutert wurden, kommen wir nun zum spannendsten Teil: Wie installiert man TYPO3 auf einem Active-Active-Cluster? Die Frage ist schnell beantwortet: Sobald der Cluster steht, funktioniert die Installation genauso wie auf einem einzelnen Server.

Der Grund dafür ist die Datenverteilung. Macht man eine Änderung an einer TYPO3-Instanz, wie zum Beispiel das Installieren einer Extension, stehen Änderungen am Dateisystem, je nach Konfiguration synchron oder asynchron, auf den einzelnen Knoten sofort zur Verfügung. Das Gleiche gilt auch für Modifikationen auf der Ebene der Datenbank. In der Bedienung verändert sich absolut nichts. Dadurch hält der Active-Active TYPO3-Cluster sein Versprechen ein: Er verhält sich nach außen wie ein einzelner Rechner.