Partager via

Résoudre les problèmes liés à l’agent de clôture Azure dans un cluster RHEL Pacemaker

S’applique à : ✔️ Machines virtuelles Linux

Cet article vous aide à résoudre les problèmes d’agent de clôture Azure dans un cluster Pacemaker qui s’exécute sur Red Hat Enterprise Linux (RHEL) et qui utilise l’agent de clôture Azure pour implémenter un appareil Shoot The Other Node in the Head (STONITH).

Aperçu

L’agent de clôture Azure utilise le programme Python situé à l’emplacement /usr/sbin/fence_azure_arm. L’agent de ressources de cluster (RA) utilisé pour implémenter un appareil STONITH appelle ce programme avec des paramètres appropriés et l’utilise pour communiquer avec la plateforme Azure via des appels d’API.

Comme introduit dans RHEL - Créer un appareil STONITH, les rôles personnalisés fournissent des autorisations pour l’agent de clôture afin d’effectuer les actions suivantes :

  • powerOff
  • start

Lorsqu’une machine virtuelle non saine est détectée, l’agent de clôture utilise les actions précédentes pour désactiver la machine virtuelle et la redémarrer, fournissant ainsi un appareil STONITH.

Symptômes

Lorsque vous vérifiez l’état de la ressource du cluster en exécutant la commande suivante, les ressources de l’agent de clôture Azure ne parviennent pas à démarrer, signalez une « erreur inconnue » et affichez un Stopped état :

sudo pcs status

Voici un exemple de sortie de commande :

Cluster name: nw1-azr
Cluster Summary:
  * Stack: corosync
  * Current DC: RHEL-SAP01 (version 2.0.5-9.el8_4.8-ba59be7122) - partition with quorum
  * Last updated: Fri Jun  7 01:34:38 2023
  * Last change:  Fri Jun  7 01:34:23 2023 by root via cibadmin on RHEL-SAP01
  * 2 nodes configured
  * 3 resource instances configured
Node List:
  * Online: [ RHEL-SAP01 RHEL-SAP02 ]
Full List of Resources:
  * rsc_st_azure        (stonith:fence_azure_arm):       Stopped
  * Clone Set: health-azure-events-clone [health-azure-events]:
    * Started: [ RHEL-SAP01 RHEL-SAP02 ]
Failed Resource Actions:
  * rsc_st_azure_start_0 on RHEL-SAP01 'error' (1): call=20, status='complete', exitreason='', last-rc-change='2023-06-04 01:34:24Z', queued=0ms, exec=4041ms
  * rsc_st_azure_start_0 on RHEL-SAP02 'error' (1): call=14, status='complete', exitreason='', last-rc-change='2023-06-04 01:34:28Z', queued=0ms, exec=4243ms
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Cause 1 : Problèmes de connectivité de point de terminaison

Si vous vérifiez le fichier journal /var/log/messages , une sortie semblable à l’exemple suivant s’affiche :

2021-03-15T20:23:15.441083+00:00 NodeName pacemaker-fenced[2550]:  warning: fence_azure_arm[21839] stderr: [ 2021-03-15 20:23:15,398 ERROR: Failed: Azure Error: AuthenticationFailed ]
2021-03-15T20:23:15.441260+00:00 NodeName pacemaker-fenced[2550]:  warning: fence_azure_arm[21839] stderr: [ Message: Authentication failed. ]
2021-03-15T20:23:15.441668+00:00 NodeName pacemaker-fenced[2550]:  warning: fence_azure_arm[21839] stderr: [  ]

Pour résoudre les problèmes de connectivité de point de terminaison, procédez comme suit :

  1. Testez la connectivité aux points de terminaison publics de l’API de gestion Azure.

    Comme décrit dans la connectivité de point de terminaison public pour Machines Virtuelles à l’aide d’Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP, il est important de vérifier la connectivité sortante aux points de terminaison publics de l’API de gestion Azure à l’aide des URL suivantes :

    • https://management.azure.com
    • https://login.microsoftonline.com

    Utilisez la commande ou curlnc la commande suivante telnetpour tester la connectivité aux deux URL.

    Note

    Telnet ou curl n’est généralement pas disponible pour les machines virtuelles clientes.

    telnet management.azure.com 443

    curl -v telnet://management.azure.com:443

    nc -z -v management.azure.com 443

  2. Vérifiez qu’un nom d’utilisateur et un mot de passe valides sont configurés pour l’appareil STONITH.

    • Lors de l’utilisation du principal de service :

      Une raison courante pour laquelle l’appareil STONITH échoue est l’utilisation de valeurs de nom d’utilisateur ou de mot de passe non valides. Pour vérifier cela, utilisez le programme fence_azure_arm , comme indiqué dans la commande suivante. Les valeurs de nom d’utilisateur et de mot de passe sont créées en fonction de RHEL : créez un appareil STONITH.

      sudo /usr/sbin/fence_azure_arm --action=list --username='<username>' --password='<password>' --tenantId=<tenant ID> --resourceGroup=<resource group>

      Note

      Remplacez les <username>valeurs , et <resource group> <password><tenant ID>remplacez les valeurs en conséquence.

      Cette commande doit retourner les noms de nœuds des machines virtuelles du cluster. Si la commande ne parvient pas à retourner, réexécutez-la avec l’indicateur -v pour activer la sortie détaillée et l’indicateur -D pour activer la sortie de débogage, comme indiqué dans la commande suivante :

      sudo /usr/sbin/fence_azure_arm --action=list --username='<user name>' --password='<password>' --tenantId=<tenant ID> --resourceGroup=<resource group> -v -D /var/tmp/debug-fence.out

      Note

      Remplacez les <user name>valeurs , et <resource group> <password><tenant ID>remplacez les valeurs en conséquence.

    • Lors de l’utilisation de l’identité managée :

      Vérifiez les valeurs de nom d’utilisateur et de mot de passe en exécutant la commande suivante :

      sudo /usr/sbin/fence_azure_arm --action=list --msi --resourceGroup=<resource group> -v -D /var/tmp/debug-fence.out

      Note

      Remplacez la <resource group> valeur en conséquence.

Cause 2 : Échecs d’authentification

Si vous vérifiez le fichier journal /var/log/messages , une sortie semblable à l’exemple suivant s’affiche :

2020-04-06T10:06:47.779470+00:00 VM1 pacemaker-controld[29309]: notice: Result of probe operation for rsc_st_azure on VM1: 7 (not running)
2020-04-06T10:06:51.045519+00:00 VM1 pacemaker-execd[29306]: notice: executing - rsc:rsc_st_azure action:start call_id:52
2020-04-06T10:06:52.826702+00:00 VM1 /fence_azure_arm: Failed: AdalError: Get Token request returned http error: 400 and server response: {"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier '<application ID>'
was not found in the directory '<directory name>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant.
You may have sent your authentication request to the wrong tenant.\r\nTrace ID: 9d86f824-52c1-45a8-b24f-c81473122d00\r\nCorrelation ID: 7dd6de5d-1d6a-4950-be8b-9a2cb2df8553\r\nTimestamp:2020-04-06 10:06:52Z","error_codes":[700016],"timestamp":"2020-04-06 10:06:52Z","trace_id":"9d86f824-52c1-45a8-b24f-c81473122d00",
"correlation_id":"7dd6de5d-1d6a-4950-be8b-9a2cb2df8553","error_uri":"https://login.microsoftonline.com/error?code=700016 "}

Pour résoudre les échecs d’authentification, procédez comme suit :

  1. Vérifiez l’ID de locataire de l’application Microsoft Entra, l’ID d’application, la connexion et les détails du mot de passe à partir de l’Portail Azure.

  2. Reconfigurez l’agent de clôture dans le cluster :

    sudo pcs property set maintenance-mode=true

sudo pcs cluster edit

  3. Modifiez les paramètres des ressources de l’agent de clôture Azure, puis enregistrez les modifications :

    sudo pcs property set maintenance-mode=false

  4. Vérifiez l’état du cluster pour vérifier que les problèmes liés à l’agent de clôture sont résolus :

    sudo pcs status

Cause 3 : Autorisations insuffisantes

Si vous vérifiez le fichier journal /var/log/messages , une sortie semblable à l’exemple suivant s’affiche :

Apr 2 00:49:57 heeudpgscs01 stonith-ng[105424]: warning: fence_azure_arm[109393] stderr: [ 2020-04-02 00:49:56,978 ERROR: Failed: Azure Error: AuthorizationFailed ]
Apr 2 00:49:57 heeudpgscs01 stonith-ng[105424]: warning: fence_azure_arm[109393] stderr: [ Message: The client '<client ID>' with object id '<object ID>' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Compute' or the scope is invalid. If access was recently granted, please refresh your credentials. ]

Pour résoudre les problèmes d’autorisations insuffisantes, procédez comme suit :

  1. Vérifiez la définition de rôle personnalisée comme Linux Fence Agent Role décrit dans Créer un rôle personnalisé pour l’agent de clôture. Le nom du rôle peut varier pour différents clients.

  2. Vérifiez si l’application de l’agent de clôture a attribué ce rôle personnalisé à la machine virtuelle affectée. Si ce n’est pas le cas, affectez le rôle personnalisé à la machine virtuelle par le biais du contrôle d’accès.

  3. Démarrez le cluster Pacemaker. Il doit commencer avec l’agent de clôture.

  4. Vérifiez l’état du cluster pour vérifier que les problèmes liés à l’agent de clôture sont résolus :

    sudo pcs status

Cause 4 : Échec de la négociation SSL

Si vous vérifiez le fichier journal /var/log/messages , une sortie semblable à l’exemple suivant s’affiche :

warning: fence_azure_arm[28114] stderr: [ 2021-06-24 07:59:29,832 ERROR: Failed: Error occurred in request., SSLError: HTTPSConnectionPool(host='management.azure.com ', port=443): Max retries exceeded with url: /subscriptions/<subscription ID>/resourceGroups/<resource group>/providers/Microsoft.Compute/virtualMachines?api-version=2019-03-01 (Caused by SSLError(SSLError('bad handshake: SysCallError(-1, 'Unexpected EOF')',),)) ]

Testez la connectivité à partir des nœuds affectés en exécutant la commande suivante openssl :

openssl s_client -connect management.azure.com:443

Vous constatez que la sortie de la commande n’affiche pas l’établissement d’une liaison de certificat complète :

CONNECTED(00000003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1625235527
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

Voici les causes possibles de l’échec de vérification du certificat :

  • Un périphérique réseau ou un pare-feu effectue une inspection des paquets ou modifie les connexions TLS (Transparent Layer Socket).
  • Taille maximale de l’unité de transmission (MTU).

Si vous utilisez Pare-feu Azure pour protéger les nœuds, veillez à ajouter les balises suivantes à l’application ou aux règles réseau pour résoudre les problèmes liés à l’agent de clôture :

Application Rules:
ApiManagement, AppServiceManagement, AzureCloud
Network Rules:
AppServiceEnvironment

Prochaines étapes

Si vous avez besoin d’aide supplémentaire, ouvrez une demande de support avec une copie du fichier, car elle est requise à des fins de debug-fence.out résolution des problèmes.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.