Substituição de PCRF do OSD-Compute UCS 240M4

Introduction

Este documento descreve as etapas necessárias para substituir um servidor osd-compute com falha em uma configuração Ultra-M que hospeda as VNFs (Virtual Network Functions, funções de rede virtual) 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 OSD-Compute.

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ó Osd-Compute, é importante verificar o estado 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. 

Do OSPD

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

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

   Verifique o arquivo ultram_health_os.report.

   Os únicos serviços devem mostrar como XXX status são neutron-sriov-nic-agent.service.

Etapa 2. Verifique se rabbitmq executa todos os controladores, que por sua vez é executado a partir 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 3. Verifique se a confiabilidade está habilitada.

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

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 são Master em galera
• Todos os nós do controlador são iniciados em Rabbitmq
• 1 nó de controlador é Master e 2 Slaves em redis

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 4. Verifique se todos os serviços openstack estão ativos. No OSPD, execute este comando:

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

Etapa 5. 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 6. 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

Passo 7. 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 8. 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 dessas etapas.

Etapa 1. Tome o despejo de Mysql.

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

Etapa 2. Para fazer backup das VMs CPS 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 OSD

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

Etapa 1. O servidor de computação contém o controlador de serviços elásticos (ESC).

[stack@director ~]$ nova list --field name,host,networks | grep osd-compute-1
| 50fd1094-9c0a-4269-b27b-cab74708e40c | esc | pod1-osd-compute-0.localdomain 
| tb1-orch=172.16.180.6; tb1-mgmt=172.16.181.3  

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.

Note: Se o nó de computação OSD a ser substituído estiver completamente inoperante e não acessível, continue com a seção intitulada "Remove the Osd-Compute Node from Nova Aggregate List" (Remover o nó de computação Osd da lista de agregação Nova). Caso contrário, continue na próxima seção.

Etapa 2. Verifique se o CEPH tem capacidade disponível para permitir que um único servidor OSD seja removido.

[root@pod1-osd-compute-0 ~]# sudo ceph df

GLOBAL:

    SIZE       AVAIL      RAW USED     %RAW USED

    13393G     11804G        1589G         11.87

POOLS:

    NAME        ID    USED      %USED     MAX AVAIL     OBJECTS

    rbd         0          0         0         3876G           0

    metrics     1     4157M      0.10         3876G      215385

    images      2     6731M      0.17         3876G         897

    backups     3         0         0         3876G           0

    volumes     4      399G      9.34         3876G      102373

    vms         5      122G      3.06         3876G       31863


    
    

Etapa 3. Verifique se o status da árvore de osd do ceph está ativo no servidor osd-compute.

[heat-admin@pod1-osd-compute-0 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2  4.35999     host pod1-osd-compute-0

 0  1.09000         osd.0                          up  1.00000          1.00000

 3  1.09000         osd.3                          up 1.00000          1.00000

 6  1.09000         osd.6                          up  1.00000          1.00000

 9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod1-osd-compute-2

 1  1.09000        osd.1                          up  1.00000          1.00000

 4  1.09000         osd.4                          up  1.00000          1.00000

 7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

 2  1.09000         osd.2                          up  1.00000          1.00000

 5  1.09000         osd.5                          up  1.00000          1.00000

 8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

Etapa 4. Os processos CEPH estão ativos no servidor osd-compute.

[root@pod1-osd-compute-0 ~]# systemctl list-units *ceph*

UNIT                              LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d11.mount loaded active mounted /var/lib/ceph/osd/ceph-11

var-lib-ceph-osd-ceph\x2d2.mount  loaded active mounted /var/lib/ceph/osd/ceph-2

var-lib-ceph-osd-ceph\x2d5.mount  loaded active mounted /var/lib/ceph/osd/ceph-5

var-lib-ceph-osd-ceph\x2d8.mount  loaded active mounted /var/lib/ceph/osd/ceph-8

ceph-osd@11.service               loaded active running Ceph object storage daemon

ceph-osd@2.service                loaded active running Ceph object storage daemon

ceph-osd@5.service                loaded active running Ceph object storage daemon

ceph-osd@8.service                loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice         loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice          loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                   loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                   loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target               loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                       loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once            

Etapa 5. Desabilite e pare cada instância do ceph e remova cada instância do osd e desmonte o diretório. Repita para cada instância do ceph.

[root@pod1-osd-compute-0 ~]# systemctl disable ceph-osd@11



[root@pod1-osd-compute-0 ~]# systemctl stop ceph-osd@11



[root@pod1-osd-compute-0 ~]# ceph osd out 11

marked out osd.11.



[root@pod1-osd-compute-0 ~]# ceph osd crush remove osd.11

removed item id 11 name 'osd.11' from crush map



[root@pod1-osd-compute-0 ~]# ceph auth del osd.11

updated



[root@pod1-osd-compute-0 ~]# ceph osd rm 11

removed osd.11



[root@pod1-osd-compute-0 ~]# umount /var/lib/ceph/osd/ceph-11



[root@pod1-osd-compute-0 ~]# rm -rf /var/lib/ceph/osd/ceph-11

   (or)

Etapa 6. O script Clean.sh pode ser usado para executar a tarefa acima de uma só vez.

[heat-admin@pod1-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd

ceph-11 ceph-3 ceph-6 ceph-8

[heat-admin@pod1-osd-compute-0 ~]$ /bin/sh clean.sh



[heat-admin@pod1-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh

set -x

CEPH=`sudo ls /var/lib/ceph/osd`

for c in $CEPH

do

   i=`echo $c |cut -d'-' -f2`

   sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd out $i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

   sleep 2

done

sudo ceph osd tree 

Depois que todos os processos OSD forem migrados/excluídos, o nó poderá ser removido da nuvem geral.

Note: Quando o CEPH é removido, o VNF HD RAID entra no estado Degraded, mas o disco rígido ainda precisa estar acessível.

Desligamento normal

Migrar ESC para o modo de espera

Etapa 1. Faça login no ESC hospedado no nó de computação e verifique se ele está no estado mestre. Se sim, mude o ESC para o modo de espera.

[admin@esc esc-cli]$ escadm status
0 ESC status=0 ESC Master Healthy


[admin@esc ~]$ sudo service keepalived stop
Stopping keepalived:                                       [  OK  ]

[admin@esc ~]$ escadm status
1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@esc ~]$ sudo reboot
Broadcast message from admin@vnf1-esc-esc-0.novalocal
       (/dev/pts/0) at 13:32 ...
The system is going down for reboot NOW!

Etapa 2. Remova o nó Osd-Compute da Nova Aggregate List.

• 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>-EM-MGMT<X> e <VNFNAME>-CF-MGMT<X>

[stack@director ~]$ nova aggregate-list
+----+------+-------------------+
| Id | Name | Availability Zone |
+----+------+-------------------+
| 3 | esc1 | AZ-esc1 |
| 6 | esc2 | AZ-esc2 |
| 9 | aaa | AZ-aaa |
+----+------+-------------------+

Em nosso caso, o servidor osd-compute pertence ao esc1. Então, os agregados que correspondem seriam esc1

Etapa 3. Remova o nó osd-compute do agregado identificado.

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host esc1 pod1-osd-compute-0.localdomain 

Etapa 4. Verifique se o nó osd-compute foi removido dos agregados. Agora, certifique-se de que o Host não esteja listado nos agregados.

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show esc1
[stack@director ~]$

Exclusão De Nó Osd-Compute

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. 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 |
+--------------------------------------+------------+-----------------+----------------------+---------------------- 

Exclua o nó Osd-Compute 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 osd-compute-0
| 404 | nova-compute     | pod1-osd-compute-0.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 abra o agente de vswitch para o servidor de computação.

[stack@director ~]$ openstack network agent list | grep osd-compute-0
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-osd-compute-0.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-osd-compute-0.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 Nova e Irônico

Exclua um nó da lista nova junto com o banco de dados irônico e verifique-o.

[stack@director ~]$ source stackrc

[stack@al01-pod1-ospd ~]$ nova list | grep osd-compute-0
| c2cfa4d6-9c88-4ba0-9970-857d1a18d02c | pod1-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.114 |

[stack@al01-pod1-ospd ~]$ nova delete c2cfa4d6-9c88-4ba0-9970-857d1a18d02c

nova show 
     
     
       | grep hypervisor 
     

[stack@director ~]$ nova show pod1-osd-compute-0 | 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 em: Guia de instalação e serviço 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 com o uso do IP do CIMC.

Etapa 3.Execute o upgrade 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. Verifique o status das unidades físicas. Deve ser Inconimaged Good.

Etapa 5. Crie uma unidade virtual a partir das unidades físicas com RAID Nível 1.

Etapa 6. Navegue até a seção de armazenamento e selecione o Cisco 12G Sas Modular Raid Controller e verifique o status e a integridade do controlador raid como mostrado na imagem.

Note: A imagem acima é apenas para fins de ilustração. No CIMC de OSD-Compute real, você vê sete unidades físicas em slots [1,2,3,7,8,9,10] em estado Bom e sem configuração, pois nenhuma unidade virtual é criada a partir delas.

Passo 7. Agora, crie uma unidade virtual a partir de uma unidade física não utilizada a partir das informações da controladora, no Cisco 12G SAS Modular Raid Controller.

Etapa 8. Selecione o VD e configure como unidade de inicialização.

Etapa 9. Ative IPMI sobre LAN dos serviços de comunicação na guia Admin.

Etapa 10. Desative a tecnologia Hyper-Threading da configuração avançada do BIOS sob o nó Computação, como mostrado na imagem.

Etapa 11. Semelhante ao BOOTOS VD criado com unidades físicas 1 e 2, crie mais quatro unidades virtuais como 

JORNAL - Da unidade física número 3

OSD1 - Do número de unidade física 7

OSD2 - Do número de unidade física 8

OSD3 - Do número de unidade física 9

OSD4 - Do número de unidade física 10

Passo 7. No final, as unidades físicas e virtuais devem ser semelhantes.

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ó OSD-Compute à Overcloud

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.  Verifique se o número de índice do novo servidor osd-compute não foi usado antes. Geralmente, aumente o próximo valor de computação mais alto.

Exemplo: O anterior mais alto foi o osd-compute-0, portanto, o osd-compute-3, no caso do sistema 2-vnf. 

Note: Lembre-se do formato json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "<MAC_ADDRESS>"
            ],
            "capabilities": "node:osd-compute-3,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 OsdComputeIPs. Nesse caso, ao substituir osd-compute-0, você adiciona esse endereço ao final da lista para cada tipo.

OsdComputeIPs:

    internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take osd-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

    storage_mgmt:

    - 11.119.0.43

    - 11.119.0.44

    - 11.119.0.45

    - 11.119.0.43   << and here

Etapa 5. Execute o script Deployment.sh que foi usado anteriormente para implantar a pilha, para adicionar o novo nó de computação à pilha da 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 | pod1       | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

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

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

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

Etapa 8. Faça login no novo servidor osd-compute e verifique os processos ceph. Inicialmente, o status está em HEALTH_WARN quando o ceph se recupera.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666

     health HEALTH_WARN

            223 pgs backfill_wait

            4 pgs backfilling

            41 pgs degraded

            227 pgs stuck unclean

            41 pgs undersized

            recovery 45229/1300136 objects degraded (3.479%)

            recovery 525016/1300136 objects misplaced (40.382%)

     monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

            election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

     osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs

            flags sortbitwise,require_jewel_osds

      pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects

            1553 GB used, 11840 GB / 13393 GB avail

            45229/1300136 objects degraded (3.479%)

            525016/1300136 objects misplaced (40.382%)

                 477 active+clean

                 186 active+remapped+wait_backfill

                  37 active+undersized+degraded+remapped+wait_backfill

                   4 active+undersized+degraded+remapped+backfilling

Etapa 9. No entanto, após um curto período (20 minutos), CEPH retorna a um estado HEALTH_OK.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666

     health HEALTH_OK

     monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

            election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

     osdmap e1398: 12 osds: 12 up, 12 in

            flags sortbitwise,require_jewel_osds

      pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects

            1599 GB used, 11793 GB / 13393 GB avail

                 704 active+clean

  client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr



[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2        0     host pod1-osd-compute-0

-3  4.35999     host pod1-osd-compute-2

 1  1.09000         osd.1                          up  1.00000          1.00000

 4  1.09000         osd.4                          up  1.00000          1.00000

 7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

 2  1.09000         osd.2                          up  1.00000          1.00000

 5  1.09000         osd.5                          up  1.00000          1.00000

 8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

-5  4.35999     host pod1-osd-compute-3

 0  1.09000         osd.0                          up  1.00000          1.00000

 3  1.09000         osd.3                          up  1.00000          1.00000

 6  1.09000         osd.6                          up  1.00000          1.00000

 9  1.09000         osd.9                          up  1.00000          1.00000

Restaure as VMs

  

Adição à lista agregada Nova

Adicione o nó osd-compute aos aggregate-hosts e verifique se o host foi adicionado.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host esc1 pod1-osd-compute-3.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show esc1
+----+------+-------------------+----------------------------------------+------------------------------------------+
| Id | Name | Availability Zone | Hosts | Metadata |
+----+------+-------------------+----------------------------------------+------------------------------------------+
| 3 | esc1 | AZ-esc1 | 'pod1-osd-compute-3.localdomain' | 'availability_zone=AZ-esc1', 'esc1=true' |
+----+------+-------------------+----------------------------------------+------------------------------------------+

Recuperação de VM ESC

Etapa 1. Verifique o status da VM ESC na lista nova e exclua-a.

stack@director scripts]$ nova list |grep esc
| c566efbf-1274-4588-a2d8-0682e17b0d41 | esc                                                | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
[stack@director scripts]$ nova delete esc
Request to delete server esc has been accepted.

If can not delete esc then use command: nova force-delete esc

Etapa 2. No OSPD, navegue até o diretório ECS-Image e verifique se as versões bootvm.py e qcou2 para ESC estão presentes, se não movê-las para um diretório.

[stack@atospd ESC-Image-157]$ ll

total 30720136

-rw-r--r--. 1 root  root       127724 Jan 23 12:51 bootvm-2_3_2_157a.py

-rw-r--r--. 1 root  root           55 Jan 23 13:00 bootvm-2_3_2_157a.py.md5sum

-rw-rw-r--. 1 stack stack 31457280000 Jan 24 11:35 esc-2.3.2.157.qcow2

Etapa 3. Crie a imagem.

[stack@director ESC-image-157]$  glance image-create --name ESC-2_3_2_157 --disk-format "qcow2" --container "bare" --file /home/stack/ECS-Image-157/ESC-2_3_2_157.qcow2

Etapa 4. Verifique se a imagem ESC existe.

stack@director ~]$ glance image-list
+--------------------------------------+--------------------------------------+
| ID                                   | Name                                 |
+--------------------------------------+--------------------------------------+
| 8f50acbe-b391-4433-aa21-98ac36011533 | ESC-2_3_2_157|
| 2f67f8e0-5473-467c-832b-e07760e8d1fa | tmobile-pcrf-13.1.1.iso              |
| c5485c30-45db-43df-831d-61046c5cfd01 | tmobile-pcrf-13.1.1.qcow2            |
| 2f84b9ec-61fa-46a3-a4e6-45f14c93d9a9 | tmobile-pcrf-13.1.1_cco_20170825.iso |
| 25113ecf-8e63-4b81-a73f-63606781ef94 | wscaaa01-sept072017                  |
| 595673e8-c99c-40c2-82b1-7338325024a9 | wscaaa02-sept072017                  |
| 8bce3a60-b3b0-4386-9e9d-d99590dc9033 | wscaaa03-sept072017                  |
| e5c835ad-654b-45b0-8d36-557e6c5fd6e9 | wscaaa04-sept072017                  |
| 879dfcde-d25c-4314-8da0-32e4e73ffc9f | WSP1_cluman_12_07_2017               |
| 7747dd59-c479-4c8a-9136-c90ec894569a | WSP2_cluman_12_07_2017               |
+--------------------------------------+--------------------------------------+

