Insgesamt ist ein TYPO3-Server somit bereits von Haus aus auch für größere Websites geeignet. Dennoch können verschiedene Anforderungen dazu führen, dass die Normalkonfiguration – eine einzelne Maschine – nicht mehr ausreicht. Was kommt dann? Die Antwort lautet, wie so oft: „Kommt darauf an.“ Worauf genau, das beleuchtet dieser Artikel.

Der Wunsch nach mehr

Ausschlaggebend für die Idee, mehrere Server gleichzeitig für eine Website einzusetzen, können verschiedene Gründe sein. Die wichtigsten sind:

• Leistungssteigerung
• Ausfallsicherheit
• Trennung von Redaktions- und Auslieferungssystem
• geographische Verteilung der Last auf mehrere Server (z.B. Europa/USA)

In der Praxis gehen oft mehrere dieser Gründe Hand in Hand. Doch zunächst zum ersten Aspekt: Mit Leistungssteigerung ist in den meisten Fällen die Anzahl der möglichen Seitenabrufe („Page Impressions“) gemeint. Dies ist eine sinnvolle Größe, da pro Seitenabruf einmal TYPO3 angesprochen wird. Hingegen hängt etwa die Anzahl der „Hits“ (also Webserverzugriffe) oder die übertragene Datenmenge eher von Faktoren wie den enthaltenen Bildern und Ähnlichem ab. Diese Faktoren sind zwar ebenfalls wichtig, bilden aber typischerweise nicht den Engpass für die resultierende Serverleistung. Bei der Betrachtung der Page Impressions ist wichtig zu wissen, dass eine Angabe „pro Monat“ zwar interessant, aber kein genauer Maßstab ist. Ausschlaggebend ist vielmehr die Last, die ein Server in Spitzenzeiten (z.B. „sonntagabends“ oder „immer morgens nach Werbeschaltungen“) zu bewältigen hat (z.B. „Auslastung pro Stunde“). Auch die gewünschte Reserve sollte bedacht werden.

AWStats zeigt für diese Website eine angenehm gleichmäßige Verteilung der Zugriffe über den Tag.

Ein weiterer Aspekt, der unter Leistungssteigerung gefasst wird, ist die Verkürzung der Antwortzeit. Diese hängt insgesamt von vielen Einflüssen ab; hier ist jedoch tatsächlich die Antwortzeit des Servers (und auf TYPO3 bezogen: die Durchlaufzeit von index.php) gemeint. Gerade im Business-Bereich ist heute neben guten Durchsatzzahlen auch eine hohe Ausfallsicherheit des Systems Pflicht. Dass eine Website wegen Serverausfalls nicht erreichbar ist, ist für professionelle Anwendungen heute teuer (sowohl in Bezug auf die Kosten als auch in Sachen Akzeptanz) und somit oft inakzeptabel. In eine andere Richtung zielt die Trennung von Redaktions- und Auslieferungssystemen: Hier soll in der Regel vor allem die redaktionelle Tätigkeit auf spezielle (nicht öffentlich zugängliche) Maschinen verlagert werden. Hinzu kommen fallweise verschiedene weitere Wünsche – etwa die, einen manuellen Veröffentlichungsvorgang einzubinden oder Firewall-Probleme zu überwinden. Ein Sonderfall schließlich ist die geographische Verteilung mit dem Ziel, Anfragen von einem räumlich nahe gelegenen Server zu beantworten. Diese Anforderung findet sich naturgemäß nur bei global ausgerichteten Sites mit hohem Transfervolumen.

Baukastensystem

Im nächsten Schritt soll zunächst der Grundstein für eine optimale Multi-Server-Lösung gelegt werden. Dabei können folgende Bereiche separat betrachtet werden:

• Webserver mit PHP (einschließlich GraphicsMagick, catdoc etc.)
• Dateien mit TYPO3 (Source, Konfiguration etc.) und Content-Daten (Bilder, Dokumente etc.)
• Datenbank
• zusätzliche Komponenten

Auf dem „klassischen“ TYPO3-System sind die drei ersten Punkte auf einem einzigen Server vereint, während mit „zusätzliche Komponenten“ solche Komponenten und Techniken gemeint sind, die speziell für Multiserver-/Hochleistungsumgebungen eingesetzt werden.

Was also tun, wenn der „Standalone“-Server nicht mehr ausreicht? Natürlich könnte dieser zunächst hardwaremäßig hochleistungsfähig und intern redundant ausgelegt werden – gerade wenn man einmal über den x86-Bereich hinausschaut. So sind etwa mit TYPO3 auf IBMs „pSeries“-Servern Zugriffszahlen möglich, die das Vielfache großer x86-Systeme betragen.

Doch der Schwerpunkt dieses Artikels soll auf einem anderen Konzept liegen, nämlich der Verteilung einer TYPO3-Installation auf mehrere Server. Der einfachste Schritt dazu ist die Trennung von Webserver/Dateien einerseits und Datenbank andererseits. Da MySQL selbst als „Ressourcenfresser“ bekannt ist, bringt dieser Schritt bereits eine deutliche Steigerung der Systemleistung. An dieser Stelle sei erwähnt, dass die meisten Aussagen über MySQL im Prinzip auch für andere Datenbanksysteme, wie zum Beispiel Oracle, zutreffen.

Aus Performance-Sicht wäre der logische nächste Schritt, mehrere Webserver auf einen Datenbankserver zugreifen zu lassen. Bei einer durchschnittlichen TYPO3-Website sind mit einer Datenbank problemlos vier bis sechs Webserver bedienbar. Allerdings stellen sich dabei zwei Fragen: Wie können die Dateien (vor allem Content-Dateien wie Bilder und Dokumente) auf allen Webservern aktuell gehalten werden? Und wie können die Anfragen auf die verschiedenen Webserver verteilt werden?

Verteilte Lasten

Um eine Verteilung der Anfragen zu erreichen werden meist vorgeschaltete Komponenten verwendet, so genannte „Network-Load-Balancer“. Diese sind als Software-Lösung (z.B. Linux Virtual Server [1] ) oder als Hardware-Lösung (z.B. von Cisco, Nortel, Kemp und anderen) verfügbar. Die meisten Produkte können zur Steigerung der Ausfallsicherheit auch gedoppelt eingesetzt werden. Die weiteren relevanten Features sind zahlreich. Genannt seien hier die Verteil-Algorithmen (z.B. „Anzahl der offenen Verbindungen“, „Antwortzeit“, „Ressourcen-Auslastung“); die Möglichkeit, einen Benutzer während seines Besuchs immer zum gleichen Server zu leiten (anhand von IP, SSL-ID, Cookie, URL) sowie die intelligente Fehlererkennung. Der Load-Balancer sollte einen Server dann „offline“ schalten, wenn TYPO3 offline ist (z.B. weil ein Fehler beim Datenbankzugriff vorliegt), und nicht nur, wenn der Webserver oder gar das ganze Betriebssystem nicht mehr antwortet.

In Verbindung mit Load-Balancern werden häufig so genannte SSL-Beschleuniger eingesetzt. Bei Websites mit hohem HTTPS-Anteil führt dieser zu erheblicher CPU-Entlastung. SSL-Beschleuniger nehmen den Webservern die Verschlüsselungsarbeit ab und führen diese selbst (in Hardware) durch; der Webserver selbst bekommt nur noch HTTP-Anfragen. Messungen in einer großen TYPO3-Installation haben eine Senkung der CPU-Last auf rund ein Zehntel ergeben. Als „Billig-Alternative“ zum Network-Load-Balancing wird gelegentlich die mehrfache Namensauflösung („Round Robin DNS“) verwendet. Dabei werden mehrere Netzwerk-Adressen für eine Website hinterlegt und die Nameserver geben mal die eine, mal die andere Adresse zurück, wenn sie nach www.mein.server gefragt werden. Dies hat Nachteile: Die mehrfache Namensauflösung schützt nicht vor einem Serverausfall (hierzu werden gerne Scripts installiert, die IP-Adressen von einem Server zum anderen verlagern – problematisch). Und auch die anderen Mechanismen eines Load Balancers sind nicht verfügbar.

Ein weiterer Mechanismus sei noch erwähnt: das Weiterverweisen („Redirect“) an unterschiedliche Server. Kommt beispielsweise eine Anfrage an www.mein.server, so könnte der Anfragende an www1.mein.server weiterverwiesen werden, der nächste an www2.mein.server und so weiter. Um auf Serverausfälle automatisch reagieren zu können, sind allerdings Zusatzmechanismen erforderlich, teilweise vorgelagert, teilweise in TYPO3 – und eine solche Extension ist gegenwärtig noch nicht bekannt. Ein Sonderfall ist die Aufteilung der Anfragen je nach Webseitenbereich (ein Server für Allgemeines, einer für das Forum, ein Server für angemeldete Benutzer). Diese Variante ist einfach zu realisieren und kann durchaus Sinn ergeben.

Mein File, dein File

Im Gegensatz zu anderen Produkten speichert TYPO3 viele Daten nicht in der Datenbank, sondern als Dateien auf der Festplatte. Dies trifft für Bilder und Dokumente zu, aber zum Beispiel auch für einige Konfigurationen, HTML-Vorlagen und CSS-Dateien. All diese Daten müssen auf sämtlichen Webservern zur Verfügung stehen. Mehr noch: Teile davon müssen meist sogar von allen Webservern geschrieben werden dürfen. Hierzu kann ein gemeinsamer Dateiserver verwendet werden, auf den alle Webserver per Netzwerkdateisystem wie NFS oder CIFS (seltener per Storage Area Network mit GFS) zugreifen.

Ausfallsicherheit: Der Auftritt der Volksbank Pforzheim läuft bei zwei unabhängigen Providern; ein Server ist neben Auslieferungs- auch Redaktionsserver.

Als Fileserver kann im einfachsten Fall der Datenbankserver dienen: Steigen die Anforderungen, kommt ein eigener Server oder gar eine Hardwarelösung (z.B. von EMC oder NetApp) in Betracht. Auch bei diesen Systemen sowie deren Anbindung an die Webserver ist auf die erforderliche Leistung/Skalierbarkeit sowie die Ausfallsicherheit zu achten.

Scheut man den Aufwand eines gesonderten Fileservers oder sprechen andere Gründe dagegen (etwa räumliche Entfernung oder der Wunsch nach maximaler Autonomie der Webserver), so kann alternativ auf eine redundante Speicherung aller Daten aufsämtlichen Webservern gesetzt werden. Realisiert werden kann dies durch einen Synchronisierungsmechanismus, zum Beispiel mit Rsync [2] (je nach Datenmenge muss dabei ein Zeitversatz im Minutenbereich berücksichtigt werden). Sofortigen Abgleich hingegen versprechen neuere Lösungen wie unionfs [3] oder Windows Dfs – allerdings liegen hierzu noch keine Erfahrungen in großem Maßstab mit TYPO3 vor.

Und die Datenbank?

Mit den bisher beschrieben Schritten lässt sich schon einiges erreichen. Ein letzter wichtiger Punkt bleibt jedoch noch zu klären: die Datenbank. Zum einen kann auch diese irgendwann an ihre Grenzen stoßen, zum anderen nutzt die beste Hochverfügbarkeit der Webserver nichts, wenn der Datenbankserver ausfällt. Hier ist Abhilfe gefragt. Um die Verfügbarkeit des zentralen MySQL zu erhöhen, war bis vor kurzem das einzig mögliche Mittel, einen zweiten Server als „Slave“ alle Änderungen mitschreiben zu lassen und im Fehlerfall diesen möglichst schnell zum „Master“ zu machen und dafür zu sorgen, dass die weggefallenen Netzwerkverbindungen wieder aufgebaut werden.

