Dépannage des problèmes d'état "JOINING"des machines virtuelles CPS-DRA dans le cluster Docker

Options de téléchargement

  • PDF     (263.7 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
Mis à jour:25 juin 2024
ID du document:222069

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    JOINING Ce document décrit comment dépanner les problèmes d'état avec la machine virtuelle (VM) de Cisco Policy Suite (CPS)-Diameter Routing Agent (DRA).

    Conditions préalables

    Exigences

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • Linux
    • CPS
      •
    note-icon

    Remarque : Cisco recommande que vous ayez un accès racine privilégié à l'interface de ligne de commande CPS DRA.

    Composants utilisés

    Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

    • CPS-DRA 22.2
    • Système d'informatique unifiée (UCS)-B
      •

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

    Informations générales

    L'agent de routage de diamètre virtuel (vDRA) CPS sert de composant opérationnel au sein d'un réseau, guidant les messages vers leurs noeuds de destination prévus grâce à l'utilisation d'algorithmes de routage.

    Le rôle central de CPS vDRA implique l'acheminement des messages et la transmission ultérieure des réponses à leurs points d'origine d'origine.

    Comprenant un ensemble de machines virtuelles (VM) orchestrées en tant que cluster à l'aide de moteurs Docker, CPS vDRA se compose d'entités distinctes, à savoir les machines virtuelles Master, Control, Director, Distributor et Worker.

    admin@orchestrator[master-1]# show docker engine
    Fri Jul 14 09:36:18.635 UTC+00:00
    MISSED 
    ID STATUS PINGS 
    ----------------------------------
    control-1 CONNECTED 0 
    control-2 CONNECTED 0 
    director-1 CONNECTED 0 
    director-2 CONNECTED 0 
    director-3 CONNECTED 0 
    director-4 CONNECTED 0 
    director-5 CONNECTED 0 
    director-6 CONNECTED 0 
    director-7 CONNECTED 0 
    director-8 CONNECTED 0 
    distributor-1 CONNECTED 0 
    distributor-2 CONNECTED 0 
    distributor-3 CONNECTED 0 
    distributor-4 CONNECTED 0 
    master-1 CONNECTED 0 
    worker-1 CONNECTED 0 
    worker-2 CONNECTED 0 
    worker-3 CONNECTED 0 
    admin@orchestrator[master-1]#

    Status : indique si l'application de planification est connectée au moteur docker et s'exécute sur un hôte.

    Pings manqués : nombre de requêtes ping consécutives manquées pour un hôte donné.

    Problème

    Parfois, la VM vDRA CPS reste bloquée dans l'état JOINING pour diverses raisons.

    admin@orchestrator[master-1]# show docker engine
    Fri Jul 14 09:36:18.635 UTC+00:00
    MISSED 
    ID STATUS PINGS 
    ----------------------------------
    control-1 CONNECTED 0 
    control-2 CONNECTED 0 
    director-1 JOINING 57
    director-2 JOINING 130
    director-3 JOINING 131
    director-4 JOINING 130
    director-5 JOINING 30
    director-6 JOINING 129 
    distributor-1 CONNECTED 0 
    distributor-2 CONNECTED 0 
    distributor-3 CONNECTED 0 
    distributor-4 CONNECTED 0 
    master-1 CONNECTED 0 
    worker-1 CONNECTED 0 
    worker-2 CONNECTED 0 
    worker-3 CONNECTED 0 
    admin@orchestrator[master-1]#

    Les raisons possibles pour lesquelles la VM reste bloquée dans cet étatJOINING,

    1. La machine virtuelle n'est pas accessible à partir de la machine virtuelle principale.

    1.1. Vérifier si l’état des connexions de trame sur la machine virtuelle concernée est en mode manchon.

    note-icon

    Remarque : Weave Net crée un réseau virtuel qui connecte les conteneurs Docker déployés sur plusieurs hôtes et active leur détection automatique. Avec Weave Net, les applications portables basées sur des microservices, constituées de plusieurs conteneurs, peuvent s'exécuter n'importe où : sur un hôte, sur plusieurs hôtes ou même entre les fournisseurs de cloud et les data centers. Les applications utilisent le réseau comme si les conteneurs étaient tous connectés au même commutateur réseau, sans configurer les mappages de ports, les ambassadeurs ou les liaisons.

    CPS-DRA a deux états principaux de connexions de tissage : fastdp et manchon. La préférence au sein de la grappe CPS-DRA est constamment orientée vers des connexions tissées dans l'étatfastdp .

    cps@director-1:~$ weave status connections
    -> xx.xx.xx.xx:6783 established sleeve 4e:5f:58:99:d5:65(worker-1) mtu=1438
    -> xx.xx.xx.xx:6783 established sleeve 76:33:17:3a:c7:ec(worker-2) mtu=1438
    <- xx.xx.xx.xx:54751 established sleeve 76:3a:e9:9b:24:84(director-1) mtu=1438
    -> xx.xx.xx.xx:6783 established sleeve 6e:62:58:a3:7a:a0(director-2) mtu=1438
    -> xx.xx.xx.xx:6783 established sleeve de:89:d0:7d:b2:4e(director-3) mtu=1438

    1.2. Vérifier si ces messages de journal sont présents dans le journalctl journal de la VM affectée.

    2023-08-01T10:20:25.896+00:00  docker-engine  Docker engine control-1 is unreachable                     
    2023-08-01T10:20:25.897+00:00  docker-engine  Docker engine control-2 is unreachable                     
    2023-08-01T10:20:25.935+00:00  docker-engine  Docker engine distributor-1 is unreachable                     
    2023-08-01T10:20:25.969+00:00  docker-engine  Docker engine worker-1 is unreachable  

    INFO: 2023/08/02 20:46:26.297275 overlay_switch ->[ee:87:68:44:fc:6a(worker-3)] fastdp timed out waiting for vxlan heartbeat
    INFO: 2023/08/02 20:46:26.297307 overlay_switch ->[ee:87:68:44:fc:6a(worker-3)] using sleeve

    2. L'espace disque de la VM est épuisé.

    2.1. Vérifiez l'utilisation de l'espace disque sur la machine virtuelle concernée et identifiez la partition avec une utilisation élevée de l'espace disque.

     cps@control-2:~$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 32G 0 32G 0% /dev
    tmpfs 6.3G 660M 5.7G 11% /run
    /dev/sda3 97G 97G 0 100% /
    tmpfs 32G 0 32G 0% /dev/shm
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 32G 0 32G 0% /sys/fs/cgroup
    /dev/sdb1 69G 4.7G 61G 8% /data
    /dev/sda1 180M 65M 103M 39% /boot
    /dev/sdb2 128G 97G 25G 80% /stats
    overlay 97G 97G 0 100% /var/lib/docker/overlay2/63854e8173b46727e11de3751c450037b5f5565592b83112a3863febf3940792/merged
    overlay 97G 97G 0 100% /var/lib/docker/overlay2/a86da2c7a289dc2b71359654c5160a9a8ae334960e78def78e6eecea95855853/merged
    overlay 97G 97G 0 100% /var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged
    overlay 97G 97G 0 100% /var/lib/docker/overlay2/49ee42311e82974707a6041d82e6c550004d1ce25349478bb974cc017a84aff5/merged
    cps@control-2:~$

    Procédure de récupération des machines virtuelles CPS-DRA à partir de l'état JOINING

    Approche 1.

    Si la VM n'est pas accessible à partir de la VM maître, utilisez cette approche.

    1. Vérifiez l'état de la connexion d'armure sur les VM affectées, s'il s'agit du mode manchon.

    #weave connection status

    Sample output:

    cps@director-1:~$ weave status connections
    -> xx.xx.xx.xx:6783 established sleeve 4e:5f:58:99:d5:65(worker-1) mtu=1438
    -> xx.xx.xx.xx:6783 established sleeve 76:33:17:3a:c7:ec(worker-2) mtu=1438
    <- xx.xx.xx.xx:54751 established sleeve 76:3a:e9:9b:24:84(director-1) mtu=1438
    -> xx.xx.xx.xx:6783 established sleeve 6e:62:58:a3:7a:a0(director-2) mtu=1438
    -> xx.xx.xx.xx:6783 established sleeve de:89:d0:7d:b2:4e(director-3) mtu=1438

    2. Redémarrez le tissage sur les machines virtuelles respectives.

    #docker restart weave


    3. Vérifiez si l'état de la connexion d'armure est passé à l'fastdp état et si la machine virtuelle affectée est passée à l'CONNECTED état.


    4. Si les machines virtuelles sont toujours bloquées dans l'étatJOINING, redémarrez les machines virtuelles concernées.

          #sudo reboot now     or   #init 6

    5. Vérifiez maintenant si la VM affectée est passée à l'état qui lui estCONNECTED associé.

    admin@orchestrator[master-1]# show docker engine
    Fri Jul 14 09:36:18.635 UTC+00:00
    MISSED 
    ID STATUS PINGS 
    ----------------------------------
    control-1 CONNECTED 0 
    control-2 CONNECTED 0 
    director-1 CONNECTED 0 
    director-2 CONNECTED 0 
    director-3 CONNECTED 0 
    director-4 CONNECTED 0 
    distributor-1 CONNECTED 0 
    distributor-2 CONNECTED 0 
    distributor-3 CONNECTED 0 
    distributor-4 CONNECTED 0 
    master-1 CONNECTED 0 
    worker-1 CONNECTED 0 
    worker-2 CONNECTED 0 
    worker-3 CONNECTED 0 
    admin@orchestrator[master-1]#

    6. Vérifiez si le vPAS commence à prendre en charge le trafic et si tous les conteneurs sont opérationnels (en particulier le point d'extrémité de diamètre), sinon redémarrez orchestrator-backup-a le conteneur dans la machine virtuelle drc01.

    #docker restart orchestrator-backup-a    

    7. Vérifiez maintenant si vPAS a commencé à traiter le trafic.

    Approche 2.

    Si l'espace disque de la VM est épuisé.

    1. Identifiez le répertoire qui consomme beaucoup d'espace disque.    

    root@control-2:/var/lib/docker/overlay2#du -ah / --exclude=/proc | sort -r -h | head -n 10
    176G 9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7

    2. Vérifiez les fichiers/journaux/vidages qui consomment beaucoup d'espace disque.        

    root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/diff# ls -lrtha | grep G
    total 88G
    -rw------- 1 root root 1.1G Jul 12 18:10 core.22781
    -rw------- 1 root root 1.2G Jul 12 18:12 core.24213
    -rw------- 1 root root 1.2G Jul 12 18:12 core.24606
    -rw------- 1 root root 1.1G Jul 12 18:12 core.24746
    -rw------- 1 root root 1.1G Jul 12 18:13 core.25398

    3. Identifiez les conteneurs qui s'exécutent sur la VM affectée (en particulier les conteneurs défectueux).

    admin@orchestrator[master-1]# show docker service | exclude HEALTHY
    Fri Jul 14 09:37:20.325 UTC+00:00
    PENALTY 
    MODULE INSTANCE NAME VERSION ENGINE CONTAINER ID STATE BOX MESSAGE 
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------
    cc-monitor 103 cc-monitor 22.1.1-release control-2 cc-monitor-s103 STARTED true Pending health check 
    mongo-node 103 mongo-monitor 22.1.1-release control-2 mongo-monitor-s103 STARTED true Pending health check 
    mongo-status 103 mongo-status 22.1.1-release control-2 mongo-status-s103 STARTED false - 
    policy-builder 103 policy-builder 22.1.1-release control-2 policy-builder-s103 STARTED true Pending health check 
    prometheus 103 prometheus-hi-res 22.1.1-release control-2 prometheus-hi-res-s103 STARTED true Pending health check 
    prometheus 103 prometheus-planning 22.1.1-release control-2 prometheus-planning-s103 STARTED false -

    admin@orchestrator[master-1]#                 

    4. Identifiez le conteneur qui déclenche des fichiers de base volumineux, pour ce faire, inspectez un par un chaque conteneur hébergé sur la machine virtuelle concernée.

    Sample output for container "cc-monitor-s103":

    root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged# docker inspect cc-monitor-s103| grep /var/lib/docker/overlay2/| grep merged
    "MergedDir": "/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged",
    root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged#

    5. Vérifiez si vous avez accès ou non à ce conteneur particulier.

     #admin@orchestrator[master-0]# docker connect cc-monitor-s103

    6. Si vous ne pouvez pas accéder à ce conteneur, supprimez les fichiers de base volumineux pour libérer de l'espace.

    root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/diff#  rm -rf core*

    7. Connectez-vous au conteneur affecté à partir de la VM affectée. 

         #docker exec -it cc-monitor-s103 bash

    8. Redémarrez le processusapp dans le conteneur pour arrêter la génération de fichiers de mémoire volumineux.

    root@cc-monitor-s103:/# supervisorctl status
    app STARTING 
    app-logging-status RUNNING pid 30, uptime 21 days, 23:02:17
    consul RUNNING pid 26, uptime 21 days, 23:02:17
    consul-template RUNNING pid 27, uptime 21 days, 23:02:17
    haproxy RUNNING pid 25, uptime 21 days, 23:02:17
    root@cc-monitor-s103:/#

    root@cc-monitor-s103:/# date; supervisorctl restart app
    Fri Jul 14 09:08:38 UTC 2023
    app: stopped
    app: started
    root@cc-monitor-s103:/# 

    root@cc-monitor-s103:/# supervisorctl status
    app RUNNING pid 26569, uptime 0:00:01
    app-logging-status RUNNING pid 30, uptime 21 days, 23:02:44
    consul RUNNING pid 26, uptime 21 days, 23:02:44
    consul-template RUNNING pid 27, uptime 21 days, 23:02:44
    haproxy RUNNING pid 25, uptime 21 days, 23:02:44
    root@cc-monitor-s103:/#

    9. Si l'étape 8. n'aide pas à arrêter la génération de fichiers de mémoire en bloc, redémarrez le conteneur concerné.

          #docker restart cc-monitor-s103

    10. Vérifiez si la génération de fichiers de mémoire en bloc s'est arrêtée. 

    11. Pour rétablir l'état CONNECTÉ de la machine virtuelle affectée, connectez-vous au conteneur,orchestrator puis effectuez un orchestration-engine redémarrage.

    cps@master-1:~$ date; docker exec -it orchestrator bash
    Fri Jul 14 09:26:12 UTC 2023
    root@orchestrator:/# 
    root@orchestrator:/# supervisorctl status
    confd RUNNING pid 20, uptime 153 days, 23:33:33
    consul RUNNING pid 19, uptime 153 days, 23:33:33
    consul-template RUNNING pid 26, uptime 153 days, 23:33:33
    haproxy RUNNING pid 17, uptime 153 days, 23:33:33
    mongo RUNNING pid 22, uptime 153 days, 23:33:33
    monitor-elastic-server RUNNING pid 55, uptime 153 days, 23:33:33
    monitor-log-forward RUNNING pid 48, uptime 153 days, 23:33:33
    orchestration-engine RUNNING pid 34, uptime 153 days, 23:33:33
    orchestrator_back_up RUNNING pid 60, uptime 153 days, 23:33:33
    remove-duplicate-containers RUNNING pid 21, uptime 153 days, 23:33:33
    rolling-restart-mongo RUNNING pid 18, uptime 153 days, 23:33:33
    simplehttp RUNNING pid 31, uptime 153 days, 23:33:33
    root@orchestrator:/# 
    root@orchestrator:/# date; supervisorctl restart orchestration-engine
    Fri Jul 14 09:26:39 UTC 2023
    orchestration-engine: stopped
    orchestration-engine: started
    root@orchestrator:/#

    12. Si l'étape 11 n'aide pas à restaurer la machine virtuelle, redémarrez le proxy du moteur dans la machine virtuelle concernée.

    cps@control-2:~$ docker ps | grep engine
    0b778fae2616 engine-proxy:latest "/w/w /usr/local/bin…" 5 months ago Up 3 weeks engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
    cps@control-2:~$ docker restart engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
    engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
    cps@control-2:~$ 
    cps@control-2:~$ docker ps | grep engine
    0b778fae2616 engine-proxy:latest "/w/w /usr/local/bin…" 5 months ago Up 6 seconds engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
    cps@control-2:~$

    13. Maintenant, vérifiez si la VM affectée est passée à l'état d'CONNECTED.

    admin@orchestrator[master-1]# show docker engine
    Fri Jul 14 09:36:18.635 UTC+00:00
    ID STATUS MISSED PINGS 
    ----------------------------------
    control-1 CONNECTED 0 
    control-2 CONNECTED 0 
    director-1 CONNECTED 0 
    director-2 CONNECTED 0 
    director-3 CONNECTED 0 
    director-4 CONNECTED 0 
    distributor-1 CONNECTED 0 
    distributor-2 CONNECTED 0 
    distributor-3 CONNECTED 0 
    distributor-4 CONNECTED 0 
    master-1 CONNECTED 0 
    worker-1 CONNECTED 0 
    worker-2 CONNECTED 0 
    worker-3 CONNECTED 0 
    admin@orchestrator[master-1]#

    Historique de révision

    Révision Date de publication Commentaires
    1.0
    25-Jun-2024
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Midhun P
      Ingénieur TAC Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits