Konsolidierungsplattform Exadata Betriebliche Erfahrungen. Gregor Büchner (Deutsche Telekom IT GmbH) Mai 2017

Transkript

1 Konsolidierungsplattform Exadata Betriebliche Erfahrungen Gregor Büchner (Deutsche Telekom IT GmbH) Mai 2017

2 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

3 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

4 Die Idee zur Konsolidierungsplattform 300+ unterschiedliche Kombinationen für ORACLE db Konsolidierungsplattform Exadata Ultra-SPARC SPARC64 SPARC T4 SPARC T5 Dell HP FTS Intel x86 AMD x86 Power 5 Power 6 Power 7 Power 8 Dell HP FTS Intel x86 AMD x86 HP RISC 4

5 Twincore Datacenter 1 Datacenter 2 ITSF x86 VMWare ITSF x86 VMWare Classic Classic ITSF Solaris Security Zone 1 ITSF Solaris Security Zone 1 DWDM ITSF AIX ITSF AIX ITSF Solaris Security Zone 2 ITSF Solaris Security Zone 2 5

6 Twincore Datacenter 1 Datacenter 2 ITSF x86 VMWare Security Zone 1 nonprod/prod Dataguard Referenz/DR Engineering ITSF x86 VMWare Classic Classic ITSF Solaris Security Zone 1 ZFS-Replikation ITSF Solaris Security Zone 1 DWDM ITSF AIX Security Zone 2 nonprod/prod Dataguard Referenz/DR ITSF AIX ITSF Solaris Security Zone 2 ITSF Solaris Security Zone 2 ZFS-Replikation 6

7 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

8 Migrationsmethoden Grundlegendes zur Migration: dedizierte Migrationsleitungen zwischen den Lokationen transportable Filer zeitlich abgestimmte Planung zur Nutzung der Leitungen Berücksichtigung Applikations-Schnittstellen Rückfall-Szenarien Auszeit-Koordination zusätzliche Storagekapazitäten (Dumps, Archive, Redologs) Koordination mit fachlichen Releases Verschlüsselung 8

9 Migrationsmethoden Datapump (Export/Import) Transportable Tablespaces RMAN duplicate/dataguard DB-Kopie/GoldenGate keine zusätzlichen Lizenzkosten unabhängig von Quell- und Ziel- OS Reorg der Daten inklusive Downtime der Applikation bei der kompletten Migration kein Fallback nach Takeover, neue Migration notwendig keine Unterstützung von LONG/LONG RAW und Objekttypen Nacharbeiten keine zusätzlichen Lizenzkosten unabhängig von Quell- und Ziel- OS RMAN convert bei ungleichem Endianess-Format von Quell- und Ziel-OS Downtime der Applikation beim letzten Migrationsschritt kein Fallback nach Takeover, neue Migration notwendig erhöhter Aufwand in der Vorbereitung und Konfiguration Nacharbeiten einfach im Setup und der Administration kurze Downtime für die Applikation beim Switchover schneller Fallback auch nach Takeover Nutzung in der Oracle EE Lizenz enthalten nur möglich bei gleichem Endianess-Format von Quell- und Ziel-OS Aufsetzpunkt: kopierte Datenbank GG unabhängig von Quell- und Ziel-OS minimale Downtime für die Applikation schneller Fallback auch nach Takeover zusätzliche Lizenzkosten erhöhter Aufwand in der Vorbereitung und Konfiguration komplex in der Administration 9

10 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

11 Wartungskonzept Grundlegendes zur Wartung: geplante Wartungsfenster für die Plattform im Change-Kalendar abgestimmt mit fachlichen Wartungen Engineering-Exadata zur Vertestung der Patchsets Test von Rollback-Szenarien DR/Referenz-Exadata vor nonprod/prod-exadata Patchen Layer für Layer Risktime rolling upgrade für Storage und Switches Auszeit-Minimierung durch HA bzw. RAC RDBMS wird getrennt betrachtet RDBMS GI DOM-U DOM-0 Switches Storage 11

12 MASSNAHMENKALENDAR/Planung Wartungsfenster 12

13 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

14 Betriebskonzept Appl. Betrieb TSM listener port Resultat: Reduktion der betrieblichen Aufwände Beschleunigung der Bereitstellung Standardisierung/Qualität Telekom-IT T-Systems Market-Unit DB-Betrieb FMO Rollen DBA & SYSDBA OS-Betrieb SAN NAS Storage-Betrieb Backup-Betrieb Netz, RZ-Betrieb Appl. Betrieb TSM DB-Betrieb FMO Rollen DBA & SYSDBA ASM listener port OVM, VLAN, Storage Cell, Backup / ZFS -Pool Exadata Systembetrieb Netz, RZ Telekom-IT T-Systems Market-Unit Betrieb komplett in der Telekom-IT Etablierung ESB-Team (Exadata Systembetrieb), Hardware Betreuung bis Oberkante OS Plattform-Management verwaltet die Ressourcen nur ein Vendor (Oracle) für die komplette Umgebung 14

15 Betriebskonzept Allgemeines: angepasste Schulungen der Betriebsteams durch Oracle Education und Oracle ACS Unterstützungsleistung durch Oracle Presales Oracle ACS-Unterstützung in der Patchplanung und Durchführung Etablierung Platinum-Support aufgrund von Security-Auflagen derzeit nicht möglich ASR im Aufbau zusätzlicher Support externer Dienstleister in Planung 15

16 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

17 Security-Aspekte Datacenter 1 Datacenter 2 komplette physikalische Trennung der Security-Zonen Trennung von Non-Produktion und Produktion - getrennte DB-Server - VLAN-Trennung - Diskgroup-Trennung dedizierte Sprung-Server ins Exadata-Mgmt-LAN Security Zone 1 nonprod/prod Dataguard ZFS-Replikation DWDM Referenz/DR Engineering Security Zone 2 nonprod/prod Dataguard Referenz/DR automatisierte Security-Scans Database Activity Monitoring kein System/Unix-Zugriff aus dem Kunden-LAN nur der Listener-Port ist im Kunden-LAN freigeschaltet ZFS-Replikation 17

18 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

19 Verfügbarkeit Redundanzen, die die Exadata mitbringt - Stromversorgungen - Infiniband-Switche - redundante LAN- und IB-Ports - Storage/ASM - Grid-Infrastructure Redundanzen, die wir zusätzlich nutzen - ZFS-Appliance mit redundanten Heads - redundante Sprung-Server zur Administration - Datenbank Service, der automatisch von einer OVM zu einer anderen OVM (auf anderen DB-Server) schwenkt - Oracle-RAC auf mehreren OVMs, auf mehreren DB-Servern 19

20 Verfügbarkeit durch Disaster Recovery Production STANDBY Security Zone 1 nonprod/prod Datacenter 1 Datacenter 2 Dataguard ZFS-Replikation Referenz/DR Engineering gestaffelte DR-Level - kein DR-Level - Backup Replikation zum Datacenter 2 - Nutzung von Referenz-Systemen im Datacenter 2 (Verdrängung) - Restore als DR-Lösung - Dataguard als DR-Lösung 20

21 Verfügbarkeit, Erfahrungen des letzten Jahres Production STANDBY Security Zone 1 nonprod/prod Datacenter 1 Datacenter 2 Dataguard ZFS-Replikation Referenz/DR Engineering CPU DB-Server defekt Cell-Server Ausfall, komplette GI betroffen Netzteil ZFS-Head defekt DIMM-Modul DB-Server defekt DOM-0 kein Zugriff auf Infiniband GI nicht mehr administrierbar DOM-0 kein Zugriff auf Infiniband ZFS Motherboard defekt Bug im Exa-Patchset DOM-0 kein Zugriff auf Infiniband Positive Aspekte: Die Hardware ist in den letzten Monaten stabil, keine weiteren Hardware-Ausfälle. Die Ursache für die DOM-0/GI-Ausfälle ist (hoffentlich) gefunden (Bug in Firmware der X5-2 IB-HBAs). 21

22 agenda 01 Konsolidierungsplattform Exadata 02 Migrationsmethoden 03 Wartungskonzept 04 Betriebskonzept 05 Security Aspekte 06 Verfügbarkeit

23 Kontakt-Möglichkeiten Gregor Büchner Deutsche Telekom IT GmbH Wolbeckerstr. 268 D Münster Telefon: +49 (0) Internet: 23