Substituição do cartão-matriz no server de Ultra- M UCS 240M4 - CP

Transcrição

1 Substituição do cartão-matriz no server de Ultra- M UCS 240M4 - CP Índice Introdução Informações de Apoio Abreviaturas Trabalhos do espanador Substituição do cartão-matriz na instalação de Ultra-M Substituição do cartão-matriz no nó do cálculo Identifique os VM hospedados no nó do cálculo Sem energia gracioso O nó do cálculo hospeda CPS/ESC VM Backup ESC Base de dados alternativo ESC Substitua o cartão-matriz Restaure os VM Compute os anfitriões CP do nó, ESC Restaure os CP VM Substituição do cartão-matriz no nó do cálculo OSD Põe CEPH no modo de manutenção Identifique os VM hospedados no nó do OSD-cálculo Sem energia gracioso O nó do OSD-cálculo do caso 1. hospeda o ESC Substitua o cartão-matriz Mova CEPH fora do modo de manutenção Restaure os VM Encaixote 1. nós do OSD-cálculo que hospedam ESC ou CP VM Substituição do cartão-matriz no nó do controlador Verifique o status de controle e põe o conjunto no modo de manutenção Substitua o cartão-matriz Restaure o estado do conjunto Introdução Este original descreve as etapas exigidas para substituir o cartão-matriz defeituoso de um server em um Ultra-M setup que a rede virtual dos anfitriões CP funciona (VNFs). 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

2 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: Arquitetura de UltraM Este original é pretendido para os Ciscos personnel que são familiares com a plataforma de Cisco Ultra-M e detalha as etapas que são exigidas ser realizadas a nível de OpenStack e de StarOS VNF na altura da substituição do cartão-matriz em um server. Note: A liberação M 5.1.x é considerada ultra a fim definir os procedimentos neste original. Abreviaturas VNF Função da rede virtual ESC Controlador elástico do serviço ESPANAD Método do procedimento

3 OR OSD HDD SSD VIM VM EM UA UUID Discos do armazenamento do objeto Unidade de disco rígido Movimentação de circuito integrado Gerente virtual da infraestrutura Máquina virtual Element Manager Ultra Automation Services Universalmente identificador exclusivo Trabalhos do espanador

4

5 Trabalhos de nível elevado do procedimento de substituição Substituição do cartão-matriz na instalação de Ultra-M Em uma instalação de Ultra-M, pode haver as encenações onde uma substituição do cartãomatriz é exigida nos seguintes tipos de servidor: Cálculo, OSD-cálculo e controlador. Note: Os discos de inicialização com a instalação do openstack são substituídos após a substituição do cartão-matriz. Daqui não há nenhuma exigência adicionar o nó de volta a encobre. Uma vez que o server é posto SOBRE após a atividade da substituição, registrarse-ia de volta à pilha encobrir. Substituição do cartão-matriz no nó do cálculo Antes da atividade, os VM hospedados no nó do cálculo são graciosamente desligamento. Uma vez que o cartão-matriz foi substituído, os VM estão restaurados para trás. Identifique os VM hospedados no nó do cálculo Identifique os VM que são hospedados no server do cálculo. O server do cálculo contém CP ou controlador dos serviços do elástico (ESC) VM: [stack@director ~]$ nova list --field name,host grep compute-8 507d67c2-1d b9d1-da879af524f8 VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea pod1-compute-8.localdomain f9c0763a-4a4f-4bbd-af51-bc be2 VNF2-DEPLOYM_c1_0_df4be88d-b4bf a ee229 pod1-compute-8.localdomain ef4b-4d68-b05d VNF2-ESC-ESC- 0 pod1-compute-8.localdomain Note: 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 O nó do cálculo hospeda CPS/ESC VM Etapa 1. Entre ao nó ESC que corresponde ao VNF e verifica 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> <vm_name>vnf2-deploym_c1_0_df4be88d-b4bf a ee229</vm_name> <state>vm_alive_state</state>

