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

Transkript

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

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

4 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 gehalten. Ausgangslage Seite 4

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

7 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

8 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

9 Entscheidung für eine neue Architektur Seite 9

11 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 User bei ver.di wurden bis zu 40 Kerne für den Application Server vorgeschlagen!) Seite 11

12 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

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

14 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

15 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

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

17 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

18 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

19 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

20 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

21 Konkrete Umsetzung im Rahmen des Projektes: Sizing und Hardware-Auswahl Simulation von bis zu Usern, 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

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

23 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 aktiv 250 aktiv 250 aktiv 250 inaktiv 250 inaktiv 250 inaktiv aktiv 750 aktiv 750 aktiv 750 inaktiv 750 inaktiv 750 inaktiv 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 aktiv 250 aktiv 250 aktiv 250 inaktiv 250 inaktiv 250 inaktiv aktiv 750 aktiv 750 aktiv 750 inaktiv 750 inaktiv 750 inaktiv aktiv 1000 aktiv 1000 inaktiv 1000 inaktiv 1000 aktiv 1000 inaktiv Seite 23

24 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

25 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

26 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

28 Einsatz von GridControl 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

29 Betriebsorganisation Seite 29

30 Betriebsorganisation Seite 30

32 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. > ) Fazit Seite 32

33 Fragen und Antworten Seite 33

34 Kontakt: Torsten Schlautmann OPITZ CONSULTING Gummersbach GmbH Clemens Bruckschen Vereinte Dienstleistungsgewerkschaft Vielen Dank für Ihre Aufmerksamkeit! Seite 34