Inzwischen gibt es auch für MySQL die Möglichkeit, mehrere Server als Cluster laufen zu lassen. Dadurch ist nicht nur eine durchgängige Verfügbarkeit gewährleistet, sondern auch die gleichmäßige Auslastung aller beteiligten Server. Und da ein Cluster aus mehr als zwei Servern aufgebaut sein kann, besteht bei Bedarf jederzeit die Möglichkeit eines weiteren Ausbaus. Es sei allerdings angemerkt, dass für eine Anwendung wie TYPO3 nicht der MySQL-eigene Cluster (in Dual License von MySQL AB) verwendbar ist, sondern lediglich der kostenpflichtige „MySQL m/cluster“ von Continuent. Ein separater Load Balancer ist für diesen übrigens nicht erforderlich, da die Funktion Bestandteil des m/clusters ist.

Neben dem Ausbau der zentralen Datenbank besteht auch die Möglichkeit mit verteilter Datenhaltung zu arbeiten. Im Extremfall bedeutet das: Jeder Webserver verfügt über seine eigene Datenbankinstanz. Auch hierfür gibt es wieder zwei Varianten: Setzt man auf Datenbank-Replikation (Webserver als Datenbank-„Slave“), so bedeutet dies, dass jeder Webserver ein Abbild der zentralen Datenbanktabellen (einschließlich z.B. unveröffentlichter Seiten) erhält. Die Feinarbeit liegt in der Festlegung, welche Datenbanktabellen von der Replikation ausgenommen werden müssen (ggf. Caching-Daten, Session-Daten) sowie an welchen Stellen Schreibzugriffe von den einzelnen Webservern (z.B. „Gästebuch“) auf die Masterdatenbank umgelenkt werden müssen (durch Modifikation in TYPO3 oder durch eine MySQL-Multi-Master-Konfiguration).

Die zweite prinzipielle Variante mit verteilter Datenhaltung besteht in der gezielten (manuellen oder gar Workflow-gebundenen) Übertragung von Inhalten (Inhaltselemente, Seiten, Seitenbäume und auch Workspaces) auf TYPO3-Ebene – bei automatischer Übertragung von Basisdaten wie Frontend-Benutzern und Ähnlichem. Zu berücksichtigen sind auch hier die Schreibzugriffe der einzelnen Webserver. Für dieses Konzept ist allerdings noch keine vollständige Umsetzung bekannt.

Sechs Live-Server auf einer Datenbank: Auf diesem System arbeiten heute bis zu 500 angemeldete Benutzer und 30 Redakteure gleichzeitig, mit großen Reserven.

Trennung von Live-Servern und Redaktion

Der eingangs erwähnte Aspekt der Trennung von Redaktions- und Auslieferungssystemen („Live-Servern“) ist mithilfe der beschriebenen Ansätze quasi „als Nebenprodukt“ möglich. Wichtig ist dabei, dass der Webserver, der den Redakteuren zur Verfügung steht, direkt auf der zentralen Datenbank arbeitet. Dabei kann dieser Webserver selbst auch wieder gedoppelt und mit einem Load Balancer versehen sein. Dies kann zum Beispiel auch vom Load Balancer der Live-Server übernommen werden. Auf den Live-Servern selbst hingegen sollte das TYPO3-Backend komplett entfernt werden. Dies bedeutet natürlich auch, dass dort kein „Frontend-Editing“ mehr möglich ist – hier ist „Frontend“ nicht mit „Live-Server“ gleichzusetzen, ein häufiges Missverständnis.

High-End: Auch beim Einsatz von Reverse Proxy Caches wird die Ausfallsicherheit der anderen Systeme berücksichtigt.

Mehr Power mit weniger PHP

