Konzeption des Webserverparks

Beim Entwurf des Webserverparks fanden die folgenden Aspekte besondere Berücksichtigung:

  • Dynamische generierte Inhalte: Jeder Infoanbieter kann überall in seinem Webspace PHP-Skripte und beliebige CGI-Programme einsetzen.

  • Konfigurierbarkeit: Die Eigenschaften des Webservers können auf Verzeichnisebene über .htaccess-Dateien weitestgehend frei konfiguriert werden.

  • Skalierbarkeit und Performanz: Eventuell auftretende Kapazitätsengpässe im neuen Webserverpark sollten durch Hinzufügen weiterer Komponenten beseitigt werden können, egal ob die Engpässe CPU-Leistung, I/O-Performance, Netzwerkbandbreite, Plattenplatz oder sonstige Komponenten betreffen.

  • Ausfallsicherheit und Stabilität: Falls eine Komponente des Webserverparks ausfällt, müssen andere Komponenten dessen Aufgaben automatisch übernehmen. Möglichst nur erprobte Komponenten sollen beim Aufbau des Webserverparks Verwendung finden.

  • Einfaches Management: Der Webserverpark soll ohne ständige Beaufsichtigung oder gar Eingriffe durch Systemadministratoren laufen können. Notwendige Sicherheitsupdates sollen möglichst automatisch vorgenommen werden. Soweit wie möglich sollen nur standardisierte Komponenten verwendet werden.

  • Erweiterbarkeit und Anpassungsfähigkeit: Der Webserverpark soll auch zukünftigen Anforderungen nach Möglichkeit gewachsen sein. Notwendige Erweiterungen sollen ohne Schwierigkeiten eingebaut werden können.

  • Sicherheit: Neben umfangreichen Maßnahmen zur Systemsicherheit sollen natürlich auch Datensicherheit und Datenschutz gewährleistet sein.

  • Nachträglich: Single Sign-On: Auch wenn es verschiedenste passwortgeschützte Bereiche im Webserverpark gibt, soll doch die einmalige Angabe von Nutzerkennung und Passwort ausreichen, um auf alle Bereiche zuzugreifen, für die man berechtigt ist.

Das jetzt realisierte Konzept verwendet für fast alle Server ein langlebiges und stabiles Linux (ursprünglich RedHat Advanced Server über Landeslizenz, inzwischen CentOS) als Betriebssystem und Softwarebasis auf leistungsfähiger Standard-Intel-Serverhardware. Nur in notwendigen Fällen wird zusätzliche Software installiert, damit soweit wie möglich der automatische Update-Service von RedHat/CentOS genutzt werden kann.

Als gemeinsames Dateisystem für alle WWW-Daten wird das GPFS-Dateisystem verwendet, welches bereits im ZIV-Cluster seine Stabilität und Performanz bewiesen hat. Zur Datenspeicherung werden gespiegelte RAID5-Plattensysteme in einem in allen Teilen redundant aufgebauten Storage Area Network (SAN) verwendet. Die tägliche Datensicherung erfolgt mit dem bewährten Tivoli-Storage-Manager TSM. Zusätzlich werden fast alle Daten auf ein separates Notfallsystem gespiegelt.

Die Server werden in mehrere funktionelle Gruppen aufgeteilt, wobei einzelne Rechner durchaus auch mehreren Gruppen angehören können:

  • Mehrere Frontend-Server nehmen sämtliche WWW-Kontakte zur zentralen WWW-Adresse www.uni-muenster.de und etlichen anderen WWW-Adressen aus dem Internet entgegen. Ein vorgeschaltetes Lastverteilungssystem verteilt ankommende Anfragen auf die Frontend-Server und sorgt dafür, dass nur laufende Frontend-Server bei der Verteilung berücksichtigt werden. Sofern Anfragen von den Frontend-Servern nicht unmittelbar mit einem Verweis (Redirect) auf ein anderes WWW-Angebot beantwortet werden können, arbeiten diese als Reverse-Proxy-Server und verteilen sie (mittels eingebautem Balancer) auf mehrere Backend-Server.

  • Mehrere normale Backend-Server leisten die Hauptarbeit und greifen auf ein gemeinsames GPFS-Dateisystem zu. Nach Bedarf können weitere Server hinzugefügt werden.

  • Drei oder mehr File-Server sorgen ausfallsicher für den Zugriff auf das GPFS-Dateisystem.

  • Ein Upload-Server erlaubt Infoanbietern die manuelle Pflege ihres WWW-Angebots. (Da Ausfälle dieses Servers keine so gravierenden Folgen haben, wurde auf den Aufbau einer Hochverfügbarkeitslösung verzichtet, inzwischen ist auch diese realisiert.) Auf den Upload-Server kann per SSH / SCP / SFTP (Dienstname upload.uni-muenster.de) zugegriffen werden, außerdem wird mittels Samba für Nutzer aus der Windows-Domain WWU das Netzwerklaufwerk \\upload.uni-muenster.de\wwwdata angeboten.

  • Einige spezielle Backend-Server erledigen besondere Aufgaben, z. B. das Content-Management-System Imperia, und liegen teilweise innerhalb, teilweise außerhalb des Webserverparks. Jeder WWW-Server kann auf diese Weise eingebunden werden.

  • Spezielle  Notfallsysteme an  getrennten Standort werden bereitgestellt, um im Falle größerer Katastrophen zumindest einen eingeschränkten Betrieb zu ermöglichen.

Jeder Informationsanbieter erhält seinen eigenen, unter einer speziell dafür eingerichteten Nutzerkennung laufenden virtuellen Server auf den Backend-Servern. Die Frontend-Server sorgen für die korrekte Abbildung der WWW-Adressen auf die virtuellen Server.

Alternativ kann ein WWW-Angebot auch ganz oder teilweise mit dem Content-Management-System Imperia gepflegt werden. Dieses wird auf einer Gruppe von speziellen Backend-Servern in den Webserverpark eingebunden.

Als wesentlicher Beitrag zum Thema Sicherheit werden alle Zugriffe von außen auf den Webserverpark durch restriktiv konfigurierte Paketfilter auf den verschiedenen Servern blockiert. Ausgenommen sind nur HTTP- und HTTPS-Zugriffe auf die Frontend-Server und SSH- und SMB-Zugriffe auf den Upload-Server sowie SSH-Zugriffe nur von wenigen Administrator-Systemen auf alle Server. Auch zwischen den Servern des Webserverparks werden durch die Paketfilter nur die benötigten Zugriffe gestattet, so dass die Frontend-Server gleichzeitig die Funktion einer Application Firewall ausüben.

Erstmals im ZIV wird zur Anmeldung per SSH / SCP / SFTP auf dem Upload-Server zwingend die Public-Key-Authentifizierung verlangt, eine Anmeldung nur mit Nutzerkennung und Passwort ist nicht mehr möglich. Ein eigener Artikel beschreibt, wie man sich einen Public Key erzeugt und diesen mittels MeinZIV auf dem Upload-Server hinterlegt. Nach dieser einmaligen Einrichtung ist der Zugang sowohl sicherer als auch in der Bedienung noch einfacher.

Alle Konfigurationsdateien der verschiedenen WWW-Server werden aus einer einzigen Konfigurationsquelle erzeugt. Für jedes WWW-Angebot (zu dem u. U. je drei virtuelle Hosts auf Frontend-Server und auf Backend-Server gehören) ist nur eine einzige Zeile in diese Konfigurationsquelle einzutragen. Dies vermindert die Gefahr von Konfigurationsfehlern. (Bei Angeboten unter Host- oder Domainnamen muss zusätzlich dafür gesorgt werden, dass die DNS-Server für diesen Namen die IP-Adresse des Frontend-Servers herausgeben.)


28.06.2010, zuletzt aktualisiert 29.11.2016