DataMotion for Volumes

Хотя эта функциональность появилась еще в Data ONTAP 8.0.1, она все еще не слишком известна и не слишком широко используется, отчасти из-за некоторых ограничений, а, по большей части, все же из-за малознакомости “широкому кругу” юзеров NeApp.

Слегка сокращенный мной перевод статьи из TechONTAP возможно позволит кому-нибудь повнимательнее присмотреться к этой новой возможности систем хранения NetApp.

Что такое DataMotion for Volumes?

DataMotion for Volumes это новая возможность, появившаяся в Data ONTAP 8.0.1 7-Mode. Она позволяет вам переносить, не прерывая работы с ними, LUN-ы на томах с одного aggregate на другой, в пределах одного контроллера системы хранения (нельзя перемещать тома между разными контроллерами, например составляющими HA-пару). DataMotion for Volumes может быть использован для миграции томов, содержащих LUN-ы с “блочным” доступом по FC, FCoE, или iSCSI. Не поддерживаются “файловые” тома, с доступом по NFS или CIFS.

tips-fig1

Рис. 1 NetApp DataMotion for Volumes позволяет вам не прерывая доступа переносить данные LUN и его том на другой aggregate, на том же контроллере NetApp.

Ключевой особенностью DataMotion for Volumes является то, что также переносятся все детали, связанные с томом:

  • Снэпшоты и их расписание
  • Настроенные отношения SnapMirror®, SnapVault®, и MetroCluster™
  • Настройки Thin provisioning
  • Состояние дедупликации (для продолжения работы дедупликации для новых данных необходимо восстановить базу фингерпринтов на новом aggregate путем запуска полного сканирования)

Вы можете перемещать данные между любыми типами дисков, подключенных к контроллеру. Например, вы можете перемещать данные с aggregate на дисках FC или SAS на aggregate, состоящий из дисков SATA, и наоборот. В текущем релизе (8.0.1) вы не можете перемещать данные между разными типами aggregate (“32-bit” и “64-bit” aggregates).

Как работает DataMotion for Volumes?

DataMotion for Volumes использует хорошо известную технологию NetApp SnapMirror для миграции данных тома. Весь процесс делится на три фазы:

  • Setup
  • Data copy
  • Cutover

В фазах setup и data copy, исходный том продолжает обслуживать операции ввода-вывода без их прерывания.

tips-fig2-lg

Рис.2 "Циклограмма" процедур DataMotion for Volumes.

Фаза Setup

В фазе setup, производятся важные предварительные проверки, чтобы убедиться, что вся процедура может быть выполнена успешно. Эти проверки проходят каждый раз, когда DataMotion for Volumes запускается, и проходят вторично, когда начинается фаза cutover.

Проверка анализирует состояние всех объектов (исходного тома, aggregate на котором располагается исходный том, и aggregate-получатель) участвующих в перемещении. Если какая-то из проверок пройдет неуспешно, вы будете уведомлены и процесс не будет запущен. Все ошибки, выявленные проверками, будут выведены в консоль и записаны в лог-файл root-тома (/etc/log/ndvm).

Если все предварительные проверки пройдены успешно, процесс DataMotion for Volumes:

  • Создает временный том на aggregate-получателе, с именем, сформированному по следующему правилу: ndm_dstvol_<timestamp>
  • Запускает начальную (baseline) передачу, устанавливая репликацию SnapMirror между источником и получателем в виде созданного выше тома. Это самая длительная фаза; длительность ее прямо пропорциональна размеру исходного тома, так как требуется передача всего его содержимого.

Фаза Data Copy

После того, как будет проведена репликация уровня baseline, начинается фаза data copy, during which successive SnapMirror updates are initiated to synchronize the destination volume with the source, which remains active. По завершении каждого успешного обновления репликации SnapMirror, DataMotion for Volumes оценивает так называемый delta lag между двумя томами. Вы получите уведомление о величине delta lag, который будет оценочным временем для следующей операции обновления. DataMotion for Volumes остается в фазе data copy так долго, пока величина delta lag остается высокой. Когда величина delta lag уменьшается, система переходит к фазе cutover.

Фаза Cutover

Процесс фазы cutover может быть выполнен вручную, или автоматически ( по умолчанию - автоматически).

Период Pre-cutover. DataMotion for Volumes переходит к фазе cutover на томе-получателе, если том-получатель может быть полностью синхронизрован в заданный интервал, называемый “окно cutover”. Фаза pre-cutover это период времени, в который проводятся предварительные проверки описанные выше, и проводятся важные проверки состояния NVLOG и уровня загрузки CPU.

Вы можете задать пороги использования CPU и диска (в процентах) для выполнения операции DataMotion for Volumes. (по умолчанию порог задан в 100 для обеих опций):

vol.move.cutover.cpu.busy.limit
vol.move.cutover.disk.busy.limit

Автоматический Cutover. Когда все проверки фазы pre-cutover проходят успешно, фаза cutover начинается автоматически. Процесс cutover должен уложиться в окно длительностью 60 секунд. Когда том-получатель полностью синхронизирован, идентификатор тома-источника переносится на том-получатель, и операции ввода-вывода продолжаются с системы-получателя.

В ходе фазы cutover выполняются следующие действия:

  • Все LUN-ы на томе-источнике переводятся в режим задержанных операций ввода-вывода (quiesced). Состояние quiesced препятствует поступлению новых операций ввода-вывода к LUN, при этом опустошается (и не пополняется новыми операциями) текущая очередь операций с данным LUNом.
  • Операции на исходный том приостанавливаются (quiesced). Как часть этой операции приостановки, последняя "дельта" (разностная часть) фиксируется в снэпшоте, который называется ndvm_final_<timestamp>.
  • Том-получатель полностью синхронизируется с томом-источником с учетом полученной "дельты" из снэпшота ndvm_final_<timestamp>. Это будет последняя порция репликации SnapMirror между двумя томами, перед тем, как операции ввода-вывода будут переданы на том-получатель.
  • Временный том на получателе переименовывается в соответствии с именем тома-источника и его file system ID (FSID), и наоборот; то есть идентификаторы тома-источника и временного тома меняются местами.
  • Перенесенный на получателя том переводится в онлайн с идентификаторами исходного тома и LUN становятся активными.
  • ??сходный том удаляется (если вы не задали в параметрах его сохранить).

Неудачный автоматический Cutover. Если процесс cutover завершается неудачей, DataMotion for Volumes пытается повторить фазу data copy и пробует еще раз некоторое время спустя (делается три попытки выполнить cutover). Если ничего не удалось, то процесс cutover прекращается, и операции ввода-вывода возобновляются на том-источник. Для продолжения работы DataMotion for Volumes требуется вмешательство оператора.

Ручной Cutover. В случае выполнения cutover в ручном режиме, DataMotion for Volumes остается в фазе data copy, продолжая выполнять репликации SnapMirror. В ходе этих репликаций он записывает их результаты в лог, и ориентируясь на эти данные вы можете самостоятельно выбрать момент для проведения ручного cutover.

Возможные области применения

Существует несколько областей, где может применяться DataMotion for Volumes.

  • Балансировка нагрузки. Переместите том с нагруженного aggregate на менее загруженный.
  • Балансировка емкости. Переместите том с заполненного aggregate на тот, где больше доступного пространства.
  • Перенос данных со сторонних дисков на диски NetApp в системе V-series. Если вы используете NetApp V-Series как front-end к дисковому массиву стороннего производителя, вы можете воспользоваться DataMotion for Volumes для миграции этих данных на диски NetApp на этом контроллере V-series.
  • ??зменение типа дисков. Переместите том с дисков одного типа на другие. Например с дисков FC на SAS или SATA.

??спользование такого способа для непрерывающего работу переноса данных с дисков FC, выходящих из употребления, на диски SAS, может помочь для критически-высокодоступных систем обеспечить нужный SLA при такой миграции. Также это может помочь пользователям шире начать использовать системы с дисками SATA (также SATA + Flash Cache). При этом пользователи будут знать, что, в случае необходимости, они могут быстро и не прерывая работы перенести данные, которым потребуется большая производительность, чем могут обеспечить диски SATA, назад на диски SAS.

Рекомендации и наилучшие практики

Обратите внимание на следующие рекомендации и наилучшие практики при использовании DataMotion for Volumes:

  • Вы можете производить только один процесс миграции DataMotion for Volumes одновременно.
  • Не делайте vol rename или изменение атрибутов тома или LUN на томе-источнике, когда выполняется DataMotion for Volumes.
  • Не запускайте какую-либо операцию, которая может вызвать конфликт процесса выполнения операций DataMotion for Volumes. Если какие-то действия начинаются до того, как процесс вошел в фазу cutover, DataMotion for Volumes прервет свои операции (abort). В состоянии cutover, DataMotion for Volumes прервет (fence) сторонние операции администрирования.
  • При использовании HA-кластера, убедитесь, что обе ноды кластера используют Data ONTAP 8.0.1 7-Mode или новее.
  • Проверьте отсутствие вышедших из строя компонентов системы и загрузку ее процессоров, перед запуском DataMotion for Volumes.
  • Для того, чтобы предотвратить ситуации с конфликтами в фазе cutover, не планируйте занимающие много времени процессы управления или защиты данных параллельно процессу DataMotion for Volumes.
  • Не изменяйте параметры конфигурации исходного тома, во время выполнения процесса DataMotion for Volumes.

SNAPMIRROR и SNAPVAULT

  • В период выполнения операций DataMotion for Volumes, не изменяйте конфигурацию SnapMirror, не редактируйте файл snapmirror.conf.
  • Пока процесс DataMotion for Volumes не достиг фазы cutover, процессы SnapMirror или SnapVault updates успешно завершаются.
  • Если процессы репликации происходят в фазе cutover, то передача данных может быть неуспешной, так как cutover прервет операцию. После того, как cutover будет завершен, репликация продолжит следующий цикл передачи обновлений.
  • В случае выполнения ручного cutover, не делайте его, пока не завершены операции передачи реплик SnapMirror и SnapVault.

SNAPDRIVE и SNAPMANAGER

В фазе cutover:

  • Не работают процессы LUN provisioning и управления снэпшотами в SnapDrive® for Windows® (SDW).
  • Не работают процессы резервного копирования и восстановления данных в продуктах SnapManager® (SME, SMSQL, SMVI, SMHV, SMO, SMSAP, and SMOSS). После окончания фазы cutover, например на следующей запланированной операции создания резервной копии, эти процедуры успешно выполнятся.

Настройки таймаутов SCSI

  • NetApp рекомендует устанавливать на OS хост-системы NetApp Host Utilities Kit, для предотвращения ошибок таймаута. Смотрите "NetApp Host Utilities Installation and Setup Guide" для вашей хост-OS http://now.netapp.com/NOW/cgi-bin/software.

FLEXVOL и FLEXCLONE

  • DataMotion for Volumes может перемещать только тома FlexVol; Тома FlexClone® не могут быть перемещены.После завершения DataMotion for Volumes, исходный том FlexVol остается в состоянии offline и отношения child-parent не изменяются.
  • Тома FlexClone должны быть отделены (split) от породившего их тома FlexVol , перед тем, как вы начнете перенос тома FlexClone.

Дедупликация и компрессия

  • Если на томе-источнике идет активный процесс дедупликации, он должен быть остановлен для успешного выполнения фазы cutover.
  • DataMotion for Volumes не переносит базу fingerprint и change logs дедуплицированного тома FlexVol. После завершения процесса DataMotion for Volumes, пользователи должны запустить команду sis start -s для того, чтобы перестроить fingerprint DB на томе-получателе.
  • Компрессированные тома не перемещаются.

Дополнительные рекомендации по использованию DataMotion for Volumes для Oracle® Database и Microsoft® Exchange можно найти в TR-3881.

One Comment

  1. bbk:

    НетАпу ещё дописать бы DataMotion for Volumes, чтобы fingerprint и change logs копировались на получатель + избавиться от проблем с скомпресированными томами + автоматизировать вопрос с FlexClone + сделать автоматизацию процесса переноса, получится самый настоящий Tiering между разными типами дисков (агрегатами).

    Учитывая то, что почти все инструменты уже есть, только заставить всё работать вместе, это было бы не очень сложно реализовать :)

    Наверняка НетАпп об этом уже задумывался, интересно они отдали предпочтение, к примеру, гибридным агрегатам, перед этим решением или оно тоже когда-то будет?

Оставить комментарий