WWW.UNIVIE.AC.AT
Alte Adresse, neue Architektur

von Peter Marksteiner (Ausgabe 07/3, Oktober 2007)

 

Ein neuer Webserver?

Seit den Anfängen des Webauftritts der Universität Wien im Jahr 1995 wurde im Comment schon mehrmals ein "neuer Webserver" angekündigt.1) Diese neuen Webserver waren jedesmal mit einer Erneuerung des Software-Standes und neuen Features verbunden (z.B. die PHP-Unterstützung seit Juni 2005), das Grundkonzept des Servers WWW.UNIVIE.AC.AT wurde aber seit 1995 nicht wesentlich verändert. Im Großen und Ganzen hat sich dieses Konzept auch gut bewährt: Der derzeit verwendete Unix-Server ist sehr leistungsfähig und kann mehrere Millionen Anfragen pro Tag problemlos bewältigen - an Spitzentagen zu Semesterbeginn sind es alles in allem an die 13 Millionen.

Ein Problem dieses "monolithischen" Servers (siehe Abb. 1) ist allerdings eine gewisse Anfälligkeit: Der Server beherbergt mehrere Millionen HTML-Dokumente und andere Dateien, zahlreiche CGI-Skripts und PHP-Programme. Jede einzelne Seite kann Ziel einer Denial of Service-Attacke werden; Probleme durch ein einziges fehlerhaftes Programm können zu übermäßigem Ressourcenbedarf führen und dadurch den ganzen Server in Mitleidenschaft ziehen. Durch geeignete Maßnahmen kann man solche Probleme zwar eindämmen, aber nicht ganz verhindern. Auch die Software-Wartung ist auf einem so großen und komplexen System schwierig, weil jede Änderung unvorhergesehene Auswirkungen haben kann.

Da der aktuelle Server demnächst an die Grenzen seiner Leistungsfähigkeit stoßen wird, ist bald wieder ein "neuer Webserver" erforderlich. Es wäre relativ einfach, die Hardware zu tauschen (es gibt noch wesentlich stärkere Server!), aber um die oben beschriebenen Anfälligkeiten zu beseitigen, hat sich der ZID entschlossen, stattdessen ein radikal neues Konzept von verteilten Servern einzuführen, das im Folgenden näher beschrieben wird.

Das neue Server-Konzept

Es gibt verschiedene Ansätze, ein verteiltes Konzept zu realisieren. Eine Möglichkeit wäre ein Cluster von Servern, die alle unter demselben Hostnamen zu erreichen sind und über ein verteiltes Filesystem alle auf dieselben Daten zugreifen. Ein Vorteil eines solchen Clusters ist die perfekte Lastverteilung (Load Balancing) - jede Anfrage kann von jedem beliebigen Server im Cluster beantwortet werden. Wir haben uns jedoch für eine andere Lösung entschieden: Nachdem der Webserver der Universität Wien ein historisch gewachsenes, komplexes System ist, kann eine so weit reichende Umstellung kaum auf einmal durchgeführt werden, sondern muss vielmehr schrittweise und ohne nennenswerte Unterbrechung des laufenden Betriebs erfolgen. Auch sollen möglichst wenige Änderungen von Benutzerseite erforderlich sein - d.h. was bisher funktioniert hat, soll auch weiterhin funktionieren.

Die Hauptbestandteile der neuen verteilten Server-Architektur sind ein Frontend und mehrere Backends:

  • Der Frontend-Server ist von außen unter der Adresse WWW.UNIVIE.AC.AT zu erreichen und nimmt alle Anfragen der Klienten (Browser) entgegen. Auch alle virtuellen Hosts (z.B. WWW.UB.UNIVIE.AC.AT) sind auf dem Frontend-Server angesiedelt. Das Frontend beantwortet die Anfragen jedoch nicht selbst, sondern reicht sie unverändert2) an den zuständigen Backend-Server weiter, erhält von diesem die Antwort und schickt sie an die Klienten zurück: Das Frontend ist ein so genannter transparenter Proxy. Das ist eine wenig anspruchsvolle Aufgabe, die von einem einzigen Server mühelos bewältigt werden kann; als Frontend dient daher bis auf weiteres der bisherige WWW-Server.
  • Den Großteil der Arbeit verrichten die Backend-Server: Dort befinden sich alle HTML-Dokumente und anderen Daten3), dort werden auch alle PHP- und sonstigen Skripts ausgeführt. In der Anfangsphase gibt es nur einen Backend-Server; sobald er ausgelastet ist, können problemlos weitere Server angefügt werden. Dadurch ist diese Architektur praktisch beliebig skalierbar. Die Backend-Server sind von außen nicht sichtbar und durch eine Firewall vor jeglichem direkten Zugriff geschützt. Auf welchem Backend sich eine Applikation oder ein Dokument befindet, ist vollkommen unerheblich, weil der Hostname des Backend-Servers nirgends aufscheint. Deshalb ist es auch relativ leicht möglich, Applikationen von einem Backend auf ein anderes zu übersiedeln.

Neben dem Frontend und den Backends zählen noch einige andere Server (Datenbank-, Zugangs- und Logserver) zur Server-Farm, die in ihrer Gesamtheit den "neuen Webserver" bildet (siehe Abb. 2). Manche dieser Server sind als virtuelle Maschinen unter VMWare implementiert.4)

 

Abb. 2: Der Webserver in der derzeitigen Übergangsphase zu einem verteilten System: Ein Teil der Webseiten ist bereits auf den Backend-Servern angesiedelt; für diese fungiert der Frontend-Server als Proxy. Der Rest befindet sich noch auf dem Frontend-Server.

 

Software-Ausstattung der Backend-Server

Das neue Konzept mit mehreren Backend-Servern bietet auch den Vorteil, dass auf verschiedenen Servern unterschiedliche Software (Betriebssystem, Webserver, Applikationsserver usw.) installiert werden kann, sodass Applikationen mit beliebigen Anforderungen unterstützt werden könnten. Für einige Anwendungen wird es spezielle Backends geben, die meisten der Backend-Server werden jedoch eine identische Standard-Ausstattung erhalten: eine LAMP-Architektur (Linux-Apache-MySQL-PHP), die im Open Source-Bereich häufigste Software-Ausstattung von Webservern.

  • Betriebssystem: Als Betriebssystem dient Redhat Enterprise Linux Server Release 5 (www.redhat.com).
  • Webserver: Hierfür wird die neueste Version 2.2.4 von Apache eingesetzt (http://httpd.apache.org/). Einige lokale Modifikationen der Software sorgen dafür, dass die Backends nichts davon merken, dass sie nicht direkt mit dem Klienten sprechen, sondern mit dem Frontend. Das ermöglicht u.a. eine Zugriffskontrolle auf Basis der IP-Adressen der Klienten, obwohl alle Anfragen eigentlich von der IP-Adresse des Frontends kommen.
  • PHP: Bisher stand auf dem Webserver der Universität die Version 4.2.2 von PHP (http://at.php.net/) zur Verfügung. Mit Ende des Jahres läuft aber der Support für die Version 4 aus. Daher wird empfohlen, PHP-Applikationen möglichst bald auf einen Backend-Server zu übersiedeln (siehe Abschnitt Migration), wo die neueste PHP-Version 5.2.4 installiert ist.
  • Perl: CGI-Skripts in Perl oder anderen Sprachen werden weiterhin unterstützt; Perl (www.perl.org) steht in der Version 5.8.8 zur Verfügung.
  • Datenbank: Auf den Backends ist lediglich ein MySQL-Klient installiert. Die Datenbanken befinden sich auf eigenen Datenbank-Servern, auf denen die Version 5.0 der MySQL-Datenbank (www.mysql.de) installiert ist. Auch hier kommen verteilte Server zum Einsatz: Für jeden MySQL-User wird ein virtueller Hostname (CNAME) eingerichtet, der beim Öffnen der Datenbankverbindung anzugeben ist; für den User ihw lautet dieser beispielsweise ihw.mysql.univie.ac.at. Dieser CNAME ist ein Aliasname für den Datenbank-Server, auf dem die jeweilige Datenbank installiert ist. Dadurch ist es möglich, Datenbanken von einem Server auf einen anderen zu verschieben (z.B. zwecks gleichmäßigerer Verteilung der Last), ohne dass irgendwelche Änderungen an Applikationen erforderlich werden.
  • Von minimalen Anpassungen abgesehen ist die Konfiguration des Webservers auf den Backends identisch mit der bisheri-gen Konfiguration, sodass alle Funktionen wie Authentifizierung mittels u:net- und Mailbox-Passwörtern weiterhin unverändert eingesetzt werden können. Eine kleinere Änderung gibt es bei der "Rechtschreibprüfung" durch das Apache-Modul mod_speling: Dieses ist nun so konfiguriert, dass es nur Abweichungen bei der Groß-/Kleinschreibung von URLs stillschweigend ausbessert, aber keinerlei andere Korrekturen (z.B. vertauschte Buchstaben) vornimmt.

    Sicherheit und Berechtigungen

    Im Abschnitt Sicherer Multiuser-Betrieb mit PHP und CGI - eine Herausforderung des eingangs erwähnten Comment-Artikels Gerda geht in Pension wurde genau beschrieben, welche Schwierigkeiten damit verbunden sind, gleichzeitig PHP- und CGI-Unterstützung anzubieten, den BenutzerInnen möglichst viele Freiheiten zu erlauben und dennoch einen sicheren und stabilen Betrieb aufrecht zu erhalten. Das Hauptproblem ist, dass PHP-Skripts vom Webserver selbst ausgeführt werden und daher mit den (sehr weit reichenden) Rechten des Webservers laufen. Damit die Skripts verschiedener BenutzerInnen einander nicht in die Quere kommen oder gar auf fremde Daten zugreifen können, sind Einschränkungen der Privilegien von PHP-Skripts mittels der PHP-Konfiguration unerlässlich.

    Auf den neuen Backends wurde eine andere Lösung implementiert: PHP-Skripts werden nicht vom Apache-Webserver ausgeführt, sondern als externe Prozesse über das CGI-Interface. Das hat folgende Vorteile:

    • PHP- und CGI-Skripts laufen ausschließlich mit den Rechten und Privilegien des Eigentümers (Owner) des Skripts. Auch Dateien, die von PHP-Skripts angelegt wurden, gehören nunmehr dem Eigentümer des Skripts und nicht mehr dem User wwwphp.
    • PHP- und CGI-Skripts können in beliebigen Verzeichnissen ausgeführt werden. Das gesonderte Beantragen der PHP-Unterstützung (nur im Unterverzeichnis php bzw. überall) entfällt.
    • Die PHP-Einstellungen Safe Mode und open_basedir sind damit nicht mehr nötig. Das erleichtert die Installation etlicher Programme, die mit diesen Einstellungen nur schwer zum Laufen gebracht werden können.

    Der Nachteil des Ausführens von PHP-Skripts über das CGI-Interface ist eine schlechtere Performance, weil dafür ein eigener Prozess gestartet werden muss. Aus diesem Grund wird die FastCGI-Schnittstelle verwendet, die im Apache-Modul mod_fcgid (http://fastcgi.coremail.cn/) implementiert ist: Es werden externe Prozesse gestartet, die zahlreiche Skripts abarbeiten können.5) Zusätzlich sorgt der eAccelerator (http://eaccelerator.net/) für eine optimale Performance von PHP-Skripts.

    Ein neuer Zugangsserver

    Bisher erfolgte die Wartung von Webseiten durch direkten Zugriff bzw. Datenübertragung auf WWW.UNIVIE.AC.AT. Einen solchen Zugriff auf die Backends wird es nicht geben; stattdessen steht dafür ein eigener Zugangsserver namens UPLOAD.UNIVIE.AC.AT zur Verfügung. Die Verzeichnisstruktur ist dieselbe wie auf den Backends.

    Anders als bisher sind nun jedoch Dateien im Home-Verzeichnis (z.B. /u/home/ihw) für den Webserver nicht mehr sichtbar, daher müssen HTML-Dokumente im Unterverzeichnis html abgelegt werden (z.B. in /u/home/ihw/html). Will man vermeiden, dass bestimmte Daten via Webbrowser abrufbar sind, müssen sie außerhalb dieses Unterverzeichnisses gespeichert werden. Der bisherige Verzeichnisname /u/www/username (z.B. /u/www/ihw) funktioniert auch weiterhin.

    Der Zugang zum Upload-Server erfolgt auf denselben Wegen wie bisher zum WWW-Server: Die Datenübertragung kann mittels FTP oder (empfohlen) sFTP erfolgen; \\upload.univie.ac.at\username kann als Netzlaufwerk verbunden werden; auch Login mittels SSH und interaktives Arbeiten am Server ist möglich. Lediglich Telnet wird aus Sicherheitsgründen nicht mehr unterstützt. Auf dem Upload-Server sind dieselben Versionen von Perl und PHP installiert wie auf den Backends, sodass Applikationen dort interaktiv getestet werden können.

    Logfiles und Statistiken

    Wer eine Webseite publiziert, will verständlicherweise auch wissen, wie oft und von wem sie gelesen wird. Aus diesem Grund besteht schon seit vielen Jahren die Möglichkeit, die Logdateien einzusehen; sie werden auch automatisch von mehreren Statistikprogrammen ausgewertet.

    Dieses beliebte Service ist nun schon etwas in die Jahre gekommen - die verwendeten Statistikprogramme sind nicht mehr die aktuellsten. Die Reorganisation des Webservers wurde daher zum Anlass genommen, auch dieses Service rundum zu erneuern. Dafür wird ein eigener Server eingesetzt, der die Logdateien von diversen Webservern einsammelt und zentral auswertet. Modernere Statistiken werden demnächst unter dem URL http://webstats.univie.ac.at/ abrufbar sein.

    Migration

    Wie bereits erwähnt, erfolgt die Inbetriebnahme des neuen verteilten Server-Konzepts schrittweise. Auf dem bisherigen WWW-Server und künftigen Frontend wird der Software-Stand eingefroren, es gibt dort keinerlei Innovationen mehr. Neue Benutzungsberechtigungen werden seit dem 10. September 2007 ausschließlich für das neue System vergeben. Die Migration der bestehenden Accounts (mehr als 1500 Benutzungsberechtigungen, die individuell behandelt werden müssen) wird sich voraussichtlich über mehrere Monate erstrecken, wobei der ZID die jeweils verantwortlichen Subserver-BetreiberInnen rechtzeitig von der bevorstehenden Umstellung ihrer Webseiten verständigt. Im Großen und Ganzen besteht kein Grund zur Eile - mit einigen Ausnahmen:

    • Einige Pilot-Anwendungen wurden bereits auf einen Backend-Server übersiedelt. Dabei handelt es sich hauptsächlich um "schwergewichtige" PHP-Applikationen, die hohe Zugriffszahlen aufweisen und den WWW-Server stark belastet haben.
    • Wenn Sie schon jetzt umstellen möchten (beispielsweise weil Sie eine neuere PHP-Version brauchen), vereinbaren Sie einfach per eMail an helpdesk.zid@univie.ac.at einen Termin für die Migration. Während der Übersiedlung sind die betroffenen Seiten in der Regel nur für wenige Minuten nicht erreichbar: Falls es sich um statische HTML-Seiten handelt, sind keinerlei Änderungen nötig, und auch bei PHP- oder Perl-Skripts sind in den meisten Fällen nur minimale Anpassungen vorzunehmen (in der Regel ändert sich lediglich der Name der MySQL-Datenbank). Gelegentlich sind wegen Inkompatibilitäten zwischen den PHP- und MySQL-Versionen kleinere Code-Modifikationen erforderlich.
    • Bei manchen WWW-Accounts gibt es individuelle Sonderlösungen und "Spezialkonstruktionen", die sich nicht automatisch migrieren lassen. Wir werden versuchen, in allen Fällen eine Lösung zu finden, teilweise könnten hier jedoch längere Vorbereitungsarbeiten nötig sein.

    Im Endausbau dient der Frontend-Server WWW.UNIVIE.AC.AT nur mehr als reiner Proxy-Server, dessen "Intelligenz" sich darauf beschränkt, zu wissen, welche Webseiten auf welchen Backends liegen (siehe Abb. 3). Dann wäre auch der Einsatz eines Load Balancers möglich, sodass sich hinter der Adresse WWW.UNIVIE.AC.AT mehrere Frontend-Server verbergen, die sich die Arbeit teilen: Dies würde nicht nur die Skalierbarkeit noch weiter erhöhen, sondern auch für höhere Stabilität sorgen, weil dadurch das Frontend als Single Point of Failure wegfällt.

     

    Abb. 3: Endausbau des verteilten Systems: Alle Daten und Anwendungen befinden sich auf den Backends, das Frontend dient nur als Proxy.

     

    Administration

    An der Administration der Benutzungsberechtigungen ändert sich durch das verteilte Server-Konzept nicht viel; Details zur Vergabe und Verwaltung sind unter http://www.univie.ac.at/ZID/www-userid/ zu finden. Eine Neuerung ist jedoch, dass WWW-Accounts nunmehr mit einem "Ablaufdatum" versehen werden. Vor dem Zeitpunkt des Ablaufs wird der Verantwortliche kontaktiert und der Account formlos verlängert, sofern er noch benötigt wird. Damit soll u.a. sichergestellt werden, dass die Daten der Kontaktpersonen aktuell bleiben: Zur Zeit gibt es zahlreiche Accounts, die vermutlich nicht mehr benötigt werden, was sich aber kaum verifizieren lässt, da keine Kontaktpersonen mehr bekannt sind. Die Übersiedlung der bestehenden Accounts auf die neuen Backend-Server wird auch zum Anlass genommen, diese Altlasten zu "entsorgen".

    Applikationen

    Auf dem Webserver stehen mit PHP und Perl mächtige Werkzeuge zur Verfügung, um eigene Anwendungen zu installieren. Dabei hat sich gezeigt, dass etliche populäre Standard-Applikationen oft gewünscht werden und folg-lich zahlreiche Instanzen dieser Softwareprodukte am Webserver installiert sind: Content Management Systeme (CMS), Diskussionsforen, Gästebücher usw. Diese Instanzen unterscheiden sich meist nur marginal voneinander, haben aber oft unterschiedliche Software-Versionen - und manchmal auch unterschiedliche Sicherheitslücken. Hier wäre eine einzige zentrale Installation effizienter, die nur einmal gewartet werden muss, aber allen BenutzerInnen zur Verfügung steht. Wir werden uns daher in Zukunft verstärkt um die Unterstützung solcher Applikationen auf unseren Webservern bemühen, wodurch Programmieren in PHP oder Perl in vielen Fällen überflüssig werden soll.

    Ein erster Schritt in diese Richtung wurde mit dem Typo3-Projekt6) gemacht: Hierbei wird ein leistungsfähiges und flexibles Content Management System zur Verfügung gestellt. Für Institute bzw. Projekte, die ihren Webauftritt im Rahmen des Typo3-Projekts erstellen, sind die in diesem Artikel beschriebenen Details weitgehend irrelevant: Für Typo3 gibt es dedizierte Backend-Server, und die Wartung und Pflege der betreffenden Webseiten erfolgt ausschließlich mit Hilfe von Typo3, sodass man sich um die Eigenschaften des darunterliegenden Webservers nicht zu kümmern braucht.

    Erneuerung des Webauftritts der Universität Wien

    Nicht nur die Hardware und Architektur des Webservers wird erneuert, auch Inhalt und Form der Webseiten sollen modernisiert werden: Zwar ist auf den verschiedenen Subservern eine Unmenge an Informationen zu finden, jedoch besteht der Webauftritt der Uni Wien aus zahlreichen weitgehend unabhängigen Einzelprojekten, die sich in der Qualität von Inhalt und Form, im Design und in der Organisation stark unterscheiden. Die DLE Öffentlichkeitsarbeit und Veranstaltungsmanagement hat den Auftrag, ein Gesamtkonzept für die Erneuerung des Webauftritts der Universität Wien zu erstellen.

    Es ist klar, dass ein so umfangreiches Projekt nicht von heute auf morgen verwirklicht werden kann. Als erster Schritt werden daher die Startseite und die in der Hierarchie unmittelbar darunter liegenden Seiten erneuert; die modernisierte Startseite soll in Kürze online sein. Für diese Seiten wird ein eigener Backend-Server zur Verfügung stehen, um höchstmögliche Stabilität zu gewährleisten.

    Wie auch immer der neue Webauftritt der Uni Wien im Detail aussehen wird: Mit dem Konzept einer Server-Farm mit Frontend, Backends und Datenbank-Servern steht eine flexible und skalierbare Hardware-Plattform und Software-Architektur zur Verfügung, die auf absehbare Zeit für alle Anforderungen gerüstet ist.

     

     

    1) siehe Artikel Ein neuer Webserver für die Uni Wien in Comment 01/3, Seite 16 bzw. unter http://comment.univie.ac.at/01-3/16/ und Artikel Gerda geht in Pension in Comment 05/2, Seite 36 bzw. unter http://comment.univie.ac.at/05-2/36/

    2) Eine Ausnahme bilden nur verschlüsselte Anfragen (HTTPS), die am Frontend entschlüsselt und unverschlüsselt an die Backends weitergereicht werden: Nachdem die unverschlüsselte Übertragung nur in einem geschützten Netz geschieht, stellt sie kein zusätzliches Sicherheitsrisiko dar.

    3) Physisch liegen die Daten auf den Speichersystemen des Storage Area Network des ZID (siehe Artikel SAN: Das Storage-Projekt macht Fortschritte in Comment 07/1, Seite 16 bzw. unter http://comment.univie.ac.at/07-1/16/), wobei nur die Backend-Server auf die entsprechenden Speicherbereiche (LUNs) zugreifen können.

    4) siehe Artikel Aus eins mach zehn: Der Zauber der Virtualisierung in Comment 07/2, Seite 7 bzw. unter http://comment.univie.ac.at/07-2/7/

    5) FastCGI steht nur für PHP-Skripts zur Verfügung, für "normale" CGI-Skripts wird weiterhin ein eigener Prozess gestartet.

    6) siehe Artikel Webauftritte leicht gemacht: Typo3 an der Universität Wien in Comment 06/3, Seite 37 bzw. unter http://comment.univie.ac.at/06-3/37/