6 <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-1d b9d1-da879af524f8</vm_id> <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id> <vm_id>9ffec58b-4b9d-4072-b bf7fcf07</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> Etapa 2. Pare os CP 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ó do cálculo). [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 a ee229</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-1d b9d1-da879af524f8</vm_id> <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id> <vm_id>9ffec58b-4b9d-4072-b bf7fcf07</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> Etapa 3. 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> <vm_name>vnf2-deploym_c1_0_df4be88d-b4bf a ee229</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-1d b9d1-da879af524f8</vm_id> <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id> <vm_id>9ffec58b-4b9d-4072-b bf7fcf07</vm_id> <state>service_active_state</state> <vm_name>vnf2-deploym_xxxx_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name> <state>vm_shutoff_state</state> <snip> Etapa 4. Entre ao ESC hospedado no nó do cálculo e verifique se está no estado mestre. Se sim, comute o ESC ao modo standby: [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>

7 <state>service_active_state</state> <vm_name>vnf2-deploym_c1_0_df4be88d-b4bf a ee229</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-1d b9d1-da879af524f8</vm_id> <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id> <vm_id>9ffec58b-4b9d-4072-b bf7fcf07</vm_id> <state>service_active_state</state> <vm_name>vnf2-deploym_xxxx_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name> <state>vm_shutoff_state</state> <snip> Backup ESC Etapa 1. O ESC tem a Redundância de 1:1 na solução de UltraM. 2 ESC VM são distribuídos e os apoios escolhem a falha em UltraM. isto é o sistema é recuperado se há uma única falha no sistema. Note: Se há mais do que uma única falha, não está apoiada e pode exigir a redisposição do sistema. Detalhes alternativos ESC: Configuração running ConfD CDB DB Logs ESC Configuração do Syslog Etapa 2. A frequência do backup ESC DB é complicada e precisa de ser segurada com cuidado como monitores ESC e mantém as várias máquinas de estado para vário VNF VM distribuídas. Recomenda-se que estes backup estão executados após seguintes atividades em VNF/POD/Site dado Etapa 3. Verifique que a saúde do ESC é boa para usar o script de health.sh. [root@auto-test-vnfm1-esc-0 admin]# escadm status 0 ESC status=0 ESC Master Healthy [root@auto-test-vnfm1-esc-0 admin]# health.sh esc ui is disabled -- skipping status check esc_monitor start/running, process 836 esc_mona is up and running... vimmanager start/running, process 2741 vimmanager start/running, process 2741 esc_confd is started tomcat6 (pid 2907) is running... [ OK ] postgresql-9.4 (pid 2660) is running... ESC service is running... Active VIM = OPENSTACK ESC Operation Mode=OPERATION /opt/cisco/esc/esc_database is a mountpoint ============== ESC HA (MASTER) with DRBD =================

8 DRBD_ROLE_CHECK=0 MNT_ESC_DATABSE_CHECK=0 VIMMANAGER_RET=0 ESC_CHECK=0 STORAGE_CHECK=0 ESC_SERVICE_RET=0 MONA_RET=0 ESC_MONITOR_RET=0 ======================================= ESC HEALTH PASSED Etapa 4. Tome um backup da configuração running e transfira o arquivo ao servidor de backup. [root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C admin connected from using console on auto-test-vnfm1-esc-0.novalocal auto-test-vnfm1-esc-0# show running-config save /tmp/running-esc cfg auto-test-vnfm1-esc-0#exit [root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc cfg -rw tomcat tomcat Dec 20 21:37 /tmp/running-esc cfg Base de dados alternativo ESC Etapa 1. Entre a ESC VM e execute este comando antes que você tome o backup. [admin@esc ~]# sudo bash [root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/escscripts/esc_dbtool.py.bkup [root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py #Set ESC to mainenance mode [root@esc esc-scripts]# escadm op_mode set --mode=maintenance Etapa 2. Verifique o modo ESC e assegure-se de que reaja do modo de manutenção. [root@esc esc-scripts]# escadm op_mode show Etapa 3. Backup de base de dados usando a ferramenta da restauração do backup da base de dados disponível no ESC. [root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file scp://<username>:<password>@<backup_vm_ip>:<filename> Etapa 4. Ajuste o ESC de volta ao modo de operação e confirme o modo. [root@esc scripts]# escadm op_mode set --mode=operation [root@esc scripts]# escadm op_mode show Etapa 5. Navegue ao diretório dos scripts e recolha os logs. [root@esc scripts]# /opt/cisco/esc/esc-scripts

9 sudo./collect_esc_log.sh Etapa 6. Para criar um instantâneo da parada programada ESC primeiro o ESC. sudo./collect_esc_log.sh Etapa 7. De OSPD crie um instantâneo da imagem. sudo./collect_esc_log.sh Etapa 8. Verifique que o instantâneo está criado sudo./collect_esc_log.sh Etapa 9. Comece o ESC de OSPD sudo./collect_esc_log.sh Etapa 10. Repita o mesmo procedimento em ESC à espera VM & transfira os logs ao servidor de backup. Etapa p11. Recolha o backup de configuração do Syslog em ambo o ESC VMS e transfira-os ao servidor de backup. [admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d [admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf 00-escmanager.conf [admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf 01-messages.conf [admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf 02-mona.conf [admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf rsyslog.conf Substitua o cartão-matriz Etapa 1. As etapas a fim substituir o cartão-matriz em um server UCS C240 M4 podem ser consultadas de: Instalação do servidor de Cisco UCS C240 M4 e guia do serviço Etapa 2. Início de uma sessão ao server com o uso do IP CIMC Etapa 3. Execute a elevação BIOS se o firmware não é conforme a versão recomendada usada previamente. As etapas para a elevação BIOS são dadas aqui: Guia da elevação do server BIOS do montagem de rack da série C de Cisco UCS Restaure os VM Compute os anfitriões CP do nó, ESC

10 Recuperação de ESC VM Etapa 1. O ESC VM é recuperável se o VM está no erro ou o estado de fechamento faz uma repartição dura para trazer acima do VM impactado. Execute estas etapas para recuperar o ESC. Etapa 2. Identifique o VM que está no ERRO ou no estado de fechamento, duro-repartição uma vez identificada o ESC VM. Neste exemplo, recarregue auto-test-vnfm1-esc-0 [root@tb1-baremetal scripts]# nova list grep auto-test-vnfm1-esc- f03e3cac-a78a-439f-952b-045aea5b0d2c auto-test-vnfm1-esc- 0 ACTIVE - running auto-testautovnf1- uas-orchestration= ; auto-testautovnf1-uasmanagement= e0d a bce auto-test-vnfm1-esc- 1 ACTIVE - running auto-testautovnf1- uas-orchestration= ; auto-testautovnf1-uasmanagement= [root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a- 439f-952b-045aea5b0d2c\ Request to reboot server <Server: auto-test-vnfm1-esc-0> has been accepted. [root@tb1-baremetal scripts]# Etapa 3. Se o ESC VM é suprimido e precisa de ser trazido acima outra vez. [stack@pod1-ospd scripts]$ nova list grep ESC-1 c566efbf a2d8-0682e17b0d41 vnf1-esc-esc- 1 ACTIVE - running vnf1- UAS-uas-orchestration= ; vnf1-uas-uasmanagement= [stack@pod1-ospd scripts]$ nova delete vnf1-esc-esc-1 Request to delete server vnf1-esc-esc-1 has been accepted. Etapa 4. De OSPD, verifique ESC novo VM é ATIVE/running: [stack@pod1-ospd ~]$ nova list grep -i esc a4-d634-40c0-a51e-fc8d55ec7144 vnf1-esc-esc- 0 ACTIVE - running vnf1- UAS-uas-orchestration= ; vnf1-uas-uasmanagement= b8ec-8ff a-e859f6642ab6 vnf1-esc-esc- 1 ACTIVE - running vnf1- UAS-uas-orchestration= ; vnf1-uas-uasmanagement= #Log in to new ESC and verify Backup state. You may execute health.sh on ESC Master too.

11 #################################################################### # ESC on vnf1-esc-esc-1.novalocal is in BACKUP state. #################################################################### [admin@esc-1 ~]$ escadm status 0 ESC status=0 ESC Backup Healthy [admin@esc-1 ~]$ health.sh ============== ESC HA (BACKUP) ================= ======================================= ESC HEALTH PASSED [admin@esc-1 ~]$ cat /proc/drbd version: (api:1/proto:86-101) GIT-hash: 3a6a769340ef93b1ba2792c db49 build by mockbuild@build64r6, :27:11 1: cs:connected ro:secondary/primary ds:uptodate/uptodate C r----- ns:0 nr: dw: dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0 Etapa 5. Se o ESC VM é unrecoverable e exige a restauração do base de dados, restaure por favor o base de dados do backup previamente tomado. Etapa 6. Para a restauração do base de dados ESC, nós temos que assegurar-se de que o serviço esc esteja parado antes de restaurar o base de dados; Para ESC HA, execute no VM secundário primeiramente e então o VM preliminar. # service keepalived stop Etapa 7. Verifique o estado do serviço ESC e assegure-se de que tudo esteja parado em VM preliminares e secundários para o HA # escadm status Etapa 8. Execute o script para restaurar o base de dados. Como parte da restauração do DB ao exemplo recém-criado ESC, a ferramenta igualmente promoverá um dos exemplos para ser um ESC preliminar, monta seu dobrador DB ao dispositivo do drbd e começará o base de dados de PostgreSQL. # /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename> Etapa 9. Reinicie o serviço ESC para terminar a restauração do base de dados. Para o HA execute em ambos os VM, reiniciam o serviço keepalived # service keepalived start Etapa 10. Uma vez que o VM é restaurado com sucesso e ser executado; assegure-se de que toda a configuração específica do Syslog esteja restaurada do backup conhecido bem sucedido precedente. Assegure-se de que esteja restaurada em todo o ESC VM [admin@auto-test-vnfm2-esc-1 ~]$ [admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d [admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf

12 00-escmanager.conf rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf 01-messages.conf rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf 02-mona.conf rsyslog.d]$ls /etc/rsyslog.conf rsyslog.conf Etapa 11. Se o ESC precisa de ser reconstruído do comando abaixo do uso do instantâneo OSPD usando o instantâneo tomado durante o backup nova rebuild --poll --name esc_snapshot_27aug2018 esc1 Etapa 12. Verifique o estado do ESC depois que a reconstrução está completa nova list --fileds name,host,status,networks grep esc Etapa 13. Verifique a saúde ESC com o comando abaixo health.sh Copy Datamodel to a backup file /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt Restaure os CP VM Os CP VM estariam 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 db0533 VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d ERROR - NOSTATE Recupere os CP 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= 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, Nov-2017 WARN Type: VM_RECOVERY_COMPLETE 14:59:50, Nov-2017 WARN Status: SUCCESS

13 14:59:50, Nov-2017 WARN Status Code: :59:50, Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [VNF2- DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d]. Quando o ESC não começa o VM Etapa 1. Em alguns casos, o ESC não começará o VM devido a um estado inesperado. Uma ação alternativa é executar um switchover ESC recarregando o mestre ESC. O switchover ESC tomará aproximadamente um minuto. Execute health.sh no mestre novo ESC para verificar que está acima. Quando o ESC se transforma mestre, o ESC pode fixar o estado VM e começar o VM. Desde que esta operação é programada, você deve esperar 5-7 minutos por ela para terminar. Etapa 2. Você pode monitorar /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se você não vê o VM obter recuperado após 5-7 minutos, o usuário precisaria de ir fazer a recuperação manual do VM impactado. Etapa 3. Uma vez que o VM é restaurado com sucesso e ser executado; assegure-se de que toda a configuração específica do Syslog esteja restaurada do backup conhecido bem sucedido precedente. Assegure-se de que esteja restaurada em todo o ESC VM. root@autotestvnfm1esc2:/etc/rsyslog.d# pwd /etc/rsyslog.d root@autotestvnfm1esc2:/etc/rsyslog.d# ll total 28 drwxr-xr-x 2 root root 4096 Jun 7 18:38./ drwxr-xr-x 86 root root 4096 Jun 6 20:33../] -rw-r--r-- 1 root root 319 Jun 7 18:36 00-vnmf-proxy.conf -rw-r--r-- 1 root root 317 Jun 7 18:38 01-ncs-java.conf -rw-r--r-- 1 root root 311 Mar ufw.conf -rw-r--r-- 1 root root 252 Nov cloudinit.conf -rw-r--r-- 1 root root 1655 Apr default.conf root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf rsyslog.conf Substituição do cartão-matriz no nó do cálculo OSD Antes da atividade, os VM hospedados no nó do cálculo são graciosamente desligamento e o CEPH é posto no modo de manutenção. Uma vez que o cartão-matriz foi substituído, os VM estão restaurados para trás e CEPH é movido fora do modo de manutenção. Põe CEPH no modo de manutenção Etapa 1. Verifique que estado da árvore do osd do ceph está acima no server [heat-admin@pod1-osd-compute-1 ~]$ sudo ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY root default host pod1-osd-compute osd.0 up osd.3 up

14 osd.6 up osd.9 up host pod1-osd-compute osd.1 up osd.4 up osd.7 up osd.10 up host pod1-osd-compute osd.2 up osd.5 up osd.8 up osd.11 up Etapa 2. Entre ao nó do cálculo OSD e põe 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-11e health HEALTH_WARN noout,norebalance,sortbitwise,require_jewel_osds flag(s) set monmap e1: 3 mons at {pod1-controller-0= :6789/0,pod1-controller- 1= :6789/0,pod1-controller-2= :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, GB / GB avail 704 active+clean client io 463 kb/s rd, kb/s wr, 263 op/s rd, 542 op/s wr Note: Quando CEPH é removido, VNF HD RAID entra no estado degradado mas o hd-disco deve ainda ser acessível Identifique os VM hospedados no nó do OSD-cálculo Identifique os VM que são hospedados no server do cálculo OSD. O server do cálculo contém o controlador dos serviços do elástico (ESC) ou os CP VM [stack@director ~]$ nova list --field name,host grep osd-compute-1 507d67c2-1d b9d1-da879af524f8 VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea pod1-compute-8.localdomain f9c0763a-4a4f-4bbd-af51-bc be2 VNF2-DEPLOYM_c1_0_df4be88d-b4bf a ee229 pod1-compute-8.localdomain ef4b-4d68-b05d VNF2-ESC-ESC- 0 pod1-compute-8.localdomain f5bd7b9c-476a e5-303f0aae9309 VNF2-UAS-uas- 0 pod1-compute-8.localdomain Note: 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.

15 Sem energia gracioso O nó do OSD-cálculo do caso 1. hospeda o ESC A potência do procedimento graciosamente de ESC ou de CP VM é mesma independentemente de se os VM estão hospedados no nó do cálculo ou do OSD-cálculo. Siga etapas do da substituição cartão-matriz no nó do cálculo graciosamente ao sem energia os VM. Substitua o cartão-matriz Etapa 1. As etapas a fim substituir o cartão-matriz em um server UCS C240 M4 podem ser consultadas de: Instalação do servidor de Cisco UCS C240 M4 e guia do serviço Etapa 2. Início de uma sessão ao server com o uso do IP CIMC 3. Execute a elevação BIOS se o firmware não é conforme a versão recomendada usada previamente. As etapas para a elevação BIOS são dadas aqui: Guia da elevação do server BIOS do montagem de rack da série C de Cisco UCS Mova CEPH fora do modo de manutenção Log no nó do cálculo OSD e movimento CEPH 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-11e health HEALTH_OK monmap e1: 3 mons at {pod1-controller-0= :6789/0,pod1-controller- 1= :6789/0,pod1-controller-2= :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, GB / GB avail 704 active+clean client io kb/s wr, 0 op/s rd, 81 op/s wr Restaure os VM Encaixote 1. nós do OSD-cálculo que hospedam ESC ou CP VM

16 O procedimento para restaurar ofcf/esc/em/uas VM é mesmo independentemente de se os VM estão hospedados no nó do cálculo ou do OSD-cálculo. Siga etapas do dos anfitriões CF/ESC/EM/UAS do nó do cálculo caso 2. para restaurar os VM. Substituição do cartão-matriz no nó do controlador Verifique o status de controle e põe o conjunto no modo de manutenção De OSPD, entre ao controlador e verifique que os PCes estão no bom estado todos os três Online e galera dos controladores que mostram todos os três controladores como o mestre. [heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 00:46: Last change: Wed Nov 29 01:20: 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 (ocf::heartbeat:ipaddr2): Started pod1-controller-1 ip (ocf::heartbeat:ipaddr2): Started pod1-controller-2 ip (ocf::heartbeat:ipaddr2): Started pod1-controller-1 ip (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 (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 (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 Põe o conjunto 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

17 Current DC: pod1-controller-2 (version el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 00:48: Last change: Mon Dec 4 00:48: 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 (ocf::heartbeat:ipaddr2): Started pod1-controller-1 ip (ocf::heartbeat:ipaddr2): Started pod1-controller-2 ip (ocf::heartbeat:ipaddr2): Started pod1-controller-1 ip (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 (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 (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 Substitua o cartão-matriz Etapa 1. As etapas a fim substituir o cartão-matriz em um server UCS C240 M4 podem ser consultadas de: Instalação do servidor de Cisco UCS C240 M4 e guia do serviço Etapa 2. Início de uma sessão ao server com o uso do IP CIMC Etapa 3. Execute a elevação BIOS se o firmware não é conforme a versão recomendada usada previamente. As etapas para a elevação BIOS são dadas aqui: Guia da elevação do server BIOS do montagem de rack da série C de Cisco UCS Estado do conjunto da restauração O início de uma sessão ao controlador impactado, remove o modo standby ajustando unstandby. Verifique que o controlador vem Online com conjunto e galera mostra todos os três controladores como o mestre. Isto pode tomar alguns minutos. [heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby [heat-admin@pod1-controller-0 ~]$ sudo pcs status

18 Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 01:08: Last change: Mon Dec 4 01:04: 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 (ocf::heartbeat:ipaddr2): Started pod1-controller-1 ip (ocf::heartbeat:ipaddr2): Started pod1-controller-2 ip (ocf::heartbeat:ipaddr2): Started pod1-controller-1 ip (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 (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 (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/enable