Не так давно компания Pure Storage анонсировали новую функциональность ActiveCluster – active/active метро кластер между хранилищами данных. Это технология синхронной репликации, при которой логический том растянут между двумя хранилищами и доступен на чтение/запись на обоих. Эта функциональность доступна с новой версией прошивки Purity//FA 5 и является абсолютно бесплатным. Также Pure Storage пообещали, что настройка растянутого кластера никогда не была еще такой простой и понятной.
В данной статье мы расскажем про ActiveCluster: из чего состоит, как работает и настраивается. Отчасти статья является переводом официальной документации. Помимо этого, мы поделимся опытом тестирования его на отказоустойчивость в VMware-окружении.
Конкурентные решения
Представленная функциональность не является чем-то инновационным, аналогичные решения есть у большинства крупных производителей СХД: Hitachi GAD (Global Active Device), IBM HyperSwap, HPE 3PAR Peer Persistance, Fujitsu Storage Cluster, Dell Compellent Live Volume, Huawei HyperMetro.
Однако мы решили выделить некоторые плюсы ActiveCluster по сравнению с конкурентными решениями:
- Не требует дополнительных лицензий. Функциональность доступна «из коробки».
- Простое управление репликацией (мы попробовали — это действительно удобно и просто).
- Облачный медиатор (Quorum device). Не требует наличия третьей площадки и развертывания на ней кворум сервера.
Обзор ActiveCluster
Рассмотрим компоненты, из которых состоит ActiveCluster:
- Transparent Failover Mediation. Cloud Mediator – это кворум сервер/устройство, которое принимает решение, какой из массивов продолжит работать и предоставлять доступ к данным, а какой должен прекратить работу в случае различных сбоев.
- Active/Active Clustered Arrays – массивы PureStorage с настроенной синхронной репликацией между ними. Предоставляют доступ к консистентной копии данных как с одного массива, так и с другого.
- Stretched Storage Containers – контейнеры, содержащие объекты, которые должны реплицироваться между двумя массивами.
В ActiveCluster появились новые объекты – Pods. Pod – это контейнер, содержащий другие объекты. Если между двумя массивами существует репликационный канал, то в pod можно добавить несколько массивов и тогда все объекты в этом pod будут реплицироваться между массивами. Растянутыми pod`ами можно управлять с любого массива.
Pod может содержать volumes, snapshots, protection groups и другую конфигурационную информацию. Pod функционирует как consistency group, то есть гарантирует согласованный порядок записи томов в одном pod.
ActiveCluster: схемы доступа хостов к массивам
Доступ хостов к данным может быть настроен двумя моделями доступа: uniform и non-uniform. В uniform модели каждый хост на обеих площадках имеет доступ к обоим массивам на чтение/запись. В non-uniform модели каждый хост имеет доступ только к локально расположенному массиву на чтение/запись.
Uniform-модель доступа
Uniform-модель доступа к данным может использоваться в окружениях, где для соединения хостов с массивами используется Fibre Channel или Ethernet (iSCSI) и между массивами используется Ethernet-соединение (10g) для репликации. В данной конфигурации хост имеет доступ к данным через оба массива: как через локальный, так и через удаленный. Это решение поддерживается только при максимальной задержке между массивами по каналам репликации в 5 мс.
Схема выше иллюстрирует логические пути от хостов до массивов, а также канал репликации между массивами в схеме доступа Uniform. Предполагается, что данные доступны обоим хостам вне зависимости от того, на какой площадке они находятся. Важно понимать, что пути до локального массива будут иметь меньшую задержку, чем до удаленного.
Оптимизация производительности при использовании Uniform-модели
Для лучшей производительности ввода/вывода при использовании active/active синхронной репликации хост не должен использовать пути до удаленного массива. Для примера рассмотрим представленную ниже картинку. Если «VM 2A» будет выполнять операцию записи на том «A», используя массив «Array A», то эта операция записи повлечет за собой двойную задержку передачи данных через канал репликации, а также задержку от хоста до удаленного массива.
Предлагаю разобрать более подробно. Предположим, что задержка по каналу репликации между массивами у нас 3ms. В случае соединения «Host B» <-> «Array B» задержка 1ms. А в случае «Host B» <-> «Array A» – 3ms. Команда записи будет отправлена от хоста «VM 2A» на удаленную площадку к массиву «Array A» с задержкой в 3ms. Далее команда записи будет отправлена через канал репликации на массив «Array B» с задержкой в 6ms (3ms + 3ms). После этого ответ об успешной записи будет отправлен обратно от массива «Array B» к массиву «Array A» через канал репликации (6ms + 3ms = 9ms). Далее ответ об успешной записи будет отправлен обратно на хост “VM 2A” (9ms + 3ms = 12ms). Итого мы получаем задержку в 12ms на операцию записи в случае использования удаленного массива. Если посчитаем точно по такому же принципу использование локального массива – то получим 8ms.
ActiveCluster позволяет использовать ALUA (Asymmetric Logical Unit Access), для предоставления путей до локальных хостов как active/optimized и предоставления путей до удаленных хостов как active/non-optimized. Оптимальный путь определяется для каждой связки host <-> volume устанавливая опцию preferred array. Таким образом, не важно на каком из хостов работает ваше приложение или виртуальная машина, хост всегда будет знать какой массив для него локальный (имеет оптимальные пути), а какой удаленный (имеет не оптимальные пути).
Используя ActiveCluster, можно конфигурировать действительно active/active датацентры, не заботясь о том, на какой площадке работает ваша виртуальная машина или приложение. Все операции чтения/записи всегда будут идти через локальный для хоста массив.
Non-uniform модель доступа
Модель доступа Non-uniform также используется в окружениях, где для соединения хостов с массивами используется Fibre Channel или Ethernet (iSCSI). В данной модели хосты имеют доступ только к локальному массиву и не имеют доступа к удаленному массиву. Данное решение также предполагает использование репликационных соединений между массивами с задержкой не более 5ms.
Плюсы и минусы этих моделей доступа
Модель доступа Uniform обеспечивает более высокий уровень отказоустойчивости, так как выход из строя одного массива не повлечет за собой рестарт виртуальных машин или приложений, использовавших этот массив, – доступ к данным будет продолжен через другой. Конечно данная модель предполагает работающий и настроенный мультипасинг (multipathing) на стороне хостов, который распределял бы запросы ввода/вывода по active/optimized путям и по active/non-optimized в случае, когда первые недоступны.
В случае использования модели Non-uniform хосты имеют доступ только к локальному массиву и, соответственно, только по active/optimized путям. В случае выхода из строя локального массива все виртуальные машины или приложения потеряют доступ к данным на этой площадке и будут перезапущены (например, средствами VMware HA) на другой площадке, используя доступ к данным через другой массив.
Настройка Active Cluster
Ребята из Pure Storage заявляют об очень простой, интуитивной настройке ActiveCluster. Что же, давайте посмотрим. Настройка производится в 4 шага:
Шаг 1: Соединение двух Flash массивов.
Соединяем наши массивы двумя каналами Ethernet 10Gb/s и через GUI настраиваем тип соединения как Sync Replication.
Шаг 2: Создание и растягивание pod.
Для создания pod мы будем использовать CLI (через GUI тоже можно). Команда purepod используется для создания и «растягивания» pod. Как мы уже говорили ранее, pod – это контейнер, который создан для упрощения управления в active/active среде. Pod определяет, какие объекты должны синхронно реплицироваться между массивами. Управлять растянутыми pod’ами и объектами в них можно с любого из массивов. Pod может содержать в себе тома, снапшоты, клоны, протекшен группы и другую конфигурационную информацию.
Создаем pod на массиве Array A:
arrayA> purepod create pod1
Растягиваем pod на Array B:
arrayA> purepod add --array arrayB pod1
Теперь любые тома, снапшоты или клоны, помещенные в этот pod, будут автоматически реплицироваться между массивами «Array A» и «Array B».
Шаг 3: Создание томов
На любом из массивов создаем том vol1 размеров 1TB и помещаем его в pod1:
> purevol create --size 1T pod1::vol1
Вместо создания тома мы можем переместить любой уже имеющийся том в pod1 и он начнет реплицироваться.
Шаг 4: Презентация тома на хост.
Еще раз отметим, что ActiveCluster – это настоящее active/active решение, которое позволяет читать и писать на один и тот же логический том, используя оба массива.
Создаем хост и презентуем том vol1 этому хосту:
> purehost create --preferred-array arrayA --wwnlist <WWNs оf ESX-1 >
> purehost connect --vol pod1::vol1 ESX-1
Прошу обратить внимание, что мы указываем опцию –preferred-array которая означает, что пути с массива «ArrayA» будут для этого хоста оптимальными (active/optimized).
Это все! Теперь ESX-1 имеет доступ к тому vol1 через оба массива «ArrayA» и «ArrayB». Быстро и просто, неправда ли?
Дополнительно проверим состояние медиатора. Мы используем облачный медиатор Pure, для доступа к нему массивы должны иметь выход в интернет. Если политика безопасности не позволяет этого сделать, то есть возможность скачать и развернуть локальный медиатор.
purepod list --mediator
Name Source Mediator Mediator Version Array Status Frozen At Mediator Status
pod1 - purestorage 1.0 Array-A online – online
Array-B online - online
Функциональное тестирование ActiveCluster в среде VMware
Перед нами стояла задача функционального тестирования связки двух Flash Array//m20 в конфигурации ActiveCluster и VMware (2 ESX хоста) в части обеспечения отказоустойчивой работы виртуальных машин. Мы эмулировали наличие двух площадок, на каждой из которой был ESX-хост и Flash Array. Использовалась версия VMware 6.5 U1 и версия Pure//FA 5.0.1.
У нас были следующие критерии успеха:
- Эмулируемые отказы дискового массива не приводят к перебою в работе виртуальных машин.
- Эмулируемые отказы ESX-сервера позволяют автоматически (средствами VMware HA) запустить виртуальные машины на другом ESX сервере.
- Эмулируемые отказы площадки (массив + esx-сервер) позволяют автоматически (средствами VMware HA) запустить виртуальные машины на другой площадке.
- Проверить работу vMotion в конфигурации с VMware + ActiveCluster.
Схема нашего стенда представлена ниже:
Между массивами m20 #1 и m20 #2 был собран ActiveCluster с использованием репликационного канала на 10 Гбит/с. На одном массиве был создан pod, а затем растянут добавлением в него второго массива. На обоих массивах создан том размером 200GB и добавлен в растянутый pod, тем самым запустив репликацию этих томов между массивами. Реплицируемый том был презентован обоим ESX-хостам по схеме Uniform access с конфигурацией preferred array для хост-групп. Для хоста ESX1 preferred array был m20 #1, а для ESX2 соответственно m20 #2. Таким образом со стороны ESX-хостов пути до датасторов были active (I/O optimized) до локального массива и active (non-optimized) до удаленного.
Эмуляция отказа дискового массива
Для тестирования была проинсталлирована виртуальная машина с Windows 2012 r2. Файлы ВМ располагались на общем датасторе на растянутом томе с Pure Storage. Также в эту ВМ был презентован еще один диск на 100GB с этого же датастора, на который мы запустили синтетическую нагрузку средствами IOmeter. Отмечу, что у нас не было цели замерять производительность, нам необходимо было сгенерировать любую I/O активность, чтобы при наших тестированиях отловить моменты, когда SCSI команды чтения/записи могли подвиснуть при переключении путей до массивов.
Итак, все готово: тестовая ВМ работает на ESX1, хост ESX1 использует оптимальные пути до массива m20 #1 для операций ввода/вывода. Мы идем в серверную и отрубаем по питанию массив m20 #1 и наблюдаем за IOmeter в ВМ. Никакого прерывания в вводе/выводе не происходит. Смотрим состояние путей до датастора: пути до m20 #1 в состоянии dead, пути до m20 #2 перешли в состояние active (I/O). Тест проводился несколько раз с немного разными входными данными, но результат всегда был успешным. Тест считаем успешно пройденным.
P.S. После включения массива m20 #1 пути переключились обратно на него, то есть на локальную для этого ESX-хоста площадку.
Эмуляция отказа ESX-хоста
Этот тест не очень интересный, так как мы, по сути, проверяем не Pure Storage, а работу VMware HA. Мы в любом случае ожидали downtime для ВМ и последующее ее воскрешение кластером на другом ESX хосте.
В общем, мы сходили в серверную и дернули по питанию хост ESX1. VMware HA отработал штатно, и наша ВМ успешно поднялась на хосте ESX2. Тест считаем успешным.
Эмуляция отказа всей площадки
По сути, это первый и второй тест, проводимые одновременно. И в любом случае это downtime для виртуальной машины, так как мы отключаем ESX хост. Исходные данные такие же, как и в первом тесте: ВМ работает на ESX1, хост ESX1 использует для ввода/вывода массива m20 #1, в ВМ запущен IOmeter для синтетической нагрузки на массив.
Мы идем в серверную и отключаем питание у ESX1 и m20 #1. Наблюдаем. В течении 1-2 минут VMware HA поднимает виртуальную машину на ESX2, пути на ESX2 в состоянии dead для m20 #1 и в состоянии active (I/O) для массива m20 #2. Тест считаем успешным.
Проверка работоспособности vMotion в конфигурации ActiveCluster
Весьма формальный тест. Нам необходимо было проверить, что он работает и нет никаких подводных камней. Погоняли vMotion как на включенной виртуальной машине, так и на выключенной, со сменой датастора и без, никаких проблем не выявлено. Тест успешно пройден.
Заключение
Технология синхронной репликации уже не нова и есть практически у каждого крупного вендора СХД, но Pure Storage выделяются среди них тем, что не требуют дополнительных лицензий на ее использование, которые зачастую могут составлять немалую часть от стоимости самой СХД. Также ребята из Pure вывели на новый уровень удобство управлением репликацией, теперь не требуется изучение множества десятков страниц документации для того, чтобы её настроить, а весь процесс интуитивно понятен. Для повышения собственных компетенций и в рамках организации Proof of Concept мы проводим различные тестирования как у себя, так и у заказчиков. Вместе с дистрибьютором OCS (второй массив мы взяли у них), мы развернули первый в России Pure Storage ActiveCluster, на котором проводили тестирования.
Сергей Сурнин, эксперт Сервисного Центра компании «Инфосистемы Джет»
Автор: JetHabr
