O que é o cluster do Expressway e como ele funciona

Introduction

Este documento descreve como os clusters do Expressway são projetados para estender a resiliência e a capacidade de uma instalação do Expressway.  

Informações de Apoio

Capacidade. O cluster do Expressway pode aumentar a capacidade de uma implantação do Expressway em um fator máximo de quatro, em comparação com um único Expressway. Os peers do Expressway em um cluster compartilham o uso da largura de banda, bem como roteamento, zona, FindMe e outras configurações.

Resiliência. O cluster do Expressway pode fornecer redundância enquanto um Expressway está em modo de manutenção ou, no caso de ele se tornar inacessível devido a uma falta de energia ou de rede, ou por outro motivo. Os endpoints podem se registrar em qualquer um dos peers em um cluster. Se os endpoints perderem a conexão com seu peer inicial, poderão se registrar novamente em outro no cluster.

Especificações

Um Expressway pode fazer parte de um cluster de até seis Expressways. Ao criar um cluster, você nomeia um peer como primário, do qual sua configuração é replicada para os outros peers. Cada peer do Expressway no cluster deve ter os mesmos recursos de roteamento. Se qualquer Expressway puder rotear uma chamada para um destino, supõe-se que todos os peers do Expressway nesse cluster possam rotear uma chamada para esse destino.

Capacidade

Não há ganho de capacidade após quatro pares. Assim, em um cluster de seis pontos, por exemplo, o quinto e o sexto Expressways não adicionam capacidade extra de chamada ao cluster. A resiliência é melhorada com os pares extras, mas não com a capacidade.

• Para máquinas virtuais pequenas (VMs), o cluster é somente para redundância e não para escala e não há ganho de capacidade do cluster.
• A capacidade baseada na configuração de cluster de 4 pares é mostrada na próxima imagem:

Elementos importantes da página

Requirements

• Conhecimento básico do Secure Shell (SSH)
• Um cluster deve conter apenas o nó Expressway-C ou apenas os nós Expressway-E.
• Todos os pares devem usar a mesma versão de software.
• Todos os colegas usam plataforma de hardware, dispositivo ou máquina virtual (VM), com recursos equivalentes.
• O Expressway suporta um atraso de ida e volta de até 80 ms.
• O modo H323 é ativado em cada peer.
• Todos os peers têm o mesmo conjunto de chaves de opção instaladas, com as próximas exceções:

• Para VCS (Video Control Server, servidor de controle de vídeo): Licenças de chamadas transversais e não-transversais
• Para Expressway: Sessões de rich media
• Para Expressway: Licenças de registro do sistema de sala e do sistema de desktop

Todas as outras chaves de licença devem ser idênticas em cada peer.

• Não deve haver Conversão de Endereço de Rede (NAT - Network Address Translation) entre os correspondentes do cluster.

Note: Se o Expressway-E usa NIC (Network Interface Controller, Controlador de Interface de Rede) único, ele deve usar IP público. Se o Expressway-E usar NIC dupla, a interface interna deverá ser usada para criar o cluster.

• O endereço IP, o Domain Name Service (DNS) e o Network Time Protocol (NTP) devem ser configurados. 

Conexões e portas do cluster

Configurações

Criar um novo cluster

1. Abra a interface da Web do Expressway.
2. Navegue até Sistema > Clustering.
3. Insira os próximos valores:

Note: Você deve criar um cluster de um peer (primário) primeiro e reiniciar o primário antes de adicionar outros peers. Você pode adicionar mais colegas depois de ter estabelecido um cluster de um.

Configuração principal: 1

Versão IP do cluster: Escolha IPv4 ou IPv6 para corresponder ao esquema de endereços de rede.

Opções do modo de verificação TLS: Permissivo (padrão) ou Aplicar.

       Permissivo significa que os peers não validam os certificados uns dos outros quando as conexões TLS (Transport Layer Security) entre clusters são estabelecidas.

       A aplicação é mais segura, mas exige que cada peer tenha um certificado válido e que a autoridade de certificação (AC) seja confiável por todos os outros pares.

Endereço do correspondente 1: Insira o endereço deste Expressway (o peer principal). Se o modo de verificação TLS estiver definido como Enforce, você deverá inserir um FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado) que corresponda ao CN (Common Name, nome comum) ou SAN (Subject Alternative Name, nome alternativo do assunto) no certificado desse peer.

4. Selecione Salvar.
5. Reiniciar o servidor.
6. Navegue até Manutenção > Opções de reinicialização e selecione Reiniciar e confirme OK.
7. Valide se o certificado é válido, como mostrado na próxima imagem:

Adicionar outros pares ao cluster

 

Para adicionar um peer adicional, siga as próximas etapas:

1. Navegue até Sistema > Clustering no Expressway principal.
2. No primeiro campo vazio, insira o endereço do novo peer do Expressway.
3. Selecione Salvar.
4. Peer 1 deve indicar Este sistema. O novo peer deve indicar Desconhecido e, em seguida, com uma atualização, deve indicar Falha porque ainda não se uniu totalmente ao cluster.
5. Navegue para Sistema > Clustering em um dos peers subordinados já no cluster e edite os próximos campos:
   
   
   
   
6. Repita a etapa anterior para cada um dos peers subordinados já no cluster.
7. Selecione Salvar.
8. O Expressway ativa um alarme de falha de comunicação de cluster. O alarme é apagado após a reinicialização necessária.
9. Reinicie o Expressway.
10. Após a reinicialização, aguarde aproximadamente 2 minutos - esta é a frequência com que a configuração é copiada do principal.
11. Validar o status do banco de dados do Cluster.
    
    
12. Verifique se a configuração é replicada em um peer suboridinate.

Aplicar verificação TLS

Caution: Antes de continuar, verifique se as SANs de certificado contêm os FQDNs que estão nos campos de endereço Peer N. Você deve ver mensagens de status verdes para clustering e certificado ao lado de cada campo de endereço antes de continuar.  

1. No peer principal, defina o modo de verificação TLS como Enforce.

Caution: Um aviso será exibido se algum certificado for inválido e impedir que o cluster funcione corretamente no modo de verificação TLS aplicada.

2. O novo modo de verificação TLS é replicado em todo o cluster.
3. Verifique se o modo de verificação TLS está agora em vigor entre si.
4. Selecione Salvar e reinicie o peer principal.
5. Depois que o peer principal estiver on-line novamente, reinicie cada peer um por um.
6. Aguarde o cluster estabilizar e valide se o status Clustering e Certificate está verde para todos os peers.

Alterar o peer principal

Note: Você pode fazer esse processo mesmo se o peer principal atual não estiver acessível.

1. No novo Expressway principal, navegue para Sistema > Clustering.
2. No menu suspenso primário Configuration selecione o número de ID da entrada de peer que diz This system.
3. Selecione Salvar.

Note: Enquanto esse processo é executado, ignore todos os alarmes no Expressway que relatam erro de incompatibilidade primária de cluster ou erro de replicação de cluster.

4. Em todos os outros pares do Expressway, comece com o antigo peer primário (se ainda estiver acessível).
5. Navegue para Sistema > Clustering.
6. No menu suspenso primário Configuration selecione o número de ID do novo Expressway principal.
7. Selecione Salvar.
8. Confirme se a alteração no primário de configuração foi aceita, navegue para Sistema > Cluster e atualize a página.
9. Se algum Expressway não aceitou a alteração, repita o mesmo procedimento.
10. Valide se o status do banco de dados do cluster relata como Ativo.

Alterar cluster para usar FQDNs

Note: Enquanto esse procedimento é executado, as comunicações entre os pares são temporariamente impactadas, isso significa que é esperado ver alarmes que persistem até que as alterações sejam concluídas e o cluster concorde com os novos endereços.

1. Entre em todos os peers do cluster e navegue para Sistema > Clustering.
2. Escolha qual endereço de peer é alterado. recomenda-se começar com o endereço do Peer 1.
3. Em cada peer no cluster, siga o próximo procedimento:
4. Altere o campo do endereço do peer escolhido do endereço IP para seu FQDN.
5. Selecione Salvar.
6. Mude para o peer identificado pelo endereço do peer alterado e reinicie o servidor.
7. Aguarde a resolução de qualquer alarme de cluster transitório.
8. Escolha o próximo endereço de peer a ser alterado e repita as etapas de 3 a 7.
9. Repita esse procedimento até que você tenha alterado todos os endereços de peer e reiniciado todos os peers.

Mapeamento de endereços de cluster para Expressway-E

Para implantações seguras como acesso móvel e remoto (MRA), cada peer Expressway-E deve ter um certificado com uma SAN que contenha seu FQDN público. O FQDN é mapeado no DNS público para o endereço IP público do Expressway-E.

Note: Se você simplesmente quiser agrupar os correspondentes do Cisco Expressway-E e não precisar de verificação TLS entre eles, você poderá formar o cluster com os endereços IP privados dos nós. Você não precisa de mapeamento de endereços de cluster.

Os mapeamentos de endereços de cluster são pares FQDN:IP compartilhados ao redor do cluster, um par para cada par. Os colegas consultam a Tabela de Mapeamento antes de consultar o DNS e, se encontrarem uma correspondência, não consultam o DNS.

Se você optar por aplicar o TLS, os correspondentes também deverão ler os nomes do campo SAN dos certificados uns dos outros e verificar cada nome em relação ao lado FQDN do mapeamento.

É altamente recomendável que você insira os mapeamentos no peer principal. Mapeamentos de endereço replicam-se dinamicamente através do cluster. Para configurar o Mapeamento de endereços, siga o próximo procedimento:

1. Nabigar para Sistema > Clustering no peer primário e alterar o menu suspenso Mapeamento de endereço de cluster ativado para Ativado (o padrão é Desativado). Os campos de mapeamento de endereços de cluster são exibidos.
2. Edite os mapeamentos de modo que os FQDNs públicos dos peers do Expressway-E correspondam aos endereços IP de suas NICs internas.
3. Selecione Salvar.

Caution: Não tente usar o DNS público para mapear os FQDNs públicos dos colegas para seus endereços IP privados, essa ação pode quebrar a conectividade externa.  

Cluster com NIC única

Se você quiser que os correspondentes do Expressway-E em um cluster verifiquem a identidade uns dos outros com certificados, você poderá permitir que eles usem DNS para resolver FQDNs de peer de cluster para seus endereços IP públicos. Essa é uma maneira perfeitamente aceitável de formar um cluster se os nós do Expressway-E tiverem:

• Somente uma NIC
• Nenhum NAT estático configurado
• Endereços IP roteáveis

Troubleshooting

O que dispara uma redefinição de fábrica?

Se você limpar todos os campos de endereço de peer da página de clustering e salvar a configuração, o Expressway, por padrão, executa uma redefinição de fábrica na próxima vez que você reiniciar. Isso significa que toda a configuração é excluída, exceto a configuração básica de rede para a interface Local Area Network 1 (LAN1), que inclui toda a configuração executada após você limpar os campos e a próxima reinicialização.

Tip: Se precisar evitar a redefinição de fábrica, restaure os campos de endereço de peer do cluster. Substitua os endereços de peer originais na mesma ordem e salve a configuração para limpar o banner.

A redefinição de fábrica é automaticamente acionada quando o peer é reiniciado, para remover dados confidenciais e a configuração do cluster. A redefinição limpa toda a configuração, exceto as próximas informações básicas de rede:

Note: Se você usar a opção NIC dupla, esteja ciente de que qualquer configuração LAN2 é completamente removida pela redefinição.

• Endereços IP - Contas e senhas de administrador e raiz
• chaves SSH
• Teclas de opção
• Acesso seguro do protocolo de transferência de hipertexto (HTTPS) ativado
• Acesso SSH habilitado

Note: Na versão X12.6, a redefinição de fábrica remove o certificado do servidor, a chave privada associada e as configurações do repositório de confiança da AC do peer. Em versões anteriores do software Expressway, essas configurações são preservadas.

Falha de redefinição de fábrica

A redefinição de fábrica pode falhar, isso pode acontecer se o Expressway for um Open Virtualization Appliance (OVA) de nova instalação e não tiver sido atualizado. 

Para corrigir isso, siga qualquer uma das seguintes opções:

• Atualize todos os nós para a mesma versão de software com o arquivo tar.gz. Ao final do processo de atualização, reinicie o servidor, que depois aciona a redefinição de fábrica.
• Carregue o arquivo tar.gz diretamente na pasta de redefinição de fábrica com WinSCP (/mnt/harddisk/fatory-reset/). Em seguida, reinicie para iniciar a redefinição de fábrica ou emita a redefinição de fábrica a partir da CLI.

Note: Certifique-se de fazer os backups corretos antes de fazer uma atualização, alterar certificado ou quando houver um aviso de redefinição de fábrica.

Sequência de reinicialização

Se for necessário reiniciar o cluster ou qualquer peer, siga as próximas etapas:

1. Reinicie o peer principal e aguarde que ele seja acessível via interface da Web.
2. Valide o status de replicação do cluster no principal e no status de todos os peers. Aguarde alguns minutos e atualize ocasionalmente as interfaces da Web do peer.
3. Reinicie outros pares, se necessário, um de cada vez. De cada vez, aguarde alguns minutos depois que ele estiver acessível e valide seu status de replicação.

Note: Talvez seja necessário aguardar aproximadamente 5 minutos após fazer qualquer alteração de nuvem antes que os peers do Expressway relatem o status de êxito.

Alarmes e avisos

Os alarmes de erros de cluster são mostrados no formato: Erro de replicação de cluster: (detalhes) a sincronização manual da configuração é necessária, alguns exemplos são os seguintes:

• Erro de replicação de cluster: a sincronização manual da configuração é necessária.
• Erro de replicação de cluster: não é possível localizar o arquivo de configuração de peer principal ou deste subordinado, é necessária a sincronização manual da configuração.
• Erro de replicação de cluster: o ID principal da configuração é inconsistente, é necessária a sincronização manual da configuração.
• Erro de replicação de cluster: esta configuração do peer está em conflito com a configuração do primário, é necessária a sincronização manual da configuração.

Se um Expressway subordinado informar o alarme mencionado, siga o procedimento a seguir:

1. Efetue login como admin em um SSH ou outra interface CLI.
2. Execute o próximo comando: xcommand ForceConfigUpdate

Note: Certifique-se de fazer os backups corretos antes de fazer uma atualização, alterar certificado ou quando houver um aviso de redefinição de fábrica.

3. Esse comando exclui a configuração subordinada do Expressway e força-o a atualizar sua configuração do Expressway principal.

Se o problema persistir, ele pode estar relacionado à chave de criptografia por peer de cluster. Geralmente ocorre quando os peers são atualizados na ordem errada, os peers subordinados não são sincronizados com o principal. Se xcommand forceconfigupdate não funcionar, siga o procedimento a seguir:

1. Entre no peer principal e confirme se ele está em um bom estado.
2. Certifique-se de que a configuração do cluster mostra esse peer como o principal.
3. Atualize o principal novamente, use o mesmo pacote que você usou originalmente para atualizar.

O alarme de replicação é cancelado depois que o peer primário é atualizado e reinicializado. Isso normalmente acontece dez minutos após a reinicialização, mas pode ser até vinte minutos após a reinicialização.

Alarmes comuns

Configuração de cluster inválida: O modo H.323 deve ser ativado - o cluster usa comunicações H.323 entre pares.

Para limpar esse alarme, certifique-se de que o modo H.323 esteja ligado, navegue para Configuration > Protocols > H.323.

Falha do banco de dados Expressway: Entre em contato com o representante de suporte da Cisco.

Para solucionar esse tipo de alarme, siga o procedimento a seguir:

1. Faça um snapshot do sistema e forneça-o ao representante de suporte.
2. Remova o Expressway do cluster.
3. Restaure o banco de dados do Expressway a partir de um backup feito no Expressway anteriormente.
4. Adicione o Expressway de volta ao cluster.

Um segundo método é possível se o banco de dados não recuperar:

1. Faça um snapshot do sistema e forneça-o ao Technical Assistance Center (TAC).
2. Remova o Expressway do cluster.
3. Efetue login como root e execute o próximo comando clusterdb_detect_and_purge_data.sh.
4. Restaure o banco de dados do Expressway a partir de um backup feito no Expressway anteriormente.
5. Adicione o Expressway de volta ao cluster. 

Note: Certifique-se de fazer os backups corretos antes de fazer uma atualização, alterar certificado ou quando houver um aviso de redefinição de fábrica.

Caution: clusterdb_detect_and_purge_data.sh é tão perigoso quanto parece — use esta opção como último recurso.

Problemas relacionados à chave do sistema

Note: As próximas informações aplicam-se à versão X14 em diante.

Falha ao atualizar os alarmes de arquivos de chave são gerados em Expressways em um único cenário de nó.

Siga o próximo procedimento para solucionar esse tipo de alarme:

1. Faça login como administrador através da CLI (disponível por padrão através do SSH e através da porta serial nas versões de hardware).
2. Execute o próximo comando: xCommand ForceSystemKeyUpdate.

Falha ao atualizar os alarmes de arquivos de chave são gerados em Expressways em um cenário de cluster.

Siga o próximo procedimento para solucionar esse tipo de alarme:

1. Faça login no nó como administrador através da CLI (disponível por padrão no SSH e através da porta serial nas versões de hardware) onde esse alarme não é acionado.
2. Execute o próximo comando: xCommand ForceSystemKeyUpdate.

Detalhes do registro

Como em qualquer outro log no Expressway, você pode ativar os logs de diagnóstico, com os Dumps de TCP.

Em um estado normal, a Sincronização de BD no nó mestre é mostrada nos registros como a próxima saída:

2020-07-21T15:16:50.321-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,321" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:50.330-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,330" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="0" 
2020-07-21T15:16:50.433-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,433" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(257)" Detail="This peer is the cluster master, local configuration has already been replicated to the other peers"
2020-07-21T15:16:50.437-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,437" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Da perspectiva do nó de peer, ela é mostrada como a próxima saída:

2020-07-21T15:16:46.900-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,899" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:46.908-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,908" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="1" 
2020-07-21T15:16:46.947-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,946" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(254)" Detail="This peer is not the cluster master, local configuration is already up to date"
2020-07-21T15:16:46.950-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,950" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Um Peer Disconnection é mostrado na próxima saída:

2020-08-12T14:57:43.353-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Processed mnesia_down event from accessible node" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="ERROR" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Inconsistent Database" Context="from mnesia system - mnesia down" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Connecting database on mnesia running_partitioned_network event" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Ready to perform node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Running node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.synchronise" Level="WARN" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Failed connecting to node" Node="clusterdb@expc02.apolo.local" Reason="{ badrpc, { EXIT, { aborted, { noproc, { gen_server, call, [ kernel_safe_sup, { start_child, { dets_sup, { dets_sup, start_link,  }, permanent, 1000, supervisor, [ dets_sup ] } }, infinity ] } } } } }"
2020-08-12T14:57:43.524-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20006" UUID="0f96695e-d954-4f6f-85c1-2ef1eae6f764" Severity="warning" Detail="Cluster database communication failure: The database is unable to replicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,524"
2020-08-12T14:57:43.771-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20004" UUID="3bca6888-f622-11df-93be-07cc953d7b99" Severity="warning" Detail="Cluster communication failure: The system is unable to communicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,771"

2020-08-12T14:57:53.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:53,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:54.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:54,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:56.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:56,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:57.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:57,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: Event="External Server Communications Failure" Reason="gatekeeper timed out" Service="NeighbourGatekeeper" Detail="name:10.15.13.16:1719" Level="1" UTCTime="2020-08-12 19:57:58,871"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:58,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Timeout=True"
2020-08-12T14:57:59.601-05:00 expc01 UTCTime="2020-08-12 19:57:59,601" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Triggering forced peer update of peers which failed DNS and queueing next run" Queue-Time-ms="300000"
2020-08-12T14:58:01.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:58:01,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Timeout=True"

A alteração para TLS Execution no nó mestre é mostrada na próxima saída:

2020-08-12T15:13:24.970-05:00 expc01 UTCTime="2020-08-12 20:13:24,969" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.976-05:00 expc01 UTCTime="2020-08-12 20:13:24,975" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.976-05:00 expc01 httpd[15060]: web: Event="System Configuration Changed" Detail="configuration/cluster/tls_verify - changed from: 'Permissive' to: 'Enforcing'" Src-ip="10.15.13.30" Src-port="53155" User="admin" Level="1" UTCTime="2020-08-12 20:13:24" 
2020-08-12T15:13:24.979-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.980-05:00 expc01 UTCTime="2020-08-12 20:13:24,980" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.986-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,986" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.142.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.031-05:00 expc01 UTCTime="2020-08-12 20:13:25,031" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed" 
2020-08-12T15:13:25.192-05:00 expc01 management: UTCTime="2020-08-12 20:13:25,192" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.195-05:00 expc01 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,194"

Da perspectiva do nó de peer, ele é mostrado na próxima saída:

2020-08-12T15:13:24.976-05:00 expc02 UTCTime="2020-08-12 20:13:24,976" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.390.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.979-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.982-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,982" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.041-05:00 expc02 UTCTime="2020-08-12 20:13:25,041" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.042-05:00 expc02 UTCTime="2020-08-12 20:13:25,042" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.046-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,047" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.049-05:00 expc02 UTCTime="2020-08-12 20:13:25,049" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
 2020-08-12T15:13:25.136-05:00 expc02 management: UTCTime="2020-08-12 20:13:25,136" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.139-05:00 expc02 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,139"

Vídeos

Os próximos vídeos podem ser úteis:

Como criar e adicionar um peer a um cluster do Expressway

Removendo um peer de um cluster do Expressway

Corrigindo o erro de replicação do Expressway "conflitos de configuração de peer com primário"

Procedimento de Reinicialização do Cluster Expressway

Como atualizar um cluster do ExpresswayGerando CSR para MRA/Clustered Expressways