La configuration des scripts des fournisseurs et les playbooks Ansible
Dans cette documentation, le fichier de configuration, le script d'exécution et les playbooks Ansible sont utilisés lors du déploiement et de l'exécution des workflows.
Les scripts exemple sont fournis en l'état et ne sont pas pris en charge par NetApp. Vous pouvez demander la version actuelle des scripts par courrier électronique à ng-sapcc@netapp.com. |
Fichier de configuration du fournisseur netapp_clone.conf
Le fichier de configuration est créé comme décrit dans "Documentation SAP Lama - Configuration des scripts enregistrés SAP Host Agent". Ce fichier de configuration doit se trouver sur le nœud de contrôle Ansible où l'agent hôte SAP est installé.
le système d'exploitation-utilisateur configuré sapuser
Doit disposer des autorisations appropriées pour exécuter le script et les playbooks Ansible. Vous pouvez placer le script dans un répertoire de script commun. SAP Lama peut fournir plusieurs paramètres lors de l'appel du script.
En plus des paramètres personnalisés, PARAM_ClonePostFix
, PROP_ClonePostFix
, PARAM_ClonePostFix
, et PROP_ClonePostFix
, beaucoup d'autres peuvent être remis, comme le montre le "Documentation SAP Lama".
root@sap-jump:~# cat /usr/sap/hostctrl/exe/operations.d/netapp_clone.conf Name: netapp_clone Username: sapuser Description: NetApp Clone for Custom Provisioning Command: /usr/sap/scripts/netapp_clone.sh --HookOperationName=$[HookOperationName] --SAPSYSTEMNAME=$[SAPSYSTEMNAME] --SAPSYSTEM=$[SAPSYSTEM] --MOUNT_XML_PATH=$[MOUNT_XML_PATH] --PARAM_ClonePostFix=$[PARAM-ClonePostFix] --PARAM_SnapPostFix=$[PARAM-SnapPostFix] --PROP_ClonePostFix=$[PROP-ClonePostFix] --PROP_SnapPostFix=$[PROP-SnapPostFix] --SAP_LVM_SRC_SID=$[SAP_LVM_SRC_SID] --SAP_LVM_TARGET_SID=$[SAP_LVM_TARGET_SID] ResulConverter: hook Platform: Unix
Script de fournisseur netapp_clone.sh
Le script du fournisseur doit être stocké dans /usr/sap/scripts
tel qu'il est configuré dans le fichier de configuration du fournisseur.
Variables
Les variables suivantes sont codées en dur dans le script et doivent être adaptées en conséquence.
-
PRIMARY_CLUSTER=
<hostname of netapp cluster> -
PRIMARY_SVM=
<SVM name where source system volumes are stored>
Les fichiers de certificat PRIMARY_KEYFILE=/usr/sap/scripts/ansible/certs/ontap.key
et PRIMARY_CERTFILE=/usr/sap/scripts/ansible/certs/ontap.pem
doit être fourni comme décrit dans "Modules NetApp Ansible - préparation de ONTAP".
Si plusieurs clusters ou SVM sont requis pour différents systèmes SAP, ces variables peuvent être ajoutées sous forme de paramètres dans la définition du fournisseur SAP Lama. |
Fonction : créer un fichier d'inventaire
Pour rendre l'exécution de PlayBook Ansible plus dynamique, un inventory. yml
le fichier est créé à la volée. Certaines valeurs statiques sont configurées dans la section variable et certaines sont créées dynamiquement pendant l'exécution.
Fonction : exécutez un PlayBook Ansible
Cette fonction permet d'exécuter le PlayBook Ansible ainsi que la création dynamique inventory.yml
fichier. la convention de nommage des playbooks est netapp_lama_${HookOperationName}.yml
. Les valeurs de ${HookOperationName}
Dépend de l'opération Lama et est transmise par Lama en tant que paramètre de ligne de commande.
Section principale
Cette section contient le plan d'exécution principal. La variable ${HookOperationName}
Contient le nom de l'action de remplacement Lama et est fourni par Lama lorsque le script est appelé.
-
Valeurs avec le workflow de provisionnement des clones de système et des copies de système :
-
Volumes en Clonevolumes
-
PostClonevolumes
-
-
Valeur avec le workflow de destruction du système :
-
Retrait de ServiceConfigConfigRemoval
-
-
Valeur avec le workflow de mise à jour du système :
-
ClearMountConfig
-
HookOperationName = Clonevolumes
Avec cette étape, le PlayBook Ansible déclenche l'opération de copie Snapshot et de clonage. Les noms de volumes et la configuration de montage sont transmis par SAP Lama via un fichier XML défini dans la variable $MOUNT_XML_PATH
. Ce fichier est enregistré car il est utilisé ultérieurement dans l'étape FinalizeCloneVolumes
pour créer la nouvelle configuration de point de montage. Les noms de volumes sont extraits du fichier XML et le PlayBook de clonage Ansible est exécuté pour chaque volume.
Dans cet exemple, l'instance EN TANT qu'instance et les services centraux partagent le même volume. Par conséquent, le clonage de volume n'est exécuté que lorsque le numéro d'instance SAP est utilisé ($SAPSYSTEM ) n'est pas 01 . Ces différences peuvent différer dans d'autres environnements et doivent être modifiées en conséquence.
|
HookOperationName = PostClonevolumes
Au cours de cette étape, les propriétés personnalisées ClonePostFix
et SnapPostFix
et la configuration du point de montage du système cible est maintenue.
Les propriétés personnalisées sont utilisées ultérieurement comme entrée lorsque le système est déclassé pendant le ServiceConfigRemoval
ou ClearMountConfig
phases Le système est conçu pour préserver les paramètres personnalisés spécifiés lors du flux de provisionnement du système.
Les valeurs utilisées dans cet exemple sont les suivantes ClonePostFix=_clone_20221115
et SnapPostFix=_snap_20221115
.
Pour le volume HN9_sap
, Le fichier Ansible créé dynamiquement inclut les valeurs suivantes : datavolumename
: HN9_sap
, snapshotpostfix: _snap_20221115
, et clonepostfix: _clone_20221115
.
Qui mène au nom du snapshot sur le volume HN9_sap HN9_sap_snap_20221115
et le nom du clone de volume créé HN9_sap_clone_20221115
.
Les propriétés personnalisées peuvent être utilisées de quelque manière que ce soit pour préserver les paramètres utilisés pendant le processus de provisionnement. |
La configuration du point de montage est extraite du fichier XML transmis par Lama dans CloneVolume
étape. Le ClonePostFix
Est ajouté aux noms des volumes et renvoyé au Lama via la sortie de script par défaut. Cette fonctionnalité est décrite dans le "Note SAP 1889590".
Dans cet exemple, les qtrees sur le système de stockage sont utilisés comme une manière commune de placer différentes données sur un seul volume. Par exemple : HN9_sap contient les points de montage pour /usr/sap/HN9 , /sapmnt/HN9 , et /home/hn9adm . Les sous-répertoires fonctionnent de la même manière. Ces différences peuvent différer dans d'autres environnements et doivent être modifiées en conséquence.
|
HookOperationName = ServiceConfigRemovation
Dans cette étape, le PlayBook Ansible responsable de la suppression des clones de volumes s'exécute.
Les noms des volumes sont transmis par SAP Lama via le fichier de configuration de montage et les propriétés personnalisées ClonePostFix
et SnapPostFix
permettent de transmettre les valeurs des paramètres initialement spécifiés lors du workflow de provisionnement du système (voir la remarque à la section HookOperationName = PostCloneVolumes
).
Les noms de volumes sont extraits du fichier xml et le PlayBook de clonage Ansible est exécuté pour chaque volume.
Dans cet exemple, l'instance EN TANT qu'instance et les services centraux partagent le même volume. La suppression du volume n'est donc exécutée que lorsque le numéro d'instance SAP est utilisé ($SAPSYSTEM ) n'est pas 01 . Ces différences peuvent différer dans d'autres environnements et doivent être modifiées en conséquence.
|
HookOperationName = ClearMountConfig
Dans cette étape, le PlayBook Ansible responsable de la suppression des clones de volumes lors d'un workflow de mise à jour du système est en cours d'exécution.
Les noms des volumes sont transmis par SAP Lama via le fichier de configuration de montage et les propriétés personnalisées ClonePostFix
et SnapPostFix
permettent de transmettre les valeurs des paramètres initialement spécifiés lors du workflow de provisionnement du système.
Les noms de volumes sont extraits du fichier XML et le PlayBook de clonage Ansible est exécuté pour chaque volume.
Dans cet exemple, l'instance EN TANT qu'instance et les services centraux partagent le même volume. La suppression du volume n'est donc exécutée que lorsque le numéro d'instance SAP est utilisé ($SAPSYSTEM ) n'est pas 01 . Ces différences peuvent différer dans d'autres environnements et doivent être modifiées en conséquence.
|
root@sap-jump:~# cat /usr/sap/scripts/netapp_clone.sh #!/bin/bash #Section - Variables ######################################### VERSION="Version 0.9" #Path for ansible play-books ANSIBLE_PATH=/usr/sap/scripts/ansible #Values for Ansible Inventory File PRIMARY_CLUSTER=grenada PRIMARY_SVM=svm-sap01 PRIMARY_KEYFILE=/usr/sap/scripts/ansible/certs/ontap.key PRIMARY_CERTFILE=/usr/sap/scripts/ansible/certs/ontap.pem #Default Variable if PARAM ClonePostFix / SnapPostFix is not maintained in LaMa DefaultPostFix=_clone_1 #TMP Files - used during execution YAML_TMP=/tmp/inventory_ansible_clone_tmp_$$.yml TMPFILE=/tmp/tmpfile.$$ MY_NAME="`basename $0`" BASE_SCRIPT_DIR="`dirname $0`" #Sendig Script Version and run options to LaMa Log echo "[DEBUG]: Running Script $MY_NAME $VERSION" echo "[DEBUG]: $MY_NAME $@" #Command declared in the netapp_clone.conf Provider definition #Command: /usr/sap/scripts/netapp_clone.sh --HookOperationName=$[HookOperationName] --SAPSYSTEMNAME=$[SAPSYSTEMNAME] --SAPSYSTEM=$[SAPSYSTEM] --MOUNT_XML_PATH=$[MOUNT_XML_PATH] --PARAM_ClonePostFix=$[PARAM-ClonePostFix] --PARAM_SnapPostFix=$[PARAM-SnapPostFix] --PROP_ClonePostFix=$[PROP-ClonePostFix] --PROP_SnapPostFix=$[PROP-SnapPostFix] --SAP_LVM_SRC_SID=$[SAP_LVM_SRC_SID] --SAP_LVM_TARGET_SID=$[SAP_LVM_TARGET_SID] #Reading Input Variables hand over by LaMa for i in "$@" do case $i in --HookOperationName=*) HookOperationName="${i#*=}";shift;; --SAPSYSTEMNAME=*) SAPSYSTEMNAME="${i#*=}";shift;; --SAPSYSTEM=*) SAPSYSTEM="${i#*=}";shift;; --MOUNT_XML_PATH=*) MOUNT_XML_PATH="${i#*=}";shift;; --PARAM_ClonePostFix=*) PARAM_ClonePostFix="${i#*=}";shift;; --PARAM_SnapPostFix=*) PARAM_SnapPostFix="${i#*=}";shift;; --PROP_ClonePostFix=*) PROP_ClonePostFix="${i#*=}";shift;; --PROP_SnapPostFix=*) PROP_SnapPostFix="${i#*=}";shift;; --SAP_LVM_SRC_SID=*) SAP_LVM_SRC_SID="${i#*=}";shift;; --SAP_LVM_TARGET_SID=*) SAP_LVM_TARGET_SID="${i#*=}";shift;; *) # unknown option ;; esac done #If Parameters not provided by the User - defaulting to DefaultPostFix if [ -z $PARAM_ClonePostFix ]; then PARAM_ClonePostFix=$DefaultPostFix;fi if [ -z $PARAM_SnapPostFix ]; then PARAM_SnapPostFix=$DefaultPostFix;fi #Section - Functions ######################################### #Function Create (Inventory) YML File ######################################### create_yml_file() { echo "ontapservers:">$YAML_TMP echo " hosts:">>$YAML_TMP echo " ${PRIMARY_CLUSTER}:">>$YAML_TMP echo " ansible_host: "'"'$PRIMARY_CLUSTER'"'>>$YAML_TMP echo " keyfile: "'"'$PRIMARY_KEYFILE'"'>>$YAML_TMP echo " certfile: "'"'$PRIMARY_CERTFILE'"'>>$YAML_TMP echo " svmname: "'"'$PRIMARY_SVM'"'>>$YAML_TMP echo " datavolumename: "'"'$datavolumename'"'>>$YAML_TMP echo " snapshotpostfix: "'"'$snapshotpostfix'"'>>$YAML_TMP echo " clonepostfix: "'"'$clonepostfix'"'>>$YAML_TMP } #Function run ansible-playbook ######################################### run_ansible_playbook() { echo "[DEBUG]: Running ansible playbook netapp_lama_${HookOperationName}.yml on Volume $datavolumename" ansible-playbook -i $YAML_TMP $ANSIBLE_PATH/netapp_lama_${HookOperationName}.yml } #Section - Main ######################################### #HookOperationName – CloneVolumes ######################################### if [ $HookOperationName = CloneVolumes ] ;then #save mount xml for later usage - used in Section FinalizeCloneVolues to generate the mountpoints echo "[DEBUG]: saving mount config...." cp $MOUNT_XML_PATH /tmp/mount_config_${SAPSYSTEMNAME}_${SAPSYSTEM}.xml #Instance 00 + 01 share the same volumes - clone needs to be done once if [ $SAPSYSTEM != 01 ]; then #generating Volume List - assuming usage of qtrees - "IP-Adress:/VolumeName/qtree" xmlFile=/tmp/mount_config_${SAPSYSTEMNAME}_${SAPSYSTEM}.xml if [ -e $TMPFILE ];then rm $TMPFILE;fi numMounts=`xml_grep --count "/mountconfig/mount" $xmlFile | grep "total: " | awk '{ print $2 }'` i=1 while [ $i -le $numMounts ]; do xmllint --xpath "/mountconfig/mount[$i]/exportpath/text()" $xmlFile |awk -F"/" '{print $2}' >>$TMPFILE i=$((i + 1)) done DATAVOLUMES=`cat $TMPFILE |sort -u` #Create yml file and rund playbook for each volume for I in $DATAVOLUMES; do datavolumename="$I" snapshotpostfix="$PARAM_SnapPostFix" clonepostfix="$PARAM_ClonePostFix" create_yml_file run_ansible_playbook done else echo "[DEBUG]: Doing nothing .... Volume cloned in different Task" fi fi #HookOperationName – PostCloneVolumes ######################################### if [ $HookOperationName = PostCloneVolumes] ;then #Reporting Properties back to LaMa Config for Cloned System echo "[RESULT]:Property:ClonePostFix=$PARAM_ClonePostFix" echo "[RESULT]:Property:SnapPostFix=$PARAM_SnapPostFix" #Create MountPoint Config for Cloned Instances and report back to LaMa according to SAP Note: https://launchpad.support.sap.com/#/notes/1889590 echo "MountDataBegin" echo '<?xml version="1.0" encoding="UTF-8"?>' echo "<mountconfig>" xmlFile=/tmp/mount_config_${SAPSYSTEMNAME}_${SAPSYSTEM}.xml numMounts=`xml_grep --count "/mountconfig/mount" $xmlFile | grep "total: " | awk '{ print $2 }'` i=1 while [ $i -le $numMounts ]; do MOUNTPOINT=`xmllint --xpath "/mountconfig/mount[$i]/mountpoint/text()" $xmlFile`; EXPORTPATH=`xmllint --xpath "/mountconfig/mount[$i]/exportpath/text()" $xmlFile`; OPTIONS=`xmllint --xpath "/mountconfig/mount[$i]/options/text()" $xmlFile`; #Adopt Exportpath and add Clonepostfix - assuming usage of qtrees - "IP-Adress:/VolumeName/qtree" TMPFIELD1=`echo $EXPORTPATH|awk -F":/" '{print $1}'` TMPFIELD2=`echo $EXPORTPATH|awk -F"/" '{print $2}'` TMPFIELD3=`echo $EXPORTPATH|awk -F"/" '{print $3}'` EXPORTPATH=$TMPFIELD1":/"${TMPFIELD2}$PARAM_ClonePostFix"/"$TMPFIELD3 echo -e '\t<mount fstype="nfs" storagetype="NETFS">' echo -e "\t\t<mountpoint>${MOUNTPOINT}</mountpoint>" echo -e "\t\t<exportpath>${EXPORTPATH}</exportpath>" echo -e "\t\t<options>${OPTIONS}</options>" echo -e "\t</mount>" i=$((i + 1)) done echo "</mountconfig>" echo "MountDataEnd" #Finished MountPoint Config #Cleanup Temporary Files rm $xmlFile fi #HookOperationName – ServiceConfigRemoval ######################################### if [ $HookOperationName = ServiceConfigRemoval ] ;then #Assure that Properties ClonePostFix and SnapPostfix has been configured through the provisioning process if [ -z $PROP_ClonePostFix ]; then echo "[ERROR]: Propertiy ClonePostFix is not handed over - please investigate";exit 5;fi if [ -z $PROP_SnapPostFix ]; then echo "[ERROR]: Propertiy SnapPostFix is not handed over - please investigate";exit 5;fi #Instance 00 + 01 share the same volumes - clone delete needs to be done once if [ $SAPSYSTEM != 01 ]; then #generating Volume List - assuming usage of qtrees - "IP-Adress:/VolumeName/qtree" xmlFile=$MOUNT_XML_PATH if [ -e $TMPFILE ];then rm $TMPFILE;fi numMounts=`xml_grep --count "/mountconfig/mount" $xmlFile | grep "total: " | awk '{ print $2 }'` i=1 while [ $i -le $numMounts ]; do xmllint --xpath "/mountconfig/mount[$i]/exportpath/text()" $xmlFile |awk -F"/" '{print $2}' >>$TMPFILE i=$((i + 1)) done DATAVOLUMES=`cat $TMPFILE |sort -u| awk -F $PROP_ClonePostFix '{ print $1 }'` #Create yml file and rund playbook for each volume for I in $DATAVOLUMES; do datavolumename="$I" snapshotpostfix="$PROP_SnapPostFix" clonepostfix="$PROP_ClonePostFix" create_yml_file run_ansible_playbook done else echo "[DEBUG]: Doing nothing .... Volume deleted in different Task" fi #Cleanup Temporary Files rm $xmlFile fi #HookOperationName - ClearMountConfig ######################################### if [ $HookOperationName = ClearMountConfig ] ;then #Assure that Properties ClonePostFix and SnapPostfix has been configured through the provisioning process if [ -z $PROP_ClonePostFix ]; then echo "[ERROR]: Propertiy ClonePostFix is not handed over - please investigate";exit 5;fi if [ -z $PROP_SnapPostFix ]; then echo "[ERROR]: Propertiy SnapPostFix is not handed over - please investigate";exit 5;fi #Instance 00 + 01 share the same volumes - clone delete needs to be done once if [ $SAPSYSTEM != 01 ]; then #generating Volume List - assuming usage of qtrees - "IP-Adress:/VolumeName/qtree" xmlFile=$MOUNT_XML_PATH if [ -e $TMPFILE ];then rm $TMPFILE;fi numMounts=`xml_grep --count "/mountconfig/mount" $xmlFile | grep "total: " | awk '{ print $2 }'` i=1 while [ $i -le $numMounts ]; do xmllint --xpath "/mountconfig/mount[$i]/exportpath/text()" $xmlFile |awk -F"/" '{print $2}' >>$TMPFILE i=$((i + 1)) done DATAVOLUMES=`cat $TMPFILE |sort -u| awk -F $PROP_ClonePostFix '{ print $1 }'` #Create yml file and rund playbook for each volume for I in $DATAVOLUMES; do datavolumename="$I" snapshotpostfix="$PROP_SnapPostFix" clonepostfix="$PROP_ClonePostFix" create_yml_file run_ansible_playbook done else echo "[DEBUG]: Doing nothing .... Volume deleted in different Task" fi #Cleanup Temporary Files rm $xmlFile fi #Cleanup ######################################### #Cleanup Temporary Files if [ -e $TMPFILE ];then rm $TMPFILE;fi if [ -e $YAML_TMP ];then rm $YAML_TMP;fi exit 0
PlayBook NetApp_lama_Clonevolumes.yml
Le PlayBook qui s'exécute lors de l'étape Clonevolumes du workflow de clonage du système Lama est une combinaison de create_snapshot.yml
et create_clone.yml
(voir "Modules NetApp Ansible - fichiers YAML"). Ce manuel peut être facilement étendu pour couvrir d'autres cas d'utilisation, comme le clonage à partir des opérations de fractionnement de clones et secondaires.
root@sap-jump:~# cat /usr/sap/scripts/ansible/netapp_lama_CloneVolumes.yml --- - hosts: ontapservers connection: local collections: - netapp.ontap gather_facts: false name: netapp_lama_CloneVolumes tasks: - name: Create SnapShot na_ontap_snapshot: state: present snapshot: "{{ datavolumename }}{{ snapshotpostfix }}" use_rest: always volume: "{{ datavolumename }}" vserver: "{{ svmname }}" hostname: "{{ inventory_hostname }}" cert_filepath: "{{ certfile }}" key_filepath: "{{ keyfile }}" https: true validate_certs: false - name: Clone Volume na_ontap_volume_clone: state: present name: "{{ datavolumename }}{{ clonepostfix }}" use_rest: always vserver: "{{ svmname }}" junction_path: '/{{ datavolumename }}{{ clonepostfix }}' parent_volume: "{{ datavolumename }}" parent_snapshot: "{{ datavolumename }}{{ snapshotpostfix }}" hostname: "{{ inventory_hostname }}" cert_filepath: "{{ certfile }}" key_filepath: "{{ keyfile }}" https: true validate_certs: false
PlayBook NetApp_lama_ServiceConfigRemoval.yml
Manuel de vente exécuté pendant le ServiceConfigRemoval
La phase du workflow de destruction du système Lama est combinée à delete_clone.yml
et delete_snapshot.yml
(voir "Modules NetApp Ansible - fichiers YAML"). Il doit être aligné sur les étapes d'exécution du netapp_lama_CloneVolumes
manuel de vente.
root@sap-jump:~# cat /usr/sap/scripts/ansible/netapp_lama_ServiceConfigRemoval.yml --- - hosts: ontapservers connection: local collections: - netapp.ontap gather_facts: false name: netapp_lama_ServiceConfigRemoval tasks: - name: Delete Clone na_ontap_volume: state: absent name: "{{ datavolumename }}{{ clonepostfix }}" use_rest: always vserver: "{{ svmname }}" wait_for_completion: True hostname: "{{ inventory_hostname }}" cert_filepath: "{{ certfile }}" key_filepath: "{{ keyfile }}" https: true validate_certs: false - name: Delete SnapShot na_ontap_snapshot: state: absent snapshot: "{{ datavolumename }}{{ snapshotpostfix }}" use_rest: always volume: "{{ datavolumename }}" vserver: "{{ svmname }}" hostname: "{{ inventory_hostname }}" cert_filepath: "{{ certfile }}" key_filepath: "{{ keyfile }}" https: true validate_certs: false root@sap-jump:~#
Ansible PlayBook netapp_lama_ClearMountConfig.yml
Le PlayBook, qui est exécuté pendant la netapp_lama_ClearMountConfig
La phase du workflow d'actualisation du système Lama est combinée delete_clone.yml
et delete_snapshot.yml
(voir "Modules NetApp Ansible - fichiers YAML"). Il doit être aligné sur les étapes d'exécution du netapp_lama_CloneVolumes
manuel de vente.
root@sap-jump:~# cat /usr/sap/scripts/ansible/netapp_lama_ServiceConfigRemoval.yml --- - hosts: ontapservers connection: local collections: - netapp.ontap gather_facts: false name: netapp_lama_ServiceConfigRemoval tasks: - name: Delete Clone na_ontap_volume: state: absent name: "{{ datavolumename }}{{ clonepostfix }}" use_rest: always vserver: "{{ svmname }}" wait_for_completion: True hostname: "{{ inventory_hostname }}" cert_filepath: "{{ certfile }}" key_filepath: "{{ keyfile }}" https: true validate_certs: false - name: Delete SnapShot na_ontap_snapshot: state: absent snapshot: "{{ datavolumename }}{{ snapshotpostfix }}" use_rest: always volume: "{{ datavolumename }}" vserver: "{{ svmname }}" hostname: "{{ inventory_hostname }}" cert_filepath: "{{ certfile }}" key_filepath: "{{ keyfile }}" https: true validate_certs: false root@sap-jump:~#
Exemple de Ansible Inventory.yml
Ce fichier d'inventaire est créé dynamiquement lors de l'exécution du workflow et n'est présenté ici qu'à titre d'illustration.
ontapservers: hosts: grenada: ansible_host: "grenada" keyfile: "/usr/sap/scripts/ansible/certs/ontap.key" certfile: "/usr/sap/scripts/ansible/certs/ontap.pem" svmname: "svm-sap01" datavolumename: "HN9_sap" snapshotpostfix: " _snap_20221115" clonepostfix: "_clone_20221115"