Решил перед экзаменом разложить по полочкам темы, с которыми у меня наблюдаются пробелы, а именно OSSV и SnapMirror.
Open System SnapVault
Open System SnapVault (OSSV) – решение позволяющее производить резервное копирование и восстановление информации, которая находится на отличных от NetApp СХД или, даже, других платформах (windows, linux, vmware хосты). Смысл технологии состоит в том, что агент, который расположен на OSSV хосте, создает блочные инкрементальные резервные копии и отправляет их на СХД NetApp. Далее перемещенные OSSV резервные копии трансформируются в обычные снимки для хранения, сохраняя при этом все преимущества последних.
Данные для резервного копирования на OSSV хосте могут располагаться на локальном диске, iSCSI/FC lun и могут содержать диск, файловую систему или подкаталог. Резервные копии SMB и NFS шар OSSV не делает. После выбора информации для резервного копирования формируются соседские отношения и резервные копии передаются в указанный qtree. Сформировать отношения можно либо из CLI СХД (snapvault), либо с помощью NetApp Protection Manager.
OSSV лицензируется следующим образом: на СХД должна быть установлена лицензия SnapVault Secondary, на хосте клиентская лицензия SnapVault Platform [Windows, Linux, VMware] Primary. Для увеличения количества одновременные процессов передачи резервных копии NetApp рекомендует приобрести лицензию NearStore.
Включается OSSV на СХД с помощью команды options snapvault.enable on.
OSSV хост общается с системами NetApp посредством tcp порта 10566. В дополнения OSSV хосты слушают tcp порт 10000 для возможности управления посредством софта с поддержкой NDMP (тот же Protection Manager).
Для ограничения доступа к системе в CLI есть опция options snapvault.access host=ossv1,ossv2,ossv3…
Так как резервные копии инициируются со стороны системы хранения, то на хосте, по желанию, можно указать каким системам это самое резервное копирование будет разрешено. Делается это с помощью списков контроля доступа (QSM Access Lists).
Рекомендации по тому, который будет хранить резервные копии такие же, как и для томов содержащих lun (nosnap on, резерв под снимки в 0%, create_ucode on).
Для установления соседства и передачи первой полной копии на СХД подается команда (к примеру, нам нужно создавать резервные копии домашних каталогов пользователей):
snapvault start –S ossv1:/home/ /vol/backups/ossv1
Обратите внимание на то, что qtree ossv1 создается в процессе подачи команды snapvault start. Руками его создавать не надо.
Расписания OSSV привязаны к тому, а это значит, что все OSSV сессии, использующие в качестве точки назначения qtree, которые лежат на одном томе, будут использовать одно расписание. Создадим ежедневное рассписание, активное по рабочим дням, которое будет создавать снимки daily_bckp.#_nubmer:
snapvault snap sched –x backups daily_bckp 30@mon-fri@23
ключ -x указывает на то, что до совершения снимка необходимо закончить все трансферы резервных копий с OSSV хостов.
Создание резервных копий можно инициировать вручную с помощью snapvault update и snapvault snap create.
Восстанавливать данные следует с OSSV хоста с помощью утилиты snapvault. Восстанавливать можно как файлы, так и каталоги.
<install_dir>\bin\snapvault restore –S fas1:/vol/backups/ossv1 C:\temp\restore <install_dir>\bin\snapvault restore –S fas1:/vol/backups/ossv1/Report.doc C:\temp\restore\Report.doc
SnapMirror
SnapMirror – отдельно лицензируемая технология по репликации томов и qtrees. Данные могут быть реплицированы через IP или FC сети и инициируются с точки назначения командой snapmirror initialize.
Может работать в асинхронном (данные запрашиваются периодически на основании расписания в snapmirror.conf файле), синхронном (репликация производится постоянно) и полу синхронном режиме. Так же обновление может быть запущено руками с использованием snapmirror update.
Ключевое отличие синхронного от асинхронного режима состоит в том, что приложения не получает подтверждений о записи данных до тех пор пока информация не будут реплицирована с основной системы на резервную. Полу синхронный – есть комбинация двух предыдущих, однако в этом режиме приложению не надо дожидаться момента подтверждения записи данных с резервной СХД.
Работает SnapMirror следующим образом:
1. Сначала осуществляется полный перенос реплицируемых данных с основной СХД на резервную посредством снимка.
2. После первоначальной синхронизации основная СХД начинает обмениваться с резервной так называемыми CP – Consistency point. Этот метод позволяет убедиться в том, что все данные из памяти, которые должны будут быть записаны на диск основной СХД так же будут получены и резервной.
3. После второго, по сути асинхронного обмена, начинается передача NVLOG, который и является синхронным. Передача инициируется, как только основная система получила команду на запись и приложения получит ответ о том, что запись прошла успешно только после того, как эти же данные упадут на резервную СХД.
Репликация может использовать до двух путей в режиме отказоустойчивости или мультиплексирования.
Некоторые команды
Разорвать отношения можно с помощью snapmirror break. При этом том переходит в online режим из resctricted mode, что позволяет использовать его, как и любой другой для операций ввода-вывода. Однако опция fs_size_fixed, которая накладывается на том, как только он становится точкой назначения для SnapMirror на резервной СХД остается включенной. Если требуется «попросить» пространство, которое было зарезервировано под репликацию, обратно, то отключать ее нужно ручками.
snapmirror resync позволяет восстановить отношения, при чем роли источника и получателя можно поменять, к примеру, после сбоя на главной площадке. snapmirror resync подается на резервной СХД. Так же соседские отношения может разрушить редактирование snapmirror.conf. snapmirror resync может стать причиной потери данных на томе-получателе, если с момента разрыва отношений и на отправителе и на получателе произошли какие-либо изменения.
snapmirror quiesce позволяет завершить текущую передачу, после чего все последующие трансферы не будут инициироваться. Синхронные snapmirror при этом будут выведены из синхронного режима. Все это будет продолжаться до тех, пока вы не подадите команду snapmirror resume.
Вся информация касательно трансферов хранится на корневом томе в каталоге /etc/log.