Как Консул восстанавливается после потери кворума при изменении IP-адресов узлов? - PullRequest
Новая
       8

Как Консул восстанавливается после потери кворума при изменении IP-адресов узлов?

0 голосов
/ 28 февраля 2019

Я развернул Консул сервер, используя Диаграмму Шлема , дав мне кластер из трех узлов.Я мог просмотреть IP-адреса и идентификаторы узлов: 

$ consul catalog nodes
Node             ID        Address     DC
consul-server-0  065ab1e4  10.60.1.11  dc1
consul-server-1  46eca681  10.60.0.16  dc1
consul-server-2  fb5fa37d  10.60.2.8   dc1

В качестве теста я принудительно удалил все три из этих узлов следующим образом: 

kubectl delete pods -n consul --force --grace-period=0 consul-server-0 consul-server-1 consul-server-2

Пришли три новых модуляразные IP-адреса, но одинаковые идентификаторы, присоединились к кластеру и снова достигли консенсуса: 

$ consul catalog nodes
Node             ID        Address     DC
consul-server-0  065ab1e4  10.60.1.12  dc1
consul-server-1  46eca681  10.60.2.9   dc1
consul-server-2  fb5fa37d  10.60.0.17  dc1

На что полагается Консул, чтобы справиться с этой ситуацией?Может ли он снова сформировать кворум, так как идентификаторы совпадают, а затем выяснить, изменились ли IP-адреса?Или имена узлов, которые остаются согласованными, также являются требованием для автоматического восстановления?

Я вижу сообщения журнала, такие как: 

consul: removed server with duplicate ID: 46eca681-b5d6-21e7-3df5-cf228ffdd02c

Так что, похоже, изменение IP-адреса вызывает новый узелбыть добавленным в кластер, но затем Консул решает, что его нужно удалить.Из-за этого я ожидаю, что в одной точке будет 6 узлов, из которых 3 недоступны, что приведет к потере кворума кластером и невозможности автоматического восстановления, но этого не происходит.

1 Ответ

0 голосов
/ 01 марта 2019

Мы также запускаем консул в Docker Swarm, и восстановление после сбоя не является тривиальной проблемой.Потому что не удалось серверу воссоздать в новом контейнере, очевидно, с другим IP.Консул весной много ошибок и сообщений о плоту.Но я не видел в этом серьезной проблемы.Я просто фильтрую журналы такого типа, а не преобразовываю их в долговременные индексы вasticsearch.

Мы используем следующую конфигурацию для более быстрого восстановления сервера: 

{
  "skip_leave_on_interrupt" : true,
  "leave_on_terminate" : true,
  "disable_update_check": true,
  "autopilot" : {
    "cleanup_dead_servers": true,
    "last_contact_threshold": "1s"
  }
}

Вы можете просмотреть параметры здесь

...