Der Betrieb eines IT-Systems, welches bereits am ersten Tag von 18.000 Besucherinnen und Besuchern genutzt wurde und seitdem allen Angehörigen der TU Wien rund um die Uhr zur Verfügung steht, stellt eine besondere Herausforderung dar.

Betrachtet man die Auslastung von TISS über den Tag verteilt, so sieht man, dass durchschnittlich zwischen 10:00 und 12:00 Uhr die meisten Seitenaufrufe durchgeführt werden, siehe Abbildung 1. Hierbei kommt es im Monatsdurchschnitt zu 125.000 Seitenaufrufen in der Stunde. Es treten aber auch Spitzen von über 12.000 Seitenaufrufen in der Minute auf, die von der TISS-Infrastruktur verarbeitet werden müssen. Die Anzahl der Seitenaufrufe erreicht zu Semesterbeginn Spitzenwerte (Oktober 2010: 157.977) und sinkt während des Semesters (November 2010: 125.369; Dezember 2010: 111.045; Jänner 2011: 137.260). An Wochentagen werden zwischen 30 und 40 GB pro Tag an Daten an die Nutzerinnen und Nutzer von TISS ausgeliefert.

Daraus ergeben sich hohe Anforderungen an Performance und Verfügbarkeit. Gleichzeitig unterliegt TISS einem sehr dynamischen und agilen Weiterentwicklungsprozess, in dem flexibel neue Anforderungen umzusetzen sind. Hierbei darf es selbst bei großen infrastrukturellen Veränderungen keine Beeinträchtigungen des Services geben.

Ein Apache Webserver Cluster dient als SSL Offloader, womit rechenintensive SSL-Verschlüsselungen im Backend wegfallen. Um Anfragen auf statischen Kontent möglichst schnell beantworten zu können und um das Backend weiter zu entlasten, wird Caching eingesetzt. Anfragen, die der Webserver nicht beantworten kann, wie beispielsweise nach dynamischem Kontent, werden an das Backend System weitergeleitet. Ein Load Balancer Cluster entscheidet, welcher Application Server die Anfrage bedienen kann. Da TISS aus unterschiedlichen Systemen besteht, kann der Load Balancer als fachlicher Dispatcher angesehen werden. Zusätzlich achtet er darauf, dass die Last auf die Infrastruktur gleichmäßig verteilt wird und somit Ressourcen optimal genützt werden. Eine ganz entscheidende Funktionalität des Load Balancers ist allerdings die Berücksichtigung von so genannten Health Checks. Der Load Balancer überprüft zyklisch die Verfügbarkeit und Funktion der einzelnen Application Server. Ist ein Application Server nicht mehr erreichbar oder liefert eine negative Health Statusmeldung, so werden Anfragen auf einen anderen Application Server umgeleitet. Nachdem jeder Application Server auch alle Subsysteme prüft, von denen seine eigene Funktion abhängt, widerspiegelt die Health Statusmeldung die ordnungsgemäße Verarbeitbarkeit von Anfragen. Wenn beispielsweise ein Application Server die Verbindung zum Datenbankserver verliert, so werden alle weiteren Anfragen bis zur Behebung des Fehlzustandes von einem anderen Application Server automatisiert übernommen. Nutzerinnen und Nutzer von TISS bemerken davon in der Regel nichts.

Die dargestellte Architektur zeichnet sich auch durch einen hohen Grad an vertikaler Skalierbarkeit aus. Zusätzliche Application Server können einfach im Betrieb integriert werden, um steigenden Anforderungen bezüglich Performance zu entsprechen.

Der Semesterbeginn ist nicht nur geprägt von gratis Zeitungsabo-Verteilungen und ewig langen Schlangen bei Ticket-Vorverkaufsschaltern sondern auch von der extremen Belastung der TISS-Infrastruktur. In Abbildung 3 werden die Seitenaufrufe im Bereich Lehre zu Semesterbeginn dargestellt. Im Unterschied zu Abbildung 1 sind Seitenaufrufe für andere Funktionalitäten von TISS – wie etwa der Organisationsbereich oder TUphone – nicht berücksichtigt.

Am 1. März kam es zu Überlastungen von TISS in der Zeit von 00:00 bis 01:00 Uhr nachts, zwischen 10:00 und 13:00 Uhr und im Bereich um 19:00 Uhr. TISS konnte Anfragen nicht schnell genug abarbeiten, weshalb es zu Antwortverzögerungen oder sogar Fehlermeldungen durch Timeout kam. Um den produktiven Betrieb aufrechtzuhalten, wurde eine Reihe von Sofortmaßnahmen gesetzt. Entsprechend dem beschriebenen Konzept der Skalierbarkeit wurde ein zusätzlicher Application Server in die Infrastruktur integriert. Des Weiteren wurden die Connection Limits des Load Balancers ins Backend pro Application Server verdoppelt. Der Load Balancer dient zum Schutz vor Überlastung als eine bewusst eingesetzte Drossel. Nachdem die Application Server aber noch genug freie Kapazitäten hatten, konnte dieser Engpass erweitert werden. Zusätzlich mussten weitere Limits bei den Application Servern und bei der Datenbank erhöht werden. Am darauffolgenden Tag kam es trotz einer noch höheren Belastungsspitze zu keinerlei Problemen.

Aktuell wird das Systemverhalten von TISS bei derartigen Extremsituationen analysiert. In einer Teststellung wird das Lastverhalten nachgestellt, Bottlenecks werden identifiziert und ein Maßnahmenkatalog erstellt, um bei der nächsten erwarteten Lastspitze am 1. Oktober noch besser vorbereitet zu sein.

Seit Oktober 2010 kam es effektiv erst zu einer längeren Service-Unterbrechung, am 13. 12. 2010. Grund hierfür war ein defektes RAM-Modul im SUN Datenbankserver. Die Gültigkeit von Murphy´s Law unterstreichend, trat dieser Hardware-Fehler gewissermaßen an der schwächsten Stelle der TISS-Infrastruktur auf. Aus Lizenzgründen wird die Oracle Datenbank als Warm Standby Failover System betrieben, wobei manuell die SAN-Anbindung zwischen dem produktiven und dem Standby Server im Fehlerfall umkonfiguriert werden muss. Hier bleibt abzuwarten, wie sich die Lizenzpolitik und der Support von Oracle weiter entwickeln. Aus betrieblicher Sicht ist jedenfalls eine Datenbank-Migration auf ein Open Source Produkt möglich. Die SUN Hardware wird derzeit durch Systeme eines anderen Herstellers abgelöst.

Ein entscheidendes Merkmal der TISS-Infrastruktur ist der Einsatz von Virtualisierung, wodurch Dienste de facto unabhängig von der darunter liegenden Hardware betrieben werden können.

Derzeit werden auf zwei physischen Servern 29 virtuelle Systeme – in der Mehrzahl Application Server – betrieben. Als Virtualisierungstechnologie wird der Hypervisor Xen eingesetzt. Performance-Tests haben ergeben, dass das Scheduling auf Hypervisor-Ebene effizienter als auf Linux OS Basis ist. Das heißt, zwei virtuelle Maschinen auf der gleichen physischen Hardware mit geteilten Ressourcen können mehr Anfragen behandeln als eine Maschine mit sämtlichen Ressourcen. 

Virtualisierung verringert ganz entscheidend die Komplexität. Hat man nur wenige physische Server zur Verfügung, so entstehen bald so genannte "Multi-Funktionsboxen". Viele Services laufen auf dem gleichen Server, der Absturz eines Dienstes kann leicht andere beeinflussen, geteilte Libraries können bei Updates Seiteneffekte bedingen und vieles mehr. Die System-Administration von derartigen Multi-Funktionsboxen wird schnell komplex, wodurch ein stabiler Betrieb sehr erschwert wird.

Durch den Hypervisor Xen kann für jedes Service leicht eine eigene virtuelle Betriebssysteminstanz aufgebaut werden. Damit schafft man nicht nur eine Komplexitätsreduktion sondern auch eine Isolation jedes Dienstes. An zentraler Stelle kann man den einzelnen virtuellen Instanzen Ressourcen wie etwa RAM oder CPU Cores zuweisen, womit die vorhandenen Ressourcen effizient und fair verteilt werden. Zusätzlich bedeutet dies, dass man auch nur auf zentraler Stelle Ressourcen-Erweiterungen durchführen muss. Wird etwa ein weiteres – entsprechend dem Preis-Leistungs-Verhältnis derzeit optimales – 8 GB RAM-Modul in den physischen Server eingebaut, so kann man im Xen-Management 2 GB dem einen Application Server und die restlichen 6 GB einem anderen Application Server zuweisen. Sollte man die Verteilung wieder ändern wollen, so kann man dies einfach in der Management-Konsole von Xen durchführen. Man muss keine Server aus dem Rack ziehen und Module umstecken. Neben RAM betrifft das aber auch CPU-Ressourcen oder Storage.