По очевидным причинам лучшая практика при построении кластеров, требующих распределенного консенсуса, - использовать 3, 5 или другое количество узлов, у которых есть разрешение конфликтов.
Однако иногда у одного есть два физических устройства, и он хочет их объединить в кластер. Один из способов повысить доступность, чем отсутствие кластеризации, в этих случаях - это два и дать одной из этих систем два голоса. Один из способов сделать это с помощью Zookeeper - настроить иерархический кворум и дать одному из узлов два голоса:
# 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
В исходном случае, когда каждый узел имеет один голос, если какой-либо узел отказал, то кворум не может быть достигнут. В этом случае узел, имеющий только один голос, может выйти из строя, не обрушив с собой другого. Таким образом, мы успешно избежали того, чтобы второй узел заставил нас менее надежный чем мы были, когда вообще не были кластеризованы - и для планового обслуживания, когда оба узла присутствуют в кластере, мы можем обновить конфигурацию с новым набором весов, чтобы позволить группе 1, но не группе 2, отключиться без потери кворума.
... Итак, вопрос: как этого можно достичь с помощью etcd, а не zookeeper? Нужно ли мне на самом деле запускать две копии etcd на узле 1 (и, если мы хотим передать это дополнительное голосование узлу 2, чтобы разрешить удаление узла 1 из кластера, вместо этого разверните там вторую копию и спустите второй экземпляр на узле-1)? Если да, можно ли это сделать без накладных расходов на синхронизацию данных с этим экземпляром (поскольку его единственная цель - действовать в качестве наблюдающего избирателя)?