here my presentation about virtualized Exadata, where i held last november 2019 at DOAG Conference ...english version will be available soon

1. Virtualized Exadata
…die ersten 4 «produktiven» Jahren
Daniele Massimi
Principal Consultant
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 1

2. Who Am I
Daniele Massimi, appliedtec gmbh (CH, Bern)
Consultant daniele.massimi@appliedtec.ch
 Oracle DBA seit ~20 Jahre (Exadata > 7 Jahre)
 Infrastruktur-Architekturen und Implementationen (Cloud und On-Premise), Backup &
Recovery, Upgrades and Migration , High Availability, Virtualisierung, Automation, Exadata
Implementationen
 Engineered Systems (Exadata, ODA, ZDLRA)
 Oracle Certifications
 Oracle Certified Master (11g und 12c)
 Oracle Certified Professional (8i – 12c)
 Oracle Certified Expert (RAC)
 Oracle Implementation Specialist (Exadata, OVM)
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 2

3. Agenda
 Projektbeschreibung
 Ziel Plattform
 System Herausforderungen
 Storage Herausforderungen
 Netzwerk Herausforderungen
 Datenbank Herausforderungen
 Patching und Upgrades Herausforderungen
 Deployments / Provisioning / Automation
 Capacity Management
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 3

4. Projektvorgaben
 Realisierung einer Konsolidierungs-Plattform für Oracle Datenbanken
 Ablösung der bestehende AIX Umgebung
 Lizenz Optimierung
 Bedienung von zwei Netz-Zonen (Intranet und DMZ)
 Isolation von Produktion zu Vor-Produktion Umgebungen
 Dedizierte Kunden-Umgebungen
 DBaaS (optional)
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 4

5. Definierte Zielplattform
 Lösung des Kunden → virtualized Exadata
 Wieso ? → Eigenschaften
 Virtualized Exadata kann als Konsolidierungs-Plattform eingesetzt werden
 Virtualized Exadata bietet Isolierung mittels VMs
 Virtualized Exadata bietet Lizenz-Optimierung mit «Trusted Partition»
 Virtualized Exadata hat die gleiche Funktionalität wie mit «Bare Metal»
 Exadata kann erweitert werden (z.B. mit Elastic Configuration)
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 5

6. Plattform und Ausbaustufen
 Initial Konfiguration → 2 X5 Quarter Rack
 Erweiterung der Cell Disks von 4Tb auf 8Tb
 Erweiterung von X6 Compute Nodes
 Je 2 Nodes per Exadata Rack
 Erweiterung von X7 Compute Nodes
 2 Nodes an einem Standort
 Erweiterung von 2 X7 Storage Server
 Ersatz von 5 X8 Storage Server
 Ausbau lokale Disks von 4 auf 8 600Gb
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 6

7. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 7
 Filesysteme haben begrenzte Kapazität
 Logfile Management nicht mehr trivial
 Applikatorische Ablagen (z.B. Staging Area für Data Load oder Extracts)
 → Lösung: NFS Shares
 Anzahl der NFS Mounts kann nicht vernachlässigt werden
 Interne Security Anforderungen benötigen zusätzliche Software
 spezifische RPMs sind notwendig
 non Standard RPMs verursachen Zusatzaufwand beim Patching
 → Lösung: Inventory führen der RPMs (Linux 6 auf Linux 7 Problematik !)

8. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 8
 Erhöhung der Lokalen virtual Disks (/ (root), /u01)
 lokale Disks in den physikalischen Server sind endlich
 → Sparsam damit umgehen !
 Grid Home bei Upgrades
 Neue oder zusätliche Oracle Homes
 Ausbau lokale Disks
 Von 4 auf 8 600Gb → 1.6Tb auf 3.8 Tb vergrösserung des /EXAVMIMAGES
 Achtung !!! → Disks werden automatisch ins RAID aufgenommen
 Synchronisation startet automatisch → resync dauert ca. 18h 
 VMs haben in der Zwischenzeit Performance Engpass !!! → I/O Waits !

9. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 9
 Erhöhung der vCPUs
 Supportetes Feature der Virtualized Exadata
 Default Setting maxvcpus auf das Maximum
 Ziel → dynamische Allozierung bei Bedarf
 Problematisch wenn sämtliche CPU Core eines Sockets belegt sind
 Steal time is the percentage of time a virtual CPU waits for a real CPU while
the hypervisor is servicing another virtual processor. (Quelle: IBM)
 → Somit nur bedingt “dynamisch”
 Wenn vCPU de-provisioniert wird, werden sämtliche vCPU dealloziert →VM hat zu
wenig Ressource und ein reboot wird i.d.R erfolgen
 → Service wird unterbrochen
top - 18:34:15 up 10 days, 3:36, 1 user, load average: 1.38, 1.46, 1.46
Tasks: 484 total, 4 running, 480 sleeping, 0 stopped, 0 zombie
Cpu0 : 1.0%us, 1.4%sy, 0.0%ni, 97.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.7%us, 0.7%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu2 : 0.7%us, 2.7%sy, 0.0%ni, 96.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu3 : 1.7%us, 1.4%sy, 0.3%ni, 96.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Mem: 123304248k total, 20590912k used, 102713336k free, 616668k buffers
Swap: 16777212k total, 0k used, 16777212k free, 6786116k cached

10. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 10
 Erweiterung von 2 Database Server
 Re-Imaging
 switch_to_ovm.sh ausführen
 Neue VMs via OEDA deployen
 Problem mit Einbindung in OEM, da dazumal “Elastic Configuration” noch
nicht vorhanden
 → databasemachine.xml musste manuell “angepasst” werden

11. Storage Cells Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 11
 Erhöhung der Diskkapazität von 4Tb auf 8Tb (rolling)
 Storage Cells offline setzen
 Disk Austausch
 Re-Imaging der Storage Cells
 Neu erstellen der Celldisks und Griddisks
 Rebalancing der ASM Diskgruppen starten
 Erweiterung um 2 X7 Storage Cells
 Erstellen der Celldisks und Griddisks
 cellip.ora ergänzen
 Rebalancing der ASM Diskgruppen starten

12. Storage Cells Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 12
 Ersatz bestehenden Cells mit 5 X8 Storage Cells (online)
 Erstellen der Celldisks und Griddisks
 cellip.ora ergänzen
 Addieren der neuen Disks und löschen alten Disks
 Rebalancing abwarten
 → durch adäquate Rebalance Power keine Performanceeinbusse
 Kein IORM im Einsatz
 regelmässige Überprüfunden finden statt
 IORM Konfiguration für Flashcache in Zukunft vorstellbar

13. Storage Cells Herausforderung
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 13
 Grundsätzlich keine Probleme und sehr stabil
 Nach Erweiterung neue X7 Storage Cells → Performance Probleme
 DBs mit hohen «log file sync wait»
 Analyse ergibt hohe Antwortzeiten auf Flash Log
 Auslöser MOS 1500257.1
 Obschon Flash Logs unabhängig von Writeback FlashCacheMode ist
resp. immer das schnellere Schreiben zwischen Flash und Disk
für das I/O Acknowledge gilt → Performance Probleme !
 → Lösung: Restart der CELLSRV Services der betroffenen Cells

14. Netzwerk - Projektanforderungen
 Kunde betreibt zwei von einander getrennte Netz-Zonen (Intranet und DMZ)
 Netzwerke sind nicht geroutet
• Mandantenfähigkeit
• Security Anforderungen
 Problematik der Exadata DB-Server
• begrenzte Anzahl von Netzwerk Interface Ports
 Lösung → VLAN Tagging
Ethernet Ports
Public Network
Optical Ports
Public Network
Mgmt Ports
Infiniband Ports
Ethernet Ports
Admin Network
Ethernet Ports
Backup/DG Network
X5 Server
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 14

15. Netzwerk Herausforderung
 VLAN Tagging
 Netzwerk Switches müssen mit Port Trunking konfiguriert
werden
 VLANs und Bridges müssen auf den physikalischen Knoten
erstellt werden
 VLANs müssen den VMs bekannt gemacht werden (vm.cfg)
 VM Interfaces müssen konfiguriert werden (udev Rules)
 → jedes zusätzliches VLAN an VM bedingt ein reboot 
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 15

16. Datenbank Architekturen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 16
 Alle DBs mit Multitenant Option (12.1.0.2)
 Folgende Standards wurden festgelegt:
 Single DB
 RAC One Node DB
 RAC One Node DB mit Data Guard

17. Datenbank Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 17
 Einführung Multitenancy →Konsolidierungs-Anforderungen erfüllen
 Character Set Problematik (12.1.0.2)
 Verfügbarkeitsklassen Problematik
 DB-Architektur Problematik (z.B. Data Guard)
 Daten Schutzklassen Problematik
 → Hohe Fragmentierung = reduzierte Konsolidierungs-Dichte !
 CDB Dichte → Abhängig von RTO und RPO
 Produktion CDBs = max. 15 PDBs, DGs Konfigurationen = 1 PDB
 Andere CDBs = max. 50 PDBs

18. Datenbank Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 18
 Probleme mit der Persistenz der «PDB modifiable» Parameter !!!
 Startup Trigger musste implementiert werden um Verlässlichkeit herbei zu führen
 Definierter Standard: zusätzliche Oracle Homes wenn spezielle One-Off
