From Database Fog to Database Cloud. Tales of Mistery and Standardization Zurich, 14. September 2011, Paolo Kreth

Transkript

1 From Database Fog to Database Cloud Tales of Mistery and Standardization Zurich, 14. September 2011, Paolo Kreth

2 Die Mobiliar die persönlichste Versicherung der Schweiz Facts & Figures 9x in Folge in Kategorie Sachversicherungen Älteste private Versicherungsgesellschaft der Schweiz (1826 gegründet) Genossenschaftlich verankert Gelebte Kundennähe: 80 Generalagenturen mit eigenem Schadendienst Rund 1,5 Millionen Kundinnen und Kunden Mitarbeitende (Vollzeitstellen) und 303 Lernende und Praktikanten 2,9 Mia. Franken Prämienvolumen Engagements für Kultur, Sport, Gesellschaft und in der Prävention: Hauptsponsor von Unihockey Schweiz, Bärenpark Bern, u.v.m. 2

3 Die Mobiliar IT Facts & Figures rund 450 Mitarbeitende (406 FTE) Clients und Smartphones etwa 150 Standorte, schweizweit vernetzt, incl. VoIP-Telefonie Budget 2011: ca. 132 Mio. CHF ca. 54% Run / 46% Change Systeme z/os, AIX, Windows, Linux Programmiersprachen COBOL, Smalltalk, Java, VB.net Datenbanken IMS, DB/2, Oracle Standardsoftware SAP, COR Life, Siebel, MobiGIS, SAS 3

4 Storage Services FC Storage / NAS Kunden Hardware Architektur Hardware Architektur im Oracle Umfeld: P FHA Power 6 CPU 81 LPARs 28 CPU 1,5 TB RAM UNIX P FHA Power 6 CPU 92 LPARs 34 CPU 1,4 TB RAM 2 P595 mit 1,5 TB RAM 81 und 92 LPARs Tiered Storage Mgmt SAN Exchange (ExC) 2 x HDS AMS 2300 Tivoli Storage Manager 2 x IBM Tape Library x IBM Tape Drives TS x HDS 9500V CISCO Fabric Manager und WebClient HDS Hi-Track Monitoring HDS Storage Navigator HDS Device Manager (TrueCopy) HDS Tuning Manager HDS Tiered Storage Manager HDS Protection Manager (ExC Backup) IBM Tape Library Manager MC License TSMManager EMC Centera Global Services 1 x HDS VSP 2 x HDS USP VM 3 x HDS AMS x HDS AMS 1000 Archive Documentum 2 x EMC Centera 6 x CISCO x CISCO x CISCO 9124 Fileservices 2 x NetApp FAS x CISCO x CISCO x CISCO x AIX (TSM) 7 x WIN (Mgmt) Management / Monitoring Backup / Archive SAN 4

5 Verschiedene CPU Pools Produktion hat Vorrang gegenüber Integration und Entwicklung/Test Default Pool hat Vorrang gegenüber Oracle Pool 42 LPARs mit Oracle Instanzen 550 Instanzen, davon 71 produktive 5

6 RUET Release-spezifische Umgebungen für Entwicklung und Test Pro Release Standard-Umgebungspaar Entwicklung und Test Konzept 2007 Verkürzung Releasing-Phase Verbesserung der Qualität Festlegen einer Standard-Umgebung Systematische Ressourcenplanung 6

7 RUET Anzahl der Umgebungen 7

8 Anwendung von RUET im Oracle Umfeld 1 Umgebung = 1 Instanz Prod Summe

9 Auswirkungen: Administration 550 Instanzen bedeuten also: 550 Release Upgrades 550 Patches 550 Backups * Retention Period 550 Backup Reports 550 Alert Logs Verschiedene Oracle Releases OEM Agents und Grid Control teilweise überlastet Monitoring fällt aus Broken Targets Rediscovery 9

10 Auswirkungen: Hardware Was kosten 480 Test-Instanzen? 550 Instanzen davon 480 Integration und Test: Im Schnitt 25 Hintergrund Prozesse pro Instanz 480* 25 Test Prozesse = Background Prozesse 480 * 2GB RAM = 960 GB RAM Disk Space: System Tablespaces: (System, Sysaux, Undo, Temp) = 3 GB * 480 = 1,5 TB Backup Tape System Daten: 4 Full Backups, 6 TB Daten Einige Instanzen enthalten 25 MB an Testdaten (funktionale Tests) 10

11 Probleme Beispiel 1 CPU Überlastung Nachts stürzen Test Datenbanken ab Mehr als 4000 Defunct Prozesse auf einem LPAR CPU Peek um 22:00 Uhr Backups (FRA to Tape)? CPU Peeks pro Stunde (FRA to Tape) Unix meint, es gäbe noch genügend CPU im Pool 11

12 Probleme Beispiel 1 CPU Überlastung Drill down auf der LPAR Loch um 22:00 Uhr Was passiert mit der Gesamtsumme? Einfach CPU einschalten? Oder: Warum ein Peek um 22:00 Uhr? 12

13 Probleme Beispiel Lösung Was passiert um 22:00 Uhr? Das letzte Backup auf Tape startet um 20:00 Uhr Inkrementelle Backups starten erst um 01:00 Uhr Automatische Tuning Tasks auf 550 Datenbanken Oracle Pool ist überlastet, Produktion hat Priorität Massnahmen: Segment Advisor auf Test abschalten Automatic SQL Tuning Task auf Test abschalten Statistiken auf Test nur wöchentlich Histogramme nur wo notwendig Änderung durch Grid Control 13

14 Probleme Beispiel 2 Db sind Langsam User rufen an, DBs seien langsam Unix zeigt grosse I/O Last auf LPAR 80 Datenbanken auf dem LPAR Wer verursacht die Last? Grid Control zeigt die DBs einzeln Grid Control Bug entdeckt: Patch auf 550 DBs und neue Auswertungen 14

15 Auswirkungen: Probleme Agent hängt -> Metric Collection Error Defunct Prozesse CPU Peek um 22:00 Uhr Statistik-Sammlung Default abhängig von Version Auto Tasks Segment Advisor und SQL Auto Tuning Task CPU Peeks pro Stunde (FRA to Tape) Bugs z.b. v$rman_backup_job_details verurscht hohe I/O Last 15

16 Standardisierung Keine Public Synonyms Keine Public Database Links Ein User Owner des DB Schemas Ein Application User mit Rechte auf Objekte Verschieden Rollen für Zugriffsrechte Alle Datenbanken auf 11gR2 migrieren Verschiedene Services für verschiedene Applikationen Verschieden Tablespaces für verschieden User Grid Control Monitoring Templates Grid Control Gruppen 16

17 Migration auf 11gR2 Ganze Umgebung auf einer Version Einige Umgebungen auf wegen Bug Fixing Regressions-Patch für Ziel: Stabilität für mehrere Jahre Anwendung neuer Features z.b. Inkrementelle Statistiken Auswirkungen von Default Einstellungen einmal optimieren Automatische Tasks starten um 22:00 Uhr Änderung bei Statistiken-Sammlung zwischen 9i, 10g und 11g Histogramme Zeit Oracle Bugs, z.b. v$rman_backup_job_details Mehrere Jahre Support 17

18 Juni 2011 Pilot Zusammenführung Instanzen Aus DBs werden Schemata Applikation Beratungstool (Vorsorge) 2 DBs (TARGET und AVOS) 6 * 2 Testumgebungen (junge Applikation mit wenigen Instanzen) 18

19 Juni 2011 Pilot Zusammenführung Instanzen Einsparungen: Messkriterien Eigenständige DB Total pro DB Multischema DB Einsparung Testdaten Ø 75 MB Target * 6 = 450 MB Ø 160 MB AVOS * 6 = 960 MB MB 0 MB Total MB Systemdaten 2,5 GB * 12 = 30 GB 2,5 GB 27,5 GB RAM (Memory) 2 GB * 12 = 24 GB 2 * 4 GB = 8 GB 16 GB Background- Prozesse 25 * 12 = 300 Proz. 2 * 25 Proz. 250 Proz. DB- Upgrades/Patches Je DB * 12 = 12 Upgr/Pat 2 Upgr/Pat 10 Upgr/Pat Backups (Anzahl) Je DB * 12 =12 Backups 2 Backups 10 Backups Backup-Space (TSM) Je DB ~ 2.5 GB *12*2,5*4 = 120GB 2 * ~3 * 4 = 24 GB ~ 100 GB 19

20 September 2011 Analyse weitere DBs Wo kann man diese Standardisierung noch anwenden? Erste Analyse zeigt 16 Applikationen, bei denen man Datenbanken leicht zusammenführen könnte. Andere Applikationen verfügen nur über eine Entwicklungsinstanz Historische Gründe Terabyte grosse Datenbanken Sind nicht in den Releases involviert Weitere Instanzen könnten Kandidaten werden Man muss trotzdem jede einzelne Applikation analysieren 20

21 Juni 2011 Pilot Zusammenführung Instanzen Schätzung der Einsparungen der ersten 16 Applikationen mit 236 Instanzen: Messkriterien Eigenständige DB Total pro DB Multischema DB Einsparung Testdaten 3.5 Tb 3.5 TB 3.5 TB 0 MB Systemdaten 2,5 GB * 236 = 590 GB 40 GB 550 GB RAM (Memory) 2 GB * 236 = 472 GB 16 * 4 GB = 66 GB 406 GB Background- Prozesse 25 * 236 = 5900 Proz. 16 * 25 Proz Proz. DB- Upgrades/Patches Je DB 236 Upgr/Pat 16 Upgr/Pat 220 Upgr/Pat Backups (Anzahl) Je DB 236 Backups 16 Backups 220 Backups Backup-Space (TSM) Je DB ~ 2.5 GB *236 *2,5*4 = 2360 GB 16 * 2.5* 4 = 24 GB ~ 2200 GB Wichtig: Das Wachstum hält an!!!!! 21

22 September 2011 Analyse weitere DBs Was muss noch gemacht werden? Prozeduren zum automatischen Umgebungsbau müssen angepasst werden Von Datenbank Cloning auf Schema Cloning Verschiedene Szenarien: mit und ohne Daten Von RMAN zu Datapump Jobs Transportable Tablespaces könnte eine Variante sein Umgebungen müssen einen separaten Service Name bekommen Umgebungsbaum muss Zeit für DBAs einplanen Nicht mehr Umgebungsbedingt, sondern global Zeitfenster müssen einbehalten werden 22

23 Phase 3 Database Cloud Für Testumgebungen könnte eine einzige Cloud genügen Verschiedene Clouds für verschiedene Major Patches? Lohnt es sich wirklich (Zeit/Kosten)? Analyse wird folgen für weitere Applikationen Analyse wird folgen für produktive Cloud Welche Datenbanken? Welchen Impact auf Manageability? 23

24 Nice to have from Oracle Plug In / Plug Out von einem Schema AWR Reports auf Schema Ebene Performance View auf Schema Ebene im Grid Control Erweiterung des DBMS_Redifinition 24

25 Fragen? 25