Dépanner l’outil AzAcSnap (Azure Application Consistent Snapshot)
Cet article explique comment résoudre les problèmes lors de l’utilisation de l’outil AzAcSnap (Azure Application Consistent Snapshot) pour Azure NetApp Files et Azure Large Instance.
Vous pouvez rencontrer plusieurs problèmes courants lors de l’exécution de commandes AzAcSnap. Suivez les instructions pour résoudre les problèmes. Si vous rencontrez toujours des problèmes, ouvrez une demande de service du Support Microsoft à partir du Portail Azure et attribuez la demande à la file d’attente Large Instance SAP HANA.
La commande AzAcSnap ne s’exécute pas
Dans certains cas, AzAcSnap ne démarre pas en raison de l’environnement de l’utilisateur.
Échec de la création de CoreCLR
AzAcSnap est écrit dans .NET et coreCLR est un moteur d’exécution pour les applications .NET, effectuant des fonctions telles que le chargement de code d’octet IL, la compilation sur le code machine et le garbage collection. Dans ce cas, un problème environnemental bloque le démarrage du moteur CoreCLR.
Une cause courante est des autorisations limitées ou une configuration environnementale pour l’utilisateur du système d’exploitation AzAcSnap, généralement « azacsnap ».
L’erreur Failed to create CoreCLR, HRESULT: 0x80004005 peut être due au manque d’accès en écriture de l’utilisateur TMPDIRazacsnap au système.
Remarque
Toutes les lignes de commande commençant # par sont des commandes exécutées en tant que root, toutes les lignes de commande commençant > par sont exécutées en tant qu’utilisateur azacsnap .
Vérifiez la /tmp propriété et les autorisations (notez que dans cet exemple, seul l’utilisateur root peut lire et écrire dans /tmp) :
# ls -ld /tmp
drwx------ 9 root root 8192 Mar 31 10:50 /tmp
Une règle générale /tmp dispose des autorisations suivantes, ce qui permet à l’utilisateur azacsnap d’exécuter la commande azacsnap :
# ls -ld /tmp
drwxrwxrwt 9 root root 8192 Mar 31 10:51 /tmp
S’il n’est pas possible de modifier les /tmp autorisations d’annuaire, créez un utilisateur spécifique TMPDIR.
Faites-en un TMPDIR pour l’utilisateur azacsnap :
> mkdir /home/azacsnap/_tmp
> export TMPDIR=/home/azacsnap/_tmp
> azacsnap -c about
WKO0XXXXXXXXXXXNW
Wk,.,oxxxxxxxxxxx0W
0;.'.;dxxxxxxxxxxxKW
Xl'''.'cdxxxxxxxxxdkX
Wx,''''.,lxxxxdxdddddON
0:''''''.;oxdddddddddxKW
Xl''''''''':dddddddddddkX
Wx,''''''''':ddddddddddddON
O:''''''''',xKxddddddoddod0W
Xl''''''''''oNW0dooooooooooxX
Wx,,,,,,'','c0WWNkoooooooooookN
WO:',,,,,,,,;cxxxxooooooooooooo0W
Xl,,,,,,,;;;;;;;;;;:llooooooooldX
Nx,,,,,,,,,,:c;;;;;;;;coooollllllkN
WO:,,,,,,,,,;kXkl:;;;;,;lolllllllloOW
Xl,,,,,,,,,,dN WNOl:;;;;:lllllllllldK
0c,;;;;,,,;lK NOo:;;:clllllllllo0W
WK000000000N NK000KKKKKKKKKKXW
Azure Application Consistent Snapshot Tool
AzAcSnap 7a (Build: 1AA8343)
Important
La modification de TMPDIR l’utilisateur doit être rendue permanente en modifiant le profil de l’utilisateur (par exemple $HOME/.bashrc , ou $HOME/.bash_profile). Il faudrait également propre le redémarrage du TMPDIR système, ce qui est généralement automatique pour /tmp.
Consulter les fichiers journaux, les fichiers de résultats et syslog
Certaines des meilleures sources d’informations pour l’examen des problèmes AzAcSnap sont les fichiers journaux, les fichiers de résultats et le journal système.
Fichiers journaux
Les fichiers journaux AzAcSnap sont stockés dans le répertoire configuré par le paramètre logPath dans le fichier de configuration AzAcSnap. Le nom de fichier de configuration par défaut est azacsnap.json, et la valeur par défaut pour logPath est ./logs. Cela signifie que les fichiers journaux sont écrits dans le répertoire ./logs associé à l’emplacement où la commande azacsnap est exécutée. Si vous créez un emplacement absolu logPath, tel que /home/azacsnap/logs, azacsnap génère toujours les journaux dans /home/azacsnap/logs, quel que soit l’emplacement où vous exécutez la commande azacsnap.
Le nom de fichier journal est basé sur le nom de l’application, azacsnap, l’exécution de commande avec -c, par exemple backup, test ou details, et le nom de fichier de configuration par défaut, tel que azacsnap.json. Avec la commande -c backup, un nom de fichier journal par défaut serait azacsnap-backup-azacsnap.log, écrit dans le répertoire configuré par logPath.
Cette convention d’affectation de noms permet d’obtenir plusieurs fichiers de configuration, un par base de données, afin de localiser les fichiers journaux associés. Si le nom de fichier de configuration est SID.json, le nom de fichier journal lors de l’utilisation de l’option azacsnap -c backup --configfile SID.json est azacsnap-backup-SID.log.
Fichiers de résultats et syslog
Pour la commande -c backup, AzAcSnap écrit dans un fichier *.result. L’objectif du fichier *.result est de fournir une confirmation générale de la réussite/de l’échec. Si le fichier *.result est vide, supposons que c’est un échec. Toute sortie écrite dans le fichier *.result est également sortie dans le journal système (par exemple, /var/log/messages) à l’aide de la commande logger. Le nom de fichier *.result a le même nom de base que le fichier journal pour permettre la mise en correspondance du fichier de résultat avec le fichier de configuration et le fichier journal de sauvegarde. Le fichier *.result entre dans le même emplacement que les autres fichiers journaux et est un fichier de sortie de ligne simple.
Exemple de réussite :
Sortie dans le fichier *.result :
Database # 1 (PR1) : completed okSortie vers
/var/log/messages:Dec 17 09:01:13 azacsnap-rhel azacsnap: Database # 1 (PR1) : completed ok
Exemple de sortie où une défaillance s’est produite et AzAcSnap a capturé l’échec :
Sortie dans le fichier *.result :
Database # 1 (PR1) : failedSortie vers
/var/log/messages:Dec 19 09:00:30 azacsnap-rhel azacsnap: Database # 1 (PR1) : failed
Dépanner un échec de la commande « test storage »
La commande azacsnap -c test --test storage peut ne pas se terminer correctement.
Vérifier les pare-feu réseau
La communication avec Azure NetApp Files peut échouer ou expirer. Pour résoudre le problème, assurez-vous que des règles de pare-feu ne bloquent pas le trafic sortant du système exécutant AzAcSnap vers les adresses et ports TCP/IP suivants :
https://management.azure.com:443https://login.microsoftonline.com:443
Utiliser Cloud Shell pour valider les fichiers de configuration
Vous pouvez tester si le principal de service est correctement configuré à l’aide de Cloud Shell via le Portail Azure. À l’aide de tests Cloud Shell de configuration correcte, contourner les contrôles réseau au sein d’un réseau virtuel ou d’une machine virtuelle.
Dans le Portail Azure, ouvrez une session Cloud Shell.
Créez un répertoire de test, par exemple
mkdir azacsnap.Basculez sur le répertoire azacsnap et téléchargez la dernière version d’AzAcSnap.
wget https://aka.ms/azacsnapinstallerCréez le programme d’installation exécutable, par exemple
chmod +x azacsnapinstaller.Extrayez le fichier binaire pour le test.
./azacsnapinstaller -X -d .Les résultats sont semblables à la sortie suivante :
+-----------------------------------------------------------+ | Azure Application Consistent Snapshot Tool Installer | +-----------------------------------------------------------+ |-> Installer version '5.0.2_Build_20210827.19086' |-> Extracting commands into .. |-> Cleaning up .NET extract dirUtilisez l’icône Cloud Shell Charger/Télécharger pour charger le fichier du principal de service, azureauth.json, et le fichier de configuration AzAcSnap, tel que azacsnap.json, pour le test.
Exécutez le test
storage../azacsnap -c test --test storageRemarque
L’exécution de la commande de test peut prendre environ 90 secondes.
Échec du test sur Azure Large Instance
L’exemple d’erreur suivant consiste à exécuter azacsnap sur Azure Large Instance :
azacsnap -c test --test storage
The authenticity of host '172.18.18.11 (172.18.18.11)' can't be established.
ECDSA key fingerprint is SHA256:QxamHRn3ZKbJAKnEimQpVVCknDSO9uB4c9Qd8komDec.
Are you sure you want to continue connecting (yes/no)?
Pour résoudre cette erreur, ne répondez pas yes. Assurez-vous que votre adresse IP de stockage est correcte. Vous pouvez confirmer l’adresse IP de stockage auprès de l’équipe des opérations Microsoft.
L’erreur s’affiche généralement lorsque l’utilisateur de stockage Azure Large Instance n’a pas accès au stockage sous-jacent. Pour déterminer si l’utilisateur de stockage a accès au stockage, exécutez la commande ssh pour valider la communication avec la plateforme de stockage.
ssh <StorageBackupname>@<Storage IP address> "volume show -fields volume"
L’exemple suivant illustre la sortie attendue :
ssh clt1h80backup@10.8.0.16 "volume show -fields volume"
vserver volume
--------------------------------- ------------------------------
osa33-hana-c01v250-client25-nprod hana_data_h80_mnt00001_t020_vol
osa33-hana-c01v250-client25-nprod hana_data_h80_mnt00002_t020_vol
Échec du test avec Azure NetApp Files
L’exemple d’erreur suivant consiste à exécuter azacsnap avec Azure NetApp Files :
azacsnap --configfile azacsnap.json.NOT-WORKING -c test --test storage
BEGIN : Test process started for 'storage'
BEGIN : Storage test snapshots on 'data' volumes
BEGIN : 1 task(s) to Test Snapshots for Storage Volume Type 'data'
ERROR: Could not create StorageANF object [authFile = 'azureauth.json']
Pour résoudre cette erreur :
Vérifiez l’existence du fichier du principal de service, azureauth.json, comme défini dans le fichier de configuration azacsnap.json.
Consultez le fichier journal, par exemple logs/azacsnap-test-azacsnap.log, pour voir si le contenu du fichier du principal de service est correct. La sortie de fichier journal suivante montre que la clé secrète client n’est pas valide.
[19/Nov/2020:18:39:49 +13:00] DEBUG: [PID:0020080:StorageANF:659] [1] Innerexception: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException AADSTS7000215: Invalid client secret is provided.Consultez le fichier journal pour voir si le principal de service a expiré. L’exemple de fichier journal suivant montre que les clés secrètes clients ont expiré.
[19/Nov/2020:18:41:10 +13:00] DEBUG: [PID:0020257:StorageANF:659] [1] Innerexception: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException AADSTS7000222: The provided client secret keys are expired. Visit the Azure Portal to create new keys for your app, or consider using certificate credentials for added security: https://learn.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials
Conseil
Pour plus d’informations sur la génération d’un nouveau principal de service, reportez-vous à la section Activer la communication avec le stockage du guide Installer l’outil Azure Application Consistent Snapshot.
Dépanner un échec de la commande « test hana »
La commande azacsnap -c test --test hana peut ne pas se terminer correctement.
Commande introuvable
Lors de la configuration de la communication avec SAP HANA, le programme hdbuserstore est utilisé pour créer les paramètres d’une communication sécurisée. AzAcSnap nécessite également le programme hdbsql pour toutes les communications avec SAP HANA. Ces programmes sont généralement sous /usr/sap/<SID>/SYS/exe/hdb/ ou /usr/sap/hdbclient et doivent se trouver dans le $PATH de l’utilisateur.
Dans l’exemple suivant, la commande
hdbsqln’est pas dans le$PATHde l’utilisateur.hdbsql -n 172.18.18.50 - i 00 -U AZACSNAP "select version from sys.m_database"If 'hdbsql' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf hdbsqlL’exemple suivant ajoute temporairement la commande
hdbsqlau$PATHde l’utilisateur, ce qui permet àazacsnapde s’exécuter correctement.export PATH=$PATH:/hana/shared/H80/exe/linuxx86_64/hdb/
Assurez-vous que le programme d’installation a ajouté l’emplacement de ces fichiers au $PATH de l’utilisateur AzAcSnap.
Remarque
Pour ajouter définitivement au $PATH de l’utilisateur, mettez à jour le fichier $HOME/.profile de l’utilisateur.
Valeur non valide pour la clé
Cette sortie de commande montre que la clé de connexion n’a pas été configurée correctement avec la commande hdbuserstore Set.
hdbsql -n 172.18.18.50 -i 00 -U AZACSNAP "select version from sys.m_database"
* -10104: Invalid value for KEY (AZACSNAP)
Pour plus d’informations sur la configuration de la hdbuserstore, consultez Bien démarrer avec AzAcSnap.
Échec du test
Lors de la validation de la communication avec SAP HANA en exécutant un test avec azacsnap -c test --test hana, vous pouvez recevoir l’erreur suivante :
> azacsnap -c test --test hana
BEGIN : Test process started for 'hana'
BEGIN : SAP HANA tests
CRITICAL: Command 'test' failed with error:
Cannot get SAP HANA version, exiting with error: 127
Pour résoudre cette erreur :
Vérifiez le fichier de configuration, par exemple azacsnap.json, de chaque instance HANA pour vous assurer que les valeurs de la base de données SAP HANA sont correctes.
Exécutez la commande suivante pour vérifier que la commande
hdbsqlse trouve dans le chemin d’accès et qu’elle peut se connecter au serveur SAP HANA.hdbsql -n 172.18.18.50 - i 00 -d SYSTEMDB -U AZACSNAP "\s"L’exemple suivant montre la sortie lorsque la commande s’exécute correctement :
host : 172.18.18.50 sid : H80 dbname : SYSTEMDB user : AZACSNAP kernel version: 2.00.040.00.1553674765 SQLDBC version: libSQLDBCHDB 2.04.126.1551801496 autocommit : ON locale : en_US.UTF-8 input encoding: UTF8 sql port : saphana1:30013
Erreur de privilège insuffisant
Si l’exécution de azacsnap présente une erreur telle que * 258: insufficient privilege, vérifiez que l’utilisateur dispose des privilèges d’utilisateur de base de données AZACSNAP appropriés configurés selon le guide d’installation. Vérifiez les privilèges de l’utilisateur avec la commande suivante :
hdbsql -U AZACSNAP "select GRANTEE,GRANTEE_TYPE,PRIVILEGE,IS_VALID,IS_GRANTABLE from sys.granted_privileges " | grep -i -e GRANTEE -e azacsnap
Cette commande doit retourner la sortie suivante :
GRANTEE,GRANTEE_TYPE,PRIVILEGE,IS_VALID,IS_GRANTABLE
"AZACSNAP","USER","BACKUP ADMIN","TRUE","FALSE"
"AZACSNAP","USER","CATALOG READ","TRUE","FALSE"
"AZACSNAP","USER","CREATE ANY","TRUE","TRUE"
L’erreur peut fournir des informations supplémentaires permettant de déterminer les privilèges SAP HANA requis, par exemple Detailed info for this error can be found with guid '99X9999X99X9999X99X99XX999XXX999' SQLSTATE: HY000. Dans ce cas, suivez les instructions sur la page Portail d’aide SAP – GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS, qui recommande d’utiliser la requête SQL suivante pour déterminer les détails du privilège requis :
CALL SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS ('99X9999X99X9999X99X99XX999XXX999', ?)
GUID,CREATE_TIME,CONNECTION_ID,SESSION_USER_NAME,CHECKED_USER_NAME,PRIVILEGE,IS_MISSING_ANALYTIC_PRIVILEGE,IS_MISSING_GRANT_OPTION,DATABASE_NAME,SCHEMA_NAME,OBJECT_NAME,OBJECT_TYPE
"99X9999X99X9999X99X99XX999XXX999","2021-01-01 01:00:00.180000000",120212,"AZACSNAP","AZACSNAP","DATABASE ADMIN or DATABASE BACKUP ADMIN","FALSE","FALSE","","","",""
Dans l’exemple précédent, le fait d’ajouter le privilège DATABASE BACKUP ADMIN à l’utilisateur AZACSNAP de SYSTEMDB devrait résoudre l’erreur de privilège insuffisant.
Étapes suivantes
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour