Índice

Introdução

Informações de Apoio

Abreviaturas

Trabalhos do espanador

Pré-requisitos

Backup

Componente RMA - Nó Compute/OSD-Compute

Identifique os VM hospedados no nó Compute/OSD-Compute

Sem energia gracioso

Encaixote 1. SF VM dos anfitriões do nó do cálculo somente

Encaixote 2. anfitriões CF/ESC/EM/UAS do nó Compute/OSD-Compute

Substitua o componente defeituoso do nó Compute/OSD-Compute

Restaure os VM

Encaixote 1. SF VM dos anfitriões do nó do cálculo somente

Encaixote 2. anfitriões CF, ESC, EM e UA do nó Compute/OSD-Compute

Segure a falha da recuperação ESC

Auto-distribua a atualização de configuração

Componente RMA - Nó do controlador

PRE-verificação

Mova o conjunto do controlador para o modo de manutenção

Substitua o componente defeituoso do nó do controlador

Potência no server

Introdução

Este documento descreve as etapas exigidas para substituir os componentes defeituosos mencionados aqui em um server do sistema de Unified Computing (UCS) em um Ultra-M setup que a rede virtual de StarOS dos anfitriões funciona (VNFs).

- ESPANADOR da substituição do módulo dual in-line memory (DIMM)

- Falha de controlador de FlexFlash

- Falha de circuito integrado da movimentação (SSD)

- Falha confiada do módulo da plataforma (TPM)

- Falha do esconderijo da invasão

- Falha quente do adaptador do barramento do controlador da invasão (HBA)

- Falha do montante PCI

- Falha de Intel X520 10G do adaptador de PCIe

- Modular LAN-na falha do cartão-matriz (MLOM)

- Fan tray RMA

- Falha CPU

Informações de Apoio

Ultra-M é uma solução móvel virtualizada pré-embalada e validada do núcleo do pacote que seja projetada a fim simplificar o desenvolvimento de VNFs. OpenStack é o gerente virtualizado da infraestrutura (VIM) para Ultra-M e consiste nestes tipos de nó:

- Cálculo

- Disco do armazenamento do objeto - Cálculo (OSD - Cálculo)

- Controlador

- Plataforma de OpenStack - Diretor (OSPD)

A arquitetura de nível elevado de Ultra-M e os componentes envolvidos são descritos nesta imagem:

Este documento é pretendido para os Ciscos personnel que são familiares com a plataforma de Cisco Ultra-M e detalha as etapas exigidas ser realizado a nível de OpenStack e de StarOS VNF na altura da substituição componente no server.

Nota: A liberação M 5.1.x é considerada ultra a fim definir os procedimentos neste documento.

Abreviaturas

VNF

Função da rede virtual

CF

Função de controle

SF

Função de serviço

ESC

Controlador elástico do serviço

ESPANADOR

Método do procedimento

OSD

Discos do armazenamento do objeto

HDD

Unidade de disco rígido

SSD

Movimentação de circuito integrado

VIM

Gerente virtual da infraestrutura

VM

Máquina virtual

EM

Element Manager

UA

Ultra Automation Services

UUID

Universalmente identificador exclusivo

Trabalhos do espanador

Pré-requisitos

Backup

Antes que você substitua um componente defeituoso, é importante verificar o estado atual de seu ambiente da plataforma de OpenStack do chapéu vermelho. Recomenda-se o verificação o estado atual a fim evitar complicações quando o processo de substituição está ligada. Pode ser conseguido por este fluxo da substituição.

Em caso da recuperação, Cisco recomenda tomar um backup do base 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

Este processo assegura-se de que um nó possa ser substituído sem afetar a Disponibilidade de todos os exemplos. Também, é backup recomendado a configuração de StarOS especialmente se o nó compute/OSD-compute a ser substituído hospeda a máquina virtual da função de controle (CF) (VM).

Nota: Se o server é o nó do controlador, continue ao "" da seção, se não continue com a próxima seção.

Componente RMA - Nó Compute/OSD-Compute

Identifique os VM hospedados no nó Compute/OSD-Compute

Identifique os VM que são hospedados no server. Pode haver duas possibilidades:

- O server contém somente a função de serviço (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    |

- Server contém função de controle (CF) /Elastic serviços controlador (ESC)/Element Manager) (EM/ultra combinação dos serviços da automatização (UA) de VM:

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

Nota: Na saída mostrada aqui, a primeira coluna corresponde universalmente ao identificador exclusivo (UUID), a segunda coluna é o nome VM e a terceira coluna é o hostname onde o VM esta presente. Os parâmetros desta saída serão usados nas seções subsequente.

Sem energia gracioso

Encaixote 1. SF VM dos anfitriões do nó do cálculo somente

Migre o cartão do SF ao estado à espera

- Entre ao StarOS VNF e identifique o cartão que corresponde ao SF VM. Use o UUID do SF VM identificado da seção “identificam os VM hospedados no nó Compute/OSD-Compute”, e identificam o cartão 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

- Verifique o estado do cartão:

[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 o cartão está no estado ativo, mova o cartão para o estado à espera:

[local]VNF2# card migrate from 8 to 10

SF VM da parada programada do ESC

- Entre ao nó ESC que corresponde ao VNF e verifique o estado do SF VM:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

VM_ALIVE_STATE

VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

VM_ALIVE_STATE</state>

<snip>

- Pare o SF VM com o uso de seu nome VM. (O nome VM notável da seção “identifica os VM hospedados no nó Compute/OSD-Compute”):

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

- Uma vez que é parado, o VM deve incorporar o estado do DESLIGAMENTO:

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

VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

VM_ALIVE_STATE

VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

VM_ALIVE_STATE

VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

VM_SHUTOFF_STATE</state>

Anfitriões CF/ESC/EM/UAS do nó do caso 2. Compute/OSD-Compute

Migre o cartão CF ao estado à espera

- Entre ao StarOS VNF e identifique o cartão que corresponde ao CF VM. Use o UUID do CF VM identificado da seção “identificam os VM hospedados no nó”, e encontram o cartão 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 estado do cartão:

[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 o cartão está no estado ativo, mova o cartão para o estado à espera:

[local]VNF2# card migrate from 2 to 1

Parada programada CF e EM VM do ESC

- Entre ao nó ESC que corresponde ao VNF e verifique o estado dos VM:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

VM_ALIVE_STATE</state>

VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

VM_ALIVE_STATE

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

507d67c2-1d00-4321-b9d1-da879af524f8

dc168a6a-4aeb-4e81-abd9-91d7568b5f7c

9ffec58b-4b9d-4072-b944-5413bf7fcf07

SERVICE_ACTIVE_STATE

VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

VM_ALIVE_STATE</state>

<snip>

- Pare o CF e o EM VM um a um com o uso de seu nome VM. (O nome VM notável da seção “identifica os VM hospedados no nó Compute/OSD-Compute”):

[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 que para, os VM devem incorporar o estado do DESLIGAMENTO:

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

VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

VM_SHUTOFF_STATE</state>

VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

VM_ALIVE_STATE

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

507d67c2-1d00-4321-b9d1-da879af524f8

dc168a6a-4aeb-4e81-abd9-91d7568b5f7c

9ffec58b-4b9d-4072-b944-5413bf7fcf07

SERVICE_ACTIVE_STATE

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

<state>VM_SHUTOFF_STATE</state>

<snip>

Migre o ESC ao modo standby

- Entre ao ESC hospedado no nó e verifique se está no estado mestre. Se sim, comute o ESC ao modo standby:

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

Nota: Se o componente defeituoso deve ser substituída no nó do OSD-cálculo, põe o Ceph na manutenção sobre o server antes que você continue com a substituição componente.

[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance

set norebalance

[admin@osd-compute-0 ~]$ sudo ceph osd set noout

set noout

[admin@osd-compute-0 ~]$ 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 {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-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

Substitua o componente defeituoso do nó Compute/OSD-Compute

Sem energia o server especificado. As etapas a fim substituir um componente defeituoso no server UCS C240 M4 podem ser consultadas de:

Substituindo os componentes de servidor

Restaure os VM

Encaixote 1. SF VM dos anfitriões do nó do cálculo somente

Recuperação do SF VM do ESC

- O SF VM estaria no estado de erro na lista da 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 o SF VM do ESC:

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

[sudo] password for admin:

Recovery VM Action

/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">

<ok/>

</rpc-reply>

- Monitore 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 o cartão do SF venha acima como o SF à espera no VNF

Encaixote 2. anfitriões CF, ESC, EM e UA do nó Compute/OSD-Compute

Recuperação de UA VM

- Verifique o estado dos UA VM na lista da nova e suprima d:

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

- A fim recuperar os autovnf-UA VM, execute o script da UA-verificação a fim verificar o estado. Deve relatar um erro. Seja executado então outra vez com --fixe a opção a fim recrear os UA faltantes VM:

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

- Entre aos autovnf-UA. Espere alguns minutos e os UA devem retornar ao bom estado:

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

Nota: Se uas-check.py --o reparo falha, você pôde precisar de copiar outra vez estes arquivo e corrida.

[stack@director ~]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/

[stack@director ~]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/

Recuperação de ESC VM

- Verifique o estado do ESC VM da lista da nova e suprima d:

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.

- Dos AutoVNF-UA, encontre a transação do desenvolvimento ESC e no log para a transação para encontrar a linha de comando boot_vm.py a fim criar o exemplo 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

Salvar a linha boot_vm.py a um arquivo do script de shell (esc.sh) e atualize todas as linhas do ***** username e do ***** da senha com a informação correta (tipicamente core/<PASSWORD>). Você precisa de remover também – a opção do encrypt_key. Para user_pass e user_confd_pass, você precisa de usar o formato – username: senha (exemplo de admin: <PASSWORD>).

- Encontre a URL bootvm.py da executar-configuração e do wget o bootvm.pyfile aos autovnf-UA VM.  Neste caso, 10.1.2.3 é o IP Auto-TI o VM:

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 de /tmp/esc_params.cfg:

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

- Execute o script de shell a fim distribuir o ESC do nó UA:

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

- Entre ao ESC novo e verifique o estado alternativo:

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

Recupere CF e EM VM do ESC

- Verifique o estado do CF e do EM VM da lista da nova. Devem estar no estado de 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

- Entre ao mestre ESC, execute a recuperação-vm-ação para cada EM e CF impactados VM. Seja paciente. O ESC programaria a ação de recuperação e não pôde acontecer por alguns minutos. Monitore yangesc.log:

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO <VM-Name>

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

- Entre ao EM novo e verifique que estado EM está acima:

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

- O log no StarOS VNF e verifica que o cartão CF está no estado à espera

Falha da recuperação do punho ESC

Nos casos onde o ESC não começa o VM devido a um estado inesperado, Cisco recomenda como executar um switchover ESC recarregando o mestre ESC. O switchover ESC tomaria aproximadamente um minuto. Execute o script “health.sh” no mestre novo ESC a fim verificar se o estado está acima. Domine o ESC para começar o VM e para fixar o estado VM. Esta tarefa da recuperação tomaria até os minutos 5 para terminar.

Você pode monitorar /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se você não vê que o VM obtém recuperado após 5-7 minutos, o usuário precisaria de ir fazer a recuperação manual do VM impactado.

Auto-distribua a atualização de configuração

- De AutoDeploy VM, edite o autodeploy.cfg e substitua o server velho do cálculo com o novo. Então a carga substitui no confd_cli. Esta etapa é exigida para a desativação da distribuição bem sucedida mais tarde:

root@auto-deploy-iso-2007-uas-0:/home/ubuntu# 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#config

Entering configuration mode terminal

auto-deploy-iso-2007-uas-0(config)#load replace autodeploy.cfg

Loading.     14.63 KiB parsed in 0.42 sec (34.16 KiB/sec)

auto-deploy-iso-2007-uas-0(config)#commit

Commit complete.

auto-deploy-iso-2007-uas-0(config)#end

- Reinicie UA-confd e serviços autodeploy após a alteração de configuração:

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

uas-confd stop/waiting

uas-confd start/running, process 14078

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

uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service autodeploy restart

autodeploy stop/waiting

autodeploy start/running, process 14017

root@auto-deploy-iso-2007-uas-0:~# service autodeploy status

autodeploy start/running, process 14017

Componente RMA - Nó do controlador

PRE-verificação

- De OSPD, o início de uma sessão ao controlador e verifica que os PCes estão em um bom estado – todos os três Online e Galera dos controladores mostram todos os três controladores como o mestre.

Nota: Um conjunto saudável exige 2 controladores ativo assim que verifique que os dois controladores que permanecem são em linha e ativos.

[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-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-0

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

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

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Mova o conjunto do controlador para o modo de manutenção

- Use os PCes aglomeram-se no controlador que é atualizado no apoio:

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

- Verifique o estado dos PCes outra vez e assegure-se de que os PCes se aglomerem parado neste nó:

[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-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1

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

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

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Também, o estado dos PCes em outros 2 controladores deve mostrar o nó como o apoio.

Substitua o componente defeituoso do nó do controlador

Sem energia o server especificado. As etapas a fim substituir um componente defeituoso no server UCS C240 M4 podem ser consultadas de:

Substituindo os componentes de servidor

Potência no server

- A potência no server e verifica que o server vem acima:

[stack@tb5-ospd ~]$ source stackrc

[stack@tb5-ospd ~]$ nova list |grep pod1-controller-0

| 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.112 |

- Entre ao controlador impactado, remova o modo standby com o uso de unstandby. Verifique que o controlador vem em linha com conjunto e Galera mostra todos os três controladores como o mestre. Isto pôde tomar 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-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1

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

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

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

- Você pode verificar alguns dos serviços do monitor tais como o ceph que estejam em um estado saudável:

[heat-admin@pod1-controller-0 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {pod1-controller-0=11.118.0.10:6789/0,pod1-controller-1=11.118.0.11:6789/0,pod1-controller-2=11.118.0.12:6789/0}

election epoch 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2

osdmap e218: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects

2142 GB used, 11251 GB / 13393 GB avail

704 active+clean

client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr