Como configurar um cluster de banco de dados do CMS versão 3.0

Introduction

Este documento descreve passo a passo a uma configuração de cluster de banco de dados (DB) do Cisco Meeting Server (CMS).

Contribuído por Amadeus Ubaldo e Octavio Miralrio, engenheiros do Cisco TAC.

Prerequisites

Requirements

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

• configuração geral de CMS
• Cliente Secure Shell (SSH)
• Cliente Secure File Transfer Protocol (SFTP)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• CMS versão 3.0
• Cliente SSH de putty
• cliente Windows Secure Copy (winSCP)

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.

Configurar

Diagrama de Rede

Configurações

Etapa 1. Selecione um CMS para ser o nó principal do cluster de banco de dados.

Note: O cluster de banco de dados CMS requer um número ímpar de servidores e máximo de 5. Leia a documentação para obter mais detalhes sobre o Guia de configuração do CMS.

Etapa 2. No CMS selecionado para a função principal, use o cliente SSH para abrir a interface do MMP (Mainboard Management Processor).

Etapa 3. Gere uma solicitação de assinatura de certificado (CSR) para a função de cliente. Usar o próximo formato:

Note: O nome comum (CN) para o cliente CSR deve ser postgres.

pki csr  
     
     
       CN:postgres pki csr DBClient CN:postgres 
     

Etapa 4. Gere um CSR para a função de servidor. Usar o próximo formato:

Note: Adicione os nomes de domínio totalmente qualificados (FQDNs) da parte dos outros servidores do mesmo cluster de banco de dados que o nome alternativo do assunto (SAN).

pki csr  
     
     
       CN: 
      
        subjectAltName: 
       
         pki csr DBServer CN:cms01.mxc-cmspod3.lab subjectAltName:cms02.mxc-cmspod3.lab,cms03.mxc-cmspod3.lab 
        
       
     

Etapa 5. Valide se agora há quatro arquivos criados com o nome que você usou dos comandos anteriores.

DBServer.csr

DBServer.key

DBClient.csr

DBClient.key

Etapa 6. Siga as etapas 3 e 4 com o restante dos servidores CMS parte do cluster DB.

Note: Os mesmos CSRs cliente e servidor e par de chaves gerados do primeiro servidor podem ser usados para o restante dos pares no cluster. Para isso, copie os arquivos .key e os certificados já assinados para o restante dos servidores CMS com um software SFTP.

Passo 7. Use um software SFTP de sua preferência para acessar cada servidor para coletar os arquivos CSR.

Etapa 8. Forneça os arquivos CSR de cada servidor à autoridade de certificação (CA) que você planeja usar para assinar o certificado.

Etapa 9. Quando o certificado já estiver assinado, use um cliente SFTP para carregar os certificados assinados em cada servidor CMS, respectivamente.

Etapa 10. Acesse via CLI para o servidor CMS e atribua o certificado e os arquivos-chave ao serviço de cluster de banco de dados. Use a próxima sintaxe:

database cluster certs 
     
      
       
        
         
         
           database cluster certs DBServer.key DBServer.cer DBClient.key DBClient.cer CA_Root.cer 
          
         
        
       
     

Etapa 11. Repita a etapa 10 para o restante dos servidores CMS para atribuir os certificados respectivamente.

Etapa 12. Acesso via CLI ao CMS designado para ser o nó mestre do cluster DB, selecione a interface atribuída para ser usada para o serviço DB, neste exemplo, é a interface a e execute o comando:

database cluster localnode a

Etapa 13. Repita a etapa 12 no restante dos servidores CMS planejados para se tornarem parte do cluster do CMS DB.

Etapa 14. Acesso via CLI ao CMS com função de BD mestre para inicializar o serviço de banco de dados, execute o próximo comando:

database cluster initialize

Note: A confirmação diferencia maiúsculas de minúsculas, digite a letra Y com maiúsculas. Esse comando deve ser executado somente no banco de dados principal e não nos próximos nós.

Etapa 15. O próximo aviso é exibido. Selecione Y.

database cluster initialize WARNING!!! Are you sure you wish to initialize this node as a new database cluster?(Y/n)
The contents of this node's database will become the primary version of the database in the new cluster.

Initialization started...

Etapa 16. Verifique o status da inicialização, execute o comando database cluster status.

Status:               initializing
Nodes:        
172.16.85.108 (me):   Connected primary
Interface:            a

Note: O status mostra a inicialização se o processo de inicialização do serviço de banco de dados ainda não estiver concluído.

Etapa 17. Execute o comando database cluster status até que o status seja Enabled, o que significa que o processo de inicialização foi bem-sucedido, como mostrado na próxima saída:

Status:       Enabled
Nodes:        172.16.85.108 (me) : Connected primary
Interface:    a

Etapa 18. Acesso via CLI ao próximo peer CMS que faz parte do cluster de banco de dados.

Etapa 19. Execute o comando database cluster join <primary_database_ip_address>.

Etapa 20. Selecione Y.

cms> database cluster join 172.16.85.108

WARNING? ! !
Are you sure you wish to attach this node to an existing database cluster? (Y/n)
The contents of this node's database will be destroyed!

Attachment started...

Etapa 21. Repita o procedimento descrito nas etapas 18, 19 e 20 para o restante dos servidores.

Verificar

Você pode verificar o status do cluster do banco de dados diretamente na CLI. Execute o comando database cluster status. a próxima saída mostra que o processo de cluster ainda não foi concluído:

cms> database cluster status

Status:              Attaching
Nodes:
172.16.85.108:       Connected Primary
172.16.85.117 (me):  Connected Replica
172.16.85.118:       Connected Replica
Interface:           a

Quando o processo de associação do cluster de banco de dados for concluído com êxito, você deverá ver o status como Ativado:

cms> database cluster status

Status:                Enabled
Nodes:
172.16.85.108:         Connected Primary
172.16.85.117 (me):    Connected Replica
172.16.85.118:         Connected Replica

Node in use:           172.16.85.108
Interface:             a     

Certificates
Server Key:            DBServer.key
Server Certificate:    DBServer.cer
Client Key:            DBClient.key
Client Certificate:    DBClient.cer
CA Certificate:        CA_root.cer
Last command:          'database cluster join 172.16.85.108' (Success)