Технологии репликации данных EMC

Не буду расплываться банальными определениями репликации и её необходимости — если человек не знает этих вещей, дальнейшее ему вообще будет непонятно и не интересно. Скажу лишь, что речь идёт о необходимости репликации наборов данных в LUN на СХД. Статья написана по мотивам документа EMC VNX Replication Technologies и немного дополнена.

Итак, какие технологии предлагает EMC для организации катастрофоустойчивости.

1. SAN Copy

Это даже не репликация. Это периодическое копирование LUN на другой LUN на блочном уровне. Начну с него, так как тоже механизм вынесения данных за пределы одного массива. Чтоб два раза не вставать.

Настраивается просто – создать исходный LUN, создать целевой LUN, создать SAN Copy сессию. Можно копировать снапшоты и клоны, что даёт больше гибкости в некоторых случаях.

Ограничения существенные:

• на период Full session должен быть полностью остановлен IO на исходном LUN.
• На период Incremental session остановка IO не требуется, однако происходит сброс кэша и IO замораживается на некоторое время автоматически.
• Целевой LUN нельзя использовать в режиме записи и изменения, т.к. это нарушает консистентность сессии и потребуется Full-репликация (с потерей данных на целевом LUN).

Целевой (резервный) LUN можно использовать либо для чтения, либо нужно будет его склонировать/заснапшотить с помощью дополнительных фич EMC (SnapView Clone, SnapView Snapshot), чтобы отдать под RW уже получившийся клон/снимок, однако вернуть потом эти изменения в исходный LUN будет проблематично.

Вывод: использовать можно под какие-то специфичные задачи (размножение ISO-библиотек по сайтам, тестирование и разработка с использованием данных, периодически выгружаемых из продуктива), но это определённо не Disaster Recovery.

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

2. RecoverPoint

Обращения записи копируются с помощью RecoverPoint Splitter (встроен в OE массива) на RecoverPoint Appliance (RPA), который, в свою очередь, посылает их на другой массив (Remote Replication) или другой LUN текущего массива (Local Replication), можно сразу и туда и туда (Concurrent local and remote). Репликация может быть синхронной и асинхронной.

Есть 4 вида лицензий по количеству реплицируемых стораджей и типу лицензирования (по объёму, по системе, по количеству vRPA-кластеров):

• RecoverPoint /SE — для VNX и Clariion. Репликация на один массив в RPA-кластере (локальная) или между двумя массивами по одному в RPA-кластере. Допускается использование одного массива на датацентр. Лицензируется на систему (включая весь объём одного массива).
• RecoverPoint /EX — для VNX, VNXe3200, VNX-F, Symmetrix  и VPLEX. Лицензируется на систему для VNX и на зарегистрированную ёмкость для VMAX и VPLEX. Поддерживает репликацию между несколькими массивами в разных ДЦ. До пяти RPA-кластеров.
• RecoverPoint /CL —  для VNX, Symmetrix, VPLEX и 3rd party систем, подключенных через VPLEX. Лицензируется на реплицируемую ёмкость. Локальная и удалённая репликация требуют разных лицензий. Поддерживает репликацию между несколькими массивами в разных ДЦ. До пяти RPA-кластеров.
• RecoverPoint /VE — для среды виртуализации на базе VMware vSphere. Лицензируется по количеству vRPA-кластеров. Один vRPA-кластер может обслуживать только один ESXi-кластер и обеспечивать локальную репликацию внутри него. Репликация между кластерами, как локальная (внутри сайта), так и удалённая требует как минимум двух лицензий.

Сравнительная таблица лицензий

Вместо аппаратного RPA может использоваться виртуальный vRPA, но подключать его тогда нужно по iSCSI, поскольку протащить FC в виртуальную машину это дополнительные трудности.

Преимущества RecoveryPoint:

• RPO может измеряться в миллисекундах;
• Поддерживаются любые приложения;
• Синхронная и асинхронная репликация — можно реплицировать даже на дальние дистанции с долгим Round Trip Time;
• Есть компрессия и дедупликация реплицируемых данных (для медленных каналов полезно).

По описанию, вроде, самый нормальный после VPLEX вариант репликации, но информации мало. Для более детального понимания надо пробовать, но у нас такой лицензии нет, потыкать самому не довелось.

3. MirrorView

Простая репликация исходного LUN на целевой. Похоже на SAN Copy, но не требует заморозки исходного LUN. Поддерживает Consistency Groups (например, БД и логи чтоб синхронизировались с соблюдением порядка изменений). Нельзя реплицировать снапшоты и клоны. Репликация также может быть синхронной (RTT < 10ms) и асинхронной (RTT > 10 ms < 200 ms).

Синхронная репликация:

1. Хост инициирует запись на основной VNX;
2. Основной VNX пишет на резервный VNX;
3. Резервный подтверждает запись основному;
4. Основной подтверждает запись хосту.

Асинхронный режим:

1. Хост инициирует запись на основной VNX;
2. Основной VNX подтверждает запись хосту;
3. Основной VNX отслеживает изменения и реплицирует данные на резервный VNX в определённый пользователем RPO-интервал.
4. Резервный VNX принимает данные и подверждает их получение.

Самые «нижние» порты массива (SPA0, SPB0) выделяются под MirrorView и должны быть зазонированы между собой. При этом не должны перекрещиваться, то есть зоны должны быть [A0-A0] и [B0-B0]. Желательно их исключить из зон основной нагрузки с инициаторами. На практике выяснилось, что одной зоны [A0-A0] для создания «зеркала» не достаточно (так получилось, что порты B0 разных массивов оказались у нас в разных фабриках). Для отказоустойчивости рекомендуется размещать порты и зоны [A0-A0] в одной фабрике, а [B0-B0] в другой.

Сначала устанавливается Mirror Connection, затем клепаются Mirrors для каждого LUN, которому это необходимо. Всё делается из Unisphere.

Можно переключить роли основного и резервного LUN (в этом случае создаётся новое зеркало с тем же именем, но новым ID, а старое убивается).

Mirror Owner определяется по LUN Owner (резервный LUN создаётся с тем же LUN Owner, что и основной).

Преимущества как у RecoverPoint, но без дедупликации и компрессии.

Лицензии требуются на всех массивах-участниках.

И последний вариант – VPLEX.

Не совсем технология репликации. Не только. Это аппаратный комплекс виртуализации подсистем хранения. Обеспечивает и репликацию и масштабируемость и мобильность данных, путём абстрагирования от уровня конкретных СХД, организуя некий единый слой хранилища. Различаются следующие варианты реализации комплекса:

VPLEX Local — один локальный кластер, охватывающий одну площадку. обеспечивает отказоустойчивость на уровне хранилища.

VPLEX Metro — два VPLEX-кластера, разделённых дистанцией синхронной записи (RTT до 5 мс). Обеспечивает отказоустойчивость на уровне площадок в пределах города.

VPLEX Geo — два VPLEX-кластера на дистанции асинхронной записи (RTT до 50 мс). Отказоустойчивость между площадками в пределах планеты.

VPLEX VE — для репликации двух VMware vSphere сред. Синхронная репликация (RTT до 10 мс).

Со всех сторон круто – растянутый кластер, мгновенный svMotion между площадками и прозрачная репликация, но стоит как самолёт.

Зато можно настроить единое сторадж-пространство между разными площадками и жить спокойно :)

Для лучшего управления репликами рекомендуется использовать Replication Manager (отдельный софт за отдельные деньги). Смысл его и функционал:

• Автоопределение приложений, подключенных массивов и технологий репликации;
• App-consistent восстановление (переводит приложения в режим восстановления, восстанавливает реплику, возвращает приложение в основной режим).

Такое получилось маркетинговое исследование.

Это не все вообще варианты репликации данных средствами EMC, но меня интересовал только блочный уровень mid-grade массивов.