8 Replies Latest reply: Dec 8, 2012 1:44 AM by INVESTSTROY15 RSS

VSC rapid backup/restore

ALEXANDER.TURSIN
Currently Being Moderated

Уважаемые эксперты!

просветите пожалуйста  по VSC rapid backup/restore.

новый проект 2240-4 полный бандл ПО 8.1.1 7 mode + VAII, NFS, Vmware 5.0, VSC 4.0.

система только запущена в продакшен и волнует вопрос:

 

в документе по VSC цитата

 

1.      About the Backup and Recovery capability

The Backup and Recovery capability of Virtual Storage Console for VMware vSphere enables you to rapidly back up and recover multihost configurations running on NetApp storage systems.

 

В моей системе, повторюсь на всякий случай все через VSC:

 

1. rapid clone любой выключенной машины на тот же датастор - секунды

2. rapid clone любой включенной машины на тот же датастор - часы

3. backup всего датастора с VMs , с возможностью восстановления и тд отдельной VM - 3 минуты

4. restore отдельной VM на тоже самое место- часы

5.mount VM автоматически на отдельный датастор - несколько минут.

 

Вышеперечисленные пункты 2, 4, особенно 4 не дают мне покоя. инженеры партнера, сопровождавшие проект, объяснить не могут, последний ответ, полученный от них: "такая технология"

 

Как соотносится цитата и пункты 2 и 4? Это так и должно быть?

 

С уважением Александр.

  • Re: VSC rapid backup/restore
    aborzenkov
    Currently Being Moderated

    Что использует VSC для 4 - SFSR (Single File Snap Restore)?

    • Re: VSC rapid backup/restore
      ALEXANDER.TURSIN
      Currently Being Moderated

      Рад бы сказать наверняка, но не знаю. все установлено со значениями по умолчанию, при установке VSC была также выбрана опция Backup/restore

      • Re: VSC rapid backup/restore
        GERA.SUKHOV
        Currently Being Moderated

        А Вы посмотрите что происходит на СХД в момент проведения операций 2 и 4 (sysstat -x 1) и посмотрите список снапшотов до и после проведения операций (snap list -V <vol_name>). Тогда станет понятно что за технология используется. Ну а тогда и подумать можно - должно ли так быть...

  • Re: VSC rapid backup/restore
    mikhailf
    Currently Being Moderated

    Так и должно быть. Клоны работающих VM не используют технологии flexclone для первой копии, но если делаются несколько копий, то следующие будут сделаны быстро.

    Восстановление одной VM требует копирования ее файлов из снапшота. Если требуется быстрое восстановление можно подмонтировать снапшот как новое хранилище, запустить VM и потом уже SVmotion ее на постоянное место.

  • Re: VSC rapid backup/restore
    INVESTSTROY15
    Currently Being Moderated

    Меня тоже сильно озадачило время восстановления отдельной VM и даже датастора целиком из VSC. Вот ответ из интегратора:

    SnapRestore и Single File Snaprestore это совершенно разные с технической точки зрения процессы, хотя они и называются похоже и выполняются похожими командами. Раньше вообще существовала только одна функция SnapRestore - восстановление полного тома из снапшота. Относительно не так давно появилась функция восстановления отдельного LUN в общем томе и затем эту функцию можно было применять и к отдельным файлам.

     

    Настоящий SnapRestore работает именно так, как Вы описали и именно так, как описано на сайте NetApp - при создании снапшота фиксируется комплект метаданных с указателями на фиксированные блоки. В любой момент времени можно в секунды этот комплект метаданных сделать активным, т. е. превратить в активную файловую систему. При этом мгновенно и одновременное восстанавливается полностью весь том из снпашота, все данные в томе. И этот процесс полностью является «родным» для архитектуры NetApp-а, для WAFL.

     

    Single File Snaprestore совсем другая функция и была создана для некоторых случаев восстановления. Функция была «навязана» вынужденно на существующую архитектуру. При восстановлении Single File Snaprestore происходит копирование блоков из снапшота в AFS, удалением ненужных данных из AFS. Копирование блоков происходит медленнее чем простое копирование файла через сервер. Процесс копирования блоков и освобождение дискового пространства не синхронны - процесс освобождения пространства запаздывает от копирования, поэтому системе нужно дополнительное дисковое пространство. Кроме того, записываются дополнительные метаданные о произошедших изменениях. Если Single File Snaprestore используется еще раз, то записываются изменения произошедшие в изменениях и так далее. Происходят накопления дополнительных метаданных, которые NetApp-у нужно учитывать, из-за этого все процессы связанные со снапшотами начинают тормозить (вывод списка снапшотов, удаление снапшотов и т. д.).

     

    Вообще Single File Snaprestore - это не лучший функционал для частого восстановления отдельных файлов VMDK.

     

    Уточните, пожалуйста, бизнес задачу частого восстановления VMDK файлов и мы попробуем порекомендовать какие-то другие схемы по восстановлению.

     

    Например,  можно предложить такую схему для случая экстренного восстановления сервиса из снапшота - делать клон всего тома из нужного снапшота (секунды), монтировать клон, подключать нужную виртуальную машину из этого клона, поднимать сервись. Далее, в наиболее удобное время просто скопировать машину в нужную DataStore, дедуплицировать.

     

    Продублирую и свой ответ:

        Протестировал snap restore на уровне тома с большим объёмом данных: действительно, работает мгновенно.

         SFSR, судя по архивам, функция достаточно зрелая и возникла раньше, чем SR на уровне тома:

    http://www.gossamer-threads.com/lists/netapp/toasters/5878

    Странно, что за это время не удалось оптимизировать её работу. На это есть какие-либо объективные технические причины?

     

    Нашёл вот такое применение SFSR в составе продукта SnapProtect:

    Single File SnapRestore (SFSR) is a NetApp-unique feature that allows for a portion of a NetApp Snapshot copy to be quickly reverted into the production volume without the need to copy data from the source Snapshot and write it to the target volume.  As of this latest release (SP5), the SnapProtect solution now has the ability to leverage this NetApp technology to restore individual VM’s as part of the Virtual Server Agent (VSA) as well as for CIFS and NFS volumes through the NAS iDA. By using the SFSR to facilitate restores of Virtual Machines and NAS files, restore times will be considerably faster for customers requiring a restore operation taking potentially 10’s-100’s of GBs to be restored in seconds, not hours, while not affecting other data on the volume.  Pretty cool stuff if you’re looking to reduce restore and recovery windows. (And who isn’t?)

    https://communities.netapp.com/community/products_and_solutions/netapp_integrated_data_protection/blog/2012/07/26/is-backup-and-recovery-causing-you-headaches

    https://communities.netapp.com/community/products_and_solutions/netapp_integrated_data_protection/blog/2012/04/04/improve-your-plumbing-with-netapp-snapprotect-part-2

    Здесь используется какой-то принципиально иной SFSR, нежели чем в Data ONTAP CLI и VSC?

     

    Не затруднит скинуть ссылки на источники информации по проблемам реализации SFSR? К сожалению, не нашёл в интернете много информации о технической стороне.

     

         Задача – быстрое восстановление VM из резервной копии без создания клонов на уровне vCenter, т.е. восстановление именно оригинальной VM (иначе теряется её UUID, статистика, привязки и т.д).

    Частично решена при помощи монтирования в том же VSC:

    https://communities.netapp.com/docs/DOC-10862

    Правда, это практически ручное восстановление с кучей лишних действий..

    • Re: VSC rapid backup/restore
      ALEXANDER.TURSIN
      Currently Being Moderated

      Спасибо Даниил. Очень интересно будет послушать ответ на ваше письмо. Если не затруднит, добавьте потом его сюда.

      • Re: VSC rapid backup/restore
        INVESTSTROY15
        Currently Being Moderated

        Суть -- пользоваться FlexClone из snapshot'ов.

        Добрый день!

         

        К сожалению, мне самому не удалось найти подробной документации по процессу Single File SnapRestore (SFSR), самому интересно, как там проходят процессы в подробностях. Спрашивал у NetApp-овцев, у них тоже нет документации и от себя комментарии, то же самое, что я писал в прошлом письме - блоки копируются физически, все проходит очень медленно, дополнительно пространство нужно и т. д.

         

        Про SFSR в SnapProtect точно не знаю, но думаю, тут скорее всего маркетинговое неправильное использование терминов либо еще что-то. Я знаю, что в большинстве случаев для быстрого восстановления отдельных виртуальных машин часто используется FlexClone и лицензии SnapRestore вообще может не быть. Возможно в SnapProtect тоже используют FlexClone, но в маркетинговом описании назвали это как SFSR, чтобы понятнее было.

        Я сам не спец в SnapProtect, а иначе можно было бы опробовать на удаленной лабе.

         

        Вот рекомендации по вариантам восстановления отдельных машин от инженеров вендора:

         

        Игорь Увкин:

        Если 8.1 и старше то сейчас как уже говорили -

        Clone start для файла vmdk из снапшота

        Удаление старого (переименование если хочется сохранить)

        Переименование клона

         

        Скрипт из 10 строчек в esx консоли

        В принципе 1 и 2 строки можно поменять местами - тогда третья будет не нужна

        Работать должен мгновенно...
        Uuid остается старый, естественно только на nfs
        sy 

        Igor

         

        Михаил Швыдкий:

        1) Копирование файла через Datastore браузер VMware.

         

        2) Storage vMotion виртуальной машины из подмонтированного бэкапа.

         

        3*) Использовать VSC 4.1 и DataONTAP 8.1 там должна быть возможность клонировать ВМ с использование SIS clone.

         

        Через CLI возможно сделать клон файла из SnapShot, я думаю что функционал доступный для VSC через API ничем не отличается от функционала доступного через CLI.

        Можно то можно, только с ограничениями: NFS, VSC4.1, DataONTAP 8.1.1, только тот же datastore. К сожалению четкого описания VSC workflow когда какая технология копирования/клонирования используется я в документации не встречал, вот такая выдержка встречалась, но это было еще до SIS clone.

         

        Here is the logic for the first copy on NFS

        1. Source and Destination are the same Datastore (and therefore volume) we use FlexClone.
        2. Source and Destination Datastores are different, but on the same controller we use NDMP copy.
        3. Source and Destination are on different controllers, we use native vCenter clone (no controller offload).

          Things that override these rules on NFS 

        • If the VM is powered on, we use native vCenter clone first (then follow the rules above).
        • If the VM has a vm level snapshot, we use native vCenter clone first (then follow the rules above).
        • If the any vmdk file associated with the VM is in a datastore on a different controller, we use native vCenter clone first (then follow the rules above).
        • If the customer choses to change the vmdk format, we use native vCenter clone first (then follow the rules above).
        • If the controller is running Data ONTAP 8.0 or earlier and any block in the source file is being referenced 255 times we use NDMP copy.
          • All subsequent copies (when you request more than one VM) use FlexClone first and fall back to NDMP copy if we hit the "255 references rule" above.

        Как всегда есть много если…

        Все должно нормально работать через VSC, только сначала нужно удалить исходную машину из inventory, а то придется менять UUID.