Klonen von Exadata Datenbanken mit der Oracle ZFS Appliance Ein Erfahrungsbericht 1
we go the extra mile database intelligence opera1ons excellence lizenzberatung Jan Schreiber, Senior Consultant Loopback.ORG GmbH Oracle-Projekte seit 2003 Data Warehouse und Business Intelligence Projekte Wartungsverträge 2
KUNDE UND ANWENDUNG Deutschlandweiter Kommunikationsdienstleister DWH/BI Landschaft mit mehreren ExaData-Systemen Datenbeladungen von 2 TB pro Tag Tägliche Bereitstellung von Key-Performance-Indikatoren 3
Ausgangssituation (physisch) RMAN 10 Gbit/sec. RMAN 1 Gbit/sec. Produktionsumgebung FC Testumgebung DOAG Konferenz 2014 SAN Storage 4
Ausgangssituation (logisch) Post-Tasks: - Anonymisierung - Maskierung - Security-Refit - Database Links Produktion Produktion - Test 5
Ausgangssituation (logisch) Produktion Produktion Post-Tasks - Anonymisierung - Security-Refit - Database Links - Test - Anonymisierung - Security-Refit - Database Links - Entwicklung lots of times... - Anonymisierung - Security-Refit - Database Links - T/E 6
Nachteile Platzverbrauch (ein n-faches der Originalvolumens) Lange Laufzeiten Hoher Netzwerk-Traffic durch Datenbewegung Lange Anpassungszeiten für Post-Tasks Insgesamt lange Bereitstellungszeiten Test / Entwicklungsumgebungen wurden zu selten aktualisiert 7
Oracle ZFS Appliance Direkt an Exadata-Infiniband angeschlossen Hohe Durchsatzraten bei der Datensicherung ZFS bietet Snapshots und Klone Schnelle Bereitstellung, geringer Platzverbrauch HCC Kompression kann beibehalten werden Native dnfs 8
Oracle ZFS Appliance Application Engineered Storage: Speziell für Datenbank-Storage entworfen 17,3GB/s bei $23/MB/s dtrace-gui Analytics Oracle Database Integration: SMU EM Cloud Control Plugin Thin Provisioning / Deduplication / Compression 9
dtrace Analysis DOAG Konferenz 2014 10
Infiniband-Integration Exa / ZS Exadata Rack 1 Exadata Rack 2 Leaf Switch 1 Leaf Switch 2 Leaf Switch 1 Leaf Switch 2 IB0 IB1 IB2 IB3 IB0 IB1 IB2 IB3 Oracle ZFS Storage Cluster Head 1 Oracle ZFS Storage Cluster Head 2 Active IPMP Link Failover Link 11
Configuring a Single Oracle ZFS Storage Appliance into an InfiniBand Fabric with Multiple Oracle Exadata Machines Two Exadata racks can be cabled together to share the same IB fabric mesh. The merged Exadata racks can then be connected to a single clustered Oracle ZFS Storage Appliance. Successful setup requires adherence to some critical prerequisites and instructions, including physical cabling procedures. Be sure to reference the Oracle Exadata Database Machine Owner's Guide, Part IV: Extension Configuring a Single Oracle ZFS Storage Appliance into an InfiniBand Fabric with Multiple Oracle Exadata Machines of the Oracle Database Machine and Oracle Exadata Storage Expansion Rack http://www.oracle.com/technetwork/server-storage/sun-unified-storage/ documentation/multiple-exadata-zfssa-121013-2080035.pdf 12
IB-Konfiguration Enable LACP Link Aggregation Active/Active-Konfiguration für IPMP nicht empfohlen* Linux ifcfg-ibx: MTU=65520 Connected Mode *siehe MOS Note: 283107.1 13
Durchsatz Infiniband Bus Transferrate 2.0Gb/sec 40Gb/s mit QDR auf Eda-Seite Erwarteter Durchsatz 4GB/s 14
Klon-Erzeugung Filesystem-Klon: offline online mit recovery Zugriff auf Archive Logs notwendig Quell- und Klon-DB liegen in einem Filesystem oder sind per zfs send repliziert RMAN-Klon: Sicherung der Quell-DB mit RMAN AS COPY auf ein (d)nfs-share der ZS RMAN Recovery auf der ZS zfs clone Start auf DB-Host per (d)nfs Mount Data-Guard-Klon: DataGuard statt RMAN Point In Time Klon möglich Verbindung mit Desaster Recovery 15
Ausgewählte Strategie Oracle RMAN Incremental Backup Oracle ASM Database Source- DB Oracle RMAN Incremental Backup MCL@t1 MCL@t2 MCL@t3 MCL@t4 MTD@t1 MTD@t2 MTD@t3 MTD@t4 S1 S2 S4 S3 S5 S6 S7 S8 C1 C2 C3 C4 C6 C5 C7 C8 C9 C10 C11 C13 C12 16 Loopback.ORG
Ausgewählte Strategie Oracle RMAN Incremental Backup Oracle ASM Database Source- DB Oracle RMAN Incremental Backup MCL@t1 MCL@t2 MCL@t3 MCL@t4 Restored DB MTD@t1 MTD@t2 MTD@t3 MTD@t4 S1 S2 S4 S3 S5 S6 S7 S8 C1 C2 C3 C4 C6 C5 C7 C8 C9 C10 C11 C13 C12 17 Loopback.ORG
Ausgewählte Strategie Oracle RMAN Incremental Backup Oracle ASM Database Source- DB Oracle RMAN Incremental Backup MCL@t1 MCL@t2 MCL@t3 MCL@t4 Restored DB MTD@t1 MTD@t2 MTD@t3 MTD@t4 Master Test DB S1 S2 S4 S3 S5 S6 S7 S8 C1 C2 C3 C4 C6 C5 C7 C8 C9 C10 C11 C13 C12 18 Loopback.ORG
Ausgewählte Strategie Oracle RMAN Incremental Backup Oracle ASM Database Source- DB Oracle RMAN Incremental Backup MCL@t1 MCL@t2 MCL@t3 MCL@t4 Restored DB MTD@t1 MTD@t2 MTD@t3 MTD@t4 Master Test DB S1 S2 S4 S3 S5 S6 S7 S8 Snapshots C1 C2 C3 C4 C6 C5 C7 C8 C9 C10 C11 C13 C12 19 Loopback.ORG
Ausgewählte Strategie Oracle RMAN Incremental Backup Oracle ASM Database Source- DB Oracle RMAN Incremental Backup MCL@t1 MCL@t2 MCL@t3 MCL@t4 Restored DB MTD@t1 MTD@t2 MTD@t3 MTD@t4 Master Test DB S1 S2 S4 S3 S5 S6 S7 S8 Snapshots C1 C2 C3 C4 C6 Klone C5 C7 C8 C9 C10 C11 C13 C12 20
Zusammenspiel RMAN und ZA RMAN AS COPY 1,75x längere Laufzeit als AS BACKUPSET Incrementally updated backup ENABLE BLOCK TRACKING BACKUP AS COPY SKIP INACCESSIBLE (ARCHIVELOG ALL) 21
RMAN Konfiguration RMAN Channel SBT_TAPE ohne Komprimierung, wenn Backup Software bereits komprimiert RMAN Compression ist sehr CPU intensiv Höhere Datenraten mit mehreren RMAN-Channels Mount der Backup Shares mit Automounter oder init.d- Skript 22
Datenbank-Kloning und ZA Alle zusammengehörigen Dateien müssen konsistent geklont werden Schreiboperationen müssen auf Redo ausgelagert werden Archive Logs müssen berücksichtigt werden 23
DB-Kloning mit SMU Management der Kloning iscsi und dnfs WebGUI und CLI Oracle 10,11, RAC, Linux, Solaris 24
DB-Kloning mit SMU 25
SMU: Ablauf 1. Klon des Backup Share 2. Mount Klon auf Target Host 3. Start Temp-Instanz aus Backup, mount Controlfile, read parameters (maxscn, FRA-Size) 4. Start Klon-DB mit neuem PFile 5. Recover Control File 6. Database Recovery 7. OPEN RESETLOGS 8. Recompile aller Schema-Objekte 26
Host-Anbindung ZS L2: FC, IB oder (10G) Ethernet TCP/IP über Ethernet und IB ZA Protokolle: ftp, smb, nfs, iscsi iscsi: ZFS datasets (Volumes) als raw devices für ASM Nur eine ASM-Instanz pro Host iscsi Volumes werden im Stück geklont 27
Oracles dnfs NFS-Implementation im Oracle-Prozess Für Datenbank-Zugriffe optimiertes Verhalten Für Datafiles, RMAN, Temp, Redo, Controlfiles Keine serverseitige Komponenten Weniger CPU-Overhead Von Oracle empfohlen für Datenbankfiles auf ZA Storage 300% der knfs-performance in Linux 100% in Solaris ;) 28
k NFS d NFS USER KERNEL MODE I/O Client Oracle Process I/O Client Oracle Process kernel NFS-Client NFS-Service I/O Client Oracle Process File A File B File B I/O Client Oracle Process NFS-Client I/O Client Oracle Process NFS-Client NFS-Service I/O Client Oracle Process NFS-Client File A File B File B USER KERNEL MODE 29 Loopback.ORG
SMU Konfiguriert Snapshots und Klone von Oracle-Datenbanken auf ZFS-Storage Oracle Datenbank 10,11 auf ZA Solaris, Linux, Windows Clients, RAC NAS & SAN Snapshot, Clone, Rollback Online, Offline, Standby Snapshots 30
ZFS-Snapshots ZFS: Allocate on Write Änderungen werden stets auf neue Blöcke geschrieben Nach einem Snapshot werden keine obsoleten Blöcke mehr gelöscht Ein Klon ist ein beschreibbarer Snapshot Schreiben auf einen Klon ist nicht langsamer 31
ZFS-Konfiguration: ARC & ZIL ARC Adaptive Read Cache in RAM oder auf SSD (Readzilla/L2ARC) Buffer Cache des Filesystems ZIL ZFS Intent Log (Writezilla) Redo Log des Filesystems Synchrones Schreiben Asynchrones Schreiben geht ins RAM 32
Schreiben in ZFS Get into a transaction group Update our in-memory buffer Create in-memory log record no Sync? yes Commit transaction Return Commit ZIL record to disk 33
ZFS logbias Latency: mit ZIL Throughput: ohne ZIL Auf SSD schreibt es sich schneller Aber viele Disks haben mehr Bandbreite als wenige SSDs 34
ZIL Konfiguration Gestripte SSDs für ZIL Maximale Performance Doppelfehler führt zu Datenverlust Gespiegelte SSDs für ZIL Maximale Schreibrate im Latency-Mode = Bandbreite eines SSD- Anschlusses 35
ZFS Share Konfiguration für Datenbanken Share Logbias Recordsize Primarycache Compression DATAFILES latency db_blocksize all LZJB Share Logbias Recordsize Primarycache Compression DATAFILES latency db_blocksize all LZJB INDIZES latency db_blocksize all off CONTROLFILES latency 128k all LZJB 36
Pool-Konfiguration Oracle empfiehlt verschiedene Pools für Datafiles und Redo Mirrored Pool für Klon-Shares? RAID-Z für RMAN, Archive Log? HDDs können nur einem Pool zugewiesen werden HDDs können nie mehr aus Pool entfernt werden Ein Pool pro Head Oracle empfielt 4 Schreib-SSDs für Klone und inkrementelle Backups 37
ZA Cluster 2 Heads, n Storage Bays Storage Bays sind untereinander querverbunden HDDs des anderen Heads können importiert werden Heads müssen einzeln konfiguriert werden Readzilla pro Head, verliert nach Schwenk Status Aufwärmphase nach dem Neustart 38
Projekt-Konfiguration ZFS datasets heissen in der ZA Shares Ein ZA Projekt ist ein Template für Shares iscsi Block Devices werden immer synchron geschrieben, daher kein Latency Mode Auf keinen Fall Deduplikation verwenden, da umfangreiche Speicherstrukturen aufgebaut werden müssen (im RAM sollte der Cache sein) Shares müssen in beiden Köpfen angelegt werden User und Group ID in den Share Voreinstellungen anpassen (1001) Eindeutiges Namens-Schema für Shares und Snapshots einhalten! 39
SMU-Konfiguration Archive Logs müssen in von Datafiles getrenntes Share Ab SMU 1.2 können Datenbank-Shares auf beiden Cluster- Köpfen liegen Bei einem RMAN Backup AS COPY auf ein Share darf sonst nichts auf dem Share liegen 40
Manuelle Klon-Konfiguration Löschen der obsoleten Snapshots automatisieren Klon Refresh erfordert einen neuen Snapshot Löschen des Snapshots löscht alle Klone mit 41
Client-Konfiguration Linux Mount Options rw, bg, hard, nointr, rsize=1048576, wsize=1048576, tcp, vers=3,timeo=600 NFS Version 3 vorausgesetzt Solaris rw,bg, hard, nointr, rsize=1048576, wsize=1048576, proto=tcp, vers=3, forcedirectio 42
Linux Native NFS abschalten # chkconfig portmap on # service portmap start # chkconfig nfs on # service nfs start # chkconfig nfslock on # service nfslock start 43
Linux /etc/sysctl.conf hkp://serverfault.com/quespons/327947/set- up- simple- infiniband- block- storage- srp- or- iser net.ipv4.tcp_timestamps=0 net.core.wmem_default=16777216 net.ipv4.tcp_sack=0 net.core.optmem_max=16777216 net.core.netdev_max_backlog=250000 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.core.rmem_default=16777216 net.ipv4.tcp_mem="16777216 16777216 16777216" net.ipv4.tcp_rmem="4096 87380 16777216" net.ipv4.tcp_wmem="4096 65536 16777216" 44
Linux RDMA NFS over RDMA brachte die besten Ergebnisse Offiziell von Oracle nicht unterstützt 45
Klonen des Oracle Homes 1. ORACLE_HOME Master auf der ZA erstellen 2. Klonen auf der ZA 3. Mount des geklonten Shares 4. Konfigurieren des ORACLE_HOME Shares mit dem clone Perl Skript* DOAG *MOS Konferenz Dokument 2014 ID300062.1 46
ZA Performance Konfiguration / Test Durchsatz lesend Durchsatz schreibend Initiale Konfig, RMAN/OS 260 MB/s CTAS, INSERT APPEND Kernel-NFS dnfs Adaptive Direct IO, NOLOG, throughput bias, rs=128k, IPoIB Oracle-Angabe 400 MB/s 1,9 GB/s 1,6 GB/s 27TB/h, 17,3GB/s on ZA 47 100 MB/s NFS over RDMA 3,5 GB/s 400 MB/s pro Pool Bündel-Test, Latency Mode 5,5 GB/s mit beiden Köpfen 1 GB/s ORION Test _adaptive_direct_read=true Mit Patch BUG 19339320 _direct_io_wslots=32, parallel_execution_message_size=6 5536 Schreiben mit vielen parallelen Sessions Mit allen SSDs NFS/IPoIB Durchsatz X4-2 / ZA 1,25GB/s pro Interface 600 MB/s (ein Kopf) 55 MB/s (DOP=10) 115 MB/s 315 MB/s 1,2 GB/s 1,7 GB/s Ziel mit 2x 4G Wirespeed 7 GB/s 4 GB/s (sustained IO)
ZA Performance II 3 Oracle SRs 1 Oracle Bug Development is still working 48
Vielen Dank für Ihre Aufmerksamkeit Jan Schreiber, Hamburg 49