Substituição de PCRF do servidor de computação UCS C240 M4

Introduction

Este documento descreve as etapas necessárias para substituir 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).

Informações de Apoio

Este documento destina-se ao pessoal da Cisco 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 substituição do servidor de computação.

Note: A versão Ultra M 5.1.x é considerada para definir os procedimentos neste documento.

Verificação de saúde

Antes de substituir um nó de computação, é importante verificar o estado de funcionamento atual do ambiente da plataforma Red Hat OpenStack. É recomendável verificar o estado atual para evitar complicações quando o processo de substituição de computação estiver ativado.

Etapa 1. Na implantação do OpenStack (OSPD). 

[root@director ~]$ su - stack
[stack@director ~]$ cd ansible
[stack@director ansible]$ ansible-playbook -i inventory-new openstack_verify.yml  -e platform=pcrf

Etapa 2. Verifique a saúde do sistema a partir do relatório de saúde ultram que é gerado a cada quinze minutos.

[stack@director ~]# cd /var/log/cisco/ultram-health

Etapa 3. Verifique o arquivo ultram_health_os.report.Os únicos serviços devem ser exibidos como XXX status são neutron-sriov-nic-agent.service.

Etapa 4. Para verificar se o rabbitmq executa todos os controladores do OSPD.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'" ) & done

Etapa 5. Verificar se a confiabilidade está ativada

[stack@director ~]# sudo pcs property show stonith-enabled

Etapa 6. Para todos os controladores, verifique o status do PCS.

• Todos os nós do controlador são iniciados em haproxy-clone.
• Todos os nós do controlador estão ativos em galera.
• Todos os nós do controlador são iniciados em Rabbitmq.
• 1 nó de controlador é Ativo e 2 Standby em redis.

 Passo 7. Do OSPD.

[stack@director ~]$ for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo pcs status" ) ;done 

Etapa 8. Verifique se todos os serviços openstack estão ativos, a partir do OSPD, execute este comando.

[stack@director ~]# sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

Etapa 9. Verifique se o status do CEPH é HEALTH_OK para Controladores.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo ceph -s" ) ;done

Etapa 10. Verifique os registros de componentes do OpenStack. Procure qualquer erro:

Neutron:
[stack@director ~]# sudo tail -n 20 /var/log/neutron/{dhcp-agent,l3-agent,metadata-agent,openvswitch-agent,server}.log

Cinder:
[stack@director ~]# sudo tail -n 20 /var/log/cinder/{api,scheduler,volume}.log

Glance:
[stack@director ~]# sudo tail -n 20 /var/log/glance/{api,registry}.log

Etapa 11. No OSPD, execute essas verificações para API.

[stack@director ~]$ source 
     
     

[stack@director ~]$ nova list

[stack@director ~]$ glance image-list

[stack@director ~]$ cinder list

[stack@director ~]$ neutron net-list

Etapa 12. Verifique a integridade dos serviços.

Every service status should be “up”:
[stack@director ~]$ nova service-list

Every service status should be “ :-)”:
[stack@director ~]$ neutron agent-list

Every service status should be “up”:
[stack@director ~]$ cinder service-list

Backup

Em caso de recuperação, a Cisco recomenda fazer um backup do banco de dados OSPD com o uso destas 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.

Para fazer backup das VMs CPS, a partir da VM do Cluster Manager:

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_$(date +\%Y-\%m-\%d).tar.gz

or

[root@CM ~]# config_br.py -a export --mongo-all --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/$(hostname)_backup_all_$(date +\%Y-\%m-\%d).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 são usados em seções subsequentes.

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

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

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

Etapa 2. Se a VM for um SM, OAM ou árbitro, além disso, interrompa os serviços do 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

Etapa 3. Para cada arquivo com o título sessionmgr-xxxx, execute service sessionmgr-xxxxx stop:

  

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

  

Remova o nó de computação da lista de agregados Nova

Etapa 1. Liste os agregados da nova e identifique o agregado que corresponde ao servidor de computação com base na VNF hospedada por ela. Geralmente, ele deve estar no formato <VNFNAME>-SERVICE<X>:

[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name              | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT   | mgmt              |
| 57 | VNF1-SERVICE1 | -                 |
| 60 | VNF1-EM-MGMT1 | -                 |
| 63 | VNF1-CF-MGMT1 | -                 |
| 66 | VNF2-CF-MGMT2 | -                 |
| 69 | VNF2-EM-MGMT2 | -                 |
| 72 | VNF2-SERVICE2 | -                 |
| 75 | VNF3-CF-MGMT3 | -                 |
| 78 | VNF3-EM-MGMT3 | -                 |
| 81 | VNF3-SERVICE3 | -                 |
+----+-------------------+-------------------+

   Nesse caso, o servidor de computação a ser substituído pertence ao VNF2. Portanto, a lista agregada correspondente é VNF2-SERVICE2.

Etapa 2. Remova o nó de computação do agregado identificado (remova por nome de host anotado da seção Identifique as VMs hospedadas na 😞 do nó de computação

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host VNF2-SERVICE2 pod1-compute-10.localdomain

Etapa 3. Verifique se o nó de computação é removido dos agregados. Agora, o host não deve ser listado no agregado:

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

Eliminação do nó de computação

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

Excluir do Overcloud

Etapa 1. Crie um arquivo de script chamado delete_node.sh com o conteúdo como mostrado aqui. Certifique-se de que os modelos mencionados sejam os mesmos usados no script Deployment.sh usado para a implantação da pilha.

 delete_node.sh

 openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack 
     
      
       
     

[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod1 49ac5f22-469e-4b84-badc-031083db0533
Deleting the following nodes from stack pod1:
- 49ac5f22-469e-4b84-badc-031083db0533
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s
user   0m0.383s
sys    0m0.086s

Etapa 2. Aguarde até que a operação da pilha OpenStack se mova para o estado COMPLETO.

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1 | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

Excluir nó de computação da lista de serviços

Exclua o serviço de computação da lista de serviços:

[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep compute-8
| 404 | nova-compute     | pod1-compute-8.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

openstack compute service delete 
     
     
[stack@director ~]$ openstack compute service delete 404

Excluir Agentes Neutron

Exclua o antigo agente de nêutrons associado e o agente de vswitch aberto para o servidor de computação:

[stack@director ~]$ openstack network agent list | grep compute-8
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete 
     
     

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03
[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

Excluir do banco de dados irônico

Exclua um nó do banco de dados irônico e verifique-o.

[stack@director ~]$ source stackrc

nova show 
     
     
       | grep hypervisor 
     

[stack@director ~]$ nova show pod1-compute-10 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete 
     
     

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a 
[stack@director ~]$ ironic node-list (node delete must not be listed now) 

Instale o novo nó de computação

As etapas para instalar um novo servidor UCS C240 M4 e as etapas de configuração inicial podem ser consultadas a partir de: Guia de instalação e serviços do servidor Cisco UCS C240 M4

Etapa 1. Após a instalação do servidor, insira os discos rígidos nos respectivos slots como o servidor antigo.

Etapa 2. Faça login no servidor usando o CIMC IP.

Etapa 3. Execute a atualização do BIOS se o firmware não estiver de acordo com a versão recomendada usada anteriormente. As etapas para a atualização do BIOS são fornecidas aqui: Guia de atualização do BIOS de servidor com montagem em rack Cisco UCS C-Series

Etapa 4. Para verificar o status das unidades físicas, navegue para Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info (Armazenamento > Controlador RAID modular SAS Cisco 12G (SLOT-HBA) > Physical Drive Info (Informações da unidade física). Deve ser Não Configurado em Bom

O armazenamento mostrado aqui pode ser a unidade SSD.

Etapa 5. Para criar uma unidade virtual a partir das unidades físicas com RAID Nível 1, navegue até Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Controller Info > Create Virtual Drive from Unused Physical Drives (Armazenamento > Controlador RAID modular SAS Cisco 12G) > Informações do controlador > Criar unidade virtual a partir de unidades físicas não utilizadas)

Etapa 6. Selecione o VD e configure Set as Boot Drive (Definir como unidade de inicialização), como mostrado na imagem.

Passo 7. Para habilitar o IPMI na LAN, navegue até Admin > Communication Services > Communication Services, como mostrado na imagem.

Etapa 8. Para desabilitar o hyperthreading, como mostrado na imagem, navegue para Compute > BIOS > Configure BIOS > Advanced > Processor Configuration.

Note: A imagem mostrada aqui e as etapas de configuração mencionadas nesta seção referem-se à versão de firmware 3.0(3e) e pode haver pequenas variações se você trabalhar em outras versões

Adicione o novo nó de computação à nuvem geral

As etapas mencionadas nesta seção são comuns independentemente da VM hospedada pelo nó de computação.

Etapa 1. Adicionar servidor de computação com um índice diferente.

Crie um arquivo add_node.json com apenas os detalhes do novo servidor de computação a ser adicionado. Certifique-se de que o número de índice do novo servidor de computação não seja usado antes. Geralmente, aumente o próximo valor de computação mais alto.

Exemplo: O anterior mais alto foi o computador-17, portanto, criou o computador-18 no caso do sistema de 2 vnf. 

Note: Lembre-se do formato json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "
     
     
       " 
     
            ],
            "capabilities": "node:compute-18,boot_option:local",
            "cpu":"24",
            "memory":"256000",
            "disk":"3000",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"<PASSWORD>",
            "pm_addr":"192.100.0.5"
        }
    ]
}

Etapa 2. Importar o arquivo json.

[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.

  

Etapa 3. Execute a introspecção de nó com o uso do UUID observado na etapa anterior.

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

Etapa 4. Adicione endereços IP a custom-templates/layout.yml em ComputeIPs. Você adiciona esse endereço ao final da lista para cada tipo, compute-0 mostrado aqui como um exemplo.

ComputeIPs:

    internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take compute-0 .43 and add here

    tenant:

    - 11.117.0.43

    - 11.117.0.44

    - 11.117.0.45

    - 11.117.0.43   << and here

    storage:

    - 11.118.0.43

    - 11.118.0.44

    - 11.118.0.45

    - 11.118.0.43   << and here

Etapa 5. Execute o script Deployment.sh usado anteriormente para implantar a pilha, para adicionar o novo nó de computação à pilha de nuvem.

[stack@director ~]$ ./deploy.sh
++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
…
Starting new HTTP connection (1): 192.200.0.1
"POST /v2/action_executions HTTP/1.1" 201 1695
HTTP POST http://192.200.0.1:8989/v2/action_executions 201
Overcloud Endpoint: http://10.1.2.5:5000/v2.0
Overcloud Deployed
clean_up DeployOvercloud: 
END return value: 0

real   38m38.971s
user   0m3.605s
sys    0m0.466s

Etapa 6. Aguarde a conclusão do status da pilha de openstack.

[stack@director ~]$ openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

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

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-18
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-compute-18    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep compute-18
| 63 | pod1-compute-18.localdomain    |

Restaure as VMs

Adição à lista agregada Nova

Adicione o nó de computação ao aggregate-host e verifique se o host foi adicionado.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host VNF2-SERVICE2 pod1-compute-18.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

Recuperação de VM do controlador de serviços elásticos (ESC)

Etapa 1. A VM está em estado de erro na lista nova.

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

Etapa 2. 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

     
     

     
     
  
     
     

Etapa 3. 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 (Policy and Charging Rules Function) da Cisco que residem na VM

Note: Se a VM estiver no estado de desligamento, ligue-a usando esc_nc_cli do ESC.

Verifique o diagnostics.sh da VM do gerenciador de cluster e se algum erro foi encontrado para as VMs recuperadas.

Etapa 1. Faça login na respectiva VM.

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

Etapa 2. Se a VM for um SM, OAM ou árbitro, além disso, inicie os serviços do sessionmgr interrompidos anteriormente:

Para cada arquivo com o título sessionmgr-xxxx, execute service sessionmgr-xxxxx start:

  

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

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

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

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

Excluir e reimplantar uma ou mais VMs em caso de falha na recuperação do ESC

Se o comando de recuperação ESC (acima) não funcionar (VM_RECOVERY_FAILED), exclua e leia as VMs individuais.

Obtenha o modelo ESC mais recente para o site

Do Portal ESC:

Etapa 1. Coloque o cursor sobre o botão Ação azul, uma janela pop-up será aberta, agora clique em Exportar modelo, como mostrado na imagem.

Etapa 2. Uma opção para baixar o modelo para a máquina local é apresentada, marque a opção Salvar arquivo, como mostrado na imagem. 

Etapa 3. Como mostrado na imagem, selecione um local e salve o arquivo para uso posterior.

Etapa 4. Faça login no ESC ativo para que o site seja excluído e copie o arquivo salvo acima no ESC neste diretório.

/opt/cisco/esc/cisco-cps/config/gr/tmo/gen

Etapa 5. Alterar diretório para /opt/cisco/esc/cisco-cps/config/gr/tmo/gen:

cd /opt/cisco/esc/cisco-cps/config/gr/tmo/gen

Procedimento para modificar o arquivo

Etapa 1. Modifique o arquivo de modelo de exportação.

Nesta etapa, você modifica o arquivo de modelo de exportação para excluir o grupo ou grupos de VMs associados às VMs que precisam ser recuperadas.

O arquivo de modelo de exportação é para um cluster específico.

Dentro desse cluster estão vários vm_groups.  Há um ou mais vm_groups para cada tipo de VM (PD, PS, SM, OM).

Note: Alguns vm_groups têm mais de uma VM.  Todas as VMs nesse grupo serão excluídas e adicionadas novamente.

Nessa implantação, você precisa marcar um ou mais vm_groups para exclusão.

Exemplo:

               <vm_group>

                  <name>cm</name>

Agora, altere <vm_group>para <vm_group nc:operation="delete"> e salve as alterações.

Etapa 2. Execute o arquivo de modelo de exportação modificado.

A partir da execução ESC:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
     
     

No Portal ESC, você deve ser capaz de ver uma ou mais VMs que mudam para o estado de desimplantação e depois desapareceram completamente.

O progresso pode ser acompanhado no documento do CES /var/log/esc/yangesc.log

Exemplo:

09:09:12,608 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUEST RECEIVED(UNDER TENANT) =====
09:09:12,608 29-Jan-2018 INFO  Tenant name: Pcrf
09:09:12,609 29-Jan-2018 INFO  Deployment name: WSP1-tmo
09:09:29,794 29-Jan-2018 INFO 
09:09:29,794 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====
09:10:19,459 29-Jan-2018 INFO 
09:10:19,459 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:10:19,459 29-Jan-2018 INFO  Type: VM_UNDEPLOYED
09:10:19,459 29-Jan-2018 INFO  Status: SUCCESS
09:10:19,459 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:10:22,292 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:10:22,292 29-Jan-2018 INFO  Type: SERVICE_UPDATED
09:10:22,292 29-Jan-2018 INFO  Status: SUCCESS
09:10:22,292 29-Jan-2018 INFO  Status Code: 200

Etapa 3. Modifique o arquivo de modelo de exportação para adicionar as VMs.

Nesta etapa, você modifica o arquivo de modelo de exportação para readicionar o grupo de VMs associado às VMs que estão sendo recuperadas.

O arquivo de modelo de exportação é dividido nas duas implantações (cluster1 / cluster2).

Dentro de cada cluster há um vm_group. Há um ou mais vm_groups para cada tipo de VM (PD, PS, SM, OM).

Note: Alguns vm_groups têm mais de uma VM.  Todas as VMs nesse grupo serão adicionadas novamente.

Exemplo:

               <vm_group nc:operation="delete">

                  <name>cm</name>

Altere <vm_group nc:operation="delete"> para apenas <vm_group>.

Note: Se as VMs precisarem ser recriadas porque o host foi substituído, o nome do host do host pode ter sido alterado.  Se o nome do host do HOST tiver sido alterado, o nome do host na seção de posicionamento do vm_group precisará ser atualizado.

<posicionamento>

                      <type>zone_host</type>

                     <imposição>estrita</imposição>

                      <host>wsstackovs-computação-4.domínio local</host>

</local>

Atualize o nome do host mostrado na seção anterior para o novo nome de host fornecido pela equipe Ultra-M antes da execução deste MOP. Após a instalação do novo host, salve as alterações.

Etapa 4. Execute o arquivo de modelo de exportação modificado.

A partir da execução ESC:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
     
     

No Portal ESC, você deve ser capaz de ver uma ou mais VMs reaparecerem e depois no estado Ativo.

O progresso pode ser acompanhado no documento do CES /var/log/esc/yangesc.log

Exemplo:

09:14:00,906 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUESTRECEIVED (UNDER TENANT) =====
09:14:00,906 29-Jan-2018 INFO  Tenant name: Pcrf
09:14:00,906 29-Jan-2018 INFO  Deployment name: WSP1-tmo
09:14:01,542 29-Jan-2018 INFO 
09:14:01,542 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====
09:16:33,947 29-Jan-2018 INFO 
09:16:33,947 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:16:33,947 29-Jan-2018 INFO  Type: VM_DEPLOYED
09:16:33,947 29-Jan-2018 INFO  Status: SUCCESS
09:16:33,947 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:19:00,148 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:19:00,148 29-Jan-2018 INFO  Type: VM_ALIVE
09:19:00,148 29-Jan-2018 INFO  Status: SUCCESS
09:19:00,148 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:19:00,275 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:19:00,275 29-Jan-2018 INFO  Type: SERVICE_UPDATED
09:19:00,275 29-Jan-2018 INFO  Status: SUCCESS
09:19:00,275 29-Jan-2018 INFO  Status Code: 200

Etapa 5. Verifique os serviços PCRF que residem na VM.

Verifique se os serviços PCRF estão inativos e inicie-os.

[stack@XX-ospd ~]$ ssh root@
     
     
[root@XXXSM03 ~]# monsum
[root@XXXSM03 ~]# monit start all

Se a VM for um SM, OAM ou árbitro, além disso, inicie os serviços do sessionmgr interrompidos anteriormente:

Para cada arquivo com o título sessionmgr-xxxx execute service sessionmgr-xxxx start:

  

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

 Se ainda assim o diagnóstico não estiver claro, execute build_all.sh da VM do Cluster Manager e, em seguida, 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

Etapa 6. Execute o diagnóstico para verificar o status do sistema.

[root@XXXSM03 init.d]# diagnostics.sh

Informações Relacionadas

• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...
• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...
  
• Suporte Técnico e Documentação - Cisco Systems