ZooKeeper é um serviço usado para coordenar (sincronizar) processos distribuídos.Ele fornece um kernel de coordenação simples e de alto desempenho no qual os usuários podem construir funções de coordenação distribuídas mais complexas.
A divisão do cérebro geralmente ocorre em ambientes de cluster, como os clusters ElasticSearch e Zookeeper. E esses ambientes de cluster possuem um recurso unificado, ou seja, eles têm um cérebro, por exemplo, existem nós Master no cluster ElasticSearch e nós Leader no cluster Zookeeper.
1. Por que os nós de cluster do Zookeeper devem ser implantados em números ímpares
A tolerância a falhas do Zookeeper significa que quando vários servidores de nó do Zookeeper estão inativos, o número restante deve ser maior que o número que está inativo, ou seja, o número de serviços de nó restantes deve ser maior que n / 2, para que o cluster Zookeeper possa continuar a ser usado. O líder pode ser eleito independentemente do número par ou ímpar. Por exemplo, 5 máquinas de nó Zookeeper estão inativas no máximo 2 e ainda podem ser usadas porque as 3 restantes são maiores que 5/2.
Por que é melhor ter um número ímpar de nós?
Isso é para economizar recursos sob a condição do número máximo de servidores tolerantes a falhas.
Por exemplo, quando a tolerância a falhas máxima é 2, o número correspondente de serviços do Zookeeper, o número ímpar é 5 e o número par é 6, ou seja, quando há 6 serviços do Zookeeper, no máximo 2 serviços podem estar inativos.
Portanto, do ponto de vista da conservação de recursos, não há necessidade de implantar 6 (mesmo) nós de serviço Zookeeper.
O cluster Zookeeper tem esse recurso: enquanto mais da metade das máquinas do cluster estiverem funcionando normalmente, todo o cluster estará disponível para o mundo externo.
Ou seja, se houver dois nós do Zookeeper, desde que um nó do Zookeeper esteja morto, o serviço do Zookeeper não pode ser usado. Como 1 não é mais da metade, a tolerância de morte de 2 Zookeepers é 0.
Da mesma forma, se houver 3 Zookeepers, um deles está morto e 2 deles são normais, o que é mais da metade do tempo, então a tolerância de 3 Zookeepers é 1.
Da mesma forma, você também pode enumerar mais alguns: 2-> 0; 3-> 1; 4-> 1; 5-> 2; 6-> 2. Uma regra será encontrada. As tolerâncias de 2n e 2n -1 são iguais., Ambos são n-1, então, para ser mais eficiente, por que adicionar um Zookeeper desnecessário.
Portanto, com base no acima, pode-se concluir que, do ponto de vista da economia de recursos, é melhor implantar um número ímpar de nós no cluster Zookeeper!
2. Descrição do cenário de "cérebro dividido" no cluster Zookeeper
Para um cluster, se você deseja melhorar a disponibilidade do cluster, geralmente adota uma implantação de sala de vários computadores. Por exemplo, há um cluster composto de 6 zkServers e implantado em duas salas de computador:
figura 1
Em circunstâncias normais, este cluster terá apenas um Líder, portanto, se a rede entre as salas de computador for interrompida, os zkServers nas duas salas de computador ainda podem se comunicar entre si. Se o mecanismo da metade não for considerado , um líder será selecionado em cada sala de informática.
Figura 2
Isso equivale ao agrupamento original sendo dividido em dois agrupamentos, e dois "cérebros" aparecem. Este é o fenômeno denominado "cérebro dividido".
Em relação a esta situação, pode-se realmente ver que um cluster unificado originalmente fornecia serviços para o mundo exterior, mas agora se tornou dois clusters que fornecem serviços para o mundo exterior ao mesmo tempo. Se depois de um tempo, a rede desconectada é repentinamente conectado, então, neste ponto, haverá um problema. Ambos os clusters acabaram de fornecer serviços para o mundo externo, como mesclar dados, como resolver conflitos de dados e assim por diante.
Ao explicar o cenário do cérebro dividido, um dos pré-requisitos é que o mecanismo da metade não seja considerado, então, na verdade, o problema do cérebro dividido não ocorrerá facilmente no cluster do Zookeeper. A razão está no mecanismo da metade .
Mecanismo de metade do Zookeeper: No processo de eleição do líder, se um zkServer obtiver mais da metade dos votos, este zkServer pode se tornar um líder.
Um exemplo simples: se houver 5 zkServers no cluster, metade = 5/2 = 2, ou seja, no processo de eleição do líder, pelo menos três zkServers devem votar no mesmo zkServer para atender ao mecanismo da metade, Para selecionar um líder.
Então, por que deve haver uma verificação de mais da metade do mecanismo no processo de eleição do Zookeeper?
Porque, dessa forma, um líder pode ser eleito sem esperar que todos os zkServers votem no mesmo zkServer. Isso é mais rápido, por isso é chamado de algoritmo de eleição de líder rápida.
Por que maior do que no Zookeeper mais da metade do mecanismo, em vez de maior ou igual a?
Isso está relacionado ao problema do cérebro dividido. Por exemplo, voltando à cena em que o problema de divisão do cérebro ocorreu acima (conforme mostrado na Figura 1 acima):
Quando a rede no meio da sala de informática for desconectada, os três servidores na sala de informática 1 conduzirão as eleições de líderes, mas, neste momento, a condição de mais da metade do mecanismo é "o número de nós> 3" , o que significa que pelo menos 4 zkServers podem ser selecionados para selecionar um líder.
Portanto, ele não pode selecionar um líder para a sala de computadores 1 e também não pode selecionar um líder para a sala de computadores 2. Nesse caso, depois que a rede de toda a sala de colisão do cluster for desconectada, o cluster inteiro não terá líder.
E se a condição para mais da metade do mecanismo for "número de nós> = 3", tanto a sala de computadores 1 quanto a sala de computadores 2 selecionarão um líder, o que causará uma divisão do cérebro. Isso pode explicar por que mais da metade do mecanismo é maior ou igual a, o objetivo é evitar a divisão do cérebro.
Se assumirmos que agora temos apenas 5 máquinas, e também as estamos implantando em duas salas de informática:
imagem 3
Neste momento, a condição para mais da metade do mecanismo é “número de nós> 2”, ou seja, são necessários pelo menos 3 servidores para selecionar um líder.
Nesse momento, a rede da sala de equipamentos é desconectada, o que não tem efeito na sala de informática 1, e o líder continua sendo o líder; para a sala de informática 2, o líder não pode ser selecionado, havendo apenas um líder em todo cluster neste momento.
Portanto, conclui-se que com mais da metade do mecanismo, para um cluster do Zookeeper, não há líder ou apenas um líder, de modo que o Zookeeper também pode evitar o problema de divisão do cérebro.
Três, processamento do problema de "cérebro dividido" do cluster Zookeeper
1. O que é cérebro dividido?
Simplificando, Split-Brain é, por exemplo, quando há dois nós em seu cluster, todos eles sabem que um mestre precisa ser eleito neste cluster. Então, quando não houver nenhum problema com a comunicação entre os dois, um consenso será alcançado e um deles será selecionado como mestre.
Mas se houver um problema de comunicação entre eles, os dois nós sentirão que não há mestre agora, então cada um se elege como mestre, então haverá dois mestres no cluster.
Para o Zookeeper, há uma questão muito importante, que se baseia em que tipo de situação para julgar que um nó está morto e inativo? Em um sistema distribuído, todos eles são julgados pelo monitor, mas também é difícil para o monitor determinar o status de outros nós. A única maneira confiável é a pulsação, então o Zookeeper também usa a pulsação para julgar se o cliente ainda está vivo.
Usar o ZooKeeper para fazer o Leader HA é basicamente da mesma maneira:
-
Cada nó tenta registrar um nó temporário que simboliza o líder, e outros nós que não conseguem se registrar tornam-se seguidores e monitorar os nós temporários criados pelo líder através do mecanismo de observação (descrito aqui);
-
O Zookeeper usa o mecanismo de pulsação interno para determinar o estado do líder. Quando o líder sofre um acidente, o Zookeeper pode aprender rapidamente e notificar outros seguidores, e outras flores responderão mais tarde, completando assim uma troca. Este modo também é um modo mais geral, e a maioria deles são basicamente implementados dessa forma.
Mas há um problema muito sério. Deixar de perceber fará com que o sistema se divida o cérebro em um curto período de tempo. Porque o tempo limite de pulsação pode ser o líder está inativo, mas também pode ser um problema com a rede entre os nós do Zookeeper, levando à suspensão do líder.
O líder não está realmente morto, mas um problema de rede com o ZooKeeper fez com que o Zookeeper pensasse que estava fora do ar e notificasse outros nós para trocar, de modo que um dos seguidores se tornasse o líder.
No entanto, o líder original não morreu. Neste momento, o cliente também recebe a mensagem de troca de líder e ainda haverá alguns atrasos. A comunicação do Zookeeper requer uma notificação uma por uma.
Neste momento, todo o sistema está um caos.É bem possível que alguns clientes tenham sido notificados para se conectar ao novo líder, e alguns clientes ainda estejam conectados ao antigo líder.
Se houver dois clientes que precisam atualizar os mesmos dados do Líder ao mesmo tempo, e esses dois clientes estiverem conectados ao antigo e ao novo Líder no momento, problemas sérios ocorrerão.
Aqui está um pequeno resumo:
-
Fingir morte: O líder é considerado morto devido a um tempo limite de pulsação (causado por razões de rede), mas na verdade o líder ainda está vivo;
-
Cérebro dividido: devido à animação suspensa, uma nova eleição de líder será iniciada e um novo líder será eleito, mas a rede do antigo líder está conectada novamente, resultando no aparecimento de dois líderes, alguns clientes se conectam ao antigo líder e alguns clientes Em seguida, conecte-se ao novo líder.
2. O que causa a divisão do cérebro do Zookeeper?
A principal razão é que o cluster Zookeeper e o cliente Zookeeper julgam que o tempo limite não pode ser completamente sincronizado, o que significa que pode ser um após o outro. Se o cluster for descoberto antes do cliente, a situação acima ocorrerá.
Ao mesmo tempo, após descobrir e alternar, notifique cada cliente sobre a ordem de velocidade. Geralmente, a probabilidade desta situação é muito pequena. Requer que o nó Líder seja desconectado da rede de cluster Zookeeper, mas não há problema com a rede entre outras funções de cluster. As condições acima devem ser atendidas, mas uma vez que isso ocorre, isso vai causar consequências muito graves. Os dados são inconsistentes.
3. Como o Zookeeper resolve o problema do "cérebro dividido"?
Para resolver o problema do cérebro dividido, geralmente existem os seguintes métodos:
-
Método Quorums (Quorum): Por exemplo, em um cluster de 3 nós, Quorums = 2, o que significa que o cluster pode tolerar a falha de 1 nó, neste momento, um lead pode ser eleito e o cluster ainda está disponível. Por exemplo, para um cluster de 4 nós, seus quóruns = 3 e os quóruns devem exceder 3, o que é equivalente à tolerância do cluster ainda é 1. Se 2 nós falharem, o cluster inteiro ainda é inválido. Este é o método padrão usado pelo Zookeeper para evitar a "divisão do cérebro" ;
-
Método de comunicação redundante (comunicação redundante): uma variedade de métodos de comunicação são usados no cluster para evitar que a falha de um método de comunicação faça com que os nós no cluster falhem na comunicação.
-
Método de esgrima (recurso compartilhado): Por exemplo, se você pode ver o recurso compartilhado, significa que você está no cluster. O líder que pode obter o bloqueio do recurso compartilhado é o líder. Se você não pode ver o recurso compartilhado recurso, você não está no cluster.
-
Mecanismo de arbitragem;
-
Inicie o modo de bloqueio de disco.
Na verdade, é muito simples evitar a situação de "cérebro dividido" do Zookeeper. Quando o nó seguidor é alternado, não é para alternar imediatamente após verificar se o nó líder antigo tem um problema, mas para dormir por um período de tempo suficiente para garantir que o antigo líder foi notificado sobre a mudança e fazer o trabalho de limpeza de desligamento relacionado e, em seguida, registrar-se como mestre pode evitar esse tipo de problema.
Este tempo de sono é geralmente definido como o tempo limite definido pelo Zookeeper. No entanto, o sistema pode estar indisponível durante este período, mas vale a pena em relação às consequências de dados inconsistentes.
1) O ZooKeeper usa quorums por padrão para evitar o fenômeno de "divisão do cérebro"
Ou seja, apenas mais da metade dos nós do cluster podem votar para eleger um líder.
Dessa forma, pode-se garantir a singularidade do líder, ou o único líder é eleito ou a eleição fracassa. A função dos quóruns no zookeeper é a seguinte:
-
O número mínimo de nós no cluster é usado para eleger o Líder para garantir que o cluster esteja disponível;
-
Notifique o cliente de que o número mínimo de nós no cluster salvou os dados antes que eles fossem salvos com segurança. Uma vez que esses nós salvaram os dados, o cliente será notificado de que eles foram salvos com segurança e pode continuar outras tarefas. Os nós restantes no cluster eventualmente também salvarão os dados.
Suponha que um líder suspende a animação e o restante dos seguidores elege um novo líder. Neste momento, o antigo líder é ressuscitado e ainda se considera um líder.Neste momento, também será rejeitado quando enviar solicitações de escrita para outros seguidores.
Porque toda vez que um novo líder é gerado, um rótulo de época (identificando a regra atual desse líder) é gerado. Essa época é incrementada. Se os seguidores confirmarem a existência do novo líder e conhecerem sua época, eles rejeitarão a época que é menos do que o líder atual. Todas as solicitações de época.
Existe algum seguidor que não sabe da existência do novo Líder? É possível, mas certamente não a maioria, caso contrário, um novo líder não pode ser produzido. A escrita do Zookeeper também segue o mecanismo de quorum, portanto, a escrita que não recebe a maior parte do apoio é inválida. Mesmo que o antigo líder se considere o líder, ainda assim não surtirá efeito.
Além de usar o método Quorums padrão acima para evitar "divisão cerebral", o Zookeeper também pode usar as seguintes medidas preventivas:
2) Adicionar linhas de batimento cardíaco redundantes, como linhas duplas, para minimizar a chance de "divisão do cérebro"
3) Habilitar bloqueio de disco
A parte servidora bloqueia o disco compartilhado e, quando o "cérebro dividido" ocorre, a outra parte "não pode pegar" completamente os recursos do disco compartilhado. Mas há um grande problema ao usar um disco de bloqueio: se a parte que está ocupando o disco compartilhado não "desbloquear" ativamente o disco compartilhado, a outra parte nunca obterá o disco compartilhado.
Na realidade, se o nó de serviço travar ou travar repentinamente, é impossível executar o comando de desbloqueio. O nó de backup não pode controlar recursos compartilhados e serviços de aplicativo. Então, alguém projetou uma fechadura "inteligente" no HA. Ou seja, o servidor só ativa o bloqueio de disco quando descobre que a linha de pulsação está totalmente desconectada (sem saber da extremidade oposta). Geralmente não está bloqueado.
4) Configure um mecanismo de arbitragem
Por exemplo, defina o IP de referência (como o IP do gateway). Quando a linha de pulsação estiver completamente desconectada, ambos os nós farão ping no IP de referência respectivamente. Se falhar, indica que o ponto de interrupção está na extremidade local, não apenas " heartbeat ", mas também" serviço "externo Se o link de rede local for interrompido, mesmo se o serviço do aplicativo for iniciado (ou continuado), é inútil, então tome a iniciativa de abandonar a competição e deixe o fim que pode pingar a referência IP para iniciar o serviço.
É mais seguro. A parte que não consegue fazer o ping do IP de referência simplesmente se reinicia para liberar completamente os recursos compartilhados que ainda podem estar ocupados.