Patches installiert werden müssen
 Sobald One-Off im BP enthalten ist, wird dieser wieder entfernt (lokale Disks
Problematik !)
 VLAN spezifische Oracle Net Zugriffe auf PDB Ebene
 Konfiguration via listener_networks Parameter
 PDBs werden von restlichen VLANs isoliert
 Komplexe Konfiguration !!! → neue Lösung mittels SDN sind in Arbeit !

19. Datenbank Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 19
 Ressource Management
 Over-Provisioning Problematik
 gerechte Ressourcen Nutzung
 Aktuell kein DBRM im Einsatz (12.1.0.2)
 Neue Datenbanken → ab Q1/2020 19c
 Datenbank Services wurden kategorisiert (S, M, L)
 CPU_COUNT auf PDB Ebene
 Overprovisioning Ansatz
 SGA_TARGET auf PDB Ebene

20. Patching und Upgrade Pfade
 Initial Exadata Image Konfiguration → 12.1.2.1.3
 Patching 12.1.2.1.3 → 12.1.3.x → 12.2.1.1.x → 19.2.5.0.0 (aktuelle eingesetzte
Version)
 Initial Infiniband Version → 2.1.x
 Verschiedene Patches bis auf 2.2.13 (aktuell eingesetzte Version)
 Initial Grid Infrastructure Version → 12.1.0.2
 Upgrades 12.1.0.2 → 12.2.0.1 → 19.3.0.0.0 (aktuell eingesetzte Version)
 Datenbanken Versionen
 11.2.0.4, 12.1.0.2, 12.2.0.1, 19.3.0.0.0
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 20

21. Patching und Upgrade Herausforderungen
 Haupt-Problematik → Wartungsfenster !
 Initial Konzept sah kein «online Patching» vor (Keine 7x24h Applikationen)
 ASM Storage nur mit «normal Redundancy» → Online Patching nicht empfohlen !
 Stark Konsolidierte Plattformen bedingen auch hohen Koordinationsaufwand beim
Patching
 Wo möglich wurden «online» Verfahren angewendet (IB, OS, GI, RDBMS)
 → zukünftige Ausrichtung: online Patching !
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 21

22. Patching und Upgrade Herausforderungen
 Virtualized Exdata → Upgrade Grid Infrastructure und RDBMS ab 18c nur mit
OEDACLI supported
 MOS → 18c: 2369422.1, 19c: 2542082.1
 OEDACLI übernimmt folgende Tasks:
 Discovery der aktuellen Virtualized Exadata Umgebung ☺
 Hinzufügen von Virtual Disks → Dom0 und DomU (für GI und RDBMS)
 Provisionieren (Copy, Installation, Relink, etc.) von GI und RDBMS Software
 Upgrade und Downgrade von Grid Infrastructure Stack (inkl. cluvfy Checks)
 → nach 5 OEDACLI Updates, funktionierte das Cluster Upgrade nicht !
 → In Abstimmung mit Oracle ACS, wurde 12.2er Upgrade Methode angewendet
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 22

23. Deployments / Provisioning / Automation
 Exadata VMs Deployment
 gemäss Oracle Best Practices → via OEDA resp. install.sh
 Oracle Databases
 Erstellung automatisiert via scripts (inkl. OEM, CMDB, Backup)
 Ansible Automation → in Arbeit !
 Grid Infrastructure und RDBMS Patching Optimization
 PoC mit Fleet Patching & Provisioning Utility und Ansible initiert
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 23

24. Capacity Management
 Capacity Management wird via OEM überwacht
 vCPU, Memory und Storage (Cells und ASM)
 Memory Huge Page Allokation für DB ca. 50-60% → je nach Anzahl der DBs auf der VMs
 CPU Erhöhung Problematik → bereits erwähnt
 Storage Erhöhung online bei Bedarf (griddisk → ASM)
 Gilt auch für Reduzierung
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 24

25. Know How
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 25
 Von Single Server DBA zu Exadata DBA !
 System Administrator
 Netzwerk Administrator
 Storage Administrator
 Cluster Administrator
 RAC Administrator
 Multitenant Option
 Die Bandbreite der Technologien und der möglichen Probleme erhöhen sich
exponentiell !!!
 → Definition und Implementation von Standards unumgänglich !

26. Fazit
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 26
 Gute Implementation für Isolation von Umgebungen
 Mit Trusted Partition hat man ein Instrument für Lizenz Optimierung
 Management Tools für das VM Management «noch» nicht vorhanden
 Mehrere Technologien = mehr Know-How wird benötigt
 Komplexität steigt exponentiell (Management, Networking, Patching,
etc.)
 Aufbau Knowledge über die verschiedene Technologien zwingend
notwendig !!!

27. Fragen ???
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 27