Das Dokument beschreibt die Implementierung einer Oracle Exadata OVM (Oracle VM) Konsolidierungsplattform zur Ablösung einer bestehenden AIX-Umgebung, mit Fokus auf Lizenzoptimierung und isolierte virtuelle Maschinen. Zudem werden verschiedene technische Eigenschaften und Empfehlungen für die Systemarchitektur und Netzwerkverwaltung detailliert erläutert. Trivadis, das Unternehmen des Autors, bietet umfassende IT-Dienstleistungen und hat viel Erfahrung in der Implementierung ähnlicher Projekte.

1. BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENF
HAMBURG KOPENHAGEN LAUSANNE MÜNCHEN STUTTGART WIEN ZÜRICH
Exadata OVM als
Konsolidierungsplattform
Daniele Massimi – Principal Consultant
Projektbericht

2. Agenda
Exadata OVM als Konsolidierungsplattform2 14.04.2016
Projektbeschreibung
Exadata OVM Eigenschaften
Exadata OVM „advanced Networking“
Exadata OVM Disklayout
Trusted Partitions
Backup der Dom0 und DomU
«normale» Betriebsaspekte

3. Who Am I
Exadata OVM als Konsolidierungsplattform3 14.04.2016
Daniele Massimi, Trivadis AG (CH, Bern)
Principal Consultant daniele.massimi@trivadis.com
Seit 2012 bei Trivadis IMS (Infrastructure Service Management),
Oracle DBA seit >15 Jahre (Exadata <5 Jahre)
Infrastruktur-Architekturen, Operations & Administration, Upgrades and
Migration, High Availability, Backup & Recovery, Enterprise Manager,
Engineered Systems (Exadata, ODA)
Oracle Certifications
– Oracle Certified Professional
– Oracle Certified RAC Expert
– Oracle Exadata Implementations Specialist

4. Mein Unternehmen.
Exadata OVM als Konsolidierungsplattform4 14.04.2016
Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem Solution
Engineering und der Erbringung von IT-Services mit Fokussierung auf -
und -Technologien in der Schweiz, Deutschland, Österreich und
Dänemark. Trivadis erbringt ihre Leistungen aus den strategischen Geschäftsfeldern:
Trivadis Services übernimmt den korrespondierenden Betrieb Ihrer IT Systeme.
B E T R I E B

5. KOPENHAGEN
MÜNCHEN
LAUSANNE
BERN
ZÜRICH
BRUGG
GENF
HAMBURG
DÜSSELDORF
FRANKFURT
STUTTGART
FREIBURG
BASEL
WIEN
Mit über 600 IT- und Fachexperten bei Ihnen vor Ort.
Exadata OVM als Konsolidierungsplattform5 14.04.2016
14 Trivadis Niederlassungen mit
über 600 Mitarbeitenden.
Über 200 Service Level Agreements.
Mehr als 4'000 Trainingsteilnehmer.
Forschungs- und Entwicklungsbudget:
CHF 5.0 Mio. / € 4.5 Mio.
Finanziell unabhängig und
nachhaltig profitabel.
Erfahrung aus mehr als 1'900 Projekten
pro Jahr bei über 800 Kunden.

6. Exadata OVM als Konsolidierungsplattform6 14.04.2016
Projektbeschreibungen

7. Projektanforderungen
Exadata OVM als Konsolidierungsplattform7 14.04.2016
Realisierung einer Oracle Konsolidierungs-Plattform
Ablösung der bestehende AIX Umgebung
Lizenz Optimierung
Bedienung von zwei Netzwerke (Intranet und DMZ)
Möglichkeit für DBaaS

8. Wahl der Lösung
Exadata OVM als Konsolidierungsplattform8 14.04.2016
Lösung des Kunden  Exadata OVM
Exadata OVM kann als Konsolidierungs-Plattform eingesetzt werden
Exadata OVM bietet Isolierung mittels VMs
Exadata OVM bietet Lizenz-Optimierung mit «Trusted Partition»
Exadata OVM hat die gleiche Funktionalität wie mit «Bare Metal»
Exadata kann erweitert werden (z.B. mit Elastic Configuration)
aber…

9. Exadata OVM als Konsolidierungsplattform9 14.04.2016
Exadata OVM Eigenschaften

