Ein neuer großartiger Artikel von Jim zu HPE Data Protector und Granular Recovery Extension für VMware 6. Eine sehr gute und lesenswerte Anleitung.
How to set up Data Protector to use Smart Cache for Power On and Live Migrate
Mit HPE Data Protector gibt es erweiterte Möglichkeiten für ein Recovery von virtuellen Maschinen wenn das Backup mit 3Par oder dem Smart Cache Gerät erfolgt. Im folgenden wird der SmartCache verwendet.
Um einige Hintergrundinformationen zu geben, warum dies die empfohlene Methode ist, ist aufgrund des Flusses / Prozess, den Data Protector verwendet, wenn diese Art der Wiederherstellung genutzt wird.
Wenn der Restore über Power On oder Live Migrate gestartet wird, dann generiert Data Protector einen NFS Share vom SmartCache Gerät und präsentiert und mountet die virtuelle Maschine an den ESXi Server.
Klingt einfach und Data Protector übernimmt die Arbeit im Hintergrund. Jedoch kann für diese Wiederherstellungsmethode ein SmartCache Gerät nicht auf einem NAS Share angelegt werden, da wegen der Limitierungen im NAS Bereich keine doppelten Mounts von shared volumes ausgeführt werden können.
Doppelte Mounts? Wenn ein NAS Share (CIFS oder NAS) angelegt wird, so zählt das als ein Share. Falls nun wie oben beschrieben Data Protector einen NFS Share an den ESXi Server bereitstellt, so würde dies als zweimaliges Sharen zählen. Dies ist nicht unterstützt.
Die Definition des SmartCache ist wie folgt.
Smart Cache:
Der SmartCache ist ein Backup-to-Disk Gerät welches eine „non-staged“ Wiederherstellung von virtuellen Maschinen ermöglicht. Non-staged in diesem Zusammenhang bedeutet, dass kein temporärer Restore notwendig ist um die virtuelle Maschine einzubinden. Der SmartCache ist auf folgenden Mount Points unterstützt:
- NAS Share (CIFS und NFS)
- Disk (SAN, iSCSI, local) – mit einem File System formatiert
Um nun also Power ON und Live Migrate nutzen zu können darf der SmartCache nicht auf einem NAS Share als Mount Point liegen, sondern muss über SAN, iSCSI oder Local Disk angesprochen werden.
Um zu starten muss ein Server der als SmartCache Client dient ausgewählt werden und das Filesystem wie üblich eingerichtet werden. Zusätzlich sollte ein Verzeichnis für den SmartCache angelegt werden.
Nachdem dies erledigt ist muss das folgende Kommando in der Powershell Admin Console ausgeführt werden. Dies ermöglicht dem Server „remotely signed executable“ Jobs auszuführen, die der Data Protector startet um die NFS Shares vom SmartCache Gerät anzulegen. Das zweite Kommando dient der Kontrolle.
Set-ExecutionPolicy remotesigned
Bei der Ausführung wird die Bestätigung angefordert, mit „Y“ wird der Befehl umgesetzt – siehe Bild.
Zur Kontrolle kann das folgende Kommando im Pfad C:\Program Files\Omniback\bin ausgeführt werden (Darstellung für Windows bei Verwendung der Standard Pfade) – siehe Bild.
.\nfsServiceCheck.ps1
Jetzt kann das Backup-to-Disk Gerät angelegt werden. Es wird der Client, wie oben konfiguriert, benutzt – siehe Bild.
Nachdem das Gerät angelegt wurde, kann die virtuelle Maschine auf das neue Backupziel gesichert werden.
Wenn nun Power On oder Live Migarate benutzt werden soll, so wählt man einfach die gewünschte Maschine, die vorher auf den SmartCache gesichert wurde und wählt Power On oder Live Migrate für die virtuelle Maschine aus – siehe Bild.
Es wird noch das Ziel ausgewählt und dann kann Power On ausgeführt werden – siehe Bild.
Der „Restore“ Prozess beginnt. Es ist darauf hinzuweisen, dass die virtuelle Maschine ohne aktiviertes Netzwerk gestartet wird und somit nicht mit bestehehenden Maschinen des gleichen DNS Namens in Konflikt gerät.
Die Sessions sieht ähnlich dem Bild aus.
Im vCenter wird die neue Maschine angezeigt; die Session ID ist Teil des Namens bei der Registrierung der virtuellen Maschine.
Nach Abschluss der Tests wird nach 24 Stunden durch den Data Protector die Maschine automatisch gelöscht. Dies gilt natürlich nicht für migrierte Maschinen welche mit Live Migrate wiederhergestellt wurden.
Dieser Beitrag wurde von Geoff Rennie dokumentiert und vorbereitet. Geoff ist ein Presales Kollege in HPE Software – AMS Region. Danke für das Bereitstellen des Inhaltes.
ZDB 3Par – VSS File System Backup
Das Einrichten einer Filesystem Sicherung mittels ZDB (Zero Downtime Backup) und einer 3Par ist recht einfach, jedoch kann es einige Herausforderungen dabei geben, die später im Artikel diskutiert werden.
Zum Ausführen von ZDB Backups werden normalerweise 3 Systeme benötigt:
- Den Anwendungsserver auf dem das zu sichernde Filesystem eingebunden ist
- Das Backup System
- Das 3Par Array
Diese Systeme sind in dem Screenshot (markiert in gelb) aufgeführt
Nachdem der Backup Job gestartet wurde (siehe unten im Artikel), wird das Kommando zum Erstellen des Snapshots für das Volume welches gesichert werden soll an den Anwendungsserver übergeben. Der Anwendungsserver übergibt das Kommando an die 3Par und generiert den Snapshot auf dem Array. Anschließend wird der Snapshot an den Backupserver präsentiert und im System eingebunden, so dass die Daten über den Backupserver (zur Entlastung des Anwendungsservers) an das Backupziel übertragen werden können – siehe Bild.
Nach einem Blick auf die Funktionsweise lässt sich zusammenfassen welche Data Protector Komponenten und Kommandos benötigt werden. Zuerst werden auf dem Anwendungsserver und dem Backupserver folgende Komponenten installiert:
- HPE 3PAR VSS Agent
- HPE P6000 /HPE 3PAR SMI-S agent
- MS Volume Shadow Copy Integration
- Disk Agent
- Media Agent especially on the Backup System
Kommentar: Der Anwendungsserver und der Backupserver sollten nicht das gleiche System sein und müssen mit dem gleichen Betriebssystem installiert sein.
Wie wird die Umgebung konfiguriert und welche Kommandos werden benötigt
Es wurde bereits gezeigt welche Komponenten benötigt werden, nun muss überprüft werden, dass das Storage Array richtig konfiguriert ist.
Zuerst muss sichergestellt werden, das ein Volume auf der 3Par konfiguriert ist und dieses Volume an den Anwendungsserver exportiert wurde. Der Anwendungsserver muss das neue Filesystem sehen und kann davon Daten lesen und darauf Daten schreiben.
Weiter muss sichergestellt sein, dass der Backupserver auch mit dem 3Par Array gezoned wurde und das System „sieht“. Die Volumes müssen dabei nicht an den Backupserver präsentiert werden.
Der Trick hierbei ist, dass die 3Par mit WWNs des Hosts arbeitet, dem Host kann dabei ein Alias gegeben werden. Wenn die Volumes nun an den Host exportiert werden, so kümmert sich die 3Par um den Rest.
Allerdings sollte darauf hingewiesen werden, dass mit dem Data Protector der Alias für das Backup System als FQDN konfiguriert werden muss – siehe Bild.
Wie man in dem ersten Bild sehen kann, wird der Anwendungsserver mit dem frei gewählten Alias gezeigt. Im zweiten Bild wird der Anwendungsserver gezeigt, der Name wird dabei in der FQDN Form dargestellt.
Die exportieren Volumes können auch eine beliebige Namenskonvention haben. Für das markierte Volume wird jedoch der FQDN des Anwendungsservers gezeigt.
Warum ist es wichtig den Namen im FQDN Format zu nutzen? Bei der Ausführung eines ZDB Backups wird der Name des Servers verwendet, wie er in der Client Liste in der Zelle definiert wurde. Wenn nicht der FQDN verwendet wird, so kann folgende Fehlermeldung ausgegeben werden, wobei am Anfang des Backups noch alles normal aussehen kann und der Fehler erst später protokolliert wird.
[Minor] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:29:55 AM [236:9210] A SMI-S call to the array did not behave as expected. Failed volume: DP-2015.11.20-10-056503991 Returned message: Error retrieving StorageID = HBA WWN of host sut74.atlpss.hp.net. [Normal] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:29:55 AM Starting drive scan. [Normal] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:26 AM Drive scan has completed. [Major] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:26 AM [236:51] Failed to resolve a storage volume on the host. Storage volume: DP-2015.11.20-10-056503991 [Critical] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:26 AM There are no valid objects left. [Critical] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:26 AM Some or all storage volumes cannot be backed up. Session will abort. [Critical] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:27 AM There are no valid objects left. [Normal] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:27 AM The HPE P6000 EVA / HPE 3PAR SMI-S agent enabled automatic mounting of new volumes on the operating system. [Minor] From: SMISA@sut74.atlpss.hp.net "SMISA" Time: 11/21/2015 4:30:31 AM Preparation of the backup system failed.
Was sagt diese Fehlermeldung aus? Das der Host sut74.atlpss.hp.net (Backupserver) nicht gefunden werden kann. Daher wird die Fehlermeldung ausgegeben und daher ist es wichtig immer den FQDN Namen in der 3Par zu verwenden.
Nach diesen einleitenden Erklärungen und warum diese notwendig sind müssen noch weitere Einstellungen vorgenommen werden. Dem Data Protector muss mitgeteilt werden wie er sich mit dem 3Par Array verbinden kann; der Benutzer ID (mit den richtigen Berechtigungen) und dem Passwort. Zwei Kommandos werden dafür benötigt.
Die Kommandos sind omnidbsmis
und omnidbzdb
. Im folgenden wird die Syntax beschrieben.
Mit dem Kommando omnidbsmis, werden die Anmeldeinformationen für SMI-S des Storage Array Providers gespeichert. Die Syntax ist:
omnidbsmis -ompasswd -add < IP Adresse des Storage Array > -user < Benutzername SMI-S Array Provider >
Beispiel:
omnidbsmis -ompasswd -add 10.10.253.134 -user administrator
Administrator ist typischerweise der Default User, Domain User Namen sollten im Format username@domain eingegeben werden.
Zur Überprüfung kann folgendes Kommando verwendet werden (Beispielausgabe):
omnidbsmis -ompasswd -list
User Host Port Ssl ---------------+--------------------+-----+----- administrator@atlpss.hp.net (administrator@atlpss.hp.net) dp9.atlpss.hp.net 5988 No administrator sut64.atlpss.hp.net 5988 No
Das nächste Kommando „omnidbzdb“ führt den administrativen Task für das 3Par Array aus und verwaltet die Konfigurationsdaten der Agenten die sich mit dem CIMOM Provider des Storage Systems verbinden wollen. Das Kommando ist auf Systemen mit installiertem User Interface (zum Beispiel auf dem Cell Manager) verfügbar.
Die zu verwendende Syntax:
omnidbzdb --diskarray 3PAR --ompasswd --add < IP Adresse des Storage Array > --user < User ID mit entsprechender Berechtigung > --passwd < Passwort des Benutzers >
Beispiel:
omnidbzdb --diskarray 3PAR --ompasswd --add 10.10.253.134 --user 3paradm --passwd 3pardata
Zur Überprüfung kann das folgende Kommando genutzt werden:
omnidbzdb --diskarray 3PAR --ompasswd --list
User Host Port Ssl ----------------+--------------------+-----+----- 3paradm 10.10.253.166 5988 No
Nachdem diese Schritte durchgeführt wurden kann das Filesystem Backup über VSS und 3Par im Data Protector eingerichtet werden.
Dieser Beitrag wurde von Geoff Rennie dokumentiert und vorbereitet. Geoff ist ein Presales Kollege in HPE Software – AMS Region. Danke für das Bereitstellen des Inhaltes.
Data Protector 9 – GR Patches 9.05 (Build 106)
Am 29.01.2016 sind für Linux, Windows und HP-UX neue Patches (Build 106) herausgegeben wurden. Dies ist nicht Patch Bundle 9.06. Voraussetzung ist das installierte Patch Bundle 9.05. Es empfiehlt sich dringend die komplette Beschreibung der Updates zu lesen.
Wenn Sie einen gültigen Wartungsvertrag haben, so können Sie den Patch unter https://softwaresupport.hp.com herunterladen, die Anmeldung erfolgt mit dem HP Passport Account. Bei der Installation der Patches ist die Reihenfolge einzuhalten – siehe https://www.data-protector.org/wordpress/2013/06/basics-installation-order-patches/
Links zu den Patches:
– Data Protector 9.05_106 – Lotus for Windows (DPWIN_00885)
– Data Protector 9.05_106 – Documentation for Windows (DPWIN_00883)
– Data Protector 9.05_106 – SMISA for Windows (DPWIN_00884)
– Data Protector 9.05_106 – Disk Agent for Windows (DPWIN_00882)
– Data Protector 9.05_106 – Cell Console for Windows (DPWIN_00881)
– Data Protector 9.05_106 – Cell Server for Windows (DPWIN_00879)
– Data Protector 9.05_106 – Core for Windows (DPWIN_00878)
– Data Protector 9.05_106 – Media Agent for Windows (DPWIN_00880)
– Data Protector 9.05_106 – Lotus for Linux/64 (DPLNX_00462)
– Data Protector 9.05_106 – SMISA for Linux/64 (DPLNX_00461)
– Data Protector 9.05_106 – Documentation for Linux/64 (DPLNX_00460)
– Data Protector 9.05_106 – Disk Agent for Linux/64 (DPLNX_00459)
– Data Protector 9.05_106 – Cell Console for Linux/64 (DPLNX_00458)
– Data Protector 9.05_106 – Media Agent for Linux/64 (DPLNX_00457)
– Data Protector 9.05_106 – Cell Server for Linux/64 (DPLNX_00456)
– Data Protector 9.05_106 – Core for Linux/64 (DPLNX_00455)
– Data Protector 9.05_106 – Lotus for HP-UX/IA (DPUX_00173)
– Data Protector 9.05_106 – SMISA for HP-UX/IA (DPUX_00172)
– Data Protector 9.05_106 – Documentation for HP-UX/IA (DPUX_00171)
– Data Protector 9.05_106 – Disk Agent for HP-UX/IA (DPUX_00170)
– Data Protector 9.05_106 – Cell Console for HP-UX/IA (DPUX_00169)
– Data Protector 9.05_106 – Media Agent for HP-UX/IA (DPUX_00168)
– Data Protector 9.05_106 – Cell Server for HP-UX/IA (DPUX_00167)
HPE Data Protector – Cross Cell Replication – step by step
Ein weiterer Artikel wie die Cross Cell Replikation mit dem HPE Data Protector funktioniert. Jim hat diesen Artikel geschrieben und zur Verfügung gestellt.