ZIDline
Server für Studierende: Next Generation
Fritz Mayer
Seit 1995 lag dem Internet-Service für Studierende die gleiche Server-Struktur zu Grunde. Obwohl sich die alte Struktur bewährte, hatte sie auch Nachteile. Daher werden die Server für Studierende umstrukturiert. Die Inbetriebnahme des Servers mail.student im Sommer 2007 war der erste Schritt zu einer neuen Server- und Servicestruktur.

Bisherige Struktur

Das bisherige Konzept hinter den Servern für Studierende sah eine Anzahl von Systemen vor, auf die alle Studenten-Accounts möglichst gleichmäßig aufgeteilt wurden. Die gleichmäßige Aufteilung war anfangs nicht immer möglich, da die Grenzen zwischen Fachbereichsservern und eigentlichen Studentenservern teilweise nicht ganz klar war. Fachbereichsserver übernahmen in den 90er-Jahren zusätzlich Internet-Services für Studierende. In dieser Zeit gab es die Fachbereichsrechner Server fbma (für Studierende der Studienrichtung Mathematik), studbimb (Bauingenieurwesen und Maschinenbau) und die Studentenserver stud1 und stud2. Als die vorhandenen Server für die wachsende Anzahl der Accounts nicht mehr ausreichten, kam stud3 hinzu. Die Server wurden damals teils unter AIX, teils unter HP-UX betrieben. Da der Aufwand mit jedem hinzugekommenen Server stieg, wurden Ende der 90er-Jahre die Server einer Konsolidierung unterzogen und es blieben nur noch die beiden Server stud3 und stud4 übrig. Seit einigen Jahren speichern beide Server ihre Daten nicht mehr auf internen Festplatten sondern auf einem zentralen Storage.

Wurde auch die Hard- und Software im Laufe der Jahre immer wieder erneuert, blieb das Konzept der Aufteilung der Accounts auf die vorhandenen Server immer gleich. Auf jedem Server wurden die gleichen Services angeboten: Mail-Abruf per POP3- oder IMAP-Protokoll, Mail-Versand per SMTP, Webzugriff über http, Benutzer-Validierung und NFS-Mounten der Home-Verzeichnisse für Logins von den Linux PCs (LIZ) in den Internet-Räumen und interaktives Login über Secure Shell. Über interaktives Login konnten die Studierenden eigene Programme kompilieren und ablaufen lassen. Gerade solche Prozesse bargen die Gefahr, dass sie das gesamte System stören oder gar in einen inoperablen Zustand versetzen könnten. Aber auch die gleichzeitig ablaufenden Prozesse der Basis-Services selbst konnten in gewissen Fällen Störungen verursachen, die das gesamte System betrafen.

In letzter Zeit kamen zusätzlich Services hinzu, wie die Einrichtung von nicht personenbezogenen Kurs-Accounts, für Studierende der Studienrichtung Bauingenieurwesen wurde zusätzlicher Speicherplatz eingerichtet. Seit der Einführung von Webmail stiegen die IMAP-Zugriffe sehr stark an.

Neue Struktur

Steigende Account-Zahlen, schon eingeführte neue Services und der Wunsch nach weiteren neuen Services seitens der Studierenden (PHP, MySQL), aber auch die Tatsache, dass die bisher im Einsatz befindlichen Server (HP900-L2000) bald das Ende ihrer erwarteten Lebenszeit erreicht haben und die Wartungskosten dafür recht beträchtlich sind, machen die Anschaffung neuer Server notwendig. Dies war eine gute Gelegenheit, das alte Konzept zu überdenken und ein neues einzuführen.

Da besonders die Vielfalt der auf jedem Server angebotenen Services Sorgen bereitet, sollen in Zukunft die Services selbst aufgeteilt werden. Dazu werden die Services in die Gruppen Mail, Home und Web eingeteilt. Jede Servicegruppe wird auf einem eigenen Server zur Verfügung gestellt. Das heißt aber auch, dass jeder Account auf jedem Server angelegt werden muss.

Die Umstellung auf die neue Struktur erfolgt schrittweise.

Service mail.student

Als erster Schritt zur neuen Struktur wurde im Juli das Mail-Service von den Servern stud3 und stud4 abgespalten und auf einem neuen Server mit Namen mail.student zur Verfügung gestellt.

Während des Wochenendes von 20. bis 22. Juli wurden alle existierenden Mail-Ordner von ca. 20.000 Accounts mit einem Gesamtumfang von ca. 200 GB auf den neuen Server übertragen. Dabei fand eine Konvertierung vom bisher verwendeten mbox-Format auf das weitaus effizientere maildir-Format statt, welches jede einzelne E-Mail als eine eigene Datei ablegt. Es wurden ca. 120.000 Mail-Ordner auf ca. 6,7 Millionen einzelne Dateien konvertiert. Damit können viele Operationen auf den Mail-Ordnern, die nur einzelne Mails betreffen, viel schneller ausgeführt werden als bisher. Auch inkrementelle Backups dauern nun bei weitem kürzer, da nicht mehr täglich der gesamte Posteingangsordner sondern nur die neuen Mails gesichert werden müssen. Dem entgegen steht allerdings ein etwas höherer Platzverbrauch. Die Quoten auf den Servern stud3 und stud4 blieben mit 200 MB gleich. Dafür wurden alleine auf dem Mail-Server die Plattenquoten pro Account auf 300 MB gesetzt. Das entspricht insgesamt einer Quotenerhöhung um 150%.

Mit der Umstellung des Mail-Services fand auch ein Wechsel von der bisherigen Betriebssystemplattform HP-UX zu Linux (Red Hat Enterprise Linux 5) statt. Der Hauptgrund dafür ist darin zu sehen, dass ein großer Teil der für das Mail-Service benötigten Software unter Linux leichter zu installieren ist als unter HP-UX bzw. für HP-UX gar nicht verfügbar ist. Als Hardware wird ein HP ProLiant DL380 G5 mit zwei Dual-Core-Prozessoren Intel XEON X5160 (3.00 GHz) und 8 GB Hauptspeicher eingesetzt.

Gravierende Änderungen gab es beim Mail-System selbst, insbesondere beim POP- und IMAP-Server. Bisher wurden zwei verschiedene Produkte eingesetzt (qpopper von Qualitas und wu-imap von der University of Washington). Diese beiden Serverprogramme waren aber nicht kompatibel zueinander, was bei gleichzeitigem Zugriff über beide Protokolle hin und wieder zu beschädigten Mail-Boxen führte. Daher wird auf dem neuen Server die Open-Source-Software dovecot eingesetzt, die beide Protokolle versteht. Aber dovecot bietet noch andere Vorteile wie die Unterstützung des Mailfilters sieve und Anzeige von Plattenquoten durch geeignete Mail-Clients.

Über ein Web-Interface:

https://mail.student.tuwien.ac.at/filter/

können Mail-Filter, Weiterleitungen und automatische Beantwortungen viel einfacher eingerichtet werden als bisher. Weiterleitungen, welche bisher über die forward-Datei oder das alte Web-Interface eingerichtet waren, wurden konvertiert und neu angelegt. Kompliziertere Filterregeln, welche von den Benutzern direkt in der procmail-Datei angelegt worden waren, wurden allerdings nicht übernommen und können über das Web-Interface von den Benutzern neu angelegt werden.

Um das Mail-Service so gut wie möglich gegen Störungen abzusichern, ist auf mail.student kein interaktives Login über Secure Shell und somit sind keine durch Benutzer gestarteten Prozesse mehr möglich. Der SSH-Zugang ist aber weiterhin auf den Servern stud3 und stud4 möglich. Der Mail-Abruf über POP- bzw. IMAP-Protokoll ist nur noch verschlüsselt (TLS/SSL) möglich. Benutzer, die die Konfiguration ihres Mail-Clients noch nicht entsprechend geändert haben, können während einer Übergangszeit E-Mails noch mit den alten Einstellungen abrufen. In diesem Fall werden alle POP- und IMAP-Request per Port-Forwarding an den neuen Server weitergereicht. Es wird jedoch empfohlen, die neuen Einstellungen im Mail-Client möglichst bald vorzunehmen.

An den E-Mail-Adressen selbst hat sich nichts geändert. Standardmäßig ist jedem Account die Adresse

e<<Matrikelnummer>>@student.tuwien.ac.at

zugeordnet. Darüber hinaus können die Studierenden über die White Pages auch eine Adresse der Form

vorname.[xxx.]nachname@student.tuwien.ac.at

reservieren. Von der Verwendung von Zustelladressen der Form e<<Matrikelnummer>>@stud[34].tuwien.ac.at bzw. (@mail.student.tuwien.ac.at) wird abgeraten. Auch wenn es sich derzeit um gültige und für die interne E-Mail-Zustellung notwendige Adressen handelt, die auch aus Gründen der Kompatibilität vorläufig noch aufrecht erhalten werden, wird die zukünftige Erreichbarkeit unter diesen Adressen nicht garantiert.

Für den Fall eines längeren Ausfalls des Servers wurde vorgesorgt, indem die Daten auf einen zweiten Server mit getrenntem Storage gespiegelt werden. Die Spiegelung erfolgt über Netzwerk durch die Software DRBD (Distributed Replicated Block Device). Es ist geplant, den zweiten Server in einem baulich getrennten Raum der TU unterzubringen, damit auch Gebäuderedundanz gegeben ist.



E-Mail-Abruf
Posteingangsserver
(Incoming Mail)
mail.student.tuwien.ac.at
unterstützte Protokolle POP3 bzw. IMAP über TLS/SSL
(Standard-Ports)
gesicherte
Kennwort-
Authentifizierung
NEIN 1
 
E-Mail-Versand
Postausgangsserver
(Outgoing Mail)
mail.student.tuwien.ac.at 2
Protokoll SMTP (Standard-Port)
Authentifizierung
über Benutzername
und Passwort
NEIN
gesicherte Verbindung NEIN
 
E-Mail-Adressen
Standard-Adresse
    e<Matrikelnummer>@student.tuwien.ac.at
Nach Einrichtung in White Pages
    vorname.[xxx.]nachname@student.tuwien.ac.at

1 Kennwort ist schon durch TLS/SSL verschlüsselt.

2 Nur falls der absendende Computer zur Domäne tuwien.ac.at gehört. Ansonsten ist der Server des Internet-Providers einzustellen.

Service home.student

Nach der Abspaltung des Mail-Services werden die restlichen Services aufgeteilt, sobald die neuen Server und das Storage-System einsatzbereit sind. Unter home.student (die Bezeichnung wird vielleicht noch geändert) wird ein File-Service angeboten werden, welches über die Protokolle NFS, SMB (CIFS, Samba) und SFTP/SCP erreichbar sein wird. Über diesen Server mounten die LIZ-PCs in den Internet-Räumen die Home-Verzeichnisse der eingeloggten Benutzer, wo diese ihre persönlichen Dateien ablegen können. Das Mounten der Home-Verzeichnisse durch PCs auf Instituten (z.B. Labor) aber auch zuhause (für Rechner innerhalb der tuwien- Domäne) wird dann ebenso möglich sein, wie das derzeit schon durch das Labor für Bauingenieurwesen praktiziert wird. Über SFTP/SCP können die Benutzer von überall ihre Dateien auf den Server und umgekehrt transferieren. Einen interaktiven Shell-Zugang (SSH) wird es jedoch auch auf diesem Server nicht geben. Die Festplattenquoten pro Benutzer stehen noch nicht fest, werden aber deutlich über den derzeit angebotenen 200 MB liegen. Für die kurzzeitige Speicherung größerer Datenmengen wird ein großzügig dimensionierter Scratch-Bereich zur Verfügung stehen. Auch für dieses Service ist ein über DRBD gespiegelter Standby-Server geplant.

Service web.student

Nach Auftrennung der genannten Services bleibt nur noch das Web-Service bzw. der interaktive Shell-Zugang übrig. Auf diesem Server können die Studierenden wie schon bisher ihre persönlichen Web-Seiten ablegen, welche über das http-Protokoll weltweit abrufbar sind. Da die „kritischen Services (Mail, nfs/LIZ) auf andere Systeme ausgelagert sind, kann das Web-Service nun um die von vielen Studierenden gewünschten Komponenten PHP und MySQL erweitert werden. Auch diese Home-Verzeichnisse können über das SMB-Protokoll auf anderen PCs eingebunden werden. Der Transfer von Dateien kann aber auch über SFTP/SCP erfolgen. Auch der interaktive Shell-Zugang über Secure Shell (SSH) wird auf diesem Server möglich sein. Falls es dadurch aber zu Störungen durch unerwünschte Prozesse kommen sollte, müsste der Shell-Zugang doch wieder unterbunden bzw. auf einen vierten Server ausgelagert werden. Die Quoten pro Account für das Web-Service wurden noch nicht festgelegt, werden aber mindestens 100 MB betragen.

Der Web-Server wird so konfiguriert werden, dass auch die schon bisher angebotenen Inhalte über die gleichen URLs abgerufen werden können wie derzeit. Der Server web.student wird also auch (zumindest für eine genügend lange Übergangszeit) über die Namen stud3 und stud4 erreichbar sein.

Zusammenfassung und Ausblick

Der Übergang von einer durch die Anzahl der Accounts bestimmten Struktur zu einer service-orientierten Struktur der Server für Studierende erhöht die Qualität der schon bisher angebotenen Services und macht die Einführung neuer Services möglich. Der erste Schritt zur Realisierung des neuen Konzeptes erfolgte mit der Abtrennung des Mail-Services. Das neue Mail-Service ist seit vier Monaten störungsfrei in Betrieb. Die Abtrennung von File- und Web-Service wird im Laufe des Sommersemesters erfolgen und das Service des ZID für Studierende weiter verbessern.


DRBD (http://www.drbd.org/) steht für Distributed Replicated Block Device. Als Kernel-Modul zusammen mit einer Management-Applikation im Userspace und einem Skript, dient es dazu, ein Blockgerät auf einem produktiven (primary) Server in Echtzeit auf einen anderen (secondary) Server zu spiegeln. Dieses Verfahren wird verwendet, um Hochverfügbarkeit(HA) im UNIX/Linux Umfeld zu realisieren und somit eine gute Verfügbarkeit verschiedener Dienste zu erreichen.

Siehe auch Diplomarbeit von Reisner, Philipp: DRBD: Festplattenspiegelung übers Netzwerk für die Realisierung hochverfügbarer Server unter Linux. TU Wien, 2000.