Componentes modulares RMA-PCRF
Opções de download
Linguagem imparcial
O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
Sobre esta tradução
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Contents
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
- 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 - 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.
- 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 - Localize todos os scripts de pós-implantação usados para enviar API de orquestração CPS.
- 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
- 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 |
- 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 - 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].
- Verifique todos os serviços nas VMs sendo iniciadas.
Recuperação de VM ESC
- Faça login no ESC via console e verifique o status.
- 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.
- Coloque o cluster de pcs no controlador sendo atualizado em standby.
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
- 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
- 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.
- 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 |
- 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
- 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
Colaborado por engenheiros da Cisco
- Nitesh BansalCisco Advance Services
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)