Neues vom Webcluster
Wie schon an dieser Stelle erwähnt, bekommt das RRZE neue Webserver.
Mittlerweile wird die neue Softwarekonfiguration auf Testservern erprobt. Diese Servergeneration wird als Betriebssystem nicht mehr Solaris, sondern Linux bekommen. Auch bei den übrigen Softwarekomponenten gibt es einige Änderungen.
Nachdem unsere Clusterserver mehr als 500 Webauftritte von beinahe ebensovielen Webmastern hosten, muss gesichert sein, dass jeder Webmaster nur Zugriff auf seine eigenen Daten hat. In der Praxis bedeutet das, dass ausführbare Skripten mit der Kennung des jeweiligen Webmasters ausgeführt werden müssen.
Der Web-Baukasten der Universität benutzt derartige Skripten zum Aufbau der Seitennavigation oder zum Einbinden von Meldungen aus dem Blogdienst. Auch der NavEditor zählt dazu. Als Programmiersprachen kommen bei den ersteren Perl und beim NavEditor PHP zum Einsatz. Ausgeführt werden sie derzeit beide über die CGI-Schnittstelle des Webservers – mittels SuExec und suPHP, um sicherzustellen, dass nur Skripten des jeweiligen Webmasters ausgeführt werden. Das hat jedoch den Nachteil, dass der Aufbau von skriptbasierten Webseiten nicht besonders schnell vonstatten geht – für jede Anfrage muss ein neuer Prozess gestartet werden. Bei PHP-basierten Anwendungen fällt dies am deutlichsten ins Gewicht.
Um trotz der Eigentümerüberprüfung den Seitenaufbau zu beschleunigen, kann man an zwei Stellen ansetzen:
- man kann die gestarteten Prozesse mehrmals verwenden (z. B. FastCGI kombiniert mit SuExec) oder
- den kompletten Apache-Prozess mit der Webmasterkennung ausführen und für die Ausführung von PHP-Skripten den PHP-Interpreter als Apache-Modul einsetzen (z. B. mod_php mit Apache MPM ITK).
Die beiden hier aufgeführten Varianten haben wir getestet. Der Geschwindigkeitsgewinn bei dynamisch erzeugten Seiten ist bei beiden Lösungen nicht zu übersehen und in etwa vergleichbar. Der Konfigurationsaufwand ist bei der FastCGI-Lösung höher, und sie hat den Nachteil, dass neu gestartete Prozesse als erste Antwort einen Serverfehler ausgeben. Bei statischen Objekten (Bilder, Stylesheets etc.) ist die FastCGI-Lösung im Vorteil.
Wir haben uns dazu entschieden, die ITK-Variante zu verwenden. Die etwas schlechtere Performance bei statischen Dateien gleichen wir durch Varnish aus – einen HTTP-Accelerator, der die Anfragen entgegennimmt und alles, was schon in seinem Zwischenspeicher ist, direkt ausliefert. Nur Anfragen für unbekannte oder nicht zwischenspeicherbare Objekte gelangen dann noch zum Webserver.
Sobald der neue Cluster bezugsfertig ist, werden wir die Webauftritte nach und nach vom derzeitigen Cluster dorthin umziehen.