Contents

Introduction

Informações de Apoio

Abreviaturas

Fluxo de trabalho do MoP

Substituição da placa-mãe na configuração Ultra-M

Substituição da placa-mãe no nó de computação

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

Desligamento normal

Caso 1. Computador nó hospeda somente a VM SF

Caso 2. Nó de computação hosts CF/ESC/EM/UAS

Substituir a placa-mãe

Restaure as VMs

Caso 1. Computador nó hospeda somente a VM SF

Caso 2. O nó de computação hospeda UAS, ESC, EM e CF

Substituição da placa-mãe no nó de computação OSD

Coloque o Ceph no modo de manutenção

Identifique as VMs hospedadas no nó Osd-Compute

Desligamento normal

Caso 1. OSD-Computing Node Hosts CF/ESC/EM/UAS

Caso 2. OSD-Compute Node Hosts Implantação Automática/AutoIt/EM/UAS

Fazer backup do CDB de implantação automática

Backup System.cfg de TI automática

Substituir a placa-mãe

Mova o Ceph para fora do modo de manutenção

Restaure as VMs

Caso 1. OSD-Computing Node Hosts CF, ESC, EM e UAS

Caso 2. O nó de computação OSD hospeda TI automática, implantação automática, EM e UAS

Recuperar VM de TI automática

Substitua a placa-mãe no nó da controladora

Verifique o status do controlador e coloque o cluster no modo de manutenção

Substituir a placa-mãe

Restaurar status do cluster

Introduction

Este documento descreve as etapas necessárias para substituir a placa-mãe defeituosa de um servidor em uma configuração Ultra-M que hospeda as VNFs (Virtual Network Functions, funções de rede virtual) do StarOS.

Informações de Apoio

O Ultra-M é uma solução de núcleo de pacotes móveis virtualizados pré-embalada e validada, projetada para simplificar a implantação de VNFs. O OpenStack é o Virtualized Infrastructure Manager (VIM) para Ultra-M e consiste nos seguintes tipos de nó:

- Computação

- Disco de Armazenamento de Objeto - Computação (OSD - Compute)

- Controlador

- Plataforma OpenStack - Diretor (OSPD)

A arquitetura de alto nível da Ultra-M e os componentes envolvidos estão descritos nesta imagem:

Arquitetura UltraM

Este documento destina-se aos funcionários da Cisco familiarizados com a plataforma Cisco Ultra-M e detalha as etapas necessárias para serem executadas no nível de VNF do OpenStack e do StarOS no momento da substituição da placa-mãe em um servidor.

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

Abreviaturas

VNF

Função de rede virtual

CF

Função de controle

SF

Função de serviço

ESC

Controlador de serviço elástico

MOP

Método de Procedimento

OSD

Discos de Armazenamento de Objeto

HDD

Unidade de disco rígido

SSD

Unidade de estado sólido

VIM

Virtual Infrastructure Manager

VM

Máquina virtual

EM

Gestor de Elementos

UAS

Ultra Automation Services

UUID

Identificador universal exclusivo

Fluxo de trabalho do MoP

Fluxo de trabalho de alto nível do procedimento de substituição

Substituição da placa-mãe na configuração Ultra-M

Em uma configuração Ultra-M, pode haver cenários em que a substituição da placa-mãe é necessária nestes tipos de servidor: Computação, OSD-Compute e Controlador.

Note: Os discos de inicialização com a instalação do OpenStack são substituídos após a substituição da placa-mãe. Portanto, não há necessidade de adicionar o nó de volta à nuvem. Quando o servidor é ligado após a atividade de substituição, ele se inscreve novamente na pilha de nuvem.

Substituição da placa-mãe no nó de computação

Antes da atividade, as VMs hospedadas no nó Computação são desligadas com facilidade. Depois que a placa-mãe for substituída, as VMs serão restauradas novamente.

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

Identifique as VMs hospedadas no Servidor de computação. Podem existir duas possibilidades:

O Servidor de Computação contém apenas SF VM:

[stack@director ~]$ nova list --field name,host | grep compute-10

| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |

pod1-compute-10.localdomain    |

O servidor de computação contém a combinação CF/ESC/EM/UAS de VMs:

[stack@director ~]$ nova list --field name,host | grep compute-8

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |

| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |

| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Note: Na saída mostrada aqui, a primeira coluna corresponde ao UUID, 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 nas seções subsequentes.

Desligamento normal

Caso 1. Computador nó hospeda somente a VM SF

Faça login no VNF do StarOS e identifique a placa que corresponde ao SF VM. Use o UUID da VM SF identificada na seção Identifique as VMs hospedadas no Nó de computação e identifique a placa que corresponde ao UUID:

[local]VNF2# show card hardware

Tuesday might 08 16:49:42 UTC 2018

<snip>

Card 8:

Card Type               : 4-Port Service Function Virtual Card

CPU Packages            : 26 [#0, #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25]

CPU Nodes               : 2

CPU Cores/Threads       : 26

Memory                  : 98304M (qvpc-di-large)

UUID/Serial Number      :  49AC5F22-469E-4B84-BADC-031083DB0533

<snip>

Verifique o status da placa:

[local]VNF2# show card table

Tuesday might 08 16:52:53 UTC 2018

Slot         Card Type                               Oper State     SPOF  Attach

-----------  --------------------------------------  -------------  ----  ------

1: CFC      Control Function Virtual Card           Active         No

2: CFC      Control Function Virtual Card           Standby        -

3: FC       4-Port Service Function Virtual Card    Active         No

4: FC       4-Port Service Function Virtual Card    Active         No

5: FC       4-Port Service Function Virtual Card    Active         No

6: FC       4-Port Service Function Virtual Card    Active         No

7: FC       4-Port Service Function Virtual Card    Active         No

8: FC       4-Port Service Function Virtual Card    Active         No

9: FC       4-Port Service Function Virtual Card    Active         No

10: FC       4-Port Service Function Virtual Card    Standby        -

Se a placa estiver no estado ativo, mova-a para o estado de espera:

[local]VNF2# card migrate from 8 to 10

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

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

Pare a VM SF com o uso de seu nome de VM. (Nome da VM observado na seção Identifique as VMs hospedadas no �� do 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

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>

Caso 2. Nó de computação hosts CF/ESC/EM/UAS

Faça login no VNF do StarOS e identifique a placa que corresponde à VM CF. Use o UUID da VM CF identificada na seção Identifique as VMs hospedadas no Nó de computação e localize a placa que corresponde ao UUID:

[local]VNF2# show card hardware

Tuesday might 08 16:49:42 UTC 2018

<snip>

Card 2:

Card Type               : Control Function Virtual Card

CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]

CPU Nodes               : 1

CPU Cores/Threads       : 8

Memory                  : 16384M (qvpc-di-large)

UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2

<snip>

Verifique o status da placa:

[local]VNF2# show card table

Tuesday might 08 16:52:53 UTC 2018

Slot         Card Type                               Oper State     SPOF  Attach

-----------  --------------------------------------  -------------  ----  ------

1: CFC      Control Function Virtual Card           Standby        -

2: CFC      Control Function Virtual Card           Active         No

3: FC       4-Port Service Function Virtual Card    Active         No

4: FC       4-Port Service Function Virtual Card    Active         No

5: FC       4-Port Service Function Virtual Card    Active         No

6: FC       4-Port Service Function Virtual Card    Active         No

7: FC       4-Port Service Function Virtual Card    Active         No

8: FC       4-Port Service Function Virtual Card    Active         No

9: FC       4-Port Service Function Virtual Card    Active         No

10: FC       4-Port Service Function Virtual Card    Standby        -

Se a placa estiver no estado ativo, mova-a para o estado de espera:

[local]VNF2# card migrate from 2 to 1

Faça login no nó ESC que corresponde ao VNF e verifique o status das VMs:

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

<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>

<vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>

<vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>

<vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>

<state>VM_ALIVE_STATE</state>

<snip>

Interrompa as VMs CF e EM um por um com o uso de seu nome de VM. (Nome da VM observado na seção Identifique as VMs hospedadas no �� do nó de computação

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

Depois de parar, as VMs devem 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_SHUTOFF_STATE</state>

<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

<state>VM_ALIVE_STATE</state>

<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>

<vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>

<vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>

<vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>

VM_SHUTOFF_STATE

<snip>

Faça login no ESC hospedado no nó de computação e verifique se ele está no estado mestre. Em caso afirmativo, mudar o sistema ESC para o modo de espera:

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status

0 ESC status=0 ESC Master Healthy

[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop

Stopping keepalived:                                       [  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status

1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ 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!

Substituir a placa-mãe

As etapas para substituir a placa-mãe em um servidor UCS C240 M4 podem ser consultadas em: Guia de instalação e serviço do servidor Cisco UCS C240 M4

Faça login no servidor usando o CIMC IP.

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

Restaure as VMs

Caso 1. Computador nó hospeda somente a VM SF

A VM SF estaria 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     |

Recupere a VM SF 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>

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

Assegure-se de que a placa SF apareça como SF de standby na VNF.

Caso 2. O nó de computação hospeda UAS, ESC, EM e CF

Recuperação da VM UAS

Verifique o status da VM UAS na lista nova e exclua-a:

[stack@director ~]$ nova list | grep VNF2-UAS-uas-0

| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | VNF2-UAS-uas-0                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.10; VNF2-UAS-uas-management=172.168.10.3

[stack@tb5-ospd ~]$ nova delete VNF2-UAS-uas-0

Request to delete server VNF2-UAS-uas-0 has been accepted.

Para recuperar a VM AutoVNF-UAS, execute o script de verificação de UAS para verificar o estado. Ele deve relatar um erro. Em seguida, execute novamente com a —fix option para recriar a VM UAS ausente:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts/

[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS

2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started

2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'

2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors

[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS --fix

2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started

2017-11-22 14:01:09,575 - INFO: Instance VNF2-UAS-uas-0' status is 'ERROR'

2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors

2017-11-22 14:01:09,778 - INFO: Removing instance VNF2-UAS-uas-0'

2017-11-22 14:01:13,568 - INFO: Removed instance VNF2-UAS-uas-0'

2017-11-22 14:01:13,568 - INFO: Creating instance VNF2-UAS-uas-0' and attaching volume ‘VNF2-UAS-uas-vol-0'

2017-11-22 14:01:49,525 - INFO: Created instance ‘VNF2-UAS-uas-0'

Efetue login no AutoVNF-UAS. Aguarde alguns minutos e então você verá que o UAS retorna ao estado bom:

VNF2-autovnf-uas-0#show uas

uas version 1.0.1-1

uas state ha-active

uas ha-vip 172.17.181.101

INSTANCE IP   STATE  ROLE

-----------------------------------

172.17.180.6  alive  CONFD-SLAVE

172.17.180.7  alive  CONFD-MASTER

172.17.180.9  alive  NA

Recuperação de VM ESC

Verifique o status da VM ESC da lista nova e exclua-a:

stack@director scripts]$ nova list |grep ESC-1

| c566efbf-1274-4588-a2d8-0682e17b0d41 | VNF2-ESC-ESC-1                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@director scripts]$ nova delete VNF2-ESC-ESC-1

Request to delete server VNF2-ESC-ESC-1 has been accepted.

No AutoVNF-UAS, localize a transação de implantação ESC e, no registro da transação, localize a linha de comando boot_vm.py para criar a instância ESC:

ubuntu@VNF2-uas-uas-0:~$ sudo -i

root@VNF2-uas-uas-0:~# confd_cli -u admin -C

Welcome to the ConfD CLI

admin connected from 127.0.0.1 using console on VNF2-uas-uas-0

VNF2-uas-uas-0#show transaction

TX ID                                 TX TYPE          DEPLOYMENT ID    TIMESTAMP                         STATUS

-----------------------------------------------------------------------------------------------------------------------------

35eefc4a-d4a9-11e7-bb72-fa163ef8df2b  vnf-deployment   VNF2-DEPLOYMENT  2017-11-29T02:01:27.750692-00:00  deployment-success

73d9c540-d4a8-11e7-bb72-fa163ef8df2b  vnfm-deployment  VNF2-ESC         2017-11-29T01:56:02.133663-00:00  deployment-success

VNF2-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml

<config xmlns="http://tail-f.com/ns/config/1.0">

<logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">

<tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>

<log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: VNF2-ESC, deactivate: 0

2017-11-29 01:56:02,179 - Notify deployment

..

2017-11-29 01:57:30,385 - Creating VNFM 'VNF2-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Salve a linha boot_vm.py em um arquivo de script shell (esc.sh) e atualize todas as linhas de nome de usuário ***** e senha **** com as informações corretas (normalmente core/<PASSWORD>). Você precisa remover a opção —encrypt_key também. Para user_pass e user_confd_pass, você precisa usar o formato - nome de usuário: password (exemplo - admin:<PASSWORD>).

Localize o URL para bootvm.py de running-config e obtenha o arquivo bootvm.py para a VM AutoVNF UAS.  Nesse caso, 10.1.2.3 é o IP da VM AutoIT:

root@VNF2-uas-uas-0:~# confd_cli -u admin -C

Welcome to the ConfD CLI

admin connected from 127.0.0.1 using console on VNF2-uas-uas-0

VNF2-uas-uas-0#show running-config autovnf-vnfm:vnfm

…

configs bootvm

value http:// 10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py

!

root@VNF2-uas-uas-0:~# wget http://10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py

--2017-12-01 20:25:52--  http://10.1.2.3 /bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py

Connecting to 10.1.2.3:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 127771 (125K) [text/x-python]

Saving to: ‘bootvm-2_3_2_155.py’

100%[=====================================================================================>] 127,771  --.-K/s   in 0.001s

2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771]

Crie um arquivo /tmp/esc_params.cfg:

root@VNF2-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg

Execute o script shell para implantar o ESC do nó UAS:

root@VNF2-uas-uas-0:~# /bin/sh esc.sh

+ python ./bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689

--net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url

http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username core --os_password <PASSWORD> --bs_os_auth_url

http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password <PASSWORD>

--esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:<PASSWORD> --user_confd_pass

admin:<PASSWORD> --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3

172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh

--file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py

--file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Faça login no novo ESC e verifique o estado de backup:

ubuntu@VNF2-uas-uas-0:~$ ssh admin@172.168.11.14

…

####################################################################

#   ESC on VNF2-esc-esc-1.novalocal is in BACKUP state.

####################################################################

[admin@VNF2-esc-esc-1 ~]$ escadm status

0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh

============== ESC HA (BACKUP) ===================================================

ESC HEALTH PASSED

Recuperar VMs CF e EM do ESC

Verifique o status das VMs CF e EM na lista nova. Eles devem estar no estado ERRO:

[stack@director ~]$ source corerc

[stack@director ~]$ nova list --field name,host,status |grep -i err

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | None                                 | ERROR|

| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     |None                                 | ERROR

Faça login no ESC Master, execute recovery-vm-action para cada VM e CF afetadas. Seja paciente. O ESC agenda a ação de recuperação e pode não acontecer por alguns minutos. Monitore o yangesc.log:

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8

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

[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-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8]

Faça login no novo EM e verifique se o estado EM está ativo:

ubuntu@VNF2vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C

admin connected from 172.17.180.6 using ssh on VNF2vnfddeploymentem-1

admin@scm# show ems

EM            VNFM

ID  SLA  SCM  PROXY

---------------------

2   up   up   up

3   up   up   up

Faça login no VNF do StarOS e verifique se a placa CF está no estado de espera.

Lidar com falha de recuperação do ESC

Nos casos em que o ESC não inicia a VM devido a um estado inesperado, recomenda-se executar um switchover ESC reiniciando o ESC mestre. O switchover do ESC leva aproximadamente um minuto. Execute o script health.sh no novo ESC mestre para verificar se o status está ativo. Mestre ESC para iniciar a VM e corrigir o estado da VM. Essa tarefa de recuperação leva até 5 minutos para ser concluída.

Você pode monitorar /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se você não vir a recuperação da VM após 5 a 7 minutos, o usuário precisa ir e fazer a recuperação manual das VMs afetadas.

Substituição da placa-mãe no nó de computação OSD

Antes da atividade, as VMs hospedadas no nó Computação são desligadas com facilidade e o Ceph é colocado no modo de manutenção. Depois que a placa-mãe for substituída, as VMs serão restauradas novamente e o Ceph será removido do modo de manutenção.

Coloque o Ceph no modo de manutenção

Verifique se o status ceph osd tree está ativo no servidor.

[heat-admin@pod1-osd-compute-1 ~]$ 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

Faça login no nó de computação OSD e coloque Ceph no modo de manutenção.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance

[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_WARN

noout,norebalance,sortbitwise,require_jewel_osds flag(s) set

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 e194: 12 osds: 12 up, 12 in

flags noout,norebalance,sortbitwise,require_jewel_osds

pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects

1585 GB used, 11808 GB / 13393 GB avail

704 active+clean

client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

Note: Quando o Ceph é removido, o VNF HD RAID entra no estado Degraded, mas o HDD ainda precisa estar acessível.

Identifique as VMs hospedadas no nó Osd-Compute

Identifique as VMs hospedadas no servidor de computação OSD. Podem existir duas possibilidades:

O servidor osd-compute contém a combinação de VMs Element Manager (EM)/UAS/AutoDeploy/AutoIT:

[stack@director ~]$ nova list --field name,host | grep osd-compute-0

| c6144778-9afd-4946-8453-78c817368f18 | AUTO-DEPLOY-VNF2-uas-0                                   | pod1-osd-compute-0.localdomain |

| 2d051522-bce2-4809-8d63-0c0e17f251dc | AUTO-IT-VNF2-uas-0                                       | pod1-osd-compute-0.localdomain |

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-osd-compute-0.localdomain |

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                           | pod1-osd-compute-0.localdomain |

O Servidor de Computação contém a combinação de funções de controle (CF)/controlador de serviços elásticos (ESC)/gerenciador de elementos (EM)/UAS:

[stack@director ~]$ nova list --field name,host | grep osd-compute-1

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |

| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |

| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Note: Na saída mostrada aqui, a primeira coluna corresponde ao UUID, 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.

Desligamento normal

Caso 1. OSD-Computing Node Hosts CF/ESC/EM/UAS

O procedimento para ligar corretamente VMs CF/ESC/EM/UAS é o mesmo independentemente de as VMs estarem hospedadas em nó Computação ou OSD-Compute. Siga as etapas de substituição da placa-mãe no nó de computação para desligar as VMs com cuidado.

Caso 2. OSD-Compute Node Hosts Implantação Automática/AutoIt/EM/UAS

Fazer backup do CDB de implantação automática

Faça backup dos dados do cdb confd de implantação automática periodicamente ou após cada ativação/desativação e salve o arquivo em um servidor de backup. A autoimplantação não é redundante e, se esses dados forem perdidos, você não poderá desativar a implantação com facilidade.

Efetue login no diretório cdb de configuração de backup e da VM de Implantação Automática.

ubuntu@auto-deploy-iso-2007-uas-0:~ $sudo -i

root@auto-deploy-iso-2007-uas-0:~#service uas-confd stop

uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:~# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd

root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd#tar cvf autodeploy_cdb_backup.tar cdb/

cdb/

cdb/O.cdb

cdb/C.cdb

cdb/aaa_init.xml

cdb/A.cdb

root@auto-deploy-iso-2007-uas-0:~# service uas-confd start

uas-confd start/running, process 13852

Observação: copie autoDeployment_cdb_backup.tar para fazer backup do servidor.

Backup System.cfg de TI automática

Faça um backup do arquivo system.cfg para fazer o backup do servidor:

Auto-it = 10.1.1.2

Backup server = 10.2.2.2

[stack@director ~]$ ssh ubuntu@10.1.1.2

ubuntu@10.1.1.2's password:

Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-76-generic x86_64)

* Documentation:  https://help.ubuntu.com/

System information as of Wed Jun 13 16:21:34 UTC 2018

System load:  0.02               Processes:           87

Usage of /:   15.1% of 78.71GB   Users logged in:     0

Memory usage: 13%                IP address for eth0: 172.16.182.4

Swap usage:   0%

Graph this data and manage this system at:

https://landscape.canonical.com/

Get cloud support with Ubuntu Advantage Cloud Guest:

http://www.ubuntu.com/business/services/cloud

Cisco Ultra Services Platform (USP)

Build Date: Wed Feb 14 12:58:22 EST 2018

Description: UAS build assemble-uas#1891

sha1: bf02ced

ubuntu@auto-it-vnf-uas-0:~$ scp -r /opt/cisco/usp/uploads/system.cfg root@10.2.2.2:/home/stack

root@10.2.2.2's password:

system.cfg                                                                                                                                                                                                          100%  565     0.6KB/s   00:00

ubuntu@auto-it-vnf-uas-0:~$

Note: O procedimento para obter a potência normal das VMs EM/UAS é o mesmo, independentemente de as VMs estarem hospedadas no nó Computação ou OSD-Compute.

Siga as etapas de substituição da placa-mãe no nó de computação para desligar essas VMs com cuidado.

Substituir a placa-mãe

As etapas para substituir a placa-mãe em um servidor UCS C240 M4 podem ser consultadas em: Guia de instalação e serviço do servidor Cisco UCS C240 M4

Faça login no servidor usando o CIMC IP.

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

Mova o Ceph para fora do modo de manutenção

Efetue login no nó Computação OSD e mova o Ceph para fora do modo de manutenção.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

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 e196: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects

1585 GB used, 11808 GB / 13393 GB avail

704 active+clean

client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

Restaure as VMs

Caso 1. OSD-Computing Node Hosts CF, ESC, EM e UAS

O procedimento para restaurar VMs CF/ESC/EM/UAS é o mesmo independentemente de as VMs estarem hospedadas no nó Computação ou OSD-Compute. Siga as etapas do Caso 2. Compute Node Hosts CF/ESC/EM/UAS para restaurar as VMs.

Caso 2. O nó de computação OSD hospeda TI automática, implantação automática, EM e UAS

Recupere a VM de implantação automática

No OSPD, se a VM de implantação automática tiver sido afetada, mas ainda mostrar ATIVE/Running, será necessário excluí-la primeiro. Se a implantação automática não tiver sido afetada, pule para Recuperação da VM de Autoit:

[stack@director ~]$ nova list |grep auto-deploy

| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.12, 10.1.2.7 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7 --delete

Depois que a implantação automática for excluída, crie-a novamente com o mesmo endereço ip flutuante:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7

2017-11-17 07:05:03,038 - INFO: Creating AutoDeploy deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'

2017-11-17 07:05:03,039 - INFO: Loading image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'

2017-11-17 07:05:14,603 - INFO: Loaded image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'

2017-11-17 07:05:15,787 - INFO: Assigned floating IP '10.1.2.7' to IP '172.16.181.7'

2017-11-17 07:05:15,788 - INFO: Creating instance 'auto-deploy-ISO-5-1-7-2007-uas-0'

2017-11-17 07:05:42,759 - INFO: Created instance 'auto-deploy-ISO-5-1-7-2007-uas-0'

2017-11-17 07:05:42,759 - INFO: Request completed, floating IP: 10.1.2.7

Copie o arquivo AutoDeployment.cfg, ISO e o arquivo confd_backup tar do servidor de backup para implantar automaticamente VM e restaurar arquivos confd cdb do arquivo tar de backup:

ubuntu@auto-deploy-iso-2007-uas-0:~# sudo -i

ubuntu@auto-deploy-iso-2007-uas-0:#  service uas-confd stop

uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd

root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar xvf /home/ubuntu/ad_cdb_backup.tar

cdb/

cdb/O.cdb

cdb/C.cdb

cdb/aaa_init.xml

cdb/A.cdb

root@auto-deploy-iso-2007-uas-0~# service uas-confd start

uas-confd start/running, process 2036

Verifique se o confd foi carregado corretamente verificando transações anteriores. Atualize o autoDeployment.cfg com o novo nome osd-compute. Consulte a Seção - Etapa final: Atualize a Configuração da Implantação Automática.

root@auto-deploy-iso-2007-uas-0:~# confd_cli -u admin -C

Welcome to the ConfD CLI

admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0

auto-deploy-iso-2007-uas-0#show transaction

SERVICE                                                              SITE

DEPLOYMENT                                                     SITE  TX    AUTOVNF  VNF  AUTOVNF

TX ID          TX TYPE             ID          DATE AND TIME                  STATUS              ID    ID    ID       ID   TX ID

-------------------------------------------------------------------------------------------------------------------------------------

1512571978613  service-deployment  tb5bxb      2017-12-06T14:52:59.412+00:00  deployment-success

auto-deploy-iso-2007-uas-0# exit

Recuperar VM de TI automática

No OSPD, se a VM de autoit foi afetada, mas ainda aparecer como ATIVE/Running, você precisará excluí-la. Se não tiver sido afetado automaticamente, vá para a próxima:

[stack@director ~]$ nova list |grep auto-it

| 580faf80-1d8c-463b-9354-781ea0c0b352 | auto-it-vnf-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.3, 10.1.2.8 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./ auto-it-vnf-staging.sh --floating-ip 10.1.2.8 --delete

Recrie a TI automática executando o script de preparação AutoIT-VNF:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-it-vnf-staging.sh --floating-ip 10.1.2.8

2017-11-16 12:54:31,381 - INFO: Creating StagingServer deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'

2017-11-16 12:54:31,382 - INFO: Loading image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'

2017-11-16 12:54:51,961 - INFO: Loaded image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'

2017-11-16 12:54:53,217 - INFO: Assigned floating IP '10.1.2.8' to IP '172.16.181.9'

2017-11-16 12:54:53,217 - INFO: Creating instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'

2017-11-16 12:55:20,929 - INFO: Created instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'

2017-11-16 12:55:20,930 - INFO: Request completed, floating IP: 10.1.2.8

Recarregue a imagem ISO. Nesse caso, o endereço IP da TI automática é 10.1.2.8. Isso levará alguns minutos para carregar:

[stack@director ~]$ cd images/5_1_7-2007/isos

[stack@director isos]$ curl -F file=@usp-5_1_7-2007.iso http://10.1.2.8:5001/isos

{

"iso-id": "5.1.7-2007"

}

to check the ISO image:

[stack@director isos]$ curl http://10.1.2.8:5001/isos

{

"isos": [

{

"iso-id": "5.1.7-2007"

}

]

}

Copie os arquivos VNF system.cfg do diretório de implantação automática do OSPD para a VM de TI automática:

[stack@director autodeploy]$ scp system-vnf* ubuntu@10.1.2.8:.

ubuntu@10.1.2.8's password:

system-vnf1.cfg                                                                                               100% 1197     1.2KB/s   00:00

system-vnf2.cfg                                                                                               100% 1197     1.2KB/s   00:00

ubuntu@auto-it-vnf-iso-2007-uas-0:~$ pwd

/home/ubuntu

ubuntu@auto-it-vnf-iso-2007-uas-0:~$ ls

system-vnf1.cfg  system-vnf2.cfg

Note: O procedimento de recuperação de EM e UAS VM são os mesmos, independentemente de a VM estar hospedada em Computação ou OSD-Compute. Siga os passos de Replace Motherboard in Compute Node para desligar essas VMs com cuidado.

Substitua a placa-mãe no nó da controladora

Verifique o status do controlador e coloque o cluster no modo de manutenção

No OSPD, faça login na controladora e verifique se os PCs estão em bom estado - todos os três controladores On-line e Galera mostra os três controladores como Master.

[heat-admin@pod1-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Mon Dec 4 00:46:10 2017 Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-0 pod1-controller-1 ]

ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2

my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Coloque o cluster no modo de manutenção:

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby

[heat-admin@pod1-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Mon Dec 4 00:48:24 2017 Last change: Mon Dec 4 00:48:18 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Node pod1-controller-0: standby

Online: [ pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-1 pod1-controller-2 ]

Stopped: [ pod1-controller-0 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-1 pod1-controller-2 ]

Slaves: [ pod1-controller-0 ]

ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-1 ]

Stopped: [ pod1-controller-0 ]

ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2

my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Substituir a placa-mãe

As etapas para substituir a placa-mãe em um servidor UCS C240 M4 podem ser consultadas em: Guia de instalação e serviço do servidor Cisco UCS C240 M4

Faça login no servidor usando o CIMC IP.

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

Restaurar status do cluster

Efetue login no controlador que sofreu impacto, remova o modo de espera definindo unstandby. Verifique se a controladora está on-line com cluster e Galera mostra as três controladoras como Mestre. Isso pode levar alguns minutos.

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby

[heat-admin@pod1-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Mon Dec 4 01:08:10 2017 Last change: Mon Dec 4 01:04:21 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-0 pod1-controller-1 ]

ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2

my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled