Об основных возможностях третьего поколения СХД 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 отношения для каждой пары томов или группы консистентности. Также массивы переходят в бескворумный режим при отказе кворума или всех путей доступа к нему. Если разместить кворум на одной из площадок, то при ее падении доступ к данным на другой площадке предоставляться не будет – потребуется ручное переключение.
В связи с тем, что распределённый между площадками том технологически базируется на обычной синхронной репликации, то и у большинства крупных производителей уже есть аналогичные решения: 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). При необходимости процесс синхронизации можно приостановить, развернуть направление или перезапустить для полной ресинхронизации томов. Следует заметить, что переключения доступа через другую СХД не происходит, в случае если массив перезагружен вручную через графическое меню или через командный интерфейс.
В процессе мы отработали симуляцию различных отказов (см. таблицу ниже). Поведение системы полностью соответствует описанному в данной таблице и в документации производителя.
*4 Падение площадки с СХД без кворума
*5 Падение площадки с СХД с кворумом
*8.1 Поломка СХД произошла более чем через 20 секунд после п.7
*8.2 Поломка СХД произошла менее чем через 20 секунд после п.7
После успешного тестирования заказчик одобрил целевую конфигурацию. Внедрение решения после такого тестирования прошло оперативно и без проблем. Система работает как часы уже в течение 5 месяцев. Техническую поддержку в режиме 24*7 оказывает наш Сервисный центр («Джет» является сервисным партнёром Huawei наивысшего уровня — Certified Service Partner 5-stars). Без ложной скромности отметим, что заказчик полностью удовлетворён возможностями HyperMetro и производительностью решения на базе 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. В его планах – дальнейшее наращивание объёмов защищаемых данных.
Материал подготовлен Дмитрием Кострюковым, старшим инженером-проектировщиком СХД, компания «Инфосистемы Джет».
