Actualisation du système SAP HANA avec LSC et SnapCenter
Suggérer des modifications
PDF
Cette section décrit comment intégrer LSC avec NetApp SnapCenter. L'intégration entre LSC et SnapCenter prend en charge toutes les bases de données SAP prises en charge. Néanmoins, nous devons différencier les bases de données SAP AnyDB et SAP HANA car SAP HANA fournit un hôte de communication central non disponible pour les bases de données SAP.
L'installation par défaut de l'agent SnapCenter et du plug-in de base de données pour SAP AnyDB est une installation locale à partir de l'agent SnapCenter, en plus du plug-in de base de données correspondant pour le serveur de base de données.
Dans cette section, l'intégration entre LSC et SnapCenter est décrite à l'aide d'une base de données SAP HANA comme un exemple. Comme indiqué précédemment pour SAP HANA, deux options sont disponibles pour l'installation de l'agent SnapCenter et du plug-in de base de données SAP HANA :
-
Un agent SnapCenter standard et une installation du plug-in SAP HANA. dans une installation standard, l'agent SnapCenter et le plug-in SAP HANA sont installés localement sur le serveur de base de données SAP HANA.
-
Une installation de SnapCenter avec un hôte de communication central. Un hôte de communication central est installé avec l'agent SnapCenter, le plug-in SAP HANA et le client de base de données HANA qui gère toutes les opérations liées à la base de données nécessaires pour sauvegarder et restaurer une base de données SAP HANA pour plusieurs systèmes SAP HANA en environnement. Par conséquent, un hôte de communication central n'a pas besoin d'installer un système de base de données SAP HANA complet.
Pour en savoir plus sur ces différents agents SnapCenter et les options d'installation du plug-in de base de données SAP HANA, consultez le rapport technique "Tr-4614 : sauvegarde et restauration SAP HANA avec SnapCenter".
Les sections suivantes mettent en évidence les différences entre l'intégration de LSC à SnapCenter à l'aide de l'installation standard ou de l'hôte de communication central. Par exemple, toutes les étapes de configuration qui ne sont pas mises en évidence sont les mêmes, quelle que soit l'option d'installation et la base de données utilisée.
Pour effectuer une sauvegarde automatisée basée sur des copies Snapshot à partir de la base de données source et créer un clone pour la nouvelle base de données cible, l'intégration décrite entre LSC et SnapCenter utilise les options de configuration et les scripts décrits dans la "Tr-4667 : automatisation des opérations de copie système et de clonage SAP HANA avec SnapCenter".
Présentation
La figure suivante montre un flux de travail général type pour le cycle de vie d'actualisation d'un système SAP avec SnapCenter sans LSC :
-
Installation initiale et préparation unique du système cible.
-
Prétraitement manuel (exportation de licences, d'utilisateurs, d'imprimantes, etc.).
-
Si nécessaire, la suppression d'un clone déjà existant sur le système cible.
-
Clonage d'une copie Snapshot existante du système source sur le système cible effectué par SnapCenter.
-
Opérations manuelles de post-traitement SAP (importation de licences, d'utilisateurs, d'imprimantes, désactivation de tâches par lots, etc.).
-
Le système peut ensuite être utilisé comme système de test ou d'assurance qualité.
-
Lorsqu'une nouvelle actualisation du système est demandée, le flux de travail redémarre à l'étape 2.
Les clients SAP savent que les étapes manuelles en vert dans la figure ci-dessous sont longues et sujettes aux erreurs. Lors de l'utilisation de l'intégration LSC et SnapCenter, ces étapes manuelles sont effectuées avec LSC de manière fiable et reproductible, avec tous les journaux nécessaires pour les audits internes et externes.
La figure suivante présente la procédure générale de mise à jour du système SAP basé sur SnapCenter.
Conditions préalables et limites
Les conditions préalables suivantes doivent être remplies :
-
SnapCenter doit être installé. Le système source et le système cible doivent être configurés dans SnapCenter, soit dans une installation standard, soit à l'aide d'un hôte de communication central. Des copies Snapshot peuvent être créées sur le système source.
-
Le système de stockage back-end doit être configuré correctement dans SnapCenter, comme illustré dans l'image ci-dessous.
Les deux images suivantes couvrent l'installation standard dans laquelle l'agent SnapCenter et le plug-in SAP HANA sont installés localement sur chaque serveur de base de données.
L'agent SnapCenter et le plug-in de base de données approprié doivent être installés sur la base de données source.
L'agent SnapCenter et le plug-in de base de données approprié doivent être installés sur la base de données cible.
L'image suivante décrit le déploiement central de communication-hôte dans lequel l'agent SnapCenter, le plug-in SAP HANA et le client de base de données SAP HANA sont installés sur un serveur centralisé (tel que le serveur SnapCenter) pour gérer plusieurs systèmes SAP HANA en environnement.
L'agent SnapCenter, le plug-in de base de données SAP HANA et le client de base de données HANA doivent être installés sur l'hôte de communication central.
La sauvegarde de la base de données source doit être correctement configurée dans SnapCenter, de sorte que la copie Snapshot puisse être créée.
Le maître LSC et le travailleur LSC doivent être installés dans l'environnement SAP. Dans ce déploiement, nous avons également installé le maître LSC sur le serveur SnapCenter et le travailleur LSC sur le serveur de base de données SAP cible, qui doit être actualisé. Pour plus de détails, consultez la section «Configuration de laboratoire. »
Ressources de documentation :
Configuration de laboratoire
Cette section présente un exemple d'architecture configurée dans un data Center de démonstration. La configuration a été divisée en une installation standard et une installation à l'aide d'un hôte de communication central.
Installation standard
La figure suivante montre une installation standard dans laquelle l'agent SnapCenter et le plug-in de base de données ont été installés localement sur le serveur source et le serveur de base de données cible. Pendant la configuration de laboratoire, nous avons installé le plug-in SAP HANA. De plus, le travailleur LSC a également été installé sur le serveur cible. Pour simplifier et réduire le nombre de serveurs virtuels, nous avons installé le maître LSC sur le serveur SnapCenter. La communication entre les différents composants est illustrée dans la figure suivante.
Hôte de communication central
La figure suivante illustre la configuration à l'aide d'un hôte de communication central. Dans cette configuration, l'agent SnapCenter et le plug-in SAP HANA et le client de base de données HANA ont été installés sur un serveur dédié. Dans cette configuration, nous avons utilisé le serveur SnapCenter pour installer l'hôte de communication central. De plus, le travailleur LSC a été de nouveau installé sur le serveur cible. Pour simplifier et réduire le nombre de serveurs virtuels, nous avons également décidé d'installer le serveur LSC maître sur le serveur SnapCenter. La communication entre les différents composants est illustrée dans la figure ci-dessous.
Premières étapes de préparation unique pour Libelle SystemCopy
Il existe trois composants principaux d'une installation LSC :
-
LSC master. comme son nom l'indique, c'est le composant maître qui contrôle le flux de travail automatique d'une copie système basée sur Libelle. Dans l'environnement de démonstration, le maître LSC a été installé sur le serveur SnapCenter.
-
LSC worker. un travailleur LSC fait partie du logiciel libelle qui s'exécute généralement sur le système SAP cible et exécute les scripts requis pour la copie automatisée du système. Dans l'environnement de démonstration, le travailleur LSC a été installé sur le serveur d'applications SAP HANA cible.
-
Satellite LSC. un satellite LSC fait partie du logiciel libelle qui fonctionne sur un système tiers sur lequel d'autres scripts doivent être exécutés. Le maître LSC peut également remplir le rôle d'un système satellite LSC en même temps.
Nous avons d'abord défini tous les systèmes impliqués dans LSC, comme illustré dans l'image suivante :
-
172.30.15.35. adresse IP du système source SAP et du système source SAP HANA.
-
172.30.15.3. adresse IP du maître LSC et du système satellite LSC pour cette configuration. Comme nous avons installé le maître LSC sur le serveur SnapCenter, les applets de commande SnapCenter 4.x PowerShell sont déjà disponibles sur cet hôte Windows car elles ont été installées pendant l'installation du serveur SnapCenter. Nous avons donc décidé d'activer le rôle satellite LSC pour ce système et d'exécuter toutes les applets de commande SnapCenter PowerShell sur cet hôte. Si vous utilisez un système différent, veillez à installer les applets de commande SnapCenter PowerShell sur cet hôte conformément à la documentation SnapCenter.
-
172.30.15.36. adresse IP du système de destination SAP, du système de destination SAP HANA et du travailleur LSC.
Au lieu d'adresses IP, de noms d'hôte ou de noms de domaine complets peuvent également être utilisés.
L'image suivante montre la configuration LSC du maître, du travailleur, du satellite, de la source SAP, de la cible SAP, base de données source et base de données cible.
Pour l'intégration principale, nous devons à nouveau séparer les étapes de configuration dans l'installation standard et l'installation à l'aide d'un hôte de communication central.
Installation standard
Cette section décrit les étapes de configuration nécessaires à l'utilisation d'une installation standard où l'agent SnapCenter et le plug-in de base de données requis sont installés sur les systèmes source et cible. Lors de l'utilisation d'une installation standard, toutes les tâches nécessaires pour monter le volume clone, restaurer et récupérer le système cible sont effectuées à partir de l'agent SnapCenter qui s'exécute sur le système de base de données cible sur le serveur lui-même. Cela permet d'accéder à toutes les informations relatives au clone disponibles via les variables d'environnement de l'agent SnapCenter. Par conséquent, il vous suffit de créer une tâche supplémentaire dans la phase de copie LSC. Cette tâche exécute le processus de copie Snapshot sur le système de base de données source, ainsi que le processus de clonage et de restauration sur le système de base de données cible. Toutes les tâches liées à SnapCenter sont déclenchées à l'aide d'un script PowerShell saisi dans la tâche LSC NTAP_SYSTEM_CLONE.
L'image suivante montre la configuration de la tâche LSC en phase de copie.
L'image suivante met en évidence la configuration du NTAP_SYSTEM_CLONE processus. Comme vous exécutez un script PowerShell, ce script Windows PowerShell est exécuté sur le système satellite. Dans ce cas, il s'agit du serveur SnapCenter avec le maître LSC installé qui sert également de système satellite.
Comme LSC doit être informé de la réussite de l'opération de copie Snapshot, de clonage et de récupération, vous devez définir au moins deux types de code retour. Un code est utilisé pour une exécution réussie du script, et l'autre code est pour une exécution échouée du script, comme indiqué dans l'image suivante.
-
LSC:OKdoit être écrit à partir du script vers la sortie standard si l'exécution a réussi. -
LSC:ERRORdoit être écrit à partir du script vers la sortie standard si l'exécution a échoué.
L'image suivante montre une partie du script PowerShell qui doit être exécutée pour exécuter une sauvegarde basée sur Snapshot sur le système de base de données source et un clone sur le système de base de données cible. Le script n'est pas conçu pour être terminé. Le script montre plutôt à quel point l'intégration entre LSC et SnapCenter peut ressembler et à quel point il est facile de le configurer.
Comme le script est exécuté sur le maître LSC (qui est également un système satellite), le maître LSC du serveur SnapCenter doit être exécuté en tant qu'utilisateur Windows disposant des autorisations appropriées pour exécuter des opérations de sauvegarde et de clonage dans SnapCenter. Pour vérifier si l'utilisateur dispose des autorisations appropriées, l'utilisateur doit pouvoir exécuter une copie Snapshot et un clone dans l'interface utilisateur de SnapCenter.
Il n'est pas nécessaire d'exécuter le maître LSC et le satellite LSC sur le serveur SnapCenter lui-même. Le maître LSC et le satellite LSC peuvent fonctionner sur n'importe quel ordinateur Windows. La condition préalable à l'exécution du script PowerShell sur le satellite LSC est que les applets de commande SnapCenter PowerShell ont été installées sur le serveur Windows.
Hôte de communication central
Pour l'intégration entre LSC et SnapCenter à l'aide d'un hôte de communication central, les seuls réglages à effectuer sont effectués dans la phase de copie. La copie Snapshot et le clone sont créés à l'aide de l'agent SnapCenter sur l'hôte de communication central. Par conséquent, tous les détails sur les volumes nouvellement créés sont uniquement disponibles sur l'hôte de communication central et non sur le serveur de base de données cible. Cependant, ces détails sont nécessaires sur le serveur de base de données cible pour monter le volume clone et effectuer la restauration. C'est la raison pour laquelle deux tâches supplémentaires sont nécessaires dans la phase de copie. Une tâche est exécutée sur l'hôte de communication central et une tâche est exécutée sur le serveur de base de données cible. Ces deux tâches sont affichées dans l'image ci-dessous.
-
NTAP_SYSTEM_CLONE_CP. cette tâche crée la copie Snapshot et le clone à l'aide d'un script PowerShell qui exécute les fonctions SnapCenter nécessaires sur l'hôte de communication central. Cette tâche s'exécute donc sur le satellite LSC, qui dans notre instance est le maître LSC qui fonctionne sous Windows. Ce script collecte toutes les informations sur le clone et les nouveaux volumes créés, et les remet à la seconde tâche
NTAP_MNT_RECOVER_CP, Qui s'exécute sur le worker LSC qui s'exécute sur le serveur de base de données cible. -
NTAP_MNT_RECOVER_CP. cette tâche arrête le système SAP cible et la base de données SAP HANA, démonte les anciens volumes, puis monte les volumes de clone de stockage nouvellement créés en fonction des paramètres transmis par la tâche précédente
NTAP_SYSTEM_CLONE_CP. La base de données SAP HANA cible est ensuite restaurée et récupérée.
L'image suivante met en évidence la configuration de la tâche NTAP_SYSTEM_CLONE_CP. Il s'agit du script Windows PowerShell exécuté sur le système satellite. Dans ce cas, le système satellite est le serveur SnapCenter avec le maître LSC installé.
Comme LSC doit savoir si l'opération de copie Snapshot et de clonage a réussi, vous devez définir au moins deux types de code retour : un code retour pour une exécution réussie du script et l'autre pour une exécution échouée du script, comme indiqué dans l'image ci-dessous.
-
LSC:OKdoit être écrit à partir du script vers la sortie standard si l'exécution a réussi. -
LSC:ERRORdoit être écrit à partir du script vers la sortie standard si l'exécution a échoué.
L'image suivante montre une partie du script PowerShell qui doit être exécutée pour exécuter une copie Snapshot et un clone à l'aide de l'agent SnapCenter sur l'hôte de communication central. Le script n'est pas destiné à être terminé. Le script est plutôt utilisé pour montrer à quel point l'intégration entre LSC et SnapCenter peut ressembler et à quel point il est facile de le configurer.
Comme mentionné précédemment, vous devez transférer le nom du volume de clone à la tâche suivante NTAP_MNT_RECOVER_CP pour monter le volume clone sur le serveur cible. Le nom du volume clone, également appelé Junction path, est stocké dans la variable $JunctionPath. Le transfert à une tâche LSC ultérieure est réalisé via une variable LSC personnalisée.
echo $JunctionPath > $_task(current, custompath1)_$
Comme le script est exécuté sur le maître LSC (qui est également un système satellite), le maître LSC du serveur SnapCenter doit s'exécuter en tant qu'utilisateur Windows disposant des autorisations appropriées pour exécuter les opérations de sauvegarde et de clonage dans SnapCenter. Pour vérifier s'il dispose des autorisations appropriées, l'utilisateur doit pouvoir exécuter une copie Snapshot et un clone dans l'interface graphique de SnapCenter.
La figure suivante présente la configuration de la tâche NTAP_MNT_RECOVER_CP. Parce que nous voulons exécuter un script Shell Linux, il s'agit d'un script de commande exécuté sur le système de base de données cible.
Comme LSC doit être conscient du montage des volumes clones et de la réussite de la restauration et de la récupération de la base de données cible, il faut définir au moins deux types de code retour. Un code est pour une exécution réussie du script, et un est pour une exécution échouée du script, comme illustré dans la figure suivante.
-
LSC:OKdoit être écrit à partir du script vers la sortie standard si l'exécution a réussi. -
LSC:ERRORdoit être écrit à partir du script vers la sortie standard si l'exécution a échoué.
La figure suivante montre une partie du script Shell Linux utilisé pour arrêter la base de données cible, démonter l'ancien volume, monter le volume clone, restaurer et récupérer la base de données cible. Dans la tâche précédente, le chemin de jonction a été écrit dans une variable LSC. La commande suivante lit cette variable LSC et stocke la valeur dans le $JunctionPath Variable du script Shell Linux.
JunctionPath=$_include($_task(NTAP_SYSTEM_CLONE_CP, custompath1)_$, 1, 1)_$
Le travailleur LSC sur le système cible s'exécute comme <sidaadm>, mais les commandes mount doivent être exécutées en tant qu'utilisateur root. C'est pourquoi vous devez créer le central_plugin_host_wrapper_script.sh. Le script central_plugin_host_wrapper_script.sh est appelé à partir de la tâche NTAP_MNT_RECOVERY_CP à l'aide du sudo commande. À l'aide du sudo Commande, le script s'exécute avec UID 0 et nous pouvons effectuer toutes les étapes suivantes, telles que le démontage des anciens volumes, le montage des volumes clones, la restauration et la récupération de la base de données cible. Pour activer l'exécution de script à l'aide de sudo, la ligne suivante doit être ajoutée dans /etc/sudoers:
hn6adm ALL=(root) NOPASSWD:/usr/local/bin/H06/central_plugin_host_wrapper_script.sh
Opération de mise à jour du système SAP HANA
Maintenant que toutes les tâches d'intégration nécessaires entre LSC et NetApp SnapCenter ont été effectuées, lancer une actualisation du système SAP entièrement automatisée est une tâche en un clic.
La figure suivante montre la tâche NTAP``SYSTEM``CLONE dans une installation standard. Comme vous pouvez le voir, la création d'une copie Snapshot et d'un clone, le montage du volume clone sur le serveur de base de données cible et la restauration et la récupération de la base de données cible ont pris environ 14 minutes. De fait, avec Snapshot et la technologie FlexClone de NetApp, la durée de cette tâche reste quasiment identique, indépendamment de la taille de la base de données source.
La figure suivante montre les deux tâches NTAP_SYSTEM_CLONE_CP et NTAP_MNT_RECOVERY_CP lors de l'utilisation d'un hôte de communication central. Comme vous pouvez le voir, la création d'une copie Snapshot, d'un clone, le montage du volume clone sur le serveur de base de données cible et la restauration et la récupération de la base de données cible ont pris environ 12 minutes. Il s'agit plus ou moins du temps nécessaire pour effectuer ces étapes lors de l'utilisation d'une installation standard. Là encore, les technologies Snapshot et NetApp FlexClone permettent d'effectuer ces tâches rapidement et de manière cohérente, quelle que soit la taille de la base de données source.
