Jan Ulrich Maue

Oracle Cloning leicht gemacht mit Nimble

Blog Post created by Jan Ulrich Maue on Nov 30, 2016

Vor einiger Zeit hatte ich erfahren, dass es mit dem neuesten Nimble Linux Toolkit (NLT) eine Oracle-Integration geben wird. Mitte November war es dann endlich soweit: NLT2.0 geht GA! Neben dem bekannten Nimble Connection Manager NCM enthält das Toolkit jetzt auch ein Nimble Docker Volume Plugin und den besagten Nimble Oracle Application Data Manager. Letzteren möchte ich an dieser Stelle näher vorstellen. Er ermöglicht es den Datenbankadministratoren, auf einfache Art storagebasierte Snapshots einer Oracle Datenbank zu erstellen. Die auf diese Weise erzeugten Snapshots können dann geklont und auf demselben Server oder auch auf einem zweiten "Remote-"Server gemountet werden. Die geklonte Datenbank wird anschließend automatisch recovered und göffnet. All das ist möglich mit jeweils nur einem Kommando und ohne tiefe Kenntnisse des Nimble Arrays.

 

Als Voraussetzungen gibt es zu erfüllen:

  • NimbleOS 3.5 or higher
  • Oracle 11.2.x.x (11gR2) - Single Instance using ASM, no RAC Support
  • RHEL 6.5 and above
  • RHEL 7.1 and above
  • Oracle Linux 6.5 and above
  • CentOS 6.5 and above
  • Note: Oracle Linux and CentOS are supported but not QA verified in this release

 

Auf meinem Laptop habe ich VMware Fusion mit zwei Nimble virtuellen Arrays sowie zwei CentOS 7.2 VMs laufen. Damit sollte es also funktionieren! Die Nimble Arrays laufen noch mit NimbleOS3.3 - der Upgrade auf 3.5.4 funktioniert aber reibungslos (allerdings wichtig zu beachten, dass man den Softwareupgrade mit der force-Option über das CLI und nicht über die GUI machen soll. Der Befehl lautet also: software --update --force).

 

1. Schritt: Installation und Konfiguration

Bei der Installation des Nimble Linux Toolkits kann ich auswählen, welche Komponenten ich haben möchte. Ich entscheide mich für den NCM und den Oracle Application Manager - etwas sperrig auch NORADATAMGR genannt. Das Docker Plugin lasse ich zunächst außen vor. Oracle installiere ich in der 12c-Version, da 11g auf CentOS 7 nicht mehr läuft. Auf dem ersten Nimble Array lege ich sechs Volumes an: jeweils ein OCR (Oracle Cluster Registry) Volume für die beiden CentOS-VMs und vier Volumes für eine "DATA" Diskgruppe im ASM. Auf dieser soll später die Datenbank laufen. Für die vier ASM-Volumes erzeuge ich eine Volume Collection "oracle" und gebe als Replikationspartner das zweite virtuelle Array an. Dies ist für später wichtig, da der NORADATAMGR einen Snapshot auch replizieren kann.

Volumes1.png

 

Damit die Oracle-User auf den Linux-Servern den Nimble Oracle App Manager auch später nutzen können, müssen nach der Installation die Rechte angepasst werden. Dies ist im Nimble Linux Integration Guide sehr gut beschrieben:

NORA-rights.png

Um den Oracle App Manager verwenden zu können, muss der Oracle Service des NLT zunächst "enabled" und dann gestartet werden:


[root@ora-prod oracle]# nltadm --enable oracle

Successfully enabled oracle plugin

[root@ora-prod oracle]# nltadm --start oracle

Done


Danach den Status prüfen:


[root@ora-prod oracle]# nltadm --status

Service Name               Service Status

------------------------------+--------------

Connection-Manager         RUNNING 
Oracle-App-Data-Manager    RUNNING 

 

Anschließend muss er nur noch bei der Nimble-Gruppe angemeldet werden, und mit --verify wird überprüft, ob alles läuft. Als IP-Adresse verwendet man die Management-IP des Nimble Group Leaders.


[root@ora-prod oracle]# nltadm --group --add --ip-address 192.168.43.100 --username admin --password xxxx

Successfully added Nimble Group information for 192.168.43.100.

[root@ora-prod oracle]# nltadm --group --verify --ip-address 192.168.43.100

Successfully verified management connection to Nimble Group 192.168.43.100.


Als letzter Schritt der Vorbereitung muss dem Oracle App Manager noch mitgeteilt werden, von welchem Server aus die Snapshot- und Cloning-Prozesse für eine bestimmte Oracle-Instanz angestoßen werden dürfen. Snapshots können dabei nur von dem lokalen Server, auf dem die Instanz läuft, erzeugt werden. Das Cloning kann von dem lokalen und auch von einem zweiten Server (auch "Remote-Server" genannt) angestoßen werden. Von daher trage ich beide CentOS-VMs ein - die Konfiguration geschieht als Oracle-User mit dem Kommando noradatamgr und den Optionen --edit und --allow-hosts:


[oracle@ora-prod oracle]# noradatamgr --edit --instance ORCL --allow-hosts ora-prod,ora-clone

Allowed hosts set to: ora-prod,ora-clone

Success: Storage properties for database instance ORCL updated.


Falls zu diesem Zeitpunkt noch keine Volume Collection für die ASM-Disks auf dem Nimble-Array existieren sollte, würde sie jetzt automatisch erzeugt werden. Das Volume-Mapping und auch die erlaubten Hosts kann ich mir mit der --describe Option anzeigen lassen:


[oracle@ora-prod oracle]# noradatamgr --instance ORCL --describe

Diskgroup: DATA

    Disk: /dev/oracleasm/disks/NIMBLEASM1

        Device: dm-3

        Volume: ora-asm1

        Serial number: a48de9fac373d3286c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/NIMBLEASM4

        Device: dm-4

        Volume: ora-asm4

        Serial number: e3c26f0c9aa46f266c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/NIMBLEASM3

        Device: dm-1

        Volume: ora-asm3

        Serial number: 12e67015f9980a0f6c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/NIMBLEASM2

        Device: dm-0

        Volume: ora-asm2

        Serial number: 75e25e2d1b9086886c9ce900a5a40084

        Size: 20GB

 

Allowed hosts: ora-prod,ora-clone


Das war es schon! Der Nimble Oracle App Manager benötigt kein Repository o.ä. Alle Daten, die für den Oracle Cloning Prozess notwendig sind (wie Oracle pfile und Redologs) werden als Metadaten direkt im Snapshot auf dem Nimble-Array mit abgespeichert. Auf diese Weise kann ein Snapshot sogar von einem zweiten Linux-System (auch "Remote"-System genannt) gemountet werden, und die Datenbank wird automatisch recovered und gestartet. Dies möchte ich in den folgenden Abschnitten beschreiben.


2. Schritt: Erzeugen von Snapshots

Der Nimble Oracle App Manager kann für Oracle Instanzen auf dem Server, auf dem er installiert ist, zwei Arten von Snapshots erzeugen: 1. crash-konsistente und 2. applikationskonsistente Snapshots. Im ersten Fall wird bei laufender Datenbank ein IO-konsistenter Snapshot für alle Nimble-Volumes, auf denen die Oracle Datenbank liegt, erzeugt. Die Datenbank ist daher in einem Zustand, als wäre der Server ungeplant ausgefallen. Beim späteren Öffnen muss Oracle somit eine Crash-Recovery durchführen. Im zweiten Fall wird die Datenbank zunächst in den "Hot Backup"-Modus versetzt, der Snapshot wird erzeugt, und anschließend wird die Datenbank wieder aus dem "Hot Backup"-Modus genommen. Beim späteren Öffnen ist somit nur eine normale Media-Recovery notwendig.


Wie bereits beschrieben ist dafür jeweils nur ein Kommando notwendig. Mit der Option --hot-backup bestimme ich, ob die Datenbank in den Hot-Backup-Modus versetzt werden soll. Mit --replicate kann ich zusätzlich angeben, ob der Snapshots mithilfe der Nimble Replikation auf ein zweites Array kopiert werden soll. Voraussetzung dafür ist, dass - wie weiter oben beschrieben - für die Volume Collection ein Replikationspartner konfiguriert ist.


[oracle@ora-prod oracle]# noradatamgr --snapshot --snapname snap1-hotbackup --instance ORCL --hot-backup --replicate

Putting instance ORCL in hot backup mode...

Success: Snapshot backup snap1-hotbackup completed.

Taking instance ORCL out of hot backup mode...


[oracle@ora-prod oracle]# noradatamgr --snapshot --snapname snap1-crash --instance ORCL

Success: Snapshot backup snap1-crash completed.


Mit --list-snapshots und zusätzlich mit --verbose lasse ich mir eine ausführliche Beschreibung der Snapshots für die entsprechende Instanz anzeigen:


[oracle@ora-prod oracle]# noradatamgr --list-snapshots --instance ORCL --verbose

Snapshot Name: snap1-crash taken at 16-11-28 12:07:39

    Instance: ORCL

    Snapshot can be used for cloning ORCL: Yes

    Hot backup mode enabled: No

    Replication status: N/A

    Database version: 12.1.0.2.0

    Host OS Distribution: CentOS

    Host OS Version: 7.2

Snapshot Name: snap1-hotbackup taken at 16-11-28 12:05:17

    Instance: ORCL

    Snapshot can be used for cloning ORCL: Yes

    Hot backup mode enabled: Yes

    Replication status: complete

    Database version: 12.1.0.2.0

    Host OS Distribution: CentOS

    Host OS Version: 7.2

 

Dieser Befehl kann auch auf dem zweiten "Remote-"Server, auf dem die produktive Instanz nicht läuft, ausgeführt werden:

[oracle@ora-clone oracle]# noradatamgr --list-snapshots --instance ORCL

-----------------------------------+--------------+--------+-------------------

Snap Name                      Taken at        Instance     Usable for cloning

-----------------------------------+--------------+--------+-------------------

snap1-crash                    16-11-28 12:07  ORCL         Yes               

snap1-hotbackup                16-11-28 12:05  ORCL         Yes               


3. Schritt: Erzeugen und Mounten von Clones und Starten der Datenbank

Nachdem wir zwei Snapshots erzeugt haben, möchten wir sie eventuell für ein Test- und Entwicklungssystem nutzen. Dies ist total simpel, da der komplette Prozess vom Erzeugen der Clones auf Basis der Snapshots, über das Mapping an den Server und Rescan der Devices bis hin zu den Datenbank-Aktivitäten (Mounten, Recovery und Öffnen der Datenbank) vollkommen automatisiert ist und mit nur einem Kommando gestartet wird! Als Output erhalte ich gleichzeitig noch ein "Describe" der geklonten Datenbank. Optional könnte ich beim Datenbankstart sogar noch einzelne Oracle Parameter im PFILE ändern oder eine andere Oracle SID vergeben. Darauf möchte ich an dieser Stelle allerdings nicht eingehen.


[oracle@ora-prod oracle]# noradatamgr --clone --instance ORCL --clone-name clonedDB --snapname snap1-crash

Cloning diskgroups ... completed.

Mounting diskgroups ... completed.

Building instance clonedDB ... completed.

Diskgroup: CLONEDDBDATADG

    Disk: /dev/oracleasm/disks/CLONEDDB0001

        Device: dm-9

        Volume: clonedDB-DATA1

        Serial number: 2030631af2be85fc6c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/CLONEDDB0002

        Device: dm-3

        Volume: clonedDB-DATA4

        Serial number: 7e03a8ce03e7c9296c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/CLONEDDB

        Device: dm-5

        Volume: clonedDB-DATA3

        Serial number: 4fee6d9baef2f29a6c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/CLONEDDB0003

        Device: dm-8

        Volume: clonedDB-DATA2

        Serial number: f1c42b1793cab81a6c9ce900a5a40084

        Size: 20GB

 

Allowed hosts: ora-prod


Man kann die --snapname Option auch weglassen. Der Oracle App Manager erzeugt dann zunächst einen Snapshot und nimmt diesen als Basis für die Clones. Allerdings geht das nur auf dem produktiven Datenbank-Server; auf dem Remote-Server ist es nicht möglich, da von hier aus kein Snapshot erzeugt werden kann.


[oracle@ora-prod oracle]# noradatamgr --clone --instance ORCL --clone-name clonedDB

Initiating snapshot backup BaseFor-clonedDB-45512c96-0337-497b-962b-d2867fbe6827 for instance ORCL...

Success: Snapshot backup BaseFor-clonedDB-45512c96-0337-497b-962b-d2867fbe6827 completed.

Cloning diskgroups ... completed.

Mounting diskgroups ... completed.

Building instance clonedDB ... completed.

[....]


Um mich zu überzeugen, dass auch beide Instanzen sauber laufen, verbinde ich mich mit SQL*Plus:


[oracle@ora-prod oracle]# echo $ORACLE_SID

ORCL

[oracle@ora-prod oracle]# export ORACLE_SID=clonedDB

[oracle@ora-prod oracle]# sqlplus / as sysdba

 

SQL*Plus: Release 12.1.0.2.0 Production on Wed Nov 28 14:23:13 2016

 

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

 

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics

and Real Application Testing options

 

SQL> select dbid, name, created

  2  from v$database;

 

      DBID NAME      CREATED

---------- --------- ---------

1456485204 CLONEDDB  28-NOV-16

 

SQL> exit

Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics

and Real Application Testing options


[oracle@ora-prod oracle]# export ORACLE_SID=ORCL

[oracle@ora-prod oracle]# sqlplus / as sysdba

 

SQL*Plus: Release 12.1.0.2.0 Production on Wed Nov 28 14:25:14 2016

 

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

 

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics

and Real Application Testing options

 

SQL> select dbid, name, created

  2  from v$database;

 

      DBID NAME      CREATED

---------- --------- ---------

1456485204 ORCL      23-NOV-16

 

Cloning auf dem Remote-Server

Wie bereits beschrieben kann der Cloning-Prozess auch auf dem Remote-Server gestartet werden. Allerdings muss ich hier einen bestehenden Snapshot angeben, da kein Neuer erzeugt werden kann. In naher Zukunft wird es sogar möglich sein, das Cloning auf dem "entfernten" Nimble-Array, also auf dem Replikationspartner des primären Arrays, durchzuführen. Auf diese Weise kann eine Testumgebung gestartet werden, die von der primären Seite physikalisch getrennt ist, oder es kann mit einfachen Mitteln eine DR-Lösung aufgebaut werden.


[oracle@ora-clone oracle]# noradatamgr --clone --instance ORCL --clone-name remoteDB -snapname snap1-hotbackup

Cloning diskgroups ... completed.

Mounting diskgroups ... completed.

Building instance remoteDB ... completed.

Diskgroup: REMOTEDBDATADG

    Disk: /dev/oracleasm/disks/REMOTEDB0001

        Device: dm-9

        Volume: remoteDB-DATA1

        Serial number: 3009abe001bc8c0f6c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/REMOTEDB0002

        Device: dm-3

        Volume: remoteDB-DATA4

        Serial number: 5fcbec2bc8ef23fa6c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/REMOTEDB

        Device: dm-5

        Volume: remoteDB-DATA3

        Serial number: 8e32ed641de4c68f6c9ce900a5a40084

        Size: 20GB

    Disk: /dev/oracleasm/disks/REMOTEDB0003

        Device: dm-8

        Volume: remoteDB-DATA2

        Serial number: 01a2aaa7acc7e9796c9ce900a5a40084

        Size: 20GB

 

Allowed hosts: ora-clone


4. Schritt: Löschen der Clones und Snapshots

Das Löschen der Clones und der ASM-Diskgruppen erfolgt ebenfalls sehr einfach. Nachdem die Datenbanken mit SQL*Plus gestoppt sind, kann ich mit einem Befehl auf jedem Server "aufräumen":


[oracle@ora-prod oracle]# noradatamgr --destroy --diskgroup CLONEDDBDATADG

Success: Diskgroup CLONEDDBDATADG deleted.


[oracle@ora-clone oracle]# noradatamgr --destroy --diskgroup REMOTEDBDATADG

Success: Diskgroup REMOTEDBDATADG deleted.

 

Einzelnen Snapshots können mit der --delete-snapshot Option vom primären Server aus gelöscht werden. Für das Löschen der Replikate auf dem Remote-Array steht noch die Option --delete-replica zur Verfügung.

[oracle@ora-prod oracle]# noradatamgr --delete-snapshot --instance ORCL --snapname snap1-crash

Success: Snapshot snap1-crash deleted.

 

5. Fazit

Der Nimble Oracle Application Data Manager ist ein sehr einfach zu implementierendes und zu konfigurierendes Tool. Es gibt den Datenbank-Administratoren die Möglichkeit, ohne weitere Kenntnisse des angeschlossenen Nimble Arrays storagebasierte Snapshots zu erstellen und sie als getrennte Umgebung für ein Test- oder Entwicklungssystem bereitzustellen - und das quasi "auf Knopfdruck" mit nur einem Befehl. Alle Prozesse im Hintergrund wie Erzeugen der Clones, Mapping an den Zielserver, Mounten der Clones und Einbinden als ASM-Diskgruppen erfolgt vollkommen automatisch. Selbst die notwendigen Oracle-Schritte wie Mounten der DB, Kopieren der benötigten Logs, Recovery und Öffnen der DB sind komplett automatisiert.

 

Außerdem sind keine zusätzlichen Kosten damit verbunden! Dadurch, dass er im neuen Nimble Linux Toolkit (NLT) enthalten ist, steht er Nimble Storage Kunden kostenfrei zur Verfügung!!

 

Er eignet sich für Kunden, die Oracle auf physikalischen Linux-Servern betreiben, die direkt an ein Nimble Array angeschlossen sind. In virtualisierten Umgebungen muss den VMs ein direkter Zugriff auf die Nimble Volumes z.B. über iSCSI gegeben werden.

Outcomes