Share via

Windows Server 8 Hyper-V. SMB Support & Live Migration.

  • Article

Сегодня мы поговорим о нововведениях Windows Server 8 Hyper-V в технологии переноса виртуальных машин. Затронем поддержку размещения виртуальных дисков на удалённых SMB хранилищах, поговорим о нововведениях в Live Migration и о Live Storage Migration.

Поддержка SMB в Hyper-V

Я, безусловно, напишу пару отдельных заметок о нововведениях в файловых технологиях Windows Server 8, ибо это сильно влияет на возможности платформы виртуализации. Пока же я лишь кратко скажу, что Hyper-V теперь позволяет размещать свои виртуальные диски на удалённых файловых серверах при использовании многоканального протокола SMB 2.2.

 

Одновременные Live Migration

Со времени появления Live Migration в Hyper-V R2 тёмные силы мутили воду, пропагандируя необходимость возможности выполнения нескольких одновременных переносов машин. Очевидная глупость, ибо времени занимает столько же (если не больше в виду того, то машины всё время обновляют свою память). Мы же все понимаем, что используем Teaming и пропускная способность у сервера выражена неким числом. Если что-то случится с узлом во время последовательного переноса, то сколько-то машин вы перенесли успешно, остальные перезагрузятся по отказу. В случае параллельного переноса перезагрузятся все машины. Тем не менее, тёмные силы и VMLimited известны в своём PR и хотя и неоднократно были пойманы, на том не останавливаются. Microsoft решила не мелочиться с рассчётами эффективности. В Windows Server 8 мы официально разрешаем параллельные миграции. Любое количество на ваше усмотрение (настраиваемый параметр), которое, по вашему мнению, резонно на вашем оборудовании. Интересно, каков будет ответ с того света, ибо у них это количество искусственно ограничено.

Live Storage Migration

С Windows Server 8 вы можете переносить виртуальные диски без остановки виртуальных машин. Переносить машину между LUN, между разыми SAN, или с сетевого SMB сервера на LUN. Как выглядит процесс?

 

  1. Вплоть до завершения операции переноса виртуальная машина работает с оригинальным источником виртуальных дисков
  2. В то время как операции чтения/записи происходят с оригинальным диском, он копируется в новое место
  3. По завершению копирования все операции записи дублируются на оригинальное и новое расположение, и в это время реплицируются изменения с оригинального источника, произошедшие за время первоначальной копии диска
  4. По завершению синхронизации виртуальная машина начинает использовать диск с нового места размещения
  5. Старая копия диска удаляется

Live Migration без кластеров и общих дисков

Заголовок прямо таки кричит сам за себя. Действительно, в Windows Server 8 Hyper-V теперь возможен живой перенос виртуальных машин между не кластерными узлами, между кластерами, без использования общего дискового хранилища. Как же это происходит?

 

  1. Вплоть до завершения операции переноса виртуальная машина работает с оригинальным источником виртуальных дисков
  2. В то время как операции чтения/записи происходят с оригинальным диском, он копируется по сети на новый сервер
  3. По завершению копирования все операции записи дублируются на оригинальное и новое расположение, и в это время реплицируются изменения с оригинального источника, произошедшие за время первоначальной копии диска
  4. По завершению синхронизации виртуальная машина начинает использовать диск с сетевого SMB места размещения и инициируется Live Migration машины на новый сервер
  5. После того как миграция успешно завершится и подтвердится, что машина запущена на новом сервере, оригинальная машина удаляется

Comments

  • Anonymous
    January 01, 2003
    Алекс, спасибо за пояснения. Ваши рассуждения понятны. Но почему я спрашивал про замеры: тут может быть засада, когда один поток копирования не утилизирует ресурсы полностью в силу каких-то ограничений: оборудования, драйверов, архитектуры самой операционной системы или гипервизора.В этом случае может получится так, что второй поток задействует неиспользованные ресурсы, и в сумме копирование пройдет быстрее. Я не удивлюсь, если это хорошо проявится на 10 гигабитных картах с офлоудингом, которые могут легко пережевывать несколько параллельных потоков.Вы как считаете? И еще - может сделаете отдельный пост по этому документу www.vmware.com/.../VMware-vSphere-vs-Hyper-V.pdf

  • Anonymous
    January 01, 2003
    Очевидно что глупость. Microsoft эту технологию включает, ибо вражеские продавцы начали активно расхваливать это как преимущество, не давая никаких исследований. Давайте подумаем вместе. Часто ли вы видите выделение нескольких сетевых интерфейсов под нужны VMotion/LiveMigration, да ещё так, что они не объединены в Team? Я тоже не припомню таких кластеров. Если вдруг у меня есть десяток интерфейсов, лучше я два из них в виде TLB Team отдам на эти нужды. Попробуем посчитать. Рассмотрим миграцию двух машин с 10ГБ памяти каждой. Предполагаю, что на копирование одного гигабайта памяти нужно 10 секунд. Виртуальная машина в это время не спит, а работает с памятью, генерируя гигабайт изменений в памяти за минуту. Итого, мигрируя одну машину я затрачу 100 секунд на первоначальные 10ГБ, за это время машина сгенерит 1.6ГБ изменений, их (с учётом изменений во время переноса) я реплицирую за 19 секунд. Итого две минуты на машину, сразу после еще за две минуты перенесу вторую. Та же ситуация, только переношу уже не одну, а две машины сразу. Толщина канала, увы, не увеличилась, считаю что машины переносятся равномерно. Для каждой из них на 1 гигабайт мне нужно уже 20 секунд (за 20 секунд я перенесу 2ГБ, по одному с каждой машины - как и в первом случае). Машины как и ранее генерят по 1ГБ изменений в минуту. На перенос 20ГБ мне, как и ранее нужно 200 секунд. За это время машины сгенерят по 3.3ГБ изменений. На перенос 6.6 ГБ мне нужно 66 секунд (а машины сгенерят еще по 1.11 ГБ). На перенос 2.22 ГБ мне нужно 22 секунды (машины сгенерят по 0,36 ГБ). Последовательность сходится (66 + 66/3 + 66/3/3 ...) = 100. Итого 300 секунд, то есть пять минут. Разница: последовательная миграция прошла за 4 минуты, параллельная - за 5. Если с сервером что-то случится через 2 минуты, то первая машина в последовательном случае уже переехала, вторая перезагрузится. В параллельном перезагрузятся обе.. Смысла в функции нет никакой. Нами введена, чтобы заткнуть голосящих кивинов, продающую педросяна под видом полезности.

  • Anonymous
    January 01, 2003
    Когда запускается мастер "Move VM", там есть возможность указать тип миграции и конечный сервер.

  • Anonymous
    January 01, 2003
    Добавлю про домены. Дяя аутентификации серверов при Live Migration используется Kerberos, по умолчанию требует домена. Через доверительные отношения в пределах леса я настроить смог, работает. Kerberos не работает через External trust, но (теоретически) можно его настроить через Forest Trust. Увы, добиться внятных комментариев, будет ли возможность миграции между доверительными лесами, я пока от разработчиков не смог. Если у вас есть два ноутбука, создайте два леса, они же узлы Hyper-V, я помогу с Kerberos. Для инициации переноса машины требуется доступность контроллера домена.

  • Anonymous
    January 01, 2003
    Что-то ваш раздел "Одновременные Live Migration" какой-то слишком сомнительный. Вы начинаете с фразы "Очевидная глупость" и заканчиваете "Microsoft решила не мелочиться с рассчётами эффективности. В Windows Server 8 мы официально разрешаем параллельные миграции. Любое количество..." Ну так глупость или все же нет? Меня как специалиста-практика не интересует война темных и светлых сторон. Мне нужна для работы объективная информация. Есть результаты сравнительных испытаний последовательной и параллельной миграции на разных платформах? Ссылки?

  • Anonymous
    January 01, 2003
    Еще раз спасибо, Алекс, за разъяснения. Ситуация понятна. Дискуссию действительно пропустил, почитаю - сейчас в силу обстоятельств пока мало в моей жизни виртуализации от MSFT, но полагаю Windows Server 8 изменит положение - это уже больше, чем просто потенциал :-)

  • Anonymous
    January 01, 2003
    Илья, вполне возможно, что многопоточность и компенсирует отставание для двух потоков. В синтетической математике примера выше мы увидели что для паралелльных двух потоков разница в 20% (5 минут против 4 минут) В случае тех же машин и четырёх потоков на перенос потребуется уже 20 минут (геометрическая прогрессия в секундах 400+266+177+118 сходится к 1200). То есть вместо 8 минут последовательной мы потратим на... 150% больше времени. Я сильно сомневаюсь что любые методы оптимизации смогут компенсировать 150% разницу. Про ссылку, что вы дали мы уже бурно подискутировали тут: blogs.technet.com/.../vsphere-principled-performance-benchmark-reality.aspx Странно, что вы пропустили. :)

  • Anonymous
    March 11, 2012
    пара вопросов по миграции без кластеров. как в таком случае в консоли указать куда мигрировать, если кластер не знает об этом гипервизоре? сохраняется ли в таком случае требование принадлежности некластерного гипервизора к домену AD и доступ к контроллеру? если да, домен должен быть тот же или возможны какие-либо трасты между доменами?