Por razões óbvias, a prática recomendada na criação de clusters que exigem consenso distribuído é usar 3, 5 ou outra contagem de nós que tenha um desempatador em vigor.
Às vezes, no entanto, um tem dois dispositivos físicos e deseja agrupá-los. Uma maneira de obter melhor disponibilidade do que não ter nenhum cluster, nestes casos, é dar dois desses dois sistemas. Uma maneira de fazer isso com o Zookeeper é configurar um quorum hierárquico e dar a um dos nós dois votos:
# 2-node zookeeper configuration that allows node-2 to fail without losing quorum
# ...node-1 cannot go down without losing quorum, *unless* these weights are first
# ...reconfigured; such configuration is allowed at runtime, with no service disruption!
group.1=1
group.2=2
weight.1=2
weight.2=1
No caso original, com cada nó tendo um voto, se um dos nós falhasse, nenhum quorum poderia ser alcançado. Nesse caso, o nó com apenas um voto pode falhar sem trazer o outro para baixo. Assim, evitamos com sucesso que um segundo nó nos tornasse menos robustos do que quando não estávamos em cluster - e para manutenção planejada, quando os dois nós estão presentes no cluster, podemos atualizar a configuração com um novo conjunto de pesos para permitir que o grupo 1, mas não o grupo 2, fique offline sem perder o quorum.
... então, a pergunta: como isso pode ser alcançado usando o etcd ao invés de zookeeper? Preciso realmente executar duas cópias do etcd no nó 1 (e, se quisermos transferir esse voto extra para o nó-2 para permitir que o nó-1 seja removido do cluster, gire uma segunda cópia para lá e desative a opção segunda cópia no nó-1)? Em caso afirmativo, isso pode ser feito sem a sobrecarga de ter dados sincronizados com essa instância (já que seu único objetivo é agir como um eleitor observador)?
Tags etcd