Erfahrungsbericht: Sizing und Betrieb einer hochverfügbaren Infrastuktur für WebForms-User

Erfahrungsbericht: Sizing und Betrieb einer hochverfügbaren Infrastuktur für 2.500 WebForms-User Torsten Schlautmann Bereichsleiter Service Engineering OPITZ CONSULTING Gummersbach GmbH Clemens Bruckschen Oracle Administration Vereinte Dienstleistungsgewerkschaft Seite 1

Agenda Ausgangslage Entscheidung für eine neue Architektur Sizing und Hardware-Auswahl Betrieb Fazit Seite 2

Im Jahre 2001 entstand die Gewerkschaft ver.di aus den fünf Gründungsorganisationen: DAG (Deutsche Angestellten-Gewerkschaft) DPG (Deutsche Postgewerkschaft) HBV (Gewerkschaft Handel, Banken und Versicherungen) IG-Medien (IG Medien- Druck und Papier, Publizistik und Kunst) ÖTV (Gewerkschaft Öffentliche Dienste, Transport und Verkehr) Im Zuge der Fusion wurde die Kernanwendung zur Mitglieder-Betreuung (MIBS) neu entwickelt Aufgrund verschiedener Rahmenparameter wurde diese Anwendung als Client-Server-Applikation mit dezentralen Datenbanken entwickelt, in der die Daten über ein zentrales System repliziert und abgeglichen wurden. Die Oberfläche wurde mit Forms 6 entwickelt, die Daten wurden in insgesamt mehr als 120 Oracle-Datenbanken der Version 8.1.7 gehalten. Ausgangslage Seite 4

Ausgangslage Bundesverwaltung Citrix-Metaframe ZMIBS Gesamtdatenbestand LAN WAN LAN LAN LAN Aussenstellen (~ 150) Bezirke (102) Landesbezirke (9 von 13) Seite 5

Entscheidung für eine neue Architektur Im Jahre 2004 wurde aufgrund geänderter Rahmenbedingungen ein Projekt zur Konzeption einer neuen Anwendungsarchitektur gestartet. Mit Hilfe einer Nutzwertanalyse wurde mögliche Alternativen einer zukünftigen Architektur bewertet. Bewertet wurden quantitativ bewertbare Kostenaspekte als auch qualitative Kriterien sowie Risikobetrachtungen und Verfügbarkeitsaspekte. Es wurde die Entscheidung für eine zentrale WebForms- Anwendung getroffen. Seite 7

Entscheidung für eine neue Architektur Auf Basis der Vorentscheidung wurde eine Infrastruktur entworfen, die alle gestellten Anforderungen bezüglich Performance, Verfügbarkeit und Skalierbarkeit gewährleisten kann. Hierbei wurde zunächst eine Architektur entworfen, die auf verschiedenen Plattformen zum Einsatz kommen kann. Seite 8

Entscheidung für eine neue Architektur Seite 9

Sizing und Hardware-Auswahl Beweggründe für die intensive Beschäftigung mit dem Thema Sizing: Performance stellt einen Aspekt von Verfügbarkeit dar, d.h. ist die Applikation zu langsam, wird diese von den Anwendern als nicht nutzbar empfunden! Kostenbewußtsein: Ein großer Teil der Kosten für eine zentrale Infrastruktur entsteht durch die Lizenzen und deren Wartungskosten, d.h. Überdimensionierung erzeugt Mehrkosten in verschiedenen Bereichen (Hardware + deren Folgekosten und Lizenzen + deren Folgekosten) Aus der Vergangenheit lagen noch keine Erfahrungen mit dem Oracle Application Server und dessen Parametrisierung vor. Angaben von Hard- und Software-Herstellern zum Sizing sind gerade bei Individualsoftware-Lösungen mit großer Vorsicht zu genießen (Bsp.: Für 2.500 User bei ver.di wurden bis zu 40 Kerne für den Application Server vorgeschlagen!) Seite 11

