Systemaktualisierung für SAP HANA mit SnapCenter
Änderungen vorschlagen
PDFs
Im folgenden Abschnitt finden Sie eine Schritt-für-Schritt-Beschreibung der verschiedenen Optionen für die Systemaktualisierung einer SAP HANA-Datenbank.
Je nach Konfiguration der SAP HANA-Datenbank werden weitere Schritte ausgeführt bzw. müssen vorbereitet werden. Die folgende Tabelle bietet eine Zusammenfassung.
| Quellsystem | Konfiguration des Quellsystems | SnapCenter- und SAP HANA-Betrieb |
|---|---|---|
MDC Einzelmandant + SID = Mandantenname |
Standardkonfiguration |
SnapCenter-Klonvorgang und optionale Ausführung von Wiederherstellungsskripten. |
SAP HANA-Verschlüsselung mit Persistenz |
Zunächst oder wenn die Stammschlüssel im Quellsystem geändert wurden, müssen die Stammschlüsselsicherungen auf dem Zielsystem importiert werden, bevor die Wiederherstellung ausgeführt werden kann. |
|
Quelle für die SAP HANA-Systemreplizierung |
Weitere Schritte sind nicht erforderlich. Wenn für das Zielsystem kein HSR konfiguriert ist, bleibt es ein eigenständiges System. |
|
SAP HANA mehrere Partitionen |
Keine zusätzlichen Schritte erforderlich, aber Mount-Punkte für SAP HANA-Volume-Partitionen müssen auf dem Zielsystem mit derselben Namenskonvention verfügbar sein (nur SID ist unterschiedlich). |
|
MDC mehrere Mandanten Oder MDC Einzelmandant + mit SID <> Mandantenname |
Standardkonfiguration |
SnapCenter-Klonvorgang und optionale Ausführung von Wiederherstellungsskripten. Skript stellt alle Mandanten wieder her. Wenn bei den Zielsystemnamen keine Mandanten- oder Mandantennamen vorhanden sind, werden erforderliche Verzeichnisse automatisch während der SAP HANA-Wiederherstellung erstellt. Die Mandantennamen entsprechen der Quelle und müssen bei Bedarf nach der Wiederherstellung umbenannt werden. |
SAP HANA-Verschlüsselung mit Persistenz |
Wenn zuvor auf dem Zielsystem keine DBID des Quellsystems vorhanden ist, muss die Systemdatenbank zuerst wiederhergestellt werden, bevor die Stammschlüsselsicherung dieses Mandanten importiert werden kann. |
|
Quelle für HANA-Systemreplizierung |
Weitere Schritte sind nicht erforderlich. Wenn für das Zielsystem kein HSR konfiguriert ist, bleibt es ein eigenständiges System. |
|
HANA mit mehreren Partitionen |
Keine zusätzlichen Schritte erforderlich, aber Mount-Punkte für SAP HANA-Volume-Partitionen müssen auf dem Zielsystem mit derselben Namenskonvention verfügbar sein (nur SID ist unterschiedlich). |
In diesem Abschnitt werden die folgenden Szenarien behandelt.
-
SAP HANA Systemaktualisierung ohne Trennung von Klonen
-
Wird aus dem primären Storage geklont, wobei der Mandantenname der SID entspricht
-
Klonen aus standortexternen Backup-Storage
-
Klonen aus dem Primärspeicher mit mehreren Mandanten
-
Klonvorgang
-
SAP HANA Systemaktualisierung mit einem Klonabteilvorgang
-
Wird aus dem primären Storage geklont, wobei der Mandantenname der SID entspricht
-
Klonteilvorgang
Voraussetzungen und Einschränkungen
Die in den folgenden Abschnitten beschriebenen Workflows weisen einige Voraussetzungen und Einschränkungen hinsichtlich der SAP HANA-Systemarchitektur und der SnapCenter-Konfiguration auf.
-
Die beschriebenen Workflows gelten nur für die SnapCenter Version 5.0 oder höher.
-
Die beschriebenen Workflows gelten für SAP HANA MDC-Systeme mit einzelnen Hosts und mehreren Mandanten. SAP HANA Multiple Host-Systeme sind nicht abgedeckt.
-
Das SnapCenter SAP HANA Plug-in muss auf dem Ziel-Host implementiert werden, um die automatische Erkennung von SnapCenter und die Ausführung von Automatisierungsskripts zu ermöglichen.
-
Die Workflows gelten für SAP HANA-Systeme mit NFS oder FCP auf physischen Hosts oder für virtuelle Hosts, die in-Guest-NFS-Mounts verwenden.
Laboreinrichtung
Die Abbildung unten zeigt das Lab-Setup, das für die verschiedenen Optionen zur Systemaktualisierung verwendet wurde.
-
Klonen aus dem primären Storage oder externen Backup-Storage. Der Mandantenname entspricht der SID.
-
Quelle SAP HANA System: SS1 mit Mandant SS1
-
Ziel SAP HANA-System: QS1 mit Mandant QS1
-
-
Klonen aus dem primären Storage, mehrere Mandanten.
-
Quell-SAP HANA-System: SM1 mit Tenant1 und Tenant2
-
SAP HANA-Zielsystem: QS1 mit Tenant1 und Tenant2
-
Es wurden folgende Softwareversionen verwendet:
-
SnapCenter 5.0
-
SAP HANA Systeme: HANA 2.0 SPS7 Rev. 73
-
SLES 15
-
ONTAP 9.14P1
Alle SAP HANA-Systeme müssen auf Basis des Konfigurationsleitfadens konfiguriert werden "SAP HANA auf NetApp AFF Systemen mit NFS". SnapCenter und die SAP HANA-Ressourcen wurden basierend auf dem Best Practice Guide konfiguriert "Technischer Bericht: SAP HANA Backup and Recovery with SnapCenter".
Erste, einmalige Vorbereitungsschritte
In einem ersten Schritt muss das SAP HANA Zielsystem innerhalb von SnapCenter konfiguriert sein.
-
Installation des SAP HANA-Zielsystems
-
Konfiguration des SAP HANA-Systems in SnapCenter wie in beschrieben "TR-4614: SAP HANA Backup and Recovery with SnapCenter"
-
Konfiguration des SAP HANA Datenbankbenutzers für SnapCenter-Backup-Vorgänge dieser Benutzer muss am Quell- und Zielsystem identisch sein.
-
Konfiguration des Schlüssels hdbuserstore für die <sid>-Lösung m mit obigem Backup-Benutzer. Wenn das Automatisierungsskript für die Wiederherstellung verwendet wird, muss der Schlüsselname <SID>-Ausschreiben Y sein
-
Implementierung des SnapCenter SAP HANA Plug-ins auf dem Ziel-Host. Das SAP HANA-System wird von SnapCenter automatisch erkannt.
-
Konfiguration des SAP HANA-Ressourcenschutzes (optional)
-
Der erste SAP-Systemaktualisierungsvorgang nach der Erstinstallation wird mit den folgenden Schritten vorbereitet:
-
Herunterfahren des Ziel-SAP HANA-Systems
-
SAP HANA-Datenvolumen unmounten.
Sie müssen die Skripte, die auf dem Zielsystem ausgeführt werden sollen, der Konfigurationsdatei „SnapCenter allowed commands“ hinzufügen.
hana-7:/opt/NetApp/snapcenter/scc/etc # cat /opt/NetApp/snapcenter/scc/etc/allowed_commands.config command: mount command: umount command: /mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh hana-7:/opt/NetApp/snapcenter/scc/etc #
Klonen vom primären Storage mit dem Mandantennamen SID
In diesem Abschnitt wird der Workflow zur Systemaktualisierung von SAP HANA beschrieben, bei dem der Mandantenname am Quell- und Zielsystem mit der SID identisch ist. Das Klonen des Storage wird im Primärspeicher durchgeführt und die Recovery wird mit dem Skript automatisiert sc-system-refresh.sh.
Der Workflow besteht aus den folgenden Schritten:
-
Wenn die SAP HANA-Persistenz-Verschlüsselung im Quellsystem aktiviert ist, müssen die Verschlüsselungsroot-Schlüssel einmal importiert werden. Ein Import ist auch erforderlich, wenn die Schlüssel im Quellsystem geändert wurden. Siehe Kapitel "„Considerations for SAP HANA System Refresh Operations using Storage Snapshot Backups“"
-
Wurde das SAP HANA-Zielsystem in SnapCenter geschützt, so muss zunächst der Schutz entfernt werden.
-
Workflow zur Erstellung von SnapCenter Klonen
-
Wählen Sie Snapshot Backup aus dem SAP HANA-Quellsystem SS1 aus.
-
Wählen Sie den Zielhost aus, und stellen Sie die Speichernetzwerk-Schnittstelle des Zielhosts bereit.
-
Geben Sie SID des Zielsystems, in unserem Beispiel QS1
-
Stellen Sie optional ein Skript für die Wiederherstellung als Post-Clone-Vorgang bereit.
-
-
Klonvorgang für SnapCenter:
-
Erstellt ein FlexClone Volume basierend auf ausgewähltem Snapshot Backup des SAP HANA Quellsystems.
-
Exportiert das FlexClone Volume zur Ziel-Host-Storage-Netzwerkschnittstelle oder Initiatorgruppe.
-
Mount-Vorgang wird von FlexClone Volume auf dem Ziel-Host gemountet.
-
Führt ein Wiederherstellungsskript für Vorgänge nach dem Klonen aus, falls zuvor konfiguriert. Andernfalls muss das Recovery manuell durchgeführt werden, wenn der SnapCenter Workflow abgeschlossen ist.
-
Recovery der Systemdatenbank
-
Wiederherstellung der Mandantendatenbank mit Mandantenname = QS1.
-
-
-
Optional können Sie die SAP HANA-Zielressource in SnapCenter schützen.
Die folgenden Screenshots zeigen die erforderlichen Schritte.
-
Wählen Sie eine Snapshot-Sicherung aus dem Quellsystem SS1 aus, und klicken Sie auf Klonen.
-
Wählen Sie den Host aus, auf dem das Zielsystem QS1 installiert ist. QS1 als Ziel-SID eingeben. Die NFS-Export-IP-Adresse muss die Speichernetzwerk-Schnittstelle des Ziel-Hosts sein.
Die eingegebene Ziel-SID steuert, wie SnapCenter die geklonte Ressource verwaltet. Wenn eine Ressource mit der Ziel-SID bereits in SnapCenter konfiguriert ist und mit dem Plug-in-Host übereinstimmt, weist SnapCenter dieser Ressource einfach den Klon zu. Wenn die SID nicht auf dem Ziel-Host konfiguriert ist, erstellt SnapCenter eine neue Ressource.
Es ist wichtig, dass die Zielsystemressource und der Host vor dem Starten des Klon-Workflows in SnapCenter konfiguriert wurden. Andernfalls unterstützt die neue von SnapCenter erstellte Ressource keine automatische Erkennung, und die beschriebenen Workflows funktionieren nicht.
Bei einer Fibre-Channel-SAN-Einrichtung ist keine Export-IP-Adresse erforderlich, Sie müssen jedoch im nächsten Bildschirm das verwendete Protokoll angeben.
|
|
Die Screenshots zeigen ein anderes Lab-Setup mit einer FibreChannel-Konnektivität. |
Mit Azure NetApp Files und einem manuellen QoS-Kapazitäts-Pool müssen Sie den maximalen Durchsatz für das neue Volume erzielen. Stellen Sie sicher, dass der Kapazitäts-Pool über genügend Reserven verfügt, sonst schlägt der Klon-Workflow fehl.
|
|
Die Screenshots zeigen ein anderes Lab Setup, das in Microsoft Azure mit Azure NetApp Files läuft. |
-
Geben Sie die optionalen Post-Clone-Skripte mit den erforderlichen Befehlszeilenoptionen ein. In unserem Beispiel verwenden wir ein Post-Clone-Skript, um die SAP HANA Datenbank-Recovery auszuführen.
|
|
Wie bereits besprochen, ist die Verwendung des Wiederherstellungsskripts optional. Die Wiederherstellung kann auch manuell durchgeführt werden, nachdem der SnapCenter Klon-Workflow abgeschlossen ist. |
|
|
Das Skript für den Wiederherstellungsvorgang stellt die SAP HANA-Datenbank mithilfe des Vorgangs „Clear Logs“ auf den Zeitpunkt des Snapshots wieder her und führt keine Forward Recovery aus. Wenn eine Rückführung auf einen bestimmten Zeitpunkt erforderlich ist, muss die Wiederherstellung manuell durchgeführt werden. Eine manuelle vorwärts-Wiederherstellung erfordert außerdem, dass die Protokoll-Backups aus dem Quellsystem auf dem Ziel-Host verfügbar sind. |
-
Im Bildschirm Jobdetails in SnapCenter wird der Fortschritt des Vorgangs angezeigt. Die Job-Details zeigen außerdem, dass die Gesamtlaufzeit einschließlich Datenbank-Recovery weniger als 3 Minuten beträgt.
-
Die Protokolldatei des
sc-system-refreshSkripts zeigt die verschiedenen Schritte an, die für den Wiederherstellungsvorgang ausgeführt wurden. Das Skript liest die Liste der Mandanten aus der Systemdatenbank und führt eine Wiederherstellung aller vorhandenen Mandanten durch.
20240425112328###hana-7###sc-system-refresh.sh: Script version: 3.0 hana-7:/mnt/sapcc-share/SAP-System-Refresh # cat sap-system-refresh-QS1.log 20240425112328###hana-7###sc-system-refresh.sh: ******************* Starting script: recovery operation ************************** 20240425112328###hana-7###sc-system-refresh.sh: Recover system database. 20240425112328###hana-7###sc-system-refresh.sh: /usr/sap/QS1/HDB11/exe/Python/bin/python /usr/sap/QS1/HDB11/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG" 20240425112346###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is started .... 20240425112347###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425112357###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425112407###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425112417###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425112428###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425112438###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425112448###hana-7###sc-system-refresh.sh: Status: GREEN 20240425112448###hana-7###sc-system-refresh.sh: HANA system database started. 20240425112448###hana-7###sc-system-refresh.sh: Checking connection to system database. 20240425112448###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY 'select * from sys.m_databases;' DATABASE_NAME,DESCRIPTION,ACTIVE_STATUS,ACTIVE_STATUS_DETAILS,OS_USER,OS_GROUP,RESTART_MODE,FALLBACK_SNAPSHOT_CREATE_TIME "SYSTEMDB","SystemDB-QS1-11","YES","","","","DEFAULT",? "QS1","QS1-11","NO","ACTIVE","","","DEFAULT",? 2 rows selected (overall time 16.225 msec; server time 860 usec) 20240425112448###hana-7###sc-system-refresh.sh: Succesfully connected to system database. 20240425112449###hana-7###sc-system-refresh.sh: Tenant databases to recover: QS1 20240425112449###hana-7###sc-system-refresh.sh: Found inactive tenants(QS1) and starting recovery 20240425112449###hana-7###sc-system-refresh.sh: Recover tenant database QS1. 20240425112449###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR QS1 USING SNAPSHOT CLEAR LOG 0 rows affected (overall time 22.138599 sec; server time 22.136268 sec) 20240425112511###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant QS1. 20240425112511###hana-7###sc-system-refresh.sh: Recovery of tenant database QS1 succesfully finished. 20240425112511###hana-7###sc-system-refresh.sh: Status: GREEN 20240425112511###hana-7###sc-system-refresh.sh: ******************* Finished script: recovery operation ************************** hana-7:/mnt/sapcc-share/SAP-System-Refresh
-
Nach Abschluss des SnapCenter-Jobs ist der Klon in der Topologieansicht des Quellsystems sichtbar.
-
Die SAP HANA Datenbank läuft nun.
-
Wenn Sie das Ziel-SAP HANA-System schützen möchten, müssen Sie die automatische Erkennung ausführen, indem Sie auf die Zielsystemressource klicken.
Wenn der automatische Erkennungsprozess abgeschlossen ist, wird das neue geklonte Volume im Abschnitt „Storage-Platzbedarf“ aufgeführt.
Durch erneutes Klicken auf die Ressource kann der Datenschutz für das aktualisierte QS1-System konfiguriert werden.
Klonen aus standortexternen Backup-Storage
In diesem Abschnitt wird der Workflow zur Systemaktualisierung von SAP HANA beschrieben, bei dem der Mandantenname am Quell- und Zielsystem mit der SID identisch ist. Das Klonen von Speichern wird im externen Backup-Speicher ausgeführt und wird mithilfe des Skripts sc-System-refresh.sh weiter automatisiert.
Der einzige Unterschied im Workflow der SAP HANA Systemaktualisierung zwischen dem Klonen des primären und externen Backup-Storage ist die Auswahl des Snapshot Backups in SnapCenter. Für das Klonen von Backup-Storage außerhalb des Standorts müssen zunächst die sekundären Backups und anschließend die Auswahl des Snapshot-Backups ausgewählt werden.
Wenn mehrere sekundäre Speicherorte für das ausgewählte Backup vorhanden sind, müssen Sie das erforderliche Zielvolume auswählen.
Alle nachfolgenden Schritte sind mit dem Workflow zum Klonen aus dem Primärspeicher identisch.
Klonen eines SAP HANA Systems mit mehreren Mandanten
In diesem Abschnitt wird der Workflow zur Aktualisierung des SAP HANA-Systems mit mehreren Mandanten beschrieben. Das Klonen von Storage wird im Primär-Storage durchgeführt und weitere automatisiert mithilfe des Skripts sc-system-refresh.sh.
Die erforderlichen Schritte in SnapCenter sind identisch mit den Schritten, die im Abschnitt „Klonen von primärem Storage mit Mandantenname gleich SID“ beschrieben wurden. Der einzige Unterschied besteht in der Wiederherstellung des Mandanten innerhalb des Skripts sc-system-refresh.sh, wo alle Mandanten wiederhergestellt werden.
20240430070214###hana-7###sc-system-refresh.sh: **********************************************************************************
20240430070214###hana-7###sc-system-refresh.sh: Script version: 3.0
20240430070214###hana-7###sc-system-refresh.sh: ******************* Starting script: recovery operation **************************
20240430070214###hana-7###sc-system-refresh.sh: Recover system database.
20240430070214###hana-7###sc-system-refresh.sh: /usr/sap/QS1/HDB11/exe/Python/bin/python /usr/sap/QS1/HDB11/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG"
[140310725887808, 0.008] >> starting recoverSys (at Tue Apr 30 07:02:15 2024)
[140310725887808, 0.008] args: ()
[140310725887808, 0.008] keys: \{'command': 'RECOVER DATA USING SNAPSHOT CLEAR LOG'}
using logfile /usr/sap/QS1/HDB11/hana-7/trace/backup.log
recoverSys started: ============2024-04-30 07:02:15 ============
testing master: hana-7
hana-7 is master
shutdown database, timeout is 120
stop system
stop system on: hana-7
stopping system: 2024-04-30 07:02:15
stopped system: 2024-04-30 07:02:15
creating file recoverInstance.sql
restart database
restart master nameserver: 2024-04-30 07:02:20
start system: hana-7
sapcontrol parameter: ['-function', 'Start']
sapcontrol returned successfully:
2024-04-30T07:02:32-04:00 P0023828 18f2eab9331 INFO RECOVERY RECOVER DATA finished successfully
recoverSys finished successfully: 2024-04-30 07:02:33
[140310725887808, 17.548] 0
[140310725887808, 17.548] << ending recoverSys, rc = 0 (RC_TEST_OK), after 17.540 secs
20240430070233###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is started ....
20240430070233###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070243###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070253###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070304###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070314###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070314###hana-7###sc-system-refresh.sh: HANA system database started.
20240430070314###hana-7###sc-system-refresh.sh: Checking connection to system database.
20240430070314###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY 'select * from sys.m_databases;'
20240430070314###hana-7###sc-system-refresh.sh: Succesfully connected to system database.
20240430070314###hana-7###sc-system-refresh.sh: Tenant databases to recover: TENANT2
TENANT1
20240430070314###hana-7###sc-system-refresh.sh: Found inactive tenants(TENANT2
TENANT1) and starting recovery
20240430070314###hana-7###sc-system-refresh.sh: Recover tenant database TENANT2.
20240430070314###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR TENANT2 USING SNAPSHOT CLEAR LOG
20240430070335###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant TENANT2.
20240430070335###hana-7###sc-system-refresh.sh: Recovery of tenant database TENANT2 succesfully finished.
20240430070335###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070335###hana-7###sc-system-refresh.sh: Recover tenant database TENANT1.
20240430070335###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR TENANT1 USING SNAPSHOT CLEAR LOG
20240430070349###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant TENANT1.
20240430070350###hana-7###sc-system-refresh.sh: Recovery of tenant database TENANT1 succesfully finished.
20240430070350###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070350###hana-7###sc-system-refresh.sh: ******************* Finished script: recovery operation **************************
Klonvorgang
Ein neuer Vorgang zur Systemaktualisierung von SAP HANA wird gestartet, indem das Zielsystem mithilfe des SnapCenter-Klonlösch-Vorgangs gereinigt wird.
Wurde das SAP HANA-Zielsystem in SnapCenter geschützt, so muss zunächst der Schutz entfernt werden. Klicken Sie in der Topologieansicht des Zielsystems auf Schutz entfernen.
Der Clone delete Workflow wird nun mit den folgenden Schritten ausgeführt.
-
Wählen Sie den Klon in der Topologieansicht des Quellsystems aus, und klicken Sie auf Löschen.
-
Geben Sie die Skripte vor dem Klonen ein und heben Sie die Bereitstellung mit den erforderlichen Befehlszeilenoptionen ab.
-
Der Bildschirm „Jobdetails“ in SnapCenter zeigt den Fortschritt des Vorgangs an.
-
Die Protokolldatei des
sc-system-refreshSkripts zeigt die Schritte zum Herunterfahren und Unmounten an.
20240425111042###hana-7###sc-system-refresh.sh: ********************************************************************************** 20240425111042###hana-7###sc-system-refresh.sh: Script version: 3.0 20240425111042###hana-7###sc-system-refresh.sh: ******************* Starting script: shutdown operation ************************** 20240425111042###hana-7###sc-system-refresh.sh: Stopping HANA database. 20240425111042###hana-7###sc-system-refresh.sh: sapcontrol -nr 11 -function StopSystem HDB 25.04.2024 11:10:42 StopSystem OK 20240425111042###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is stopped .... 20240425111042###hana-7###sc-system-refresh.sh: Status: GREEN 20240425111052###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425111103###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425111113###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425111123###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425111133###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425111144###hana-7###sc-system-refresh.sh: Status: YELLOW 20240425111154###hana-7###sc-system-refresh.sh: Status: GRAY 20240425111154###hana-7###sc-system-refresh.sh: SAP HANA database is stopped. 20240425111154###hana-7###sc-system-refresh.sh: ******************* Finished script: shutdown operation **************************
-
Der SAP HANA-Aktualisierungsvorgang kann nun mithilfe des SnapCenter-Klonerstellung erneut gestartet werden.
SAP HANA Systemaktualisierung mit Klonteilvorgang
Ist die Verwendung des Zielsystems für die Systemaktualisierung über einen längeren Zeitraum geplant, ist es sinnvoll, das FlexClone Volume im Rahmen der Systemaktualisierung zu teilen.
|
|
Der Aufspaltung von Klonen blockiert nicht die Verwendung des geklonten Volume und kann somit jederzeit ausgeführt werden, während die SAP HANA Datenbank verwendet wird. |
|
|
Bei Azure NetApp Files ist der Aufspaltung von Klonen nicht verfügbar, da Azure NetApp Files den Klon nach der Erstellung immer teilt. |
Der Clone Split Workflow in SnapCenter wird in der Topologieansicht des Quellsystems initiiert, indem der Klon ausgewählt und auf Clone Split geklickt wird.
Im nächsten Bildschirm wird eine Vorschau angezeigt, die Informationen zur erforderlichen Kapazität für das geteilte Volumen liefert.
Das Jobprotokoll von SnapCenter zeigt den Status des Klonabteilvorgangs an.
In der Ressourcenansicht in SnapCenter wird das Zielsystem QS1 nun nicht mehr als geklonte Ressource markiert. Wenn der Klon zurück zur Topologieansicht des Quellsystems angezeigt wird, ist er nicht mehr sichtbar. Das Split-Volume ist jetzt unabhängig vom Snapshot Backup des Quellsystems.
Der Aktualisierungs-Workflow nach einem Klonteilvorgang sieht etwas anders aus als der Vorgang ohne Klontrennung. Nach einer Klonaufteilung ist kein Klonvorgang erforderlich, da es sich beim Zieldatenvolume nicht mehr um ein FlexClone Volume handelt.
Der Workflow besteht aus den folgenden Schritten:
-
Wurde das SAP HANA-Zielsystem in SnapCenter geschützt, so muss zunächst der Schutz entfernt werden.
-
Die SAP HANA Datenbank muss heruntergefahren, das Daten-Volume abgehängt und der von SnapCenter erstellte fstab Eintrag entfernt werden. Diese Schritte müssen manuell ausgeführt werden.
-
Der Workflow zur Erstellung von SnapCenter Klonen kann nun wie in den vorherigen Abschnitten beschrieben ausgeführt werden.
-
Nach dem Aktualisierungsvorgang ist das alte Zieldatenvolume noch vorhanden und muss manuell mit z.B. dem ONTAP-Systemmanager gelöscht werden.
SnapCenter Workflow-Automatisierung mit PowerShell Skripten
In den vorherigen Abschnitten wurden die verschiedenen Workflows über die UI von SnapCenter ausgeführt. Alle Workflows können auch mit PowerShell-Skripten oder REST-API-Aufrufen ausgeführt werden, was eine weitere Automatisierung ermöglicht. In den folgenden Abschnitten werden die grundlegenden Beispiele für PowerShell-Skripts für die folgenden Workflows beschrieben.
-
Erstellen von Klonen
-
Klon löschen
Die Beispielskripte werden wie IS bereitgestellt und von NetApp nicht unterstützt.
Alle Skripte müssen in einem PowerShell Befehlsfenster ausgeführt werden. Bevor die Skripte ausgeführt werden können, muss mithilfe der eine Verbindung zum SnapCenter-Server hergestellt werden Open-SmConnection Befehl.
Erstellen von Klonen
Das einfache Skript unten zeigt, wie eine SnapCenter Klonerstellung mithilfe von PowerShell Befehlen ausgeführt werden kann. Das SnapCenter New-SmClone Der Befehl wird mit der erforderlichen Befehlszeilenoption für die Lab-Umgebung und dem zuvor erläuterten Automatisierungsskript ausgeführt.
$BackupName='SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
$JobInfo=New-SmClone -AppPluginCode hana -BackupName $BackupName -Resources @\{"Host"="hana-1.sapcc.stl.netapp.com";"UID"="MDC\SS1"} -CloneToInstance hana-7.sapcc.stl.netapp.com -postclonecreatecommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh recover' -NFSExportIPs 192.168.175.75 -CloneUid 'MDC\QS1'
# Get JobID of clone create job
$Job=Get-SmJobSummaryReport | ?\{$_.JobType -eq "Clone" } | ?\{$_.JobName -Match $BackupName} | ?\{$_.Status -eq "Running"}
$JobId=$Job.SmJobId
Get-SmJobSummaryReport -JobId $JobId
# Wait until job is finished
do \{ $Job=Get-SmJobSummaryReport -JobId $JobId; write-host $Job.Status; sleep 20 } while ( $Job.Status -Match "Running" )
Write-Host " "
Get-SmJobSummaryReport -JobId $JobId
Write-Host "Clone create job has been finshed."
Die Bildschirmausgabe zeigt die Ausführung des PowerShell-Skripts Clone erstellen.
PS C:\Windows\system32> C:\NetApp\clone-create.ps1 SmJobId : 110382 JobCreatedDateTime : JobStartDateTime : 6/26/2024 9:55:34 AM JobEndDateTime : JobDuration : JobName : Clone from backup 'SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458' JobDescription : Status : Running IsScheduled : False JobError : JobType : Clone PolicyName : JobResultData : Running Running Running Running Running Running Running Running Running Running Completed SmJobId : 110382 JobCreatedDateTime : JobStartDateTime : 6/26/2024 9:55:34 AM JobEndDateTime : 6/26/2024 9:58:50 AM JobDuration : 00:03:16.6889170 JobName : Clone from backup 'SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458' JobDescription : Status : Completed IsScheduled : False JobError : JobType : Clone PolicyName : JobResultData : Clone create job has been finshed.
Klon löschen
Das einfache Skript unten zeigt, wie eine SnapCenter Klonlösch-Operation mit PowerShell Befehlen ausgeführt werden kann. Das SnapCenter Remove-SmClone Der Befehl wird mit der erforderlichen Befehlszeilenoption für die Lab-Umgebung und dem zuvor erläuterten Automatisierungsskript ausgeführt.
$CloneInfo=Get-SmClone |?\{$_.CloneName -Match "hana-1_sapcc_stl_netapp_com_hana_MDC_SS1" }
$JobInfo=Remove-SmClone -CloneName $CloneInfo.CloneName -PluginCode hana -PreCloneDeleteCommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh shutdown QS1' -UnmountCommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh umount QS1' -Confirm: $False
Get-SmJobSummaryReport -JobId $JobInfo.Id
# Wait until job is finished
do \{ $Job=Get-SmJobSummaryReport -JobId $JobInfo.Id; write-host $Job.Status; sleep 20 } while ( $Job.Status -Match "Running" )
Write-Host " "
Get-SmJobSummaryReport -JobId $JobInfo.Id
Write-Host "Clone delete job has been finshed."
PS C:\NetApp>
In der Bildschirmausgabe wird die Ausführung des PowerShell-Skripts Clone –delete.ps1 angezeigt.
PS C:\Windows\system32> C:\NetApp\clone-delete.ps1 SmJobId : 110386 JobCreatedDateTime : JobStartDateTime : 6/26/2024 10:01:33 AM JobEndDateTime : JobDuration : JobName : Deleting clone 'hana-1_sapcc_stl_netapp_com_hana_MDC_SS1__clone__110382_MDC_SS1_04-22-2024_09.54.34' JobDescription : Status : Running IsScheduled : False JobError : JobType : DeleteClone PolicyName : JobResultData : Running Running Running Running Completed SmJobId : 110386 JobCreatedDateTime : JobStartDateTime : 6/26/2024 10:01:33 AM JobEndDateTime : 6/26/2024 10:02:38 AM JobDuration : 00:01:05.5658860 JobName : Deleting clone 'hana-1_sapcc_stl_netapp_com_hana_MDC_SS1__clone__110382_MDC_SS1_04-22-2024_09.54.34' JobDescription : Status : Completed IsScheduled : False JobError : JobType : DeleteClone PolicyName : JobResultData : Clone delete job has been finshed. PS C:\Windows\system32>