Skip to main content
NetApp Solutions SAP
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Provider-Skriptkonfiguration und Ansible Playbooks

Beitragende

Die folgende Provider-Konfigurationsdatei, das Ausführungsskript und Ansible-Playbooks werden während der Beispielimplementierung und der Workflow-Ausführung in dieser Dokumentation verwendet.

Hinweis Die Beispielskripte werden wie IS bereitgestellt und von NetApp nicht unterstützt. Sie können die aktuelle Version der Skripte per E-Mail an ng-sapcc@netapp.com anfordern.

Konfigurationsdatei des Anbieters netapp_Clone.conf

Die Konfigurationsdatei wird wie im beschrieben erstellt "SAP Lama Documentation – Konfigurieren von registrierten Skripten für SAP-Host-Agent". Diese Konfigurationsdatei muss sich auf dem Ansible-Steuerungsknoten befinden, auf dem der SAP-Host-Agent installiert ist.

Der konfigurierte os-Benutzer sapuser Zum Ausführen des Skripts und der sogenannten Ansible Playbooks müssen die entsprechenden Berechtigungen vorhanden sein. Sie können das Skript in einem gemeinsamen Skriptverzeichnis platzieren. SAP Lama kann beim Aufruf des Skripts mehrere Parameter bereitstellen.

Zusätzlich zu den benutzerdefinierten Parametern PARAM_ClonePostFix, PROP_ClonePostFix, PARAM_ClonePostFix, und PROP_ClonePostFix, Viele andere können übergeben werden, wie in der gezeigt "SAP Lama-Dokumentation".

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

Provider-Skript netapp_clone.sh

Das Provider-Skript muss in gespeichert sein /usr/sap/scripts Wie in der Provider-Konfigurationsdatei konfiguriert.

Variablen

Die folgenden Variablen sind im Skript hartcodiert und müssen entsprechend angepasst werden.

  • PRIMARY_CLUSTER=<hostname of netapp cluster>

  • PRIMARY_SVM=<SVM name where source system volumes are stored>

Die Zertifikatdateien PRIMARY_KEYFILE=/usr/sap/scripts/ansible/certs/ontap.key Und PRIMARY_CERTFILE=/usr/sap/scripts/ansible/certs/ontap.pem Muss wie in beschrieben bereitgestellt werden "NetApp Ansible Module – ONTAP vorbereiten".

Hinweis Wenn für verschiedene SAP-Systeme unterschiedliche Cluster oder SVMs erforderlich sind, können diese Variablen als Parameter in der SAP Lama-Provider-Definition hinzugefügt werden.

Funktion: Inventurdatei erstellen

Um die Ansible-Playbook-Ausführung dynamischer zu machen inventory. yml Datei wird während des Betriebs erstellt. Einige statische Werte werden im Abschnitt Variable konfiguriert und einige werden während der Ausführung dynamisch erzeugt.

Funktion: Ansible-Playbook ausführen

Diese Funktion wird verwendet, um das Ansible-Playbook zusammen mit dem dynamisch erstellten auszuführen inventory.yml Datei: Die Namenskonvention für Playbooks lautet netapp_lama_${HookOperationName}.yml. Die Werte für ${HookOperationName} Ist von der Lama-Operation abhängig und wird von Lama als Kommandozeilenparameter übergeben.

Abschnitt Main

Dieser Abschnitt enthält den Hauptausführungsplan. Die Variable ${HookOperationName} Enthält den Namen des Lama-Ersatzschritts und wird von Lama zur Verfügung gestellt, wenn das Skript aufgerufen wird.

  • Werte mit dem Bereitstellungs-Workflow für Systemklone und Systemkopien:

    • KlonVolumes

    • PostCloneVolumes

  • Wert mit dem Workflow zum Löschen des Systems:

    • ServiceConfigRemoval

  • Nutzen des Workflows zur Systemaktualisierung:

    • ClearMountConfig

HookOperationName = CloneVolumes

Mit diesem Schritt wird das Ansible Playbook ausgeführt und der Snapshot Kopier- und Klonvorgang wird gestartet. Die Volume-Namen und Mount-Konfiguration werden von SAP Lama über eine in der Variable definierte XML-Datei übergeben $MOUNT_XML_PATH. Diese Datei wird gespeichert, da sie später im Schritt verwendet wird FinalizeCloneVolumes So erstellen Sie die neue Mount-Point-Konfiguration. Die Volume-Namen werden aus der XML-Datei extrahiert und das Ansible-Klon-Playbook für jedes Volume wird ausgeführt.

Hinweis In diesem Beispiel teilen sich DIE AS-Instanz und die zentralen Dienste dasselbe Volume. Daher wird das Klonen von Volumes nur dann ausgeführt, wenn die SAP Instanznummer angegeben ist ($SAPSYSTEM) Ist nicht 01. Dies kann in anderen Umgebungen variieren und muss entsprechend geändert werden.

HookOperationName = PostCloneVolumes

In diesem Schritt werden die benutzerdefinierten Eigenschaften angezeigt ClonePostFix Und SnapPostFix Und die Mount-Point-Konfiguration für das Zielsystem bleibt erhalten.

Die benutzerdefinierten Eigenschaften werden zu einem späteren Zeitpunkt als Eingabe verwendet, wenn das System während des außer Betrieb gesetzt wird ServiceConfigRemoval Oder ClearMountConfig Signifikant. Das System ist so entworfen, dass die Einstellungen der benutzerdefinierten Parameter beibehalten werden, die während des Workflows zur Systembereitstellung angegeben wurden.

Die in diesem Beispiel verwendeten Werte sind ClonePostFix=_clone_20221115 Und SnapPostFix=_snap_20221115.

Für das Volume HN9_sap, Die dynamisch erstellte Ansible-Datei enthält die folgenden Werte: datavolumename: HN9_sap, snapshotpostfix: _snap_20221115, und clonepostfix: _clone_20221115.

Was zu dem Snapshot-Namen auf dem Volume HN9_sap führt HN9_sap_snap_20221115 Und den Namen des erstellten Volume-Klons HN9_sap_clone_20221115.

Hinweis Benutzerdefinierte Eigenschaften können in jeder Hinsicht verwendet werden, um Parameter zu erhalten, die während des Bereitstellungsprozesses verwendet werden.

Die Mount-Point-Konfiguration wird aus der XML-Datei extrahiert, die Lama im übergeben hat CloneVolume Schritt: Der ClonePostFix Wird den Volume-Namen hinzugefügt und über die Standard-Skriptausgabe an Lama zurückgesendet. Die Funktionalität wird in beschrieben "SAP-Hinweis 1889590".

Hinweis In diesem Beispiel werden qtrees auf dem Storage-System als gemeinsame Methode zum Speichern verschiedener Daten auf einem einzelnen Volume verwendet. Beispiel: HN9_sap Hält die Mount-Punkte für /usr/sap/HN9, /sapmnt/HN9, und /home/hn9adm. Unterverzeichnisse funktionieren auf die gleiche Weise. Dies kann in anderen Umgebungen variieren und muss entsprechend geändert werden.

HookOperationName = ServiceConfigRemoval

In diesem Schritt wird das Ansible-Playbook, das für das Löschen der Volume-Klone verantwortlich ist, ausgeführt.

Die Volume-Namen werden von SAP Lama über die Mount-Konfigurationsdatei und die benutzerdefinierten Eigenschaften übergeben ClonePostFix Und SnapPostFix Werden verwendet, um die Werte der Parameter, die ursprünglich während des System-Provisioning-Workflows angegeben wurden, zu übergeben (siehe Hinweis unter HookOperationName = PostCloneVolumes).

Die Volume-Namen werden aus der XML-Datei extrahiert und das Ansible-Klon-Playbook für jedes Volume wird ausgeführt.

Hinweis In diesem Beispiel teilen sich DIE AS-Instanz und die zentralen Dienste dasselbe Volume. Daher wird das Volume-Löschen nur bei der SAP-Instanznummer ausgeführt ($SAPSYSTEM) Ist nicht 01. Dies kann in anderen Umgebungen variieren und muss entsprechend geändert werden.

HookOperationName = ClearMountConfig

In diesem Schritt wird das Ansible-Playbook ausgeführt, das während der Systemaktualisierung die Löschung von Volume-Klonen übernimmt.

Die Volume-Namen werden von SAP Lama über die Mount-Konfigurationsdatei und die benutzerdefinierten Eigenschaften übergeben ClonePostFix Und SnapPostFix Werden verwendet, um die Werte der Parameter zu übergeben, die ursprünglich während des System-Provisioning-Workflows angegeben wurden.

Die Volume-Namen werden aus der XML-Datei extrahiert und das Ansible-Klon-Playbook für jedes Volume wird ausgeführt.

Hinweis In diesem Beispiel teilen sich DIE AS-Instanz und die zentralen Dienste dasselbe Volume. Daher wird das Löschen von Volumes nur bei der SAP-Instanznummer ausgeführt ($SAPSYSTEM) Ist nicht 01. Dies kann in anderen Umgebungen variieren und muss entsprechend geändert werden.
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

Ansible-Playbook netapp_lama_KlonVolumes.yml

Das Playbook, das während des CloneVolumes-Schritts des Arbeitsablaufs des Lama-Systems ausgeführt wird, ist eine Kombination aus create_snapshot.yml Und create_clone.yml (Siehe "NetApp Ansible Module – YAML-Dateien"). Dieses Playbook kann einfach erweitert werden, um weitere Anwendungsfälle wie das Klonen von sekundären Operationen und Klontrennungen abzudecken.

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

Ansible-Playbook netapp_lama_ServiceConfigRemoval.yml

Das Playbook, das während des ausgeführt wird ServiceConfigRemoval Phase des Lama-System zerstörenden Workflows ist eine Kombination von delete_clone.yml Und delete_snapshot.yml (Siehe "NetApp Ansible Module – YAML-Dateien"). Sie muss an den Ausführungsschritten des ausgerichtet sein netapp_lama_CloneVolumes playbook.

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

Das Playbook, das während des ausgeführt wird netapp_lama_ClearMountConfig Die Phase des Arbeitsablaufs zur Systemaktualisierung ist eine Kombination aus delete_clone.yml Und delete_snapshot.yml (Siehe "NetApp Ansible Module – YAML-Dateien"). Sie muss an den Ausführungsschritten des ausgerichtet sein netapp_lama_CloneVolumes playbook.

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:~#

Beispiel für Ansible-Inventar.YML

Diese Bestandsdatei wird während der Workflow-Ausführung dynamisch erstellt, und sie wird hier nur zur Illustration angezeigt.

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"