[stack@ ~]$ openstack flavor list
+--------------------------------------+------------+--------+------+-----------+-------+-----------+
| ID                                   | Name       |    RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+------------+--------+------+-----------+-------+-----------+
| 1e4596d5-46f0-46ba-9534-cfdea788f734 | pcrf-smb   | 100352 |  100 |         0 |     8 | True      |
| 251225f3-64c9-4b19-a2fc-032a72bfe969 | pcrf-oam   |  65536 |  100 |         0 |    10 | True      |
| 4215d4c3-5b2a-419e-b69e-7941e2abe3bc | pcrf-pd    |  16384 |  100 |         0 |    12 | True      |
| 4c64a80a-4d19-4d52-b818-e904a13156ca | pcrf-qns   |  14336 |  100 |         0 |    10 | True      |
| 8b4cbba7-40fd-49b9-ab21-93818c80a2e6 | esc-flavor |   4096 |    0 |         0 |     4 | True      |
| 9c290b80-f80a-4850-b72f-d2d70d3d38ea | pcrf-sm    | 100352 |  100 |         0 |    10 | True      |
| e993fc2c-f3b2-4f4f-9cd9-3afc058b7ed1 | pcrf-arb   |  16384 |  100 |         0 |     4 | True      |
| f2b3b925-1bf8-4022-9f17-433d6d2c47b5 | pcrf-cm    |  14336 |  100 |         0 |     6 | True      |
+--------------------------------------+------------+--------+------+-----------+-------+-----------+

Etapa 5. Crie esse arquivo no diretório de imagem e inicie a instância ESC.

[root@director ESC-IMAGE]# cat esc_params.conf 
openstack.endpoint = publicURL

[root@director ESC-IMAGE]./bootvm-2_3_2_157a.py esc --flavor esc-flavor --image ESC-2_3_2_157 --net tb1-mgmt --gateway_ip 172.16.181.1 --net tb1-orch --enable-http-rest --avail_zone AZ-esc1 --user_pass "admin:Cisco123" --user_confd_pass "admin:Cisco123" --bs_os_auth_url http://10.250.246.137:5000/v2.0 --kad_vif eth0 --kad_vip 172.16.181.5 --ipaddr 172.16.181.4 dhcp --ha_node_list 172.16.181.3 172.16.181.4 --esc_params_file esc_params.conf

Note: Depois que a VM ESC problemática é reimplantada com exatamente o mesmo comando bootvm.py da instalação inicial, o ESC HA executa a sincronização automaticamente sem qualquer procedimento manual. Certifique-se de que o ESC Master esteja ativo e em execução.

Etapa 6. Faça login no novo ESC e verifique o estado de backup.

[admin@esc ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) ===================================================
ESC HEALTH PASSED