about NetApp

В связи с тем, что, постепенно, 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

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

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

Continue reading ‘SnapMirror, часть 2’ »

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

Тем не менее все равно остаются темы, на которые хотелось бы иметь больше информации “простым человеческим языком”, многие фичи NetApp, как я заметил, именно поэтому и не используются широко, потому что раз никто не пользуется – мало информации, а раз мало информации – вот никто и не пользуется. Так что начнем со сравнительно  неплохо известного в принципе: с средства репликации SnapMirror.

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

Для начала несколько слов о том, в чем разница между двумя системами репликации, имеющимися у NetApp. Это SyncMirror и SnapMirror.

??сторически SyncMirror была синхронной репликацией (только), а SnapMirror – асинхронной (только). В те времена было все просто и понятно. Если нужна синхронная репликация – первое, асинхроная – второе. Напомню разницу: синхроная репликация – это такая, на которой сигнал “готово, записано” от стораджа к записыващему приложению не отдается до тех пор, пока блок данных не будет записан ?? на исходный сторадж, ?? на его реплику. Сперва пишем блок на локальный, потом передаем его на удаленный, записываем там, получаем ответ “записано” с удаленного, и только после этого сигналим “записано, продолжай” приложению.

• Плюсы: Мы гарантированно имеем два стораджа в синхронной, идентичной копии. Если блок не записан на удаленную систему, то и на локальной он не записан, и приложение об этом знает. Никакой потери данных и рассинхронизации из-за обрыва связи между стораджами нет “по определению”. Это самый надежный способ.
• Минусы: Это, одновременно, и самый медленный способ с точки зрения приложения. Нетрудно видеть, что скорость работы с приложением, bandwidth между приложением и стораджем, равен скорости работы, bandwidth между локальным и удаленным стораджем. Если у вас приложение подключено к стораджу по 8Gb FC, а канал между стораджами, находящимися в синхронной репликации, составляет 10Mb/s, то максимальная скорость передачи данных между приложением и локально подключенным по FC 8Gb стораджем будет составлять не более 10 мегабит в секунду, то есть будет равным скорости межстораджевого канала репликации.

Отсюда видно, почему синхронная репликация крайне редко применяется в “географически” разнесенных решениях, а там, где она применяется в таких решениях, например в NetApp Metrocluster, это сложная и дорогая конструкция, с отдельной “фабрикой” репликации, занятой только этим.

Гораздо чаще на практике для репликации двух систем хранения используют так называемую “асинхронную” репликацию. В этом случае локальная система сразу сигналит “записано” приложению, а потом, с определенным интервалом, шлет обновления на удаленную систему – “Эй, тут у меня есть свежак, прими!”

• Плюсы: Производительность работы приложения с локальным стораджем максимальна, канал репликации не ограничивает производительность приложения. Кроме того существенно экономится и ресурсы самого канала. Представим себе, что приложение каждые несколько миллисекунд изменияет один блок данных. В случае синхронной репликации, каждое такое изменение должно быть передано на удаленную систему. А в случае асинхронной репликации – только одно, состояние этого блока на момент начала репликации, или же итоговое его значение после всех изменений.
• Минусы: Удаленная копия никогда не становится идентичной локальной. Она ее всегда догоняет, но, если изменения непрерывны, всегда отстает, и этот интервал отставания называется “лагом репликации”. Более того, если не предпринимать специальных мер, то приложение может и не узнать, что каких-то данных на удаленной системе нет, или они не соответствуют данным локальной системы.

Некоторым промежуточным вариантом является так называемая “полусинхронная” или “квазисинхронная” репликация, то есть пока успеваем физически – синхронная, когда не успеваем – не тормозим локальную систему, а переходим в асинхронный режим, и синхронизируемся так, пока не догоним, после чего опять переходим в “синхрон”.

Так вот, в свете всего вышеизложенного, SyncMirror это в чистом виде синхронная репликация, причем на достаточно низком уровне. Так как вы помните, что в NetApp его RAID это просто то, как функционирует его файловая система WAFL, можно считать, что SyncMirror это просто в этой файловой системе функция RAID-1, “зеркалирование”, “мирроринг”, или, вернее будет, RAID-41 или RAID-61, как принято называть комбинированные уровни, одни, поверх уже имеющихся других.

На сегодня SyncMirror в ее изначальной форме широко применяется только в Metrocluster.

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

Обратите внимание также, что в текущей лицензионной модели SyncMirror бесплатно входит в Data ONTAP Essentials, то есть присутствует бесплатно на любой системе хранения, а вот SnapMirror стоит денег, причем довольно существенных, и это отдельная лицензия.

Ну и, наконец, слово Snap в названии как бы намекает нам, что за технология использована при реализации репликации – это снэпшоты, или разностные “снимки состояния” соответствующего тома. При организации репликации сначала осуществляется так называемый baseline transfer, то есть передача исходного состояния. Это довольно продолжительная и емкая по ресурсам задача, когда целиком весь объем данных реплицируемого тома передается с локальной на удаленную систему. Зато потом, когда завершен baseline transfer на удаленную систему по каналу репликации передаются только изменения от одного цикла репликации до другого, они, обычно, сравнительно невелики по объему. Технически сторадж для этого делает специальный служебный, обычно невидимый пользователю снэпшот с реплицируемого тома, а затем получившиеся изменения передает на удаленную систему, “накатывая” их на тот том, находящийся в специальном состоянии restricted, после чего служебный снэпшот удаляется, на следующий цикл обновления операция повторяется.

??так, разобравшись с тем, что является, и что не является SnapMirror, перейдем к деталям. Продолжение следует.

SnapMirror, Часть 2.

Я уже писал, что в разделе Toolchest на NOW можно, порой, найти какие-нибудь интересные и полезные утилитки, про которых, часто, никто не знает. Вот и в этот раз там обнаружилась любопытная утилита SnapMirror Progress Monitor Tool.

Это, что явствует из названия, инструмент для слежения за процессом репликации SnapMirror.

Если в вашей системе хранения используется SnapMirror, а в особенности, если SnapMirror передает достаточно объемные репликации по сравнительно узким WAN-каналам, то, безусловно, такая утилитка будет в вашей практике весьма применима и полезна.

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

Не секрет, что компания IBM продает под названием IBM N-series системы хранения, являющиеся, произведенными для IBM, знакомыми нам системами NetApp FAS. Отличаются они корпусом (вернее передней лицевой панелью), а также “брендированным” IBM-ом софтом. Ну и, конечно, саппортом, оказываемым IBM, и рядом подобных же отличий в процессе продаж и сопровождении (например для системы IBM N-series можно купить диски поштучно, а не целой полкой, как у NetApp).

Но вот как обстоят дела с софтовой совместимостью, например, можно ли установить в качестве партнера репликации SnapMirror к IBM N-series систему NetApp FAS?

Да, это возможно, SnapMirror и SnapVault совместимы между NetApp FAS и IBM N-series, однако помните, что должны соблюдаться соответствия версий Data ONTAP между этими системами (например, в случае использования Volume SnapMirror, получатель репликации должен иметь версию Data ONTAP равную или новее, чем источник). Что может быть определенной проблемой, так как IBM заметно запаздывает с выпуском новых версий Data ONTAP под N-series.

По умолчанию, TCP-окно Snapmirror равно 1,994,752 байт. В структурах, где SnapMirror используется для репликации данных через WAN, такое значение может заметно замедлять процесс репликации. Важно правильно вычислить верные настройки TCP-окна, и соответствующим образом их установить. Базовая формула такова:

Window Size = Round Trip Delay X Desired Rate

Таким образом, если у вас используется канал 10Mb/s и средний RTD равен 100ms, то window size должен быть 125,000 байт.

Несколько замечаний о этом TCP Window size:

Это теоретически минимальное возможное окно, используемое SnapMirror, и может не быть самым оптимальным. Попробуйте несколько вариантов в районе этой цифры, чтобы выбрать наилучшее.
Установить размер TCP window size можно в файле /etc/snapmirror.conf в параметре wsize.
Это надо установить и на системе-получателе репликации.

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

options snapmirror.delayed_acks.enable off

Эта установка выключает TCP/IP delayed acknowledgments. В сетях с высоким значением задержки, это может дать выгоду. По умолчанию она включена.

romx: Хочу также обратить внимание, что в речь идет именно о тонкой настройке и оптимизации определенных вариантов конфигурации, так как настройки SnapMirror по умолчаню выбраны для удовлетворительной работы в любых условиях. Если вы не уверены в том, что вы делаете, то лучше оставьте по умолчанию. Помните первое правило профессионала: “Работает - не трогай!” :)

Оригинал тут:
http://rajeev.name/blog/2008/03/18/optimizing-snapmirror-performance/
(будьте внимательны, на хостинге этой страницы сейчас сидит веб-червяк-троян!)