Сплит
Сплит системы это ситуация, когда каждая из частей кластера (в случае, если кластер состоит из двух частей):
- теряет связь с другой частью;
- считает, что другая половина кластера не доступна;
- начинает работать, как будто второй половины кластера нет.
В результате создается ситуация, что каждая часть кластера работает самостоятельно друг от друга.
Виды сплитов
Виды сплитов системы:
- Полный сплит системы - сплит, при котором все ноды одной половины кластера перестают "видеть" спаренные ноды из другой половины кластера.
- Сплит определенных нод кластера - сплит, при котором только часть нод одной половины кластера перестает "видеть" спаренные ноды из другой половины кластера.
- Сплит данных - сплит, при котором только данные на одной половине кластера "разошлись" с данными из другой половины кластера. При этом ноды разных частей кластера "видят" друг друга.
Сплит отличается от аварийного отключения части нод кластера тем, что при аварийном отключении аварийные ноды отключаются и не обслуживают нагрузку, которая полностью переводится на оставшиеся в работе ноды кластера, в то время как при сплите ноды считают себя активными и работоспособными, но "не видят" соседние кластера.
Основной причиной сплита системы является некорректная работа сети передачи данных между элементами кластера, а также процессов на нодах, которая приводит к тому, что нода не успевает отрабатывать кластерный обмен за заданное время. Кластер поддерживается в консистентном состоянии за счет постоянного обмена пакетами информации между элементами кластера, при этом обмен является интенсивным и должен проходить за определенное время. Если возникают проблемы с доставкой пакетов, а также в случае неспособности ноды отправить ответные сообщения в рамках кластерного обмена - происходит сплит. Ноды считают, что их соседние ноды недоступны и каждая начинает работать самостоятельно друг от друга.
Важными действиями по обеспечению надежной работы кластера является обеспечение гарантированной надежной передачи данных между нодами и обеспечение приоритета операциям по обработке пакетов синхронизации кластера.
Для этого предпринимают следующие действия:
- использование стекируемых коммутаторов (дублирование) для резервирования инфраструктуры сети передачи данных;
- резервирование физических подключений к сети передачи данных - 2/3/4 и более физических подключений от сервера в стек коммутаторов;
- объединение нескольких Ethernet-интерфейсов в один логический Bond-интерфейс, который с использованием протокола LACP позволяет штатно отрабатывать ситуации отключения части Ethernet-каналов;
- повышение приоритетов процессам, обрабатывающим трафик синхронизации кластера.
Последствие сплита
Если в системе, где присутствует сплит, выполняются команды на изменение конфигурации или состояния элементов со стороны оператора или со стороны кластеров системы ECSS-10 (как правило адаптеров), эта информация будет обработана и сохранена только на одной из нод, на которую эта команда поступила. Проблема заключается в том, что команды поступают в общую очередь команд, из которой ноды выполняют команды, поэтому часть изменений будет на одной ноде, часть на другой.
В автоматическом режиме система не может принять решение, какую из нод нужно оставить активной, а какую необходимо исключить из работы и перезагрузить. Поэтому данная процедура выполняется оператором. После перезагрузки вновь запущенная нода загрузит конфигурацию из данных кластера (с активной ноды).
Диагностика сплита
Проявление сплита:
- В системе возникают следующие предупреждения:
- Inconsistent database with node <NODE_NAME> - данное предупреждение генерируется в случае, если база данных mnesia перешла в неконсистентное состояние.
- Node <NODE_NAME> of "<CLUSTER_NAME>" cluster is down - данное предупреждение генерируется в случае, если определенная нода пропала из кластера.
- Запрос списка нод в консоли управления выдает разные результаты от команды к команде.
- Команда на изменение конфигурации выполняется, но при просмотре настроек на разных нодах конфигурация отличается.
- Вызов на один и тот же номер может как проходить, так и не проходить без дополнительных внешних воздействий (предупреждение о недоступности нод должны присутствовать).
Пример
Предупреждения во время сплита на сети:
----------------------------------------------------------------------------------------------------------------------------------------- | Date |Severity| Location |Domain| Cause | Class | Instance | Message | |--------------+--------+---------------+------+---------------+---------------+---------------+----------------------------------------| |02.09 08:52:59|major |megaco1@ecss1 | |outOfService |ecss::oasys::mn|megaco1@ecss1 |Mnesia down on the node megaco1@ecss2. | | | | | | |esia | | | |02.09 08:52:59|major |ds@ecss1 | |outOfService |ecss::oasys::mn|ds@ecss1 |Mnesia down on the node ds@ecss2. | | | | | | |esia | | | |02.09 08:52:59|major |megaco1@ecss1 | |outOfService |ecss::cluster::|sip1@ecss2 |Node sip1@ecss2 of "sip1" cluster is dow| | | | | | |node | |n | |02.09 08:52:59|major |ds@ecss1 | |outOfService |ecss::cluster::|ds@ecss2 |Node ds@ecss2 of "ds" cluster is down | | | | | | |node | | | |02.09 08:53:00|major |md1@ecss1 | |outOfService |ecss::cluster::|core1@ecss2 |Node core1@ecss2 of "core1" cluster is d| | | | | | |node | |own | |02.09 08:53:00|major |sip1@ecss1 | |outOfService |ecss::cluster::|md1@ecss2 |Node md1@ecss2 of "md1" cluster is down | | | | | | |node | | | |02.09 08:53:06|major |megaco1@ecss1 | |outOfService |ecss::cluster::|megaco1@ecss2 |Node megaco1@ecss2 of "megaco1" cluster | | | | | | |node | |is down | |02.09 08:53:06|major |md1@ecss1 | |outOfService |ecss::cluster::|mycelium1@ecss2|Node mycelium1@ecss2 of "mycelium-myceli| | | | | | |node | |um12" cluster is down | |02.09 08:54:06|critical|md1@ecss1 | |outOfService |ecss::oasys::mn|md1@ecss1 |Inconsistent database with node md1@ecss| | | | | | |esia | |2. | -----------------------------------------------------------------------------------------------------------------------------------------
Решение:
Необходимо убедиться, что это действительно сплит. Для этого нужно подключиться к командной консоли CLI и выполнить команду
/node/nodes-info nodes
:node/nodes-info ┌───────────────┬───────────────────────────────┬─────────────────────┐ │ Node │ Erlang │ Mnesia │ ├───────────────┼───────────────────────────────┼─────────────────────┤ │core1@ecss1 │core1@ecss1,core1@ecss2 │not running │ │core1@ecss2 │core1@ecss1,core1@ecss2 │not running │ │ds1@ecss1 │ds1@ecss1,ds1@ecss2 │ds1@ecss1,ds1@ecss2 │ │ds1@ecss2 │ds1@ecss1,ds1@ecss2 │ds1@ecss1,ds1@ecss2 │ │md1@ecss1 │md1@ecss1,md1@ecss2 │md1@ecss1,md1@ecss2 │ │md1@ecss2 │md1@ecss1,md1@ecss2 │md1@ecss1,md1@ecss2 │ │mycelium1@ecss1│mycelium1@ecss1,mycelium1@ecss2│not running │ │mycelium1@ecss2│mycelium1@ecss1,mycelium1@ecss2│not running │ │sip1@ecss1 │sip1@ecss1,sip1@ecss2 │sip1@ecss1,sip1@ecss2│ │sip1@ecss2 │sip1@ecss1,sip1@ecss2 │sip1@ecss1,sip1@ecss2│ └───────────────┴───────────────────────────────┴─────────────────────┘
В приведенной таблице отображается полная информация о состоянии нод:
- количество нод, запущенных в системе;
- "видят" ли ноды кластера друг друга (Erlang);
- есть ли сплит базы данных (Mnesia).
В этом примере сплита нет. Все ноды "видят" друг друга. Сплита БД нет.
Mycelium и core не хранят в БД никакой информации, поэтому их статус — "not running".
Пример сплита:
Все ноды, кроме SIP-адаптера, находятся в сплите и "не видят" соседних нод.
Нужно перезапустить ноды.
Для того чтобы перезапустить ноды необходимо в консоли Linux выполнить командуsudo systemctl restart <RELEASE_NAME>
для каждой ноды, где <RELEASE_NAME> - имя останавливаемой подсистемы.Пример перезапуска подсистемы mycelium:
sudo systemctl restart ecss-mycelium.service
Для упрощения этого процесса можно перезапустить все подсистемы одной командой
sudo systemctl restart ecss.service
.Необходимо убедится, что сплит отсутствует. Для этого нужно подключиться к командной консоли CLI и выполнить команду
/node/nodes-info nodes
.