Sizing und Hardware-Auswahl Vorgehen von ver.di für das Sizing und die Hardware- Auswahl: 1. Durchführung eines grundlegenden Sizings anhand von Berechnungen und Schätzungen, um den Rahmen für die Hardware-Auswahl zu abzustecken (Max. Anzahl Sessions, Speicherverbrauch pro Session [AS + DB], Anteil aktiver Sessions etc.) 2. Durchführung eines vergleichenden Lasttests ( Benchmark ) auf unterschiedlichen Hardware-Plattformen, um die geeignete Infrastruktur auszuwählen und die Skalierbarkeit zu verifizieren Seite 12

Sizing und Hardware-Auswahl Ein Lasttest lässt sich in folgende Phasen unterteilen: Seite 13

Sizing und Hardware-Auswahl Ein Lasttest sollte so realitätsnah wie möglich sein: Hardware Software Datenbestände Nutzeranzahl Nutzungsart Interpolation ist NICHT bzw. nur sehr eingeschränkt möglich! Seite 14

1. Anforderungsprofil erstellen: Sizing und Hardware-Auswahl Wie viele Benutzer arbeiten später mit dem System und müssen simuliert werden? Welche Bandbreiten müssen simuliert werden? Gibt es Spitzenlasten (z.b. Jahresabschlussarbeiten) die simuliert werden müssen? Welche Programmabläufe werden wie häufig und mit welchen Parametern aufgerufen? Welche Denkzeiten sind zu berücksichtigen? Welcher Anteil der Benutzer ist als aktiv, welcher als passiv zu bewerten? Wie soll das Antwortzeitverhalten sein? Seite 15

2. Auswahl eines geeigneten Lastgenerators Sizing und Hardware-Auswahl Seite 16

Sizing und Hardware-Auswahl 2. Auswahl eines geeigneten Lastgenerators (Forts.) hauptsächlich abhängig von dem verwendeten Application-Server / Netzwerk-Protokoll Notwendige Anzahl und Ausstattung an Lasttreibern berücksichtigen!!! z.b. für WebForms kommen in Frage: (s_aturn von Zott & Co. GmbH, Murnau) Intercept Server von Oracle Mercury Loadrunner Segue SilkPerformer für html bzw. http sind auch einige OpenSource-Programme verfügbar: OpenSTA Grinder jmeter Seite 17

3. Operationalisierung des Anforderungsprofils Erzeugung von Testdaten (ggf. Anonymisierung) Aufzeichnung der Abläufe mit dem Lastgenerator Parametrisierung der erstellten Skripte Zusammenfassen von Skripten zu Benutzerprofilen Erzeugung von Parameter-Dateien Erstellung von Lastszenarien Sizing und Hardware-Auswahl Seite 18

4. Durchführung der Messung Sizing und Hardware-Auswahl Definition von Regeln zur Durchführung der Messungen Planung des Ablaufs: Warm-Up/Ramp-up -Zeiten, Dauer der Messungen, Anzahl der Durchläufe usw. Erstellung einer Baseline Mehrfache Wiederholung von Messungen, um die Varianz zu bestimmen Monitoring der Hardware und Software ggf. Fehleranalyse und/oder Identifikation von bottlenecks Dokumentation von Änderungen im Testaufbau Wiederholung der Tests mit unterschiedlicher simulierter Benutzer- Anzahl Seite 19

5. Auswertung und Berechnung Sizing und Hardware-Auswahl Berechnung der Kennwerte (z.b. Antwortzeiten, Durchsatz) entsprechend des Anforderungsprofils Berechnung von Varianzen der verschiedenen Messungen Seite 20

Konkrete Umsetzung im Rahmen des Projektes: Sizing und Hardware-Auswahl Simulation von bis zu 2.000 Usern, 1.000 hierbei gleichzeitig aktiv Durchführung der Tests auf zwei unterschiedlichen Hardware- und Betriebssystem-Plattformen (1x Unix, 1x Linux) Durchführung der Tests für OLTP- und Batch-Betrieb Nutzung des Echtdatenbestandes (ca. 300 GB, anonymisiert) Durchführung der Test mit unterschiedlicher Skalierung (Anzahl User, Hardware-Ausbau) Enger Zeitplan aufgrund von notwendigen Entscheidungen, daher für die Durchführung der Lasttests nur jeweils eine Woche pro Plattform. Seite 21

Sizing und Hardware-Auswahl OLTP-Benchmark Simulation von Oracle Forms Benutzern aktiv inaktiv Summe Test 1 250 250 500 Test 2 500 500 1000 Test 3 1000 1000 2000 Batchverarbeitung Starten einer Soll-Stellung verkürzt auf max. 30 Min. Laufzeit Seite 22

Sizing und Hardware-Auswahl Benutzer Server 3 Server à 2 CPUs 3 Server à 3 CPUs 3 Server à 4 CPUs Plattform Linux 4 Kerne je Server 6 Kerne je Server 8 Kerne je Server 500 250 aktiv 250 aktiv 250 aktiv 250 inaktiv 250 inaktiv 250 inaktiv 1500 750 aktiv 750 aktiv 750 aktiv 750 inaktiv 750 inaktiv 750 inaktiv 2000 1000 aktiv 1000 aktiv 1000 aktiv 1000 inaktiv 1000 inaktiv 1000 inaktiv Plattform Unix 4 Kerne je Server 6 Kerne je Server 8 Kerne je Server 500 250 aktiv 250 aktiv 250 aktiv 250 inaktiv 250 inaktiv 250 inaktiv 1500 750 aktiv 750 aktiv 750 aktiv 750 inaktiv 750 inaktiv 750 inaktiv 2000 1000 aktiv 1000 aktiv 1000 inaktiv 1000 inaktiv 1000 aktiv 1000 inaktiv Seite 23

Sizing und Hardware-Auswahl Batch Server 3 Server à 2 CPUs 3 Server à 3 CPUs 3 Server à 4 CPUs Plattform Linux 4 Kerne je Server 6 Kerne je Server 8 Kerne je Server 30 Min. Soll- Stellung 3x 3x 3x Plattform Unix 4 Kerne je Server 6 Kerne je Server 8 Kerne je Server 30 Min. Soll- Stellung 3x 3x 3x Seite 24

Regeln: Sizing und Hardware-Auswahl nach jedem Testlauf werden alle Systeme (RAC-DB und IAS) neu gestartet nach Beginn der Tests dürfen keine Parameter mehr geändert werden (Zeit!) jeder Test wird dreimal durchgeführt Seite 25

Ergebnis: Sizing und Hardware-Auswahl Beide Hardware-/ Betriebssystemplattformen sind für die Infrastruktur von ver.di geeignet und skalieren gut. Für den Betrieb der Anwendung werden jeweils 3 Application Server (Middle-Tier) und 3 Real Application Cluster Server mit jeweils 2 CPUs / 4 Kernen benötigt. Im OLTP-Betrieb der Anwendung hatte die Plattform A leicht die Nase vorn. Im Batch-Betrieb der Anwendung hatte die Plattform B leicht die Nase vorn. => Die Entscheidung zum Kauf konnte zwischen diesen beiden Plattformen auf der Basis anderer Kriterien (Preisgestaltung etc.) getroffen werden. Seite 26

Einsatz von GridControl 10.2.0.2 Dedizierter Linux Server Vollständige Überwachung aller Server Sogar Überwachung der Loadbalancer Verwendung der Managment Packs Database Diagnostics Pack Database Tuning Pack Intensive Nutzung der GC Berechtigungen z.b. Anwendungsentwickler können Blackouts setzten Zuständige DBAs kümmern sich um ihre Systeme Nutzung der Inventarisierung Server Clients Betriebsorganisation Seite 28

Betriebsorganisation Seite 29

Betriebsorganisation Seite 30

Das Sizing einer hochverfügbaren Infrastruktur mit Application Server und Real Application Cluster ist ein eigenes Projekt. Das richtige Sizing kann im Betrieb viel Ärger verhindern ( zu wenig Performance ) und viel Geld ( zu viel Performance ) sparen. Beim Sizing sollte man sich eine unabhängige Meinung bilden. (Bsp.: 40 Kerne zu 12 Kernen = Faktor 3,3 bzw. > 500.000 ) Fazit Seite 32

Fragen und Antworten Seite 33

Kontakt: Torsten Schlautmann torsten.schlautmann@opitz-consulting.de OPITZ CONSULTING Gummersbach GmbH +49 2261 6001-1175 +49 173 7252409 Clemens Bruckschen clemens.bruckschen@verdi.de Vereinte Dienstleistungsgewerkschaft + 49 30 6956 2978 Vielen Dank für Ihre Aufmerksamkeit! Seite 34