Всем привет! На связи АЭРОДИСК!
В этой статье мы снова хотим затронуть тему метрокластера. Сегодня мы раскроем подробнее некоторые технические аспекты, расскажем, как менялись архитектурные подходы к реализации логики этого сложного функционала и чем были обоснованы эти изменения, а также обозначим, в каком направлении движемся сейчас. Послушать про это и позадавать вопросы в режиме онлайн можно будет на вебинаре "Около ИТ", который пройдёт 5 сентября 2023 г. в 15:00 – Регистрируйтесь по ссылке.
Вспомним матчасть
Метрокластер – достаточно трудоемкий функционал, основанный на возможностях удаленной блочной репликации и механизмах взаимодействия узлов по протоколу iSCSI. Основными преимуществами являются автоматизация и надежность – метрокластер предназначен не только для автоматической обработки failover’а между площадками с СХД, но и для предотвращения возможных конфликтов и коллизий. Давайте вспомним верхнеуровневую модель построения метрокластера.
![](https://habrastorage.org/getpro/habr/upload_files/831/e7a/1f0/831e7a1f055912b8ed4e1ab742d3b616.png)
Система основана на вычислительной сети, состоящей из трех компонентов: ЦОД с СХД-1, ЦОД с СХД2, отдельный узел под названием Арбитр.
Для понимания механики и особенностей работы метрокластера давайте попробуем пойти еще дальше и рассмотреть ключевые элементы системы хранения данных. Дисковая группа, логический том, узел репликации – терминология, которая снится разработчикам СХД по ночам – это программные сущности в нашей системе.
Дисковая группа – объединение физических дисков в одно логическое пространство с целью повышения производительности и отказоустойчивости. Логический том – слой абстракции, позволяющий распределять и управлять пространством дисковой группы. Узел репликации - программный элемент, отвечающий за передачу и синхронизацию данных между двумя логическими томами.
Так как перечисленные компоненты непосредственно связаны друг с другом, схематически их можно представить в виде пирамиды (вершина не может существовать без основания). На схеме ниже стрелкой показано направление репликации данных.
![](https://habrastorage.org/getpro/habr/upload_files/3b4/a3f/0e0/3b4a3f0e0382a95273815f3560eba197.png)
Соответственно, включение дисковой группы на контроллере влечет за собой включение логических томов, принадлежащих этой группе, и включение сконфигурированных на этих томах узлов репликации.
Несколько рабочих кейсов
Ниже мы опишем несколько сложных сценариев отказов, которые мы научились обрабатывать при последних доработках метрокластера. В таблице же предлагаем посмотреть на текущую картинку обработки отказов.
Вариант отказа |
Что с трафиком до хостов на площадке А? |
Что с трафиком до хостов на площадке Б? |
Действия метрокластера |
Отказ контроллера на площадке А с ролью Primary |
Кратковременная остановка, продолжает работать с выжившим контроллером на площадке А |
Кратковременная остановка, продолжает работать с выжившим контроллером на площадке А |
Переключение группы на СХД на площадке А на выживший контроллер |
Отказ контроллера на площадке А не владеющего группой |
Штатная работа |
Штатная работа |
Никаких действий |
Отказ контроллера на площадке Б с ролью Secondary |
Штатная работа |
Штатная работа |
Переключение группы на СХД на площадке Б на выживший контроллер |
Отказ контроллера на площадке Б не владеющего группой |
Штатная работа |
Штатная работа |
Никаких действий |
Отказ репликационной связи между СХД |
Штатная работа |
Штатная работа |
Никаких действий |
Отказ связи между арбитром и СХД на площадке А с ролью Primary |
Штатная работа |
Штатная работа |
Проверка доступности СХД на площадке А, через СХД на площадке Б |
Отказ связи между арбитром и СХД на площадке Б с ролью Secondary |
Штатная работа |
Штатная работа |
Проверка доступности СХД на площадке Б, через СХД на площадке А |
Отказ СХД на площадке А целиком |
Кратковременная остановка, нагрузка переводится на СХД на площадке Б |
Кратковременная остановка, нагрузка переводится на СХД на площадке Б |
Перевод репликационных связей с роли Secondary на роль Primary на площадке Б |
Отказ СХД на площадке Б целиком |
Штатная работа |
Штатная работа |
Никаких действий |
А теперь поговорим о достаточно редком кейсе, который тоже ни в коем случае нельзя исключать. Что, если узлы репликации включаются одновременно? А как быть, если узлы репликации включаются последовательно, но при этом по каким-либо причинам изолированы и не видят друг друга. Как корректно установить роли в автоматическом режиме, не отдавая полностью это решение на усмотрение Арбитра?
Кто первый встал, того и тапки
Алгоритм данного подхода заключается в том, что при включении узел репликации пытается обнаружить соседа. Если сосед обнаружен и имеет статус Primary, то узел становится Secondary и начинает реплицировать данные на себя. Если же конкурентов в сети не видно, то самое время стартовать в Primary и брать на себя всю ответственность за ситуацию.
В идеальном мире всё работает идеально. Проблемы начинаются тогда, когда в дело вступают внешние условия. Например, сетевое соединение между узлом Primary на СХД1 и узлом Secondary на СХД2 пропадает, а в это время, как назло, происходит отказ одного из контроллеров СХД2, на котором активен этот узел репликации. Дисковая группа меняет владельца, происходит автоматическая обработка failover’а между контроллерами СХД, а простыми словами – аварийный переезд группы.
![](https://habrastorage.org/getpro/habr/upload_files/ee7/5bf/14d/ee75bf14de2c4723505812c6378121d3.png)
Таким образом, в лучшем случае получим два узла Primary, вероятно проблемы с консистентностью данных на узлах и split-brain в случае активного трафика. А если используется метрокластер, возможна даже коллизия IP-адресов в сети.
Уговор дороже денег
Как полностью исключить возможность появления данной ситуации? Конечно, если используется метрокластер, можно спросить Арбитр. Но если действительно нестабильна сеть и связь СХД2 с Арбитром временно отсутствует? К тому же, хотелось бы такую же гарантию получить и при использовании функционала удаленной репликации без метрокластера.
Каждый узел репликации имеет уникальный идентификатор, а также хранит у себя идентификатор узла Primary. Идентификаторы узлов (node_id) генерируются при создании репликационной связи, а при ручном переключении из Secondary в Primary идентификаторы Primary (primary_id) меняются на обоих узлах.
Так как же мы можем быть уверены, что никто наши тапки не займет раньше времени? Самое время научиться договариваться! Конечно, договориться мы сможем только в том случае, если получим ответ с удаленного узла, запросив у него primary_id из его конфигурации. К примеру, узлы репликации A и B включаются одновременно, узел A займет позицию Primary только в случае выполнения следующего равенства. В противном случае ситуация потребует ручного вмешательства, и пользователь должен будет сам поднять актуальную площадку.
![](https://habrastorage.org/getpro/habr/upload_files/1b4/921/3e7/1b49213e72398380398fe2eab4766ed8.png)
А что с Арбитром?
Несомненно, залог успеха лежит в богатстве функционала Арбитра. Чем он умнее, тем больше кейсов (в том числе непредсказуемых и пограничных) возможно обработать в автоматическом режиме.
Первым делом решили добавить веб-интерфейс. Встречает нас здесь системная панель, где в режиме реального времени отображается состояние обеих СХД в кластере.
![](https://habrastorage.org/getpro/habr/upload_files/a49/f26/a14/a49f26a1436b488856e1ec391ec7c885.png)
![](https://habrastorage.org/getpro/habr/upload_files/1c9/cf9/3b5/1c9cf93b562d34d90068c5183ab3be9c.png)
На первых порах никуда и без системного журнала, решили мы. Сюда записываются все важные системные сообщения, например, о недоступности контроллеров СХД, о передаче аварийного сигнала failover с Арбитра на СХД.
![](https://habrastorage.org/getpro/habr/upload_files/bce/004/877/bce0048770cf1acf0556dc8a3c796796.png)
Ну и, конечно же, теперь доступна долгожданная улучшенная система обновления, которая показывает текущую версионность ПО и помогает своевременно обновлять Арбитр.
![](https://habrastorage.org/getpro/habr/upload_files/005/681/1d2/0056811d2eb83da6fb0ef8246866601a.png)
Основная задача Арбитра – по-прежнему мониторинг доступности управляющих интерфейсов СХД в кластере. В случае недоступности первой площадки, аварийный сигнал будет отправлен на вторую. Узлы репликации будут подняты в Primary в автоматическом режиме с временным интервалом от 10 до 60 секунд, в зависимости от количества и объёма ресурсов площадки.
В основе работы мониторинга лежит протокол ICMP (ping и проверка доступности определенных портов). В основе работы управляющих сигналов лежит технология SSH, проверенная временем. Дело в том, что сама по себе СХД - монструозная система, в которой используется многообразие технологий и протоколов ввода-вывода. По этой причине не всегда приходится рассчитывать и ориентироваться на состояние веб-сервисов. Ведь нарушение функционирования веб-сервисов совсем не означает, что хостами потеряны блочный или файловый доступы :)
Когда репликации не переключаются в Primary автоматически?
Повторимся, метрокластер - технически сложная система, в работе которой задействовано много различных технологий и сервисов. Допустим, Арбитр потерял СХД1 и отправил сигнал бедствия на СХД2, но мы всё равно должны убедиться, что вызов не ложный :)
СХД2 переключит узлы репликации в Primary и поднимет VIP’ы метрокластера только в случае выполнения следующих условий:
Управляющие интерфейсы СХД1 недоступны с СХД2.
Репликации на СХД2 находятся в состоянии «разрыв соединения».
Когда репликации автоматически переключаются в Secondary?
У нас по-прежнему стоит задача защититься от двойного Primary и split-brain. Представим, что со стороны СХД1 потеряна связь с СХД2 и Арбитром. Узлы репликации оказываются изолированы и возникает риск автоматического переключения Арбитром на площадку с СХД2. В этом случае в течение 5 секунд все узлы репликации Primary (если таковые имеются) автоматически переключатся в Secondary.
Однако на описанном выше мы, естественно, не останавливаемся. У нас есть дорожная карта по развитию функционала метрокластера, и её реализация позволит переживать значительно большее количество сценариев отказов. Например, мы планируем отдельно мониторить все виды трафика по отдельности: СХД-Хост, СХД-СХД, управление СХД, что позволит очень гибко настраивать именно сетевое взаимодействие. Так как сейчас есть ряд ограничений при настройке сетевого взаимодействия между СХД и “внешним” миром в схеме с метрокластером.
Подводим итог
Получив новую внешность и функционал, Арбитр становится полноценным элементом экосистемы метрокластера. И основная веха в развитии этого проекта, как мы считаем, - это, конечно же, система обновления. Ведь именно она в дальнейшем позволит доставлять новую бизнес-логику и исправлять возможные ошибки. В принципе, система обновления любого программного продукта - это основной механизм обеспечения его жизненного цикла.
Теперь для обновления Арбитра, в большинстве случаев не требуется останавливать метрокластер. Пакет обновления для Арбитра можно будет без особых проблем получить у наших коллег из отдела внедрения и сопровождения, и установить на вашу систему.
А впереди достаточно долгий, возможно тернистый, но не менее интересный путь развития и этого проекта в частности, и всей экосистемы в целом. Дальше будет интереснее.
И напоминаем, что ждем вас на нашем вебинаре "Около ИТ" 5 сентября по ссылке, на котором мы подробнее расскажем про функционал метрокластера и ответим на ваши вопросы.