10. Was ist Oracle VM: Komponenten
Exadata OVM als Konsolidierungsplattform10 14.04.2016
Besteht normalerweise aus zwei Haupt-Komponenten
• Trifft jedoch für die Engineered Systems (ODA, Exadata) nicht zu
1..n Oracle VM Server (OVS)
• Hosts für die Virtual Machines
1 Oracle VM Manager (OVMM)
• Management Infrastructure für OVS (Repository-DB, Web-frontend, CLI)
Oracle Enterprise Linux
Java Based Management Server
Repository DB
OVM Server N
OVM Server 1
Browser interface
Commandline OVM Manager
OVM
Agent
OVM
Agent
OVMM OVS
OracleVM

11. «Bare Metal» zu «virtualized» Exadata
Exadata OVM als Konsolidierungsplattform11 14.04.2016
Nach dem Bare Metal Setup muss die Installation zur «virtualized»
Konfiguration konvertiert werden
Filesystem für Repository wird erstellt
OVM Dom0
root@tvd01dbadm01 oracle.SupportTools]# ./switch_to_ovm.sh
2015-04-10 00:59:33 +0200 [INFO] Switch to DOM0 system partition /dev/VGExaDb/LVDbSys3
(/dev/mapper/VGExaDb-LVDbSys3)
2015-04-10 00:59:33 +0200 [INFO] Active system device: /dev/mapper/VGExaDb-LVDbSys1
2015-04-10 00:59:33 +0200 [INFO] Active system device in boot area: /dev/mapper/VGExaDb-LVDbSys1
2015-04-10 00:59:33 +0200 [INFO] Set active systen device to /dev/VGExaDb/LVDbSys3 in
/boot/I_am_hd_boot
2015-04-10 00:59:33 +0200 [INFO] Reboot has been initiated to switch to the DOM0 system partition
[root@tvd01dbadm01 oracle.SupportTools]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbSys3
30G 20G 8.6G 70% /
tmpfs 7.0G 4.0K 7.0G 1% /dev/shm
none 3.5G 40K 3.5G 1% /var/lib/xenstored
/dev/sda3 721G 8.6G 713G 2% /EXAVMIMAGES
/dev/sda1 496M 65M 406M 14% /boot
[root@tvd01dbadm01 oracle.SupportTools]# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 8192 4 r----- 283.9

12. OVM Restriktionen auf der Exadata
Exadata OVM als Konsolidierungsplattform12 14.04.2016
OEDA «einziges» Tool für die Generierung der VM Konfiguration
VNC Console nicht vorhanden  nur via «xm console» möglich
OVM Manager nicht verfügbar (nur Native Commands möglich)
Keine OVM Cluster möglich (HA via RAC, RAC One Node oder Data
Guard)
Kein «Shared Repositories» für die VMs
Keine Live Migration
Memory balloning (keine online Memory re-Konfiguration möglich)
Empfehlung VM auf Exadata
• Memory of min. 8Gb für jede VMs
• CPU min. 2 vCPU

13. Erstellung von VM auf der Exadata (1)
Exadata OVM als Konsolidierungsplattform13 14.04.2016
Generierung der Konfiguration indem ein neuer Cluster hinzugefügt wird
Mittels oneCommand Deployment-Steps vom DB-Server 1 ausführen
./install.sh -cf <ExadataConfig_dir>/exa02adm01vm01.trivadis.com-vm.xml –r 1-17

14. Erstellung von VM auf der Exadata (2)
Exadata OVM als Konsolidierungsplattform14 14.04.2016
Einer der oneCommand Steps erstellt die VM
[root@exa01dbadm01 linux-x64]# ./install.sh -cf ../Exa01/TVD-exa01.xml -s 3
Executing Create Virtual Machine
Creating guests for cluster exa01-cluster.........................
Checking status of remote files........
Checking status of existing files on remote
nodes................................................
Getting status of local files........................................................
Creating guest using /opt/oracle.SupportTools/linux-x64/WorkDir/exa01adm01vm01.ttc.trivadis.com-
vm.xml on node exa01dbadm01.ttc.trivadis.com
Creating guest using /opt/oracle.SupportTools/linux-x64/WorkDir/exa01adm02vm01.ttc.trivadis.com-
vm.xml on node exa01dbadm02.ttc.trivadis.com............................................
.
.
Successfully logged into machine exa01adm02vm01
Successfully logged into machine exa01adm01vm01
Guests created, waiting for them to be up....
Creating databasemachine.xml for EM discovery
Done Creating databasemachine.xml for EM discovery.
Successfully completed execution of step Create Virtual Machine [elapsed Time [Elapsed = 1006520
mS [16.0 minutes] Thu Apr 16 19:27:19 CEST 2015]]

15. VM Management auf der Exadata
Exadata OVM als Konsolidierungsplattform15 14.04.2016
"xm" ist das Tool um für das Management der VMs auf der Exadata
Nur XEN native commands sind verfügbar !
• VMs auflisten
– xm list; oder xm list -l
• Starten der DomU
– xm create /path-to-vm.cfg/vm.cfg
• Shutdown der DomU
– xm shutdown <name_of_vm | number>
• Power-off der DomU
– xm destroy <name_of_vm | number>
Hardware (CPU, Memory, Disk, Network, ...)
Native Device Drivers
Host OS
Unmodified
user
programs
Guest OS
Modifiedkernel (paravirt.)
Unmodified
user
programs
DomU
Front-End Device DriversBack-End Device Drivers
Dom0
Linux XEN-Kernel
XEN
control
software
Event Channel Virtual MMUVirtual CPUControl
Interface
Safe H/W
interface XEN Virtual Machine Monitor (Hypervisor)

16. XEN commandos in der Exadata
Exadata OVM als Konsolidierungsplattform16 14.04.2016
Nicht alle nativen XEN commandos werden auf der Exadata supported
– Folgende commandos funktionieren auf der Exadata nicht:
• mem-set
• mem-max
• migrate
• save
• restore
• suspend
• resume
• sched-*
• cpupool-*
Memory Ballooning
Nützlich für Resouce Management

17. Wie viele VMs sollten erstellt werden ?
Exadata OVM als Konsolidierungsplattform17 14.04.2016
Grundsätzlich sollten so wenig VM’s
wie möglich erstellt werden
X5-2: max. 63 VMs möglich
X4-2: max. 63 VMs möglich
X3-2: max. 16 VMs möglich
SR-IOV= Single Root I/O Virtualization
Virtualisierung des PCI Adapters
(z.B. der Infiniband HCA)
Management und Ressourcen Overhead
vermeiden
P101-VM01
P201-VM02
I101-VM03
I201-VM04
DBS01
P102-VM01
P202-VM02
I102-VM03
I202-VM04
DBS02
Exadata Rack Data Center 1

18. Exadata OVM als Konsolidierungsplattform18 14.04.2016
Exadata OVM
„advanced Networking“

19. Projektanforderung
Exadata OVM als Konsolidierungsplattform19 14.04.2016
Kunde betreibt zwei von einander getrennte Netzwerke (Intranet und DMZ)
Netzwerke sind nur teilweise 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

20. XEN / OVM Netzwerk – Überblick
Exadata OVM als Konsolidierungsplattform20 14.04.2016
Computer - XEN
Bridge: xenbr0Bridge
dom0 (Host)
Computer
domU-X
(VM)N
e
t
w
o
r
k
eth1
eth2
bondeth0
eth0
vmbondeth0
vifX.0

21. Netzwerk – von «physical to bridge»
Exadata OVM als Konsolidierungsplattform21 14.04.2016
/etc/sysconfig/network-scripts/ifcfg-vmbondeth0
Eine Bridge ist eine Art von «Virtual Switch»
DEVICE=vmbondeth0
TYPE=Bridge
IPADDR=10.10.10.142
NETMASK=255.255.254.0
BOOTPROTO=static
ONBOOT=yes
DELAY=0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
BRIDGE=vmbondeth0
NM_CONTROLLED=no
BONDING_OPTS="..."
Bridge: xenbr0
bond0
vmbondeth0
vifX.0
Bridge
# ifconfig vmbondeth0
10.10.10.0 Link encap:Ethernet HWaddr B4:99:BA:BB:BE:54
inet addr:10.10.10.142 Bcast:10.10.10.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

22. Netzwerk – VLAN Tagging
Exadata OVM als Konsolidierungsplattform22 14.04.2016
ifcfg-bondeth0.1000
ifcfg-vmbondeth0.1000
Bridge: xenbr0
bondeth0.1000
vmbondeth0.1000
vifX.0
Bridge
Bridge: xenbr0
bondeth0.2000
vmbondeth0.2000
vifX.0
Bridge
bondeth0
DEVICE=bondeth0.1000
HWADDR=B4:99:BA:BB:BE:5
6
BOOTPROTO=none
ONBOOT=yes
VLAN=yes
BRIDGE=vmbondeth0.1000
NM_CONTROLLED=no
DEVICE=vmbondeth0.1000
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes
DELAY=0
ifconfig vmbondeth0.1000
vmbondeth0.1000 Link encap:Ethernet HWaddr B4:99:BA:BB:BE:56
inet addr:192.168.100.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

23. Netzwerk Konfiguration: VLAN Tagging auf Exadata VM
Exadata OVM als Konsolidierungsplattform23 14.04.2016
vconfig package muss installiert sein resp. werden
Tag auf den VLAN Interface erstellen
Check mit brctl
# rpm -qa | grep vconfig
vconfig-1.9-3
./VTagXBrConfig.sh create -v 1000 -l 1000 -i bondeth0
# brctl show
bridge name bridge id STP enabled interfaces
vmbondeth0 8000.90e2ba813434 no bondeth0
………………………………
vmbondeth0.1000 8000.90e2ba813434 no bondeth0.1000
………………………………..
vmeth0 8000.0010e062c00e no eth0

24. VM mit VLAN Tagging erweitern (1)
Exadata OVM als Konsolidierungsplattform24 14.04.2016
Editieren des vm.cfg File auf jeder VM
Erstellen einer neuen ramdom MAC Adresse
Folgende Modifikationen anbringen (vm.cfg)
# cd /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfg
# cp vm.cfg vm.cfg.before_vlantag
# echo -n "00:16:3e"; dd bs=1 count=3 if=/dev/random 2>/dev/null | hexdump -v -e
'/1 ":%02x"'
00:16:3e:e6:28:88
vif = ['type=netfront,mac=00:16:3e:e6:94:28,bridge=vmeth0']
to
vif =
'type=netfront,mac=00:16:3e:e6:28:88,bridge=vmbondeth0.1000','type=netfront,mac=00
:16:3e:e6:94:28,bridge=vmeth0']

25. VM mit VLAN Tagging erweitern (2)
Exadata OVM als Konsolidierungsplattform25 14.04.2016
Eintrag im /etc/udev/rules.d/70-persistent-net.rules File jeder DomU erstellen,
um das Naming des Interface zu garantieren
Konfigurien der IP-Adresse für das neu hinzugefügte Interface
Gleiche Prozedur gilt auch für das Admin Interface, falls solche
Anforderungen bestehend sind
OEDA 12.1.2.3.0 (Patch 22694905 vom 19.02.2016) unterstützt “ein” VLAN Tag
MOS Note 2018550.1 (VLAN Tag Exa OVM - Public Network)
MOS Note 2090345.1 (VLAN Tag Exa OVM Admin Network, seit 22.01.2016)
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:16:3e:e6:28:88",
KERNEL=="eth*", NAME="bondeth0"
# /opt/oracle.cellos/ipconf.pl –nocodes

26. Infiniband Partitioning
Exadata OVM als Konsolidierungsplattform26 14.04.2016
IB Partitionen haben die gleiche Funktion wie VLAN Tagging
Partitionen definieren welche Nodes untereinander kommunizieren können
Partition keys (pkey) – werden dabei als “Tag” verwendet
• Pkey “0x7fff” (dezimal 32767) gilt als default Partition key
Ein Nodes kann mehrere “Partitions” ansprechen

27. Infiniband Problematik im «Projekt»
Exadata OVM als Konsolidierungsplattform27 14.04.2016
Projektanforderung = zwei getrennte Netze sollen betrieben werden
Via IB Interface kann man sich auf DomU des anderen Ntzwerk verbinden !
Infiniband Netz “muss” daher partitioniert werden !
OEDA unterstützt IB Partitioning für “ein” Partition key
Quelle: Oracle

28. Infiniband Problematik – Lösung
Exadata OVM als Konsolidierungsplattform28 14.04.2016
Interconnect Verbindung wird mit Infiniband Partitioning versehen
IB Partitioning für Storage Server bleibt “geshared”
Zusätzliche IB IP-Adressen werden benötigt (Private IP-Range)
Konfiguration auf IB-Switch, VM und DB-Servers notwendig
Quelle: Oracle

29. Exadata OVM als Konsolidierungsplattform29 14.04.2016
Exadata OVM Disklayout

30. Exadata OVM und ASM Storage
Exadata OVM als Konsolidierungsplattform30 14.04.2016
Database Storage auf der Exadata OVM befindet sich in den Storage
Cells
Storage Partitionen (Celldisks, Griddisks) sind gleich wie bei Bare Metal
• Zwei Diskgroups für jede VM werde erstellt (DATACn and RECOCn)
• Griddisk Grössen werden aus der OEDA Konfiguration abgeleitet
• Storage wird via I/O Virtualization  SR-IOV
 Auch bekannt als PCI Passthrough, keinen Hypervisor Interaktion =
keinen Overhead !

31. Exadata OVM – Projektspezifisches Disk Layout
Exadata OVM als Konsolidierungsplattform31 14.04.2016
Der Disk Layout wird implizit aus der OEDA Konfiguration abgeleitet
Problem  unflexibles Disk Layout !
Lösung  Erstellung von Griddisk Einheitsgrössen um:
• Flexible Erweiterung von bestehende Diskgruppen sicherzustellen
• Vermeidung von Leer-Kapazitäten
 (z.B. durch sub-optimale Aufteilung kann nicht den vollen phys.
Diskplatz benutzt werden
• Optimale Diskplatz-Ausnutzung von Storage Server
 frühzeitige Beschaffung von zusätzlichen Storage Server vermeiden
Griddisks werden demnach mittels folgender Formel partitioniert:
• (Grösse ASM-Diskgruppe : n Storage Cells) : 12 (Anzahl phys. Disks)

32. Exadata OVM – Disk Layout Reorg
Exadata OVM als Konsolidierungsplattform32 14.04.2016
Reorganisation der Griddisks kann online durchgeführt werden
Vorgehen  Reorg der Griddisks  Reorg der ASM Diskgruppe
Resizen der Griddisks  auf allen Storage Cells ausführen !
Resizen der Diskgruppen
Wenn Griddisks zwischen den Diskgruppen verschoben werden sollen,
müssen diese zuerst aus der ASM DG gedroppt werden
Danach müssen die alten Griddisk gelöscht und neue erstellt werden, dies
aufgrund der Names-Konvention der VMs
CellCLI> alter griddisk RECOC1_CD_00_tvd01celadm01,RECOC1_CD_01_tvd.. size=200G
SQL> alter diskgroup RECOC1 resize all;
CellCLI> drop griddisk RECOC1_CD_00_tvd01celadm01;
CellCLI> create griddisk all prefix=RECOC4 size=200G;

33. Exadata OVM als Konsolidierungsplattform33 14.04.2016
Exadata OVM mit Trusted Partitions

34. Trusted-Partition – Lizenz Optimierung
Exadata OVM als Konsolidierungsplattform34 14.04.2016
Erlaubt die Lizenzierung der Oracle Produkte von einem subset der
verwendeten Prozessoren in ihrer Exadata
Mit Trusted Partition müssen auf der Exadata mindestens 40% der
Prozessoren lizenziert werden
Hyper-Threading muss eingeschaltet werden
Zwei vCPU werden als einem physical Core gezählt
Enterprise Manager ist zwingend einzusetzen (Nachvollziehbarkeit)

35. Exadata OVM als Konsolidierungsplattform35 14.04.2016
Backup der Dom0 und DomU

36. Backup der Dom0 (auch für DomU anwendbar)
Exadata OVM als Konsolidierungsplattform36 14.04.2016
Dom0 (root FS) liegt auf LVM Volumes
Zwei Backup Möglichkeiten sind möglich
• Normales Filesystem Backup
 Backup Client ist nötig
 Möglichkeit einzelne Files vom Backup Server zu restoren ist
gegeben
• LVM Snapshots
 Mount-bar auf jedes LVM basiertes System möglich
 Möglichkeit einzelne Files zu restoren durch mounten des Snapshot
Auch für DomU anwendbar !

37. Backup of DomU
Exadata OVM als Konsolidierungsplattform37 14.04.2016
Auch für das Backup der DomU sind zwei Backup Methoden möglich
• Normal Filesystem Backup (Backup Client notwendig)
• OCFS2 Reflink basierte Snapshots (von der Dom0 ausgeführt)
 Pausieren der DomU
 Erstellen von Reflinks (Snapshots) für jedes Files
 Unpausieren der DomU
 Backup der Snapshots erstellen
 Reflinks löschen
# xm pause <name_of_vm | number>
# reflink orig_file snap_file
# xm unpause <name_of_vm | number>
# rm –rf snap_file

38. Exadata OVM als Konsolidierungsplattform38 14.04.2016
„Normale“ Betriebsaspekte

39. Betriebaspekte
Exadata OVM als Konsolidierungsplattform39 14.04.2016
Betriebsaspekte wie:
• Grid Infrastructure
• Datenbanken
• Backup von Datenbanken
• Maintenance von Datenbanken
• Migrationen
• Patching
• uvm.
 Werden wie auf einer normalen Oracle Datenbank Plattform
vorgenommen !

40. Fazit
Exadata OVM als Konsolidierungsplattform40 14.04.2016
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
Nahezu gleiche Performance wie mit Bare Metal
Mehrere Technologien = mehr Know-How wird benötigt
Komplexität steigt exponentiell (Management, Networking, Backup, etc.)

41. Fragen und Antworten…
Daniele Massimi
Principal Consultant
Tel. +41 58 459 50 92
daniele.massimi@trivadis.com
14.04.2016 Exadata OVM als Konsolidierungsplattform41