Cluster de alta disponibilidade SSM On-Prem 8.X em funcionamento

Opções de download

  • PDF     (7.7 MB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (8.0 MB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (4.1 MB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:24 de junho de 2021
ID do documento:217212

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 como a sincronização de Conta On-Prem do Smart Software Manager (SSM) e o registro de Instância de Produto funcionam no servidor SSM On-Prem implantado como um Cluster de alta disponibilidade (HA), no momento de cenários de failover e de rechamada.

    Prerequisites

    Requirements

    A Cisco recomenda que você tenha conhecimento destes tópicos:

    • SSM no local
    • HA

    Componentes Utilizados

    As informações neste documento são baseadas no SSM On-Prem 8 e superiores.

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

    Informações de Apoio

    Estes são os documentos de referência que fornecem informações sobre HA.

    Sincronização de conta no local do SSM durante failover e failback

    O HA entre dois servidores SSM On-Prem deve ser configurado com a ajuda deste guia:

    Implante o cluster HA: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    Nesta demonstração, use:

    .5 - Endereço IP do servidor primário

    .10 - Endereço IP do servidor secundário

    .12 - Endereço IP virtual

    Alta Disponibilidade

    1. A configuração bem-sucedida do HA mostra o servidor primário (.5) como servidor secundário ativo (.10) como standby e o sd VIP (.12) mostrado na imagem.

    2. A sincronização do SSM On-Prem com o Cisco Software Central foi concluída com êxito do servidor Principal/Ativo, como mostrado na imagem.

    3. O status de HA do cluster mostra que o banco de dados do servidor primário (Replication Master) à esquerda é replicado para o banco de dados do servidor secundário (Replication Slave) à direita, conforme esperado, como mostrado na imagem.

    Failover

    1. Interrompendo cluster HA no servidor primário como mostrado na imagem.

    2. Primário|Secundário como mostrado na imagem.

    3. Conectado à GUI do SSM On-Prem com o uso de VIP e a GUI primária está inoperante.

    4. O servidor secundário (.10) é mostrado como um servidor Ativo.

    5. O ritmo cardíaco está desconectado.

    6. Servidor primário (.5) movido para o estado Standby.

    7. A sincronização da conta no local do SSM com o Cisco Software Central pode ser vista com êxito na GUI do servidor Secundário/Ativo, como mostrado na imagem.

    8. Iniciando o cluster HA no servidor primário como mostrado na imagem.

    9. O status do cluster HA mostra que o banco de dados principal é replicado do banco de dados secundário.

    10. Primário|Secundário como mostrado na imagem.

    11. A GUI mostra o heartbeat como conectado, Secundário no estado Ativo e Primário no estado Standby, como mostrado na imagem.

    12. Crie uma nova conta TEST e ative-a no modo de espera ativo. (.10) servidor.

    13. A GUI principal (.5) não estará acessível neste estágio.

    Retorno

    1. Parando Ha_cluster em Secundário, como mostrado na imagem.

    2. O status atual do banco de dados do servidor primário e do banco de dados do servidor secundário podem ser vistos aqui.

    3. Conectado à GUI no local do SSM com o uso de VIP e a GUI secundária está inoperante.

    4. O servidor primário (.5) é mostrado como um servidor ativo.

    5. O ritmo cardíaco está desconectado.

    6. Servidor secundário (.5) movido para o estado Standby.

    7. A conta TEST recém-criada pode ser vista em estado sincronizado à medida que a replicação ocorreu do banco de dados Secundário para Principal, como mostrado na imagem.

    8. A GUI será acessível do endereço VIP (.12) neste estágio e não do endereço IP secundário.

    9. Iniciando o cluster HA no servidor secundário como mostrado na imagem.

    10. O status de HA do cluster mostra que o banco de dados do servidor primário (Replication Master) à esquerda está sendo replicado para o banco de dados do servidor secundário (Replication Slave) à direita, como esperado na imagem.

    11. A GUI mostra Heartbeat conectado entre o servidor Ative Primary e o servidor Standby Secondary.

    12. A conta TEST é sincronizada com êxito com o Cisco Software Central.

    Registro de instância de produto com SSM VIP no local durante failover e failback

    A alta disponibilidade entre dois servidores no local SSM deve ser configurada usando este guia:

    Implantação do cluster HA: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    Nesta demonstração, use:

    .11 - Endereço IP do servidor primário

    .9 - Endereço IP do servidor secundário

    .14 - Endereço IP virtual

    Alta Disponibilidade

    1. Configuração de HA bem-sucedida que mostra o servidor primário (.11) como servidor secundário ativo (.9) como standby e VIP (.14).

    2. O status de HA do cluster mostra que o banco de dados do servidor primário (Replication Master) à esquerda é replicado para o banco de dados do servidor secundário (Replication Slave) à direita, conforme esperado, como mostrado na imagem.

    3. Quando o SSM On-Prem for implantado como um cluster HA, faça login no SSM On-Prem Administration Workspace, navegue até Security > Certificados e use o Virtual IP Address no Host Common Name.

    4. Esse valor deve corresponder ao valor que você planeja usar para a URL de destino do produto. Se estiver implantando pilha dupla (IPv4 e IPv6), esse valor deve ser um FQDN e não um endereço IP.

    5. Depois de atualizar o nome comum do host, certifique-se de que seus certificados sejam regenerados com o novo nome comum, sincronizando suas contas locais com o Cisco Smart Software Manager.

    6. Você deve sincronizar antes de tentar registrar novamente os produtos com o novo Nome Comum na configuração de URL de destino.

    7. A não sincronização pode fazer com que os produtos não se registrem com o novo Host Common Name.

    8. Duas instâncias de produto (annanr-39) e (cucmpub) estão registradas no endereço VIP do SSM On-Prem, conforme visto na guia Product Instances (Instâncias de produto).

    9. A licença consumida/solicitada por essas instâncias de produto está refletindo na guia Licença.

    Failover

    1. Interrompendo cluster HA no servidor primário como mostrado na imagem.

    2. Conectado à GUI do SSM On-Prem com o uso de VIP (.14) e a GUI primária está inoperante.

    3. O servidor secundário (.9) é mostrado como um servidor ativo.

    4. O ritmo cardíaco está desconectado.

    5. O servidor primário (.11) é movido para o estado Standby.

    6. Registrando instâncias de produtos com o uso do SSM On-Prem VIP na URL de registro de produto na configuração do Transport Gateway, como mostrado na imagem.

    7. Nome da instância do produto: pi37 foi registrado com êxito com o SSM On-Prem com o uso de um endereço VIP, como mostrado na imagem.

    8. Registrando outras instâncias de produto com o uso do SSM On-Prem VIP na URL de registro de produto na configuração do Transport Gateway.

    9. O registro do produto foi concluído com êxito com o SSM On-Prem usando um endereço VIP como mostrado na imagem.

    10. Nome da instância do produto: cucm-pub-30 foi registrado com êxito com o SSM On-Prem com o uso de um endereço VIP, como mostrado na imagem.

    11. Duas novas instâncias de produto (pi37) e (cucm-pub-30) estão registradas no endereço VIP do SSM On-Prem, conforme visto na guia Product Instances.

    12. A licença consumida/solicitada por essas instâncias de produto está refletindo na guia Licença.

    13. Iniciando o cluster HA no servidor primário.

    14. O status do cluster HA mostra que o banco de dados principal é replicado do banco de dados secundário.

    15. Primário|Secundário como mostrado na imagem.

    16. A GUI mostra o heartbeat como conectado, Secundário no estado Ativo e Primário no estado Standby, como mostrado na imagem.

    Retorno

    1. Parando Ha_cluster no secundário.

    2. O status atual do banco de dados do servidor primário e do banco de dados do servidor secundário inativo podem ser vistos.

    3. Conectado à GUI no local do SSM usando VIP (.14) e a GUI secundária está inoperante.

    4. O servidor primário (.11) é mostrado como um servidor Ativo.

    5. O ritmo cardíaco está desconectado.

    6. Servidor secundário (.9) movido para o estado Standby.

    7. A GUI será acessível do endereço VIP (.14) neste estágio e não do endereço IP secundário.

    8. Iniciando o cluster HA no servidor secundário.

    9. O status de HA do cluster mostra que o banco de dados do servidor primário (Replication Master) à esquerda é replicado para o banco de dados do servidor secundário (Replication Slave) à direita conforme esperado.

    10. A GUI mostra Heartbeat conectado entre o servidor Ative Primary e o servidor Standby Secondary.

    11. Todas as quatro instâncias de produto registradas no endereço VIP do SSM On-Prem, conforme visto na guia Product Instances.

    12. A licença consumida/solicitada por essas instâncias de produto está refletindo na guia Licença.

    Desatualizar um cluster de alta disponibilidade

    1. Um cluster no local do Cisco Smart Manager pode ser baixado diretamente para um único nó autônomo.
    2. Use o console local para se conectar ao SSM principal/ativo no local com o uso do comando <ha_teardown>.
    3. Depois de verificar a operação do SSM On-Prem, o servidor Secundário/Standby deve ser descartado e não pode ser reutilizado.
    4. Agora você terá um sistema autônomo em vez de um cluster.
    5. O encerramento foi iniciado conforme mostrado na imagem.

    6. Disparo no servidor secundário, como mostrado na imagem.

    7. O cluster HA foi destruído. O SSMS agora está em um modo independente.

    8. A GUI acessada com o uso do endereço IP do servidor secundário não exibe mais o widget Alta disponibilidade.

    9. Disparo no servidor Primário como mostrado na imagem.

    10. HA foi desabilitado com êxito.

    11. A GUI acessada com o uso do endereço IP do servidor primário não exibe mais o widget Alta disponibilidade.

    O que vem a seguir?!

    1. Faça login no SSM On-Prem Primary Administration Workspace, navegue até Security > Certificados e use o Primary server's (endereço IP/nome de host/FQDN) no Host Common Name.

    2. Depois de atualizar o Nome Comum do Host, certifique-se de que seus certificados sejam regenerados com o novo Nome Comum, sincronizando suas Contas Locais com o Cisco SSM.

    3. Você deve sincronizar antes de tentar registrar novamente os produtos com o novo Nome Comum na configuração de URL de destino.

    4. A não sincronização pode fazer com que os produtos não se registrem com o novo Host Common Name.

    Informações Relacionadas

    TAC Authored

    Colaborado por engenheiros da Cisco

    • Annangarachari R
      Cisco TAC Engineer

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Este documento se refere a estes produtos