Die folgende Abbildung zeigt die für dieses Kapitel verwendete Laboreinrichtung. Zwei HANA-Hosts, hana-3 und hana-4, wurden mit HANA System Replication konfiguriert.

Für die HANA-Systemdatenbank wurde ein Datenbankbenutzer „SnapCenter“ mit den erforderlichen Privileges erstellt, um Backup- und Recovery-Vorgänge auszuführen (siehe "Technischer Bericht: SAP HANA Backup and Recovery with SnapCenter"). Ein HANA-Benutzerspeicherschlüssel muss auf beiden Hosts mit dem oben genannten Datenbankbenutzer konfiguriert sein.

Aus einer übergeordneten Sicht müssen Sie die folgenden Schritte durchführen, um HANA System Replication in SnapCenter einzurichten.

Nachdem Sie das SnapCenter HANA Plug-in auf beiden HANA-Hosts installiert haben, werden die HANA-Systeme in der Ansicht der SnapCenter-Ressourcen wie andere automatisch erkannte Ressourcen angezeigt. Ab SnapCenter 4.6 wird eine zusätzliche Spalte angezeigt, in der der Status der HANA-Systemreplizierung (aktiviert/deaktiviert, primär/sekundär) angezeigt wird.

Durch Klicken auf die Ressource fordert SnapCenter den HANA-Benutzerspeicherschlüssel für das HANA-System an.

Weitere Schritte zur automatischen Ermittlung werden ausgeführt, und SnapCenter zeigen die Ressourcendetails an. In SnapCenter 4.6 werden der Replikationsstatus des Systems und der sekundäre Server in dieser Ansicht aufgelistet.

Nach Durchführung der gleichen Schritte für die zweite HANA-Ressource ist die automatische Ermittlung abgeschlossen, und beide HANA-Ressourcen werden in SnapCenter konfiguriert.

Für HANA System Replication-fähige Systeme müssen Sie eine SnapCenter-Ressourcengruppe, einschließlich beider HANA-Ressourcen, konfigurieren.

NetApp empfiehlt die Verwendung eines benutzerdefinierten Namensformats für den Snapshot-Namen. Dieser sollte den Hostnamen, die Richtlinie und den Zeitplan enthalten.

Sie müssen der Ressourcengruppe beide HANA-Hosts hinzufügen.

Die Richtlinien und Zeitpläne für die Ressourcengruppe werden konfiguriert.

Die Konfiguration der Ressourcengruppe ist jetzt abgeschlossen und Backups können ausgeführt werden.

Wenn ein Backup-Vorgang der Ressourcengruppe ausgeführt wird, identifiziert SnapCenter den primären Host und löst nur ein Backup auf dem primären Host aus. Das bedeutet, dass nur das Daten-Volume des primären Hosts mit Snapshots erstellt werden wird. in unserem Beispiel ist hana-3 der aktuelle primäre Host und ein Backup wird auf diesem Host ausgeführt.

Das SnapCenter-Jobprotokoll zeigt den Identifizierungsvorgang und die Ausführung des Backups auf dem aktuellen primären Host hana-3.

Ein Snapshot-Backup wurde jetzt auf der primären HANA-Ressource erstellt. Der im Backup-Namen enthaltene Hostname zeigt hana-3.

Das Snapshot-Backup ist auch im HANA-Backup-Katalog sichtbar.

Falls ein Übernahmevorgang ausgeführt wird, identifizieren weitere SnapCenter Backups jetzt den früheren sekundären Host (hana-4) als primär und der Backup-Vorgang wird auf hana-4 ausgeführt. Erneut wird nur das Daten-Volume des neuen primären Hosts (hana-4) mit Snapshots erstellt.

Das SnapCenter-Jobprotokoll zeigt den Identifizierungsvorgang und die Ausführung des Backups auf dem aktuellen primären Host hana-4.

Ein Snapshot-Backup wurde jetzt auf der primären HANA-Ressource erstellt. Der im Backup-Namen enthaltene Hostname zeigt hana-4.

Das Snapshot-Backup ist auch im HANA-Backup-Katalog sichtbar.

SnapCenter 4.6 verwendet dieselbe Logik wie für Snapshot Backup-Vorgänge bei dateibasierten Backups beschrieben zur Überprüfung der Blockintegrität. SnapCenter identifiziert den aktuellen primären HANA-Host und führt das dateibasierte Backup für diesen Host aus. Das Aufbewahrungsmanagement wird auch auf beiden Hosts durchgeführt, sodass das älteste Backup unabhängig davon, welcher Host sich derzeit im primären System befindet, gelöscht wird.

Damit transparente Backup-Vorgänge ohne manuelle Interaktion möglich sind, muss im Falle einer Übernahme und unabhängig davon, dass der HANA-Host derzeit der primäre Host ist, eine SnapVault-Beziehung für die Daten-Volumes beider Hosts konfiguriert werden. SnapCenter führt bei jedem Backup-Durchlauf einen SnapVault Update-Vorgang für den aktuellen primären Host durch.

Da die Retention Management am SnapVault-Ziel außerhalb von SnapCenter durch ONTAP verwaltet wird, kann die Aufbewahrung nicht über beide HANA-Hosts abgewickelt werden. Daher werden Backups, die vor einem Takeover erstellt wurden, nicht mit Backup-Vorgängen auf dem ehemaligen Sekundärstandort gelöscht. Diese Backups bleiben so lange erhalten, bis der frühere primäre wieder auf den primären Speicher zurückgeht. Damit diese Backups das Aufbewahrungsmanagement von Log-Backups nicht blockieren, müssen sie entweder am SnapVault-Ziel oder im HANA-Backup-Katalog manuell gelöscht werden.

SnapCenter 4.6 verwaltet Aufbewahrung für Snapshot-Backups, Block-Integrität-Check Operationen, HANA Backup-Katalog Einträge, und Log-Backups (wenn nicht deaktiviert) über beide HANA-Hosts, so ist es egal, welcher Host derzeit primär oder sekundär ist. Backups (Daten und Protokoll) und Einträge im HANA-Katalog werden basierend auf der definierten Aufbewahrung gelöscht, unabhängig davon, ob ein Löschvorgang auf dem aktuellen primären oder sekundären Host erforderlich ist. Das bedeutet, dass keine manuelle Interaktion erforderlich ist, wenn ein Übernahmemodus durchgeführt wird und/oder die Replizierung in andere Richtung konfiguriert wird.

Wenn die SnapVault-Replizierung Teil der Datensicherungsstrategie ist, ist für bestimmte Szenarien eine manuelle Interaktion erforderlich, wie in Abschnitt beschrieben "SnapVault-Replizierung"

Die folgende Abbildung zeigt ein Szenario, in dem mehrere Übernahmen ausgeführt und Snapshot Backups an beiden Standorten erstellt wurden. Mit dem aktuellen Status ist der Host hana-3 der primäre Host und das neueste Backup T4, das auf Host hana-3 erstellt wurde. Wenn Sie einen Restore- und Recovery-Vorgang durchführen müssen, sind die Backups T1 und T4 für die Wiederherstellung im SnapCenter verfügbar. Die Backups, die auf dem Host hana-4 (T2, T3) erstellt wurden, können mit SnapCenter nicht wiederhergestellt werden. Diese Backups müssen zur Wiederherstellung manuell auf das Datenvolumen von hana-3 kopiert werden.

Die Wiederherstellungs- und Recovery-Vorgänge für eine SnapCenter 4.6-Ressourcengruppe sind identisch mit einer automatisch erkannten Konfiguration, die nicht vom System stammt. Alle Optionen für Restores und automatisiertes Recovery sind verfügbar. Weitere Einzelheiten finden Sie im technischen Bericht "TR-4614: SAP HANA Backup and Recovery with SnapCenter".

Eine Wiederherstellung aus einem Backup, das auf dem anderen Host erstellt wurde, wird im Abschnitt beschrieben "Wiederherstellung aus einem Backup, das auf dem anderen Host erstellt wurde".