Spieglein, Spieglein an der Wand  . . .

Im ersten Teil unserer Serie "Oracle auf NetApp" [1] haben wir Ihnen vorgestellt, wie Oracle Instanzen auf NetApp Storage betrieben und gesichert werden können. In diesem Teil der Serie wollen wir uns damit beschäftigen, wie Datenbanken filer-übergreifend kopiert werden. Für dieses Anliegen gibt es gute Gründe: produktionsnahe Datenstände sollen in der Entwicklungsumgebung verfügbar gemacht werden oder Backups sollen physikalisch vom aktiven Filer (File-System) separiert werden.

Abb. 1: Flexclone. Auf Basis eines Snapshots kann aus einem Quell-Volume (A) ein neues Volume (B) platzsparend geklont werden. Vergrößern Abb. 2: Bei einem Snapmirror werden Inhalte und Strukturen asynchron gespiegelt. Vergrößern Abb. 3: Das Snapvault-Verfahren ist aufgrund der getrennten Snapshot-Verwaltung für Backup-Szenarien prädestiniert. Vergrößern Abb. 4: Data Guard zur Filer-Übertragung. Vergrößern

Getrennte Welten – Integration und Entwicklung

In IT-Abteilungen werden Datenbanken oft in mehreren Ebenen (Stages) betrieben. Getrennt werden der produktive Bereich von der Integrations- und Entwicklungsumgebung. In der Regel sind die entsprechenden Datenbanken/Instanzen mit separaten Filer-Systemen verbunden. In der Praxis werden relativ häufig produktionsnahe Datenbestände auf einem Entwicklungssystem oder der Integrationsumgebung benötigt, um auf ihnen z. B. möglichst realitätsnahe Performance- und/oder Lasttests durchzuführen. Darüber hinaus werden Snapshots zu Backup-Zwecken auf entfernte Filer-Systeme übertragen, um sie vom aktiv genutzten File-System (Filer) zu entkoppeln.

Flexclones - immer schön flexibel bleiben

Um die nachfolgend beschriebenen Verfahren zu verstehen, müssen im Vorfeld einige Begriffe geklärt werden. Den Begriff Snapshot haben wir bereits in der Ausgabe 2/2009 „Oracle auf NetApp (Teil I)“ [1] beleuchtet und erklärt.

Neu hingegen ist der Begriff Flexclone. Ein Flexclone ist eine Kopie eines Volumes, das auf dem Snapshot eines Quell-Volumes basiert. Flexclones benötigen im Moment ihrer Erzeugung zunächst keinen (kaum) eigenen physikalischen Speicherplatz. Ihre Datenblöcke sind direkt per lesendem Zugriff auf die Datenblöcke im Quell-Volume verlinkt. Erst wenn mit den kopierten Volumes gearbeitet wird (schreibende Zugriffe), müssen die erzeugten Delta-Informationen im neuen Volume abgespeichert werden. Durch diese Änderungen wächst nun auch das „geklonte“ Volume physikalisch (siehe Abbildung 1). Bei Bedarf können die Flexclones nachträglich physikalisch von ihrem Quell-Volume getrennt werden. Zu diesem Zeitpunkt werden alle noch nicht veränderten Datenblöcke vom Quell-Volume auf den Flexclone übertragen.

Wie ein Ei dem anderen

Wie bekommen wir nun die Datenbankinhalte (also die Datenbankdateien) konsistent von einem Filer (z. B. dem Produktions-Filer) in die Entwicklungsumgebung? Das NetApp-Betriebssystem Ontap bietet uns zwei mögliche Wege an. Beide sind lizenzkostenpflichtig:

• Snapmirror
• Snapvault

Snapmirror

Das Snapmirror-Verfahren spiegelt Volumes von einen auf den anderen Filer. Neben dem aktiven File-System des Volumes werden auch die historischen File-Systeme (Snapshots) mit übertragen. Das Quell- und Ziel-Volume sind bei diesem Verfahren idealtypisch identisch dimensioniert. Das Ziel-Volume muss mindestens gleich groß, kann aber auch größer als das Quell-Volume sein. Diese Art eines Spiegels kann jederzeit aktualisiert werden. Das Ziel- und Quell-Volume sind – wenn auch ggf. etwas zeitverzögert – synchron. Wird ein Snapshot auf dem Quell-Volume erstellt oder gelöscht, so wird diese Änderung auch auf das Ziel-Volume übertragen. Eine getrennte Verwaltung (Retention) der Snapshots ist in einer Snapmirror-Beziehung demnach nicht möglich.

Solange der Spiegel aktiv ist, kann mit dem Ziel-Volume nicht „normal“ (also lesend und schreibend) gearbeitet werden. Um die Datenbankdateien eines gespiegelten Volumes von einer Instanz verwenden zu lassen, muss vorher der Spiegel „zerbrochen“ werden.

Alternativ können natürlich die Snapshots des gespiegelten Volumes verwendet werden, um Flexclones zu erzeugen. In diesem Fall kann der Spiegel für künftige Updates erhalten bleiben und trotzdem neue Datenbanken „geklont“ werden (siehe Abbildung 2).

Snapvault

Beim Snapvault-Verfahren werden die Datenblöcke des Quell-Volumes auf ein Ziel-Volume übertragen. Bei den zu übertragenden Datenblöcken kann es sich um das aktive oder ein historisches File-System (Snapshot) des Quell-Volumes handeln. Das Ziel eines Snapvaults ist demnach nicht die Erzeugung der Kopie eines Volumes inkl. der Snapshots, sondern lediglich die Übertragung der Inhalte eines Standes des Quell-Volumes. Die Daten können daher in einen Qtree eines beliebigen Volumes transferiert werden. Ein Qtree stellt eine Art logische Ordnerstruktur in einem Volume dar. Zum Vergleich: Volume = Festplatte; Qtree = Ordner.

Theoretisch kann somit ein Volume mit einer entsprechenden Anzahl von Qtrees als Sicherungsmedium von vielen Quell-Volumes (Datenbank-Volumes) genutzt werden. Da bei diesem Verfahren nur Inhalte und keine verwaltungstechnischen oder logischen Einheiten wie. z. B. Snapshots übertragen werden, können auf dem Ziel-Volume unabhängig Snapshots erstellt und gelöscht werden (siehe Abbildung 3).

Data Guard

Neben den herstellerspezifischen Protokollen gibt es noch weitere Möglichkeiten, Datenbankinformationen von A nach B zu transferieren, z. B. mit Oracle Data Guard.

Hier ein mögliches Szenario: Sie betreiben Ihre Produktionsdatenbank auf einem entsprechenden Produktions-Filer. Parallel dazu setzen Sie eine Standby-Datenbank ein, deren Datenbankdateien auf einem Entwicklungs-Filer liegen. Die Standby-Datenbank läuft nun – ggf. mit einem gewünschten Versatz (Delay) – parallel zur Ihrem Produktionssystem. Um die Entwicklungsinstanz auf den aktuellen Produktionsstand zu bringen, stoppen Sie die Standby-Datenbank. Sie bringen damit die Datenbankdateien in einen konsistenten Zustand. Standby-Datenbanken können leider nicht in den Hotbackup-Modus versetzt werden [1]. Nun erstellen Sie einfach einen Snapshot von den Datenbankdateien und starten im Anschluss daran erneut Ihre Standby-Datenbank.

Die erzeugten Snapshots können dann verwendet werden, um neue Volumes für Entwicklungsdatenbanken zu klonen (Flexclone). Dieser Vorgang ist natürlich auch recht einfach zu skripten und bietet den Vorteil, dass eine große Datenmenge der über diesen Weg aufgebauten Datenbanken nur einmalig physikalisch vorgehalten wird.

Viele Daten einer Entwicklungsdatenbank werden in aller Regel nicht geändert (z. B. Systeminformationen oder archivierte Daten). Da diese Daten nicht schreibend verändert werden, können sie dem Quell-Volume (also dem Volume der Standby-Datenbank) entnommen werden. Bei einer entsprechenden Anzahl von Entwicklungsdatenbanken potenziert sich dieser Effekt natürlich (siehe Abbildung 4).

Fazit

Eine filer-übergreifende Versorgung von Datenbanken ist über das NetApp-Betriebssystem Ontap problemlos möglich, sofern die entsprechenden Lizenzen erworben wurden. Die Administration und Überwachung der Spiegelbeziehung ist unkompliziert und kann sehr schnell erlernt und eingesetzt werden. Darüber hinaus stehen auch alternative Konzepte zur Versorgung von Entwicklungsinstanzen bereit (z. B. Data Guard). Neben einer reinen Versorgung von Datenbanken mit produktionsnahen Ständen kann gerade das Snapvault-Verfahren genutzt werden, um Datenbanken auf getrennten Filer-Systemen zu sichern (Backup-To-Disk-Konzepte). Die Möglichkeit, getrennte Retentions auf dem Produktions- und Backup-System zu nutzen, macht dieses Verfahren zum klaren Favoriten in Sachen Backup.

Im nächsten Teil der Serie präsentieren wir Ihnen NetApp SMO (Snap Manager for Oracle). Es handelt sich dabei um ein herstellerspezifisches Werkzeug, mit dem Datenbanken gesichert, wiederhergestellt und/oder kopiert werden können.

Matthias Jung (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen