Cluster de Alta Disponibilidade SSM 8.X Local em Funcionamento

Opções de download

  • PDF     (7.9 MB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (9.9 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.

    Introdução

    Este documento descreve como a sincronização da conta local do Smart Software Manager (SSM) e o registro da instância do produto funcionam no servidor local do SSM implantado como um cluster de alta disponibilidade (HA), no momento dos cenários de failover e fallback.

    Pré-requisitos

    Requisitos

    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 superior.

    As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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 Local do SSM durante Failover e Fallback

    O HA entre dois servidores SSM no local 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 de HA mostra o servidor primário (.5) como Ative, servidor secundário (.10) como Standby e VIP (.12) sd mostrado na imagem.

    2. A sincronização do SSM Local com o Cisco Software Central foi concluída com êxito a partir do servidor Principal/Ativo, conforme mostrado na imagem.

    3. O status HA do cluster mostra que o banco de dados do servidor primário (Mestre de Replicação) à esquerda replica no banco de dados do servidor secundário (Escravo de Replicação) à direita, conforme esperado, conforme mostrado na imagem.

    Failover

    1. Parando cluster de alta disponibilidade no Servidor Primário, conforme mostrado na imagem.

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

    3. Conectado à GUI local do SSM com o uso do VIP e a GUI principal está inativa.

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

    5. Pulsação desconectada.

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

    7. A sincronização da conta 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 a pulsação como conectada, Secundária no estado Ativo e Primária 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.

    Fallback

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

    2. O status atual do banco de dados do servidor Primário e do banco de dados do servidor Secundário pode ser visto aqui.

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

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

    5. Pulsação desconectada.

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

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

    8. A GUI estará acessível a partir do endereço VIP (.12) nesse 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 HA do cluster mostra que o banco de dados do servidor primário (Mestre de Replicação) à esquerda está replicando para o banco de dados do servidor secundário (Escravo de Replicação) à direita, como esperado, conforme mostrado na imagem.

    11. A GUI mostra o Heartbeat conectado entre o servidor Primário Ativo e o servidor Secundário em Espera.

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

    Registro de instância de produto com SSM On-Prem VIP durante failover e fallback

    A alta disponibilidade entre dois servidores SSM no local 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 bem-sucedida de HA que mostra o servidor primário (.11) como servidor ativo, secundário (.9) como em espera e VIP (.14).

    2. O status HA do cluster mostra que o banco de dados do servidor primário (Mestre de Replicação) à esquerda replica no banco de dados do servidor secundário (Escravo de Replicação) à direita, conforme esperado, conforme mostrado na imagem.

    3. Quando o SSM no local for implantado como um cluster de alta disponibilidade, efetue login no espaço de trabalho de administração do SSM no local, navegue até Segurança > Certificados e use o Endereço IP virtual no Nome comum do host.

    4. Esse valor deve corresponder ao valor que você planeja usar para o URL de destino do produto. Se estiver implantando pilha dupla (IPv4 e IPv6), esse valor deverá 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 gerados novamente 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 da URL de destino.

    7. A não sincronização pode fazer com que os produtos não se registrem com o novo Nome Comum de Host.

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

    9. A licença consumida/solicitada por essas instâncias de produto estão sendo refletidas na guia Licença.

    Failover

    1. Parando cluster de alta disponibilidade no Servidor Primário, conforme mostrado na imagem.

    2. Conectado à GUI local do SSM com o uso do VIP (.14) e a GUI principal está inativa.

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

    4. Pulsação desconectada.

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

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

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

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

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

    10. Nome da instância do produto: O cucm-pub-30 foi registrado com êxito no 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) sã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ão sendo refletidas na guia Licença.

    13. Iniciando o cluster de alta disponibilidade 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 a pulsação como conectada, Secundária no estado Ativo e Primária no estado Standby, como mostrado na imagem.

    Fallback

    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 pode ser visto.

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

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

    5. Pulsação desconectada.

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

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

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

    9. O status HA do cluster mostra que o banco de dados do servidor primário (Mestre de Replicação) à esquerda replica no banco de dados do servidor secundário (Escravo de Replicação) à direita, conforme esperado.

    10. A GUI mostra o Heartbeat conectado entre o servidor Primário Ativo e o servidor Secundário em Espera.

    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ão sendo refletidas na guia Licença.

    Fazer downgrade de um cluster de alta disponibilidade

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

    6. Disparando a subdivisão no servidor Secundário, conforme mostrado na imagem.

    7. O agregado 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 neva mais no widget Alta disponibilidade.

    9. Disparando a subdivisão no servidor Primário, conforme mostrado na imagem.

    10. O HA foi desabilitado com êxito.

    11. GUI acessada com o uso do endereço IP do servidor primário não neva mais o widget de alta disponibilidade.

    O que vem a seguir?!

    1. Efetue login no SSM On-Prem Primary Administration Workspace, navegue até Security > Certificates e use o servidor Primário (endereço IP/Nome do Host/FQDN) no Nome Comum do Host.

    2. Depois de atualizar o Nome Comum do Host, certifique-se de que seus certificados sejam gerados novamente 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 da URL de destino.

    4. A não sincronização pode fazer com que os produtos não se registrem com o novo Nome Comum de Host.

    Informações Relacionadas

    TAC Authored

    Colaborado por engenheiros da Cisco

    • Annangarachari R
      Engenheiro do Cisco TAC

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Este documento se refere a estes produtos