VMotion - процесс переноса работающей ВМ между хостами без ее выключения. И без перерыва в ее работе. И "внешние" пользователи приложения на этой ВМ ничего не замечают.
Для того, чтобы у нас такое получилось, необходимо:
- общий LUN, на котором лежат файлы тех ВМ, которые мы хотим мочь мигрировать.
- Названия групп портов для ВМ должны называться одинаково обоих хостах . Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1.
- Процессоры на хостах, между которыми осуществляется перенос - должны быть максимально одинаковы. Подробнее в Online Library, там - Basic System Administration : Migrating Virtual Machines : Migration with VMotion : VMotion Requirements. Даже если при инициации VMotion будет выдаваться ошибка на несовместимость CPU - это можно попробовать поправить, см. тут, и тут. Грубо - смотрим в сообщение об ошибке, на какой регистр ругается. Идем в свойства ВМ и помечаем этот регистр как неиспользуемый. Само собой, прощаемся с официальным суппортом для этой ВМ.
UPD. можно еще тут почитать. - Гигабитная сеть между хостами под задачи самой миграции, в идеале - выделенная.
- Выбираем физическую сетевушку, через которую пойдет трафик VMotion. Цепляем ее к виртуальному свитчу. На нем создаем порт vmkernel(На этом виртуальном свитче могут быть и порты SC, и порты ВМ.). Даем ему настройки IP, не забываем ставить галочку "Enable VMotion". Эту операцию повторяем для обоих хостов. Важно - из консоли пробуем пингануть другой ESX командой vmkping - эта команда задействует сетевой интерфейс vmkernel, а не SC, как простой ping. Важно - пинговать надо IP интерфейса vmkernel для VMotion второго ESX. Если пинги идут - полдела сделано. Если нет - разбираемся почему.
- Убеждаемся, что те LUN и группы портов, которые использует ВМ - доступны ей на обоих хостах. Проще всего это сделать, ткнув в эту ВМ и перейдя на закладку Map. Выглядеть это должно примерно так:
- Если это не так - добейтесь такого результата и..на этом все.
По поводу того, что из себя представляет сам процесс, и что идет через сеть VMotion -
Как только мы запускаем миграцию, память нашей ВМ блокируется на запись. ВМ продолжает работать, но все изменения в ее оперативке пишутся "рядом" с заблокированным массивом.
Теперь эта память передается на другой ESX. Именно через интерфейс vmkernel, который мы задействуем под VMotion.
Как только вся передалась - ВМ блокируется полностью - и на второй ESX передается область памяти с изменениями. Т.к. он почти наверняка будет небольшой - время в течении которого ВМ полностью блокируется также невелико. Весьма невелико.
На этом этапе мы имеем два идентичных процесса, две идентичные ВМ на обоих ESX'ах. Теперь ВМ на исходном хосте убивается, по сети идет оповещение, что машина с этим MAC адресом доступна уже в другом месте. Все.
Если на каком то этапе идет сбой - то ВМ просто не убивается на исходном хосте.
Мне ни разу не приходилось даже слышать о падении ВМ из за VMotion - максимум сам процесс миграции закончится неудачей, значит ВМ как работала, так и будет работать.
0 коммент.:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.