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.
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).
In questo documento viene descritto come ripristinare le istanze di Cisco Virtual Policy e Charging Rules Function (vPCRF) distribuite nella distribuzione di Ultra-M/Openstack.
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 abilitare il relativo monitoraggio in Elastic Services Controller (ESC).
Passaggio 1. Controllare lo stato dell'istanza tramite OpenStack.
source /home/stack/destackovsrc-Pcrf nova list --fields name,host,status | grep cm_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | 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 cm_0 SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_ERROR_STATE
Passaggio 4. Accendere l'istanza da openstack.
source /home/stack/destackovsrc-Pcrf nova start SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
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_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | ACTIVE
Passaggio 6. EAttivare il monitor 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_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
Per ulteriori ripristini delle configurazioni delle istanze, fare riferimento alle procedure specifiche per il tipo di istanza fornite qui.
Questa procedura può essere utilizzata se lo stato dell'istanza di CPS in openstack è ERROR:
Passaggio 1. Controllare lo stato dell'istanza in OpenStack.
source /home/stack/destackovsrc-Pcrf nova list --fields name,host,status | grep cm_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | destackovs-compute-2 | ERROR|
Passaggio 2. 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 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 cm_0 SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_ERROR_STATE
Passaggio 4. 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 SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 nova reboot –-hard SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
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_0 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | 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 SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634
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.
Se Cisco Policy Suite (CPS) è bloccato in stato ERROR e non può essere acceso con le procedure già descritte e l'istanza è disponibile in openstack. Si consiglia di ricreare l'istanza tramite l'immagine snapshot.
Passaggio 1. Assicurarsi che lo snapshot dell'ultima configurazione valida nota sia presente come file QCOW, utilizzare il file generato in precedenza durante il backup, scp/sftp e restituirlo al computer OpenStack Platform- Director (OSPD). Per convertirla in un'immagine panoramica, attenersi alla procedura descritta di seguito.
source /home/stack/destackovsrc-Pcrf glance image-create --name CPS_Cluman_13.1.1 --disk-format "qcow2" --container "bare" --file /var/Pcrf/cluman_snapshot.raw Alternatively, glance image-create --name rebuild_cluman --file /home/stack/cluman_snapshot.raw --disk-format qcow2 --container-format bare
Passaggio 2. Utilizzare un comando nova rebuild su OSPD per ricreare l'istanza di Cluman VM con lo snapshot caricato, come illustrato.
nova rebuild
Passaggio 3. 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 |cm_0_170d9c14-0221-4609-87e3-d752e636f57f| ACTIVE |
Passaggio 4. Se, dopo la ricostruzione, lo stato di Gestione cluster viene impostato su ATTIVO, controllare lo stato dell'istanza in ESC e, se necessario, abilitare Monitoraggio VM in ESC.
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep cm cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR cm_0_170d9c14-0221-4609-87e3-d752e636f57f
Passaggio 5. Verificare che il volume Cinder associato all'immagine ISO originale di Cluster Manager venga aggiornato con l'ora corrente dopo la ridistribuzione:
cinder list | grep tmobile-pcrf-13.1.1-1.iso | 2f6d7deb-60d6-40fa-926f-a88536cf98a3 | in-use | tmobile-pcrf-13.1.1-1.iso | 3 | - | true | a3f3bc62-0195-483a-bbc0-692bccd37307 | cinder show 2f6d7deb-60d6-40fa-926f-a88536cf98a3 | grep updated_at | updated_at | 2018-06-18T08:54:59.000000 updated_at | 2018-06-18T08:54:59.000000
Passaggio 6. Collegare i dischi di backup o qualsiasi altro volume Cinder precedentemente collegato all'istanza di Cluster Manager se non viene collegato automaticamente nei passaggi precedenti.
source /home/stack/destackovsrc-Pcrf cinder list +--------------------------------------+-----------+---------------------------+------+-------------+----------+--------------------------------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+---------------------------+------+-------------+----------+--------------------------------------+ | 0e7ec662-b59e-4e3a-91a9-35c4ed3f51d7 | available | pcrf-atp1-mongo02 | 3 | - | false | | | 2f6d7deb-60d6-40fa-926f-a88536cf98a3 | in-use | tmobile-pcrf-13.1.1-1.iso | 3 | - | true | a3f3bc62-0195-483a-bbc0-692bccd37307 | | 4c553948-df75-4f0b-bf7b-0e64127dfda3 | available | pcrf-atp1-svn01 | 3 | - | false | | | 594c052e-aaa3-4c82-867d-3b36162244b3 | available | tmobile-pcrf-13.1.1-2.iso | 3 | - | true | | | 64953713-de86-40d5-a0e5-07db22d692f2 | in-use | tmobile-pcrf-13.1.1.iso | 3 | - | true | 80a93e90-59e2-43bd-b67e-5d766d0a2f11 | openstack server add volume--device
Passaggio 7. Se lo snapshot della colonna è precedente e è disponibile il backup config_br.py di una data di creazione dello snapshot del post. Importare la configurazione dal backup e, in caso contrario, ignorare questo passaggio.
sshconfig_br.py –a import --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/
Passaggio 8. Ricostruire tutte le immagini VM dal backup tramite config_br.py in Gestione cluster:
/var/qps/install/current/scripts/build/build_all.sh
Se la VM di Gestione cluster CPS è persa (impossibile da ripristinare) e anche il processo di ricostruzione (come descritto nella sezione 2.3) non è riuscito, è necessario ridistribuire l'istanza tramite ESC. In questa procedura viene descritto il processo per la stessa operazione:
Passaggio 1. Assicurarsi che lo snapshot dell'ultima configurazione valida nota sia presente come file QCOW, utilizzare il file generato in precedenza durante il backup, scp/sftp per tornare al calcolo OSPD.
ls –ltr /var/Pcrf/cluman_snapshot.qcow -rw-r--r--. 1 root root 328514100 May 18 16:59 cluman_snapshot.qcow
Passaggio 2. Utilizzare questa procedura per convertirla in un'immagine panoramica.
source /home/stack/destackovsrc-Pcrf glance image-create --name CPS_Cluman_13.1.1 --disk-format "qcow2" --container "bare" --file /var/Pcrf/cluman_snapshot.qcow
Passaggio 3. Quando l'immagine è disponibile, accedere a ESC e verificare lo stato dell'istanza di Gestione cluster in Opdata ESC.
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep cm cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE
Passaggio 4. Verificare che il file /home/admin/PCRF_config.xml sia presente come backup nella versione 2.1.1
Passaggio 5. Ottenere il nome della distribuzione, il tenant e vm_group per il cluster manager da ripristinare.
Frammento di esempio:
Pcrf ---------------- Name of the tenantfalse DEP1 ---------------- Name of the Deployment ----- ----- -----cm --------------- Name of the vm_group pcrf-13.1.1.qcow2 ------------- Name of the Image usedpcrf-cm 600 30
Passaggio 6. Attivare un'eliminazione della macchina virtuale di Gestione cluster da ESC:
Avviso: Il comando per rimuovere l'istanza da opdata deve essere completo, il comando incompleto può eliminare l'intera distribuzione. Per favore, siate cauti. Il comando deve sempre contenere tutti i parametri, ad esempio il nome del tenant, il nome della distribuzione e il nome del gruppo_vm.
/opt/cisco/esc/confd/bin/confd_cli -u admin –C esc-ha-01# config esc-ha-01(config)# no esc_datamodel tenants tenant Pcrf deployments deployment DEP1 vm_group cm esc-ha-01(config)# commit esc-ha-01(config)# exit
Il passaggio precedente deve rimuovere l'istanza da openstack e da ESC opdata. In altre parole, Gestione cluster non fa più parte della distribuzione.
Passaggio 7. Verificare che l'istanza di Gestione cluster venga rimossa dalla distribuzione da yangesc.log, escmanager.log in ESC e in nova list nel nodo OSPD.
Passaggio 8. Modificare il file PCRF_config.xml di cui è stato eseguito il backup nel passaggio 2.1.1 e modificare il nome dell'immagine di Gestione cluster nell'immagine appena creata da snapshot nei passaggi precedenti:
Prima della modifica | Dopo modifica |
<gruppo_macchine virtuali> <name>cm</name> <image>pcrf-13.1.1.qws2</image> |
<gruppo_macchine virtuali> |
Passaggio 9. Modificare il file PCRF_config.xml e rimuovere il file di dati utente del cloud per il gruppo di macchine virtuali di Gestione cluster. Di seguito è riportato un esempio di frammento xml da rimuovere:
--user-data file:///opt/cisco/esc/cisco-cps/config/pcrf-cm_cloud.cfg CLUSTER_ID P1 CM_IP_ADDR_PVT 192.168.1.107 PREFIX vpc SEQ 01 SITE_ID DE
Passaggio 10. Copiare il file PCRF_config.xml nella cartella /opt/cisco/esc/cisco-cps/config/ in cui sono presenti tutti gli altri file di configurazione.
Passaggio 11. Caricare Unire il nuovo file di configurazione in Opdata ESC.
/opt/cisco/esc/confd/bin/confd_cli -u admin –C esc-ha-01# config esc-ha-01(config)# load merge /opt/cisco/esc/cisco-cps/config/PCRF_config.xml esc-ha-01(config)# commit esc-ha-01(config)# exit
Passaggio 12. Monitorare i file yangesc.log, escmanager.log su ESC e nova list su OSPD per verificare la distribuzione di Cluster Manager.
source /home/stack/destackovsrc-Pcrf nova list --fields name,status| grep cm | 96a5647e-9970-4e61-ab5c-5e7285543a09 | cm_0_a11a9068-df37-4974-9bd8-566f825d5e39 | ACTIVE
Passaggio 13. Se, dopo la ricostruzione, lo stato di Gestione cluster viene modificato in ATTIVO, controllare lo stato dell'istanza in ESC e, se necessario, abilitare il monitoraggio delle macchine virtuali in ESC.
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep cm cm_0_170d9c14-0221-4609-87e3-d752e636f57f VM_ERROR_STATE /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR cm_0_170d9c14-0221-4609-87e3-d752e636f57f
Passaggio 14. Collegare i dischi di backup o qualsiasi altro volume Cinder precedentemente collegato all'istanza di Cluster Manager e non automaticamente da esc nel passaggio precedente.
source /home/stack/destackovsrc-Pcrf cinder list +--------------------------------------+--------+------------------------+------+------------+---------+----------------------------------------+ | ID | Status | Name | Size | Volume Type| Bootable| Attached to | +--------------------------------------+--------+------------------------+------+------------+---------+----------------------------------------+ | 4c478cce-c746-455a-93f1-3f360acb87ce | in-use | CPS_14.0.0.release.iso | 3 | - | true | 96a5647e-9970-4e61-ab5c-5e7285543a09 | | 7e5573d9-29bc-4ea0-b046-c666bb1f7e06 | in-use | PCRF_backup | 1024 | - | false | | | d5ab1991-3e09-41f2-89f5-dd1cf8a9e172 | in-use | svn01 | 2 | - | false | 09f4bafa-dfb6-457f-9af5-69196eb31b13 | | d74988a7-1f59-4241-9777-fc4f2d4f3e78 | in-use | svn02 | 2 | - | false | 86ea448d-09bc-4d2f-81a3-de05884f1e05 | +--------------------------------------+--------+------------------------+------+------------+---------+----------------------------------------+ openstack server add volume--device
Passaggio 15. Se lo snapshot della colonna è precedente e config_br.py è disponibile un backup della data in cui è stata creata una snapshot post-copia. Importare la configurazione dal backup, altrimenti ignorare questo passaggio.
sshconfig_br.py –a import --svn --etc --grafanadb --users --auth-htpasswd --haproxy /mnt/backup/
Passaggio 16. Ricostruire tutte le immagini VM dal backup tramite config_br.py in Gestione cluster:
/var/qps/install/current/scripts/build/build_all.sh