15 Replies Latest reply: Jun 18, 2013 11:38 PM by GERA.SUKHOV RSS

vmotion vs reallocate

SPORYKHIN Sprinter
Currently Being Moderated

Приветствую!

Преамбула.

Есть некое количество томов достаточно больших размеров. На них живет виртуализация, много перезаписей. После анализа производительности, поддержка настоятельно рекомендовала провести reallocate данных томов. Измерение проходило порядка 4-5 дней ввиду больших размеров и я подозреваю, что сама реалокация будет так же идти очень долго, причем нагибая диски и как следствие - это отразится на клиетах.

 

Вопрос.

Имеет ли смысл делать последовательгный vmotion с с тома на том, что на разных агрегатах вместо реалокации? Будут ли при таком процессе данные распологаться оптимально?

 

Спасибо!

  • Re: vmotion vs reallocate
    GERA.SUKHOV Kart Racer
    Currently Being Moderated

    На сколько я понимаю, vmotion это средство VMware для "живой" миграции ВМ с хоста на хост. А rellocate это средство СХД для оптимизации расположения блоков в WAFL. В такой трактовке их сравнивать неправомерно.

    Но у NetApp есть технология DataMotion for Volumes, которая позволяет перемещать тома с лунами с одного агрегата на другой в пределах одного контроллера не прерывая работу с этими лунами.

    И в случае rellocate и DataMotion, следуя Вашей терминологии "нагибает" диски. :-) Чудес не бывает.

    Я бы рекомендовал именно reallocate, если агрегаты по типу дисков и количеству сопоставимы. А если новый агрегат на быстрых дисках, да еще и шпинделей больше - то однозначно DataMotion для ресурсов к которым нужен быстрый доступ.

  • Re: vmotion vs reallocate
    murzic2000 Sprinter
    Currently Being Moderated

    Если агрегат получатель новый, то естественно при Storage vMotion процедуре данные будут располагаться последовательно для каждой мигрируемой машины.

    Главное перевозить по одной машине за раз.

    Но не факт что процедура Storage vMotion меньше нагибает диски при переезде, чем reallocate.

    И на старом агрегате все равно придется делать reallocate после переезда.

    • Re: vmotion vs reallocate
      GERA.SUKHOV Kart Racer
      Currently Being Moderated

      Плюс к этому Storage vMotion делает копирование (на сколько я себе представляю) всех файлов ВМ на другой репозиторий. А это значит еще и нагрузку на сеть (SAN - FC или LAN iSCSI).

  • Re: vmotion vs reallocate
    SPORYKHIN Sprinter
    Currently Being Moderated

    Поясню, что предполагаю: смигрировав все тома я опустошу текущий агрегат, на нем почти не будет данных, при переезде обратно, как я думаю, блоки должны лечь более оптимально, т.к. агрегат пустой. Т.е. перемещение 2 раза.

  • Re: vmotion vs reallocate
    SPORYKHIN Sprinter
    Currently Being Moderated

    Да, не стоит так делать..

  • Re: vmotion vs reallocate
    alexey_tkachev Sprinter
    Currently Being Moderated

    У reallocate есть по крайней мере преимущество в том, что для этой процедуры можно определить расписание запуска, а кроме того, приостанавливать и возобновлять ее выполнение. Так можно уменьшить негативное влияние на производительность.

     

    Если все-таки решитесь на Storage vMotion или DataMotion for Volumes, то после возвращения данных обратно вероятно имеет смысл сделать reallocate регулярным по расписанию, чтобы не запускать ситуацию

  • Re: vmotion vs reallocate
    mikhailf NetApp Employee Sprinter
    Currently Being Moderated

    Я голосую за Storage vMotion.

    Reallocate (если имеется в виду volume reallocate) оптимизирует для операций чтения, агрегат остается фрагментированным. Кроме того дедуплицированные блоки пропускаются. Storage vMotion в пустой агрегат максимизирует нефрагментированное свободное пространство, что ускоряет операции записи (а в виртуальной инфраструктуре операций записи бывает сильно больше половины), при этом vmdk будет расположен последовательно, что улучшит и последовательное чтение. Мы как-то мигрировали данные с одного файлера на другой, после этого система летала, write latencies были практически нулевые, да и чтение было очень пристойно. Если версия Ontap достаточно свежая, то на новый пустой агрегат также рекомендуется поставить опцию free_space_realloc on, а на томе опцию read_realloc space_optimized. Первая опция дефрагментирует свободное пространтство и таким образом оптимизирует запись, вторая оптимизирует последовательное чтение. В результате система само-подстраивается и производительность должна поддерживаться на стабильном уровне вне зависимости от возраста и заполненности.

    • Re: vmotion vs reallocate
      GERA.SUKHOV Kart Racer
      Currently Being Moderated

      А Вы ничего не путаете? На запись в СХД есть кэш. Кроме того, wafl так устроен, что изменение любого блока все равно пишется в новое место. Задержка с записью возможна если мало свободного места. При заполненности более 90-95%. Может в Вашем случае миграции имели место другие причины? Например более быстрые диски в агрегате или большее количество шпинделей...

      • Re: vmotion vs reallocate
        mikhailf NetApp Employee Sprinter
        Currently Being Moderated

        Задержка записи происходит не столько от заполненности диска как такового, сколько от вызванной этим фрагментации свободного пространства. Со временем свободное пространство фрагментируется даже если достаточно свободного места. Особенно это заметно если много операций случайной записи (например vmware), и агрегат когда либо был заполнен на 90-95%. Во время выполнения операции записи WAFL пытается найти свободный full stripe, тогда операция записи будет очень быстрой. Если же full stripe нет, то придется читать данные с остальных дисков для того, чтобы пересчитать parity, что и вызывает дополнительную нагрузку и задержки.

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

        • Re: vmotion vs reallocate
          GERA.SUKHOV Kart Racer
          Currently Being Moderated

          Если следовать Вашей логике, то непрерывное свободное место все равно закончится даже при небольшой загруженности агрегата и full stripe не будет возможности записать. Хотя бы потому что освобождаются свободные блоки по одному и случайно, а записываются страйпом. Но что-то я не слышал от клиентов об ухудшении производительности на запись. И есть примеры и на VMware и Citrix и Hiper-V. Мне кажется, что Ваши представления в чем-то не совсем верны.

          В то-же время, в документе "Reallocate Best Practices Guide" (TR-3929) в п.3.1 говорится, что наибольшую выгоду reallocate может принести при последовательном чтении после случайной записи. Чем это плохо для виртуалок? Может там и не большой процент последовательного чтения, но данные то это упорядочит!

          К тому-же я когда то читал статейку, где мужик тестировал NetApp на случайные запись/чтение. И вот деградация производительности на запись начиналась при заполненности в 95-98% (если не изменяет память). Как бы эта статейка не блоге Романа была... Может стоит ее обсудить здесь, чтобы придти к какому-то мнению на счет распространенного мнения о дефрагментации?...

          • Re: vmotion vs reallocate
            mikhailf NetApp Employee Sprinter
            Currently Being Moderated

            NetApp делает отличную работу по маскировке всех трудностей в своей работе. Запись подтверждается клиенту как только она оказывается в NVRAM (локальном и партнера). Все необходимые чтения производятся во время consistency point, который происходит когда NVRAM заполняется наполовину, либо после 10 сек. Настоящие проблемы с записью начинаются когда один CP еще не успел сбросить буфера, а другой уже требуется (так называемый back-to-back CP). Это более вероятно при сильной загруженности агрегата, так как один записываемый блок требуется много операций чтения. После storage vmotion какое-то время будут происходить full stripe write, хотя я согласен, что скоро это скорее всего прекратится, хотя позитивный эффект будет еще чувствоваться. Reallocate не даст практически ничего для виртуальной инфраструктуры, особенно если используется дедупликация (дедуплицированные блоки не реаллокируются)

            • Re: vmotion vs reallocate
              murzic2000 Sprinter
              Currently Being Moderated

              Начиная с 8.1 дедуплицированные блоки дефрагментируются с помощью physical reallocation (опция -p)

            • Re: vmotion vs reallocate
              GERA.SUKHOV Kart Racer
              Currently Being Moderated

              Конечно, storage vmotion даст результат. Вот только при большой заполненности агрегата - на сколько... И сколько эта операция будет длится при тех объемах, когда агрегат заполнен сильно? ;-) Не получится ли так, что storage vmotion будет длится пару суток, а эффект будет только в первый день при завершении? ;-)

              Впрочем это пустая дискуссия. Варианты разные и для разных случаев...

  • Re: vmotion vs reallocate
    SPORYKHIN Sprinter
    Currently Being Moderated

    Коллеги, спасибо за обсуждение, очень интересные мысли появляются!

     

    Михаил, а можно как-то лично пообщаться, чувствуется богатый опыт.

    Спасибо!

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points