Компания NetApp впервые в мире реализовала и запатентовала технологию снепшотирования в 1993 г. С тех пор технология естественным образом развивалась и отлаживалась. Спустя 23 года можно с полной уверенностью сказать, что снепшотирование NetApp отлично работает, не влияя на производительность, независимо от протокола: блочного или файлового. С приходом Flash технологий ИТ индустрия обратила свой взор на использование снепшотов и тонкого клонирования из-за того, что Flash пока что – дорогая технология, и её ресурсы необходимо экономить. Компания NetApp долгие годы единолично вырабатывала и несла на своих плечах парадигму резервного копирования, построенную на сшепшотах, где снепшоты были не временной необходимостью, а основой всей этой идеи, и наконец-то получила признание того, что это эффективный и правильный подход для резервного копирования и разработки. А с появлением Thing Propositioning и UNMAP снепшоты стало действительно удобно использовать и хранить как резервные копии прямо на основную, продуктивную СХД, что позволяет крайне быстро восстанавливать данные после логической ошибки. А для резервирования и защиты от выхода из строя основной СХД использовать технологии репликации данных, основанные на снепшотах, чтобы реплицировать только изменения, а не полный набор данных.


Важным преимуществом снепшотов является их возможность более быстрого снятия и восстановления без необходимости гонять трафик через хост и медиа-сервер (прокси-сервер). Ни CPU хоста, ни сетевые адаптеры не страдают от перегрузок, дисковая подсистема в случае восстановления из снепшота вообще не нагружается, а в случае восстановления из реплики нагружается намного меньше, чем при Full Backup/Restore. Это кардинально улучшает картину резервного копирования: резервные копии вместе с аппаратными снепшотами становится возможно снимать чаще, и прямо среди рабочего дня.

Но вся эта картина не полна без ПО для резервного копирования. Так как снятые и отреплицированные данные сами по себе не консистентны с точки зрения приложения, а без каталогизации всей информации их применение сильно усложняется. Компания NetApp сотрудничает с многими известными компаниями-производителями резервного ПО для того, чтобы обеспечить интеграцию их продуктов с возможностями СХД.

В этой статье я хочу рассказать о возможных схемах взаимодействия NetApp и Veeam Backup & Replication для выполнения и хранения резервных копий виртуализированной инфраструктуры.

Схема: Хранение резервных копий на основной системе в виде снепшотов

В этой схеме предусматривается запуск продуктива и хранение данных на ONTAP. Для того, чтобы работала функция каталогизации данных на LUN, необходимо иметь SnapRestore или FlexClone лицензию. Для протокола NFS, для работы каталогизации содержимого не нужна какая-либо лицензия, а для восстановления данных на ONTAP желательно наличие SnapRestore, но если её нет, будет использоваться встроенный NDMP клиент. В случае восстановления данных крайне желательно наличие лицензии SnapRestore или FlexClone, чтобы моментально восстановить любой объем данных из снепшота. Без лицензии восстановление будет выполняться при помощи операции копирования из СХД на (возможно ту же) СХД, через медиа-агент, что будет занимать какое-то время.
Важно отметить, что основная масса повреждения данных закрывается именно этой схемой, так как «логических повреждений» приходится намного больше, по сравнению с авариями или катастрофами, которые происходят, но намного-намного реже.

Хранение и восстановление резервных копий на вторичной NetApp ONTAP системе

В нижеописанных схемах предусматривается запуск продуктива и хранение данных на ONTAP и последующая их репликация на вторую (третью и т.д.) ONTAP. Как правило, применяется совместно со схемой «Хранение резервных копий на основной системе в виде снепшотов». Это позволяет более быстро восстановить данные в случае «логического повреждения» (хакеры, вирусы и т.д.), так как таких повреждений – основная масса по сравнению с катастрофами и авариями. Разница между Архивированием и DR в том, что в первом случае восстановление, как, например, в случае с ленточными носителями, всегда происходит на основную систему, туда, где данные были до этого (или на новое место, но с ленты ведь не запустишь БД например, так же и здесь). Во втором случае со SnapMirror, можно переключиться c первой (основной) на запасную (вторичную) систему, в случае аварии на площадке, и продолжить работу уже с неё. Для работы Архивации или DR необходима лицензия репликации, SnapVault или SnapMirror соответственно.
Для выполнения каталогизации LUN на основной или резервной СХД необходимо наличие на соответствующей площадке иметь SnapRestore или FlexClone лицензию.

После того, как данные отреплицируются на запасную систему, очень удобно именно там запускать каталогизацию и тестирование, чтобы этими операциями не нагружать продуктив. Опять-таки, со второй системы можно вытягивать зарезервированные данные, чтобы положить их на третичную систему (NetApp или стороннего производителя). Как в случае с NFS, так и LUN'ами (для SAN нужна лицензия FlexClone или SnapRestore), данные будут тянуться из запасной системы через медиа-агент. В случае с LUN, он будет скопирован при помощи тонкого клонирования, автоматически подключён к медиа агенту. В случае с NFS клонироваться ничего не будет, так как Veeam, как было сказано ранее, при помощи встроенного в себя агента может при помощи NFS протокола «лазить» и читать снепшоты.

VSA / Public Cloud

Данные могут быть отреплицированы как на физическую платформу NetApp FAS с ONTAP, так и на Data ONTAP Edge, ONTAP Select или в ONTAP for Cloud, расположенную внутри публичного облака.

Схема: Архивирование (SnapVault) – восстанавливаем на основную площадку

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

Схема: Disaster Recovery (SnapMirror) – восстанавливаемся на запасную площадку

Как правило, применяется совместно со схемой «Хранение резервных копий на основной системе в виде снепшотов». Это позволяет более быстро востановить данные в случае «логического повреждения» (хакеры, вирусы и т.д.). В случае катастрофы на основной площадке, запасная площадка может быть конвертирована в основную СХД. Логично, чтобы мочь это сделать, чтобы основная и запасная системы были более-менее одинаковые по производительности. Иначе стоит заранее задаться вопросом, какие самые критичные сервисы необходимо будет запустить, а какие будут не запущены. Для этого сценария может быть использован SnapMirror for SVM с одним из режимов восстановления Identity Preserve или Identity Discard. Identity Preserve сохраняет настройки сетевых адресов при «переезде», что накладывает необходимость растягивать L2 домен между площадками и требует соответствующего сетевого оборудования и каналов. Identity Discard позволяет заранее задать новые сетевые адреса (которые возникнут в момент переключения на вторичную СХД), по которым будут доступны данные на вторичной СХД, это не устраняет необходимость в специализированном оборудовании, но требует перенастройки хостов вручную или при помощи скриптов.

Данные, отреплицированные при помощи SnapMirror на вторичную (запасную СХД), могут далее быть отреплицированы на третичную NetApp Data ONTAP систему при помощи SnapVault.

Схема: Заливка резервных копий на ONTAP – таргет репозиторий архивов с аппаратным дедупом

Для того чтобы аппаратный дедуп наиболее эффективно работал, со стороны Veeam необходимо настроить в расширенных настройках Job'а политику компрессии «Dedup-friendly», чтобы блоки данных ложились по границе блока файловой системы WAFL (block misalignment) или отключить прорамный дедуп в Veeam.

Veeam Direct NFS Client

Начиная с Availability Suite v9 поддерживается Direct NFS, встроенный прямо в приложение Veeam (не путать с NFS Client for Windows), он был разработан специально для ONTAP. Это позволяет Veeam напрямую общаться с хранилищем NetApp, позволяя бекапить и восстанавливать данные напрямую, минуя гипервизор, что приводит к ускорению таких операций. Важной полезной функцией является возможность вычитывать существующие снепшоты с СХД.
Кстати, а вы знали что NFS в VMware появился точно так же, благодаря NetApp?

On-Demand Sandbox

Начиная с v9 поддерживается продукт On-Demand Sandbox for Storage Snapshots, который позволяет выполнять тонкие Hardware-Assistant копии виртуальных машин для их тестирования и разработки. Для работы этого функционала необходима лицензия, запускающая технологию FlexClone.

VVOL

Технология VVOL кардинально изменит подход резервного копирования виртуальной среды. Одной из причин тому есть принципиально другой подход снепшотирования и резервного копирования, так как VVOL использует аппаратное снепшотирование, вопрос консолидации и удаления снепшотов VMware отпадает. Из-за устранения проблемы с консолидацией снепшотов VMware снятие application-aware (аппартаных) снепшотов резервных копий перестает быть головной болью админов. Компания NetApp является технологическим партнёром и партнёром по дизайну VVOL, и поддерживает эту технологию, начиная с ONTAP версии 8.2.1 и выше. Также поддерживается функционал DR для VP что позволяет использовать аппаратную репликацию SnapMirror. Veeam также поддерживает возможность управления аппаратной репликацией SnapMirror и VVOL (по отдельности каждой). Пока что Veeam B&R не поддерживает VVOL совместно с SnapMirror, но ввиду перспективности технологии она там появится. Veeam: Virtual Volumes от компании VMware – внедрять нельзя ждать?.

NetApp AltaVault

Veeam отлично умеет взаимодействовать с AlataVault, выполняя заливку резервных копий для долговременного хранения на эту систему со всеми вышеперечисленными примерами, т.е. выступать вторичным или третичным репозиторием архивных копий. Так как AlataVault выступает как файловая шара, то Veeam туда всегда выполняет заливку данных через медиа-агент.

Выводы

Резервное копирование данных при помощи Veeam Backup & Replication совместно с аппаратными снепшотами и тонкой репликацией позволяет более часто снимать резервные копии, защищая как от логических повреждений данных (вирусы, хакеры и т.д.), так и от физического уничтожения, не нагружая CPU и сетевые интерфейсы хоста, полностью их минуя.
Veeam специально разработала NFS агент NetApp ONTAP для возможности чтения содержимого снепшотов «напрямую», как для каталогизации, так и для резервного копирования, что, в свою очередь, говорит о глубокой интеграции этих продуктов и наиболее оптимальном использовании ресурсов.
Есть множество схем репликации и резервного копирования, ещё раз подтверждая эффективность и оптимальность использования парадигмы резервного копирования, основанной на снепшотах.
Для получения наибольшего эффекта от обоих производителей, стоит применять схему Disaster Recovery (SnapMirror) – восстанавливаемся на запасную площадку с возможностью тестирования и каталогизации на резервной площадке.

Здесь могут содержаться ссылки на Habra-статьи, которые будут опубликованы позже.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.