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’е дело. Ему может сам НетАпп не давать “торопиться”.

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

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