Substituição de componentes com falha no servidor UCS C240 M4 - CPAR

Opções de download

  • PDF     (3.5 MB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (3.3 MB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (2.7 MB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:6 de setembro de 2018
ID do documento:213663

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.

    Introduction

    Este documento descreve as etapas necessárias para substituir os componentes defeituosos mencionados aqui em um servidor do Unified Computing System (UCS) em uma configuração Ultra-M.

    Este procedimento aplica-se a um ambiente Openstack com o uso da versão NEWTON onde ESC não gerencia CPAR e CPAR é instalado diretamente na VM implantada no Openstack.

    • 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 

    Informações de Apoio

    O Ultra-M é uma solução de núcleo de pacotes móveis virtualizados 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 arquitetura de alto nível da Ultra-M e os componentes envolvidos estão descritos nesta imagem:

    Este documento destina-se aos funcionários da Cisco que estão familiarizados com a plataforma Cisco Ultra-M e detalha as etapas necessárias para serem executadas no OpenStack e no sistema operacional Redhat.

    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 Objeto
    OSPD OpenStack Platform Diretor
    HDD   Unidade de disco rígido
    SSD   Unidade de estado sólido
    VIM   Virtual Infrastructure Manager
    VM    Máquina virtual
    EM    Gestor de Elementos
    UAS   Ultra Automation Services
    UUID Identificador universal exclusivo

    Fluxo de trabalho do MoP


    Prerequisites

    Backup

    Antes de substituir um componente defeituoso, é importante verificar o estado atual do ambiente da plataforma Red Hat OpenStack. Recomenda-se que você verifique o estado atual para evitar complicações quando o processo de substituição estiver ativado. Isso pode ser feito 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 quaisquer instâncias. Além disso, é recomendável fazer o backup da configuração do StarOS, especialmente se o nó de computação/OSD a ser substituído hospeda a máquina virtual (VM) Control Function (CF).

    Note: Se o Servidor for o nó Controlador, vá para a seção "", caso contrário, continue com a próxima seção. Certifique-se de ter o instantâneo da instância para que você possa restaurar a VM quando necessário. Siga o procedimento sobre como fazer um snapshot da VM.

    RMA do componente - Nó de computação

    Identificar VMs hospedadas no nó de computação

    Identifique as VMs hospedadas no servidor.

    [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 UUID, a segunda coluna é o nome da VM e a terceira coluna é o nome do host onde a VM está presente. Os parâmetros dessa saída serão usados em seções subsequentes.

    Backup: PROCESSO DE INSTANTÂNEO

    1. Desligamento do aplicativo CPAR

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

    É importante não desligar todas as 4 instâncias de AAA em um site ao mesmo tempo, fazer isso de uma forma por uma.

    Etapa 2. Para desligar o aplicativo CPAR, execute o comando:

    /opt/CSCOar/bin/arserver stop

    Uma mensagem "Cisco Prime Access Registrar Server Agent desligado concluído". deve aparecer.

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

    ERROR:    You cannot 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 para que o CPAR possa ser interrompido. Se for esse o caso, encerre esse processo executando o comando:

    kill -9 *process_id*

     Em seguida, repita a etapa 1.

    Etapa 3. Para verificar se o aplicativo CPAR foi realmente desligado, execute o comando:

    /opt/CSCOar/bin/arstatus

    Essas mensagens devem aparecer:

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

    2. Tarefa de Instantâneo da VM

    Etapa 1. Digite o site da GUI do Horizon que corresponde ao Site (Cidade) em que está sendo trabalhado.

    Quando você acessa o Horizon, essa tela é observada.

    Etapa 2. Navegue até Project > Instances como mostrado nesta imagem.

    Se o usuário usado foi cpar, somente as 4 instâncias AAA aparecem neste menu.

    Etapa 3. Desligar apenas uma instância por vez, repita todo o processo neste documento. Para desligar a VM, navegue para Ações > Desligar instância como mostrado nesta imagem e confirme sua seleção.

    Etapa 4. Confirme se a instância foi realmente desligada verificando o Status = Desligamento e Estado de energia = Desligar como mostrado nesta imagem.

    Esta etapa encerra o processo de encerramento do CPAR.

    Instantâneo de VM

    Quando as VMs CPAR estiverem desativadas, os snapshots 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 AAA (25 minutos - 1 hora) (25 minutos para instâncias que usaram uma imagem qcou como origem e 1 hora para instâncias que usam uma imagem bruta como origem)

    1. Faça login na GUI do Horizon do Openstack do POD.
    2. Depois de fazer login, navegue até a seção PROJECT > COMPUTE > INSTÂNCIAS no menu superior e procure as instâncias de AAA como mostrado nesta imagem.

    3. Clique em Criar instantâneo para continuar com a criação do instantâneo (isso precisa ser executado na instância AAA correspondente) como mostrado nesta imagem.

    4. Depois que o snapshot for executado, navegue até o menu Imagens e verifique se todos terminam e relatam problemas, como mostrado nesta imagem.

    5. A próxima etapa é baixar o 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 snapshot executando o comando glance image-list no nível 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 |

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

    6. Depois de identificar o snapshot a ser baixado (o marcado em verde), você pode baixá-lo em um formato QCOW2 com 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 plano de fundo. Pode levar algum tempo para concluir esta ação, uma vez concluída, a imagem pode ser localizada no diretório /tmp.
    • Ao enviar o processo ao segundo plano , se a conectividade for perdida, o processo também será interrompido. 
    • Execute o comando disown -h para que, caso a conexão SSH seja perdida, o processo ainda seja executado e concluído no OSPD.

    7. Quando o processo de download terminar, um processo de compactação precisa ser executado, pois esse snapshot pode ser preenchido com ZEROES devido a processos, tarefas e arquivos temporários tratados pelo sistema operacional (SO). O comando a ser usado para compactação de arquivos é virt-sparsify.

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

    Esse processo pode levar 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 que isso ocorra, 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 é perdido, o snapshot recém-criado no formato QCOW2 precisa ser transferido para uma entidade externa. Antes de iniciar a transferência de arquivos, você deve 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. Um conselho é transferi-lo temporariamente para o OSPD de outro site com o uso do 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, você pode executar o comando scp *name_of_the_file*.qcou2 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 normal

    • Desligar nó
    1. Para desligar a instância: nova stop <INSTANCE_NAME>
    2. Você pode 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                 |

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

    Substituir componente defeituoso do nó de 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

    Restaurar VMs

    Recuperar instância com instantâneo

    Processo de recuperação

    É possível reimplantar a instância anterior com o snapshot realizado nas etapas anteriores.

    Etapa 1. [opcional] Se não houver nenhum VMsnapshot anterior disponível, conecte-se ao nó OSPD onde o backup foi enviado e faça o SFTP de volta ao nó OSPD original. Com sftproot@x.x.x.x onde x.x.x.x é o IP de um OSPD original. Salve o arquivo de snapshot no diretório /tmp.

    Etapa 2. Conecte-se ao nó OSPD onde a instância pode ser reimplantada, como mostrado na imagem.

    Origem das variáveis de ambiente com este comando:

                 

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

    Etapa 3. Para usar o snapshot como uma imagem, é necessário carregá-lo no horizonte como tal. Execute 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 e como mostrado nesta imagem.

    Etapa 4. No Horizon, navegue para Project > Instances e clique em Iniciar instância como mostrado nesta imagem.

    Etapa 5. Digite o Nome da instância e escolha a Zona de disponibilidade conforme mostrado nesta imagem.

    Etapa 6. Na guia Origem, escolha a imagem para criar a instância. No menu Select Boot Source (Selecionar fonte de inicialização) selecione image, uma lista de imagens é exibida. Escolha a imagem que foi carregada anteriormente clicando no + sinal e como mostrado na imagem.

    Passo 7. Na guia Flavor, escolha o sabor AAA clicando no + sinal, como mostrado nesta imagem.

      

    Etapa 8. Finalmente, navegue até a guia Rede e escolha as redes que a instância precisará clicando no sinal +. Nesse caso, selecione diâmetro-soutable1, radius-routable1 e tb1-mgmt como mostrado nesta imagem.

      

    Finalmente, clique em Iniciar instância para criá-la. O progresso pode ser monitorado no Horizon:

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

    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 alcançado de fora da arquitetura Ultra M/Openstack e pode se comunicar com outros nós da rede.

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

    Etapa 2. Clique em Alocar IP para Projeto.

    Etapa 3. Na janela Alocar IP Flutuante, selecione o Pool do qual o novo IP flutuante pertence, o Projeto ao qual ele será atribuído e o novo Endereço IP Flutuante em si.

    Por exemplo:

                                                                     

    Etapa 4. Clique no botão Alocar IP flutuante.

    Etapa 5. No menu superior do Horizon, navegue até Project > Instances.

    Etapa 6. Na coluna Ação, clique na seta que aponta para baixo no botão Criar instantâneo, um menu é exibido. Selecione a opção Associar IP flutuante.

    Passo 7. Selecione o endereço IP flutuante correspondente destinado a ser usado no campo Endereço IP e escolha a interface de gerenciamento correspondente (eth0) da nova instância onde esse IP flutuante será atribuído na Porta a ser associada. Consulte a próxima imagem como um exemplo deste procedimento.

                                            

    Etapa 8. Finalmente, clique em Associar.

    Habilitar SSH

    Etapa 1. No menu superior do Horizon, navegue até Project > Instances.

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

    Etapa 3. Clique na guia Console. Isso exibirá a CLI da VM.

    Etapa 4. Depois que a CLI for exibida, insira as credenciais de login apropriadas, conforme mostrado na imagem:

               Nome de usuário:raiz

               Senha:cisco123

                                              

    Etapa 5. Na CLI, execute 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 I para editar o arquivo. Em seguida, procure a seção e altere a primeira linha de PasswordAuthentication no para PasswordAuthentication yes conforme mostrado nesta imagem.

    Passo 7. Pressione ESC e execute :wq! para salvar as alterações no arquivo sshd_config.

    Etapa 8. Execute o comando service sshd restart conforme mostrado na imagem.

    Etapa 9. Para testar se as alterações na configuração do SSH foram aplicadas corretamente, 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 como mostrado na imagem.

    Estabelecer sessão SSH

    Etapa 1. Abra uma sessão SSH com o endereço IP da VM/servidor correspondente onde o aplicativo está instalado, como mostrado na imagem.

    início de instância de CPAR

    Siga estas etapas, depois que a atividade tiver sido concluída e os serviços CPAR puderem ser restabelecidos no Site que foi encerrado.

    Etapa 1. Faça login novamente no Horizon, navegue até Project > Instance > Start Instance

    Etapa 2. Verifique se o status da instância está Ativo e se o estado de energia está Em execução como visto nesta imagem.

    9. Verificação de integridade pós-atividade

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

      

    [root@wscaaa04 ~]# /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 o CPAR Health está em 10 de 10 e se a CLI do CPAR de saída está em 10.

    [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 de grep e verifique se todas as conexões DRA estão estabelecidas.

    A saída mencionada aqui é para um ambiente em que 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 esses são os que você precisa prestar atenção.

    O valor do 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 executando o comando:

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

    Esse valor destacado deve ser inferior a 7 Gb, que é o máximo permitido no nível do aplicativo.

    Componente RMA - Nó de computação OSD

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

    Identifique as VMs hospedadas no servidor OSD-Compute.

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

    Note: Na saída mostrada aqui, a primeira coluna corresponde ao UUID, a segunda coluna é o nome da VM e a terceira coluna é o nome do host onde a VM está presente. Os parâmetros dessa saída serão usados em seções subsequentes.

    Backup: PROCESSO DE INSTANTÂNEO 

    1. Desligamento do aplicativo CPAR

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

    É importante não desligar todas as 4 instâncias de AAA em um site ao mesmo tempo, fazer isso de uma forma por uma.

    Etapa 2. Para desligar o aplicativo CPAR, execute o comando:

    /opt/CSCOar/bin/arserver stop

    Uma mensagem "Cisco Prime Access Registrar Server Agent desligado concluído". deve aparecer.

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

    ERROR:    You cannot 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 para que o CPAR possa ser interrompido. Se for esse o caso, encerre o processo executando o comando:

    kill -9 *process_id*

    Em seguida, repita a etapa 1.

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

    /opt/CSCOar/bin/arstatus

    Essas mensagens devem aparecer:

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

    2. Tarefa de Instantâneo da VM

    Etapa 1. Digite o site da GUI do Horizon que corresponde ao Site (Cidade) em que está sendo trabalhado.

    Quando você acessa o Horizon, essa tela pode ser observada.

    Etapa 2. Navegue até Project > Instances como mostrado nesta imagem.

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

    Etapa 3. Desligar apenas uma instância por vez, repita todo o processo neste documento. Para desligar a VM, navegue para Ações > Desligar instância como mostrado na imagem e confirme sua seleção. 

    Etapa 4. Confirme se a instância foi realmente desligada verificando o Status = Desligamento e Estado de energia = Desligar conforme mostrado na imagem.

    Esta etapa encerra o processo de encerramento do CPAR.

    Instantâneo de VM

    Quando as VMs CPAR estiverem desativadas, os snapshots podem ser obtidos em paralelo, pois pertencem a computadores independentes.

    Os quatro arquivos QCOW2 são criados em paralelo.

    Faça um instantâneo de cada instância AAA. (25 minutos - 1 hora) (25 minutos para instâncias que usaram uma imagem qcou como origem e 1 hora para instâncias que usaram uma imagem bruta como origem)

    1. Faça login na GUI do Horizon do Openstack do POD
    2. Depois de fazer login, navegue até a seção Project > Compute > Instances no menu superior e procure as instâncias de AAA como mostrado nesta imagem.

    3. Clique em Create Snapshot para continuar com a criação do snapshot (isso precisa ser executado na instância AAA correspondente), como mostrado na imagem.

    4. Depois que o snapshot for executado, navegue até o menu Imagens e verifique se todos terminam e relatam problemas como vistos nesta imagem.

    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 snapshot executando o comando glance image-list no nível 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 |

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

    6. Depois de identificar o snapshot a ser baixado (o marcado em verde), você pode baixá-lo em um formato QCOW2 com 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 plano de fundo. Pode levar algum tempo para concluir esta ação, uma vez concluída, a imagem pode ser localizada no diretório /tmp.
    • Ao enviar o processo ao segundo plano , se a conectividade for perdida, o processo também será interrompido. 
    • Execute o comando disown -h para que, caso a conexão SSH seja perdida, o processo ainda seja executado e concluído no OSPD.

    7. Quando o processo de download terminar, um processo de compactação precisa ser executado, pois esse snapshot pode ser preenchido com ZEROES devido a processos, tarefas e arquivos temporários tratados pelo SO. O comando a ser usado para compactação de arquivos é virt-sparsify.

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

    Esse processo pode levar 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 que isso ocorra, 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 é perdido, o snapshot recém-criado no formato QCOW2 precisa ser transferido para uma entidade externa. Antes de iniciar a transferência de arquivos, você deve verificar se o destino tem espaço em disco disponível suficiente. Execute o comando df - khin para verificar o espaço de memória. Um conselho é transferi-lo temporariamente para o OSPD de outro site 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, você pode executar o comando scp *name_of_the_file*.qcou2 root@ x.x.x.x:/tmp (onde x.x.x.x é o IP de um OSPD remoto) para transferir o arquivo para outro OSPD.

    Coloque o CEPH no modo de manutenção

    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.

    • Verifique se o status do ceph osd tree 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
    • Faça login no nó de computação OSD e coloque 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 Degraded, mas o disco rígido ainda precisa estar acessível.

    Desligamento normal

    • Desligar nó
    1. Para desligar a instância: nova stop <INSTANCE_NAME>
    2. Você pode 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                 |

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

    Substituir componente defeituoso do nó de computação OSD

    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

    Mova o CEPH do modo de manutenção

    • Efetue login no nó Computação OSD e mova o CEPH para fora 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

    Restaurar VMs

    Recuperar instância com instantâneo

    Processo de recuperação

    É possível reimplantar a instância anterior com o snapshot realizado nas etapas anteriores.

    Etapa 1. [OPCIONAL] Se não houver nenhum VMsnapshot anterior disponível, conecte-se ao nó OSPD onde o backup foi enviado e faça o sftp de volta ao nó OSPD original. Usando sftproot@x.x.x.x onde x.x.x.x é o IP de um OSPD original. Salve o arquivo de snapshot no diretório /tmp.

    Etapa 2. Conecte-se ao nó OSPD onde a instância será reimplantada.

    Origem das variáveis de ambiente com este comando:

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

    Etapa 3. Para usar o snapshot como uma imagem, é necessário carregá-lo no horizonte como tal. Execute 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 Project > Instances e clique em Lauch Instance como mostrado nesta imagem.

    Etapa 5. Insira o Nome da instância e escolha a Zona de disponibilidade conforme mostrado na imagem.

    Etapa 6. Na guia Origem, escolha a imagem para criar a instância. No menu Select Boot Source (Selecionar fonte de inicialização) selecione Image (Imagem), uma lista de imagens é exibida. Escolha a imagem que foi carregada anteriormente clicando em seu sinal +.

    Passo 7. Na guia Flavor, escolha o sabor AAA clicando no sinal +.

      

    Etapa 8. Finalmente, navegue até a guia Redes e escolha as redes que a instância precisará clicando no sinal +. Nesse caso, selecione diâmetro-soutable1, radius-routable1 e tb1-mgmt como mostrado nesta imagem.

      

    Finalmente, clique em Iniciar instância para criá-la. O progresso pode ser monitorado no Horizon:

    Após alguns minutos, a instância será 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 alcançado de fora da arquitetura Ultra M/Openstack e pode se comunicar com outros nós da rede.

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

    Etapa 2. Clique em Alocar IP para Projeto.

    Etapa 3. Na janela Alocar IP Flutuante, selecione o Pool do qual o novo IP flutuante pertence, o Projeto onde ele será atribuído e o novo Endereço IP Flutuante propriamente dito.

    Por exemplo:

                                                                     

    Etapa 4. Clique em Alocar IP Flutuante.

    Etapa 5. No menu superior do Horizon, navegue até Project > Instances.

    Etapa 6. Na coluna Ação, clique na seta que aponta para baixo no botão Criar instantâneo, um menu deve ser exibido. Selecione a opção Associar IP flutuante.

    Passo 7. Selecione o endereço IP flutuante correspondente destinado a ser usado no campo Endereço IP e escolha a interface de gerenciamento correspondente (eth0) da nova instância onde esse IP flutuante será atribuído na Porta a ser associada. Consulte a próxima imagem como um exemplo deste procedimento.

                                            

    Etapa 8. Finalmente, clique em Associar.

    Habilitar SSH

    Etapa 1. No menu superior do Horizon, navegue até Project > Instances.

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

    Etapa 3. Clique na guia Console. Isso exibirá a interface de linha de comando da VM.

    Etapa 4. Depois que a CLI for exibida, insira as credenciais de login apropriadas, conforme mostrado na imagem:

    Nome de usuário:raiz

    Senha:cisco123

    Etapa 5. Na CLI, execute 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 I para editar o arquivo. Em seguida, procure esta seção e altere a primeira linha de PasswordAuthentication no para PasswordAuthentication yes.

    Passo 7. Pressione ESC e digite :wq!t para salvar as alterações de arquivo sshd_config.

    Etapa 8. Execute o comando service sshd restart.

    Etapa 9. Para testar se as alterações na configuração do SSH foram aplicadas corretamente, 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 sessão SSH

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

    início de instância de CPAR

    Siga estas etapas, depois que a atividade tiver sido concluída e os serviços CPAR puderem ser restabelecidos no Site que foi encerrado.

    Etapa 1. Faça login novamente no Horizon, navegue para Project > Instance > Start Instance.

    Etapa 2. Verifique se o status da instância está Ativo e se o estado de energia está em execução conforme mostrado na imagem.

    9. Verificação de integridade pós-atividade

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

      

    [root@wscaaa04 ~]# /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 em 10 e se a CLI CPAR de saída é 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 de grep e verifique se todas as conexões DRA estão estabelecidas.

    A saída mencionada aqui é para um ambiente em que 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 esses são os que você precisa prestar atenção.

    O valor do 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 executando o comando:

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

    Esse valor destacado deve ser inferior a 7 Gb, que é o máximo permitido no nível do aplicativo.

    RMA do componente - Nó do controlador

    Pré-verificação

    • No OSPD, faça login na controladora e verifique se os pcs estão em bom estado - todos os três controladores Online e Galera mostram os três controladores como Master. 

    Note: Um cluster em bom estado exige 2 controladores ativos, portanto, verifique se os dois controladores que permanecem estão On-line e ativos.

    [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

    Mover o cluster do controlador para o modo de manutenção

    • Execute o cluster de pcs no controlador que é atualizado em standby:
    [heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster standby
    • Verifique o status dos pcs novamente e certifique-se de que o cluster de pcs parou neste nó:
    [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           

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

    Substituir componente com falha 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

    Servidor de Ligação

    • Ligue o servidor e verifique se ele está ativado:
    [stack@director ~]$ source stackrc
    [stack@director ~]$ nova list 
    +--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
    | ID | Name | Status | Task State | Power State | Networks |
    +--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
    | 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod2-stack-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.106 |
    | 1f725ce3-948d-49e9-aed9-b99e73d82644 | pod2-stack-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.107 |
    | fbc13c78-dc06-4ac9-a3c5-595ccc147adc | pod2-stack-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.119 |
    | 3b94e0b1-47dc-4960-b3eb-d02ffe9ae693 | pod2-stack-compute-3 | ACTIVE | - | Running | ctlplane=192.200.0.112 |
    | 5dbac94d-19b9-493e-a366-1e2e2e5e34c5 | pod2-stack-compute-4 | ACTIVE | - | Running | ctlplane=192.200.0.116 |
    | b896c73f-d2c8-439c-bc02-7b0a2526dd70 | pod2-stack-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.113 |
    | 2519ce67-d836-4e5f-a672-1a915df75c7c | pod2-stack-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.105 |
    | e19b9625-5635-4a52-a369-44310f3e6a21 | pod2-stack-controller-2 | ACTIVE | - | Running | ctlplane=192.200.0.120 |
    | 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.109 |
    | 26d3f7b1-ba97-431f-aa6e-ba91661db45d | pod2-stack-osd-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.117 |
    | 6e4a8aa9-4870-465a-a7e2-0932ff55e34b | pod2-stack-osd-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.103 |
    +--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
    • Faça login no controlador afetado, remova o modo de espera com o uso de modo de espera. Verifique se a controladora está on-line com o cluster e Galera mostra as três controladoras como Mestre. 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

    • Você pode verificar alguns dos serviços de monitoramento, como ceph, de que eles estão em um estado saudável:
    [heat-admin@pod2-stack-controller-0 ~]$ sudo ceph -s
       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
    TAC Authored

    Colaborado por engenheiros da Cisco

    • Karthikeyan Dachanamoorthy
      Cisco Advanced Services
    • Harshita Bhardwaj
      Cisco Advanced Services

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco