SAP Systemklon mit SnapCenter
Dieser Abschnitt enthält eine Schritt-für-Schritt-Beschreibung für den SAP-Systemklonvorgang, mit der ein Reparatursystem zur Beseitigung logischer Beschädigung eingerichtet werden kann.
Die SAP Applikations-Services werden nicht im Labor eingerichtet und validiert. In der Dokumentation werden jedoch die erforderlichen Schritte für SAP-Anwendungsservices hervorgehoben. |
Voraussetzungen und Einschränkungen
Die in den folgenden Abschnitten beschriebenen Workflows weisen einige Voraussetzungen und Einschränkungen hinsichtlich der HANA-Systemarchitektur und der SnapCenter-Konfiguration auf.
-
Der beschriebene Workflow gilt für SAP HANA MDC-Systeme mit einem einzelnen Host und einem Mandanten.
-
Das SnapCenter HANA Plug-in muss auf dem Ziel-Host implementiert werden, um die Ausführung von Automatisierungsskripts zu ermöglichen. Es ist nicht erforderlich, das HANA-Plug-in auf dem HANA-Quell-System-Host zu installieren.
-
Der Workflow wurde für NFS validiert. Das Automatisierungsskript
sc-mount-volume.sh
, Das zum Mounten des HANA Shared Volume verwendet wird, unterstützt kein FCP. Dieser Schritt muss entweder manuell oder durch erweitern des Skripts durchgeführt werden. -
Der beschriebene Workflow gilt nur für SnapCenter 4.6 P1 oder höher. Ältere Versionen weisen leicht unterschiedliche Workflows auf.
Laboreinrichtung
Die folgende Abbildung zeigt die Lab-Einrichtung, die für einen Systemklonvorgang verwendet wird.
Es wurden folgende Softwareversionen verwendet:
-
SnapCenter 4 6 P1
-
HANA-Systeme: HANA 2.0 SPS6 Rev
-
VMware 6.7.0
-
SLES 15 SP2
-
ONTAP 9.7P7Alle HANA-Systeme wurden anhand des Konfigurationsleitfadens konfiguriert "SAP HANA auf NetApp AFF Systemen mit NFS". SnapCenter- und HANA-Ressourcen wurden basierend auf dem Best Practice-Leitfaden konfiguriert "Technischer Bericht: SAP HANA Backup and Recovery with SnapCenter".
Vorbereitung des Ziel-Hosts
In diesem Abschnitt werden die Vorbereitungsschritte beschrieben, die auf einem Server erforderlich sind, der als Systemklonziel verwendet wird.
Im normalen Betrieb kann der Zielhost für andere Zwecke verwendet werden, beispielsweise als HANA QA- oder Testsystem. Daher müssen die meisten der beschriebenen Schritte ausgeführt werden, wenn der Systemklonvorgang angefordert wird. Zum anderen die relevanten Konfigurationsdateien, wie /etc/fstab
Und /usr/sap/sapservices
, Kann vorbereitet und dann in die Produktion einfach durch Kopieren der Konfigurationsdatei.
Die Vorbereitung des Ziel-Hosts umfasst auch das Herunterfahren des HANA QA- oder Testsystems.
Hostname und IP-Adresse des Zielservers
Der Hostname des Zielservers muss mit dem Hostnamen des Quellsystems identisch sein. Die IP-Adresse kann unterschiedlich sein.
Ein ordnungsgemäßes Fechten des Zielservers muss eingerichtet werden, damit er nicht mit anderen Systemen kommunizieren kann. Wenn kein ordnungsgemäßes Fechten vorhanden ist, kann das geklonte Produktionssystem Daten mit anderen Produktionssystemen austauschen. |
In unserem Labor-Setup haben wir den Hostnamen des Zielsystems nur intern aus der Perspektive des Zielsystems geändert. Extern war der Host immer noch mit dem Hostnamen hana-7 zugänglich. Bei der Anmeldung beim Host ist der Host selbst hana-1. |
Installieren Sie die erforderliche Software
Die SAP-Hostagent-Software muss auf dem Zielserver installiert sein. Ausführliche Informationen finden Sie im "SAP Host Agent" Im SAP-Hilfeportal.
Das SnapCenter HANA Plug-in muss auf dem Ziel-Host mithilfe der Add-Host-Operation in SnapCenter implementiert werden.
Konfiguration von Benutzern, Ports und SAP-Diensten
Die erforderlichen Anwender und Gruppen für die SAP HANA-Datenbank müssen auf dem Zielserver verfügbar sein. In der Regel wird die zentrale Benutzerverwaltung verwendet. Daher sind keine Konfigurationsschritte auf dem Zielserver erforderlich. Die erforderlichen Ports für die HANA-Datenbank müssen auf den Ziel-Hosts konfiguriert sein. Die Konfiguration kann durch Kopieren des aus dem Quellsystem kopiert werden /etc/services
Datei auf dem Zielserver.
Die erforderlichen SAP Services-Einträge müssen auf dem Zielhost verfügbar sein. Die Konfiguration kann durch Kopieren des aus dem Quellsystem kopiert werden /usr/sap/sapservices
Datei auf dem Zielserver. Die folgende Ausgabe zeigt die erforderlichen Einträge für die im Lab-Setup verwendete SAP HANA-Datenbank.
#!/bin/sh LD_LIBRARY_PATH=/usr/sap/SS1/HDB00/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/SS1/HDB00/exe/sapstartsrv pf=/usr/sap/SS1/SYS/profile/SS1_HDB00_hana-1 -D -u ss1adm limit.descriptors=1048576
Vorbereiten des Protokoll- und Protokollvolumes
Da Sie das Protokoll-Volume nicht aus dem Quellsystem klonen müssen und eine Wiederherstellung mit der Option Protokoll löschen durchgeführt wird, muss ein leeres Protokoll-Volume auf dem Zielhost vorbereitet sein.
Da das Quellsystem mit einem separaten Protokoll-Backup-Volume konfiguriert wurde, muss ein leeres Protokoll-Backup-Volume vorbereitet und an denselben Bereitstellungspunkt wie am Quellsystem angehängt werden.
hana- 1:/# cat /etc/fstab 192.168.175.117:/SS1_repair_log_mnt00001 /hana/log/SS1/mnt00001 nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 192.168.175.117:/SS1_repair_log_backup /mnt/log-backup nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0
Innerhalb des Protokollvolumens hdb* müssen Sie Unterverzeichnisse auf die gleiche Weise erstellen wie beim Quellsystem.
hana- 1:/ # ls -al /hana/log/SS1/mnt00001/ total 16 drwxrwxrwx 5 root root 4096 Dec 1 06:15 . drwxrwxrwx 1 root root 16 Nov 30 08:56 .. drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:14 hdb00001 drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:15 hdb00002.00003 drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:15 hdb00003.00003
Innerhalb des Protokoll-Backup-Volumes müssen Sie Unterverzeichnisse für das System und die Mandantendatenbank erstellen.
hana- 1:/ # ls -al /mnt/log-backup/ total 12 drwxr-xr-x 4 root root 4096 Dec 1 04:48 . drwxr-xr-x 1 root root 48 Dec 1 03:42 .. drwxrwxrwx 2 root root 4096 Dec 1 06:15 DB_SS1 drwxrwxrwx 2 root root 4096 Dec 1 06:14 SYSTEMDB
Bereiten Sie Dateisystemeinhängungen vor
Die Mount-Punkte für die Daten und das freigegebene Volume müssen vorbereitet werden.
Mit unserem Beispiel die Verzeichnisse /hana/data/SS1/mnt00001
, /hana/shared
Und usr/sap/SS1
Muss erstellt werden.
Vorbereiten der SID-spezifischen Konfigurationsdatei für SnapCenter-Skript
Sie müssen die Konfigurationsdatei für das SnapCenter-Automatisierungsskript erstellen sc-system-refresh.sh
.
hana- 1:/mnt/sapcc-share/SAP-System-Refresh # cat sc-system-refresh-SS1.cfg # --------------------------------------------- # Target database specific parameters # --------------------------------------------- # hdbuserstore key, which should be used to connect to the target database KEY="SS1KEY" # Used storage protocol, NFS or FCP PROTOCOL
Klonen des gemeinsamen HANA Volumes
-
Wählen Sie eine Snapshot-Sicherung aus dem freigegebenen SS1-Quellvolume des Quellsystems aus, und klicken Sie auf Klonen aus Sicherung.
-
Wählen Sie den Host aus, auf dem das Ziel-Reparatursystem vorbereitet wurde. Die NFS-Export-IP-Adresse muss die Speichernetzwerk-Schnittstelle des Ziel-Hosts sein. Als Ziel-SID halten die gleiche SID wie das Quellsystem; in unserem Beispiel ist dies SS1.
-
Geben Sie das Mount-Skript mit den erforderlichen Befehlszeilenoptionen ein.
Das HANA-System verwendet für einzelne Volumes /hana/shared `as well as for `/usr/sap/SS1
, Wie im Konfigurationsleitfaden empfohlen in Unterverzeichnissen getrennt "SAP HANA auf NetApp AFF Systemen mit NFS". Das Skriptsc-mount-volume.sh
Unterstützt diese Konfiguration mit einer speziellen Befehlszeilenoption für den Mount-Pfad. Wenn die Befehlszeilenoption Mount Path gleich istusr-sap-and-shared
, Das Skript mountet die Unterverzeichnisseshared
Undusr-sap
Entsprechend im Volumen. -
Der Bildschirm „Jobdetails“ in SnapCenter zeigt den Fortschritt des Vorgangs an.
-
Die Logdatei des
sc- mount-volume.sh
Skript zeigt die verschiedenen Schritte, die für den Mount-Vorgang ausgeführt werden.20201201041441###hana-1###sc-mount-volume.sh: Adding entry in /etc/fstab. 20201201041441###hana-1###sc-mount-volume.sh: 192.168.175.117://SS1_shared_Clone_05132205140448713/usr-sap /usr/sap/SS1 nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 20201201041441###hana-1###sc-mount-volume.sh: Mounting volume: mount /usr/sap/SS1. 20201201041441###hana-1###sc-mount-volume.sh: 192.168.175.117: /SS1_shared_Clone_05132205140448713/shared /hana/shared nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 20201201041441###hana-1###sc-mount-volume.sh: Mounting volume: mount /hana/shared. 20201201041441###hana-1###sc-mount-volume.sh: usr-sap-and-shared mounted successfully. 20201201041441###hana-1###sc-mount-volume.sh: Change ownership to ss1adm.
-
Wenn der SnapCenter-Workflow abgeschlossen ist, wird das angezeigt
usr/sap/SS1
Und das/hana/shared
Dateisysteme werden auf dem Zielhost angehängt.hana-1:~ # df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.175.117:/SS1_repair_log_mnt00001 262144000 320 262143680 1% /hana/log/SS1/mnt00001 192.168.175.100:/sapcc_share 1020055552 53485568 966569984 6% /mnt/sapcc-share 192.168.175.117:/SS1_repair_log_backup 104857600 256 104857344 1% /mnt/log-backup 192.168.175.117: /SS1_shared_Clone_05132205140448713/usr-sap 262144064 10084608 252059456 4% /usr/sap/SS1 192.168.175.117: /SS1_shared_Clone_05132205140448713/shared 262144064 10084608 252059456 4% /hana/shared
-
Innerhalb von SnapCenter ist eine neue Ressource für das geklonte Volume sichtbar.
-
Nun das
/hana/shared
Volume ist verfügbar, der SAP HANA Service kann gestartet werden.hana-1:/mnt/sapcc-share/SAP-System-Refresh # systemctl start sapinit
-
Die SAP Host Agent und sapstartsrv Prozesse werden nun gestartet.
hana-1:/mnt/sapcc-share/SAP-System-Refresh # ps -ef |grep sap root 12377 1 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile sapadm 12403 1 0 04:34 ? 00:00:00 /usr/lib/systemd/systemd --user sapadm 12404 12403 0 04:34 ? 00:00:00 (sd-pam) sapadm 12434 1 1 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D root 12485 12377 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile root 12486 12485 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile ss1adm 12504 1 0 04:34 ? 00:00:00 /usr/sap/SS1/HDB00/exe/sapstartsrv pf=/usr/sap/SS1/SYS/profile/SS1_HDB00_hana-1 -D -u ss1adm root 12582 12486 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile root 12585 7613 0 04:34 pts/0 00:00:00 grep --color=auto sap hana-1:/mnt/sapcc-share/SAP-System-Refresh #
Klonen zusätzlicher SAP Applikationsservices
Zusätzliche SAP-Anwendungsservices werden auf die gleiche Weise wie das gemeinsam genutzte SAP HANA-Volume geklont, wie im Abschnitt „ beschriebenKlonen des gemeinsamen HANA Volumes.“ Selbstverständlich müssen auch die benötigten Speichervolumen(en) der SAP-Applikationsserver durch SnapCenter geschützt werden.
Sie müssen die erforderlichen Diensteinträge zu hinzufügen /usr/sap/sapservices
, Und die Ports, Benutzer und die Dateisysteme-Mount-Punkte (z. B. /usr/sap/SID
) Muss vorbereitet werden.
Klonen des Daten-Volumes und Recovery der HANA Datenbank
-
Wählen Sie ein HANA Snapshot Backup aus dem Quellsystem SS1 aus.
-
Wählen Sie den Host aus, auf dem das Ziel-Reparatursystem vorbereitet wurde. Die NFS-Export-IP-Adresse muss die Speichernetzwerk-Schnittstelle des Ziel-Hosts sein. Ein Ziel-SID hält dieselbe SID wie das Quellsystem, in unserem Beispiel ist dies SS1.
-
Geben Sie die Mount- und Post-Clone-Skripte mit den erforderlichen Befehlszeilenoptionen ein.
Das Skript für den Recovery-Vorgang stellt die HANA-Datenbank auf den Zeitpunkt der Snapshot-Operation wieder her und führt keine Forward Recovery durch. 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.
Der Bildschirm „Jobdetails“ in SnapCenter zeigt den Fortschritt des Vorgangs an.
Die Logdatei des sc-system-refresh.sh
Skript zeigt die verschiedenen Schritte, die für den Mount und den Wiederherstellungsvorgang ausgeführt werden.
20201201052114###hana-1###sc-system-refresh.sh: Adding entry in /etc/fstab. 20201201052114###hana-1###sc-system-refresh.sh: 192.168.175.117:/SS1_data_mnt00001_Clone_0421220520054605 /hana/data/SS1/mnt00001 nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 20201201052114###hana-1###sc-system-refresh.sh: Mounting data volume: mount /hana/data/SS1/mnt00001. 20201201052114###hana-1###sc-system-refresh.sh: Data volume mounted successfully. 20201201052114###hana-1###sc-system-refresh.sh: Change ownership to ss1adm. 20201201052124###hana-1###sc-system-refresh.sh: Recover system database. 20201201052124###hana-1###sc-system-refresh.sh: /usr/sap/SS1/HDB00/exe/Python/bin/python /usr/sap/SS1/HDB00/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG" 20201201052156###hana-1###sc-system-refresh.sh: Wait until SAP HANA database is started .... 20201201052156###hana-1###sc-system-refresh.sh: Status: GRAY 20201201052206###hana-1###sc-system-refresh.sh: Status: GREEN 20201201052206###hana-1###sc-system-refresh.sh: SAP HANA database is started. 20201201052206###hana-1###sc-system-refresh.sh: Source system has a single tenant and tenant name is identical to source SID: SS1 20201201052206###hana-1###sc-system-refresh.sh: Target tenant will have the same name as target SID: SS1. 20201201052206###hana-1###sc-system-refresh.sh: Recover tenant database SS1. 20201201052206###hana-1###sc-system-refresh.sh: /usr/sap/SS1/SYS/exe/hdb/hdbsql -U SS1KEY RECOVER DATA FOR SS1 USING SNAPSHOT CLEAR LOG 0 rows affected (overall time 34.773885 sec; server time 34.772398 sec) 20201201052241###hana-1###sc-system-refresh.sh: Checking availability of Indexserver for tenant SS1. 20201201052241###hana-1###sc-system-refresh.sh: Recovery of tenant database SS1 succesfully finished. 20201201052241###hana-1###sc-system-refresh.sh: Status: GREEN
Nach dem Mount- und Recovery-Vorgang wird das HANA-Daten-Volume auf dem Ziel-Host gemountet.
hana-1:/mnt/log-backup # df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.175.117:/SS1_repair_log_mnt00001 262144000 760320 261383680 1% /hana/log/SS1/mnt00001 192.168.175.100:/sapcc_share 1020055552 53486592 966568960 6% /mnt/sapcc-share 192.168.175.117:/SS1_repair_log_backup 104857600 512 104857088 1% /mnt/log-backup 192.168.175.117: /SS1_shared_Clone_05132205140448713/usr-sap 262144064 10090496 252053568 4% /usr/sap/SS1 192.168.175.117: /SS1_shared_Clone_05132205140448713/shared 262144064 10090496 252053568 4% /hana/shared 192.168.175.117:/SS1_data_mnt00001_Clone_0421220520054605 262144064 3732864 258411200 2% /hana/data/SS1/mnt00001
Das HANA-System ist jetzt verfügbar und kann beispielsweise als Reparatursystem genutzt werden.