Contenu

Introduction

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

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

Récupération du gestionnaire de sessions/MongoDB

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

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

Jeux de réplicas de reconstruction

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

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

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

3. Exécutez la commande sur Cluster Manager.

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

4. 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

2. Répertorie tous les membres de tous les jeux de réplicas.

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

4. Arrêtez le processus mongo et nettoyez le contenu dans dbpath :

/etc/init.d/sessionmgr-xxxxx stop

rm -rf /var/data/sessions.1/b/*

5. 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é.

2. 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.

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

4. 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/

2. 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

--