Проблема split-brain и слежение за кворумом

Рассматриваемый случай касается многосерверного кластера, но возможен уже в двухсерверной инсталляции. Некоторые сервисы управляют данными, хранят данные. Для этого используются распределенное объектное хранилище, либо подключение к мастер-экземпляру postgresql (при наличии потоковой репликации на рекавери-экземпляр). Необходимо сохранять целостность данных.

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

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

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

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

Эта проблема носит условное название Split-brain.

Решению этой проблемы служит концепция кворума.

Если остров содержит меньше, чем 50% + 1 сервер, то его сервисы, способные нарушить целостность, следует принудительно тушить:

На какие бы острова система не распалась, не существует двух островов размером 50% + 1 сервер.

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

И в том и в другом случае преследуется цель обеспечить сервер на одной половине при выходе второй половины из строя. Но побочным эффектом является возможный split-brain.

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

Решением может служить добавление к кластеру еще одного узла. Это может быть:

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

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

Выборы осуществляются на основании специальных порядковых значений, заданных в конфигурации для серверов, а при их отсутствии, на основании лексикографической сортировки имен серверов конфигурации. Тот кто имеет в своем составе минимальное значение, признается лидером. Для того, чтобы связаться через внешнюю сеть, для всех серверов в конфигурации может быть задан специальный URL для этой цели. Серверы обращаются по этим URL к веб-серверам (микросервисам), расположенным на этих серверах.

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

Кворум настраивается в конфигурации.

По умолчанию в автоматически формируемых конфигурациях слежение за кворумом отключено.

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

За кворумом следят:

Поскольку доменный центр в распределенной системе резервируется в режиме active-passive и следит за кворумом, то в зависимости от него оказываются и другие микросервисы, работающие с доменным деревом, но резервируемые в режиме active-active, в частности:

Поскольку все микросервисы работающие с распределенным объектным хранилищем резервируются в режиме active-active, целостность этих хранилищ не нарушается.

Поскольку mware в распределенной системе резервируется в режиме active-passive и следит за кворумом, то в зависимости от кворума оказываются:

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