Hochverfügbarkeit und RAC
Agenda Hochverfügbarkeit und RAC 1 01 Agenda 02 Ausgangssituation ti 03 Zielsetzung 04 Oracle MAA (Maximum Availability Architecture) 05 RAC (Real Application Clusters) 06 ASM (Automatic Storage Management) 07 DataGuard 08 Projektstand: Hochverfügbarkeitstests 09 WWK Architektur
Ausgangssituation HP Superdome Umgebung g Superdome 1 Superdome 2 serv0701 (10[+10] * 1.6 GHz / 40 GB RAM) Package Applikation App.-Typ init ANT APP init openft APP prdlifeb lifestream Batch APP serv0702 (4[+10] * 1.6 GHz / 40 GB RAM) Package Applikation App.-Typ initit ANT APP init openft APP prdlea Livelink Enterprise Archive APP serv0707 (2*16GHz/10GBRAM) 1.6 10 GB prddwh PRDDWH, PRDCOG DB serv0708 (1[+1]*16GHz/10GBRAM) 1.6 10 GB 2 serv0709 (4 * 1.6 GHz / 24 GB RAM) prdlifed PRDLIFE DB serv0710 (1[+3] * 1.6 GHz / 24 GB RAM)
Ausgangssituation Aktiv passiv Failoverlösung von HP Betrieb von Anwendungen auf Ersatzhardware -> Auslastung der Systeme Keine Probleme mit ungeplanten Downtimes bei der WWK Geplante p Wartungsarbeiten an Samstagen: 2008: 7 Wartungssamstage 2009: Stand heute: bisher 12 Wartungswochenenden Verfügbarkeit der Arbeitsumgebung: Abends + Wochenende -> Berater 3 tagsüber -> Mitarbeiter im Hause Nachts + Wochenende -> umfangreiche Batchverarbeitungen
Ausgangssituation Clusterfailover von einem System auf den Clusterpartner wird nicht wirklich gelebt: - Anwendungen befinden sich alle ständig in der Erweiterung mit den entsprechenden Folgen in der Pflege -> Synchronhalten der Clusterpartner - Anwendungen dürfen keine Downtime erfahren - Auslastung der Systeme könnte in so manchem Fall kritisch werden Entscheidung der Führung, die Verfügbarkeit der Systeme zu erhöhen (24x365 im Bereich Internetportal) Zusätzliche Belastung der betroffenen Mitarbeiter 4
Ausgangssituation 5 Verfügbarkeit in % Downtime im Jahr (365x24) Tage Stunden Minuten 90 % 36 12 0 95 % 18 6 0 97 % 10 22 48 98 % 7 7 12 99 % 3 15 36 99,9 % 0 8 46 99,99 % 0 0 53 99,999 % 0 0 5 99,99999999 % 0 0 1
Zielsetzung Verlagerung g der Wartungstätigkeiten g in die normale Arbeitszeit und damit Entlastung der Mitarbeiter Erhöhung der Verfügbarkeit der geschäftskritischen Systeme durch Reduzierung der Downtime auf maximal drei Stunden im Monat. Nutzung der gesamten redundant ausgelegten Hardware: - Performancesteigerung g - höherer ROI Aufbau einer Referenzarchitektur für die Integration von geschäftskritischen h WWK-Anwendungen in der neuen Systemlandschaft 6
Oracle MAA (Maximum Availability Architecture) Ungeplante Downtime System Fehler Daten Fehler Storage Fehler Faktor Mensch Datenkorruption System Geplante Änderungen Downtime 7 Daten Änderungen Site Failures
Oracle MAA (Maximum Availability Architecture) 8 Real Application Clusters ASM Flashback RMAN & Oracle Secure Backup H.A.R.D Data Guard Streams Online Reconfiguration Rolling Upgrades Online Redefinition Ora cle MA AA Best Practi ices
Oracle MAA (Maximum Availability Architecture) 9 Geplanter Ausfalltyp Von Oracle Downtime empfohlene Lösung Betriebssystem und Hardware Upgrades Oracle Real Application Clusters (RAC) und Oracle Clusterware Keine Downtime Oracle Interim Patches RAC Keine Downtime Oracle Online Patches Online Patching Keine Downtime Oracle Clusterware Upgrades und Patches Cluster Ready Services (CRS) (RAC) Keine Downtime Upgrade ASM ASM Keine Downtime Migration Storage ASM Keine Downtime Migration nach ASM oder Oracle Data Guard Sekunden bis wenige eine Single Instanz nach Minunten RAC migrieren Patchset und Upgrade der Oracle Data Guard (SQL Sekunden bis wenige Datenbank Apply & logical Standby) Minunten
Oracle MAA (Maximum Availability Architecture) Geplanter Ausfalltyp Von Oracle Downtime empfohlene Lösung Platform Migrationen zwischen Windows und Oracle Data Guard Sekunden bis wenige Minunten Linux Plattformen Plattform Migrationen Transportable Database Minuten bis Stunden auf dem gleichen Endianformat Plattform Migrationen Transportable Minuten bis Stunden zwischen verschiedenen Endianformaten Tablespace 10
11 RAC
12 RAC
ASM I/O-Performance wie bei Raw Devices Einbindung spezielle Treiber für HP-UX zur Verwendung Direct I/O- Funktionen entfällt; ASM greift direkt auf die Raw Devices zu -> Parallele asynchrone Verarbeitung Verbesserung der Performance durch dynamisches Balancing dynamische Optimierung der I/O-Verteilung im System (Storagepool); vereinfachtes Hinzufügen weiterer Platten im laufenden Betrieb Sicherheit vor versehentlichem Löschen von Daten Rebalancing der Daten beim Entfernen von Platten durch den Administrator; i t scheitert t dies, kann die Platte nicht entfernt t werden Spiegelung von Daten neben Striping wird Redundanz konfiguriert: 13 Normal Redundancy: 2-Wege Spiegelung High Redundancy: 3-Wege Spiegelung External Redundancy: keine Spiegelung durch ASM
14 ASM
Data Guard Verfügbarkeit rund um die Uhr Umschalten auf konsistente Datenbankkopie (Failover oder Switchover) Höhere Leistung Auslagerung von Backup oder Berichtswesen auf Replik Synchronisationsstufen (Abwägung Verfügbarkeit gegen Performance) Vereinfachte Abläufe & geringere Kosten komplexes Management herkömmlicher Replikationslösungen entfällt 15 Wiederherstellungszeit nach Benutzerfehler niedriger gegenüber dem Einspielen der Datensicherung und Recovery der DB
16 DataGuard
WWK Architektur 5200 5200 5200 5200 17
Projektstand: Hochverfügbarkeitstests 18 Kontrolliertes Herunterfahren (NODE1) Kontrolliertes Herunterfahren (NODE2) Power off (NODE1) Power off (NODE2) Abziehen eines Kabels auf dem Public Interface (NODE1) Abziehen beider Kabel auf dem Public Interface (NODE1) Abziehen eines Kabels auf dem Public Interface (NODE2) Abziehen beider Kabel auf dem Public Interface (NODE2) Abziehen eines Kabels auf dem private Interface Interconnect (NODE1) Abziehen beider Kabel auf dem private Interface Interconnect (NODE1) Abziehen eines Kabels auf dem private Interface Interconnect (NODE2) Abziehen beider Kabel auf dem private Interface Interconnect (NODE2) Ausfall einer oder mehrerer Platten (->ASM) (NODE1) Ausfall einer oder mehrerer Platten (->ASM) (NODE2) Ausfall komplettes SAN im RZ1 (NODE1) Ausfall komplettes SAN im RZ2 (NODE1) Ausfall komplettes SAN im RZ1 (NODE2) Ausfall komplettes SAN im RZ2 (NODE2) Kill -9 auf Oracle Listenerprozess (NODE1) Kill -9 auf Oracle Listenerprozess (NODE2) Kill -9 auf Oracle Pmon-Prozess (NODE1) Kill -9 auf Oracle Pmon-Prozess Prozess (NODE2)
Projektstand: Hochverfügbarkeitstests 19 Serv1758: /oracle/product/crs/log/serv1758/crsd/crsd.log 2009-04-2104 21 10:21:23.498: 23 [ CRSD][134872] Shutdown Manager: Wait for recovery is complete.0 2009-04-21 10:21:23.499: [ CRSD][134872] Shutdown Manager: Wait for startup is complete 2009-04-21 10:21:23.499: [ CRSD][134872] Shutdown Manager: Wait for ongoing commands is complete 2009-04-21 10:21:23.532: [ CRSD][134872] SM: asked E2E to exit. 2009-04-21 10:21:24.752: [ CRSRES][134884] ] Attempting to stop `ora.serv1758.listener_ SERV1758.lsnr` on member `serv1758` 2009-04-21 10:21:25.914: [ CRSMAIN][42] UI Cmd received after shutdown began. 2009-04-21 10:21:26.391: [ CRSRES][134884] Stop of `ora.serv1758.listener_serv1758.lsnr` on member `serv1758` succeeded. 2009-04-21 10:21:26.426: [ CRSRES][134884] StopResource: setting CLI values 2009-04-21 10:21:26.487: [ CRSRES][134884] StopResource: setting CLI values 2009-04-21 10:21:26.490: [ CRSRES][134884] Attempting to stop `ora.serv1758.vip` on member `serv1758` 2009-04-2104 21 10:21:27.069: 069: [ CRSRES][134884] Stop of `ora.serv1758.vip vip` on member `serv1758` succeeded. 2009-04-21 10:21:35.007: [ CRSRES][134883] Attempting to stop `ora.serv1758.asm2.asm` on member `serv1758` 2009-04-21 10:21:40.151: [ CRSRES][134883] Stop of `ora.serv1758.asm2.asm` on member `serv1758` succeeded. 2009-04-21 10:21:40.223: [ CSSCLNT][32]clssgsGGetStatus: CSS shutting down. 2009-04-21 10:21:40.223: [ CSSCLNT][32]clssgsGGetStatus: returning 22 2009-04-21 10:21:40.231: [ CRSD][32] CRSD exiting on CSS shutdown request 2009-04-21 10:21:40.231: [ CRSD][32] Done. Serv1757: /oracle/product/crs/log/serv1757/crsd/crsd.log 2009-04-21 10:21:40.301: [ OCRMAS][20]th_master:13: I AM THE NEW OCR MASTER at incar 12. Node Number 1 2009-04-21 10:21:40.302: [ OCRRAW][20]proprioo: for disk 0 (/dev/rdisk/disk100), id match (1), my id set (340532584,126570451) total id sets (1), 1st set (340532584,126570451), 2nd set (0,0) my votes (1), total votes (2) 2009-04-21 10:21:40.302: [ OCRRAW][20]proprioo: for disk 1 (/dev/rdisk/disk102), id match (1), my id set (340532584,126570451) total id sets (1), 1st set (340532584,126570451), 2nd set (0,0) my votes (1), total votes (2) 2009-04-21 10:21:40.307: [ OCRMAS][20]th_master: Deleted ver keys from cache (master) 2009-04-21 10:21:41.752: [ CRSCOMM][241] CLEANUP: Searching for connections to failed node serv1758 2009-04-21 10:21:41.752: [ CRSEVT][241] Processing member leave for serv1758, incarnation: 132675916 2009-04-21 04 21 10:21:41.755: [ CRSD][241] SM: recovery in process: 8 2009-04-21 10:21:41.755: [ CRSEVT][241] Do failover for: serv1758 2009-04-21 10:21:42.137: [ CRSRES][243] startrunnable: setting CLI values 2009-04-21 10:21:42.169: [ CRSRES][244] Attempting to start `ora.serv1758.vip` on member `serv1757` 2009-04-21 10:21:42.176: [ CRSRES][247] Attempting to start `ora.hallo.db` on member `serv1757` 2009-04-2104 21 10:21:42.183: 183: [ CRSRES][243] Attempting to start `ora.tstalex.db db` on member `serv1757` 2009-04-21 10:21:42.611: [ CRSRES][247] Start of `ora.hallo.db` on member `serv1757` succeeded. 2009-04-21 10:21:42.703: [ CRSRES][243] Start of `ora.tstalex.db` on member `serv1757` succeeded. 2009-04-21 10:21:49.162: [ CRSRES][244] Start of `ora.serv1758.vip` on member `serv1757` succeeded. 2009-04-21 10:21:49.188: [ CRSEVT][241] Post recovery done evmd event for: serv1758
Vielen Dank für Ihre Aufmerksamkeit. Kontakt: alexandra.strauss@wwk.de