Об основных возможностях третьего поколения СХД Huawei Oceanstor на Хабре уже рассказывали, а вот о функции доступа к тому «растянутому» между площадками, информации немного. Постараемся закрыть это упущение. Данный материал подготовлен по результатам внедрения у одного из наших заказчиков в банковской среде.

Подробное описание

Основное предназначение HyperMetro – защита от выхода из строя ЦОД, и только затем СХД, дисковой полки и т.д. Функция стала доступна вместе с прошивкой V300R003C00SPC100 в декабре 2015.

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

Рисунок 1. Топология HyperMetro

Для арбитража в случае сбоев используется Quorum, который устанавливается на третьем сайте, имеет доступ к обоим массивам по сети Ethernet и представляет собой приложение для Linux (SUSE/RHEL/Ubuntu). Чтение и запись в распределённый том возможны с любой из площадок на любую из двух СХД за счёт обмена блокировками между массивами при помощи записи в журнал транзакций (data change log — DCL), который защищает от возможности записи с разных хостов в один блок. Также следует заметить, что запись в кэш обеих СХД идёт параллельно, а не последовательно. Далее представлен процесс записи в HyperMetro.

Рисунок 2. Порядок операций при записи на распределённый том

Приоритизацией локального чтения/записи во избежание межсайтового траффика занимается драйвер MPIO Huawei Ultrapath (поставляется в комплекте с Oceanstor V3). Допускается балансировка по производительности между площадками. Возможно использование не только FC, но и iSCSI – как для доступа к хостам, так и для репликации.

После создания отношений HyperMetro оба тома считаются симметричными и равноценными. Однако на случай отказа кворума и связи между СХД задаётся приоритетная сторона для каждого из отношений HyperMetro, чтобы избежать ситуации “split brain”. Есть возможность использовать группы консистентности для объединения нескольких пар томов. В случае отказа одной из копий в подавляющем большинстве случаев не происходит потеря доступа к данным.

При отсутствии третьей площадки возможно использование HyperMetro в безкворумном режиме (Static Priority Mode). Данный режим предусматривает автоматическое принятие решений при сбоях в пользу СХД с установленным высоким приоритетом (preferred site). В случае отказа основной СХД non-preferred массив придётся запускать доступ вручную, изменяя приоритетность HyperMetro отношения для каждой пары томов или группы консистентности. Также массивы переходят в бескворумный режим при отказе кворума или всех путей доступа к нему. Если разместить кворум на одной из площадок, то при ее падении доступ к данным на другой площадке предоставляться не будет – потребуется ручное переключение.

Плюсы:

• HyperMetro лицензируется на каждую СХД, а не на зеркалированный объём;
• в связи с общим кодом прошивки в СХД Oceanstor третьего поколения эта функция доступна начиная с 2600v3 до Hi-End массива 18800v3;
• работает не только по FC, но и по IP между двумя основными сайтами;
• доступно использование репликации, многоуровневого хранения, виртуализации, мгновенных снимков и других функций СХД на защищённых с помощью HyperMetro томах.

Минусы:

• требует отдельной Ethernet-платы для подключения к арбитру (выделенные порты для управления СХД задействовать под эти цели нельзя);
• требуется установка на хосты драйвера MPIO Ultrapath.

Конкурентные решения

В связи с тем, что распределённый между площадками том технологически базируется на обычной синхронной репликации, то и у большинства крупных производителей уже есть аналогичные решения: HPE 3Par Peer Persistance, IBM HyperSwap, HDS Global Active Device, Fujitsu Storage Cluster, Dell Compellent Live Volume. И особняком можно выделить решения по защите данных между площадками, которые появились значительно раньше вышеперечисленных и базируются на уникальных решениях: IBM SVC Stretched Cluster, EMC VPLEX Metro, и Netapp MetroCluster.

В данном материале мы не преследовали цель сопоставить продукты от разных производителей. Однако в комментариях постараемся ответить на ваши вопросы относительно сравнения каких-либо конкретных точек в архитектуре решений.

Внедрение

Так как HyperMetro была новой и непроверенной функцией, мы решили сначала произвести тестирование совместно с заказчиком на базе оборудования из демофонда. В тестировании использовались две серверных площадки заказчика, соединённые по DWDM. Объединённая SAN сеть на основе двух фабрик Brocade. На каждой площадке – по одной СХД Huawei OceanStor 5500 V3 с SAS 10k rpm дисками и SSD, ферма x86 blade-серверов c VMware.

На двух СХД последовательно создаются LUN, группы консистентности и настраивается отношение HyperMetro. После этого производится адресация томов с обеих СХД на нужные хосты. На серверах запускались тестовые виртуальные машины с запущенным IOmeter. При имитации отказа одной из СХД значительного падения производительности (>10%) замечено не было. При загрузке CPU контроллеров менее 50%.

После полноценной настройки даже жесткое выключение массива (выдёргивали кабели питания из контроллеров) не привело к потере доступа. После восстановления связи между массивами синхронизация томов производится вручную (можно настроить автоматический режим в настройках каждого отношения HyperMetro — Recovery Policy). При необходимости процесс синхронизации можно приостановить, развернуть направление или перезапустить для полной ресинхронизации томов. Следует заметить, что переключения доступа через другую СХД не происходит, в случае если массив перезагружен вручную через графическое меню или через командный интерфейс.

В процессе мы отработали симуляцию различных отказов (см. таблицу ниже). Поведение системы полностью соответствует описанному в данной таблице и в документации производителя.

#	Работоспособность оборудования			Работоспособность соединения			Результат
	СХД №1	СХД №2	Quorum	№1 <-> Q	№2 <-> Q	№1 <-> №2
1.	+	+	+	+	+	+	Всё работает в обычном режиме
2.	-	+	+	+	+	+	Доступ к тому идёт через рабочую СХД
3.	+	-	+	+	+	+
4.	-*	+	+	-	+	-
5.	+	-*	+*	+	-	-
6.	+	+	-	-	-	+	Доступ к тому идёт через обе СХД. Они в течение 20 сек. переходят в безкворумный приоритетный режим
7.	+	+	-	+	+	+
8.1.	+	-*	-	+	+	+	Доступ к тому идёт через Priority СХД. Если сломалась Priority, то необходимо ручное включение доступа с Non-Priority СХД
8.2.	+	-*	-	+	+	+	Доступ к тому остановлен, необходимо ручное включение доступа на СХД
9.	+	+	+	-	+	+	Доступ к тому идёт через обе СХД.
	+	+	+	+	-	+
11.	+	+	+	+	+	-	Происходит арбитраж. Доступ к тому идёт через Priority СХД.
12.	+	+	+	-	+	-	Доступ к тому идёт через СХД №2.
13.	-	+	+	+	-	+	Доступ остановлен. Необходимо ручное включение доступа с СХД №2

*4 Падение площадки с СХД без кворума
*5 Падение площадки с СХД с кворумом
*8.1 Поломка СХД произошла более чем через 20 секунд после п.7
*8.2 Поломка СХД произошла менее чем через 20 секунд после п.7

После успешного тестирования заказчик одобрил целевую конфигурацию. Внедрение решения после такого тестирования прошло оперативно и без проблем. Система работает как часы уже в течение 5 месяцев. Техническую поддержку в режиме 24*7 оказывает наш Сервисный центр («Джет» является сервисным партнёром Huawei наивысшего уровня — Certified Service Partner 5-stars). Без ложной скромности отметим, что заказчик полностью удовлетворён возможностями HyperMetro и производительностью решения на базе OceanStor. В его планах – дальнейшее наращивание объёмов защищаемых данных.

Материал подготовлен Дмитрием Кострюковым, старшим инженером-проектировщиком СХД, компания «Инфосистемы Джет».