about NetApp

??так, в прошлом посте я показал подробно, что за средства репликации данных есть у NetApp, и почему так получилось, что для синхронной репликации есть целых два решения, а также чем отличаются синхронная и асинхронная репликация для тех, кто это пока еще нетвердо знал.

Начнем же подробнее про именно SnapMirror.

Для начала стоит сказать, что SnapMirror, как ни странно, также существует в двух существенно отличающихся “технических ипостасях”, это так называемый Volume SnapMirror (VSM), и так называемый QTree SnapMirror (QSM). Эти два режима существенно отличаются особенностями своей работы, поэтому об этих отличиях стоит знать и уметь эти отличия применять себе на пользу.

Я уже упомянул в прошлом посте о том, что основой SnapMirror является технология снэпшотов, то есть создания мгновенных копий состояния дискового тома. В снэпшоте хранятся только изменения, поэтому он сравнительно невелик по размерам, и, перенеся его на получателя репликации, например на удаленную систему, мы с легкостью перенесем на нее все изменения с исходного стораджа, сэкономив время и трафик. Репликацию можно выполнить по локальной сети Ethernet, через любой IP-канал, в том числе WAN, а при определенных условиях, через FC, но для этого нужны специальные адаптеры в контроллер, и такой вариант считается редкостью и приеняется нечасто. Обычно возможностей и пропускной способности IP-сети вполне достаточно для репликации.

Оба этих режима, как Volume SnapMirror, так и QTree SnapMirror используют для своей работы снэпшоты, но в остальном они существенно отличаются.

Volume SnapMirror:

• Блочная репликация, блок-в-блок диска, без учета содержимого и файловой структуры.
• Репликация всегда один-в-один том.
• Поддерживается синхронный, полусинхронный и асинхронный режимы.
• Не страдает производительность при большом объеме мелких файлов или глубоко вложенных директориях
• ??сходный том во время репликации доступен для записи и чтения, том-получатель репликации – readonly.
• Неприменимы квоты на томе-получателе
• Сохраняются дедупликация, компрессия, и прочие свойства данных на томе-источнике, а также сделанные на нем снэпшоты, которые тоже переносятся на получателя репликации.
• Не поддерживается репликация между томами разных систем, то есть между traditional и flexvol
• Начиная с 8.1 поддерживаются репликации между томами 32-bit и 64-bit
• Версия Data ONTAP на системе-получателе репликации должна быть идентична источнику, или новее его.

QTree SnapMirror:

• “Логическая”, файловая репликация. Файлы и директории создаются последовательно на томе-получателе в процессе репликации
• Неважно каков будет том-получатель, он может быть иной структуры и размера, чем том-источник.
• Можно организовать репликацию “много QTree с разных источников – на один том-получатель”
• Том как источника, так и получателя может быть доступен для записи, но реплицируемый в данный момент qtree-получатель будет readonly, остальные qtree тома – доступны на запись.
• Возможна только асинхронная репликация
• Не поддерживает каскадированную репликацию
• Глубоко вложенные директории или директории с большим количеством файлов при репликаци могут вызвать падение производительности и высокую нагрузку на контроллер.

Как вы видите, подчас может показаться, что QSM и VSM это вообще две разных системы репликации, да, в общем-то, так оно и есть :)

Основная настройка репликации SnapMirror производится изменениями записей в конфигурационном файле snapmirror.conf, находящемся на /etc

Для того, чтобы настроить репликацию, прежде всего убедитесь, что на системе есть нужные лицензии SnapMirror, если нет – добавьте их на обоих системах, и получателе, и источнике, командой:

license add [license_number]

Затем укажите, что две эти системы взаимно будут находиться в отношениях репликации (relationship), это настроит соответствующие сетевые порты на обеих системах.

filerA > options snapmirror.access host=filerB

filerB > options snapmirror.access host=filerA

Теперь можно задать конфирурацию репликации в файле snapmirror.conf строкой в формате:

Source-storage-system-name:source-path destination-storage-system-name:destination-path arguments schedule

В arguments можно, например, задать максимальную полосу, используемую репликацией: kbps=3000 означает, что максимально от канала связи между источником и получателем будет заниматься не более 3000 kilobit/s. Это поможет вам ограничить “аппетиты” репликации, и сделать так, чтобы репликация не забивала совместно используемый канал, и не влияла на обычную работу систем.

Расписание репликации (schedule) задается в формате, известном как CRON format:

minute hour day-of-month month day-of-week

Цифра (или диапазон) указывает конкретную величину, а “звездочка” в позиции – любое, срабатывает всегда. Например значение расписания 10 22 * 1,3,4 будет значить:

• 10 – запускать репликацию по прохождении 10 минут от начала часа
• 22 – в 22 часа
• * – в все дни месяца
• 1,3,4 – в понедельник (1), среду (3) и четверг (4)

Расписание 10 * * * * задает старт репликации каждые 10 минут, а 15 7,19 * 1,2,3,4,5 – запуск репликации в 7:15 утром и 19:15 вечером, каждого буднего дня (1,2,3,4,5) с понедельника по пятницу. Как видите, несмотря на некоторую аскетичность, механизм расписания позволяет задавать его довольно произвольно.

Обратите внимание, что даже если вы не планируете использовать SnapMirror (и SnapVault, тема нашего следующего поста в Back-to-Basics) в реальной жизни, вам все равно придется крайне досконально проштудировать тему, если вы нацелитесь сдать нетапповскую сертификацию, например NCDA (NetApp Certified Data Administrator), там ОЧЕНЬ много вопросов по настройке SnapMirror и SnapVault.

??так, если все настройки в snapmirror.conf сделаны, можно начать репликацию. Если репликация до этого не делалась, и том-получатель пока “чистый”, то придется, первым шагом, выполнить так называмый baseline transfer, полную начальную передачу всех даных на томе-источнике на том-получатель. Для осуществления репликации, том-получатель (в нашем примере – volA на filerB) должен находиться в состоянии, называемом restricted, и назначаемым тому специальной командой.

filerB > vol restrict volA

filerB > snapmirror initialize -S filerA:volA filerB:volA

Baseline transfer, это, конечно, довольно продолжительная процедура. Посмотреть процесс ее выполнения можно с помощью команды:

filerB > snapmirror status

Обратите внимание: Никогда не удаляйте вручную автоматически созданный внутри процедуры SnapMirror снэпшот тома. В этом случае SnapMirror не сможет определить инкрементальные блоки для репликации, и снова начнет полную репликацию baseline transfer. Впрочем, иногда это можно сделать специально, для переинициализации SnapMirror и траблшутинга.

Вы также можете разрешить системе вести лог репликации, укажите options.snapmirror.log enabled, и вслед за этим в файл /etc/log/snapmirror будет выводиться лог репликации.

Если репликация не запускается, то, среди прочего, проверьте нет ли между двумя системами файрволла. При работе SnapMirror использует группу портов от номера 10565 до 10569. Самое простое (и, в целом, безопасное) решение – открыть для IP системы-получателя и системы-источника диапазон портов TCP 10565-10569 в обоих направлениях.

Baseline transfer отработал успешно, и на протяжении долгого времени репликация передает изменения с тома FilerA на том FilerB. Но вот настал момент, когда нам потребовалось воспользоваться репликой данных. Для этого, прежде всего, надо разорвать отношения репликации, break relationship.

filerB > snapmirror break <volume name>

При этом том-получатель и данные на нем становятся доступными.

Для временной приостановки репликации, без ее разрыва, используется команда:

filerB > snapmirror quiesce <volume name>

Если после разрыва репликации вам потребовалось их вновь восстановить не проводя baseline transfer, это делается процедурой resync:

filerB > snapmirror resync filerB:volume-name

Для разрыва репликации насовсем, используется другая команда, отдаваемая  на файлере-источнике:

filerA > snapmirror release source_vol filerB:dest_vol

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

Другим интересным вариантом использования SnapMirror является система “дистрибуции контента”, например передачи содержимого определенных папок, с документами или иной подобной информацией, с главного стораджа, например в головном офисе, на системы филиалов. С учетом того, что репликация осуществляется только изменений, к тому же используется компрессия в канале передачи данных, подобная репликация может быть весьма выгодной и эффективной.