Как стать автором
Обновить

Архитектура резервного копирования на системах NetApp FAS

Время на прочтение 4 мин
Количество просмотров 5.9K
В этой статье я рассмотрю как архитектура 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.

Восстановление данных может быть выполнено как с удалённого хранилища, локального, так и с ленточной библиотеки.
Есть несколько способов (можно даже сказать путей) восстановления, в зависимости от типа данных, типа восстановления и размещения этих данных.

Так для восстановления всего Volume или qtree из снепшота на локальном хранилище может быть задействована технология моментального восстановления средствами хранилища из снепшота — SnapRestore. При аналогичном восстановлении но из удалённой системы, потребуется выполнить «обратную репликацию» при помощи технологии SnapMirror или SnapVault. Реплицировать можно не только самые последние данные, но и один из снепшотов расположенный на удалённом хранилище.

При необходимости «гранулярного восстановления», внутреняя логика выглядит как клонирование снепшота удалённой или основной системы и подключения его к медиа агенту, дальше выполняется перенос необходимых объектов из медиа агента на требуемых хост. Восстановление из ленточной библиотеки происходит аналогичным образом — через медиа агент на хост.

Технологии необходимые на хранилищах:
Таким образом подытожив можно сказать, что на основном сайте обязательно должны присутствовать технологии FlexClone, SnapRestore, одна из лицензий репликации (SnapVault/SnapMirror) и собственно сам SnapProtect.

На резервном хранилище, соответственно необходимо наличие FlexClone если каталогизация будет выполняться там. Если по схеме резервного копирования/восстановления требуется иметь возможность быстрого восстановления Volume из снепшота на удалённом хранилище, то на таком хранилище необходимо наличие технологии SnapRestore. Так как мы реплицируем данные с основной системы на удалённую, то также на удалённой системе необходима поддержка технологии репликации (SnapVault/SnapMirror). Ко всему прочему нужна поддержка самого SnapProtect.

Как результат, NetApp жестко регламентирует, для «двухсайтовой модели», дополнительные лицензии, на основной и резервной СХД для развертывания архитектуры SnapProtect:



Гранулярное восстановление.
Под гранулярностью восстановления понимается возможность восстановления не целого LUN/Volume с данными, а отдельных объектов или файлов находящегося на LUN. К примеру для виртуальной инфраструктуры таким объектом может быть виртуальная машина, файл виртуальной машины, vDisk или отдельные файлы внутри виртуальной машины. Для Баз данных таким объектом может быть отдельный инстанс базы. Для Exchange это может быть отдельный почтовый ящик или отдельное письмо и т.д.

SAN + Грануляный бекап и восстановление
В случае использования архитектуры SnapProtect с SAN сетью, необходимо данные приложений, требующие гранулярного восстановления (таких как Exchange, Oracle, MS SQL и других), размещать на отдельном выделенном LUN. В случае применения серверной виртуализации с такими приложениями действует то же правило: необходимо размещать данные от этих приложений на отдельно выделенном RDM диске. Сами же LUN'ы на стороне системы хранения должны, каждый, лежать в отдельном Volume. К примеру в случае виртуализации с БД Oracle и использованием SAN сети, необходимо выделить под каждый тип данных для этой БД отдельный LUN, подключённый в виде RDM, точно по таким же правилам, как если бы вместо SnapProtect мы использовали SnapManager. Т.е. логика разбиения и размещения дисков для SnapProtect будет такая же как и для SnapManager, здесь действуют одни и те же правила. Ведь и технологии консистентного снятия hardware-assistant снепшотов в обоих случаях схожие, если не сказать идентичные.

Подробнее рассмотреть этот пример можно в моей статье «SnapManager for Oracle & SAN сеть» на хабре.



Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии
Теги:
Хабы:
+11
Комментарии 8
Комментарии Комментарии 8

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн