exadata with vm as consolidation plattform

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

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

Who Am I


Daniele Massimi, Trivadis AG (CH, Bern)

Principal Consultant [email protected]

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

mailto:[email protected]

Mein Unternehmen.


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

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.


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.


Projektbeschreibungen

Projektanforderungen


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

Wahl der Lösung


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…


Exadata OVM Eigenschaften

Was ist Oracle VM: Komponenten


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 1Browser interface

Commandline OVM Manager

OVM

Agent

OVM

Agent

OVMM OVS

OracleVM

«Bare Metal» zu «virtualized» Exadata


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

OVM Restriktionen auf der Exadata


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

Erstellung von VM auf der Exadata (1)


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

Erstellung von VM auf der Exadata (2)


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]]

VM Management auf der Exadata


"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 OSModified kernel (paravirt.)

Unmodified

user

programs

DomU

Front-End Device DriversBack-End Device Drivers

Dom0

Linux XEN-Kernel

XEN

control

software

Event Channel Virtual MMUVirtual CPU Control

Interface

Safe H/W

interface XEN Virtual Machine Monitor (Hypervisor)

XEN commandos in der Exadata


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

Wie viele VMs sollten erstellt werden ?


Grundsätzlich sollten so wenig VM’s

wie möglich erstellt werden

X5-2: max. 63 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


Exadata OVM

„advanced Networking“

Projektanforderung


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

XEN / OVM Netzwerk – Überblick


Computer - XEN

Bridge: xenbr0Bridge

dom0 (Host)

Computer

domU-X

(VM)N

e

t

w

o

r

k

eth1

eth2

bondeth0

eth0

vmbondeth0

vifX.0

Netzwerk – von «physical to bridge»


/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

Netzwerk – VLAN Tagging


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

Netzwerk Konfiguration: VLAN Tagging auf Exadata VM


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

VM mit VLAN Tagging erweitern (1)


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']

VM mit VLAN Tagging erweitern (2)


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 solcheAnforderungen 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

Infiniband Partitioning


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

Infiniband Problematik im «Projekt»


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

Infiniband Problematik – Lösung


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


Exadata OVM Disklayout

Exadata OVM und ASM Storage


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 !

Exadata OVM – Projektspezifisches Disk Layout


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)

Exadata OVM – Disk Layout Reorg


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;


Exadata OVM mit Trusted Partitions

Trusted-Partition – Lizenz Optimierung


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)


Backup der Dom0 und DomU

Backup der Dom0 (auch für DomU anwendbar)


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 !

Backup of DomU


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


„Normale“ Betriebsaspekte

Betriebaspekte


Betriebsaspekte wie:

• Grid Infrastructure

• Datenbanken

• Backup von Datenbanken

• Maintenance von Datenbanken

• Migrationen

• Patching

• uvm.

Werden wie auf einer normalen Oracle Datenbank Plattform

vorgenommen !

Fazit


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.)

Fragen und Antworten…

Daniele Massimi

Principal Consultant

Tel. +41 58 459 50 92

[email protected]

14.04.2016 Exadata OVM als Konsolidierungsplattform41

exadata with vm as consolidation plattform

Technology