Architektur von SnapCenter
SnapCenter ist eine einheitliche, skalierbare Plattform für applikationskonsistente Datensicherung. SnapCenter bietet zentrale Kontrolle und Überwachung und delegiert die Möglichkeit, dass Benutzer applikationsspezifische Backup-, Restore- und Klonaufgaben managen können. Mit SnapCenter erhalten Datenbank- und Storage-Administratoren ein Tool, mit dem sie Backup-, Wiederherstellungs- und Klonvorgänge für verschiedene Applikationen und Datenbanken managen können.
SnapCenter managt Daten über Endpunkte in der Data-Fabric-Architektur von NetApp hinweg. Daten können mit SnapCenter zwischen lokalen Umgebungen, zwischen lokalen Umgebungen und der Cloud sowie zwischen Private, Hybrid oder Public Clouds repliziert werden.
Komponenten von SnapCenter
SnapCenter umfasst den SnapCenter-Server, das SnapCenter-Plug-in-Paket für Windows und das SnapCenter-Plug-in-Paket für Linux. Jedes Paket enthält SnapCenter-Plug-ins für diverse Applikations- und Infrastrukturkomponenten.
SnapCenter SAP HANA Backup-Lösung
Die SnapCenter Backup-Lösung für SAP HANA umfasst folgende Bereiche:
-
Backup-Vorgänge, Planung und Aufbewahrungsmanagement
-
SAP HANA Daten-Backup mit Storage-basierten Snapshot Kopien
-
Backup nicht datenbasierter Volumes mit Storage-basierten Snapshot Kopien (z. B.
/hana/shared
) -
Integritätsprüfungen der Datenbankblöcke mithilfe eines dateibasierten Backups
-
Die Replizierung an ein externes Backup oder einen Disaster-Recovery-Standort
-
-
Allgemeine Ordnung und Sauberkeit des SAP HANA Backup-Katalogs
-
Für HANA Daten-Backups (Snapshot und dateibasiert)
-
Für HANA-Protokoll-Backups
-
-
Restore- und Recovery-Vorgänge
-
Automatisiertes Restore und Recovery
-
Restore von einzelnen Mandanten für SAP HANA (MDC)-Systeme
-
Backups von Datenbankdateien werden von SnapCenter in Kombination mit dem Plug-in für SAP HANA ausgeführt. Das Plug-in löst den Speicherpunkt für das SAP HANA Datenbank-Backup aus, sodass die Snapshot Kopien, die auf dem primären Storage-System erstellt werden, auf einem konsistenten Image der SAP HANA Datenbank basieren.
SnapCenter ermöglicht die Replizierung konsistenter Datenbank-Images auf einen externen Backup- oder Disaster-Recovery-Standort mithilfe von SnapVault oder der SnapMirror Funktion. In der Regel werden verschiedene Aufbewahrungsrichtlinien für Backups auf dem primären und externen Backup-Storage definiert. SnapCenter übernimmt die Aufbewahrung im Primärspeicher und ONTAP übernimmt die Aufbewahrung auf dem externen Backup-Storage.
Für ein vollständiges Backup aller mit SAP HANA verbundenen Ressourcen ermöglicht SnapCenter auch das Backup aller nicht datenbezogenen Volumes über das SAP HANA Plug-in mit Storage-basierten Snapshot Kopien. Sie können nicht-Daten-Volumes unabhängig vom Datenbank-Daten-Backup planen, um individuelle Aufbewahrungs- und Sicherungsrichtlinien zu aktivieren.
SAP empfiehlt, Storage-basierte Snapshot-Backups mit einem wöchentlichen dateibasierten Backup zu kombinieren, um eine Integritätsprüfung für Blöcke durchzuführen. Sie können die Integritätsprüfung der Blöcke in SnapCenter ausführen. Basierend auf Ihren konfigurierten Aufbewahrungsrichtlinien managt SnapCenter die allgemeine Ordnung und Sauberkeit der Datendatei-Backups im primären Storage, Backup von Protokolldateien und den SAP HANA Backup-Katalog.
SnapCenter übernimmt die Aufbewahrung auf dem primären Storage, während FSX für ONTAP die sekundäre Backup-Aufbewahrung managt.
Die folgende Abbildung bietet einen Überblick über die SnapCenter Backup- und Aufbewahrungsvorgänge.
Beim Ausführen eines Storage-basierten Snapshot Backups der SAP HANA Datenbank führt SnapCenter die folgenden Aufgaben durch:
-
Erstellung eines SAP HANA Backup-Speicherpunktes, um ein konsistentes Image auf der Persistenzschicht zu erstellen.
-
Erstellt eine Storage-basierte Snapshot Kopie des Daten-Volumes
-
Registrieren des Storage-basierten Snapshot-Backups im SAP HANA Backup-Katalog
-
Gibt den Speicherpunkt für SAP HANA Backup frei.
-
Führt, falls konfiguriert, ein SnapVault oder SnapMirror Update für das Daten-Volume durch
-
Löscht die Storage-Snapshot-Kopien im primären Storage auf der Grundlage der definierten Aufbewahrungsrichtlinien.
-
Löscht die Einträge des SAP HANA Backup-Katalogs, wenn die Backups nicht mehr im primären oder externen Backup-Speicher vorhanden sind.
-
Sobald ein Backup auf Basis der Aufbewahrungsrichtlinie oder manuell gelöscht wurde, löscht SnapCenter auch alle Log-Backups, die älter als das älteste Daten-Backup sind. Log-Backups werden im Dateisystem und im SAP HANA Backup-Katalog gelöscht.
Inhalt des vorliegenden Dokuments
Dieses Dokument beschreibt die gängigste SnapCenter-Konfigurationsoption für ein einzelnes Hostsystem mit einem einzelnen SAP HANA MDC-Mandanten auf FSX für ONTAP. Es sind andere Konfigurationsoptionen möglich und in manchen Fällen auch für bestimmte SAP HANA Systeme erforderlich, beispielsweise für ein mehrere Host-Systeme. Eine ausführliche Beschreibung zu anderen Konfigurationsoptionen finden Sie unter "SnapCenter-Konzepte und Best Practices (netapp.com)".
In diesem Dokument verwenden wir die Amazon Web Services (AWS)-Konsole und die FSX für ONTAP CLI, um die erforderlichen Konfigurationsschritte auf der Storage-Ebene auszuführen. Sie können FSX für ONTAP auch mit NetApp Cloud Manager managen. Dies ist jedoch nicht im Umfang dieses Dokuments enthalten. Informationen zur Verwendung von NetApp Cloud Manager für FSX für ONTAP finden Sie unter "Weitere Informationen zu Amazon FSX für ONTAP (netapp.com)".
Datensicherung Strategie
Die folgende Abbildung zeigt eine typische Backup-Architektur für SAP HANA auf FSX für ONTAP. Das HANA-System befindet sich in der AWS-Verfügbarkeitszone 1 und verwendet ein FSX für ONTAP-Dateisystem innerhalb derselben Verfügbarkeitszone. Snapshot Backup-Vorgänge werden für die Daten und das gemeinsam genutzte Volume der HANA Datenbank ausgeführt. Neben den lokalen Snapshot Backups, die 3-5 Tage aufbewahrt werden, werden Backups auch zur längerfristigen Aufbewahrung auf einen externen Storage repliziert. Der externe Backup-Storage ist ein zweites FSX für ONTAP-Filesystem, das sich in einer anderen AWS-Verfügbarkeitszone befindet. Backups der HANA Daten und des gemeinsam genutzten Volumes werden mit SnapVault in die zweite FSX für ONTAP Filesystem repliziert und 2-3 Wochen aufbewahrt.
Vor dem Konfigurieren von SnapCenter muss die Datensicherungsstrategie auf Basis der RTO- und RPO-Anforderungen der verschiedenen SAP Systeme definiert werden.
Ein gemeinsamer Ansatz besteht in der Definition von Systemtypen wie Systemen für Produktion, Entwicklung, Test oder Sandbox. Alle SAP-Systeme des gleichen Systemtyps haben typischerweise die gleichen Datenschutzparameter.
Folgende Parameter müssen definiert werden:
-
Wie oft sollte ein Snapshot Backup ausgeführt werden?
-
Wie lange sollten Snapshot Kopien Backups auf dem Primärspeichersystem aufbewahrt werden?
-
Wie oft sollte eine Blockintegritätsprüfung ausgeführt werden?
-
Sollten die primären Backups auf einen externen Backup-Standort repliziert werden?
-
Wie lange sollten die Backups auf dem externen Backup-Storage aufbewahrt werden?
Die folgende Tabelle zeigt ein Beispiel für die Datensicherungsparameter für die Systemtypen: Produktion, Entwicklung und Test. Für das Produktionssystem wurde eine hohe Backup-Frequenz definiert und die Backups werden einmal pro Tag an einen externen Backup-Standort repliziert. Die Testsysteme haben niedrigere Anforderungen und keine Replikation der Backups.
Parameter | Produktionssysteme auszuführen | Entwicklungssysteme | Testsysteme |
---|---|---|---|
Sicherungshäufigkeit |
Alle 6 Stunden |
Alle 6 Stunden |
Alle 6 Stunden |
Primäre Aufbewahrung |
3 Tage |
3 Tage |
3 Tage |
Block-Integritätsprüfung |
Einmal in der Woche |
Einmal in der Woche |
Nein |
Replizierung an externe Backup-Standorte |
Einmal am Tag |
Einmal am Tag |
Nein |
Externe Backup-Aufbewahrung |
2 Wochen |
2 Wochen |
Keine Angabe |
In der folgenden Tabelle werden die Richtlinien aufgeführt, die für die Datensicherheitsparameter konfiguriert werden müssen.
Parameter | RichtliniengebietsSnap | Policy LocalSnapAndSnapVault | RichtlinienblockIntegritätsprüfung |
---|---|---|---|
Backup-Typ |
Auf Snapshot-Basis |
Auf Snapshot-Basis |
File-basiert |
Zeitplanhäufigkeit |
Stündlich |
Täglich |
Wöchentlich |
Primäre Aufbewahrung |
Anzahl = 12 |
Anzahl = 3 |
Anzahl = 1 |
SnapVault Replizierung |
Nein |
Ja. |
Keine Angabe |
Richtlinie LocalSnapshot
Werden für Produktions-, Entwicklungs- und Testsysteme verwendet, um lokale Snapshot-Backups mit einer Aufbewahrung von zwei Tagen abzudecken.
In der Konfiguration für den Ressourcenschutz wird der Zeitplan für die Systemtypen unterschiedlich definiert:
-
Produktion: Zeitplan alle 4 Stunden.
-
Entwicklung: Alle 4 Stunden einplanen.
-
Test: Alle 4 Stunden planen.
Richtlinie LocalSnapAndSnapVault
Wird für die Produktions- und Entwicklungssysteme eingesetzt, um die tägliche Replizierung auf den externen Backup Storage zu decken.
In der Konfiguration für den Ressourcenschutz wird der Zeitplan für die Produktion und Entwicklung definiert:
-
Produktion: Zeitplan jeden Tag.
-
Entwicklung: Zeitplan jeden Tag.die Politik
BlockIntegrityCheck
Wird für die Produktions- und Entwicklungssysteme eingesetzt, um die wöchentliche Blockintegritätsprüfung mithilfe eines dateibasierten Backups abzudecken.
In der Konfiguration für den Ressourcenschutz wird der Zeitplan für die Produktion und Entwicklung definiert:
-
Produktion: Zeitplan jede Woche.
-
Entwicklung: Zeitplan jede Woche.
Für jede einzelne SAP HANA Datenbank, die die externe Backup-Richtlinie nutzt, müssen Sie eine Sicherungsbeziehung auf der Storage-Ebene konfigurieren. Die Sicherungsbeziehung definiert, welche Volumes repliziert werden und wie die Aufbewahrung von Backups im externen Backup-Storage aufbewahrt wird.
Im folgenden Beispiel wird für jedes Produktions- und Entwicklungssystem im externen Backup-Storage eine Aufbewahrung von zwei Wochen definiert.
In diesem Beispiel unterscheiden sich die Sicherungsrichtlinien und die Aufbewahrung von SAP HANA Datenbankressourcen und Ressourcen ohne Datenvolumen.
Beispiel für die Laboreinrichtung
Das folgende Lab-Setup wurde als Beispielkonfiguration für den Rest dieses Dokuments verwendet.
HANA-System-PFX:
-
Ein Host-MDC-System mit einem einzelnen Mandanten
-
HANA 2.0 SPS 6, Version 60
-
SLES FÜR SAP 15SP3
SnapCenter
-
Version 4.6
-
Auf einem HANA Datenbank-Host implementiertem HANA und Linux Plug-in
FSX für ONTAP-Dateisysteme:
-
Zwei FSX für ONTAP Filesysteme mit einer einzigen Storage Virtual Machine (SVM)
-
Jedes FSX für ONTAP-System in einer anderen AWS-Verfügbarkeitszone
-
HANA Daten-Volume zur Replizierung in das zweite FSX für ONTAP Filesystem