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.

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.

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.

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.

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.

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.

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.

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.

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.

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: