ODA virtualisiert Erfahrungen aus Projekten und Praxis

Transkript

1 ODA virtualisiert Erfahrungen aus Projekten und Praxis Marco Friebe , Dresden

2 Agenda ODA bei Robotron, Kunden und im Projekt ODA Evolution, Plattformen Architektur Deployment Integration in Betriebsumgebungen Fazit Erkenntnisse und Wünsche

3 ODA bei Robotron ODA Projekte seit 2012 erste SAP Implementierung in D 2 eigene DEMO/Projekt - ODA im Haus (V1 und X3-2) Robotron Energiemarkt Produkte als Solution-In-A-Box Robotron EDM Appliance (REA) seit März 2015 ODA X5-2 Projekte umfangreiche Praxiserfahrungen ODA-Piloten

4 ODA bei Robotron Kunden ODA Target: Mittelstand Robotron Kunden: Banken, Betreiber (RZ), Forschungszentren, mittelgroße bis große Städte, Energieversorger, Einsatzgründe für ODA (Auszug): Konsolidierung Oracle Datenbanken (EE) Betreiben dedizierter Applikationen (Full Stack) Optimierte Oracle Lizenzierung (Capacity On Demand) Einsatzgründe für integrierte Systeme (Auszug): kleine IT-Teams, knappe Ressourcen, Fachkräftemangel limitierte IT Budgets für Projekte und Betrieb komplexe, heterogene Umgebungen

5 ODA bei Robotron Kunden verwenden primär Virtualized Paltform () Flexibilität (Lizenzierung, Einsatzzwecke, Ressourcennutzung etc.) nutzen häufig im Vorlauf einen PoCs positive Erfahrungen für Kunden und Robotron fachliche und synthetische Tests Inbetriebnahme, Administration bis Patchmanagement Fachabteilung und IT-Betrieb werden mitgenommen Fakten sind greifbar Laufzeit typischerweise 3-6 Wochen Projektlaufzeiten ODA von Auftrag bis Ready for Migration (1-3 Monate) Projektlaufzeiten ODA von Auftrag bis Projektende (6-9 Monate) Abhängigkeiten zu Applikationen, Kunden, anderen Projekten etc.

6 ODA Projekt Kickoff früher Termin während der ODA Bestellzeit (Vorwärtsplanung) trotz Beratung (und PoC) gibt es noch kundenseitige Aha-Erlebnisse nochmal Verinnerlichung des Appliance Charakters Architektur- und Migrationsplanung ODA Configuration Sheet Vorbereitung Deployment Integration in das Betriebskonzept (Auszug Themen) Backup/(Desaster)Recovery Konzept Monitoring/Administration Sicherheitskonzept (z.b. Härtung OS) Patchmanagement ja, es gibt (manchmal) auch ein Betriebshandbuch

7 Agenda ODA im Projekt ODA Evolution, Plattformen Architektur Deployment Integration in Betriebsumgebungen Fazit Erkenntnisse und Wünsche

8 Oracle Database Appliance X5-2 Hardware Spezifikation: 2 x 1RU x86 Servers 2 x 18-core 2.3 GHz Intel Xeon Processors E v3 256 GB Memory (optional erweiterbar auf 768 GB) Mirrored 600 GB Lokaler Storage Redundanter InfiniBand Interconnect 10GBase-T Public Network Optional 10GbE SFP+ Public Network 1 x 4RU SAS Storage Shelf (+1 Shelf optional) 800 RAW GB SSD für Redologs 1.6 TB RAW SSD Storage für Database Cache oder Tablespaces 64 (128) TB RAW HDD Storage für Daten, Archivelogs, Backups etc.

9 ODA HW Evolution CPU 1) V1 (Sep 2011) X3-2 (Mär 2013) X4-2 (Dez 2013) X5-2 (Feb 2015) 2 x 6-core 3.07 Ghz X5675 (12 Cores) 2 x 8-core 2.9 Ghz E (16 Cores) 2 x 12-core 2.7 Ghz E v2 (24 Cores) 2 x 18-core 2.3 Ghz E v3 (36 Cores) Memory1) 96 GB 256 GB 256 GB 256 (768) GB Network 1) 2 x 1 GbE (onboard) Quad-port GbE NIC (PCIe) Dual-port 10 GbE NIC (PCIe) Redundant private 1 GbE interconnects for cluster communication 4 x 100/1000/10G Base-T Ethernet ports (onboard) Dual-port 10GBase-T as interconnect for cluster communication (PCIe) 4 x 100/1000/10G Base-T Ethernet ports (onboard) Dual-port 10GBase-T as interconnect for cluster communication (PCIe) (copper and fibre) 4 x 100/1000/10G Base-T Ethernet ports (onboard) Dual-port Infiniband interconnect for cluster communication (PCIe) (copper and fibre) Local Storage 1 2 x GB 7200 rpm SATA 2 x GB 10k rpm SAS-2 2 x GB 10k rpm SAS-2 2 x GB 10k rpm SAS-2 Shared Storage 20 x GB 15k rpm SAS HDD (4000 i/o per sec) (12 TB RAW) 20 x GB 10k rpm SAS-2 HDD (3.300 i/o per sec) (18 TB RAW) 20 x GB 10k rpm SAS-2 HDD (3.300 i/o per sec) (18 TB RAW) 16 x TB bzw. 8 TB 7.2k rpm SAS-2 HDD (1500 i/o per sec.) 4 x GB SAS SSD (292 GB 4 x GB SAS-2 SLC SSD 4 x GB SAS-2 SLC SSD (64 bzw. 128 TB RAW) RAW) (800 GB RAW) (800 GB RAW) 4 x GB SAS-2 SLC SSD 1 x 4 GB USB Memory Optional storage expansion Optional storage expansion (800 GB RAW) doubles storage capacity doubles storage capacity 4 x GB SAS-2 SLC SSD ( i/o per sec.) (1.6 TB RAW) Optional storage expansion 1) per Knoten doubles storage capacity