Ein wichtiger Grund dafür, dass Performance-Fragen in den Vordergrund gerückt sind ist, dass Websites immer dynamischer werden und dass diese Dynamik – bei TYPO3 die von PHP – trotz des ausgefeilten TYPO3-Cachings erheblich rechenintensiver ist als die Auslieferung von statischem HTML. Gerade dort, wo weite Teile einer Website statisch sind, lohnt es sich einen selektiven statischen HTML-Export zu erwägen. Hierfür kommen insbesondere Startseiten in Frage. Auch dabei kann die Verteilung auf mehrere Server Sinn machen. Mächtiger scheint jedoch der Einsatz von Reverse Proxy Caches, der seit TYPO3 Version 3.8.0 möglich ist. Hierbei wird alles, was TYPO3 zum Caching erlaubt, vom Reverse Proxy Cache (z.B. Squid oder Apache) als Datei zwischengespeichert. Bei der nächsten Anfrage wird die Datei wieder ausgeliefert, was dem Bereitstellen von statischem HTML gleichkommt: TYPO3 ist nicht mehr involviert.

Welche Lösung ist die Richtige?

Im konkreten Projekt muss aus dem bisher skizzierten „Baukasten“ ein sinnvolles Ganzes zusammengesetzt werden. Dabei sind Fragen zu beantworten wie

• Welche Last- und Performancedaten sind gefordert?
• Welche Ausfallzeiten sind tolerierbar?
• Wo werden die Systeme gehostet?
• Gibt es weitere Topologie-Bedingungen (wie z.B. „Redaktionssystem intern“, Firewalls etc.)?
• Welches Budget steht zur Verfügung?

Außerdem sollte beachtet werden, dass die Gesamtlösung den Anforderungen des Systembetriebs gerecht wird, das heißt langfristig für die Administratoren beherrschbar ist. Ziel sollte die weitgehende Steuerung über ein Backend-Modul in TYPO3 sein. Auf dieser Basis können ganz unterschiedliche Ausprägungen entstehen. Einige davon sind in den Abbildungen sowie in [4] dargestellt. Sofern mit der gewählten Lösung noch keine Erfahrung vorliegt, empfiehlt es sich diese vor Inbetriebnahme eingehend zu prüfen. Neben der funktionalen Prüfung gehören dazu auch Lasttests. Zunächst zum groben Herausfinden von Kapazitätsgrenzen gedacht, folgt der Test des Dauerbetriebs bei Last unterhalb der Kapazitätsgrenze. Hierbei sollte stets auf Fehlermeldungen in Logfiles aller Komponenten, die Anzahl von Dateien in temporären Verzeichnissen und Tabellen sowie das Verhalten bei Ausfällen einzelner Komponenten („Failover-Tests“) beobachtet werden.

Fazit

Mit TYPO3 werden bereits große Umgebungen mit vielen Servern betrieben. Dass dabei unterschiedliche Konzepte in verschiedenen Kombinationen verwendet werden, liegt zum einen daran, dass einige Techniken noch nicht öffentlich verfügbar sind. Vor allem liegt es aber an den völlig unterschiedlichen Anforderungen, die an eine Multi-Server-Lösung gestellt werden.

In einigen Fällen kommt es vor, dass die konkreten Anforderungen auch mit einer Einzelmaschine abbildbar sind. Einerseits ist vielen gar nicht bewusst, welch große Durchsatzzahlen auch mit einem einzelnen Server erreichbar sind. Andererseits ist immer wieder zu beobachten, dass TYPO3 in vielen Fälle nicht optimal konfiguriert wurde.

Setzt man auf Multi-Server-Technik, so führt an sorgfältiger Planung und spezieller Implementierung heute kein Weg mehr vorbei. Schon mehrfach diskutiert, aber bisher nicht umgesetzt, wurde die Idee, eine hochverfügbare und skalierbare Plattform in das Standard-Angebot eines Webhosters aufzunehmen. So ließen sich die Kosten des Datenbank-Clusters auf mehrere Nutzer verteilen – ein interessanter Ansatz für die nähere Zukunft.