Lernplattform OPAL Maßnahmen zur Sicherung der Verfügbarkeit

Transkript

1 Lernplattform OPAL Maßnahmen zur Sicherung der Verfügbarkeit Jens Schwendel BPS Bildungsportal Sachsen GmbH 25. Februar 2009 Dresden, NRW-Workshop Allgemeine Maßnahmen Betrieb auf leistungsfähiger redundanter Hardware am URZ der TU Chemnitz Umstellung auf Virtual Private Server - Technologie Kein Zweitsystem vorzuhalten, automatischer Wechsel auf neuen Wirt bei Ausfall eines Servers Verteiltes Storage Area Network (SAN) Jederzeit flexible Ressourcenänderung (CPU, RAM, Storage) Deutlich verringerte Zeiten für Backup Redundante Netzanbindung an Internet-Backbone Fortlaufendes Monitoring der Applikationen und Ressourcen inklusive Dokumentation von Parameterverläufen (auch Antwortzeit) Automatische Mail-/SMS-Benachrichtigung bei Problemsituationen Automatisierte Fehleranalysen bei Überschreitung von Grenzwerten Fortlaufende Qualifizierung des eingesetzten Personals 1

2 Analyse der Ursachen von Nicht-Verfügbarkeit Klassifikation über tabellarische Übersicht: Phänomen Mögliche Gründe Differenzierte Ursachen 4 Phänomene aus Nutzersicht: System nicht erreichbar Antwortzeit zu lang Partieller Ausfall von Anwendungsfunktionen Anmeldung nicht möglich Fazit: Vielfältige Ursachen denkbar Serverseitige Hardware- und Netzwerkausfälle sehr unwahrscheinlich Client- bzw. Hochschulseitige Gründe müssen mit bedacht werden Vordergründig von BPS zu vertreten bzw. beeinflussbar: P1: Softwarefehler im LMS P2: Applikationsseitige Konfigurationsfehler P3: Zu hohe Systemlast Maßnahmen für P1 und P2 Ziel: Vermeidung von Software- und Konfigurationsfehlern Aktuelle Maßnahmen: Kontinuierliches Monitoring von Anwendungsfehlern Fortlaufender Abgleich mit OLAT-Bugfixes der Uni Zürich Übernahme erprobter OLAT-Releases (mindestens 2 Monate nach Go-Live an Uni Zürich) Schrittweiser Test neuer Releases / neuer Anwendungsfunktionen / geänderter Konfigurationen (lokal, Demosystem, Konsolidierungssystem) mit definierten und dokumentierten Workflows (u.a. mittels Einführung feingranulares Projektmanagementsystem) Einbezug breiterer Nutzerkreise in Vor-Produktiv-Tests ( 4-Augen-Prinzip bei Updates inklusive Nachweisführung Mittelfristig: Entwicklung und Verstetigung von (teil-)automatisierten Funktions- und Lasttests 2

3 Differenzierung von P3 Ziel: Vermeidung von Ausfällen bedingt durch zu hohe Systemlast Differenzierung der Ursachen P3.1: zu viele Nutzer im Gesamtsystem Hardware- und/oder Systemressourcen überlastet P3.2: zu viele Nutzer in einer einzelnen Anwendungsfunktion oder einem einzelnen Datenobjekt Ressourcenüberlastung und/oder Locking von Anwendungs- /Datenobjekten Systemressourcen (Prozessor, Apache, Hauptspeicher, Tomcat, Datenbank, Dateisystem) werden durch aktuelle Systemkonfigurationen bei hoher Last vollständig ausgereizt Konfigs sind in Abstimmung mit Uni Zürich in Q4/2008 verbessert worden weitergehende OPAL-spezifische Optimierungen nur mit hohem Aufwand möglich (derzeit keine realen Lastsituationen simulierbar) Bereitstellung zusätzlicher Systemressourcen bringt derzeit keine Vorteile, da anwendungstechnisch bedingt keine beliebige Skalierung möglich ist Maßnahmen zu P3.1 Ziel: Bewältigung hoher System-Grundlast durch größeren Ressourceneinsatz Maßnahmen (Reihenfolge = Priorität): Erhöhung DB-Durchsatz durch Clustering des DBMS Sinnvoll, da DB wesentlicher Engpass und >90% lesende Zugriffe Projektgrobplanung erfolgt, Ausschreibung für externen Anbieter Realisierung geplant bis Ende August 2009 Vergrößerung des Speichers für Java-Heap (Tomcat) Sinnvoll, da jede aktive Session einen bestimmten Speicherbedarf hat und Java-Heap relevanter Engpass war (siehe Gast-Sessions) Nur möglich mit Wechsel auf 64Bit-System und umfangreichen Tests Realisierung geplant bis Ende August 2009 Skalierung der OPAL-Applikation (Verteilung auf mehrere Tomcat) Verteilung der Nutzeranfragen auf mehrere Tomcat-Instanzen / CPUs Voraussetzung ist Skalierbarkeit von OLAT (ab OLAT 6.1) Seit 02/2009 im Produktivbetrieb an Uni Zürich Migration von OPAL auf OLAT 6.1 vor WS07/08 (ohne Skalierung) Echte Skalierung bedarf umfangreicher Tests, geplant bis Ende

4 Maßnahmen zu P3.2 Ziel: Vermeidung von Systemausfällen infolge von Lastspitzen bedingt durch bestimmte Funktionen bzw. Objekt-Locking Problem bisher beschränkt auf Massen-Einschreibungen Grundsätzlich wirken sich hier alle Maßnahmen von P3.1 (mehr oder weniger) positiv aus, insbesondere das DB-Clustering Weitergehende Maßnahmen (Reihenfolge = Priorisierung): Hinweise an Autoren zum Umgang mit Einschreibungsszenarien Funktionsanpassung: Verbesserung des Einschreibungsprozesses durch Last-optimierte First-come-first-serve-Schlangen mit clientseitiger Wartelogik Optimierung der DB-Zugriffe für den spezifischen Anwendungsfall Diese drei Maßnahmen werden durch BPS bis Ende März 2009 umgesetzt Fazit und Diskussion Lastspitzen durch Massen-Einschreibungen werden durch Maßnahmen-Mix bis Ende März 2009 verringert/vermieden Bereitstellung höherer Systemressourcen durch DB-Clustering und Java-Heap-Vergrößerung bis Ende August 2009 Schaffung von Voraussetzungen für Applikations-Skalierung durch Migration auf OLAT 6.1 vor WS 09/10 Realisierung Applikations-Skalierung und Abschluss Verfügbarkeitsprojekt bis Ende 2009 Abhängigkeiten zu Finanzierungsmöglichkeiten (Basisdienst/Projekte) Optionale Ergänzungen/Erweiterungen durch Studien-/Diplom- /Masterarbeiten in Kooperation mit Hochschullehrern angedacht Wir bitten Sie (jetzt oder später) um Ihre spezifischen Anmerkungen, Ideen und Wünsche! Herzlichen Dank. 4

5 Ende. Vielen Dank für Ihre Aufmerksamkeit. Bitte fragen Sie! Jens Schwendel Tel: Mail: URL: 5