NetApp Data Motion for Volumes

Интересующиеся некоторыми новыми технологиями 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, то есть использовать это для “апгрейда аггрегейтов” не получится. Но обещают.)

image

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

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

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

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

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

    Круть! В догонку к статье http://www.youtube.com/watch?v=nMg3K4RocQI это правда между контроллерами, но все же тоже круть :)

    P.S. по сравнению с конкурирующей фирмой (не будем называть имен) у NetApp реализовано это на порядок лучше :)

  2. Minus:

    Роман, а можно поподробнее о лицензировании этой опции?

  3. Minus:

    Я так понял, что это “встроенная” возможность 8.0.1, по крайней мере так я думал до твоего вопроса :)
    > vol move
    ,и поехали.

    Подробно вот тут:
    http://media.netapp.com/documents/tr-3873.pdf

    Александр:

    Ну не совсем так, как я понял. Если речь про FAST, в сравнении с DMVol, то первое все же “готовый продукт”, а второе - пока только инструмент для создания такого же продукта.

  4. Minus:

    Спасибо, прочитал. Видимо, что-то ввело меня в заблуждение, думал, отдельно лицензируемая опция.
    А не знаешь ли ты, когда появится возможность в 8G изменения типа аггрегатов 3264, и/или возможность онлайн компрессии на 32-битных аггрегатах? Лично для нас, как для заказчиков,этот вопрос достаточно важен, так как у нас много данных CIFS лежит по естественным причинам на SATA, которые, в свою очередь, в 32-битных аггрегатах (так исторически сложилось). Вот и хотелось бы компрессию, для полного счастья :)

    Кстати, у тех, кто купил NetApp от IBM, на улице праздник - в середине февраля стала доступна ONTAP 8.0.1, а еще до кучи такая удобная вещь, как System Manager. :)

  5. > Спасибо, прочитал. Видимо, что-то ввело меня в заблуждение, думал, отдельно лицензируемая опция.

    Возможно тут путаница. Дело в том, что есть Data Motion for vFilers, которая появилась еще в 8.0, и которой, понятно, для vFiler-ов нужен Multistore, который, до недавних пор, отдельно лицензировался.

    > А не знаешь ли ты, когда появится возможность в 8G изменения типа аггрегатов 3264

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

    > а еще до кучи такая удобная вещь, как System Manager.

    Да-а… не торопится IBM :(

  6. Minus:

    А вот еще вопрос - читал твой документ, п. 2.4. Там сказано, что используется асинхронный Snapmirror, который стоит денег. Значит ли это, что без него DMVol не будет работать, или будет использоваться какой-то урезанный нелицензируемый механизм SnapMirror (вроде урезанного CIFS, который появлялся в системе при наличии купленного SnapDrive, т.е. без лицензии CIFS можно было работать с дефолтными шарами)

  7. одна птичка:

    Data Motion это путаница:
    - для Data Motion for Volume лицензия SnapMirror не требуется.
    - для Data Motion for vFilers лицензия SnapMirror нужна
    - для Data Motion for Files лицензия SnapMirror не требуется ( само свойство в ограниченом доступе)

  8. bbk:

    >Да-а… не торопится IBM :(
    Я так подозреваю, что не в одном IBM’е дело. Ему может сам НетАпп не давать “торопиться”.

    Кстати пора бы уже новую статейку написать на эту же тему, с обновлённой информацией, наверняка уже многое изменилось в лучшую сторону :)

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

20/0.135

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.