Anzeige
Anzeige
Software
Artikel merken

Multiserver-Szenarien mit TYPO3: Darf es etwas mehr sein?

TYPO3 hat unterschiedliche Eigenschaften, die seinen großen Erfolg begünstigen: Funktionsumfang und Dynamik, Architektur und Flexibilität, eine starke Community und Fundierung durch die Association sowie vieles mehr. Gerade für größere Websites sind daneben auch „Power“ und Stabilität des Systems von Vorteil, wozu zum einen das ausgefeilte TYPO3-interne Caching beiträgt, zum anderen die Verwendung von weit verbreiteten Plattformtechnologien wie PHP.

10 Min. Lesezeit
Anzeige
Anzeige

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

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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:

Anzeige
Anzeige
  • 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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

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.

Anzeige
Anzeige

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.

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?
Zugriffsverteilung
Load Balancer + Ausfallschutz
Round Robin DNS + Kostengünstig
Dateien
Zentraler Fileservice + kein Zeitversatz
+ gut für große Datenmengen
+ kein Verteilungs-Overhead
Redundante Datenhaltung + hohe Zuverlässigkeit
+ Verteilbarkeit auch über Netzgrenzen
+ manuelle/selektive Variante möglich
Datenbank
Cluster + einfacher Betrieb
+ Schreiben durch Live-Server problemlos
Replikation + Verteilbarkeit auch über Netzgrenzen
+ manuelle/selektive Variante möglich
+ keine Lizenzkosten
+ technische Trennung der Live-Systeme

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.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige