Contents

Introduction

Informações de Apoio

Abreviaturas

Identificação e solução de problemas de RMA de componente - Nó de computação/OSD

Etapa 1. Desligamento normal

Identificar as VMs hospedadas no nó Computação/OSD-Compute

Para o desligamento harmonioso da VM do Cluster Manager

Para o desligamento gradual da VM de PD/balanceador de carga ativo

Para o desligamento gradual da VM de controle de carga/PD em standby

Para o desligamento gradual da VM PS/QNS

Para o desligamento gradual da VM OAM/pcrfclient

Para a VM do Arbiter

Etapa 2. Backup de banco de dados ESC.

Etapa 3. Migre o ESC para o modo de espera.

Etapa 4. Substitua o componente com falha do nó de computação/OSD-computação.

Etapa 5. Restaure as VMs.

Recuperação de VM do ESC

Recuperação de VM ESC

Lidar com falha de recuperação do ESC

Solução de problemas de RMA de componente - Nó do controlador

Etapa 1. Controlador - Pré-cheques

Etapa 2. Mova o cluster do controlador para o modo de manutenção.

Etapa 3. Substitua o componente defeituoso do nó do controlador.

Etapa 4. Ligue o servidor.

Introduction

Este documento descreve as etapas necessárias para substituir os componentes defeituosos mencionados aqui em um servidor Cisco Unified Computing System (UCS) em uma configuração Ultra-M que hospeda as funções de rede virtual (VNFs) do Cisco Policy Suite (CPS).

- MOP de substituição de módulo de memória em linha dupla (DIMM)

- Falha do controlador FlexFlash

- Falha da unidade de estado sólido (SSD)

- Falha no Trusted Platform Module (TPM)

- Falha De Cache Raid

- Falha do controlador RAID/adaptador de barramento quente (HBA)

- Falha na riser PCI

- Falha de adaptador PCIe Intel X520 10G

- Falha na placa-mãe modular LAN on (MLOM)

- RMA da bandeja do ventilador

- Falha da CPU

Contribuído por Nitesh Bansal, Cisco Advance Services.

Informações de Apoio

O Ultra-M é uma solução virtualizada 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 versão Ultra M 5.1.x é considerada para definir os procedimentos neste documento.

- 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 de componentes no servidor.

Antes de substituir um componente defeituoso, é importante verificar o status atual do ambiente da plataforma Red Hat Open Stack. Recomenda-se que você verifique o estado atual para evitar complicações quando o processo de substituição estiver ativado.

Em caso de recuperação, a Cisco recomenda fazer o backup do banco de dados OSPD com a ajuda destas etapas:

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql

/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack

tar: Removing leading `/' from member names

Esse processo garante que um nó possa ser substituído sem afetar a disponibilidade das instâncias.

Note: Se um servidor for um nó controlador, vá para a seção , caso contrário, continue com a próxima seção.

Abreviaturas

VNF

Função de rede virtual

PD

Diretor de política (balanceador de carga)

PS

Servidor de política ( pcrfclient )

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

SM

Gerenciador de Sessão

QNS

Servidor de Nome Quântico

UUID

Identificador de ID universal exclusivo

Identificação e solução de problemas de RMA de componente - Nó de computação/OSD

Etapa 1. Desligamento normal

Identificar as VMs hospedadas no nó Computação/OSD-Compute

O Compute/OSD-Compute pode hospedar vários tipos de VM. Identifique todos e prossiga com as etapas individuais junto com o nó baremetal específico e para os nomes de VM específicos hospedados neste computador:

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

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634     |

pod1-compute-10.localdomain    |

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_sm-s3_0_05966301-bd95-4071-817a-0af43757fc88     |

pod1-compute-10.localdomain    |

Para o desligamento harmonioso da VM do Cluster Manager

Etapa 1. Crie um Snapshot e faça FTP do arquivo para outro local fora do servidor ou, se possível, fora do próprio rack.

openstack image create --poll

Etapa 2. Pare a VM do ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < CM vm-name>

Etapa 3. Verifique se a VM está parada.

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

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

<snip>

<state>SERVICE_ACTIVE_STATE</state>

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634

VM_SHUTOFF_STATE

Para o desligamento gradual da VM de PD/balanceador de carga ativo

Etapa 1. Faça login no Lb ativo e interrompa os serviços como abaixo

- Mudar o lb de ativo para standby

service corosync restart

- interromper serviços no standby lb

service monit stop

service qns stop

Passo 2. Do mestre ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

Etapa 3.  Verifique se a VM está parada.

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

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Para o desligamento gradual da VM de controle de carga/PD em standby

Etapa 1. Faça login no lb de standby e interrompa os serviços.

service monit stop

service qns stop

Etapa 2. Do mestre ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

Etapa 3. Verifique se a VM está parada.

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

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Para o desligamento gradual da VM PS/QNS

Etapa 1. Parar o serviço:

service monit stop

service qns stop

Etapa 2. Do mestre ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

Etapa 3.  Verifique se a VM está parada.

[dmin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[dmin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Para o desligamento harmonioso da VM do SM

Etapa 1. Pare todos os serviços mongo presentes no sessionmgr.

[root@sessionmg01 ~]# cd /etc/init.d

[root@sessionmg01 init.d]# ls -l sessionmgr*

[root@sessionmg01 ~]# /etc/init.d/sessionmgr-27717 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27718 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27719 stop Stopping mongod: [  OK  ]

Etapa 2. Do mestre ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

Etapa 3. Verifique se a VM está parada.

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

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Para o desligamento gradual da VM OAM/pcrfclient

Etapa 1. Verifique se a política SVN está sincronizada por meio desses comandos. Se um valor for retornado, o SVN já está sincronizado e você não precisa sincronizá-lo a partir do PCRFCLIENT02. Você deve ignorar a recuperação do último backup e ainda pode ser usado, se necessário.

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

Etapa 2. Restabeleça a sincronização mestre/escravo SVN entre pcrfclient01 e pcrfclient02 com pcrfclient01 como mestre executando a série de comandos no PCRFCLIENT01.

/bin/rm -fr /var/www/svn/repos

/usr/bin/svnadmin create /var/www/svn/repos

/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0

http://pcrfclient02/repos-proxy-sync

/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"

/etc/init.d/vm-init-client

/var/qps/bin/support/recover_svn_sync.sh

Etapa 3.  Faça um backup do SVN no gerenciador de cluster.

config_br.py -a export --svn /mnt/backup/svn_backup_pcrfclient.tgz

Etapa 4.  Desligue os serviços no pcrfclient.

service monit stop

service qns stop

Etapa 5.  Do mestre ESC:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

Etapa 6.  Verifique se a VM está parada.

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

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Para a VM do Arbiter

Etapa 1. Faça login no árbitro e desligue os serviços.

[root@SVS1OAM02 init.d]# ls -lrt sessionmgr*

-rwxr-xr-x 1 root root 4382 Jun 21 07:34 sessionmgr-27721

-rwxr-xr-x 1 root root 4406 Jun 21 07:34 sessionmgr-27718

-rwxr-xr-x 1 root root 4407 Jun 21 07:34 sessionmgr-27719

-rwxr-xr-x 1 root root 4429 Jun 21 07:34 sessionmgr-27717

-rwxr-xr-x 1 root root 4248 Jun 21 07:34 sessionmgr-27720

service monit stop

service qns stop

/etc/init.d/sessionmgr-[portno.] stop , where port no is the db port in the arbiter.

Etapa 2.Do mestre ESC.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

Etapa 3. Verifique se a VM está parada.

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

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Para o controlador de serviços elásticos (ESC)

Etapa 1. O backup das configurações no ESC-HA deve ser mensal, antes/depois de qualquer operação de dimensionamento horizontal ou horizontal com o VNF e antes/depois das alterações de configuração no ESC. É necessário fazer uma cópia de segurança para que a recuperação de catástrofes do CES seja eficaz

1. Faça login no ESC usando credenciais de administrador e exporte opdata para XML.

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u

-p

--get-config > /home/admin/ESC_config.xml

2. Faça o download deste arquivo para seu computador local de ftp/sftp para um servidor fora da nuvem.

Etapa 2. Faça backup da configuração de nuvem PCRF Todos os scripts e arquivos de dados de usuário referenciados em XMLs de implantação.

1. Localize todos os arquivos de dados do usuário referenciados em XMLs de implantação de todas as VNFs do opdata exportado na etapa anterior.Exemplo de saída.

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg

2. Localize todos os scripts de pós-implantação usados para enviar API de orquestração CPS.

3. Exemplos de trechos de script pós-implantação no esc opdata.

Exemplo 1:

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

----------

script_filename

/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py

script_timeout

3600

Exemplo 2:

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

CLUMAN_MGMT_ADDRESS

10.174.132.46

CLUMAN_YAML_FILE

/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml

script_filename

/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py

wait_max_timeout

3600

Se os opdata do ESC de implantação (extraídos na etapa anterior) contiver qualquer um dos arquivos destacados, faça o backup.

Exemplo de comando Backup:

tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/

Faça o download deste arquivo para seu computador local de ftp/sftp para um servidor fora da nuvem.

Note:- Although opdata is synced between ESC master and slave, directories containing user-data, xml and post deploy scripts are not synced across both instances. It is suggested that customers can push the contents of directory containing these files using scp or sftp, these files should be constant across ESC-Master and ESC-Standby in order to recover a deployment when ESC VM which was master during deployment is not available do to any unforeseen circumstances.

Etapa 2. Backup de banco de dados ESC.

Etapa 1. Colete os registros das duas VMs ESC e faça o backup.

$ collect_esc_log.sh

$ scp /tmp/

@

:

Etapa 2. Faça backup do banco de dados a partir do nó ECS mestre.

Etapa 3. Mude para o usuário raiz e verifique o status do ESC primário e valide se o valor de saída é Master.

$ sudo bash

$ escadm status

Set ESC to maintenance mode & verify

$ sudo escadm op_mode set --mode=maintenance

$ escadm op_mode show

Etapa 4. Use uma variável para definir o nome do arquivo e incluir as informações de data, chamar a ferramenta de backup e fornecer a variável de nome de arquivo da etapa anterior.

fname=esc_db_backup_$(date -u +"%y-%m-%d-%H-%M-%S")

$ sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup -- file /tmp/atlpod-esc-master-$fname.tar

Etapa 5. Verifique o arquivo de backup no armazenamento de backup e verifique se ele está lá.

Etapa 6. Coloque o ESC do mestre de volta no modo de operação normal.

$ sudo escadm op_mode set --mode=operation

Se o utilitário de backup de dbtool falhar, aplique a seguinte solução uma vez no nó ESC. Em seguida, repita a etapa 6.

$ sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump,"

/opt/cisco/esc/esc-scripts/esc_dbtool.py

Etapa 3. Migre o ESC para o modo de espera.

Etapa 1. Faça login no ESC hospedado no nó e verifique se ele está no estado mestre. Se sim, mude o 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!

Etapa 2. Quando a VM estiver em espera ESC, desligue a VM pelo comando: shutdown -r now

Note: Se o componente defeituoso for substituído no nó OSD-Compute, coloque o CEPH em Manutenção no servidor antes de continuar com a substituição do 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

Etapa 4. Substitua o componente com falha do nó de computação/OSD-computação.

Desligue o servidor especificado. As etapas para substituir um componente defeituoso no servidor UCS C240 M4 podem ser consultadas a partir de:

Substituindo os componentes do servidor

Consulte o registro persistente no procedimento abaixo e execute conforme necessário

Etapa 5. Restaure as VMs.

Recuperação de VM do ESC

1. A VM 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     |

2. Recupere as VMs 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

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

4. Verifique todos os serviços nas VMs sendo iniciadas.

Recuperação de VM ESC

1. Faça login no ESC via console e verifique o status.

2. Inicie os processos caso ainda não tenha sido iniciado

[admin@esc ~]$ sudo service keepalived start

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

Lidar com falha de recuperação do ESC

Nos casos em que o ESC não inicia a VM devido a um estado inesperado, a Cisco recomenda executar um switchover ESC reiniciando o ESC mestre. A transição para o ESC levaria cerca de um minuto. Execute o script "health.sh" no novo ESC principal para verificar se o status está ativo. Mestre ESC para iniciar a VM e corrigir o estado da VM. Essa tarefa de recuperação levaria 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 VM sendo recuperada após 5 a 7 minutos, o usuário precisaria ir e fazer a recuperação manual das VMs afetadas.

Caso a VM ESC não seja recuperada, siga o procedimento para implantar uma nova VM ESC. Entre em contato com o Suporte da Cisco para saber como proceder.

Solução de problemas de RMA de componente - Nó do controlador

Etapa 1. Controlador - Pré-cheques

Do OSPD, faça login no controlador e verifique se os pcs estão em bom estado - todos os três controladores online e galera mostrando os três controladores como master.

Note: Um cluster em bom estado exige 2 controladores ativos, portanto, verifique se os dois controladores restantes estão On-line 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

Etapa 2. Mova o cluster do controlador para o modo de manutenção.

1. Coloque o cluster de pcs no controlador sendo atualizado em standby.

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

2. Verifique o status dos pcs novamente e certifique-se de que o cluster dos pcs parou 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

3. Além disso, o status dos pcs nos outros 2 controladores deve mostrar o nó como standby.

Etapa 3. Substitua o componente defeituoso do nó do controlador.

Desligue o servidor especificado. As etapas para substituir um componente defeituoso no servidor UCS C240 M4 podem ser consultadas a partir de:

Substituindo os componentes do servidor

Etapa 4. Ligue o servidor.

1. Ligue o servidor e verifique se ele está ativado.

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

2. Faça login no controlador afetado e remova o modo de espera definindo o modo de não espera. Verifique se o controlador vem on-line com cluster e galera mostra todos os três controladores 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-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

3. Você pode verificar alguns dos serviços de monitoramento, como o ceph, de que eles estão 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