В продолжение статьи о парадигме резервного копирования NetApp, хочу рассказать о недокументированной возможности преобразования «архивных копий» в «резервные» для серии FAS. Отличительной чертой СХД компании NetApp серии FAS является то, что они все унифицированы. Унифицированность не только в том, что одно устройство предоставляет доступ хостам как по блочным, так и по файловым протоколам, но и по способу применения. Системы FAS используются для виртуализации, для Data Compliance, для хранения архивных копий, для построения Disaster Recovery решений и т.д. Одна и та же СХД может выполнять сразу множество функций. Так для каждой функции не нужно держать одно «специализированное» устройство, а в случае если срочно понадобится «запасная» СХД, её всегда можно «перепрофилировать» из того что есть, к примеру из СХД для архивации данных. Благодаря этой универсальности нет необходимости переобучаться под каждую из этих задач ведь операционная система, командная строка и все принципы настройки одни и те же для всех FAS систем.
В этой статье я расскажу как построенное решение «Архивация данных на NetApp» переделать в решение «Disaster Recovery».
С точки зрения бизнеса Disaster Recovery и архивирование отличаются тем, что:
Поясню на примере: когда у вас есть хотя бы две СХД с настроенной репликацией SnapMirror, в такой схеме одна из них играет роль источника (primary), а вторая роль приемника (Secondary). В случае аварии, при разрыве репликации (командой break, а не просто разрыв линка), принимающая (Secondary) система переведёт реплицируемое зеркало из режима read-only в режим read-write. Т.е. это инструмент для создания решения «Переключение на запасную площадку в случае аварии» (Disaster Recovery). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.
В то время, как SnapVault предназначен для архивирования на резервную (Secondary) систему, чтобы потом из неё восстановить все данные обратно на первичную систему или вообще на третью систему. Стоит отметить, что для задач архивирования очень важно хранить данные в неизменённом состоянии все время. В данном случае вторичная система, куда складываются все архивы, может быть любой модели. Здесь логично иметь самую дешевую модель NetApp FAS с медленными и дешевыми дисками большего объема. К примеру, FAS2554 или FAS2520.
Более детально как работает SnapMirror и SnapVault можно прочесть соответствующих статьях, а также сравнить эти два решения с технической точки зрения.
QSM SnapMirror работает практически также как и SnapVault и использует всё тот же алгоритм и внутреннего устройства репликации, SnapMirror кроме QSM, включает в себя ещё и блочную репликацию VSM. Блочная репликация может быть синхронная или асинхронная, в то время как SnapVault и QSM SnapMirror только асинхронно реплицируют данные по расписанию. Но за то архивы SnapVault передаваемые в виде снепшотов попав на удалённую систему, могут быть продедублицированны (подобным образом работает WAFL File Folding), с содержимым предыдущих снепшотов (не путать с дедубликацией внутри активной файловой системы). Таким образом, SnapVault предоставит аналог разного рода, типов архивов, передавая на удалённую систему только изменённые данные в виде снепшотов и храня их в дедублицированном виде. Т.е. снепшоты это аналог инкрементных бэкапов, если попробовать приблизить терминологию к стандартной терминологии резервного копирования, то снепшоты у NetApp это аналог обратных инкрементальных бэкапов. Такие бэкапы (снепшоты) не нужно собирать в «полный бэкап» и тратить время, нагружая систему, при этом занимают такие архивы место как обычные инкрементальные бэкапы. Хочу обратить внимание на то, что «классическая реализация» снепшотов по технологии COW у других производителей отличается от технологии снепшотирования NetApp. Так снепшоты работающие по технологии COW имеют падение производительности, при увеличении их количества. Подробнее.
Обратной стороной SnapVault является то, что в случае разрыва отношений, данные на вторичной системе не переходят в режим чтения-записи, это же архивы, так ведь?
В связи с чем, лицензия для архивирования SnapVault намного дешевле, нежели SnapMirror. Сразу скажу, о ценах я здесь говорить не собираюсь, эти вопросы, пожалуйста, к уполномоченным лицам — к вашим интеграторам, дистрибьюторам и представителям. Я инженер и работаю с технологиями, а не ценами.
Напомню, что как в случае SnapVault, так и в случае SnapMirror лицензии не «по терабайтные», а «по-контроллерные», т.е. лицензия необходима как на источнике, так и на получателе. Приведу пример: есть две HA (два контроллера в отказоустойчивой паре) системы одна на основной, другая на резервной площадке, в сумме 4-ре контроллера, для репликации будь то SnapMirror, будь то SnapVault необходимо приобрести 4-ре соответствующие лицензии.
Иногда случается так, что при использовании SnapVault ну очень прям срочно нужно наш архив перевести в режим чтения-записи и в аварийном, экстренном или нештатном случае на базе вторичной системы поднять DR сайт. Т.е преобразовать архивную систему в DR систему, пускай, даже если она слабее основной. Так как QSM SnapMirror и внутри «под капотом» это тот же SnapVault, то это можно сделать при помощи не документированных сервисных команд.
Напомню, что все операции вы выполняете на свой собственный страх и риск, автор не несёт никаких обязательств и гарантий.
Добавляем лицензию SnapMirror, можно запросить триальную лицензию у представительства, обычно это очень быстрый процесс:
Удостоверимся, что SnapMirror выключен:
Если у вас есть лицензия FlexClone или вы заказали триальную лицензию, рекомендую ею воспользоваться, чтобы не трогать и не повредить ваши бэкап архивы, а сделать полноценную тонкую копию данных и работать уже с ней. Кстати напомню у тонкого клонирования NetApp, в отличие от к примеру, IBM Storwize блочного клонирования, нет падения производительности от любого количества таких клонов. Если лицензии нет, и вы будете конвертировать бэкап, пропустите этот шаг и перейдите к следующему.
При клонировании будут скопированы и «SnapVault отношения»
Далее выполняем магическую комбинацию из команд для конвертации:
SnapVault работает только с Qtree*, соответственно конвертировать нужно Qtree. Конвертируются в SnapMirror не только сама Qtree, но и «отношения» репликации. Таким же образом можно конвертировать и «в другую сторону» из QSM в SnapVault.
Включаем SnapMirror
Без включенного SnapMirror нельзя разорвать отношения (теперь уже SnapMirror отношения, они же конвертировались тоже)
Останавливаем отношения. И окончательно их разрываем (при необходимости) для того чтобы перевести вольюм в RW состояние.
Удаляем лицензию SnapMirror при необходимости:
Хочу обратить внимание, на то, что в результате вы сможете увидеть в актуальной файловой системе NetApp самые последние архивированы данные, которые были реплицированы и на неё, доступные на запись. А вот восстановить более старые снепшоты, можно несколькими способами:
Скопировать их ручками из снепшотов, к примеру при помощи NDMP команды ndmpcopy из командной строки СХД или скопировать все необходимые данные через хост стандартным для него способом, зайдя в скрытую папку «snapshoot».
Также можно воспользоваться ещё одной лицензией SnapRestore, которая моментально откатит актуальную файловую систему к требуемому снепшоту.
Третий вариант заключается в том, что на этапе клонирования архива (вольюма с qtree), можно клонировать не состояние актуальных данных на ФС NetApp, а один из хранимых снепшотов, таким образом, не прибегая к лицензии SnapRestore или к длительному ручному копированию.
*Qtree — Применение для репликации в системах NetApp FAS с ОС DataONTAp Cluster-Mode (Clustered ONTAP), более не требуется, так как SnapVault и SnapMirror QSM теперь умеют реплицировать и восстанавливать данные на уровне Volume.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии
В этой статье я расскажу как построенное решение «Архивация данных на NetApp» переделать в решение «Disaster Recovery».
С точки зрения бизнеса Disaster Recovery и архивирование отличаются тем, что:
- Архивирование (SnapVault) — решение предназначено для длительного хранения и защиты данных от изменений, для последующего восстановления их туда, откуда они были скопированы (или в другое место).
- Disaster Recovery (SnapMirror) — хранение данных на резервном сайте, для переключения на него (и соответственно изменения данных), в случае катастрофы.
Поясню на примере: когда у вас есть хотя бы две СХД с настроенной репликацией SnapMirror, в такой схеме одна из них играет роль источника (primary), а вторая роль приемника (Secondary). В случае аварии, при разрыве репликации (командой break, а не просто разрыв линка), принимающая (Secondary) система переведёт реплицируемое зеркало из режима read-only в режим read-write. Т.е. это инструмент для создания решения «Переключение на запасную площадку в случае аварии» (Disaster Recovery). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.
В то время, как SnapVault предназначен для архивирования на резервную (Secondary) систему, чтобы потом из неё восстановить все данные обратно на первичную систему или вообще на третью систему. Стоит отметить, что для задач архивирования очень важно хранить данные в неизменённом состоянии все время. В данном случае вторичная система, куда складываются все архивы, может быть любой модели. Здесь логично иметь самую дешевую модель NetApp FAS с медленными и дешевыми дисками большего объема. К примеру, FAS2554 или FAS2520.
Более детально как работает SnapMirror и SnapVault можно прочесть соответствующих статьях, а также сравнить эти два решения с технической точки зрения.
QSM SnapMirror работает практически также как и SnapVault и использует всё тот же алгоритм и внутреннего устройства репликации, SnapMirror кроме QSM, включает в себя ещё и блочную репликацию VSM. Блочная репликация может быть синхронная или асинхронная, в то время как SnapVault и QSM SnapMirror только асинхронно реплицируют данные по расписанию. Но за то архивы SnapVault передаваемые в виде снепшотов попав на удалённую систему, могут быть продедублицированны (подобным образом работает WAFL File Folding), с содержимым предыдущих снепшотов (не путать с дедубликацией внутри активной файловой системы). Таким образом, SnapVault предоставит аналог разного рода, типов архивов, передавая на удалённую систему только изменённые данные в виде снепшотов и храня их в дедублицированном виде. Т.е. снепшоты это аналог инкрементных бэкапов, если попробовать приблизить терминологию к стандартной терминологии резервного копирования, то снепшоты у NetApp это аналог обратных инкрементальных бэкапов. Такие бэкапы (снепшоты) не нужно собирать в «полный бэкап» и тратить время, нагружая систему, при этом занимают такие архивы место как обычные инкрементальные бэкапы. Хочу обратить внимание на то, что «классическая реализация» снепшотов по технологии COW у других производителей отличается от технологии снепшотирования NetApp. Так снепшоты работающие по технологии COW имеют падение производительности, при увеличении их количества. Подробнее.
Обратной стороной SnapVault является то, что в случае разрыва отношений, данные на вторичной системе не переходят в режим чтения-записи, это же архивы, так ведь?
В связи с чем, лицензия для архивирования SnapVault намного дешевле, нежели SnapMirror. Сразу скажу, о ценах я здесь говорить не собираюсь, эти вопросы, пожалуйста, к уполномоченным лицам — к вашим интеграторам, дистрибьюторам и представителям. Я инженер и работаю с технологиями, а не ценами.
Напомню, что как в случае SnapVault, так и в случае SnapMirror лицензии не «по терабайтные», а «по-контроллерные», т.е. лицензия необходима как на источнике, так и на получателе. Приведу пример: есть две HA (два контроллера в отказоустойчивой паре) системы одна на основной, другая на резервной площадке, в сумме 4-ре контроллера, для репликации будь то SnapMirror, будь то SnapVault необходимо приобрести 4-ре соответствующие лицензии.
Иногда случается так, что при использовании SnapVault ну очень прям срочно нужно наш архив перевести в режим чтения-записи и в аварийном, экстренном или нештатном случае на базе вторичной системы поднять DR сайт. Т.е преобразовать архивную систему в DR систему, пускай, даже если она слабее основной. Так как QSM SnapMirror и внутри «под капотом» это тот же SnapVault, то это можно сделать при помощи не документированных сервисных команд.
Напомню, что все операции вы выполняете на свой собственный страх и риск, автор не несёт никаких обязательств и гарантий.
Добавляем лицензию SnapMirror, можно запросить триальную лицензию у представительства, обычно это очень быстрый процесс:
netapp-sec1-7M> license add SNAPMIRRORCODE
Удостоверимся, что SnapMirror выключен:
netapp-sec1-7M> snapmirror off
Если у вас есть лицензия FlexClone или вы заказали триальную лицензию, рекомендую ею воспользоваться, чтобы не трогать и не повредить ваши бэкап архивы, а сделать полноценную тонкую копию данных и работать уже с ней. Кстати напомню у тонкого клонирования NetApp, в отличие от к примеру, IBM Storwize блочного клонирования, нет падения производительности от любого количества таких клонов. Если лицензии нет, и вы будете конвертировать бэкап, пропустите этот шаг и перейдите к следующему.
netapp-sec1-7M> vol clone create new_infra -b backup
При клонировании будут скопированы и «SnapVault отношения»
Далее выполняем магическую комбинацию из команд для конвертации:
netapp-sec1-7M> options snapvault.enable off
netapp-sec1-7M> priv set diag; snapmirror convert /vol/new_infra/nfs; priv set
netapp-sec1-7M> options snapvault.enable on
SnapVault работает только с Qtree*, соответственно конвертировать нужно Qtree. Конвертируются в SnapMirror не только сама Qtree, но и «отношения» репликации. Таким же образом можно конвертировать и «в другую сторону» из QSM в SnapVault.
Включаем SnapMirror
netapp-sec1-7M> snapmirror on
Без включенного SnapMirror нельзя разорвать отношения (теперь уже SnapMirror отношения, они же конвертировались тоже)
Останавливаем отношения. И окончательно их разрываем (при необходимости) для того чтобы перевести вольюм в RW состояние.
netapp-sec1-7M> snapmirror quiesce /vol/new_infra/nfs
netapp-sec1-7M> snapmirror break /vol/new_infra/nfs
Удаляем лицензию SnapMirror при необходимости:
netapp-sec1-7M> license delete SNAPMIRRORCODE
Хочу обратить внимание, на то, что в результате вы сможете увидеть в актуальной файловой системе NetApp самые последние архивированы данные, которые были реплицированы и на неё, доступные на запись. А вот восстановить более старые снепшоты, можно несколькими способами:
Скопировать их ручками из снепшотов, к примеру при помощи NDMP команды ndmpcopy из командной строки СХД или скопировать все необходимые данные через хост стандартным для него способом, зайдя в скрытую папку «snapshoot».
Также можно воспользоваться ещё одной лицензией SnapRestore, которая моментально откатит актуальную файловую систему к требуемому снепшоту.
Третий вариант заключается в том, что на этапе клонирования архива (вольюма с qtree), можно клонировать не состояние актуальных данных на ФС NetApp, а один из хранимых снепшотов, таким образом, не прибегая к лицензии SnapRestore или к длительному ручному копированию.
*Qtree — Применение для репликации в системах NetApp FAS с ОС DataONTAp Cluster-Mode (Clustered ONTAP), более не требуется, так как SnapVault и SnapMirror QSM теперь умеют реплицировать и восстанавливать данные на уровне Volume.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии
