Как перенести данные с системы 7-mode на Cluster-mode?

В связи с тем, что, постепенно, Cluster-mode Data ONTAP, или как ее теперь правильно называть Clustered Data ONTAP, входит в жизнь, и все больше пользователей задумываются о ее использовании, возникает вопрос, как бы наиболее щадящим и простым способом перенести между двумя этими системами данные.
К сожалению, разница “в потрохах” между этими двумя OS, несмотря на схожесть названий, слишком велика, чтобы просто “запустить скрипт, и все сделается за час”. К сожалению пока нет реально работающего способа преобразовать уже имеющуюся 7-mode систему в C-mode. Поэтому, обычно, о Clustered ONTAP начинают думать в случае появления новой, “чистой” системы хранения, тем более, что сегодня есть возможность сделать Clustered Data ONTAP из всего пары контроллеров. Это интересно тем, что впоследствии вы уже сможете довольно свободно добавлять к этой паре контроллеров новые пары. Например старые (если они поддерживаются) контроллеры, работавшие в 7-mode, после завершения миграции данных с них, могут быть легко добавлены в такой кластер.

Довольно быстро в голову приходит идея использовать SnapMirror, штатную репликацию данных NetApp. Но поддерживает ли она репликацию между двумя “модами”? Да, поддерживает, хотя и с ограничениями. Наиболее существенным является невозможность перенести LUN-ы FCP или iSCSI. Увы, изменения в работе с метаданными LUN-ов в C-mode слишком значительны, чтобы это можно было просто реплицировать. В случае LUN-ов вы получите при попытке репликации сообщение в логах:

wafl.voltrans.lun.exists: Volume vmware_datastore1@vserver:a0cc5791-fd70-11e2-9f1f-123478563412 contains 7-Mode LUNs. It cannot be transitioned to Cluster-Mode.

В случае LUN-ов вам придется воспользоваться ручным переносом данных, либо через хост, либо через какой-то софт создания образа диска, хотя бы Norton Ghost или Acronis True Image.

Для разделов с файловыми данными, однако, можно все сделать собственными средствами SnapMirror.

Допустим, у нас есть две физических системы: 7-mode по имени NETAPP_7MODE (192.168.2.10) и Netapp Clustered ONTAP system по имени NETAPP_CMODE (192.168.1.10).

Создадим SnapMirror peer:
NETAPP_CMODE::> vserver peer transition create -local-vserver NETAPP_CMODE -src-filers-name NETAPP_7MODE

Transition peering created

Создадим том-получатель реплики данных:
NETAPP_CMODE::> volume create -volume vmware_datastore1 -aggregate aggr1 -size 100GB -type DP

[Job 16] Job succeeded: Successful

Создадим межкластерный интерфейс LIF:
NETAPP_CMODE::> network interface create -vserver NETAPP_CMODE -lif intcl_lif1 -role intercluster -home-node NETAPP_CMODE -home-port a0a-10 -address 192.168.1.10 -netmask 255.255.255.0

NETAPP_CMODE::> network routing-groups route create -vserver NETAPP_CMODE -routing-group i192.168.1.0/24 -destination 0.0.0.0/0 -gateway 192.168.1.1

Проверим, что связь есть:
NETAPP_CMODE::> network ping -lif intcl_lif1 -lif-owner NETAPP_CMODE -destination 192.168.2.10

192.168.2.10 is alive

Устанавливаем отношения репликации SnapMirror:
NETAPP_CMODE::> snapmirror create -source-path NETAPP_7MODE:vmware_datastore1 -destination-path NETAPP_CMODE:vmware_datastore1 -type TDP

Operation succeeded: snapmirror create the relationship with destination NETAPP_CMODE:vmware_datastore1

Проводим инициализацию репликации:
NETAPP_CMODE::> snapmirror initialize -destination-path NETAPP_CMODE:vmware_datastore1

Operation is queued: snapmirror initialize of destination NETAPP_CMODE:vmware_datastore1

Ждем завершения начальной полной передачи данных, проверяя статус:
NETAPP_CMODE::> snapmirror show

При необходимости обновляем данные на получателе, если они изменились на источнике:
NETAPP_CMODE::> snapmirror update -destination-path NETAPP_CMODE:vmware_datastore1

Отрезаем реплику от источника (quiesce):
NETAPP_CMODE::> snapmirror quiesce -destination-path NETAPP_CMODE:vmware_datastore1

При необходимость снова восстановить репликацию после отреза (quiesce):
NETAPP_CMODE::> snapmirror resume -destination-path NETAPP_CMODE:vmware_datastore1

Отрываем реплику (break):
NETAPP_CMODE::> snapmirror break -destination-path NETAPP_CMODE:vmware_datastore1

При необходимости повторять репликацию назначаем расписание:
NETAPP_CMODE::> job schedule cron create -name Every15mins -minute 15

NETAPP_CMODE::> snapmirror modify -destination-path NETAPP_CMODE:vmware_datastore1 -schedule Every15mins

После завершения репликации у вас на новой системе окажется копия данных системы с 7-mode, и их можно начинать использовать.

ВАЖНО: После репликации для тома-получателя будет автоматически выставлена опция fs_fixed_size, вы не сможете ее изменить командой vol options fs_fixed_size off, вместо этого воспользуйтесь командой: vol modify -vserver -volume -filesys-size-fixed false

12 комментариев

  1. Александр:

    Прям пичаль пичаль… ставил два больших нетапа (Primary+DR) когда ещё нельзя было C-Mode из одной пары без свитчей сделать. Теперь нужно ещё пару маленьких поставить в С-Mode, а мне так хотелось чтобы они в все в кластере были. :(

  2. Александр:
    Интересно, а у партнеров-дисти все еще нет услуги “стораджа напрокат” для такой вот процедуры? По крайней мере для крупных и важных клиентов. Мне кажется это было бы востребовано, и сильно бы продвинуло переход на Clustered ONTAP.

  3. Александр:

    romx:
    Сам NetApp предлагал подобное. Я, если честно, с нетерпением жду C-Mode Metro Cluster - вот тогда уже будет резонно переводить текущую систему на C-Mode ибо Primary и DR разнесены по ЦОД’ам.

  4. Nostromo:

    А кстати, есть хоть примерные сроки выхода метрокластера в C-mode?

  5. Nostromo:
    Если я правильно помню, то ждем 8.3 в первой половине этого года. Но опять же, если слухи верны, то 8.3 будет версией уже без 7-mode вообще.

  6. Александр:

    romx:
    По данным от заграничного NetApp’а - сентябрь/октябрь. Только у меня нет данных, что это будет RC или уже GA.

  7. Борис:

    Для миграции LUN’ов вроде бы предлагают DTA2800 Data Transport Appliance через партнёров.

  8. Mike:

    Для тех, кто любит GUI есть 7 Mode Transition Tool (7MTT), который делает все вышеперечисленное, плюс может перенести IP адреса и позаботиться о миграции 7-mode систем с репликацией. Довольно крутая тулза…

  9. Евгений:

    А есть данные относительно возможности использования штатного бэкплейна для интерконнекта в C-Mode. Из-за этого “нюанса” возникает большая печалька в виде накладных расходов из двух 10GbE карт на контроллер. А в FAS22xx и так одна мезанинная карта на контроллер, и если её использовать только для целей интерконнекта, то я не пойму в чем смысл C-mode? Гигабит для клиентов, единственный 10GbE интерконнект без FC?
    За обновление ради обновления на продакшне никто по голове не погладит.

  10. > А в FAS22xx и так одна мезанинная карта на контроллер
    Но там же по 2 порта на карту (контроллер)?

    > я не пойму в чем смысл C-mode?
    Ну так кроме 2240 у NetApp еще целый воз моделей стораджей с разными, существенно более мощными контроллерами.

  11. Евгений:

    > Но там же по 2 порта на карту (контроллер)?
    Да, по два порта для отказоустойчивости. Для C-mode интерконнекта требуется только одна внешняя 10GbE сетевая карта на контроллер?

    > Ну так кроме 2240 у NetApp еще целый воз моделей стораджей с разными, существенно более мощными контроллерами.
    Вы правы. Не спорю, даже 3220AE удовлетворит многие потребности даже на смешанной нагрузке. Здесь решение C-mode безусловно интересно, но я не могу понять зачем (по крайней мере, в этом конкретном случае) используется как встроенные 2×10GbE линки для обычного HA-интерконнекта между нодами в HA-паре, так и ещё дополнительные 10GbE линки для интерконнекта C-mode на этих же нодах при решении из двух контроллеров? Просто использовать бы существующие встроенные порты 10GbE для всех интерконнектов было бы для меня понятнее и логичнее.

    Мой вопрос адресован Александру и (многим) другим, желающим построить C-mode на низшей линейке:
    > нужно ещё пару маленьких поставить в С-Mode
    Для меня маленькие это FAS2200 и мне жаль отдавать единственные в них порты десятки только на кластерные издержки. Может, ситуация в дальнейшем изменится - не один же я такой.

  12. Евгений:

    > Для C-mode интерконнекта требуется только одна внешняя 10GbE сетевая карта на контроллер?

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

    > но я не могу понять зачем (по крайней мере, в этом конкретном случае) используется как встроенные 2×10GbE линки для обычного HA-интерконнекта между нодами в HA-паре

    Например человеку нужен функционал, существующий только в C-mode, его уже довольно много, от SMB 3.0 и pNFS, до полностью nondisruptive operations. Наконец, он может хотеть подключить контроллеры 2240 в существующий кластер (наприемр из других, более мощных контроллеров), или же планирует в будущем такие контроллеры завести и использовать, введя их в уже существующий и хранящий данные кластер. Причины могут быть разные.

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

20/0.144

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.