ELASTICSEARCH как более «изящно» осуществить репликацию через playbook ANSIBLE?

Question

[gremlintv2]

Здравствуйте,

После настройки реплики MASTER -> SLAVE на POSTGRES оказалось, что есть необходимость в создании, подобного типа репликации и для ELASTICSEARCH.
Немного погуглив узнал что ELASTICSEARCH поддерживает только кластреную мультимастер репликацию (MASTER - MASTER ELIGIBLE).

Почему мне не подходит способ через создание снэпшотов.

Но для подобия MASTER -> SLAVE на POSTGRES можно испльзовать механизм создания снэпшотов. С переодическим созданием/востановлением снэпшота через крон. Но как я понял для такой схемы необходимо:

1. создать снэпшот,
   
2. остановить ELASTICSEARCH на ноде "SLAVE" (и в этот момент он не доступен для клиента)
   
3. востановить снэпшот
   
4. запустить ELASTICSEARCH
   

Данная схема не подходит, так как необходима постоянная доступность ELASTICSEARCH для приложения.
Значит наиболее подходящим в данном случае будет способ предложеный командой ELASTIC: MASTER - MASTER ELIGIBLE

При добавлении новой ноды в кластер MASTER - MASTER ELIGIBLE - необходимо на всех существующих нодах включая мастер через ANSIBLE запустить

следующее

1. добавить в hosts и elasticsearch.yml запись нового хоста
   
2. изменить правила firewall
   
3. перезагрузить сервис elasticsearch
   

Так же есть вероятность смены IP ноды (специфика проэкта), что требует создание дополнительного плэйбука с теми же тасками.

Такие манипуляции вызывают определенные опасения:
1) Не вызовет ли это split brain если что-то пойдет "не так" (временная недоступность IP одной из нод)
2) Краш всего кластера после перезапуска ELASTICSEARCH (временная недоступность IP одной из нод)

1 )Как "предупредить" данные проблемы (см. выше)?
2) Может есть способ более "изящный"? (на мой взгяд у Postgres он более удобен не смотря на единственную точку отказа).

Нашел туториал, но вопросы те же, плюс добавился дополнительный - 3) Надежен ли tinc, что может вызвать его падение, получится ли настроить его в OPENVZ контейнере?

Answer 1

[Алексей]

Вы не правы, я на проде никогда не перезагружал ноды, после добавления новых.
Все делается налету:
В конфиге новой ноды вы прописываете все ноды, после запускаете и она заходит в кластер и начинается синкаться (лучше делать когда нагрузка на кластер минимальна, так как будет много копирования), синк будет зависит от настроек распределения шардов и реплик. Соответственно:
1. Убрать все ограничения по сети (настроить правила firewall (Добавить, поправить и тд)), если существуют
2. Запустить новую ноду, она сама зайдет в кластер и будет синкаться
3. Добавить на существующие в конфиг новую.

По поводу ваших вопросов сплит брейна, в настройках эластика есть настройка минимальное кол-во нод для работы: discovery.zen.minimum_master_nodes: кол-во
Это позволяет, например, у вас 5 нод, вы держите по 1 праймари шарду на каждой ноде и 2 реплики каждого шарда на других нодах. С настройкой discovery.zen.minimum_master_nodes: 3, вы всегда сможете вывести 2 сервера из работы (на обслуживание), при этом кластер перейдет в желтое состояние но будет отдавать данные (не так быстро правда, деградации производительности)