Risoluzione dei problemi relativi al ripristino della VM di PCRF Session Manager - Openstack

Opzioni per il download

  • PDF     (124.7 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (88.6 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (78.6 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:4 settembre 2018
ID documento:213624

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    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

      

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

    2. Eseguire il comando in Gestione cluster.
    cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
    1. 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

      

    1. Elenca tutti i membri di tutti i set di repliche.
    1. 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

       

    1. Interrompere il processo mongo e pulire il contenuto in dbpath:
    /etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*
    1. 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.
    1. 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.

    1. Se si desidera ricreare un set di repliche specifico per un database, utilizzare questo comando:
    build_set.sh --
     
     
       --create --setname

      

    1. 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/
    1. 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 
          
            --
    TAC Authored

    Contributo dei tecnici Cisco

    • Nitesh Bansal
      Cisco Advanced Services

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci

    Questo documento si applica a questi prodotti