Konzeption des Webserverparks

Beim Entwurf des Webserverparks wurden die folgenden Aspekte besonders berücksichtigt:

  • Dynamische generierte Inhalte: Infoanbietende können überall in ihrem 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 können durch Hinzufügen weiterer Komponenten beseitigt werden, egal ob die Engpässe CPU-Leistung, I/O-Performance, Netzwerkbandbreite, Plattenplatz oder sonstige Komponenten betreffen.

  • Ausfallsicherheit und Stabilität: Fällt eine Komponente des Webserverparks aus, übernehmen andere Komponenten dessen Aufgaben automatisch. Es werden möglichst nur erprobte Komponenten beim Aufbau des Webserverparks eingesetzt.

  • Einfaches Management: Der Webserverpark kann ohne ständige Beaufsichtigung oder gar Eingriffe durch Systemadministrator*innen laufen. Notwendige Sicherheitsupdates werden möglichst automatisch vorgenommen. Es werden möglichst nur standardisierte Komponenten verwendet.

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

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

  • Single Sign-On: Auch wenn es verschiedenste passwortgeschützte Bereiche im Webserverpark gibt, soll doch die einmalige Angabe von Nutzer*innenkennung 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 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 Infoanbietenden 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*innen 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.

Informationsanbietende erhalten einen eigenen, unter einer speziell dafür eingerichteten Nutzer*innenkennung 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 wird zur Anmeldung per SSH / SCP / SFTP auf dem Upload-Server zwingend die Public-Key-Authentifizierung verlangt, eine Anmeldung nur mit Nutzer*innenkennung und Passwort ist nicht mehr möglich. Ein eigener Artikel beschreibt, wie man sich einen Public Key erzeugt und diesen mittels des IT-Portals 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.)