about NetApp

??нтересующиеся некоторыми новыми технологиями NetApp, возможно уже обратили внимание на продукт, созданный еще в прошлом году –  NetApp Data Motion for vFilers, он появился в Data ONTAP 7.3.3, и который позволяет осуществлять непрерывающую миграцию (перенос) между контроллерами так называемых vFilers, то есть “виртуальных файлеров”, “инстансов” Data ONTAP, работающих как отдельные виртуальные системы хранения, в рамках продукта Multistore.
(да когда же я вам уже про Multistore расскажу уже? ??нтереснейшая тема, кстати! Поставил себе в ToDo пометку: “В ближайшее время написать статью про Multistore!”, тем более теперь Multistore идет в ONTAP Essentials со всеми 3200/6200)

То есть делать примерно то же самое, что делает VMware vMotion для виртуальных машин, только для нетапповских “виртуальных файлеров”, между несущими их физическими контроллерами.

Однако в Data ONTAP 8.0.1 появилась и еще одна новая возможность – Data Moion for Volumes.

NetApp Data Motion for Volumes это новая возможность, появившаяся в версии Data ONTAP 8.0.1, и которая позволяет проводить непрервывающую миграцию на одном контроллере, для томов данных, содержащих LUN-ы, между разными его aggregates. То есть если первый был vMotion for NetApp vFilers, то второе – примерный аналог Strorage vMotion.
Первая и очевидная область применений – организация tier-инга данных, то есть, например, можно, не прерывая работы с данными, мигрировать том с LUN-ами c FC/SAS аггрегейта на аггрегейт на SATA на том же контроллере.

Обатите внимание, что это только для LUN-ов пока, то есть НЕ для CIFS/NFS. Только для FC/iSCSI/FCoE! То есть правильно было бы назвать его Data Motion for LUNs.

Также нельзя мигрировать между HA-парой контроллеров. Только между aggregates одного физического контроллера, для томов, содержащих только LUN-ы, с блочным доступом. Также пока не поддерживается миграция между разнородными aggregates (то есть пока только с 32 на 32, и с 64 на 64, но не с 32 на 64, то есть использовать это для “апгрейда аггрегейтов” не получится. Но обещают.)

Несмотря на такие ограничения в текущей версии, возможность эта довольно интересная.

При такой миграции сохраняются все связанные с томом и LUN-ом настройки, такие как: снэпшоты и их расписания, настройки репликации для такого тома, настройки и свойства thin provisioning, дедупликации (правда на новом месте нужно провести рескан для пересоздания базы фингерпринтов, они останутся на уровне aggregate и не переедут вслед за томом, однако на уже дедуплицированные данные это не повлияет).

Подробнее на английском – в Tech OnTap за февраль этого года. Вы ведь подписаны на русскую версию? Никогда не поздно. :)

NetApp Data Motion – новая технология “непрерывающей” миграции данных между системами хранения NetApp. Эта технология несколько напоминает VMware vMotion, но для хранилищ данных, при которой виртуальные машины могут, не прерывая работы, мигрировать между хост-серверами, например в зависимости от их загрузки, или состояния. Это также чем-то похоже на VMware Storage vMotion, но выполняется целиком “аппаратно”, средствами системы хранения, и не привязано к какому-либо софтверному решению на хостах.

Она объявлена для версий новой “линейки” Generation 8, но в январе выйдет и в “Classic”, “Generation 7”, в версию Data ONTAP 7.3.3, для тех, кто вынужден оставаться на старой линейке.

Для работы NetApp Data Motion необходимы следующие компоненты и лицензии:

1. Multistore – лицензия позволяющая создавать на контроллере NetApp так называемые vFilers, “виртуальные файлеры”, изолированные, виртуализованные средствами самого NetApp ONTAP, “псевдофайлеры”. Раньше эта лицензия обычно использовалась для того, чтобы разделить физический “файлер” на несколько “виртуальных”, например для того, чтобы подключить его в многодоменную CIFS-сеть, или раздать такие “виртуальные файлеры” различным администраторам подразделений в крупной организации или компании-провайдере услуг хранения. Однако идея NetApp, стоящая за Multistore была куда шире.
2. SnapMirror в режиме Semi-sync – лицензия на средство репликации данных между системами хранения NetApp, осуществляемое, в данном случае, в “квази-синхронном” режиме, по IP-сети.
3. Средство управления Provisioning Manager версии 4, являющееся частью продукта Operations Manager v.4. Это сравнительно новый для пользователя продукт, обеспечивающий GUI-управление, в том числе и процессом Data Motion, размещающийся на администраторском компьютере.

Процесс миграции заключается в предварительной репликации данных с одной физической системы хранения, где находится мигрируемый vFiler, на другую, когда предварительная baseline replication завершена, то, с помощью Provisioning Manager-а администратор может отдать команду, и vFiler “переключится” с одного контроллера на другой, на котором уже к тому времени будут находиться его данные, при этом ресурсы, такие как, естественно, данные, адреса, имена шар, LUN и их маппинг, также смигрируют вслед за vFiler.

Пока технология не лишена недостатков и ограничений.

1. Пока не поддерживаются LUN с работой по FC. Но работает iSCSI. Поддержка FC будет реализована позднее в 2010 году. Разумеется работает NFS и CIFS, однако, в случае CIFS, текущая, на момент миграции, сессия CIFS будет прервана, и ее надо будет переустановить (что связано со stateful-природой CIFS как протокола).
2. Необходимо, чтобы оба контроллера, и источник и получатель миграции,  находились в одной IP-подсети.
3. Оба контроллера (пока) должны быть однотипными, в случае неоднотипности, миграция возможна с контроллера с меньшим размером NVRAM на бОльший (но в этом случае миграция будет однонаправленная). Также (пока) не поддерживается вариант миграции данных с FC/SAS-дисков на SATA.
4. Естественно не поддерживаются traditional volumes (кто-то их использует по доброй воле еще?).
5. Мигрируются все тома, принадлежащие данному vFiler.
6. SnapLock и FlexCache (пока) не поддерживаются.
7. Дедуплицированные данные переносятся дедуплицированными, и сохраняют доступность в своем дедуплицированном виде, но соответствующие им метаданные на “получателе” репликации надо заново перегенерировать, чтобы новые записываемые данные могли также дедуплицироваться вместе со старыми, так как метаданные (база фингерпринтов) остаются на уровне aggregate, и не мигрируют.
8. Мигрированные FlexClones - “развернутся”, “девиртуализируются”, и займут “положенное им по объему” (это, к сожалению, свойство их репликации с помощью SnapMirror).
9. Пока управление процессами Data Motion возможно только через GUI Operations Manager-а, не через командную строку.

Будем надеяться, что значительная часть ограничений, присущих любому продукту “версии 1.0” со временем будет устранена. Сама же Data Motion это логичный шаг в направлении глобальной стратегии NetApp – построении “облачного” распределенного хранилища, с глобальным “пространством хранения”, распределенным и прозрачно мигрирующим между множеством различных физических хранилищ.

В основу поста легла заметка в блоге Аарона Делпа, по новостям с NetApp Insight 2009, и презентации Ларри Туше, инженера “команды виртуализации” NetApp.