Устранение распространенных сценариев Split-Brain в кластере Elasticsearch

Split brain — это отказ Elasticsearch, о котором говорят, потому что это звучит драматично, но полезный вопрос более практичен: может ли более чем одна часть кластера одновременно принимать решения на уровне мастера? Современные версии Elasticsearch разработаны для предотвращения этого с помощью координации кластера на основе большинства. Более старые кластеры, особенно до версии 7.0 с неправильной настройкой discovery.zen.minimum_master_nodes, было легче неправильно сконфигурировать.

Поэтому эта статья разделяет две ситуации, которые часто путают. Истинный split brain означает, что независимые разделы могут избрать или сохранить мастера. Сбой выборов мастера означает, что кластер не может избрать мастера, потому что у него нет большинства. Первый риск — конфликтующее состояние кластера и несогласованность данных. Второй болезненен, но обычно это более безопасный режим отказа.

Как выглядит split brain

В здоровом кластере один избранный мастер управляет состоянием кластера: создание индексов, решения о распределении шардов, маппинги, членство узлов и подобные метаданные. Узлы данных могут обрабатывать чтение и запись, но кластер все равно зависит от единого представления мастера о мире.

Сценарий split-brain возникает, когда сетевые разделы или неправильные настройки обнаружения позволяют двум группам узлов вести себя так, как будто каждая группа является реальным кластером. Одна сторона может принимать записи в индекс, в то время как другая сторона принимает другие записи. Когда связь восстанавливается, Elasticsearch не может просто объединить две конфликтующие истории, как текстовый файл.

В современном Elasticsearch, если раздел не имеет большинства узлов, имеющих право быть мастером, он не должен избирать мастера. Это означает, что некоторые узлы могут стать недоступными вместо формирования конкурирующего кластера. Это поведение, которое вам нужно.

Версия имеет значение

Для Elasticsearch 6.x и старше ключевой настройкой было:

discovery.zen.minimum_master_nodes: 2

Правило было большинством узлов, имеющих право быть мастером: (N / 2) + 1, округленное вниз для целочисленного деления перед добавлением единицы. С тремя узлами, имеющими право быть мастером, установите значение 2. С пятью — 3. Установка значения 1 в трехузловом кластере делала split brain возможным.

Для Elasticsearch 7.x и новее discovery.zen.minimum_master_nodes удален. Координация кластера изменилась, и Elasticsearch управляет конфигурацией голосования. Новые кластеры все еще нуждаются в правильной начальной загрузке с помощью cluster.initial_master_nodes, но эта настройка предназначена только для первого формирования кластера. После формирования кластера удалите ее из конфигурации.

Не "исправляйте" современный кластер, добавляя старые настройки discovery.zen. Они больше не являются плоскостью управления.

Распространенные причины

Наиболее распространенным триггером является сетевой раздел между узлами, имеющими право быть мастером. В облачных терминах это может быть изменение группы безопасности, плохая таблица маршрутизации, сетевой ACL, проблема на уровне зоны или правило брандмауэра, блокирующее транспортный порт 9300. В средах с "голым железом" это может быть проблема с коммутатором, VLAN, DNS, MTU или потерей пакетов.

Другая причина — запуск слишком малого количества узлов, имеющих право быть мастером. Два узла, имеющих право быть мастером, неудобны, потому что после отказа одного нет чистого большинства. Производственный кластер обычно использует три выделенных узла, имеющих право быть мастером, или три узла со смешанными ролями в небольшом развертывании.

Третья причина — устаревшие или повторно используемые каталоги данных. Если вы клонируете виртуальные машины или повторно используете диски из старых кластеров, узлы могут нести метаданные кластера, которые вы не планировали. Это может привести к запутанным сбоям присоединения и, в худших случаях, к случайному формированию отдельного кластера.

Наконец, ручное восстановление под давлением может усугубить проблему. Перезагрузка случайных узлов, очистка путей данных или принудительное небезопасное распределение до того, как вы узнаете, какой раздел является авторитетным, может превратить восстанавливаемый инцидент в потерю данных.

Первые проверки во время инцидента

Начните с опроса каждого доступного узла о том, что он думает:

curl -s "http://NODE:9200/_cat/master?v"
curl -s "http://NODE:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://NODE:9200/_cluster/health?pretty"

Запустите их на нескольких узлах, если возможно. Если разные узлы сообщают о разных мастерах или разном членстве узлов, возможно, вы имеете дело с разделенным кластером или изолированными узлами.

Проверьте журналы на узлах, имеющих право быть мастером, на предмет сообщений о выборах, присоединениях, отключениях и сбоях публикации. Полезные поисковые термины включают master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception и handshake.

Затем проверьте транспортное соединение, а не только HTTP:

nc -vz node-1.example.internal 9300
nc -vz node-2.example.internal 9300
nc -vz node-3.example.internal 9300

Запустите эти тесты от узла к узлу. Балансировщик нагрузки или бастион, достигающий HTTP-порта 9200, мало что говорит о том, могут ли узлы Elasticsearch сформировать кластер через порт 9300.

Проверьте конфигурацию обнаружения и начальной загрузки

На Elasticsearch 7.x и новее проверьте эти настройки:

cluster.name: my-cluster
discovery.seed_hosts:
  - node-1:9300
  - node-2:9300
  - node-3:9300

Только для совершенно нового кластера:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Имена начальной загрузки должны совпадать с node.name. После формирования кластера удалите cluster.initial_master_nodes со всех узлов.

На Elasticsearch 6.x и старше проверьте:

discovery.zen.minimum_master_nodes: 2

для кластера с тремя узлами, имеющими право быть мастером. Также убедитесь, что все узлы, имеющие право быть мастером, имеют согласованные хосты обнаружения и имена кластеров.

Принципы восстановления

Если вы подозреваете истинный split brain, прекратите вносить изменения через API кластера, пока не узнаете, какая сторона является авторитетной. Самое безопасное восстановление обычно следует этому порядку:

1. Сохраните доказательства: соберите журналы, списки узлов, представления мастера и состояние индексов из каждого раздела.
2. Восстановите сетевое соединение или намеренно изолируйте плохую сторону.
3. Выберите авторитетный раздел на основе большинства, последних действительных данных и бизнес-воздействия.
4. Остановите Elasticsearch на узлах, которые не должны продолжать работу как независимый раздел.
5. Возвращайте узлы по одному и проверяйте, что они присоединяются к авторитетному кластеру.
6. Восстановите отсутствующие данные из снимков, если какая-либо история первичных шардов потеряна или несогласована.

Не удаляйте каталоги translog в качестве обычного исправления split-brain. Это опасный совет. Translog являются частью восстановления Elasticsearch. Ручное удаление файлов в пути данных может привести к потере данных и должно выполняться только с указаниями от поддержки Elastic, специфичными для версии, или после того, как вы приняли потерю и имеете план восстановления.

Если два раздела независимо принимали записи, идеального автоматического слияния может не быть. Возможно, вам потребуется восстановить из снимка, переиндексировать из исходных систем, воспроизвести журналы приложений или выбрать данные одной стороны как авторитетные.

Реалистичный пример

Представьте трехузловой кластер в трех частных подсетях. Изменение брандмауэра случайно блокирует транспортный трафик между узлом 1 и узлами 2 и 3. Узлы 2 и 3 все еще видят друг друга, поэтому они сохраняют или избирают мастера. Узел 1 не видит большинства. В современном, правильно настроенном кластере узел 1 не должен сам по себе формировать конкурирующего мастера. Клиенты, использующие узел 1, могут выйти из строя, но кластер избегает конфликтующих мастеров.

Теперь представьте старый кластер 6.x с тремя узлами, имеющими право быть мастером, и discovery.zen.minimum_master_nodes: 1. Узел 1 может избрать себя, в то время как узлы 2 и 3 избирают другого мастера. Это классический риск split-brain. Исправление заключается не только в восстановлении сети. Вам также необходимо исправить конфигурацию кворума и решить, как обрабатывать любые записи, принятые на неправильной стороне.

Предотвращение

Используйте три узла, имеющих право быть мастером, для небольших и средних кластеров. Для более крупных кластеров сделайте их выделенными мастер-узлами, чтобы нагрузка поиска и индексации не мешала координации кластера.

Держите узлы, имеющие право быть мастером, на надежных сетях с низкой потерей пакетов. Распределение узлов по зонам может помочь доступности, но только если сеть между зонами надежна и дизайн кворума все еще имеет смысл.

Отслеживайте изменения мастера. Выборы мастера во время планового обслуживания — это нормально. Частые выборы во время обычного трафика — предупреждающий знак.

Отслеживайте транспортное соединение, а не только время безотказной работы HTTP. Узел может отвечать на порту 9200 и все еще не может правильно участвовать в кластере, если транспортный трафик заблокирован.

Регулярно делайте снимки и тестируйте восстановление. Реплики не защищают вас от плохого удаления, поврежденных данных или конфликтующих записей во время серьезного инцидента.

Будьте осторожны с настройками начальной загрузки. В современных кластерах cluster.initial_master_nodes — это не повседневная настройка обнаружения. Используйте ее для создания нового кластера, затем удалите.

Лучшее восстановление split-brain — это то, которое вам никогда не понадобится: право на мастерство на основе большинства, правильные настройки обнаружения, соответствующие версии, скучные сетевые правила и проверенный план снимков.

Как отличить split brain от обычных выборов

Выборы мастера — это не автоматически split brain. Во время перекатывающегося перезапуска, сетевого флапа или отказа мастер-узла Elasticsearch может избрать нового мастера. Если кластер сохраняет одного авторитетного мастера, а старый мастер уходит в отставку, это нормальное поведение распределенной системы.

Предупреждающие признаки — разные представления от разных узлов. Если узел A сообщает о себе как о мастере, в то время как узел B сообщает об узле C как о мастере, остановитесь и расследуйте. Если две группы узлов обе принимают изменения состояния кластера, будучи отключенными, у вас гораздо более серьезная ситуация, чем кратковременные выборы.

Также следите за поведением клиентов. Клиенты, привязанные к изолированному узлу, могут видеть сбои, даже если сторона большинства здорова. Это не означает, что кластер большинства сломан. Это может означать, что ваша стратегия подключения клиентов или балансировщик нагрузки все еще отправляют трафик на узел, который не может участвовать.

Балансировщики нагрузки и маршрутизация клиентов

Транспортное обнаружение Elasticsearch — это не то же самое, что маршрутизация HTTP клиентов. Не помещайте обнаружение мастера за обычный HTTP-балансировщик нагрузки и не ожидайте, что это решит проблему членства в кластере. Узлам необходимо транспортное соединение друг с другом.

Для клиентов используйте несколько HTTP-конечных точек или балансировщик нагрузки, который быстро удаляет нездоровые узлы. Узел, потерявший своего мастера, может все еще иметь работающий процесс в течение короткого времени, но это не хорошая цель для записи. Проверки работоспособности должны быть более значимыми, чем "порт 9200 открыт".

Практическая проверка работоспособности HTTP может запрашивать состояние кластера локально и отклонять узлы, у которых нет обнаруженного мастера. Точный подход зависит от вашего клиента и инфраструктуры, но принцип прост: не продолжайте отправлять записи на изолированные узлы.

Очистка после инцидента

После того, как кластер стабилен, сравните состояние индексов, количество документов и количество источников истины на уровне приложения. Если была вероятность попадания записей на разные разделы, одного только состояния Elasticsearch недостаточно, чтобы доказать, что данные семантически корректны.

Просмотрите временную шкалу. Какой узел первым потерял связь? Какой узел был мастером до события? Продолжали ли клиенты писать? Были ли снимки актуальными? Сработали ли оповещения до того, как пользователи заметили? Эти детали определяют, нужна ли вам только сетевая настройка или план согласования данных.

Для старых кластеров запланируйте работу по версии и настройке обнаружения. Если вы все еще используете версию, которая зависит от discovery.zen.minimum_master_nodes, убедитесь, что она правильна сегодня, затем спланируйте путь обновления. Предотвращение split-brain — это не одноразовый шаг в runbook; это часть управления жизненным циклом кластера.

Изменения конфигурации, которых следует избегать во время паники

Не меняйте cluster.name, чтобы заставить узлы присоединиться. Это создает другую проблему идентичности кластера.

Не очищайте пути данных, если вы намеренно не отбрасываете локальные копии шардов узла и не подтвердили, что кластер имеет действительные копии в другом месте или доступны снимки.

Не добавляйте cluster.initial_master_nodes обратно в существующий современный кластер в качестве общего исправления перезапуска. Эта настройка предназначена для начальной загрузки, а не для повседневного обнаружения.

Не снижайте защиту типа кворума на старых кластерах для восстановления доступности. Сделать раздел меньшинства доступным для записи может показаться прогрессом, но именно так становятся возможными конфликтующие мастера.

Проектирование для неудобных доменов отказа

Три узла, имеющих право быть мастером, работают лучше всего, когда ни одно инфраструктурное событие не может удалить два из них. В трехзонном облачном регионе один узел, имеющий право быть мастером, на зону — это распространенный шаблон. В двухзонной среде размещение сложнее, потому что одна зона может содержать два голоса. Если эта большая зона выходит из строя, оставшийся единственный голос не может безопасно избрать мастера. Это не хрупкость Elasticsearch; это математика большинства.

Не решайте эту проблему, добавляя четное количество голосующих узлов, не продумав режимы отказа. Четыре узла, имеющих право быть мастером, все равно требуют большинства, и раздел два-два не может безопасно выбрать сторону. Выделенные узлы только для голосования могут помочь в некоторых конструкциях, но принцип остается тем же: кластеру необходимо надежное большинство для принятия решений о состоянии кластера.

Запишите это в примечаниях к архитектуре. Во время сбоя люди часто спрашивают, почему выживший узел или выжившая зона не могут просто продолжать обслуживать записи. Ответ должен быть ясен до инцидента: принятие записей без большинства рискует конфликтующей историей.