Et des meilleures pratiques
Clone du système SAP avec SnapCenter
Suggérer des modifications
PDF
Cette section fournit une description détaillée de l'opération de clonage du système SAP, qui peut être utilisée pour configurer un système de réparation afin de résoudre la corruption logique.
|
La configuration et la validation du laboratoire ne comprennent pas les services d'application SAP. Toutefois, les étapes requises pour les services d'application SAP sont mises en évidence dans la documentation. |
Conditions préalables et limites
Les workflows décrits dans les sections suivantes présentent quelques conditions préalables et limites relatives à l'architecture du système HANA et à la configuration SnapCenter.
-
Le flux de travail décrit est valide pour les systèmes MDC SAP HANA à hôte unique avec un seul locataire.
-
Le plug-in SnapCenter HANA doit être déployé sur l'hôte cible pour permettre l'exécution de scripts d'automatisation. Il n'est pas nécessaire d'installer le plug-in HANA sur l'hôte du système source HANA.
-
Le workflow a été validé pour NFS. Le script d'automatisation
sc-mount-volume.sh, Qui est utilisé pour monter le volume partagé HANA, ne prend pas en charge FCP. Cette étape doit être effectuée manuellement ou en étendant le script. -
Le workflow décrit n'est valide que pour la version SnapCenter 4.6 P1 ou ultérieure. Les versions plus anciennes ont des flux de travail légèrement différents.
Configuration de laboratoire
La figure suivante présente la configuration de laboratoire utilisée pour une opération de clonage du système.
Les versions logicielles suivantes ont été utilisées :
-
SnapCenter 4. 6 P1
-
Systèmes HANA : HANA 2.0 SPS6 rév.61
-
VMware 6.7.0
-
SLES 15 SP2
-
ONTAP 9.7P7All les systèmes HANA ont été configurés en fonction du guide de configuration "SAP HANA sur les systèmes AFF de NetApp avec NFS". Les ressources SnapCenter et HANA ont été configurées conformément au guide des meilleures pratiques "SAP HANA : sauvegarde et restauration avec SnapCenter".
Préparation de l'hôte cible
Cette section décrit les étapes de préparation requises sur un serveur utilisé comme cible de clone du système.
En fonctionnement normal, l'hôte cible peut être utilisé à d'autres fins, par exemple comme système d'assurance qualité ou de test HANA. Par conséquent, la plupart des étapes décrites doivent être exécutées lorsque l'opération de clonage du système est demandée. D'autre part, les fichiers de configuration appropriés, comme /etc/fstab et /usr/sap/sapservices, peut être préparé puis mis en production simplement en copiant le fichier de configuration.
La préparation de l'hôte cible inclut également l'arrêt du système d'assurance qualité ou de test HANA.
Nom d'hôte et adresse IP du serveur cible
Le nom d'hôte du serveur cible doit être identique au nom d'hôte du système source. L'adresse IP peut être différente.
|
|
Une clôture correcte du serveur cible doit être établie de sorte qu'il ne puisse pas communiquer avec d'autres systèmes. Si une clôture correcte n'est pas en place, le système de production cloné peut échanger des données avec d'autres systèmes de production. |
|
|
Dans notre configuration de laboratoire, nous avons modifié le nom d'hôte du système cible uniquement en interne du point de vue du système cible. En externe, l'hôte était toujours accessible avec le nom d'hôte hana-7. Lorsque vous êtes connecté à l'hôte, celui-ci est hana-1. |
Installez le logiciel requis
Le logiciel de l'agent hôte SAP doit être installé sur le serveur cible. Pour plus d'informations, reportez-vous à la section "Agent hôte SAP" Sur le portail d'aide SAP.
Le plug-in SnapCenter HANA doit être déployé sur l'hôte cible à l'aide de l'opération d'ajout d'hôte dans SnapCenter.
Configuration des utilisateurs, des ports et des services SAP
Les utilisateurs et groupes requis pour la base de données SAP HANA doivent être disponibles sur le serveur cible. En général, la gestion centralisée des utilisateurs est utilisée ; aucune étape de configuration n'est donc nécessaire sur le serveur cible. Les ports requis pour la base de données HANA doivent être configurés sur les hôtes cibles. La configuration peut être copiée à partir du système source en copiant /etc/services vers le serveur cible.
Les entrées de services SAP requises doivent être disponibles sur l'hôte cible. La configuration peut être copiée à partir du système source en copiant /usr/sap/sapservices vers le serveur cible. Le résultat suivant montre les entrées requises pour la base de données SAP HANA utilisée dans la configuration de laboratoire.
#!/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
Préparation du volume de sauvegarde des journaux et des journaux
Comme il n'est pas nécessaire de cloner le volume de journal à partir du système source et que toute restauration soit effectuée avec l'option Effacer le journal, un volume de journal vide doit être préparé sur l'hôte cible.
Comme le système source a été configuré avec un volume de sauvegarde de journaux distinct, un volume de sauvegarde de journaux vide doit être préparé et monté sur le même point de montage que sur le système source.
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
Dans le volume de journal hdb*, vous devez créer des sous-répertoires de la même manière que dans le système source.
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
Dans le volume de sauvegarde de journaux, vous devez créer des sous-répertoires pour le système et la base de données de tenant.
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
Préparer les montages du système de fichiers
Vous devez préparer des points de montage pour les données et le volume partagé.
Dans notre exemple, les répertoires /hana/data/SS1/mnt00001, /hana/shared et usr/sap/SS1 doit être créé.
Préparer le fichier de configuration spécifique au SID pour le script SnapCenter
Vous devez créer le fichier de configuration pour le script d'automatisation SnapCenter 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
Clonage du volume partagé HANA
-
Sélectionnez une sauvegarde Snapshot à partir du volume partagé SS1 du système source et cliquez sur Cloner à partir de la sauvegarde.
-
Sélectionnez l'hôte sur lequel le système de réparation cible a été préparé. L'adresse IP d'exportation NFS doit être l'interface réseau de stockage de l'hôte cible. Comme la DSRI cible garde le même SID que le système source ; dans notre exemple, il s'agit de SS1.
-
Entrez le script de montage avec les options de ligne de commande requises.
Le système HANA utilise un seul volume pour /hana/shared `as well as for `/usr/sap/SS1, séparé dans les sous-répertoires comme recommandé dans le guide de configuration "SAP HANA sur les systèmes AFF de NetApp avec NFS". Le scriptsc-mount-volume.shprend en charge cette configuration à l'aide d'une option de ligne de commande spéciale pour le chemin de montage. Si l'option de ligne de commande chemin de montage est égale àusr-sap-and-shared, le script monte les sous-répertoiressharedetusr-sapdans le volume en conséquence.
-
L'écran des détails du travail dans SnapCenter indique la progression de l'opération.
-
Le fichier journal du
sc- mount-volume.shle script montre les différentes étapes exécutées pour l'opération de montage.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.
-
Lorsque le workflow SnapCenter est terminé, le
usr/sap/SS1et le/hana/sharedles systèmes de fichiers sont montés sur l'hôte cible.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
-
Dans SnapCenter, une nouvelle ressource pour le volume cloné est visible.
-
Maintenant que le
/hana/sharedLe volume est disponible, les services SAP HANA peuvent être démarrés.hana-1:/mnt/sapcc-share/SAP-System-Refresh # systemctl start sapinit
-
Les processus SAP Host Agent et sapstartsrv sont à présent démarrés.
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 #
Clonage de services d'applications SAP supplémentaires
Les autres services d'application SAP sont clonés de la même manière que le volume partagé SAP HANA, comme indiqué dans la section «Clonage du volume partagé HANA. » Bien entendu, le ou les volumes de stockage requis des serveurs d'applications SAP doivent également être protégés avec SnapCenter.
Vous devez ajouter les entrées de services requises à /usr/sap/sapservices, et les ports, les utilisateurs et les points de montage du système de fichiers (par exemple, /usr/sap/SID) doit être préparé.
Clonage du volume de données et restauration de la base de données HANA
-
Sélectionnez une sauvegarde Snapshot HANA dans le système source SS1.
-
Sélectionnez l'hôte sur lequel le système de réparation cible a été préparé. L'adresse IP d'exportation NFS doit être l'interface réseau de stockage de l'hôte cible. Un SID cible garde le même SID que le système source ; dans notre exemple, c'est SS1.
-
Entrez les scripts de montage et post-clonage avec les options de ligne de commande requises.
Le script de l'opération de restauration restaure la base de données HANA au point dans le temps de l'opération Snapshot et n'exécute aucune restauration vers le avant. Si une récupération de transfert vers un point dans le temps spécifique est nécessaire, la récupération doit être effectuée manuellement. Une restauration manuelle par transfert nécessite également que les sauvegardes de journaux du système source soient disponibles sur l'hôte cible. 
L'écran des détails du travail dans SnapCenter indique la progression de l'opération.
Le fichier journal du sc-system-refresh.sh script affiche les différentes étapes exécutées pour le montage et l'opération de restauration.
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
Après l'opération de montage et de restauration, le volume de données HANA est monté sur l'hôte cible.
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
Le système HANA est désormais disponible et peut être utilisé, par exemple, comme système de réparation.