Criteri e regole di caricamento Funzione Interrompi e avvia nodo di calcolo

Introduzione

Questo documento descrive i passaggi necessari per arrestare e avviare un server di elaborazione difettoso in una configurazione Ultra-M che ospita funzioni di rete virtuale (VNF) di Cisco Policy Suite (CPS).

Nota: Per definire le procedure descritte in questo documento, viene presa in considerazione la release di Ultra M 5.1.x. Questo documento è destinato al personale Cisco che ha familiarità con la piattaforma Cisco Ultra-M e descrive i passaggi richiesti per essere eseguiti a livello OpenStack e CPS VNF al momento dell'avvio di Compute Server.

Prerequisiti

Backup

Prima di arrestare e avviare un nodo Compute, è importante verificare lo stato corrente dell'ambiente della piattaforma Red Hat OpenStack. Si consiglia di controllare lo stato corrente per evitare complicazioni.

In caso di ripristino, Cisco consiglia di eseguire un backup del database OSPD attenendosi alla seguente procedura.

<[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

Questo processo assicura che un nodo possa essere sostituito senza influire sulla disponibilità di alcuna istanza. È inoltre consigliabile eseguire il backup della configurazione CPS.

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz

Identificare le VM ospitate nel nodo di calcolo

Identificare le VM ospitate nel server di elaborazione.

[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  pod1-compute-10.localdomain    | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129

Nota: Nell'output mostrato di seguito, la prima colonna corrisponde all'UUID (Universally Unique IDentifier), la seconda colonna è il nome della macchina virtuale e la terza colonna è il nome host in cui la macchina virtuale è presente. I parametri di questo output verranno utilizzati nelle sezioni successive.

Disabilitare i servizi PCRF residenti sulla VM da arrestare

1. Accedere all'IP di gestione della VM.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit stop all

2. Se la VMè un SM, OAMorArbiter, arrestare anche i servizi sessionmgr.

[root@XXXSM03 ~]# cd /etc/init.d
[root@XXXSM03 init.d]# ls -l sessionmgr*
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717
-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727

3. Per ogni file denominato sessionmgr-xxxxx eseguire il servizio sessionmgr-xxxxx arrestare.

[root@XXXSM03 init.d]# service sessionmgr-27717 stop

Spegnimento regolare

Arresta VM da ESC

1. Accedere al nodo ESC corrispondente al file VNF e controllare lo stato della macchina virtuale.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

2. Arrestare la macchina virtuale utilizzando il relativo nome. (Nome VM indicato nella sezione " Identificazione delle VM ospitate nel nodo di calcolo").

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

 3. Una volta arrestata, la VM deve entrare nello stato SHUTOFF.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip> 

Stop-Start nodo di calcolo

I passaggi descritti in questa sezione sono comuni indipendentemente dalle VM ospitate nel nodo di calcolo.

Stop-Start Compute Node da OSPD

1. Controllare lo stato, quindi arrestare e avviare il nodo.

[stack@director ~]$ nova list | grep compute-10 
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ nova stop pod1-stack-compute-10

2. Attendere che il calcolo si trovi nello stato Shutoff, quindi riavviarlo.

[stack@director ~]$ nova start pod1-stack-compute-10

3. Verificare che il nuovo nodo di calcolo sia nello stato Attivo.

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-10
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ source pod1-stackrc-Core
[stack@director ~]$ openstack hypervisor list |grep compute-10
| 6 | pod1-compute-10.localdomain    |

Ripristino delle VM

Ripristino VM da ESC

1. Se si seleziona l'elenco Nova da OSPD, è consigliabile che le VM siano nello stato di arresto. In questo caso, è necessario avviare le VM da ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action START VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

2. In alternativa, se la macchina virtuale è in stato di errore nell'elenco delle macchine virtuali, eseguire questa configurazione.

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     | 

3. Ripristinare la VM dalla ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

4. Controllare il file yangesc.log.

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

Controllare i servizi PCRF residenti sulla VM

Nota: Se la VM è nello stato SHUTOFF, accenderla utilizzando il comando esc_nc_cli di ESC. Controllare il file diagnostics.sh dalla macchina virtuale di Gestione cluster e verificare se sono stati rilevati errori per le macchine virtuali che vengono ripristinate.

1. Accedere alla VM corrispondente.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit start all

2. Se la VM è un SM, OAMorArbiter, avviare anche i servizi sessionmgr arrestati in precedenza. Per ogni file denominato sessionmgr-xxxxx, eseguire il servizio sessionmgr-xxxxx start.

[root@XXXSM03 init.d]# service sessionmgr-27717 start

 3. Se la diagnostica non è ancora chiara, eseguire build_all.sh dalla VM di Cluster Manager e la VM-init sulla VM corrispondente.

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01 
/etc/init.d/vm-init