Risoluzione dei problemi relativi a PCRF VM Recovery-Arbiter- Openstack
Opzioni per il download
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).
Sommario
Introduzione
In questo documento viene descritto come ripristinare le istanze di Cisco Virtual Policy and Charging Rules Function (vPCRF) distribuite nella distribuzione di Ultra-M/Openstack.
Contributo di Nitesh Bansal, Cisco Advance Services.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Openstack
- CPS
- È ora disponibile il calcolo su cui sono state distribuite le istanze interessate.
- Le risorse di calcolo sono disponibili nella stessa zona di disponibilità dell'istanza interessata.
Componenti usati
Le informazioni di questo documento si basano su CPS e sono applicabili a tutte le versioni.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Risoluzione dei problemi
Accendere l'arbitro dallo stato SHUTOFF
Se un'istanza è nello stato SHUTOFF a causa di un arresto pianificato o per altri motivi, eseguire la procedura seguente per avviare l'istanza e abilitare il monitoraggio dell'istanza in Elastic Service Controller (ESC).
Passaggio 1. Controllare lo stato dell'istanza tramite 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|
Passaggio 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 |
Passaggio 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 arbiter r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE
Passaggio 4. Accendere l'istanza da openstack.
source /home/stack/destackovsrc-Pcrf nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
Passaggio 5. Attendere cinque minuti prima che l'istanza venga avviata e venga messa in stato attivo.
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 |
Passaggio 6. Abilitare il monitoraggio della macchina virtuale in ESC dopo che l'istanza è in stato attivo.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
Per ulteriori ripristini delle configurazioni delle istanze, fare riferimento alle procedure specifiche per il tipo di istanza fornite di seguito.
Ripristina qualsiasi istanza dallo stato di errore
Se lo stato dell'istanza di CPS in openstack è in stato ERROR, utilizzare la procedura seguente per avviare l'istanza:
Passaggio 1. Reimpostare lo stato dell'istanza per riportare l'istanza allo stato attivo anziché allo stato di errore. Al termine, riavviare l'istanza.
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
Passaggio 2. 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 arbiter r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE
Passaggio 3. Verificare se il calcolo è disponibile e se funziona correttamente.
source /home/stack/destackovsrc nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’ | state | up | | status | enabled |
Passaggio 4. Controllare lo stato dell'istanza in 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|
Passaggio 5. Attendere cinque minuti prima che l'istanza venga avviata e venga messa in stato attivo.
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 |
Passaggio 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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
Passaggio 7. 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.
Recupera arbiter/arbitervip
Se un'istanza di arbitro/pcrfclient è stata ripristinata di recente e l'arbitro non si trova nell'output diagnostics.sh get_replica_status, seguire questa procedura.
Se la distribuzione dispone di una VM arbitro dedicata, utilizzare i passaggi da 1 a 3 per arbitervip eseguire anche il passaggio 4, quindi eseguire i passaggi seguenti:
- In Cluster Manager, eseguire questo comando per creare gli script di avvio/arresto mongodb in base alla configurazione del sistema:
cd /var/qps/bin/support/mongo build_set.sh --all --create-scripts
2. In PCRFCLIENTXX o (e) arbiter eseguire questo comando per elencare tutti i processi che è necessario avviare.
cd etc/init.d/ ll | grep sessionmgr
3. In PCRFCLIENTXX o (e) arbiter per ogni file elencato nell'ultimo output, eseguire questo comando, sostituire xxxxx con i numeri di porta, ad esempio per 27717:
/etc/init.d/sessionmgr-xxxxx start Example: /etc/init.d/sessionmgr-27717 start
- Se viene utilizzato arbiter vip, verificare se le risorse pcs su pcrfclient01 richiedono la pulizia con questo comando:
pcs resource show | grep –v started
Se il comando del passaggio 4 restituisce un output, pulire la risorsa pcs utilizzando il comando seguente, per più risorse pcs non avviate ripetere il comando per ciascuna risorsa:
pcs resource cleanup
Verifica
Verificare lo stato della replica:
Run diagnostics.sh on pcrfclient01
Se l'arbitro viene eseguito come arbitro e non come arbitro/pcrfclient per verificare se la VM è stata ripristinata completamente, è possibile eseguire i seguenti passaggi:
- Sull'arbitro primario, tutti i processi mongo devono essere eseguiti e può essere verificato con questo comando su arbitro:
ps –aef | grep mongo
- Verificare che tutti i processi monitorati siano in uno stato valido (In esecuzione/Controllato) per l'arbitro.
monit summary
Contributo dei tecnici Cisco
- Nitesh BansalCisco Advanced Services
Feedback