Всем привет! На связи АЭРОДИСК!

В этой статье мы снова хотим затронуть тему метрокластера. Сегодня мы раскроем подробнее некоторые технические аспекты, расскажем, как менялись архитектурные подходы к реализации логики этого сложного функционала и чем были обоснованы эти изменения, а также обозначим, в каком направлении движемся сейчас.  Послушать про это и позадавать вопросы в режиме онлайн можно будет на вебинаре "Около ИТ", который пройдёт 5 сентября 2023 г. в 15:00 – Регистрируйтесь по ссылке.

Вспомним матчасть

Метрокластер – достаточно трудоемкий функционал, основанный на возможностях удаленной блочной репликации и механизмах взаимодействия узлов по протоколу iSCSI. Основными преимуществами являются автоматизация и надежность – метрокластер предназначен не только для автоматической обработки failover’а между площадками с СХД, но и для предотвращения возможных конфликтов и коллизий. Давайте вспомним верхнеуровневую модель построения метрокластера.

Система основана на вычислительной сети, состоящей из трех компонентов: ЦОД с СХД-1, ЦОД с СХД2, отдельный узел под названием Арбитр.

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

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

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

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

Несколько рабочих кейсов

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

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

Кто первый встал, того и тапки

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

В идеальном мире всё работает идеально. Проблемы начинаются тогда, когда в дело вступают внешние условия. Например, сетевое соединение между узлом Primary на СХД1 и узлом Secondary на СХД2 пропадает, а в это время, как назло, происходит отказ одного из контроллеров СХД2, на котором активен этот узел репликации. Дисковая группа меняет владельца, происходит автоматическая обработка failover’а между контроллерами СХД, а простыми словами – аварийный переезд группы.

Таким образом, в лучшем случае получим два узла Primary, вероятно проблемы с консистентностью данных на узлах и split-brain в случае активного трафика. А если используется метрокластер, возможна даже коллизия IP-адресов в сети.

Уговор дороже денег

Как полностью исключить возможность появления данной ситуации? Конечно, если используется метрокластер, можно спросить Арбитр. Но если действительно нестабильна сеть и связь СХД2 с Арбитром временно отсутствует? К тому же, хотелось бы такую же гарантию получить и при использовании функционала удаленной репликации без метрокластера.

Каждый узел репликации имеет уникальный идентификатор, а также хранит у себя идентификатор узла Primary. Идентификаторы узлов (node_id) генерируются при создании репликационной связи, а при ручном переключении из Secondary в Primary идентификаторы Primary (primary_id) меняются на обоих узлах.

Так как же мы можем быть уверены, что никто наши тапки не займет раньше времени? Самое время научиться договариваться! Конечно, договориться мы сможем только в том случае, если получим ответ с удаленного узла, запросив у него primary_id из его конфигурации. К примеру, узлы репликации A и B включаются одновременно, узел A займет позицию Primary только в случае выполнения следующего равенства. В противном случае ситуация потребует ручного вмешательства, и пользователь должен будет сам поднять актуальную площадку.

А что с Арбитром?

Несомненно, залог успеха лежит в богатстве функционала Арбитра. Чем он умнее, тем больше кейсов (в том числе непредсказуемых и пограничных) возможно обработать в автоматическом режиме.

Первым делом решили добавить веб-интерфейс. Встречает нас здесь системная панель, где в режиме реального времени отображается состояние обеих СХД в кластере.

На первых порах никуда и без системного журнала, решили мы. Сюда записываются все важные системные сообщения, например, о недоступности контроллеров СХД, о передаче аварийного сигнала failover с Арбитра на СХД.

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

Основная задача Арбитра – по-прежнему мониторинг доступности управляющих интерфейсов СХД в кластере. В случае недоступности первой площадки, аварийный сигнал будет отправлен на вторую. Узлы репликации будут подняты в Primary в автоматическом режиме с временным интервалом от 10 до 60 секунд, в зависимости от количества и объёма ресурсов площадки.

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

Когда репликации не переключаются в Primary автоматически?

Повторимся, метрокластер - технически сложная система, в работе которой задействовано много различных технологий и сервисов. Допустим, Арбитр потерял СХД1 и отправил сигнал бедствия на СХД2, но мы всё равно должны убедиться, что вызов не ложный :)

СХД2 переключит узлы репликации в Primary и поднимет VIP’ы метрокластера только в случае выполнения следующих условий:

1. Управляющие интерфейсы СХД1 недоступны с СХД2.

2. Репликации на СХД2 находятся в состоянии «разрыв соединения».

Когда репликации автоматически переключаются в Secondary?

У нас по-прежнему стоит задача защититься от двойного Primary и split-brain. Представим, что со стороны СХД1 потеряна связь с СХД2 и Арбитром. Узлы репликации оказываются изолированы и возникает риск автоматического переключения Арбитром на площадку с СХД2. В этом случае в течение 5 секунд все узлы репликации Primary (если таковые имеются) автоматически переключатся в Secondary.

Однако на описанном выше мы, естественно, не останавливаемся. У нас есть дорожная карта по развитию функционала метрокластера, и её реализация позволит переживать значительно большее количество сценариев отказов. Например, мы планируем отдельно мониторить все виды трафика по отдельности: СХД-Хост, СХД-СХД, управление СХД, что позволит очень гибко настраивать именно сетевое взаимодействие. Так как сейчас есть ряд ограничений при настройке сетевого взаимодействия между СХД и “внешним” миром в схеме с метрокластером.

Подводим итог

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

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

А впереди достаточно долгий, возможно тернистый, но не менее интересный путь развития и этого проекта в частности, и всей экосистемы в целом. Дальше будет интереснее.

И напоминаем, что ждем вас на нашем вебинаре "Около ИТ" 5 сентября по ссылке, на котором мы подробнее расскажем про функционал метрокластера и ответим на ваши вопросы.