Безусловно, главной функцией в работе любой системы хранения данных является сохранность этих самых данных. Следующим пунктом уже идет обеспечение доступа к ним. А применение различных технологий, многие из которых уже давно стали стандартом де-факто, позволяет объединить эти важнейшие вехи. В данной статье мы поговорим об одной из таких технологий – метро-кластере, поддержка которого появится в СХД Qsan начиная с FW 4.3.0.

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

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

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

Для реализации метро-кластера потребуется две СХД под управлением ОС XEVO3 или QSM4. В общем случае крайне рекомендуется использовать одинаковые СХД, в том числе с одинаковой конфигурацией пулов. Однако, также поддерживается работа между разнотипными моделями (об этом чуть подробнее рассмотрим далее). СХД между собой соединяются при помощи Ethernet и фактически общаются с помощью протокола NVMe-oF (TCP или RoCE). Хосты при этом могут использовать любой тип подключения к СХД: iSCSI/FC для блочных протоколов и CIFS/NFS для файловых протоколов. Разумеется, для работы в режиме метро-кластера каждый хост должен иметь подключение к обеим СХД, в том числе к обоим контроллерам каждой из СХД. Также необходим “свидетель” (witness) – специальное ПО, которое поддерживает связь с обеими СХД и является арбитром на случай потери связи между ними.

Схема реализации QMetro

Важные замечания касательно конфигурации QMetro:

  • Несмотря на то, что хост имеет пути до обеих СХД, при текущей реализации весь ввод/вывод осуществляется на основную СХД. Backup СХД постоянно находится в пассивном режиме и лишь содержит копию данных, находящихся на основной системе. Поэтому на стороне хоста необходимо установить политику MPIO в active-passive. В таком случае при аварии на основной СХД ввод/вывод автоматически будет перенаправлен на резервную систему;

  • На обеих СХД требуется создать одинаковые тома, включая тип (файловый или блочный)/размер тома/размер блока. Безусловно, активация режима метро-кластера не возбраняет использовать каждую из систем для прочих целей. Т.е., под защитой QMetro могут быть далеко не все тома основной СХД;

  • Между СХД постоянно выполняется синхронная репликация. Требования к производительности канала связи: latency round trip ≤ 5ms, пропускная способность ≥ 250 Mb/s на каждый реплицируемый том. Сам канал связи должен быть не ниже 10GbE, хотя крайне рекомендуется использование 25GbE или даже 100GbE для устранения узких мест в плане производительности.
    Напоминаем, что синхронная репликация по сути является двойной записью (с поправкой на кэширование). Поэтому применение максимально скоростных интерфейсов благотворно скажется на общей производительности связки из двух СХД;

  • Т.к. каждый контроллер каждой СХД должен иметь связь друг с другом, необходим коммутатор между системами. Он должен поддерживать non-blocking режим для траффика и поддерживать NVMe-oF. И, если коммутатор также используется для других задач, траффик синхронизации должен быть помещен в изолированный VLAN;

  • Сеть между СХД должна быть плоской и без использования тегирования на портах;

  • Для однозначного определения отказа какой-либо СХД, а также для контроля над ситуацией, когда связь меду системами полностью отсутствует (так называемая проблема split brain), необходимо развертывание дополнительного ПО с ролью “свидетеля” (witness). Эту роль выполняет ПО XInsight, которое все равно необходимо для настроек метро-кластера (напомним, что настройка всего нового функционала Unified систем переехала в XInsight, и обычный WebGUI теперь обеспечивает только базовую настройку). Разумеется, что сервер или VM с XInsight должен иметь связь с обеими СХД (для связи используются порты управления). С точки зрения корректности работы не стоит размещать такую VM на дисковом ресурсе, который расположен на одной из СХД.

После первичной настройки метро-кластера происходит синхронизация содержимого основной СХД с резервной. И далее при любом изменении данных на основной СХД производится синхронная репликация на резервную.

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

В случае возникновения аварии на резервной СХД (не получен ответ на heartbeat на основной СХД и у “свидетеля”) репликация просто останавливается. На остальные компоненты влияние это не оказывает. При восстановлении работы резервной СХД происходит синхронизация содержимого томов, и репликация возобновляется.

В случае возникновения аварии на основной СХД (не получен ответ на heartbeat на резервной СХД и у “свидетеля”) происходит передача роли Мастера на резервную СХД. У хостов же ввод/вывод переключается на резервную систему благодаря MPIO. При восстановлении основной СХД обратная передача роли Мастера автоматически не производится. Она просто принимает на себя обязанности быть резервной системой после завершения синхронизации. В случае необходимости администратор может вручную переназначить роли.

Если происходит обрыв связи между двумя СХД (не получен ответ на heartbeat у обоих СХД, но у “свидетеля” есть от них ответы), то репликация останавливается и администратору выдается сообщение о нарушении работы метро кластера.

В целом QMetro может работать и без “свидетеля” (намеренно или из-за отказа сервера/VM с XInsight). Но тогда администратор должен будет принять на себя риски потенциального возникновения split brain.

Вполне ожидаемо, что, как и у других производителей СХД, функционал метро-кластера является опциональным и подлежит лицензированию. Иного ожидать было бы глупо. Однако, плюсом идет поддержка асинхронного режима работы и относительная простота настроек. Впрочем, это не отменяет необходимости четкого планирования конфигурации и грамотного подбора компонентов. Мы же, как старейший дистрибьютор Qsan в РФ, со своей стороны в очередной раз хотели бы отметить свой внушительный опыт в технической поддержке СХД Qsan, который позволяет нашим заказчикам не только подбирать и внедрять решения любой сложности, но и быть уверенными, что ни одна их проблема не останется нерешенной.