Política e regras de cobrança Função Parar e Iniciar Nó de Computação

Introduction

Este documento descreve as etapas necessárias para parar o início de um servidor de computação defeituoso em uma configuração Ultra-M que hospeda as funções de rede virtual (VNFs) do Cisco Policy Suite (CPS).

Note: A versão Ultra M 5.1.x é considerada para definir os procedimentos neste documento. Este documento destina-se ao pessoal da Cisco que está familiarizado com a plataforma Ultra-M da Cisco e detalha as etapas necessárias para serem executadas no nível de VNF do OpenStack e CPS no momento da parada do Servidor de computação.

Prerequisites

Backup

Antes de parar de iniciar um nó de computação, é importante verificar o estado atual do ambiente da plataforma Red Hat OpenStack. Recomenda-se que verifique o estado atual para evitar complicações.

Em caso de recuperação, a Cisco recomenda fazer um backup do banco de dados OSPD com o uso dessas etapas.

<[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

Esse processo garante que um nó possa ser substituído sem afetar a disponibilidade de quaisquer instâncias. Além disso, é recomendável fazer backup da configuração do CPS.

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

Identificar as VMs hospedadas no nó de computação

Identifique as VMs hospedadas no servidor de computação.

[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

Note: Na saída mostrada aqui, a primeira coluna corresponde ao UUID (Universal Unique IDentifier), a segunda coluna é o nome da VM e a terceira coluna é o nome do host onde a VM está presente. Os parâmetros dessa saída serão usados em seções subsequentes.

Desative os serviços de PCRF residentes na VM para ser desligado

1. Faça login no IP de gerenciamento da VM.

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

2. Se a VMfor umSM, OAMouArbiter, além disso, pare os serviços 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. Para cada arquivo com o título sessionmgr-xxxxx execute service sessionmgr-xxxxx stop.

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

Desligamento normal

Desligar VM do ESC

1. Faça login no nó ESC que corresponde ao VNF e verifique o status da VM.

[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. Interrompa a VM com o uso de seu Nome da VM. (Nome da VM observado na seção " Identifique as VMs hospedadas no nó de computação").

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

 3. Depois de parada, a VM deve entrar no estado 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> 

Início de parada do nó de computação

As etapas mencionadas nesta seção são comuns independentemente das VMs hospedadas no nó de computação.

Stop-Start Compute Node do OSPD

1. Verifique o status e pare de iniciar o nó.

[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. Aguarde até que o computador esteja no estado Desligado e inicie-o novamente.

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

3. Verifique se o novo nó de computação está no estado Ativo.

[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    |

Restaure as VMs

Recuperação de VM do ESC

1. Idealmente, a partir do OSPD, se você verificar a lista de novas, as VMs devem estar no estado Fechado. Nesse caso, você precisa iniciar as VMs do 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. Ou, se a VM estiver em estado de erro na lista nova, execute esta configuração.

[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. Agora, recupere a VM do 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. Monitore o 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].

Verifique os serviços PCRF que permanecem na VM

Note: Se a VM estiver no estado SHUTOFF, ligue-a com o uso de esc_nc_cli do ESC. Verifique o diagnostics.sh da VM do gerenciador de cluster e se você encontra algum erro encontrado para as VMs recuperadas.

1. Faça login na respectiva VM.

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

2. Se a VMfor umSM, OAMouArbiter, além disso, inicie os serviços sessionmgr que pararam antes. Para cada arquivo com o título sessionmgr-xxxx, execute o comando service sessionmgr-xxxxx start.

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

 3. Se o diagnóstico ainda não estiver claro, execute build_all.sh da VM do Cluster Manager e execute o VM-init na respectiva VM.

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

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