10 ODA SW Evolution v2.1 (Sep 2011) Markteinführung v2.2 v2.4 (2012) Third Party Software Support (Backup, Monitoring etc.) Multiple DB Home Support External Storage Support (NFS und ZFS Filer) Double Mirroring Support v2.4 (Nov. 2012) SAP Support v2.5 (Feb 2013) Virtualized Platform () v2.6 (Mai 2013) WLS Deployment Package v2.8 (Nov 2013) OVM Shared Repository, VLAN Support v (Sep 2014) Support für GI/DB 12.1 DB und VM Snapshots VDISK Support ACFS Standard für DB-Files v (Feb 2015) Support für X5-2 (Infiniband, Exafusion, Cluster Flash Cache etc.) v (Mrz 2016) Oracle Linux 6.7 Rolling Infra Upgrade

11 ODA Betriebsplattformen Bare Metal (ODABM) Konsolidierung von Datenbanken Pay as you Grow (nicht shrink!) Lizenzierung über MOS Lizenzschlüssel geringste Komplexität Virtualized Platform () auf Basis einer spezifischen Oracle VM Integration: Konsolidierung für Applikationen Partitionierung unterschiedlicher Applikationsworkloads Capacity-On-Demand Lizenzierung für Oracle Produkte (DB, WLS, BI ) Applikationsbetrieb unter anderen Betriebssystemen (Windows, Solaris, )

12 Agenda ODA im Projekt ODA Evolution, Plattformen Architektur Deployment Integration in Betriebsumgebungen Fazit Erkenntnisse und Wünsche

13 ODA Virtualized Platform (ODVP) Domänenkonzept erlaubt Trennung der Workloads ODA Base besitzt privilegierten Zugriff (PCI-Passthrough) auf Shared Storage VLAN, VDISK Support und oakcli VM Management Hochverfügbare DomU durch Systemfailover oder Live- Migration VM-Snapshoting über ACFS Funktionalität

14 Agenda ODA im Projekt ODA Evolution, Plattformen Architektur Deployment Integration in Betriebsumgebungen Fazit Erkenntnisse und Wünsche

15 ODA Virtualized Plattform Deployment Parameter Parameter Wertebereich Wert System-Name Name oda-prod Region Europe Europe Zeitzone Europe/Berlin Europe/Berlin ODA_BASE Cores Backup Bereich lokal/extern extern Diskgruppen Redundanz zweifach/dreifach zweifach DNS-Domain Name robotron.de DNS-Server IP oder Hostnamen NTP-Server IP oder Hostnamen ASR Proxy-Server oder ASR Manager IP oder Hostname proxy.robotron.de ASR Proxy-Server Port oder ASR Manager Port Port 80 Oracle MyOracleSupport Account Login Account Cloud FS (ACFS) Mountpoint und Size /MyACFS, 100 GB Shared VM Repository Name, Size und DG ShRepo, 200 GB, +DATA

16 ODA Virtualized Plattform Deployment Parameter Ebene Knoten 0 Knoten 1 Beide Hostname IP-Adresse Hostname IP-Adresse Subnetmask Gateway ILOM odaprodilom odaprodilom Hypervisor (DOM0) odaproddom odaproddom ODA-BASE odaprodbase odaprodbase RAC-VIP odaprodvip odaprodvip SCAN odaprodscan , Backup/DG/DMZ User VM 1 odaprodvm

17 ODA Virtualized Plattform Deployment Bare Metal Virtualized Platform Funktion OS ISO Image Linux 6.x Oracle VM 3.2.x Reimaging ODA VM Template n/a Extra Download Deployment End User Bundle Extra Download In VM Template enthalten Deployment ODA Patch Bundle Extra Download Extra Download Upgrade über ILOM Webfronend oakcli deploy oda_base oakcli deploy [-conf onecommand.param]

18 ODA Virtualized Plattform Deployment User-VM Erstellung von VM-Templates von laufender OVM Umgebung, Oracle Template Builder, Oracle Virtual Assembly Builder, OVM Templates von Oracle edelivery Cloud von OS-ISO Image (Doc ID ) von Vmware/Hyper-V (Doc ID ) Rollout auf ODA Whitpaper: Oracle Database Appliance: Automated Virtual Machine Provisioning

19 Agenda ODA im Projekt ODA Evolution, Plattformen Architektur Deployment Integration in Betriebsumgebungen Fazit Erkenntnisse und Wünsche

20 ODA Virtualized Plattform Backup/Recovery

21 ODA Virtualized Plattform Backup/Recovery Backup-Ebene Backup-Type Backup-Modus Hypervisor/DOM0 Redeployment n/a ODA_BASE VM Images Direkt per NFS/CIFS/iSCSI/SCP auf Backup-Server Offline ODA_BASE Inhalte direkt per Backup-Agent direkt per NFS/CIFS/iSCSI/SCP auf Backup-Server USER VM Images per ACFS Snapshot (Stufe 1) per Backup-Agent (Stufe 2) per NFS/CIFS/iSCSI/SCP auf Backup-Server (Stufe 2) direkt per Backup-Agent direkt per NFS/CIFS/iSCSI/SCP auf Backup-Server Online Offline (Stufe 1) Offline Datenbanken direkt per Backup-Agent Online per NFS/CIFS/iSCSI /SCP auf Backup-Server (Stufe 1) per Backup-Agent (Stufe 2) in Fast Recovery Area (Stufe 1) per Backup-Agent (Stufe 2) Online Online Doc ID

22 ODA Virtualized Plattform Desaster Recovery Produktion (X4-2) ACFS-Replikation 3 rd Party-Replikation/Sync (z.b. rsync) (Active) Data Guard Desaster Recovery (X4-2 + Expansion) QS Test RZ 1 RZ 2 Nutzung von ACFS DB-Snaphots Methoden: Nutzung der jetzt kostenfreien ACFS Replikation Einsatz von rsync innerhalb der User VM Erstellen von Snaphots und Transport zu Standbyseite Doc ID

23 ODA Virtualized Plattform Monitoring/Administration Monitoring Administration EM Cloud Control R4/R5 HW, VM, OS, Gridinfra, DB OS, GI, DB OAK (oakcli) HW HW, VM, OS, Gridinfra, DB ILOM SNMP HW n/a ILOM Alerting HW n/a ASR HW n/a Third Party Monitoring HW über oakcli, snmp Empfehlung Monitoring Einbindung oakcli und/oder SNMP für Service Desk (Operating) Cloud Control für DBA/DMA

24 ODA Virtualized Plattform Patchmanagement Upgrade Infra Patching ILOM, Bios, Firmware, Treiber, Oracle VM, Linux, (oakcli update -patch infra) ca. 2 Stunden Upgrade Gridinfra Patching Clusterware, ASM (oakcli update -patch gi) ca. 1,5 Stunden Upgrade DB Optional: Patching DB-Homes, Datenbanken (oakcli update -patch database) DB (Home) spez. Quartalsweise Bundle Patch für ODA Infra und Gridinfra zusammen und max. 1 Patch Bundle zurück DB gemäß Applikations- bzw. Unternehmensfreigabe versionsabhängiger Bundlepatch Readme folgen OneOff Patches nach Rücksprache mit dem Oracle Support Patchmanagement User VM, OS, Appl. und ThirdParty separat

25 Agenda ODA im Projekt ODA Evolution, Plattformen Architektur Deployment Integration in Betriebsumgebungen Fazit Erkenntnisse und Wünsche

26 Fazit & Lessons Learned Wir sind überzeugt vom ODA-Konzept ermöglicht höhere Flexibilität bei überschaubarer Komplexität das Konzept muss für den Kunden/Nutzer passen evtl. PoC Kunde/Nutzer sollte: sich im Vorlauf intensiv informieren/beraten lassen Erwartungshaltung zeitig im Projekt mit den Rahmenbedingungen von integierten Systemen (Standardisierung versus Flexibilität) befassen die Standards leben Änderungen (Hacks) vermeiden oder in separate Projekt-Meilensteine auslagern Gute Planung ist die halbe Miete: man würde sagen wie immer noch wichtiger mit integrierten Systemen kleine Planungsfehler können umfangreiche Auswirkungen haben Technische Apekte (Auszug): MAC-Adressen pro Port im Switch sollten disabled or eine hohe Nummer haben ( braucht einige) Härtung (STIG+, PCI DSS etc.) könnte spanned warden ;-) versionsbezogene Known Issues in Doc ID vor Deployment/Upgrade lesen

27 Erweiterungswünsche Performante Lösung zur Nutzung der DB SE2 (optimal ohne EE licensing) separate ODA_BASEs für DB versions, Editionen, DB Options Clustering of ODAs via Infiniband High Performance ODA, wählbar SSD, schneller HDD oder Kapazität erweitertes Backup/Recovery-Concept für integriertes Disaster Recovery für VM (z.b. unter Verwendung von ACFS Replikation etc.) Partitioning der ODA for mittlere und kleine Kunden ala Half-ODA or oder flexiblere Konfigurationen (Exadata like) mehr Flexibilität bei Plattenaufteilung im ASM/ACFS (wie Exadata)

28 Marco Friebe Leiter Oracle Services & Support Telefon: Fragen?