Sommario

Introduzione

Risoluzione dei problemi

Procedure di ripristino dell'istanza di Session Manager

Accendere Gestione sessioni dallo stato SHUTOFF

Ripristina qualsiasi istanza dallo stato di errore

Ripristino di Session Manager/MongoDB

Membro del set di repliche nello stato offline

Membri del set di repliche bloccati nello stato di avvio2/ripristino per uno stato a lungo termine

Ricompila set di repliche

Ripristina il database dal post-set di replica di backup

Introduzione

In questo documento viene descritta la procedura di ripristino di Session Manager distribuita nelle distribuzioni Ultra-M/Openstack.

Risoluzione dei problemi

Procedure di ripristino dell'istanza di Session Manager

Accendere Gestione sessioni dallo stato SHUTOFF

Se un'istanza si trova nello stato SHUTOFF a causa di un arresto pianificato o per altri motivi, utilizzare questa procedura per avviare l'istanza e abilitarne il monitoraggio in ESC.

1. Controllare lo stato dell'istanza tramite 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. Verificare che il computer sia disponibile e che lo stato sia attivo.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

3. Accedere al master Elastic Services Controller (ESC) come utente admin e verificare lo stato dell'istanza in 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. Accendere l'istanza da openstack

source /home/stack/destackovsrc-Pcrf

nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
.

5. Attendere cinque minuti per consentire all'istanza di avviarsi e diventare attiva.

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. Abilita monitoraggio VM in ESC dopo che l'istanza è nello stato attivo.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

Per ulteriori ripristini delle configurazioni delle istanze, fare riferimento alle procedure specifiche per il tipo di istanza fornite nella sezione successiva.

Ripristina qualsiasi istanza dallo stato di errore

Questa procedura può essere utilizzata se lo stato dell'istanza di CPS in openstack è ERROR:

1. Controllare lo stato dell'istanza in 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. Verificare che il computer sia disponibile e che funzioni correttamente.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep â€˜status|stateâ€™

| state                     | up                                       |

| status                    | enabled                                  |

3. Accedere al master ESC come utente amministratore e verificare lo stato dell'istanza in 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. Reimpostare lo stato dell'istanza per riportare l'istanza allo stato attivo anziché a uno stato di errore. Al termine, riavviare l'istanza.

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. Attendere cinque minuti per consentire all'istanza di avviarsi e tornare allo stato attivo.

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. Se lo stato di Gestione cluster viene modificato in ATTIVO dopo il riavvio, abilitare Monitoraggio VM in ESC dopo che l'istanza di Gestione cluster è in stato attivo.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

Dopo il ripristino allo stato in esecuzione/attivo, fare riferimento alla procedura specifica del tipo di istanza per ripristinare la configurazione o i dati dal backup.

Ripristino di Session Manager/MongoDB

In Gestione sessioni viene fornito il livello di database alla suite di criteri cluster in questa sezione viene illustrato il ripristino dei database in un'istanza ripristinata di recente di Gestione sessioni:

Membro del set di repliche nello stato offline

Se i membri di un set di repliche sono nello stato offline, utilizzare la procedura seguente:

1. Controllare lo stato del set di repliche utilizzando questo comando in Gestione cluster.

diagnostics.sh --get_replica_status

2. Elencare tutti i membri OFF-LINE in tutti i set di repliche.

3. Eseguire il comando in Gestione cluster.

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

4. Proteggere la shell nelle macchine virtuali sessionmgr e avviare il processo mongo.

ssh sessionmgrXX

/etc/init.d/sessionmgr-XXXXX start

Membri del set di repliche bloccati nello stato di avvio2/ripristino per uno stato a lungo termine

Se i membri di un set di repliche sono bloccati nello stato di avvio2 o di ripristino e il database primario è disponibile nel set di repliche, utilizzare la procedura seguente:

1. Controllare lo stato del set di repliche utilizzando questo comando in Gestione cluster.

diagnostics.sh --get_replica_status

2. Elenca tutti i membri di tutti i set di repliche.

3. Proteggere la shell nelle macchine virtuali sessionmgr e ottenere la posizione di archiviazione del processo mongo.Come mostrato nell'esempio, dbpath è /var/data/sessions.1/b per il processo mongo in esecuzione su sessionmgr01 alla porta 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. Interrompere il processo mongo e pulire il contenuto in dbpath:

/etc/init.d/sessionmgr-xxxxx stop

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

5. Avviare il processo mongo. In questo modo il membro del set di repliche sincronizzerà tutti i dati del database primario e non il log.

/etc/init.d/sessionmgr-xxxxx start

Il passaggio 5 potrebbe richiedere molto tempo per la sincronizzazione di tutti i dati dal database primario, a seconda delle dimensioni del database.

Ricompila set di repliche

A causa di alcune interruzioni, potrebbe essere necessario ricostruire alcuni o tutti i set di repliche. Tuttavia, prima di decidere se ricostruire alcuni o tutti i set di repliche, si potrebbe notare che tutti i dati in questi set potrebbero andare perduti. È necessario verificare la disponibilità dei backup per i database seguenti:

- Admin (generalmente su 27721)

- Saldo (generalmente sulla porta 27718)

- SPR (generalmente sulla porta 2720)

Dopo aver eseguito la verifica incrociata dei backup e aver deciso di ricreare i set di repliche del database, attenersi alla procedura descritta di seguito.

1. Controllare il contenuto di /etc/broadhop/mongoConfig.cfg, LLD deve avere informazioni su quale configurazione deve essere presente in questo file o è possibile utilizzare un file di backup.

2. Il comando build_set.sh —<nome-db> —create deve essere eseguito in Gestione cluster, che dipende dal database che si desidera ricreare. Vengono creati tutti i set di repliche correlati a tale database.

Nota: Il comando per la creazione di tutti i database in un set di repliche consente di pulire il database. Tutto il contenuto del set di repliche andrebbe perso.

3. Se si desidera ricreare un set di repliche specifico per un database, utilizzare questo comando:

build_set.sh --

--create --setname

4. Se si desidera ricompilare tutti i set di repliche per tutti i database, utilizzare questo comando:

build_set.sh --all --create

Ripristina il database dal post-set di replica di backup

Una volta che tutti i membri del set di repliche sono online e uno dei membri è primario, è possibile ripristinare mongoDB dal backup tramite questa procedura.

1. Per ripristinare tutti i database dal backup, utilizzare questo comando:

config_br.py --action import --mongo-all  /mnt/backup/

2. Per ripristinare un database specifico dal backup tramite config_br.py, sono disponibili le seguenti opzioni:

- SPR

config_br.py --action import --mongo-all --spr /mnt/backup/

- Admin

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

- Saldo

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

- Reporting

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

Se si utilizza mongodump per eseguire il backup dei database, questo spiega il suo utilizzo attraverso il ripristino mongo:

1. Estrarre il file tar.gz di backup.

tar -zxf /mnt/backup/

2. Individuare la cartella contenente il dump mongo del database che si desidera recuperare e cambiare directory per immetterlo.

ls -ltr  /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump

3. Ripristinare il set di repliche dal backup.

mongorestore --host

--port

4. Facoltativamente, per ripristinare una raccolta specifica o un database, utilizzare questo comando:

mongorestore --host

--port

--db

--