Quorums de Servidores de Catálogo

Quando o mecanismo quorum é ativado, todos os servidores de catálogo no quorum deve estar disponíveis para que as operações de posicionamento ocorram na grade de dados.

Termos Importantes

Pulsações e Detecção de Falha

Servidores de contêiner e grupos principais

O serviço de catálogo coloca servidores de contêiner em grupos principais de tamanho limitado. Um grupo principal tenta detectar a falha de seus membros. Um único membro de um grupo principal é escolhido para ser o líder do grupo principal. O líder do grupo principal informa periodicamente ao serviço de catálogo que o grupo principal está ativo e relata quaisquer alterações de associação no serviço de catálogo. Uma mudança de associação pode ser uma falha da JVM ou uma JVM recém-incluída que une o grupo principal.

Se um soquete de JVM for fechado, essa JVM será considerada não mais disponível. Cada membro do grupo principal também efetua pulsação sobre esses soquetes a uma taxa determinada pela configuração. Se uma JVM não responder a essas pulsações dentro de um período de tempo máximo configurado, a JVM será considerada como não mais disponível, acionando uma detecção de falha.

Se o serviço de catálogo marcar uma JVM de contêiner como com falha e o servidor de contêiner for posteriormente relatado como disponível, o contêiner JVM será informado a encerrar os servidores de contêiner do WebSphere eXtreme Scale. Uma JVM neste estado não é visível nas consultas do comando do utilitário xscmd. As mensagens nos logs da JVM de contêiner indicam que a JVM de contêiner falhou. É necessário reiniciar manualmente estas JVMs.

Se o líder do grupo principal não puder entrar em contato com nenhum membro, ele continuará tentando novamente o contato com o membro.

Também é possível uma falha completa de todos os membros de um grupo principal. Se o grupo principal inteiro falhar, o serviço de catálogo é responsável por detectar essa perda.

Pulsação do domínio de serviço de catálogo

O domínio do serviço de catálogo é semelhante a um grupo principal privado com uma associação estática e um mecanismo de quorum. Ele detecta falhas da mesma forma que um grupo principal normal. Porém, o comportamento é modificado para incluir a lógica de quorum. O serviço de catálogo também usa uma configuração de pulsação menos rigorosa.

Detecção de Falha

O WebSphere eXtreme Scale detecta o fim dos processos por meio de eventos de encerramento do soquete anormais. O serviço de catálogo é informado imediatamente quando um processo é finalizado.

Para obter mais informações sobre como configurar a pulsação, consulte Ajustando a Configuração do Intervalo de Pulsação para Detecção de Failover.

Comportamento do Quorum

Normalmente, os membros do serviço de catálogo possuem conectividade completa. O domínio do serviço de catálogo é um conjunto estático de JVMs. O WebSphere eXtreme Scale espera que todos os membros do serviço de catálogo estejam on-line. Quando todos os membros estiverem on-line, o serviço de catálogo possuirá quorum. O serviço de catálogo responde aos eventos do contêiner apenas enquanto o serviço de catálogo possuir quorum.

Razões para perda de quorum

O WebSphere eXtreme Scale espera perder o quorum nos seguintes cenários:

  • Falha do membro da JVM de serviço de catálogo
  • Indisponibilidade de energia da rede
  • Perda do datacenter
O WebSphere eXtreme Scale não perde o quorum no seguinte cenário:
  • Parar uma instância do servidor de catálogos com o comando stopOgServer ou quaisquer outras ações administrativas. O sistema sabe que a instância do servidor parou, o que é diferente de uma falha ou indisponibilidade de energia da JVM.

Se o serviço de catálogo perder um quorum, ele espera que o quorum seja restabelecido. Enquanto o serviço de catálogo não possui um quorum, ele ignora os eventos dos servidores de contêiner. Os servidores de contêiner continuam tentando quaisquer solicitações que forem rejeitadas pelo servidor de catálogos durante esse tempo. A pulsação é suspensa até um quorum ser restabelecido.

Perda de quorum a partir de uma falha de JVM

Uma falha de servidor de catálogos causa perda de quorum. Se uma JVM falhar, o quorum deverá ser substituído o mais rápido possível. O serviço de catálogo com falha não pode unir novamente a grade de dados até que o quorum seja substituído.

Perda de quorum a partir de indisponibilidade de energia da rede

O WebSphere eXtreme Scale foi projetado para esperar a possibilidade de indisponibilidades de energia. Uma indisponibilidade de energia é quando ocorre uma perda temporária de conectividade entre os datacenters. Essas indisponibilidades de energia geralmente são temporárias e finalizadas em segundos ou minutos. Embora o WebSphere eXtreme Scale tenta manter a operação normal durante o período de indisponibilidade de energia, essa indisponibilidade é considerada um evento de falha único. A falha deve ser corrigida e, em seguida,a operação normal deve ser continuada sem ações necessárias.

Uma queda de energia de longa duração pode ser classificada como um blacaute apenas sob intervenção do usuário. Substituir o quorum em um lado da indisponibilidade de energia é necessário para que o evento seja classificado como um blecaute.

Ciclo JVM de serviço de catálogo

Se um servidor de catálogos for parado ao usar o comando stopOgServer, o quorum diminuirá para um servidor a menos. Os servidores restantes ainda possuirão um quorum. Reiniciar o servidor do catálogos configura o quorum de volta para o número anterior.

Consequências de perda de quorum

Se uma JVM de contêiner falhar enquanto o quorum for perdido, a recuperação não ocorrerá até que a indisponibilidade de energia seja recuperada. Em um cenário de blecaute, a recuperação não ocorre até que o comando de quorum seja executado. A perda de quorum e uma falha do contêiner são consideradas como uma falha dupla, o que é um evento raro. Devido a essa falha dupla, os aplicativos podem perder o acesso de gravação dos dados que foram armazenados na JVM com falha. Quando o quorum é restaurado, a recuperação normal ocorrerá.

Da mesma forma, se você tentar iniciar um contêiner durante um evento de perda de quorum, o contêiner não iniciará.

A conectividade completa do cliente é permitida durante a perda de quorum. Se não ocorrer nenhuma falha de contêiner ou problemas de conectividade durante o evento de perda de quorum, os clientes ainda poderão interagir completamente com os servidores de contêineres.

Se ocorrer uma indisponibilidade de energia, alguns clientes poderão não ter acesso às cópias principais ou réplicas dos dados até voltar a energia.

Novos clientes poderão iniciar porque uma JVM de serviço de catálogo deve existir em cada datacenter. Portanto, pelo menos um servidor de catálogos pode ser acessado por um cliente mesmo durante um evento de indisponibilidade de energia.

Recuperação de quorum

Se o quorum for perdido por algum motivo, quando o quorum for restabelecido, um protocolo de recuperação será executado. Quando ocorrer um evento de perda de quorum, toda a verificação de atividade dos grupos principais será suspensa e os relatórios de falha também serão ignorados. Quando o quorum retornar, o serviço de catálogo verificará todos os grupos principais para determinar imediatamente a associação. Quaisquer shards anteriormente hospedados nas JVMs de contêiner relatados como falha serão recuperados. Se os shards primários forem perdidos, as réplicas sobreviventes serão promovidas para serem os shards primários. Se os shards de réplicas foram perdidos, shards de réplicas adicionais serão criados nos que sobreviveram.

Substituindo Quorum

Substitua o quorum apenas quando ocorrer uma falha do datacenter. A perda de quorum é causada por uma falha de JVM de serviço de catálogo ou por uma indisponibilidade de energia de rede, o que deverá ser recuperado automaticamente quando a JVM de serviço de catálogo for reiniciada ou a energia de rede for restabelecida.

Os administradores são os únicos que reconhecem uma falha do datacenter. O WebSphere eXtreme Scale trata uma indisponibilidade de energia e um blecaute de forma semelhante. Você deve informar o ambiente do WebSphere eXtreme Scale de tais falhas com o comando xscmd -c overrideQuorum. Este comando informa ao serviço de catálogo a assumir que o quorum foi obtido com a associação atual e que uma recuperação completa ocorrerá. Ao emitir um comando de substituição de quorum, você está assegurando que as JVMs no datacenter com falha realmente falharam e que não há nenhuma chance de recuperação.

A lista a seguir considera alguns cenários para substituição de quorum. Nesse cenário, há três servidores de catálogos: A, B e C.
  • Indisponibilidade de energia: O servidor de catálogos C é isolado temporariamente. O serviço de catálogo perde o quorum e aguarda a indisponibilidade de energia acabar. Quando a indisponibilidade de energia acabar, o servidor de catálogo C une novamente o domínio do serviço de catálogo e o quorum é restabelecido. Seu aplicativo não terá problemas durante esse tempo.
  • Falha temporária: Durante uma falha temporária, o servidor de catálogos C falha e o serviço de catálogo perde o quorum. O quorum deve ser substituído. Depois que o quorum for restabelecido, é possível reiniciar o servidor de catálogos C. O servidor de catálogos C une o domínio do serviço de catálogo novamente quando ele for reiniciado. Seu aplicativo não terá problemas durante esse tempo.
  • Falha do datacenter: Verifique se o datacenter falhou e se ele foi isolado na rede. Em seguida, emita o comando xscmd -c overrideQuorum. Os dois datacenters sobreviventes executam uma recuperação completa ao substituir os shards que estavam hospedados no datacenter com falha. O serviço de catálogo agora está em execução com um quorum completo dos servidores de catálogos A e B. O aplicativo pode ver atrasos ou exceções durante o intervalo entre o início do blecaute e quando o quorum é substituído. Depois que o quorum for substituído, a grade de dados será recuperada e a operação normal é continuada.
  • Recuperação do datacenter: Os datacenters sobreviventes já estão em execução com o quorum substituído. Quando o datacenter que contém o servidor de catálogos C é reiniciado, todas as JVMs no datacenter deverão ser reiniciadas. Em seguida, o servidor de catálogos C unirá novamente o domínio do serviço de catálogo existente e a configuração do quorum será revertida para a situação normal sem nenhuma intervenção do usuário.
  • Falha e indisponibilidade de energia do datacenter: O datacenter que contém o servidor de catálogos C falha. O quorum é substituído e recuperado nos datacenters restantes. Se ocorrer uma indisponibilidade de energia entre os servidores de catálogos A e B, as regras de recuperação normal dessa indisponibilidade serão aplicadas. Depois que a indisponibilidade de energia acabar, o quorum será restabelecido e a recuperação necessária da perda do quorum ocorrerá.

Comportamento do Contêiner Durante a perda de Quorum

Os contêineres hospedam um ou mais shards. Os shards são primários ou réplicas de uma partição específica. O serviço de catálogo designa shards para um contêiner e o servidor de contêiner usa essa designação até que as novas instruções cheguem a partir do serviço de catálogo. Por exemplo, um shard primário continua tentando se comunicar com seus shards de réplica durante as indisponibilidades de energia de rede até o serviço de catálogo fornecer instruções adicionais para o shard primário.

Comportamento de réplica síncrona

O shard primário pode aceitar novas transações enquanto a conexão estiver interrompida e se o número de réplicas on-line estiver pelo menos dentro do valor de propriedade minsync para o conjunto de mapas. Se alguma das novas transações for processada no shard primário enquanto o link para a réplica síncrona estiver quebrado, a réplica será ressincronizada com o estado atual do shard primário quando o link for restabelecido.

Não configure a replicação síncrona entre os datacenters ou em um link do tipo WAN.

Comportamento de réplica assíncrona

Enquanto a conexão estiver interrompida, o shard primário pode aceitar novas transações. O shard primário armazena em buffer as mudanças até um limite. Se a conexão com a réplica for restabelecida antes de atingir esse limite, a réplica será atualizada com as alterações em buffer. Se esse limite for atingido, o shard primário destruirá a lista armazenada em buffer e, quando a réplica for reconectada, ela será limpa e ressincronizada.

Comportamento do Cliente Durante a Perda de Quorum

Os clientes sempre podem se conectar com o servidor de catálogos para realizar uma autoinicialização da grade de dados independente se o domínio de serviço de catálogo tiver quorum ou não. O cliente tenta se conectar com qualquer instância do servidor de catálogos para obter uma tabela de rota e, em seguida, interage com a grade de dados. A conectividade de rede pode impedir que o cliente interaja com algumas partições devido à configuração da rede. O cliente pode se conectar com réplicas locais para dados remotos se ele tiver sido configurado para tal. Os clientes não poderão atualizar os dados se a partição primária para esses dados não estiver disponível.