about NetApp

Продолжим наш курс Back to basics. Кроме репликации SnapMirror у NetApp есть еще один Snap-что-то продукт – SnapVault. Давайте посмотрим, что это и для чего может в жизни сгодиться.

SnapVault, как можно догадаться из названия, это средство, позволяющее сложить снэпшоты (Snap) на долговременое хранилище (Vault), то есть это такое средство бэкапа данных с системы хранения, например главной, рабочей, или, в терминах NetApp – Primary, на резервную, или Secondary.

Зачем? Ну, зачем вообще используется резервное копирование на другой сторадж? Чтобы обезопаситься и обезопасить данные от физического отказа системы хранения. Почму бы для этого не использовать SnapMirror? Очень просто. Потому же, почему RAID это не бэкап. Репликация никак не поможет в случае повреждения непосредственно данных. Поврежденные данные, например испорченные на уровне приложения, точно также отреплицируются на резервную систему, и вы будете иметь два комплекта плохих данных. Тут выручили бы снэпшоты. Но снэпшоты, как вы помните, хранятся на самой системе хранения, непосредственно на исходном томе, такова их принциппиальная конструкция, и если мы вдобавок ко всему, имеем поврежденную или физически потерянную primary систему хранения, то вместе с ней погибнут и данные снэпшотов. Хорошо бы эти снэпшоты уметь выносить куда-то наружу, чтобы потом иметь возможность из них исходные данные не любой сохраненный момент восстанавливать. Вот как раз этим и занимается SnapVault.

SnapVault позволяет передавать для хранения снэпшоты томов с одной или множества primary-систем хранения, тех, которые хранят собственно ваши рабочие данные, на одну secondary, где они и складируются. В роли такой системы, кроме физического стораджа NetApp, может работать также Data ONTAP Edge-V, то есть виртуальная машина с Data ONTAP в ней.

Для использования SnapVault вам нужно иметь две лицензии, отдельно для primary-системы (sv_ontap_pri), и отдельно для secondary (sv_ontap_sec).

?? в случае SnapVault мы впервые всерьез сталкиваемся с таким элементом иерархии данных Data ONTAP как Qtree. Что это я уже тут, было дело, писал. Вкратце – это “папка” уровнем иерархии выше тома (volume), и ее можно рассматривать как поддиректорию на томе-корне. Свойством Qtree, откуда и пошло ее название, является то, что на нее можно назначить пользовательскую и групповую квоту (Quota Tree). ??менно QTree является базовым элементом структуры, которой оперирует SnapVault, именно с уровнем QTree он и работает. Даже если на primary-системе данные не располагаются в QTree, например лежали прямо в корне тома, на Secondary она будут помещены в структуры Qtree.

Как и в случае SnapMirror все начинается с процесса первоначальной передачи данных – Initial (baseline) Transfer. После успешного завершения Baseline transfer, далее по расписанию на secondary-систему передается только изменения, как это и принято в Snap-продуктах.

На файрволлах между системами, участвующих в процессе обмена данными SnapVault должны быть открыты в обоих направлениях порты: 10000 – для операций управления протокола NDMP, используемому в SnapVault, а также 10566, это порт, по которому осуществляется основной обмен данными в SnapVault.

Если у вас уже развернута инфраструктура управления, в частности NetApp Protection Manager, то удобно настроить политики резервного копирования для SnapVault именно через него. Но для небольших систем, например для всего пары, primary – secondary, все настройки можно делать и так, через командную строку.

Логи операций SnapVault вы можете найти в обычном месте, в /etc/log

При необходимости настроить throttling, то есть ограничение по загрузке канала между системами, следует воспользоваться опцией > options replication.throttle.enable on|off как видно из ее названия, она работает глобально на все операции репликации.

Наконец, немного про дедупликацию. Как вы помните из моего рассказа про SnapMirror, в SM существует два режима, Volume SnapMirror (VSM), при котором на систему-получатель передается полный образ тома, включая все особенности его структуры, снэпшоты и, в том числе, компресия и дедупликация. ?? QTree SnapMirror, в котором репликация происходит пофайлово, и при этом, конечно, дедупликация не передается, дедуплицированный файл считывается для передачи как файл, соответственно “разжимается”, и в таком виде передается и записывается. Также работает и SnapVault.

Однако, у SV есть интересный механизм, помогающий с дедупликацией. SnapVault может автоматически стартовать процесс дедупликации сразу после окончания передачи данных на secondary_систему, то есть получатель и хранитель бэкапов. Помните, однако, что таким образом, например при передаче множества primary на одну secondary, может быть стартовано сразу множество процессов дедпликации, это это может повлиять на производительность secondary-системы. В текущей версии Data ONTAP одновременно может работать до восьми процессов дедупликации на одном контроллере, остальные заносятся в очередь, и запускаются по мере окончания работы ранее стартовавших.

Давайте рассмотрим на примерах, как происходит настройка и использование SnapVault. FilerA это система-источник, та, что сохраняет свои данные, FilerB – получатель, та, что хранит бэкапы.

Предположим, что лицензии у нас уже введены, если же нет – вводим их

filerA> license add <sv_ontap_pri>

filerB> license add <sv_ontap_sec>

Разрешаем взаимный доступ участвующих систем

filerA> options sanpvault.enable on

filerA> options snapvault.access all

filerB> options sanpvault.enable on

filerB> options snapvault.access all

Создадим Qtree для бэкапируемых данных на стороне системы-источника, сделаем так “для порядку”, напомню, что бэкапить можно и данные не в Qtree, но с ними удобнее и более “аккуратненько”. Qtree на стороне-получателе создастся автоматически при начале baseline transfer.

filerA> qtree create /vol/vol_primary/qt

Настроим расписание работы SnapVault

filerA> snapvault snap sched vol_primary sv_hourly 6@0-23

filerB> snapvault snap sched -x vol_secondary sv_hourly 24@0-23

??, наконец, запустим baseline transfer

filerB> snapvault start -S filerA:/vol/vol_primary/qt /vol/vol_secondary/qt

Обратите внимание, создание и передача бэкапа инициируется с системы-получателя, с secondary! При выполнении этой команды на secondary-системе создастся Qtree с именем qt, и начнется передача состояния указанного Qtree с данными в этот Qtree-папку.

Проверим статус передачи. Эта команда работает и на системе-источнике, и на получателе.

snapvault status -l filerA:/vol/vol_primary/qt

или просто

snapvault status

При необходмости обновим состояние “бэкапа” инициировав передачу данных вручную. Снова, обратите внимание, это делается командой с системы-получателя, хранящей бэкапы!

filerB> snapvault update /vol/vol_secondary/qt

 

Теперь посмотрим, как можно сделать восстановление данных:

filerA> snapvault restore -S filerB:/vol/vol_secondary/qt /vol/vol_primary/qt

 

Отключим более ненужные реплики, например для уже неиспользуемых систем. Снова, как и выше, FilerA это источник данных, то, что бэкапим, FilerB – получатель, то, куда бэкапим.

Определим кто у нас получатель

filerA> snapvault destinations

Отцепляем уже ненужные реплики

filerA> snapvault release /vol/vol_primary/qt filerB:/vol/vol_secondary/qt

Останавливаем сервис snapvault

filerB> snapvault stop -f filerB:/vol/vol_secondary/qt

Убираем расписания

filerA> snapvault snap unsched -f vol_primary sv_hourly

filerB> snapvault snap unsched -f vol_secondary sv_hourly

Удаляем старые копии

filerA> snap list vol_primary

filerA> snap delete vol_primary <snapshot name>

filerB> snap list vol_secondary

filerB> snap delete vol_secondary <snapshot name>

 

Ресинхронизируем реплику SnapVault (снова, обратите внимание, делается с secondary).

filerB> snapvault start -r -S filerA:/vol/vol_primary/qt filerB:/vol/vol_secondary/qt

 

Отдельно в нашей теме стоит такой интересный продукт, как OSSV или Open Systems SnapVault, это программный продукт, разработанный для того, чтобы подключить к secondary-SnapVault системе, то есть той, которая принимает данные резервных копий, и хранит бэкапы, сервера под управлением Windows, Linux, и прочие системы, иногда называемые “Open Systems”. То есть OSSV это такая система резервного копирования для ваших серверов, также построенная на снэпшотах состояния дисков, но бэкапящая не сторадж NetApp на другой сторадж NetApp, а обычные сервера с обычными приложениями и OS на хранилище NetApp, как параллельно обычному SnapVault, так и просто так, само по себе. Разработал OSSV, кстати, сторонний разработчик, компания Bakbone, автор сравнительно малоизвестного, но славящегося своей многоплатформенностью и широкой поддержкой странных разнообразных приложений, продукта резервного копирования NetVault. OSSV, кстати, совместим с NetVault, в том числе может с него управляться, и, в отличие от него, бесплатен для пользователей NetApp. Но тему OSSV и его использования мы рассмотрим как-нибудь отдельно.