Im Juni 2009 führte WIENFLUSS im Auftrag von WienTourismus den Relaunch der offiziellen Wiener Tourismuswebsite wien.info durch. In einer losen Artikelserie wollen wir ein wenig die Hintergründe und Erfahrungen aus diesem Projekt beleuchten.

Jede Website braucht ein Zuhause, so auch wien.info. Für eine normale Website benötigt man dafür zumindest eine Domain, ein wenig Webspace und vielleicht auch noch eine Datenbank. Dass es damit bei wien.info nicht genug ist, war naheliegend, und wir machten uns auf die Suche nach einem geeigneten Hosting-Anbieter.

Anforderungen an das Hosting

Als ersten Schritt für diese Anbieter-Suche sammelten wir technische, organisatorische und finanzielle Anforderungen. Daraus ergab sich eine Liste von konkreten Kriterien auf Basis derer Hosting-Anbieter zur Angebotslegung eingeladen wurden. Die Kernanforderungen waren:

• hohe Verfügbarkeit: Redundanz, tägliches Backup, zeitnahes Restore, …
• Gute Performance: Hardware, Anbindung, Caching, …
• CMS: Erfahrungen und Kompetenzen im Betrieb von Plone
• Service: Wartung von Hard- und Software, SLA, …

Auch Informationen über aktuelle Zugriffszahlen sind in dieser Phase hilfreich. Einige Zeit vor dem Relaunch wurden folgende Zugriffe registriert:

• Pages: 150.000 pro Tag
• Hits: 750.000 pro Tag
• Traffic: 10 GB pro Tag

Die Auslegung sollte jedoch auf mindestens die doppelten Werte erfolgen. Wie sich im Nachhinein zeigt, liegen die Spitzenwerte auch hier schon drüber.

Hosting-Optionen

Es wurde schnell klar, dass klassische Hosting-Angebote die genannten Anforderungen nicht abdecken können und daher andere Möglichkeiten in Betracht gezogen werden müssen. Im Wesentlichen beschränkte sich die Auswahl daher auf zwei Vorgehensweisen:

1. Anmieten eines bzw. mehrerer dezidierter Server.
2. Hosting bei einem Anbieter der sich auf Plone-Hosting spezialisiert hat.

Während dezidierte Server schon recht kostengünstig angemietet werden können, fallen bei Plone-Hosting nicht unwesentliche Mehrkosten an. Andererseits erspart man sich bei einem Plone-Anbieter den Aufwand für die Einrichtung und laufende Verwaltung des Systems.

Zusätzlich kann man bei einem Plone-Hoster davon ausgehen, dass dieser auch über fundierte Kenntnisse und einen großen Erfahrungsschatz in der Wartung und dem Betrieb eines solchen Systems verfügt. Aus diesen Beweggründen wurde der Option Plone-Hostings der Vorzug gegeben.

Wie und wo findet man nun Anbieter?

Die Liste der professionellen Plone Hosting-Anbieter ist recht überschaubar. Die Kunst besteht darin zu wissen, wo man diese Anbieter findet. Als recht gute Quelle hat sich hier die Liste der „ZOPE-Dienstleister im deutschsprachigen Raum“ herausgestellt. Auch die Mailing-Liste der deutschsprachige Zope User Group (DZUG) sei in diesem Zusammenhang erwähnt. Der entscheidende Hinweis kam aber wie so oft über eine persönliche Empfehlung.

So konnte eine erste Liste von etwa 15 potentiellen Anbietern zusammengestellt werden. Diese wurden in weiterer Folge auf Basis der Anforderungen ein Offert zu legen.

Um die Angebote besser vergleichbar zu machen, wurde ein Punktesystem erstellt. Diese Matrix listet für jeden Anbieter Kriterien aus den Bereichen Technik, Service & Wartung, Lieferzeiten, Kosten, vertragliche Regelungen sowie Referenzen auf. Jeden Bereich erhielt eine gewichtete Bewertung nach dem Schulnotensystem. Ungeeignete Anbieter konnten somit schnell ausgeschieden werden, wodurch sich die Liste auf sieben potentielle Anbieter reduzierte.

Diese Anbieter wurden nun genau unter die Lupe genommen und zu ihren Angeboten befragt. Schließlich konnte dem Auftraggeber eine Short-List von drei Anbietern vorgelegt werden. Aus diesen drei Angeboten wurde dann gemeinsam mit dem Auftraggeber der bestbietende Anbieter 25th Floor ermittelt und beauftragt.

Das Hosting-Setup

Das ursprüngliche Angebot und Setup für den Betrieb sah eine klassische „Managed Dedicated Server“ Lösung vor. Im Laufe der Vorgespräche kristallisierten sich weitere wichtige Anforderungen heraus: Ausfallsicherheit bei Hardware-Defekten und die Möglichkeit, einfach, überschaubar und flexibel vertikal zu skalieren – zu diesem Zeitpunkt waren die Anforderungen der Applikation an die System-Ressourcen noch nicht zu 100% bekannt. Das alles natürlich bei möglichst geringen Kosten und geringem Wartungsaufwand. Zusätzlich sollte auch sichergestellt sein, dass sowohl der Auftraggeber als auch WIENFLUSS jederzeit autonom und uneingeschränkt in das System und dessen Konfiguration eingreifen können.

Der Schritt in Richtung eines ausfallsicheren Clusters lag auf der Hand. Cluster und Hochverfügbarkeit für anspruchsvolle Web-Applikationen und Content Management Systeme sind längst nicht mehr nur für die nationalen und internationalen „Big Player“ ein Thema, sondern auch für Klein- und Mittelbetriebe realisier- und leistbar.

Durch die Verwendung von etablierten, frei verfügbaren und Open-Source Technologien wurde ein loadbalanced Aktiv/Aktiv-Cluster aufgebaut, der alle Cluster-Komponenten wie das Cluster-Management, Shared Storage und Loadbalancing in den vorhandenen zwei Knoten vereint.

Die wesentlichen Eckpunkte des Systems sind im Folgenden dargestellt (mit Dank an das Team von 25th-floor.com für den technischen Input zum Thema Hosting-Setup):

Der Kern des Systems sind die beiden Server (Nodes), die zu einem Cluster zusammengefasst sind. Die beiden Nodes verfügen über einen zentralen Datenspeicher mittels DRDB (Distributed Replicated Block Device). Dieses Dateisystem, das man grob als „netzwerkbasiertes Raid-1“ bezeichnen kann, ermöglicht es, dass beide Systeme immer auf dem selben Datenstand sind. Eine zusätzliche Synchronisation der Daten entfällt somit. In Verbindung mit dem OCFS2 (Oracle Cluster File System 2) wird sichergestellt, dass beide Nodes über dieselben Daten verfügen und auch jeweils Daten schreiben können.

Durch den Verzicht auf z.B. externe Storage-Systeme (iSCSI, FC-SAN) und Management-Nodes konnten die Kosten niedrig gehalten werden, ohne dabei Abstriche bei der Ausfallsicherheit und flexiblen Nutzung des Systems machen zu müssen.

Den beiden Nodes ist ein Load-Balancer vorgelagert, der dafür Sorge trägt, dass die Last zwischen den beiden Systemen sinnvoll aufgeteilt wird. Auf jedem der Systeme läuft ein Webserver (lighttpd), ein Caching Server (varnish) sowie mehrere Plone Instanzen (ZEO-Clients). Diese wiederum greifen auf den ZEO-Server (Zope-Datenbank) zu, der das Plone-System und dessen Daten beherbergt.

Auf Grund des eingangs erwähnten zentralen Datenspeichers kann der ZEO-Server auf einer beliebigen Node betrieben werden. Somit ist im Falle eines Ausfalls der primären Node gewährleistet, dass die zweite Node innerhalb kurzer Zeit (i.d.R. weniger als 60 Sekunden) die Aufgaben des anderen Systems übernehmen kann und dass alle statischen Dateien (i.d.R. Bilder, Javascript-Sourcefiles, CSS, etc.) den Zope-Instanzen zur Verfügung stehen.

Testing & Monitoring

Bevor man so ein Setup nun in die freie Wildbahn entlässt, ist es natürlich notwendig die Funktionalität auch unter verschiedenen Lasten zu testen. Hierfür boten sich zwei Testmethoden an:

1. Lasttest mit Zugriff auf eine Seite oder
2. Lasttest mit Zugriff auf unterschiedliche Seiten.

Die beiden Tests zielen auf unterschiedliche Komponenten des Systems ab. Während der erste Test Aufschluss über die Performance des Webservers bzw. des Cachings gibt, erlaubt die zweite Methode genauere Einblicke in die Performance des Plone-Setups.

Um diese Tests durchzuführen wurden die folgenden Tools verwendet:

• ab: Apache HTTP Server Benchmarking Tool
• pylot: ein auf Python basiertes Web Performance Tool
• Xenu’s Link Sleuth: ein Linkchecker
• Yslow und Page Speed: Firebug Addons zur Performance-Analyse von Yahoo! bzw. Google

ab und pylot wurden zur Simulation von Zugriffen auf bestimmte, einzelne Seiten eingesetzt. Damit war es möglich die Performance verschiedener Konfigurationen des Webservers bzw. des Cache-Servers zu testen, Probleme zu identifizieren und so das optimale Setup zu finden.

Xenu’s Link Sleuth ist eines von vielen Tools, um Links auf einer Website zu überprüfen. Da es damit auch möglich ist bis zu 100 parallele Anfragen abzuschicken, eignet sich dieses Tool auch für einfache Performance-Tests. Da hier bei jeder Anfrage eine neue Seite aufgerufen wird, kommt hier das Caching das Systems nicht zu Tragen (vorausgesetzt der Cache wurde vorher geleert). Auf diese Weise kann man gut evaluieren, ab welcher Last mit Performance-Einbußen zu rechnen ist.

Hinweis: Werden diese Tests von entfernten Systemen ausgeführt, muss darauf geachtet werden, dass vermeintliche Performanceeinbüche nicht durch andere Faktoren (z.B. die lokale Internetanbindung, internes Netzwerk) verursacht werden.

Fazit

Wenn man nicht gerade einen guten Hosting-Anbieter an der Angel hat, kann sich die Suche für Projekte dieser Art durchaus kompliziert gestalten. Der Aufwand lohnt sich aber alle mal. In diesem Segment bekommt man Produkte angeboten, die auf die Bedürfnisse des Vorhabens zugeschnitten sind, aber auch genug Anpassungspotenzial für zukünftige Anforderungen bieten.

In unserem nächsten Beitrag (folgt in Kürze) werden wir uns mit dem Thema „Performance und Caching“ beschäftigen. Dabei werden wir beleuchten, wie man Performance-Probleme identifizieren kann, welche Maßnahmen es gibt, die Performance zu verbessern, und auf ein paar Spezialfälle eingehen, die im Zuge des Relaunch von wien.info zu lösen waren.