Быть сертифицированным NetApp хостинг-провайдером — значит предоставлять дифференцированные и, что немаловажно, качественные сервисы, базирующиеся на проверенной продуктовой линейке именитого вендора. Плюсом решений NetApp является простая и легкая интеграция с публичными облаками NetApp хостинг-провайдеров, что позволяет заказчикам строить гибкую, надежную и многофункциональную инфраструктуру. Продуктовая линейка NetApp включает в себя множество различных решений и технологий, ориентированных в первую очередь на работу с облачной инфраструктурой.
На сегодняшний день, когда доступность информации является важной составляющей любого бизнеса, использование решения, позволяющего выполнять репликацию критически важных данных с NetApp клиента в облако NetApp сервис-провайдера, становится все более и более востребованным. В этом материале мы хотим рассказать вам об основных преимуществах технологии репликации NetApp SnapMirror, пользоваться которой не только просто и удобно, но еще и полезно. Заметьте, что помимо репликации в NetApp SnapMirror доступна функциональность послеаварийного восстановления для различных СХД NetApp.
В чем преимущества репликации, выполняемой со стороны клиента в облако NetApp хостинг-провайдера? В первую очередь в гибкости, эффективности и надежности.
Почему это гибко
Репликация между клиентской площадкой NetApp и площадкой NetApp хостинг-провайдера может выполняться синхронно либо асинхронно. В асинхронном режиме применимы различные схемы: «один — один», «один — множество», «множество — один», «множество — множество».
Почему это эффективно
Благодаря возможному уплотнению данных, начиная с DataONTAP 7.3.2 объем трафика SnapMirror при репликации томов стал существенно меньше. При этом сама репликация выполняется в режиме онлайн, не затрагивая работу продакшен-сервисов. Кроме этого, репликация NetApp работает через штатные IP-сети, соответственно, клиентам нет необходимости тратить деньги на построение выделенной Fiber Channel сети.
Почему это надежно
Не стоит списывать со счетов чрезвычайные ситуации. С помощью NetApp SnapMirror можно проверять эффективность намеченного плана мероприятий в реальных условиях, это не будет влиять на штатный режим работы компании и расписание самой репликации. С целью защиты данных от повреждения создается набор моментальных снимков, который хранится на резервной площадке NetApp хостинг-провайдера. Благодаря этому можно откатываться в состояние до момента «разрушения».
Особенности технологии репликации NetApp SnapMirror
В одном из материалов мы рассказывали про технологию SnapMirror. В продолжение темы предлагаем ответить на вопросы: как работает SnapMirror, как выполнить основные шаги конфигурации и какие плюсы можно получить от использования этой технологии? SnapMirror давно зарекомендовала себя как технология, позволяющая реплицировать измененные данные между массивами NetApp клиента на удаленную площадку/площадки IaaS-провайдера , обеспечивая высокую скорость и возможность эффективного использования каналов.
Как работает SnapMirror?
Напомним, что при помощи SnapMirror осуществляется копирование данных с Protected Site клиента на Recovery Site облачного провайдера. А в ситуации, когда выполняется обновление на Protected Site, SnapMirror реплицирует (синхронно илиасинхронно) данные на Recovery Site. Для обеспечения прозрачности процесса используется технология Snapshot с основной площадки клиента. То есть создается моментальный снимок данных, после чего изменения, произошедшие с момента последнего созданного Snapshot, попадают на Recovery Site поставщика услуг. Поскольку моментальный снимок создается прозрачно, никакого влияния на основной сайт не происходит.
Конфигурация SnapMirror с помощью OnCommand System Manager
Как настроить SnapMirror и запустить процесс репликации, если вы — компания с собственной инфраструктурой, выбравшая удаленную площадку поставщика облачных услуг «ИТ-ГРАД» для хранения там своей реплики? Все просто: достаточно воспользоваться NetApp OnCommand System Manager и ответить на несколько вопросов мастера. Для наглядной демонстрации функциональности SnapMirror мы подготовили стенд с двумя кластерами, один из которых ассоциирован с сайтом клиента, другой — с удаленной площадкой облачного хостинг-провайдера. Выглядит стенд следующим образом:
Пример стенда для наглядной демонстрации функциональности SnapMirror
На что стоит обратить внимание? Конечно же, на нюансы. Дело в том, что при конфигурации SnapMirror создаются так называемые SnapMirror Relationship, которые необходимо установить между кластером клиента и кластером поставщика. Устанавливать SnapMirror Relationship в System Manager необходимо со стороны кластераназначения (destinationcluster). Для этого выбираем созданный в «ИТ-ГРАД» SVM (vs1_dest)->Vserver ->Protection->Create ->Mirror.
Начальная конфигурация SnapMirror
В открывшемся окне необходимо идентифицировать кластерназначения, в нашем примере это cluster01, а после определить кластеристочник. Если peer кластера не установлен, необходимо это сделать, иначе будет невозможным интеркластерное взаимодействие и дальнейшая конфигурация. Обратите внимание, что для каждого узла кластера нужно задать IP-адреса.
Создание peer кластера
Дальше выбираем SVM клиента. Если SVM клиента не имеет peer с SVM провайдера, System Manager создаст его для обоих SVM. Следующий шаг — выбираем том на стороне SVM клиента.
Выбор тома на стороне SVM источника
После чего необходимо выбрать том на стороне SVM провайдера. Если том отсутствует, его необходимо создать.
Пример создания нового тома
Следующий шаг:
создаем политику SnapMirror и определяем расписание репликации либо выбираем уже существующую политику. Обратите внимание, что при создании новой политики SnapMirror мастер предлагает задать имя и уровень «Transfer Priority», который можно изменить в дальнейшем. Возможны два варианты: обычный (Normal), который устанавливается по умолчанию,и низкий (Low).
Создание MirrorPolicy и определение TransferPriority
Что касается расписания, как отмечалось выше, можно использовать уже имеющееся либо создать новое. Для определения параметров нового расписания в окне мастера выбираем опцию «создать новое расписание» (Create New Schedule).
Необходимо задать отображаемое имя, установить, насколько часто будет выполняться заданное действие, указать дату и время выполнения операции.
Создание нового расписания
После создания SnapMirror Relationship для автоматического запуска SnapMirror необходимо включить опцию Start Baseline.
Включение опции StartBaselineTransfer
По окончании работы мастера вы увидите статус и суммарную конфигурационную информацию.
Отображение статуса и суммарной информации SnapMirrorRelationship
Управление SnapMirror Relationship
Для управления SnapMirror Relationship в System Manager необходимо вызвать контекстное меню и выбрать «Операции» (Operations), где будут доступны опции, проиллюстрированные ниже:
Доступные опции в меню «Операции» SystemManager
Учтите, что опции, выделенные серым цветом, в текущем состоянии SnapMirror Relationship не могут быть задействованы.
Предлагаем рассмотреть возможные опции контекстного меню SystemManager:
- Редактировать (Edit). Редактировать расписание SnapMirror Relationship.
- Удалить (Delete). УдалитьSnapMirror Relationship. Обратите внимание, что эта функция не удаляет том назначения.
- Инициализировать (Initialize). Выполняет первоначальную базовую передачу данных для новых SnapMirror Relationship.
- Обновить (Update). Выполняет обновление SnapMirror Relationship по требованию, реплицируя любые новые данные и имеющиеся копии снэпшотов, созданные после последнего выполненного обновления, в пункт назначения.
- Заморозить (Quiesce). Прекращает в дальнейшем любые обновления SnapMirror Relationship.
- Возобновить (Resume). Возобновляет SnapMirror Relationship, которые были заморожены.
- Восстановить (Restore). Восстанавливает копии снимка из тома источника в том назначения.
- Приостановить (Break). Переводит том назначения в режим read/write.
- Ресинхронизация (Resync). Восстанавливает разорванные отношения до того момента, как произошла приостановка SnapMirror.
Важно! Если SnapMirror Relationship были разорваны, удалены и затем заново воссозданы, необходимо выполнить ресинхронизацию SnapMirror, чтобы тома повторно синхронизировались без выполнения повторной базовой конфигурации. Эта функциятребует наличия общей копии снимка на обоих томах.
- Обратить/Ресинхронизировать (Reverse/Resync). Автоматизирует некоторые шаги, чтобы «обратить» SnapMirror Relationship, пересоздать их и затем повторно синхронизировать. Это необходимо, если существующие отношения находятся в состоянии разрыва. Необходимо определить, какие исходные тома не задействованы клиентами, поскольку операция Reverce/Resync переводит оригинальный том источника в режим «только чтение» и повторно синхронизируется с площадкой назначения. При выборе этой функции System Manager отобразит окно подтверждения, указывая на то, какая операция может быть выполнена.
- Прервать (Abort). Отменяет текущий прогресс трансфера.
Новая «фича» в Clustered Data ONTAP 8.3, или Как настроить гибкую репликацию на основе версий?
Определение. Гибкая репликация на основе версий — это новая возможность, появившаяся в Clustered Data ONTAP 8.3, которая снимает ограничения с контроллеров назначения кластерной системы Data ONTAP, в основе которой лежит номер версии равный или больший, чем номер версии контроллера источника.
- MirrorLatest — эта функция похожа на Qtree SnapMirror, реализованная в 7-Mode. Ее суть заключается в том, что создается копия снимка активной файловой системы и передается от кластера источника до кластера назначения.
- MirrorAllSnapshots похожа на дефолтный SnapMirror. Все копии снимков источника, включая копию снимка активной файловой системы SnapMirror, передаются от источника в место назначения.
- MirrorAndVault дает возможность выполнять аварийное восстановление и резервное копирование в один и тот же том.
Сконфигурировать гибкую репликацию на основе версий, используя политику MirrorAllSnapshots, можно прописать в командной строке:
Давайте рассмотрим сценарий, когда заказчик использует SnapMirror в Clustered Data ONTAP 8.2, но хочет начать применять гибкую репликацию на основе версий, которая реализована в Clustered Data ONTAP 8.3, используя при этом единственный том назначения как для аварийного восстановления, так и для резервного копирования. Что для этого необходимо?
В первую очередь, выполнить апгрейд кластера. То есть кластер источника и кластер назначения должны соответствовать версии Clustered Data ONTAP 8.3. (Обратите внимание на то, что peerclusterи peer SVM созданы.) Дальше выполним следующее:
- Создадим том на стороне кластера клиента:
- Создадим так называемый DataProtection том на удаленном кластере в облаке IaaS-провайдера:
- Создадим SnapMirror Relationship между кластером клиента и кластером IaaS-провайдера.
4. Инициализируем SnapMirror Relationship:
5. Выполним преобразование SnapMirror в гибкую репликацию на основании версий. Для этого первоначально удалим SnapMirror:
6. Выполним разрыв SnapMirror:
7. Создадим SnapVault:
8. Выполним ресинхронизацию SnapMirror:
По завершении текущих шагов можно настроить расписание и политику, согласно которым будут сохраняться копии снимков на стороне назначения. Обращаем ваше внимание, что после перехода на гибкую репликацию на основе версий будет невозможно выполнить конвертацию в обратный дефолтный SnapMirror Relationship.
Заключение
В заключении, как обычно, стоит подвести итоги и сделать выводы.Технология NetApp SnapMirror пользуется популярностью у компаний различного формата. Простая в обращении, недорогая по сравнению с конкурирующими продуктами, технология SnapMirror остаётся предпочтительным средством репликации и послеаварийного восстановления.
