Dépannage de la récupération des machines virtuelles du Gestionnaire de session PCRF - Openstack

Options de téléchargement

  • PDF     (158.3 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (89.8 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (80.3 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:4 septembre 2018
ID du document:213624

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

    Ce document décrit la procédure de récupération de Session Manager déployée sur les déploiements Ultra-M/Openstack.

    Dépannage

    Procédures de récupération d'instance du gestionnaire de sessions

    Mise sous tension du gestionnaire de session à partir de l'état SHUTOFF

    Si une instance est dans l'état SHUTOFF en raison d'un arrêt planifié ou d'une autre raison, veuillez utiliser cette procédure pour démarrer l'instance et activer la surveillance it’s dans ESC.

    1. Vérifier l'état de l'instance via OpenStack

      source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep sm-s1
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|
    2. Vérifiez si le calcul est disponible et assurez-vous que l'état est actif.

      source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state                     | up                                       |
| status                    | enabled                                  |
    3. Connectez-vous au contrôleur de services élastiques (ESC) Master en tant qu'utilisateur administrateur et vérifiez l'état de l'instance dans opdata. 

      /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE
    4. Mettre l'instance sous tension à partir d'openstack

      source /home/stack/destackovsrc-Pcrf
nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
      .
    5. Attendez cinq minutes pour que l'instance démarre et passe à l'état actif.

      source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep sm-s1_0
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |
    6. Activer le moniteur de VM dans l'ESC après que l'instance est en état actif.
    /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

      

    Pour une récupération ultérieure des configurations d'instance, reportez-vous aux procédures spécifiques au type d'instance fournies dans la section suivante.

    Récupérer une instance à partir de l'état ERROR

    Cette procédure peut être utilisée si l'état de l'instance CPS dans openstack est ERROR :

    1. Vérifiez l'état de l'instance dans OpenStack. 

      source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep sm-s1
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|
    2. Vérifiez si le calcul est disponible et s'exécute correctement.

      source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state                     | up                                       |
| status                    | enabled                                  |
    3. Connectez-vous à ESC Master en tant qu'utilisateur admin et vérifiez l'état de l'instance dans opdata.

      /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE
    4. Réinitialisez l'état de l'instance pour forcer le rétablissement de l'état actif au lieu d'un état d'erreur, une fois terminé, redémarrez votre instance.

      source /home/stack/destackovsrc-Pcrf

nova reset-state –active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
nova reboot –-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
    5. Attendez cinq minutes que l'instance démarre et passe à l'état actif.

      source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep sm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |
    6. Si le Gestionnaire de cluster passe à ACTIVE après le redémarrage, activez le Moniteur de VM dans ESC après que l'instance du Gestionnaire de cluster est en état actif.
    /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

      

    Après la récupération à l'état actif/en cours, référez-vous à la procédure spécifique au type d'instance pour récupérer la configuration/les données à partir de la sauvegarde.

    Récupération du gestionnaire de sessions/MongoDB

    Le gestionnaire de sessions fournit la couche de base de données à la suite de stratégies de cluster dans cette section. La récupération des bases de données sur une instance récemment restaurée du gestionnaire de sessions est abordée :

    Membre du jeu de réplicas dans l'état Hors connexion

    Si le ou les membres d'un jeu de réplicas sont en mode hors connexion, procédez comme suit :

    1. Vérifiez l'état du jeu de réplicas à l'aide de cette commande sur le Gestionnaire de cluster.
    diagnostics.sh --get_replica_status

      

    1. Répertoriez tous les membres OFF-LINE dans tous les jeux de réplicas.

    2. Exécutez la commande sur Cluster Manager.
    cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
    1. Fixez le shell aux machines virtuelles sessionmgr et démarrez le processus de mongo.
    ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

    Membre(s) du jeu de réplicas bloqué dans l'état Démarrage2/Récupération pour un état de longue durée

    Si le ou les membres d'un jeu de réplicas sont bloqués dans l'état de démarrage2 ou de récupération et que le principal est disponible dans le jeu de réplicas, procédez comme suit :

    1. Vérifiez l'état du jeu de réplicas à l'aide de cette commande sur le Gestionnaire de cluster.
    diagnostics.sh --get_replica_status

      

    1. Répertorie tous les membres de tous les jeux de réplicas.
    1. Fixez le shell aux machines virtuelles sessionmgr et obtenez l'emplacement de stockage du processus mongo.Comme l'illustre l'exemple dbpath est /var/data/sessions.1/b pour le processus mongo exécuté sur sessionmgr01 au port 37717.
    ssh sessionmgr01
ps -ef | grep mongo | grep 37717
root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

       

    1. Arrêtez le processus mongo et nettoyez le contenu dans dbpath :
    /etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*
    1. Démarrez le processus mongo, ce qui entraîne la synchronisation de toutes les données de la base de données principale par le membre du jeu de réplicas et non par le téléchargement.
    /etc/init.d/sessionmgr-xxxxx start

    L'étape 5 peut prendre beaucoup de temps pour synchroniser toutes les données du primaire, selon la taille de la base de données.

    Jeux de réplicas de reconstruction

    En raison de certaines pannes, il peut être nécessaire de reconstruire certains jeux de réplicas ou tous les jeux de réplicas. Toutefois, avant de prendre la décision de reconstruire certains ou tous les jeux de réplicas, il peut être noté que toutes les données de ces jeux de réplicas pourraient être perdues. La disponibilité des sauvegardes doit être vérifiée de manière croisée pour ces bases de données :

    • Admin (généralement sur 27721)
    • Solde (généralement sur le port 27718)
    • SPR (généralement sur le port 27720)

    Une fois les sauvegardes vérifiées et la décision de recréer les jeux de réplicas de base de données prise, procédez comme suit :

    1. Vérifiez le contenu de /etc/broadhop/mongoConfig.cfg, LLD doit avoir des informations sur la configuration qui doit être présente dans ce fichier ou vous pouvez utiliser un fichier sauvegardé.
    1. La commande build_set.sh —<db-name> —create doit s'exécuter sur Cluster Manager, qui dépend de la base de données que vous avez l'intention de reconstruire. Il crée tous les jeux de réplicas relatifs à cette base de données.

    Note: La commande permettant de créer tous les dbs dans un jeu de réplicas nettoie la base de données. Tout le contenu du jeu de réplicas sera perdu.

    1. Si vous souhaitez reconstruire un jeu de réplicas spécifique pour une base de données, utilisez cette commande :
    build_set.sh --
     
     
       --create --setname

      

    1. Si vous souhaitez reconstruire tous les jeux de réplicas pour toutes les bases de données, utilisez cette commande :
    build_set.sh --all --create

    Restaurer la base de données à partir du jeu de réplicas de post-sauvegarde

    Une fois que tous les membres du jeu de réplicas sont en ligne et qu'un des membres est primaire, mongoDB peut être restauré à partir de la sauvegarde via cette procédure.

    1. Afin de restaurer toutes les bases de données à partir de la sauvegarde, utilisez cette commande :
    config_br.py --action import --mongo-all  /mnt/backup/
    1. Afin de restaurer une base de données spécifique à partir de la sauvegarde via config_br.py, ces options sont disponibles :
    • SPR
    config_br.py --action import --mongo-all --spr /mnt/backup/

      

    • Admin
    config_br.py --action import  --mongo-all --admin  /mnt/backup/

      

    • Solde 
    config_br.py --action import  --mongo-all --balance  /mnt/backup/

      

    • Rapports
    config_br.py --action import  --mongo-all --report  /mnt/backup/

    Si mongodump est utilisé pour sauvegarder des bases de données, cela explique son utilisation par le biais de la restauration mongo :

    1. Extrayez le fichier tar.gz de sauvegarde.

      tar -zxf /mnt/backup/
    2. Recherchez le dossier contenant le vidage mongo de la base de données que vous voulez récupérer et modifiez le répertoire pour l'entrer.

      ls -ltr  /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump
    3. Restaurer le jeu de réplicas à partir de la sauvegarde.

      mongorestore --host 
          
          
            --port
    4. Pour restaurer une collection spécifique ou une base de données, utilisez cette commande :
    mongorestore --host 
        
        
          --port 
         
           --db 
          
            --
    TAC Authored

    Contribution d’experts de Cisco

    • Nitesh Bansal
      Cisco Advance Services

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits