Soll eine Vielzahl von Web-Auftritten auf einer zentralen Zope/Plone-Installation gehostet werden, stößt man recht schnell an die Grenzen dieses Web-Content-Ma- nagement-Systems.[1, 2] Vor allem die eher schlechte Performance bei vielen parallelen Zugriffen sorgt dafür, dass man die Anfragen und damit die Last auf viele Server verteilen muss. Das allein genügt aber oft nicht. Der nächste Schritt ist es, die häufig abgefragten Seiten, Bilder und Stylesheets zu cachen, statt sie von Zope/ Plone ständig neu generieren oder aus der Datenbank holen zu lassen, wobei der Cache von Zope/Plone selbst natürlich schnell überfordert ist. Zudem soll das ganze System auch ausfallsicher sein, was den Hardware-Einsatz nochmals erhöht und letztlich neue Probleme generiert.

Zope/Plone-Administratoren stoßen im laufenden Betrieb auf eine ganze Rei- he weiterer Probleme. So ist das System bekannt für seine Speicherlöcher, d. h. ohne regelmäßiges „Durchstarten“ des Zope-Clients läuft der RAM voll, was das System zum „Swappen“ bringt und da- mit die Server in die Knie zwingt.

Wenn Autoren Seiteninhalte ändern und gleichzeitig lesend darauf zugegriffen wird, fällt schlagartig die Performance, da die schreibenden Zugriffe die lesenden blockieren. Durch häufiges Editieren von Seiten wächst die Datenbank-Datei rapide (jede neue Version vergrößert die Daten- bank), was die Zugriffe auf Inhalte eben- falls ausbremst. Mal abgesehen davon, dass man die Datenbank-Dateien auch noch in endlicher Zeit ins Backup-System – also auf Band – bekommen muss. Ein regelmäßiges Packen – also Entfernen alter Content-Versionen – und ein Verteilen von Inhalten auf mehrere File-Storages ist dabei unausweichlich, wobei beim Packen genügend Platten-Kapazität vorhanden sein muss, da die Datenbank- Datei beim Packen kopiert wird. Manche Dateisysteme bekommen übrigens Performance-Probleme, wenn Datei-Größen die Zwei-Gigabyte-Marke sprengen.

Nicht neu ist auch, dass Software fehlerbehaftet ist. Manchmal bleiben Zope- Clients hängen, weil sie durch Ausnah- mefehler in einen undefinierten Zustand geraten. Das macht eine Überwachung zwingend. Je mehr Plone/Zope-Produkte im Einsatz sind, desto mehr kann auch schiefgehen.

Wie man alle diese und die neuen Probleme, die durch die Lösungen entstehen, löst, ohne zu verzweifeln, soll nun anhand der Zope/Plone-Installation erläutert werden, die am Computer- und Medienservice der Humboldt-Universität zu Berlin betrieben wird.

Um zu verstehen, warum wir dieses und kein anderes Setup gewählt haben, muss man die Anforderungen kennen, die an das HU-Setup gestellt wurden:

Zope/Plone-Server-Setup der HU

Die Abbildung 1 gibt eine grobe Übersicht über Komponenten der Zope/Plone-Installation am Computer- und Medienservice der HU wieder. Als Betriebssysteme setzen wir Debian (Zeo-Client/DB-Server) und Ubuntu (Load-Balancer) Linux ein.

Vor den Zeo-Clients sind zwei Server geschaltet, die im Load-Balancing-Betrieb Anfragen auf die Cluster-IP (webmania. cms.hu-berlin.de) entweder an den lokal laufenden Apache oder auf den Apache der Slave-Node weiterleiten. Dabei kommt der Linux Virtual Server (IPVS) zum Einsatz, der im Round-Robin-Verfahren (Algorithmus: rr) eingehende Pakete auf den Ports 80 und 443 an localhost oder an die Slave-Node routet (Direct Routing: dr). [3]

Der Load-Balancer selbst ist geclustert, d. h. bei Ausfall des Masters übernimmt der Slave die Master-Funktionalität (Load-Balancing, Heartbeat). [4] Sollten der Slave oder einzelne Dienste auf dem Master ausfallen, erkennt der Keepalived-Dämon diesen Ausfall und konfiguriert IPVS entsprechend um.

Parallel zum Load-Balancer läuft ein Apache, der URLs aller eingehenden Anfragen mittels Rewrite-Rules in Virtual Host Monster-URLs umschreibt und dann die Anfragen an den ebenfalls auf dem Load-Balancer laufenden Squid weiterreicht (siehe Abb. 2). Der Apache-Server verwendet ausschließlich Rewrite-Regeln und keinerlei Virtual-Host-Konfiguration, um alle ca. 180 Web-Adressen zu bedienen.

Abb. 1: Überblick

Abb. 2: Load-Balancer

Der Squid selbst leitet Anfragen nicht direkt weiter (always_direct never bzw. never_direct allow all), sondern überreicht diese an sogenannte Cache-Peers. Diese Cache-Peers sind die Apache-Server auf den Zeo-Client-Servern. Die Anfragen werden gewichtet verteilt, da wir unterschiedlich leistungsfähige Hardware bei den Zeo-Client-Servern einsetzen. Der Squid-Cache selbst liegt ausschließlich im RAM (via tmpfs) und belegt pro Cluster-Node circa 30GB.

Auf den Zeo-Client-Servern läuft jeweils ein Apache, der anhand der Virtual Host Monster-URL den korrekten Port der dazugehörigen Zeo-Client-Instanz bestimmt und an diese die Anfragen weiterreicht (siehe Abb. 3). Auf den Zeo-Client-Servern, die alle identisch konfiguriert sind, laufen für jede Site eigene Instanzen des Zeo-Clients (derzeit ca. 70). Jeder Zeo-Client kommuniziert mit dem ZeoDatenbank-Server. Außerdem sind die Server paarweise via Heartbeat geclustert (Failover-Konfiguration).

Zusätzlich läuft auf jedem Zeo-Client-Server ein Apache, der über die Standard-Webports 80 (http) und 443 (https) erreichbar ist und wie auf dem Load-Balancer über Squid auf den Port-umschreibenden Apache zugreift, um einzelne Cluster-Knoten testen zu können. Außerdem lässt sich im Notfall die Load-Balancer-Cluster-IP-Adresse auf eine oder mehrere Zeo-Client-Server umlegen (DNS-Round-Robin), was gerade bei Totalausfall des Load-Balancers nützlich ist.

Auf dem Zeo-Datenbankserver läuft für jede Site eine eigene Zeo-Datenbank-Instanz. Die Zeo-Datenbanken liegen auf einem DRB-Device (DRBD=Distributed Replicated Block Device; kurz RAID-1 übers Netz), das sämtliche Schreiboperationen über das interne Netz an den Ausfallserver weiterreicht. Sollte der Datenbank-Server ausfallen, übernimmt automatisch der Ausfall-Server mittels Heartbeat das DRBD-Device und die Cluster-IP-Adresse für den Zeo-Datenbank-Zugriff.

Die gesamte Kommunikation zwischen Load-Balancer, Zeo-Client-Servern und Zeo-Datenbank-Server läuft über ein separates, privates und geswitchtes Netz, das im Moment noch einen „Single Point of Failure“ darstellt, da bei Ausfall des Switches kein alternativer Pfad zwischen den Zeo-Clients und den Zeo-DBs existiert. In den letzten drei Jahren kam es nur zu einem Ausfall und der entstand durch Arbeiten im 19-Zoll-Schrank, in dem sich der Switch befindet – das Stromkabel wurde versehentlich gezogen. Unter Linux könnte man das Problem mit zusätzlichen Netzwerk-Adaptern, separater Switch-Technik und Link-Aggregation (Ethernet Bonding) lösen. [5]

Technische Daten:

Unterstützende Systeme:

Abb. 3: Zeo-Client

Cluster-Probleme

Die Isolation der Web-Sites ist nicht unproblematisch. Da über 70 Instanzen parallel laufen, nehmen sich diese gegenseitig Ressourcen wie Arbeitsspeicher und CPU-Zeit weg. Außerdem verliert man die Site-übergreifende Link-Prüfung, was nur durch zusätzliche Prüfsoftware oder durch Auswertung von Web-Statistiken ausgeglichen werden kann. Tote Links, die in Zope-Instanzen referenzieren, verursachen nicht unerhebliche Performance-Probleme.

Der Einsatz von Load-Balancern und Fail-Over-Clustern schafft neue Probleme und Mehraufwand:

Sicherheitskonzept, Serverüberwachung und Backup

Nicht nur über die Ausfallsicherheit muss man sich beim Betrieb eines solchen Clusters Gedanken machen. Die Server müssen auch vor Angreifern geschützt werden, die die Systeme „cracken“ wollen, um sie als Dateiablage oder als Ausgangspunkt für Angriffe auf andere Server-Systeme im Internet zu missbrauchen.

Üblicherweise werden bei uns alle Server gehärtet: [6]

Bis auf die Apache-Installationen, die die Web-Ports 80 und 443 bedienen, sind alle Port-Bindungen von Apache, Squid, Zeo-Client und Zeo-DB auf private und damit nicht geroutete Netze gelegt. Dasselbe gilt für alle Cluster-Produkte wie Heartbeat. Sie sind aus dem HU-Netz und damit aus dem Internet nicht erreichbar. Durch die Wahl der Ports schützt zusätzlich die Firewall der HU vor Zugriffen von außen. Sämtliche Dienste laufen mit eingeschränkten Benutzerrechten, d. h. nicht mit root-Rechten. Da Ports oberhalb der 1024 verwendet werden, werden auch /etc/ services-Einträge benötigt, um sicherzustellen, dass nicht die normalen, dynamischen Netzverbindungen die Server-Ports belegen.

Um Ausfälle und Angriffe schnell zu erkennen, ist eine Server-Überwachung lebensnotwendig. Neben Nagios, mit dem die Erreichbarkeit von Diensten, die Speicher-, Platten- und CPU-Auslastung und Prozesse überwacht werden, loggen auch alle Server zentral auf einem Loghost. Die Logdaten werden sofort automatisch auf Auffälligkeiten überprüft und die zweimal am Tag erstellten Log-Statistiken helfen ebenfalls, Probleme und Angriffe zu erkennen. Lüfter, Netzteile, RAM, Betriebs-Temperaturen und andere Hardware-Komponenten werden von einem im Server integrierten Controller überwacht und bei Störungen, Ausfällen usw. automatisch per E-Mail gemeldet.

Da Zeo-Client-Instanzen gerne Arbeitsspeicher auffressen, wird der Speicher-Verbrauch aller Instanzen stündlich überwacht und der übermäßige Konsum durch Neustart gestoppt. Leider geraten die Instanzen auch gern in undefinierte Zustände, beispielsweise durch Ausnahme-Fehler. Ein Überwachungsskript, das jede Instanz kontrolliert, indem die Ausgabe der Start-Seite mittels MD5-Summe überprüft wird, hilft dabei zuverlässig, derartige Probleme zu erkennen. Es müssen aber bei zwei auf anderen Servern laufenden Instanzen andere MD5Summen zustande kommen (Mehrheitsentscheid) und der letzte Neustart lang genug her sein, um ein Stopp/Start auszulösen.

Sämtliche Server werden durch das zentrale Backup der HU gesichert. Leider lässt sich die Zeo-DB nicht wie jede Datenbank sichern, d. h. dass man nicht einzelne „Ordner“ oder Content-Objekte aus dem Backup wiederherstellen kann, sondern nur die komplette Datenbank. Man benötigt daher auch immer eine separate Zope-Installation, an die man eine wiederhergestellte Datenbank hängen kann, um dann auf einzelne Objekte zugreifen zu können. Damit ein schneller Zugriff auf die letzten drei gesicherten Zeo-Datenbanken gewährleistet ist, werden diese zusätzlich auf dem NFS-Server abgelegt.

Hilfsskripte

Bei uns kommen eine ganze Reihe von Skripten zum Einsatz, die die Arbeit mit dem Cluster und die Überwachung vereinfachen. Einige hatte ich schon erwähnt, aber der Übersicht halber möchte ich hier mal eine kleine Liste liefern.

Nützliche Skripte bei Änderungen an Konfigurationen und Installationen:

Skripte zur Überwachung:

Weitere Skripte:

Diese Liste von Skripten ist unvollständig und die Quellcodes stellen wir gerne auf Anfrage zur Verfügung.

Statistik

Web-Statistiken können als Argumentationshilfen dienen, wenn es beispielsweise um Browser-Anpassungen von Webseiten geht (Wieso soll sich noch jemand wegen selten benutzter Browser die Mühe von Style-Anpassungen machen? usw.) oder wenn mal neue Hardware beschafft werden muss (viel zu viele Zugriffe ...). Sie helfen, tote Links zu finden oder bei der (Um-)Gestaltung von Einstiegsseiten, da auch Statistiken über Einstiegs- und Ausstiegsseiten („Entry“/“Exit“ Pages) generiert werden. Für unsere Web-Statistiken setzen wir AWstats ein, das recht umfangreiche Informationen liefert. Die Web-Statistiken selbst sind frei zugänglich (Link am Ende des Artikels). [7,8]

Neben Web-Statistiken lassen wir auch System-Aktivitäten („sar“) mitloggen, um Lastspitzen des Betriebssystems besser analysieren zu können und um Engpässe zu erkennen, z. B. Mangel an CPU-Kapazitäten oder Probleme beim I/O-Durchsatz.

Das zentrale Logging unserer Server erlaubt uns, Statistiken über die System-Meldungen zu generieren. Die Häufigkeiten von Einträgen einzelner Schweregrade (Severities) von Anwendungen (Facilities) helfen uns bei der Problem-Erkennung.