Skip to main content
NetApp Solutions SAP
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Clone du système SAP avec SnapCenter

Contributeurs
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 figure ci-dessous récapitule les étapes requises pour une opération de clonage de système SAP avec SnapCenter.

  1. Préparez l'hôte cible.

  2. Workflow de création de clone SnapCenter pour le volume partagé SAP HANA.

  3. Démarrage des services SAP HANA

  4. Le clone de SnapCenter crée un workflow pour le volume de données SAP HANA, y compris pour la restauration de la base de données.

  5. Le système SAP HANA peut désormais être utilisé comme système de réparation.

    Remarque Si vous devez réinitialiser le système sur une autre sauvegarde Snapshot, les étapes 6 et 4 sont suffisantes. Le volume partagé SAP HANA peut continuer à être monté.

    Si le système n'est plus nécessaire, le processus de nettoyage est effectué avec les étapes suivantes.

  6. Workflow de suppression de clone SnapCenter pour le volume de données SAP HANA, y compris l'arrêt de la base de données.

  7. Arrêt des services SAP HANA

  8. Workflow de suppression des clones SnapCenter pour le volume partagé SAP HANA.

image clone copie sc 9

Conditions préalables et limites

Les workflows décrits dans les sections suivantes présentent des prérequis et des limites pour l'architecture du système SAP HANA et la configuration SnapCenter.

  • Le workflow décrit est valide pour les systèmes MDC SAP HANA à un hôte. Plusieurs systèmes hôtes ne sont pas pris en charge.

  • Le plug-in SnapCenter SAP HANA doit être déployé sur l'hôte cible pour permettre l'exécution des scripts d'automatisation.

  • Le workflow a été validé pour NFS. L'automatisation script sc-mount-volume.sh, utilisée pour monter le volume partagé SAP HANA, ne prend pas en charge FCP. Cette étape doit être effectuée manuellement ou en étendant le script.

  • Le flux de travail décrit n'est valide que pour la version SnapCenter 5.0 ou supérieure.

Configuration de laboratoire

La figure ci-dessous présente la configuration de l'atelier utilisée pour les opérations de clonage du système.

Les versions logicielles suivantes ont été utilisées :

  • SnapCenter 5.0

  • Systèmes SAP HANA : HANA 2.0 SPS6 rév.61

  • SLES 15

  • ONTAP 9.7P7

Tous les systèmes SAP HANA doivent être configurés conformément au guide de configuration "SAP HANA sur les systèmes AFF de NetApp avec NFS". Les ressources SnapCenter et SAP HANA ont été configurées sur la base du guide des bonnes pratiques "SAP HANA : sauvegarde et restauration avec SnapCenter".

copie sc clone image41

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.

Pendant le fonctionnement normal, l'hôte cible peut être utilisé à d'autres fins, par exemple en tant que système d'assurance qualité ou de test SAP 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, peuvent être préparés et ensuite 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 de contrôle qualité ou de test SAP 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.

Remarque 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.
Remarque 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.

Installer le logiciel requis

Le logiciel de l'agent hôte SAP doit être installé sur le serveur cible. Pour obtenir des informations complètes, consultez le "Agent hôte SAP" sur le portail d'aide SAP.

Le plug-in SnapCenter SAP HANA doit être déployé sur l'hôte cible à l'aide de l'opération d'ajout d'hôte dans SnapCenter.

Configurer les utilisateurs, les ports et les 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 SAP HANA doivent être configurés sur les hôtes cibles. La configuration peut être copiée à partir du système source en copiant le fichier /etc/services sur 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-- 2 ss1adm sapsys 4096 Dec 1 04:48 .
drwxr-xr-- 2 ss1adm sapsys 4896 Dec 1 03:42 ..
drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:15 DB_SS1
drwxr-xr-- 2 ss1adm sapsys 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é.

Avec notre exemple, les répertoires /hana/data/SS1/mnt00001, /hana/shared et usr/sap/SS1 doivent être créés.

Préparer l'exécution du script

Vous devez ajouter les scripts, qui doivent être exécutés sur le système cible dans le fichier de configuration des commandes autorisées SnapCenter.

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
command: /mnt/sapcc-share/SAP-System-Refresh/sc-mount-volume.sh
hana-7:/opt/NetApp/snapcenter/scc/etc #

Clonage du volume partagé HANA

  1. Sélectionnez une sauvegarde Snapshot dans le volume partagé SS1 du système source, puis cliquez sur Cloner.

copie sc clone image42

  1. 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. En tant que SID cible, conserver le même SID que le système source. Dans notre exemple SS1.

copie sc clone image43

  1. Entrez le script de montage avec les options de ligne de commande requises.

    Remarque Le système SAP HANA utilise un volume unique pour /hana/shared et pour /usr/sap/SS1, séparés en sous-répertoires, comme recommandé dans le guide de configuration "SAP HANA sur les systèmes AFF de NetApp avec NFS". Le script sc-mount-volume.sh prend 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 mount path est égale à usr-sap-and-shared, le script monte les sous-répertoires partagés et usr-sap dans le volume en conséquence.
copie sc clone image44

  1. L'écran Détails du travail dans SnapCenter indique la progression de l'opération.

copie sc clone image45

  1. Le fichier journal du script sc-mount-volume.sh affiche 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.

  1. Lorsque le flux de travail SnapCenter est terminé, les systèmes de fichiers /usr/sap/SS1 et /hana/shared 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

  1. Dans SnapCenter, une nouvelle ressource pour le volume cloné est visible.

image de clone copie sc 46

  1. Maintenant que le volume /hana/shared est disponible, les services SAP HANA peuvent être démarrés.

hana-1:/mnt/sapcc-share/SAP-System-Refresh # systemctl start sapinit

  1. SAP Host Agent et les processus sapstartsrv sont maintenant 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

D'autres services d'applications SAP sont clonés de la même manière que pour le volume partagé SAP HANA, comme indiqué dans la section « clonage du volume partagé SAP HANA ». Bien sûr, 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 dans /usr/sap/sapservices, et les ports, les utilisateurs et les points de montage du système de fichiers (par exemple, /usr/sap/SID) doivent être préparés.

Clonage du volume de données et restauration de la base de données HANA

  1. Sélectionnez une sauvegarde Snapshot SAP HANA dans le système source SS1.

copie sc clone image47

  1. 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. En tant que SID cible, conserver le même SID que le système source. Dans notre exemple SS1

copie sc clone image48

  1. Entrez les scripts post-clonage avec les options de ligne de commande requises.

    Remarque Le script de l'opération de restauration restaure la base de données SAP HANA au point dans le temps de l'opération Snapshot et n'exécute aucune restauration par transfert. 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.
copie sc clone image23

L'écran des détails du travail dans SnapCenter indique la progression de l'opération.

image clone copie sc 49

Le fichier journal du sc-system-refresh script indique les différentes étapes qui sont exécutées pour le montage et l'opération de récupération.

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
After the recovery operation, the HANA database is running and the data volume is mounted at the target host.
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 SAP HANA est désormais disponible et peut être utilisé, par exemple, en tant que système de réparation.