Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Dépannage

Mise sous tension de l'arbitre à partir de l'état SHUTOFF

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

Récupérer Arbiter/arbitervip

Vérification

Introduction

Ce document décrit comment récupérer les instances vPCRF (Virtual Policy and Charging Rules Function) de Cisco déployées sur le déploiement Ultra-M/Openstack.

Contribué par Nitesh Bansal, Cisco Advance Services.

Conditions préalables

Conditions requises

Cisco vous recommande d'avoir des connaissances sur ces sujets :

- OpenStack

- CPS

- Le calcul sur lequel les instances affectées ont été déployées est désormais disponible.

- Les ressources de calcul sont disponibles dans la même zone de disponibilité que l'instance affectée.

Components Used

Les informations de ce document sont basées sur CPS et s'appliquent à toutes les versions.

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.

Dépannage

Mise sous tension de l'arbitre à 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 la procédure suivante pour démarrer l'instance et activer sa surveillance dans le contrôleur de service élastique (ESC).

Étape 1. Vérifiez l'état de l'instance via OpenStack.

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep arbiter

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2  | SHUTOFF|

Étape 2. Vérifiez si l'ordinateur 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                                  |

Étape 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 arbiter

r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE

Étape 4. Mettez l'instance sous tension à partir d'openstack.

source /home/stack/destackovsrc-Pcrf

nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Étape 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 cm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |

Étape 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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

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

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

Si l'état de l'instance CPS dans openstack est ERROR, procédez comme suit pour démarrer l'instance :

Étape 1. 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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

nova reboot –-hard  r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Étape 2. 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 arbiter

r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE

Étape 3. 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                                  |

Étape 4. Vérifiez l'état de l'instance dans OpenStack.

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep arbiter

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2  | ERROR|

Étape 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 arbiter

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |

Étape 6. Si L'état du Gestionnaire de cluster devient ACTIVE après le redémarrage, activez le Moniteur de VM dans l'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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Étape 7. 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érer Arbiter/arbitervip

Si une instance d'arbitre/pcrfclient est récemment restaurée et que l'arbitre n'est pas dans la sortie diagnostics.sh get_replica_status, suivez cette procédure.

Si le déploiement a une machine virtuelle arbitre dédiée, utilisez les étapes 1 à 3 , pour arbitervip, exécutez l'étape 4, puis exécutez ces étapes :

1. Sur le gestionnaire de cluster, exécutez cette commande pour créer les scripts de démarrage/d'arrêt mongodb en fonction de la configuration système :

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

2.  Sur PCRFCLIENTXX ou (et) arbitre, exécutez cette commande pour répertorier tous les processus à démarrer.

cd etc/init.d/

ll | grep sessionmgr

3.  Sur PCRFCLIENTXX ou (et) arbitre pour chaque fichier répertorié dans la dernière sortie, exécutez cette commande, remplacez xxxxx par des numéros de port, par exemple pour 27717 ici :

/etc/init.d/sessionmgr-xxxxx start

Example:

/etc/init.d/sessionmgr-27717 start

4. Si vous utilisez la fonction graphique de l'arbitre, vérifiez si l'une des ressources pc de pcrfclient01 nécessite un nettoyage à l'aide de ces commandes :

pcs resource show | grep –v started

Si une sortie est renvoyée par la commande à l'étape 4, nettoyez la ressource pcs à l'aide de la commande suivante, pour les ressources pcs multiples qui ne sont pas démarrées, répétez la commande pour chaque ressource :

pcs resource cleanup

Vérification

Vérifiez l'état du réplica :

Run diagnostics.sh on pcrfclient01

Si l'arbitre fonctionne en tant qu'arbitre et non en tant qu'arbitre/client pcrfclient, vous pouvez effectuer les étapes suivantes pour vérifier si la machine virtuelle est entièrement restaurée ou non :

1. Sur l'arbitre principal, tous les processus de mongo doivent s'exécuter et il peut être vérifié avec cette commande sur l'arbitre :

ps –aef | grep mongo

2. Vérifiez que tous les processus sous surveillance de monit sont en bon état (en cours d'exécution/surveillé) pour l'arbitre.

monit summary