Привет, Хабр!
Когда речь заходит об отказоустойчивости между ЦОДами, метрокластер — почти всегда первое, что приходит в голову. Раньше это был стандарт: один ЦОД падает — второй подхватывает. Все работает, данные не теряются. Вместе с уходом западных вендоров их решения ушли вместе с ними либо появились огромные трудности с их конфигурированием и поддержкой.
С 2024 года у нас на тестовом стенде стоят системы хранения AQ440 от «Аэродиск». Мы их активно «мучаем»: имитируем отказы, нагружаем, меряем задержки, устраиваем испытания на выживание. Наш выбор связан с тем, что это единственное решение (на данный момент), у которого есть поддержка метрокластера. И основной фокус сегодняшнего рассказа — описать сценарии работы этой технологии. Не имитацию, не полумеру, а рабочую схему с реальным переключением между площадками, отказами и всем, что из этого следует.
Недавно мы провели митап, на котором показали, как это все работает вживую. А до этого уже делились тестами — в статьях и докладах. Но в этот раз решили сделать все наглядно, в формате прямой трансляции с нашего тестового стенда. Если не смотрели — записи доступны на VK video и Rutube. Вопросы оставляйте в комментариях — читаем, отвечаем.
Если решите все же не смотреть митап (ну а вдруг), вот краткий пересказ и разбор ключевых моментов — собрали все важное в этой статье.
К тестированию мы подошли с полной ответственностью. Построили рабочий контур практически полностью на отечественном железе и софте, чтобы все было максимально приближено к реальным условиям (подробности ниже). А чтобы не было совсем «просто», мы решили добавить расстояние между дата-центрами — через эмулятор сетевой задержки. В роли «замедлителя» выступает устройство от IBM. Он создает задержку, имитируя, что между ЦОДами имеется путь в 60 км.
Все этапы проверяла и настраивала наша команда экспертов из «Инфосистемы Джет» — люди, которые знают толк в инфраструктуре.
Мы не просто так акцентируем внимание на развитии метрокластера на отечественном оборудовании. Сама технология — это фундамент отказоустойчивости на уровне целого массива в критически важной инфраструктуре. По факту на уровне LUN'ов. И теперь у нас есть возможность реализовать это на отечественном оборудовании. Работает? Да. Есть нюансы? Конечно. Мы все их разберем дальше.
Зачем это нужно? Давайте коротко
Самое частое применение — организация отказоустойчивого контура (ЗО) КИИ на отечественном оборудовании. Отказоустойчивость — гарантия для ИТ и бизнеса, которая убережет их данные и нервы.
Это доступность данных и сервисов на случай аварии в ЦОДе и переключения информационных систем в рЦОД.
Это возможность беспрерывного обслуживания и модернизаций систем. При регламентированных работах — это возможность переключить доступ до данных на другую систему в режиме non-stop.
Как мы построили тестовый стенд
Подход к реализации испытуемого стенда метрокластера строится на мировых практиках — две одинаковые СХД на разных площадках и узел-свидетель, расположенный на третьей площадке, который имеет связность до всех СХД. В настоящее время в России нет решений в области коммутаторов FC, поэтому основной протокол передачи данных — это iSCSI. Конечно, могут появиться сложности в организации сетевой L2 или в крупных масштабах L3-архитектур. Поэтому тут необходима помощь квалифицированных сетевых инженеров.
Со своей стороны, мы задумались, что делать кластер на расстоянии соседних стоек просто не интересно. Поэтому с помощью эмулятора задержки, реализованного на отдельном физическом сервере IBM «между ЦОДами» с ОС Linux и команды tc, мы выставили задержку в миллисекундах, эквивалентную расстоянию 60 км (порядка 2 миллисекунд).
Общая схема стенда представлена на рисунке 1. Эта архитектура принимается за «исходное состояние» в сценариях отказа.
Из чего состоит наш метрокластер
Две СХД «Аэродиск» AQ440 (Аэродиск 1 и Аэродиск 2)
Два сервера Aquarius T50 (node01 и node02)
Программное обеспечение (ПО) виртуализации — zVirt 4.2U3
База данных (БД) PostgreSQL на 25 млрд. строк (PgDB)
«Эмулятор» (сервер) сетевой задержки IBM
Узел-свидетель (арбитр), расположенный на сервере сетевой задержки
Коммутаторы iSCSI Qtech 10GE (rulab-qt-sw1, rulab-qt-sw2)
Коммутатор IPMI 1GE (rulab-qt-sw3)
Система мониторинга «Пульт» 2.0
Платформа анализа данных с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных (Visiology)
На массивах расположены три пары МетроЛунов
DDP_Metro/HE — Hosted Engine платформы виртуализации zVirtа
DDP_Metro/Visiology — ЛУНы для хранения данных виртуальной машины с платформой Visiology
DDP_Metro/PosgreSQL — ЛУНы для хранения данных виртуальной машины с PosgreSQL
Сценарии отказов. Что мы тестировали
Отказ продуктивного кластера виртуализации
Отказ продуктивной СХД
Отказ продуктивной площадки целиком
Отказ сети передачи данных продуктивной площадки
Представленные схемы демонстрируют наиболее распространенные случаи выхода из строя оборудования.
Сценарий №1: Уронили хост виртуализации
Схема теста представлена на рисунке 2.
Сценарий максимально прост: обрубаем один из серверов виртуализации. Мы смотрим на реакцию массивов, не будет ли там каких-то нештатных переключений и (или) блокировок записи на одном из них. На защиту приложений упавшего сервера встают инструменты виртуализации, а именно высокая доступность или HA (High Availability), благодаря чему не происходит отказа сервисов. По сценарию обработка нештатной ситуации выполняется исключительно на прикладном уровне. Системы хранения продолжают работать штатно, а между площадками никаких переключений не происходит.
Путь к «непадению» пролегает через автоматическое переключение сервисов (виртуальных машин) с узла 2 на узел 1, как показано на рисунке 3.
На мониторинге, как со стороны zVirt, так и внешней системы «Пульт», мы получаем информацию о недоступности одного сервера.
Но что же происходит у нас с прикладом? Побежали его проверять — запустился процесс синхронизации данных. Нагрузка на БД генерируется PGbench с помощью случайных операций Input/Output для каждой транзакции. Ошибки в записи отсутствуют. Платформа Visiology подвисла и не получает актуальных данных.
Время ожидания переключения сервисов составило две минуты. На мониторинге, по уже известному сценарию с двух сторон, подтверждается завершение переключения сервисов при выключенном узле 2. После этого мы решаем, что хватит мучать наш стенд, и включаем упавший узел. На этот раз необходимо «ручками» смигрировать из консоли управления zVirt ранее переместившиеся виртуальные хосты с PostgreSQL и Visiology обратно на узел 2. Через несколько минут данные доступны в исходном состоянии для чтения и записи.
Сценарий №2: Отключили СХД
Схема теста представлена на рисунке 4.
Данный сценарий чуть сложнее — одновременно обрубаем все питание массива 2. Отыгрывая свою роль, узел-свидетель оповестил, что один из массивов недоступен после нескольких секунд работы.
В этом сценарии вводим термин «(VIP) метрокластера». Это плавающий IP-адрес, привязанный к адресам контроллеров СХД и являющийся основным интерфейсом «доступа к блочным данным» Для виртуальных машин узла 2 происходит автоматическое переключение путей доступа до данных с массива 2 на массив 1, в соответствии с рисунком 5.
По логике массивов происходит автоматическая смена ролей Primary-Secondary в парах репликации и (VIP) на массиве 1. После переключения все операции выполняются в штатном режиме. Время транзакций в PostgreSQL по нашему стенду чуть увеличено, благодаря работе эмулятора сетевой задержки.
Немного отвлечемся и ответим на один из частых вопросов: Что происходит с данными, если внезапно отключить питание у СХД и нет ни метрокластера, ни второго массива? Потеряются ли последние изменения, если они были еще в кеше?
Ответ: Не потеряются. В сценариях без метрокластера (т.е. без дублирующего массива), при внезапном выключении питания запись всегда идет напрямую на энергонезависимое хранилище (SSD RW-кэш в RDG или на SSD в группе DDP). Это позволяет избежать потери последних данных.
Убедившись в доступности данных, включаем обратно массив 2. Статус ресинхронизации МетроЛунов отображается в массивах в процентном соотношении. С учетом того, что нагрузка на базу данных PostgreSQL продолжает поступать под PGbench, время синхронизации происходит дольше за счет поступления новых данных. Для ускорения процесса мы временно отключаем нагрузку PGbench и ждем завершения синхронизации, которое уже происходит в разы быстрее, и возвращаем стенд в исходное состояние.
Сценарий №3: Обрубили площадку целиком
Схема для наглядности представлена на рисунке 6.
Данный сценарий еще веселее)))
Внезапно выключается питание и у узла 2, и у массива 2. Арбитр штатно уведомляет о недоступности массива, а компонент мониторинга zVirt оповещает о недоступности сервера. И тут начинается магия — происходит перезапуск виртуальных машин с узла 2 на узел 1 и переезд (VIP) метрокластера на массив 1. База данных PosgtreSQL недоступна, Visiology также недоступна. По сути, такой сценарий отказа является совмещенным вариантом сценариев №1 и №2, поэтому происходит аналогичное развитие событий, как на рисунке 7.
Сервис перезапускается аналогично по времени с первым сценарием отказа. Поскольку сейчас остается один массив, то количество транзакций в секунду PostgreSQL увеличивается в результате локализации трафика данных и отсутствия необходимости подтверждения записи от другого массива на расстоянии 60 км. После демонстрации доступности данных и работоспособности сервисов возвращаем стенд в исходное состояние.
Сценарий №4: Сломали сеть между площадками
Схема отказа представлена на рисунке 8.
Данный сценарий — один из самых неприятных, здесь происходит эмуляция приезда экскаватора, который неожиданно (!) во время проведения землеройных работ обрывает сеть между площадками. При этом все устройства остаются включенными и сохраняют возможность управления через порты BMC.
Сеть — это «самое-самое» место, если вы понимаете, о чем это мы. А если без шуток, то это один из самых сложных и трудноконфигурируемых элементов в любой отказоустойчивой архитектуре. Поэтому, несмотря на трудности, мы были обязаны провести этот сценарий. Итак, обрываем сеть между ЦОДами.
Узел-свидетель просигналил о недоступности сети между массивом 1 и массивом 2.
И снова фокус-покус по сценарию 2: (VIP) метрокластера переезжает на массив 1 в течение шести секунд (подтверждается логами), а виртуализация автоматически начала переключение виртуальных машин на узел 1. Перезапуск виртуальных машин и полное переключение на резервные системы происходит в течение пяти минут. За это время мы внимательно осматриваем стенд на соответствие заявленному ожиданию о доступности данных и отсутствии логических ошибок приклада. По завершении испытания происходит восстановление стенда до исходного состояния.
Что в итоге?
Если коротко — мы еще раз показали, что метрокластер на отечественном оборудовании — это вполне рабочая практика. Вот ключевые моменты, которые удалось подтвердить в ходе демонстрации:
Мы еще раз показали, что метрокластер на отечественном оборудовании — это вполне рабочая практика. Вот ключевые моменты, которые удалось подтвердить в ходе демонстрации:
Четыре наиболее частых сценария отказа контуров данных на двух площадках были смоделированы и успешно отработаны на стенде. Все полностью на российском оборудовании и софте.
За контролем доступности стендового оборудования следила система мониторинга «Пульт». Дополнительная контрпроверка проводилась с помощью платформы управления zVirt и узла-свидетеля от «Аэродиска».
Системы «Аэродиск» совместимы с механизмом высокой доступности — HA (high availability) zVirt. В случае падения одного из хостов виртуализации — на втором сервере происходит автоматический перезапуск сервисов. Ручное вмешательство требуется только при возврате виртуальных машин на исходный узел. Переключение путей до массивов на этом этапе не требуется в теории и не происходит на практике. Массивы стабильно продолжают работать без всяких изменений.
При отказе одного из массивов арбитр определяет его недоступность, что занимает не более шести секунд после отказа. После этого он автоматически переводит пути до данных на доступное хранилище.
Сценарий с отказом второй площадки тоже отработан по всем стандартам мировых практик. Виртуальные машины автоматически поднимаются на доступном сервере. Организация доступа данных на рабочий массив происходит также без ручного вмешательства.
Сценарий с обрывом связи между площадками показал ожидаемый результат. Сервисы автоматически поднимаются на узле 1. Пути до данных сервисов переключились на массив 1.
Были замечены небольшие задержки при переключении сервисов с узла 2 на узел 1. Критичных последствий не возникло.
В ходе проверок сценариев отказа данные не потерялись.
Восстановление связности между массивами происходит в процессе ресинхронизации, данные актуализируются на недоступном массиве. При этом актуальные данные также поступают. Время зависит от объема поступающих изменений.
И наконец. Мы успешно отработали iSCSI метрокластера между двумя площадками с эмулированным расстоянием в 60 км.
Авторы:
Тигран Казарян, руководитель направления СХД в «Инфосистемы Джет»
Алексей Быков, ведущий инженер-проектировщик систем хранения данных в «Инфосистемы Джет»
Евгений Бергинов, системный архитектор в «Инфосистемы Джет»