В этой статье я рассмотрю как архитектура SnapProtect притворяет в жизнь "парадигму резервного копирования NetApp", используя передовые технологии и преимущества систем хранения, серии FAS. ПО SnapProtect (SP) предназначенно для управления жизненным циклом резервных копий, архивацией и восстановлением данных для всей инфраструктуры, расположенной на СХД NetApp FAS. SP обеспечивает связность с приложениями, консистентность при снятии резервной копии, управление репликацией/архивацией между хранилищами, каталогизацией, восстановление данных в случае необходимости, проверкой резервных копий, а также другие функции. FAS очень универсальные системы, которые могут использоваться для задач как «основной» СХД, «запасной» (DR) так и для архивации данных.
Комплекс SnapProtect состоит из следующих основных компонент:
- Сервер с SnapProtect Management Server (CommServe license), для отказоустойчивости применяется кластеризация (на уровне приложения + кластеризация БД)
- Серверы с инсталлированным MediaAgent'ами.
- Агенты iDataAgent (iDA). Устанавливаются на хосты для интеграции с ОС, файловыми системами, приложениями и другими компонентами хостовой ОС.
- SP взаимодействует с хранилищем NetApp через Oncommand Unified Manager.
Существуют такие iDA агенты:
- VSA — Для VMWare и Hyper-V
- для Oracle под Windows/Unix/Linux (В том числе с RAC)
- для Exchange (в том числе с DAG)
- для MS SQL
- для SnarePoint
- Qsnap Driver для файловых систем Win/Unix
- NAS NDMP iDA
- DB2 Unix/Linux
- Lotus Domino на Windows
- Active Directory iDA
Консистентность, как было сказано ранее выполняется по средством агента iDA установленного на хосте перед снятием hardware-assistant SnapShot на стороне хранилища.
Репликация (консистентных) снепшотов между стореджами может быть выполнена при помощи SnapMirror или SnapVault.
Заливка данных с основной или резервной системы на ленточную библиотеку выполняется через медиа агент для SAN и NAS данных. Также для NAS можно выполнять заливку данных напрямую с хранилища NetApp на ленточную библиотеку по средством протокола NDMP и SMtape, к сожалению, в этом случае не поддерживается каталогизация данных.
Катологизация выполняется как пост-процесс при помощи примапливания клонированных (технология FlexClone) снепшотов с хранилища NetApp.
Восстановление данных может быть выполнено как с удалённого хранилища, локального, так и с ленточной библиотеки.
Есть несколько способов (можно даже сказать путей) восстановления, в зависимости от типа данных, типа восстановления и размещения этих данных.
Так для восстановления всего вольюма или qtree из снепшота на локальном хранилище может быть задействована технология моментального восстановления средствами хранилища из снепшота — SnapRestore. При аналогичном восстановлении но из удалённой системы, потребуется выполнить «обратную репликацию» при помощи технологии SnapMirror или SnapVolt. Реплицировать можно не только самые последние данные, но и один из снепшотов расположенный на удалённом хранилище.
При необходимости «гранулярного восстановления», внутренеяя логика выглядит как клонирование снепшота удалённой или основной системы и подключения его к медиа агенту, дальше выполняется перенос необходимых объектов из медиа агента на требуемых хост. Восстановление из ленточной библиотеки происходит аналогичным образом — через медиа агент на хост.
Технологии необходимые на хранилищах:
Таким образом подытожив можно сказать, что на основном сайте обязательно должны присутствовать технологии FlexClone, SnapRestore, одна из лицензий репликации (SnapVault/SnapMirror) и собственно сам SnapProtect.
На резервном хранилище, соответственно необходимо наличие FlexClone если каталогизация будет выполняться там. Если по схеме резервного копирования/восстановления требуется иметь возможность быстрого восстановления вольюма из снепшота на удалённом хранилище, то на таком хранилище необходимо наличие технологии SnapRestore. Так как мы реплицируем данные с основной системы на удалённую, то также на удалённой системе необходима поддержка технологии репликации (SnapVault/SnapMirror). Ко всему прочему нужна поддержка самого SnapProtect.
Как результат, NetApp жестко регламентирует дополнительные лицензии на основной и резервной СХД для развертывания архитектуры SnapProtect:
Гранулярное восстановление.
Под гранулярностью восстановления понимается возможность восстановления не целого луна/вольюма с данными, а отдельных объектов или файлов находящегося на луне. К примеру для виртуальной инфраструктуры таким объектом может быть виртуальная машина, файл виртуальной машины, vDisk или отдельные файлы внутри виртуальной машины. Для Баз данных таким объектом может быть отдельный инстанс базы. Для Exchange это может быть отдельный почтовый ящик или отдельное письмо и т.д.
SAN + Грануляный бекап и восстановление
В случае с применением SAN архитектуры с приложениями требующих гранулярного восстановления, таких как Exchange, Oracle, MS SQL и других, необходимо данные таких приложений размещать на отдельном выделенном луне. В случае применения виртуализации с такими приложениями действует то же правило: необходимо размещать данные от этих приложений на отдельно выделенном RDM диске. Сами же луны на стороне системы хранения должны, каждый, лежать в отдельном вольюме. К примеру в случае виртуализации с БД Oracle и использованием SAN сети, необходимо выделить под каждый тип данных для этой БД отдельный лун, подключённый в виде RDM, точно по таким же правилам, как если бы вместо SnapProtect мы использовали SnapManager. Т.е. логика разбиения и размещения дисков для SnapProtect будет такая же как и для SnapManager, здесь действуют одни и те же правила. Ведь и технологии консистентного снятия hardware-assistant снепшотов в обоих случаях схожие, если не сказать идентичные.
Подробнее рассмотреть этот пример можно в моей статье «SnapManager for Oracle & SAN сеть» на хабре.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии
Автор: bbk
