Beiträge

SMU 1.3.0

Das Oracle Snap Management Utility (SMU) für die Administration von Snapshots und Klonen auf der ZFS Storage Appliance ist in der Version 1.3 erschienen. Damit können nun auch 12c Container-Datenbanken verwendet werden.

Neben der Unterstützung von Snap Cloning für Multitenant Databases bringt die neue Version weitere Features mit:

  • Clone Copy (Binärkopie der Quelldatenbank)
  • Standby Clone (Einrichtung von Data Guard aus einem Klon)
  • Incomplete Recovery (Point in Time Recovery einer Datenbank auf einen Zeitpunkt oder eine SCN zwischen zwei Snapshot Backups)
  • Refresh Clone (Ein Klon muss für einen Refresh nicht mehr neu angelegt werden)

Die Release Notes finden sich hier.

/von

Probleme mit dem Snapshop Management Utility

,

In einem Kundenprojekt werden Test- und Entwicklungs-Datenbanken vorbereitet, indem ein Backup der Produktion auf einem ZFS Appliance Cluster geklont wird. Auf diese Weise können schnell und ohne überflüssigen Platzverbrauch neue Datenbanken erzeugt werden.

Das Klonen eines ZFS Shares (datasets) selbst erfordert keine spezielle Vorbereitung und ist mit einem Klick in der Appliance GUI beziehungsweise einem CLI-Befehl erledigt. Soll allerdings eine ganze Datenbank geklont werden, ist etwas mehr Umsicht erforderlich, denn die Klone aller ZFS Shares, auf denen Datafiles der Datenbank liegen, müssen zusammenhängend ausgeführt werden, und es muss sichergestellt werden, das kein Share, auf dem Dateien der Datenbank liegen, vergessen wird. Außerdem müssen bei Online Backups die Archive Redo Files separat geklont werden. Und beim De-kommissionieren einer Datenbank muss geprüft werden, welche Klone aufgelöst werden können.

Um all dies zu berücksichtigen, ohne sich die Finger wund zu skripten, hat Oracle das Snapshop Management Utility (SMU) entwickelt. In der GUI lassen sich alle Datenbanken, die verwaltet werden sollen, sowie alle Storage Server, die verwendet werden, eintragen, und dann lässt sich jede Datenbank wahlweise online oder offline mit einem Befehl per Snapshot sichern und auch klonen. Es steht sowohl eine Web GUI als auch ein Command Line Interface (CLI) zur Verfügung.

Ein feine Sache, die viel eigenen Entwicklungsaufwand sparen kann, und ein Produkt mit Oracle Support. Unser Kunde plant, das SMU in das eigene Skript-Framework inkl. der lokalen Vor- und Nachbereitungen bei der Erstellung von Testumgebungen einzubauen und per CLI aufzurufen.

In der letzten SMU-Version 1.1 liefen die Tests vielversprechend, aber eine Sache fehlte noch: SMU konnte nur Datenbanken verwalten, deren Datafiles auf einem einzigen Kopf eines ZFS-Appliance-Clusters liegen. Hat man eine ZFS Cluster, wird man seine größeren Datenbanken aber selten nur auf einem Kopf belassen. Stattdessen wird man in der Regel versuchen, die Datafiles auf beide Köpfe zu verteilen, um die Bandbreite beider Köpfe zu nutzen und so die Gesamtperformance zu erhöhen.

Daher war die Freude groß, als es im README zur Version 1.2 hieß:

„Important: Previously, all of the database shares had to reside with one head of a clustered Oracle ZFS Storage system. With the Snap Management Utility 1.2 release, this is no longer a requirement. Shares can span both heads of a clustered appliance.“

Leider ist es aber nicht möglich, diese Funktionalität auch zu nutzen. Auch nur der Versuch, mit dem SMU 1.2 ein Offline-Backup einer Datenbank, deren Datendateien sich über beide Köpfe eines Clusters erstrecken, auszuführen, führt zum Fehler:

„The number of remote shares is greater than the number of shares to backup.“

Für dieses Problem haben wir im Dezember 2014 einen Oracle Service Request eröffnet, der mittlerweile zu einem Bug (20469398) geführt hat. Das bisherige Fazit ist aber leider: SMU ist für größere Installationen, die an Performance interessiert sind, nicht zu verwenden.

/von

Performance Probleme mit der Oracle ZFS Appliance

, , , , ,

Für das Data Warehouse eines unserer Projektkunden, eines großen Telekommunikationsversorgers, hat dieser eine Oracle ZFS Appliance angeschafft und per Infiniband direkt mit seinen Exadata-Produktionssystemen verbunden, um ein schnelles Datensicherungs-Medium zu gewinnen, mit dem auch unkompliziert neue Test- und Entwicklungs-Umgebungen erzeugt werden können.

Die ZFS Storage Appliance (ZA) kann, wie jedes moderne Storage-System, Snapshots erzeugen, ohne nennenswert Zeit mit dem Kopieren der Daten zu verbringen. Diese können als Klone auch zum Schreiben geöffnet werden und so als Grundlage für neue Datenbanken dienen. Waren die Entwicklungsdatenbanken bisher stark veraltet, da das Erstellen aus der Produktion viel Zeit und Speicherplatz brauchte, können diese nun spontan geklont und auch einmal auf Zuruf in den Ausgangsstand zurückgesetzt werden. Die dafür notwendigen Schritte auf der ZA werden durch ein Oracle Tool namens Snapshot Management Utility (SMU) erleichtert, der den kompletten Prozess des Klonens inklusive dem notwendigen Recovery der Datenbanken dirigiert. Die Datenbanken werden dann mittels RMAN BACKUP AS COPY als inkrementelles Backup auf den NFS-Share der ZA  gesichert, wo sie als Datafiles vorliegen und nach einem Recovery geöffnet werden können.

Zunächst wurden auf der ZFS Appliance die entsprechenden Projekte und Shares angelegt. Wir haben einen ZA Cluster verwendet, der aus zwei Köpfen besteht, die jeweils alle Platten sehen, aber nur die ihnen zugewiesenen verwenden. In jedem Kopf sind Solid State Disks (SSDs) als Schreib-Cache (ZIL) verbaut. Fällt ein Kopf aus, kann der jeweils andere seine Platten übernehmen. Dieser Vorgang dauert übrigens tatsächlich einige Zeit, hinzu kommt, dass die Caches, wie nach jedem Neustart eines Kopfes, neu gefüllt werden müssen.

Aus Performance-Gründen haben wir nur einen ZFS Pool pro Kopf eingerichtet und ihn als Mirror (und nicht als RAIDZ) konfiguriert. Laut den Vorgaben aus dem entsprechenden Oracle Whitepaper für den Datenbank-Betrieb auf der ZA wurden dann die Shares für Datafiles, Redo und Archivelog entsprechend mit den passenden Einstellungen für Logbias, Recordsize, Kompression und Primarycache konfiguriert:

Share

Logbias

Recordsize

Primarycache

Compression
DATAFILES

latency (oder throughput)

db_blocksize

all

LZJB
INDIZES

latency

db_blocksize

all

off
CONTROLFILES

latency

128k

all

LZJB

Von der in ZFS prinzipiell unterstützen Deduplikation ist übrigens für diesen Einsatzzweck stark abzuraten, da die erforderlichen Ordnungstabellen sehr viel Platz im RAM benötigen und dort mit dem Cache kollidieren.

Die SSDs für das ZIL wurden gestriped eingerichtet. Ein Fehler auf einer SSD kann nun zusammen mit einem Stromausfall und dem daraus folgenden Verlust des Hauptspeicher-Inhaltes zu Datenverlust führen, aber wählt man hier die Konfiguration als Mirror, wird im Latency-Modus die maximale Schreibrate durch den Cache durch die Bandbreite einer SSD begrenzt – zu langsam für uns.

Auf der Exadata als Quellsystem und einer X4-2 Maschine, die als Datenbankserver für die Klon-Datenbankenvorgesehen ist, werden nun die Linux-Interfaces für Infiniband eingerichtet:

Enable LACP Link Aggregation
ifcfg-ibx MTU: 65520
Connected Mode

Dann werden die ZA-Shares per dNFS eingehängt. dNFS wickelt die wesentlichen Übertragungsprozesse direkt in den Oracle-Prozessen ab und führt für den Database Writer sowie für RMAN zu erheblichen Geschwindigkeitsvorteilen. Wir haben die folgenden Linux NFS- und Mount-Options verwendet:

rw, bg, hard, nointr, rsize=1048576, wsize=1048576, tcp, vers=3,timeo=600

Die Einstellungen in /etc/sysctl.conf waren:

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=0
net.core.netdev_max_backlog=250000
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216
net.core.optmem_max=16777216
net.ipv4.tcp_mem="16777216 16777216 16777216"
net.ipv4.tcp_rmem="4096 87380 16777216"
net.ipv4.tcp_wmem="4096 65536 16777216"

dNFS in Kombination mit Remote Direct Memory Access (RDMA) erbrachte die besten Ergebnisse. Allerdings ist RDMA nicht in allen Konfigurationen von Oracle mit dNFS unterstützt.

Insgesamt blieben die Lese- und vor allem Schreibraten, die wir von den Linux-Servern gegen die ZA bekamen, weit hinter den Erwartungen zurück.

Mit dd, CTAS aus der Datenbank oder anderen Testwerkzeuge haben wir folgende Durchsätze gemessen:

Konfiguration / Test

Durchsatz lesend

Durchsatz schreibend
Initiale Konfig, RMAN/OS

 

260 MB/s
CTAS, INSERT APPEND 

 

100 MB/s
Kernel-NFS

400 MB/s

 
dNFS

1,9 GB/s

 
Adaptive Direct IO, NOLOG, throughput bias, rs=128k, IPoIB

1,6 GB/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

 

600 MB/s (ein Kopf)
_adaptive_direct_read=TRUE

 

55 MB/s (DOP=10)
Mit Patch für Bug 19339320

 

115 MB/s
_direct_io_wslots=32, parallel_execution_message_size=65536

 

315 MB/s
Schreiben mit vielen parallelen Sessions

 

1,2 GB/s
Mit allen SSDs

 

1,7 GB/s
NFS/IPoIB Durchsatz X4-2 / ZA

1,25GB/s pro Interface

 
Ziel mit 2x 4G Wirespeed

7 GB/s

4 GB/s (sustained IO)
Oracle-Angabe

(27TB/h), 17,3GB/s on ZA

 

Viele der genannten Tests beruhen auf Vorschlägen durch den Oracle Support. Wegen dieser Performance sind seit einigen Monaten zwei Oracle-SRs und ist mittlerweile ein Bug offen. In den Griff bekommen haben wir die Probleme bisher trotz Überprüfung von allen denkbaren Komponenten bis hinunter zur Verkabelung und Einsatzes mehrere Oracle-Engineers vor Ort nicht. Eventuell ist hier ein Bug in den Mellanox-Treibern oder im Linux Kernel verantwortlich?

/3 Kommentare/von