Substituição da placa-mãe no servidor UCS 240M4 Ultra-M - CPAR

Introdução

Este documento descreve as etapas necessárias para substituir uma Placa-mãe defeituosa de um servidor em uma configuração Ultra-M.

Este procedimento se aplica a um ambiente Openstack usando a versão NEWTON onde ESC não está gerenciando CPAR e CPAR está instalado diretamente na VM implantada no Openstack.

Informações de Apoio

A Ultra-M é uma solução de núcleo de pacotes móveis virtualizados, validada e predefinida, 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 objetos - Computação (OSD - Computação)
• Controlador
• Plataforma OpenStack - Diretor (OSPD)

A arquitetura avançada do Ultra-M e os componentes envolvidos são descritos nesta imagem:

Este documento destina-se ao pessoal da Cisco que está familiarizado com a plataforma Cisco Ultra-M e detalha as etapas que devem ser executadas no OpenStack e no Redhat OS.

---

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

Abreviaturas

MOP	Método de Procedimento
OSD	Discos de Armazenamento de Objetos
OSPD	Diretor da plataforma OpenStack
HDD	Unidade de disco rígido
SSD	Unidade de estado sólido
VIM	Gerente de infraestrutura virtual
VM	Máquina virtual
EM	Gerenciador de Elementos
UAS	Ultra Automation Services
UUID	Identificador Exclusivo Universal

Fluxo de trabalho do MoP

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

Em uma configuração Ultra-M, pode haver situações em que uma substituição de placa-mãe é necessária nos seguintes tipos de servidor: Computação, computação OSD e controlador.

---

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

---

Pré-requisitos

Antes de substituir um nó Compute, é importante verificar o estado atual do ambiente da plataforma Red Hat OpenStack. É recomendável verificar o estado atual para evitar complicações quando o processo de substituição de Computação estiver ativado. Isso pode ser obtido por meio desse fluxo de substituição.

Em caso de recuperação, a Cisco recomenda fazer um backup do banco 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

Esse processo garante que um nó possa ser substituído sem afetar a disponibilidade de nenhuma instância. 

Note: Verifique se você tem o instantâneo da instância para que possa restaurar a VM quando necessário. Siga este procedimento para obter um instantâneo da VM.

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

Antes da atividade, as VMs hospedadas no nó Computação são encerradas normalmente. Após a substituição da placa-mãe, as VMs são restauradas.

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

[stack@al03-pod2-ospd ~]$ nova list --field name,host

+--------------------------------------+---------------------------+----------------------------------+

| ID                                   | Name                      | Host                             |

+--------------------------------------+---------------------------+----------------------------------+

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | pod2-stack-compute-3.localdomain |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | pod2-stack-compute-3.localdomain |

+--------------------------------------+---------------------------+----------------------------------+

  

Note: Na saída mostrada aqui, a primeira coluna corresponde ao Universally Unique IDentifier (UUID), a segunda coluna é o nome da VM e a terceira coluna é o nome do host onde a VM está presente. Os parâmetros desta saída são usados nas seções subsequentes.

Backup: Processo de Instantâneo

Etapa 1. Desligamento do aplicativo CPAR.

Etapa 1.Abra qualquer cliente ssh conectado à rede e conecte-se à instância CPAR.

 É importante não desligar todas as 4 instâncias de AAA dentro de um site ao mesmo tempo, fazê-lo de um por um.

Etapa 2.Desligue o aplicativo CPAR com este comando:

/opt/CSCOar/bin/arserver stop

A Message stating “Cisco Prime Access Registrar Server Agent shutdown complete.” Should show up

 Se um usuário deixou uma sessão CLI aberta, o comando arserver stop não funcionará e esta mensagem será exibida:

ERROR:    You can not shut down Cisco Prime Access Registrar while the

          CLI is being used.   Current list of running

          CLI with process id is:

 2903 /opt/CSCOar/bin/aregcmd –s

Neste exemplo, a id de processo 2903 destacada precisa ser encerrada antes que o CPAR possa ser interrompido. Se esse for o caso, encerre esse processo com este comando:

kill -9 *process_id*

Em seguida, repita a etapa 1.

  

Etapa 3.Verifique se o aplicativo CPAR foi realmente desligado, emitindo o comando:

/opt/CSCOar/bin/arstatus

Essas mensagens devem ser exibidas:

  

Cisco Prime Access Registrar Server Agent not running
Cisco Prime Access Registrar GUI not running

Tarefa Instantâneo de VM

Etapa 1.Insira o site da GUI do Horizon que corresponde ao site (cidade) que está sendo trabalhado no momento.

Ao acessar o Horizon, esta tela é observada:

Etapa 2.Navegue até Projeto > Instâncias, como mostrado na imagem.

Se o usuário usado foi CPAR, somente as 4 instâncias AAA aparecerão neste menu.

Etapa 3.Desligue apenas uma instância por vez. Repita todo o processo neste documento.

Para desligar a VM, navegue para Ações > Desligar instância e confirme sua seleção.

Etapa 4.Valide se a instância foi realmente desativada verificando Status = Desligamento e Estado de energia = Desligamento.

Esta etapa encerra o processo de encerramento do CPAR.

Instantâneo de VM

Quando as VMs do CPAR estão inativas, os instantâneos podem ser obtidos em paralelo, pois pertencem a computadores independentes.

Os quatro arquivos QCOW2 serão criados em paralelo.

Tirando um instantâneo de cada instância de AAA (25 minutos -1 hora) (25 minutos para instâncias que usaram uma imagem qcow como origem e 1 hora para instâncias que usam uma imagem raw como origem)

Etapa 1. Faça login no OpenStack’s Horizon do PODGUI.
    

Etapa 2. Depois de fazer login, vá para a seção Project > Compute > Instances no menu superior e procure as instâncias AAA.

Etapa 3. Clique no botão Create Snapshot para continuar com a criação do snapshot (isso precisa ser executado na instância AAA correspondente).

Etapa 4. Depois que o snapshot for executado, navegue até o menu IMAGENS e verifique se todos terminaram e não relataram problemas.

Etapa 5. A próxima etapa é fazer o download do snapshot em um formato QCOW2 e transferi-lo para uma entidade remota, caso o OSPD seja perdido durante esse processo. Para conseguir isso, identifique o instantâneo com este comando glance image-list no nível do OSPD.

[root@elospd01 stack]# glance image-list

+--------------------------------------+---------------------------+

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

+--------------------------------------+---------------------------+

Etapa 6. Uma vez identificado o snapshot a ser baixado (nesse caso, será o marcado acima em verde), faça o download em um formato QCOW2 usando o comando glance image-download, como mostrado aqui.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

• O "&" envia o processo para o segundo plano. Essa ação levará algum tempo para ser concluída. Depois disso, a imagem poderá ser localizada no diretório /tmp.
• Ao enviar o processo para o segundo plano, se a conectividade for perdida, o processo também será interrompido. 
• Execute o comando "dissown -h" para que, no caso da conexão SSH ser perdida, o processo ainda seja executado e termine no OSPD.

Etapa 7. Quando o processo de download for concluído, um processo de compactação precisará ser executado, pois o instantâneo poderá ser preenchido com ZEROS devido a processos, tarefas e arquivos temporários tratados pelo Sistema Operacional. O comando a ser usado para compactação de arquivo é virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Esse processo leva algum tempo (cerca de 10 a 15 minutos). Uma vez concluído, o arquivo resultante é aquele que precisa ser transferido para uma entidade externa, conforme especificado na próxima etapa.

A verificação da integridade do arquivo é necessária; para conseguir isso, execute o próximo comando e procure o atributo "corrupt" (corrompido) no final de sua saída.

[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2
image: AAA-CPAR-LGNoct192017_compressed.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 18G
cluster_size: 65536
Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

 Para evitar um problema em que o OSPD seja perdido, o instantâneo criado recentemente no formato QCOW2 precisa ser transferido para uma entidade externa. Antes de iniciar a transferência de arquivos, temos que verificar se o destino tem espaço em disco disponível suficiente, use o comando "df -kh" para verificar o espaço de memória. Nosso conselho é transferi-lo temporariamente para o OSPD de outro local usando o SFTP "sftproot@x.x.x.x", onde x.x.x.x é o IP de um OSPD remoto. Para acelerar a transferência, o destino pode ser enviado a vários OSPDs. Da mesma forma, podemos usar o seguinte comando scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (onde x.x.x.x é o IP de um OSPD remoto) para transferir o arquivo para outro OSPD.

Desligamento da energia - normal

Desligar nó

1. Para desligar a instância: nova stop <INSTANCE_NAME>
2. Agora você verá o nome da instância com o status shutoff.

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

Substitua a placa-mãe

As etapas para substituir a placa-mãe em um servidor UCS C240 M4 podem ser consultadas no Guia de Instalação e Serviço do Servidor Cisco UCS C240 M4

1. Faça login no servidor usando o IP do CIMC.
   
   
2. Execute o upgrade do BIOS se o firmware não estiver de acordo com a versão recomendada usada anteriormente. As etapas para a atualização do BIOS são fornecidas aqui: Guia de atualização do BIOS do servidor com montagem em rack Cisco UCS C-Series

Restaure as VMs

Recuperar uma instância por meio de snapshot

Processo de recuperação

É possível reimplantar a instância anterior com o instantâneo obtido nas etapas anteriores.

Etapa 1 [OPCIONAL].Se não houver um VMsnapshot anterior disponível, conecte-se ao nó OSPD para o qual o backup foi enviado e execute sftp para o backup de volta ao nó OSPD original. Usando "sftproot@x.x.x.x" onde x.x.x.x é o IP do OSPD original. Salve o arquivo de instantâneo no diretório /tmp.

Etapa 2.Conecte-se ao nó OSPD em que a instância é reimplantada.

Crie as variáveis de ambiente com este comando:

              

# source /home/stack/pod1-stackrc-Core-CPAR

Etapa 3.É necessário usar o instantâneo como uma imagem para carregá-lo no horizonte como tal. Use o próximo comando para fazer isso.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

O processo pode ser visto no horizonte.

Etapa 4.No Horizon, navegue para Projeto > Instâncias e clique em Iniciar Instância.

Etapa 5.Preencha o nome da instância e escolha a zona de disponibilidade.

Etapa 6.Na guia Origem, escolha a imagem para criar a ocorrência. No menu Select Boot Source (Selecionar origem de inicialização) selecione image, uma lista de imagens é mostrada aqui, escolha a que foi carregada anteriormente ao clicar no sinal +.

Passo 7.Na guia Sabor, escolha o tipo AAA ao clicar no sinal +.

  

Etapa 8.Finalmente, navegue até a guia network e escolha as redes de que a instância precisa ao clicar no sinal +. Para esse caso, selecione diâmetro-roteável1, raio-roteável1 e tb1-mgmt.

  

Etapa 9. Finalmente, clique em Iniciar instância para criá-la. O progresso pode ser monitorizado no Horizonte:

Após alguns minutos, a instância é completamente implantada e pronta para uso.

Criar e atribuir um endereço IP flutuante

Um endereço IP flutuante é um endereço roteável, o que significa que ele pode ser acessado de fora da arquitetura Ultra M/Openstack e pode se comunicar com outros nós da rede.

Etapa 1.No menu superior Horizon, navegue até Admin > IPs flutuantes.

Etapa 2. Clique no botãoAllocateIP to Project.

Etapa 3. Na janela Allocate Floating IPselecione oPool ao qual o novo IP flutuante pertence, oProjeto ao qual ele será atribuído e o newFloating IP Addressitself.

Por exemplo:

                                                                

Etapa 4.Clique no botão AllocateFloating IP.

Etapa 5. No menu superior Horizon, navegue atéProjeto > Instâncias.

Etapa 6.Na colunaAção, clique na seta que aponta para baixo no botão Criar Instantâneo, um menu deve ser exibido. Selecione a opção Associar IPs Flutuantes.

Etapa 7. Selecione o endereço IP flutuante correspondente a ser usado no campo IP Addressfield e escolha a interface de gerenciamento correspondente (eth0) na nova instância em que esse IP flutuante será atribuído na Porta a ser associada. Consulte a próxima imagem como exemplo desse procedimento.

Etapa 8.Finalmente, clique no botão Associar.

Habilitando o SSH

Etapa 1.No menu superior Horizon, navegue atéProjeto > Instâncias.

Etapa 2.Clique no nome da instância/VM que foi criada na seção Iniciar uma nova instância.

Etapa 3. Clique emConsoletab. Isso exibirá a interface de linha de comando da VM.

Etapa 4.Quando a CLI for exibida, insira as credenciais de login apropriadas:

           Nome de usuário:raiz

           Senha:cisco123

Etapa 5.Na CLI, insira o comando vi /etc/ssh/sshd_config para editar a configuração do ssh.

Etapa 6. Quando o arquivo de configuração ssh estiver aberto, pressione Ipara editar o arquivo. Em seguida, procure a seção mostrada abaixo e altere a primeira linha dePasswordAuthentication paraPasswordAuthentication yes.

Passo 7.Pressione ESCe insira:wq!para salvar as alterações do arquivo sshd_config.

Etapa 8. Execute o commandservice sshd restart.

                                  

Etapa 9.Para testar se as alterações na configuração do SSH foram corretamente aplicadas, abra qualquer cliente SSH e tente estabelecer uma conexão segura remota usando o IP flutuante atribuído à instância (por exemplo, 10.145.0.249) e a raiz do usuário.

Estabelecer uma sessão SSH

Abra uma sessão SSH usando o endereço IP da VM/servidor correspondente onde o aplicativo está instalado.

Início da instância de CPAR

Siga as etapas abaixo, depois que a atividade for concluída e os serviços CPAR puderem ser restabelecidos no site que foi encerrado.

1. Para fazer login novamente no Horizon, navegue para Project > Instance > Start Instance.
   
   
2. Verifique se o status da instância está ativo e se o estado de energia está em execução:

Verificação de Integridade Pós-atividade

Etapa 1.Execute o comando /opt/CSCOar/bin/arstatus no nível do SO.

[root@aaa04 ~]# /opt/CSCOar/bin/arstatus
Cisco Prime AR RADIUS server running       (pid: 24834)
Cisco Prime AR Server Agent running        (pid: 24821)
Cisco Prime AR MCD lock manager running    (pid: 24824)
Cisco Prime AR MCD server running          (pid: 24833)
Cisco Prime AR GUI running                 (pid: 24836)
SNMP Master Agent running                (pid: 24835)
[root@wscaaa04 ~]#

Etapa 2.Execute o comando /opt/CSCOar/bin/aregcmd no nível do SO e insira as credenciais de administrador. Verifique se CPAR Health é 10 de 10 e saia do CPAR CLI.

[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc.  All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]

    LicenseInfo = PAR-NG-TPS 7.2(100TPS:)

                  PAR-ADD-TPS 7.2(2000TPS:)

                  PAR-RDDR-TRX 7.2()

                  PAR-HSS 7.2()

    Radius/

    Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit

Etapa 3.Execute o comando netstat | diâmetro grep e verificar se todas as conexões DRA estão estabelecidas.

A saída mencionada abaixo é para um ambiente onde links de diâmetro são esperados. Se menos links forem exibidos, isso representa uma desconexão do DRA que precisa ser analisada.

[root@aa02 logs]# netstat | grep diameter
tcp         0            0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED

Etapa 4.Verifique se o registro TPS mostra solicitações sendo processadas pelo CPAR. Os valores destacados representam o TPS e são aqueles aos quais precisamos prestar atenção.

O valor de TPS não deve exceder 1500.

[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv
11-21-2017,23:57:35,263,0
11-21-2017,23:57:50,237,0
11-21-2017,23:58:05,237,0
11-21-2017,23:58:20,257,0
11-21-2017,23:58:35,254,0
11-21-2017,23:58:50,248,0
11-21-2017,23:59:05,272,0
11-21-2017,23:59:20,243,0
11-21-2017,23:59:35,244,0
11-21-2017,23:59:50,233,0

 

Etapa 5.Procure qualquer mensagem de "erro" ou "alarme" em name_radius_1_log

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log

Etapa 6.Verifique a quantidade de memória que o processo CPAR está usando emitindo o seguinte comando:

superior | raio do grep

[root@sfraaa02 ~]# top | grep radius
27008 root      20   0 20.228g 2.413g  11408 S 128.3  7.7   1165:41 radius

Este valor realçado deve ser inferior a: 7 Gb, que é o máximo permitido em um nível de aplicativo.

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

Antes da atividade, as VMs hospedadas no nó Computação são encerradas normalmente e o CEPH é colocado no modo de manutenção. Depois que a placa-mãe for substituída, as VMs serão restauradas e o CEPH sairá do modo de manutenção.

Identificar as VMs hospedadas no nó Osd-Compute

Identifique as VMs que estão hospedadas no servidor de computação OSD.

[stack@director ~]$ nova list --field name,host | grep osd-compute-0
| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

Backup: Processo de Instantâneo

Desligamento do aplicativo CPAR

Etapa 1.Abra qualquer cliente ssh conectado à rede e conecte-se à instância CPAR.

 É importante não desligar todas as 4 instâncias de AAA dentro de um site ao mesmo tempo, fazê-lo de um por um.

Etapa 2.Desligue o aplicativo CPAR com este comando:

/opt/CSCOar/bin/arserver stop

A Message stating “Cisco Prime Access Registrar Server Agent shutdown complete.” Should show up

Note: Se um usuário deixou uma sessão CLI aberta, o comando arserver stop não funcionará e a seguinte mensagem será exibida:

ERROR:    You can not shut down Cisco Prime Access Registrar while the

          CLI is being used.   Current list of running

          CLI with process id is:

 2903 /opt/CSCOar/bin/aregcmd –s

Neste exemplo, a id de processo 2903 destacada precisa ser encerrada antes que o CPAR possa ser interrompido. Se esse for o caso, encerre esse processo com este comando:

kill -9 *process_id*

Em seguida, repita a etapa 1.

  

Etapa 3.Verifique se o aplicativo CPAR foi realmente desligado com este comando:

/opt/CSCOar/bin/arstatus

Essas mensagens são exibidas:

  

Cisco Prime Access Registrar Server Agent not running
Cisco Prime Access Registrar GUI not running

Tarefa Instantâneo de VM

Etapa 1.Insira o site da GUI do Horizon que corresponde ao site (cidade) que está sendo trabalhado no momento.

Ao acessar o Horizon, a imagem mostrada é observada:

Etapa 2. Navegue até Projeto > Instâncias, conforme mostrado na imagem.

Se o usuário usado foi CPAR, somente as 4 instâncias AAA aparecerão neste menu.

Etapa 3.Desligue apenas uma instância por vez. Repita todo o processo neste documento.

Para desligar a VM, navegue para Ações > Desligar instância e confirme sua seleção.

Etapa 4.Valide se a instância foi realmente desativada verificando Status = Desligamento e Estado de energia = Desligamento.

Esta etapa encerra o processo de encerramento do CPAR.

Instantâneo de VM

Quando as VMs do CPAR estão inativas, os instantâneos podem ser obtidos em paralelo, pois pertencem a computadores independentes.

Os quatro arquivos QCOW2 são criados em paralelo.

Tirar um instantâneo de cada instância de AAA (25 minutos - 1 hora) (25 minutos para instâncias que usaram uma imagem qcow como origem e 1 hora para instâncias que usam uma imagem raw como origem)

Etapa 1. Faça login na GUI do Horizon do POD.

Etapa 2. Depois de fazer login, vá para a seção Project > Compute > Instances no menu superior e procure as instâncias AAA.

Etapa 3. Clique no botão Create Snapshot para continuar com a criação do snapshot (isso precisa ser executado na instância AAA correspondente).

Etapa 4. Depois que o snapshot for executado, navegue até o menu IMAGENS e verifique se todos terminaram e não relataram problemas.

Etapa 5. A próxima etapa é fazer o download do snapshot em um formato QCOW2 e transferi-lo para uma entidade remota, caso o OSPD seja perdido durante esse processo. Para conseguir isso, identifique o instantâneo com este comando glance image-list no nível do OSPD.

[root@elospd01 stack]# glance image-list

+--------------------------------------+---------------------------+

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

+--------------------------------------+---------------------------+

Etapa 6. Uma vez identificado que o snapshot deve ser baixado (neste caso, será o marcado acima em verde), baixe-o agora em um formato QCOW2 com este comando glance image-download como mostrado aqui.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

• O "&" envia o processo para o segundo plano. Essa ação levará algum tempo para ser concluída. Depois disso, a imagem poderá ser localizada no diretório /tmp.
• Ao enviar o processo para o segundo plano, se a conectividade for perdida, o processo também será interrompido. 
• Execute o comando "dissown -h" para que, no caso da conexão SSH ser perdida, o processo ainda seja executado e termine no OSPD.

7. Quando o processo de download for concluído, um processo de compactação precisará ser executado, pois esse instantâneo poderá ser preenchido com ZEROS devido a processos, tarefas e arquivos temporários tratados pelo Sistema Operacional. O comando a ser usado para compactação de arquivo é virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Esse processo leva algum tempo (cerca de 10 a 15 minutos). Uma vez concluído, o arquivo resultante é aquele que precisa ser transferido para uma entidade externa, conforme especificado na próxima etapa.

A verificação da integridade do arquivo é necessária. Para conseguir isso, execute o próximo comando e procure o atributo "corrupt" (corrompido) no final de sua saída.

[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2
image: AAA-CPAR-LGNoct192017_compressed.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 18G
cluster_size: 65536
Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

 Para evitar um problema em que o OSPD seja perdido, o instantâneo criado recentemente no formato QCOW2 precisa ser transferido para uma entidade externa. Antes de iniciar a transferência de arquivos, temos que verificar se o destino tem espaço em disco disponível suficiente, use o comando "df -kh" para verificar o espaço de memória. Nosso conselho é transferi-lo temporariamente para o OSPD de outro local usando o SFTP "sftproot@x.x.x.x", onde x.x.x.x é o IP de um OSPD remoto. Para acelerar a transferência, o destino pode ser enviado a vários OSPDs. Da mesma forma, podemos usar o seguinte comando scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (onde x.x.x.x é o IP de um OSPD remoto) para transferir o arquivo para outro OSPD.

Colocar o CEPH no Modo de Manutenção

Etapa 1. Verificar se o status da árvore de ceph está ativo no servidor

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-1 13.07996 root default 
-2 4.35999 host pod2-stack-osd-compute-0 
 0 1.09000 osd.0 up 1.00000 1.00000 
 3 1.09000 osd.3 up 1.00000 1.00000 
 6 1.09000 osd.6 up 1.00000 1.00000 
 9 1.09000 osd.9 up 1.00000 1.00000 
-3 4.35999 host pod2-stack-osd-compute-1 
 1 1.09000 osd.1 up 1.00000 1.00000 
 4 1.09000 osd.4 up 1.00000 1.00000 
 7 1.09000 osd.7 up 1.00000 1.00000 
10 1.09000 osd.10 up 1.00000 1.00000 
-4 4.35999 host pod2-stack-osd-compute-2 
 2 1.09000 osd.2 up 1.00000 1.00000 
 5 1.09000 osd.5 up 1.00000 1.00000 
 8 1.09000 osd.8 up 1.00000 1.00000 
11 1.09000 osd.11 up 1.00000 1.00000 

Etapa 2. Efetue login no nó OSD Compute e coloque o CEPH no modo de manutenção.

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set norebalance
[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set noout

[root@pod2-stack-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 {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}
 election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2
 osdmap e79: 12 osds: 12 up, 12 in
 flags noout,norebalance,sortbitwise,require_jewel_osds
 pgmap v22844323: 704 pgs, 6 pools, 804 GB data, 423 kobjects
 2404 GB used, 10989 GB / 13393 GB avail
 704 active+clean
 client io 3858 kB/s wr, 0 op/s rd, 546 op/s wr

Note: Quando o CEPH é removido, o VNF HD RAID entra no estado Degradado, mas o disco rígido ainda deve estar acessível

Desligamento da energia - normal

Desligar nó

1. Para desligar a instância: nova stop <INSTANCE_NAME>
   
   
2. Você verá o nome da instância com o status shutoff.

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

Substitua a placa-mãe

As etapas para substituir a placa-mãe em um servidor UCS C240 M4 podem ser consultadas no Guia de Instalação e Serviço do Servidor Cisco UCS C240 M4

1. Faça login no servidor usando o IP do CIMC.
   
   
2. Execute o upgrade do BIOS se o firmware não estiver de acordo com a versão recomendada usada anteriormente. As etapas para a atualização do BIOS são fornecidas aqui: Guia de atualização do BIOS do servidor com montagem em rack Cisco UCS C-Series

Mover o CEPH para fora do Modo de Manutenção

 Faça login no nó OSD Compute e retire o CEPH do modo de manutenção.

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset norebalance
[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset noout

[root@pod2-stack-osd-compute-0 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}
 election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2
 osdmap e81: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v22844355: 704 pgs, 6 pools, 804 GB data, 423 kobjects
 2404 GB used, 10989 GB / 13393 GB avail
 704 active+clean
 client io 3658 kB/s wr, 0 op/s rd, 502 op/s wr

Restaure as VMs

Recuperar uma instância por meio de snapshot

Processo de recuperação:

É possível reimplantar a instância anterior com o instantâneo obtido nas etapas anteriores.

Etapa 1 [OPCIONAL].Se não houver um VMsnapshot anterior disponível, conecte-se ao nó OSPD para o qual o backup foi enviado e execute sftp para o backup de volta ao nó OSPD original. Usando "sftproot@x.x.x.x" onde x.x.x.x é o IP do OSPD original. Salve o arquivo de instantâneo no diretório /tmp.

Etapa 2.Conecte-se ao nó OSPD em que a instância é reimplantada.

Crie as variáveis de ambiente com este comando:

             

# source /home/stack/pod1-stackrc-Core-CPAR

Etapa 3.É necessário usar o instantâneo como uma imagem para carregá-lo no horizonte como tal. Use o próximo comando para fazer isso.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot 

O processo pode ser visto no horizonte.

Etapa 4.No Horizon, navegue para Projeto > Instâncias e clique em Iniciar Instância.

 Etapa 5.Preencha o nome da instância e escolha a zona de disponibilidade.

Etapa 6.Na guia Origem, escolha a imagem para criar a ocorrência. No menu Select Boot Source (Selecionar origem de inicialização) selecione image, uma lista de imagens é mostrada aqui, escolha a que foi carregada anteriormente ao clicar no sinal +.

Passo 7.Na guia Sabor, escolha o tipo AAA ao clicar no sinal +.

  

Etapa 8.Finalmente, navegue até a guia network e escolha as redes de que a instância precisa ao clicar no sinal +. Para esse caso, selecione diâmetro-roteável1, raio-roteável1 e tb1-mgmt.

  

Etapa 9. Finalmente, clique em Iniciar instância para criá-la. O progresso pode ser monitorizado no Horizonte:

Após alguns minutos, a instância é completamente implantada e pronta para uso.

Criar e atribuir um endereço IP flutuante

Um endereço IP flutuante é um endereço roteável, o que significa que ele pode ser acessado de fora da arquitetura Ultra M/Openstack e pode se comunicar com outros nós da rede.

Etapa 1.No menu superior Horizon, navegue até Admin > IPs flutuantes.

Etapa 2.Clique no botãoAllocateIP to Project.

Etapa 3. Na janela Allocate Floating IPselecione oPool ao qual o novo IP flutuante pertence, oProjeto ao qual ele será atribuído e o newFloating IP Addressitself.

Por exemplo:

Etapa 4.Clique no botão AllocateFloating IP.

Etapa 5. No menu superior Horizon, navegue atéProjeto > Instâncias.

Etapa 6. Na colunaAção, clique na seta que aponta para baixo no botão Criar Instantâneo, um menu deve ser exibido. Selecione a opção Associar IPs Flutuantes.

Etapa 7. Selecione o endereço IP flutuante correspondente a ser usado no campo IP Addressfield e escolha a interface de gerenciamento correspondente (eth0) na nova instância em que esse IP flutuante será atribuído na Porta a ser associada. Consulte a próxima imagem como exemplo desse procedimento.

                                  

Etapa 8.Finalmente, clique no botão Associar.

Habilitando o SSH

Etapa 1.No menu superior Horizon, navegue atéProjeto > Instâncias.

Etapa 2.Clique no nome da instância/VM que foi criada na seção Iniciar uma nova instância.

Etapa 3.Clique emConsoletab. Isso exibe a CLI da VM.

Etapa 4. Quando a CLI for exibida, digite as credenciais de login adequadas:

           Nome de usuário:raiz

           Senha:cisco123

                                          

Etapa 5.Na CLI, insira o comando vi /etc/ssh/sshd_config para editar a configuração do ssh.

Etapa 6. Quando o arquivo de configuração ssh estiver aberto, pressione Ipara editar o arquivo. Em seguida, procure a seção mostrada aqui e altere a primeira linha dePasswordAuthentication paraPasswordAuthentication yes.

Passo 7.Pressione ESCe insira:wq!para salvar as alterações do arquivo sshd_config.

Etapa 8. Execute o commandservice sshd restart.

                                      

Etapa 9.Para testar se as alterações na configuração do SSH foram corretamente aplicadas, abra qualquer cliente SSH e tente estabelecer uma conexão segura remota usando o IP flutuante atribuído à instância (por exemplo, 10.145.0.249) e a raiz do usuário.

Estabelecer uma sessão SSH

Abra uma sessão SSH usando o endereço IP da VM/servidor correspondente onde o aplicativo está instalado.

Início da instância de CPAR

Siga estas etapas depois que a atividade for concluída e os serviços CPAR puderem ser restabelecidos no site que foi encerrado.

1. Faça login de volta no Horizon, navegue até Projeto > Instância > Iniciar instância.
   
   
2. Verifique se o status da instância está ativo e se o estado de energia está em execução:

Verificação de Integridade Pós-atividade

Etapa 1. Execute o comando /opt/CSCOar/bin/arstatus no nível do SO.

[root@aaa04 ~]# /opt/CSCOar/bin/arstatus
Cisco Prime AR RADIUS server running       (pid: 24834)
Cisco Prime AR Server Agent running        (pid: 24821)
Cisco Prime AR MCD lock manager running    (pid: 24824)
Cisco Prime AR MCD server running          (pid: 24833)
Cisco Prime AR GUI running                 (pid: 24836)
SNMP Master Agent running                (pid: 24835)
[root@wscaaa04 ~]#

Etapa 2. Execute o comando /opt/CSCOar/bin/aregcmd no nível do SO e insira as credenciais de administrador. Verifique se CPAR Health é 10 de 10 e saia do CPAR CLI.

[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc.  All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]

    LicenseInfo = PAR-NG-TPS 7.2(100TPS:)

                  PAR-ADD-TPS 7.2(2000TPS:)

                  PAR-RDDR-TRX 7.2()

                  PAR-HSS 7.2()

    Radius/

    Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit

Etapa 3.Execute o comando netstat | diâmetro grep e verificar se todas as conexões DRA estão estabelecidas.

A saída mencionada aqui é para um ambiente onde os links de diâmetro são esperados. Se menos links forem exibidos, isso representa uma desconexão do DRA que precisa ser analisada.

[root@aa02 logs]# netstat | grep diameter
tcp         0            0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED

Etapa 4.Verifique se o registro TPS mostra solicitações sendo processadas pelo CPAR. Os valores destacados representam o TPS e são aqueles aos quais precisamos prestar atenção.

O valor de TPS não deve exceder 1500.

[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv
11-21-2017,23:57:35,263,0
11-21-2017,23:57:50,237,0
11-21-2017,23:58:05,237,0
11-21-2017,23:58:20,257,0
11-21-2017,23:58:35,254,0
11-21-2017,23:58:50,248,0
11-21-2017,23:59:05,272,0
11-21-2017,23:59:20,243,0
11-21-2017,23:59:35,244,0
11-21-2017,23:59:50,233,0

 

Etapa 5.Procure qualquer mensagem de "erro" ou "alarme" em name_radius_1_log

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log

Etapa 6.Verifique a quantidade de memória que o processo CPAR usa com este comando:

superior | raio do grep

[root@sfraaa02 ~]# top | grep radius
27008 root      20   0 20.228g 2.413g  11408 S 128.3  7.7   1165:41 radius

Este valor realçado deve ser inferior a: 7 Gb, que é o máximo permitido em um nível de aplicativo.

Substituição da placa-mãe no nó do controlador

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

A partir do OSPD, faça login no controlador e verifique se os pcs estão em bom estado - todos os três controladores on-line e a galera mostrando todos os três controladores como Master. 

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Fri Jul 6 09:02:52 2018Last change: Mon Jul 2 12:49:52 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

 ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Master/Slave Set: redis-master [redis]
 Masters: [ pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]
 ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Coloque o cluster no modo de manutenção

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

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Fri Jul 6 09:03:10 2018Last change: Fri Jul 6 09:03:06 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Node pod2-stack-controller-0: standby
Online: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

 ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]
 Stopped: [ pod2-stack-controller-0 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Master/Slave Set: redis-master [redis]
 Masters: [ pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-1 ]
 Stopped: [ pod2-stack-controller-0 ]
 ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Substitua a placa-mãe

O procedimento para substituir a placa-mãe em um servidor UCS C240 M4 pode ser consultado no Guia de Instalação e Serviço do Servidor Cisco UCS C240 M4

1. Faça login no servidor usando o IP do CIMC.
   
   
2. Execute o upgrade do BIOS se o firmware não estiver de acordo com a versão recomendada usada anteriormente. As etapas para o upgrade do BIOS são fornecidas aqui:

      Guia de atualização do BIOS do servidor com montagem em rack Cisco UCS C-Series

Restaurar Status do Cluster

Faça login na controladora afetada e remova o modo de espera definindo unstandby.  Verifique se o controlador está on-line com o cluster e se a galera mostra todos os três controladores como Master.  Isso pode levar alguns minutos.

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

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Fri Jul 6 09:03:37 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

 ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod2-stack-controller-1 pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-0 ]
 ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]
 Stopped: [ pod2-stack-controller-0 ]
 ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Master/Slave Set: redis-master [redis]
 Masters: [ pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]
 ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled