Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 7

Wie das CMS lastverteilt betrieben wird: Lastenausgleich mit TYPO3

    Wie das CMS lastverteilt betrieben wird: Lastenausgleich mit TYPO3

Unternehmen präsentieren sich nicht mehr nur auf ihrer Website, sondern stellen mehr und mehr ihre Dienstleistungen zur Verfügung. Dadurch rücken Aspekte wie Verfügbarkeit und Performance in den Mittelpunkt. Die Internetpräsenz eines Kunden kann nicht mehr nur nach optischen Gesichtspunkten optimiert werden, sondern auch in puncto Erreichbarkeit und adäquater Performance. TYPO3-Dienstleister müssen folglich stets bemüht sein, ihren Kunden eine Plattform zur Verfügung zu stellen, die eine hohe Service-Qualität liefert.

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

Hochverfügbarkeit

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.

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden