vMotion – живая миграция ВМ между серверами

vMotion – это название процесса живой миграции. То есть переезда виртуаль ной машины с одного сервера на другой без перерыва в работе. Живая миграция пригодится вам:

Q когда необходим плановый простой сервера. ВМ с требующего выключе-

ния сервера можно убрать на другие серверы и спокойно выключить его;

Q для балансировки нагрузки. С загруженного сервера можно мигрировать виртуальные машины на более свободные серверы.

Как только мы запускаем миграцию, vCenter проверяет выполнение условий для виртуальной машины и серверов, между которыми она мигрирует. Об условиях далее.

Затем гипервизор начинает копировать содержимое оперативной памяти этой виртуальной машины на другой ESX(i). Но ведь виртуальная машина продолжает работать, и за время копирования содержимого оперативной памяти это содержимое успеет поменяться. Поэтому гипервизор начинает вести список адресов измененных блоков памяти перемещаемой виртуальной машины. ВМ продолжает работать, но адреса измененных страниц в ее памяти фиксируются.

Итак, основной объем памяти передается на другой ESX(i) через интерфейс VMkernel, который мы задействуем под vMotion.

Как только вся память передалась – ВМ блокируется полностью, и на второй ESX(i) передаются измененные страницы памяти. Так как их объем будет небольшой – время, в течение которого ВМ полностью блокируется, также невелико. Весьма невелико. А если объем измененной памяти будет больше некоего порогового значения, значит, ESX(i) просто повторит итерацию. Благодаря этому область памяти, для передачи которой ВМ полностью заморозится, обязательно будет очень небольшой, пусть и через несколько итераций.

На этом этапе мы имеем два идентичных процесса, две идентичные ВМ на обоих ESX’ах. Теперь ВМ на исходном сервере убивается, по сети идет оповещение, что машина с этим MAC-адресом доступна уже на другом порту физического коммутатора. Все.

Если на каком-то этапе идет сбой – то ВМ просто не убивается на исходном сервере и никуда не уезжает, но падения ВМ из-за неудавшегося vMotion не происходит.

Для того чтобы какую-то ВМ можно было мигрировать без простоя между двумя серверами, должны быть выполнены некоторые условия для этой виртуальной машины и этих серверов.

Основное условие vMotion, налагаемое на серверы, – процессоры серверов должны быть совместимы с точки зрения vMotion. Дело в том, что процессор – единственная подсистема сервера, которую виртуальные машины (гостевые ОС) видят такой, какая она есть физически. Не имеет значения, если у процессоров этих серверов окажутся разные тактовые частоты, размер кеш-памяти, количест во ядер. А имеет значение набор поддерживаемых инструкций, таких как SSE 3, SSE 4.1, NX/XD и др. Если на двух разных серверах разные процессоры, а приложение использует какую-то из инструкций, что была доступна до, но не доступна после переезда, – то приложение упадет.

Дабы не допустить этого, vCenter не позволит начать vMotion между серверами с несовместимыми процессорами. Кстати, не забудьте, что часть функций процессора управляется BIOS, так что и серверы с идентичными процессорами могут быть непригодны для горячей миграции между ними ВМ, если настройки BIOS отличаются. Иногда проще всего сбросить их на значения по умолчанию.

В идеале процессоры у вас совместимы для vMotion (подробности доступны в базе знаний VMware). Если нет, но живая миграция очень нужна, вам могут помочь следующие варианты:

Q редактирование так называемой CPUID Mask (свойства ВМ ? Options

?CPUID Mask). Суть в том, что для конкретной ВМ мы можем «спрятать»

те процессорные инструкции, что мешают миграции. Подробные инструк-

ции вы найдете в базе знаний VMware (http://kb.vmware.com/kb/1993);

Q в принципе, отключение самой проверки на одинаковость процессоров, которую делает vCenter. Действие не поддерживаемое, но работающее. Конечно, данное решение имеет смысл использовать, лишь если вы уверены, что приложения в ваших ВМ не задействуют те инструкции, которыми отличаются процессоры серверов. Для отключения проверки необходимо вставить строки

<migrate>

<test>

<CpuCompatible>false</CpuCompatible>

</test>

</migrate>

в файл %AllUsersProfile%\Application Data\VMware\VMware VirtualCenter\vpxd.cfg и перезапустить службу vCenter;

Q Enhanced vMotion Compatibility, EVC. Что это такое, можно прочитать в на-

чальных разделах книги, как это включается – в разделе про DRS. Однако EVC включается и для кластера, в котором DRS не включен.

Вернемся к условиям, которые налагаются на ВМ и серверы из-за vMotion.

Все ресурсы, которые задействует ВМ, должны быть доступны на обоих серверах. Это:

Q разумеется, файлы самой ВМ. vmx, vmdk и прочие (за исключением файла

подкачки vswp). Если резюмировать – ВМ должна быть расположена на общем хранилище. Какого именно типа – FC, iSCSI или NFS, не важно. RDM также поддерживается, но LUN, подключенный как RDM, должен быть виден обоим серверам;

Q для виртуальных SCSI-контроллеров настройка SCSI Bus Sharing не

должна быть выставлена в значение, отличное от None. Это означает, что виртуальные машины-узлы кластера Майкрософт не могут быть мигриро ваны с помощью vMotion;

Q к ВМ могут быть подключены образы CD-ROM и Floppy. Эти файлы также должны быть доступны с обоих серверов;

Q к ВМ не должен быть подключен CD-ROM сервера, то есть настройка

«Host Device» в свойствах виртуального CD-ROM. Те же условия верны для FDD;

Q к ВМ не должны быть подключены физические COM и LPT порты сервера;

Q у ВМ не должно быть настроено CPU Affinity – указание конкретных ядер, на которых должна работать эта ВМ;

Q группы портов, к которым подключена ВМ, должны существовать на обоих серверах. Проверяется только совпадение имен, с точностью до регистра;

Q ВМ не должна быть подключена к виртуальному коммутатору без привя занных физических сетевых контроллеров. Однако проверку на это можно отключить. Для этого вставьте строки

<migrate>

<test>

<CompatibleNetworks>

<VMOnVirtualIntranet>false</VMOnVirtualIntranet>

</CompatibleNetworks>

</test>

</migrate>

в файл %AllUsersProfile%\Application Data\VMware\VMware VirtualCenter\vpxd.cfg и перезапустите службу vCenter;

Q в процессе vMotion между серверами передается содержимое оперативной

памяти ВМ. Это содержимое передается между интерфейсами VMkernel, так что мы должны создать эти интерфейсы. Обратите внимание, что любой интерфейс VMkernel может одновременно использоваться еще и для NFS, iSCSI, Fault Tolerance, и для управляющего трафика (последнее в случае ESXi). Однако для vMotion рекомендуется выделить отдельный гигабитный интерфейс и, как следствие, отдельный интерфейс VMkernel. В свойствах виртуального сетевого контроллера VMkernel, который вы планируете задействовать под vMotion, необходимо поставить флажок «Use this port group for vMotion».

Обратите внимание. vCenter проверяет только факт наличия интерфейсов VMkernel с флажком «Use this port group for vMotion» в свойствах, но не наличие связи между этими интерфейсами разных серверов. Чтобы убедиться, что в конфигурации сети нет ошибок, на одном из серверов выполните команду vmkping <IP vMotion-интерфейса VMkernel второго сервера>.

Для проверки выполнения большей части условий из списка выше хорошо подойдет закладка Maps для виртуальной машины (рис. 6.57).

Обратите внимание на рисунок – на нем показана схема виртуальной инфра-

структуры в контексте vMotion одной ВМ. Сейчас виртуальная машина «File_Server_ Win2008» работает на esx1.vm4.ru. Мною обведены те объекты, на которые стоит обратить внимание, так как они препятствуют vMotion этой ВМ на второй сервер:

Q это группа портов «External_VM_Network» – она есть на одном сервере, но на сервере esxi2.vm4.ru ее нет. Решение – создать группу портов с тем же именем на сервере esxi2. Или перестать ее задействовать для данной ВМ;

Q данная ВМ задействует два хранилища – «iSCSI_LUN_1_main» и «Local_esx1». Притом второе недоступно с сервера esxi2. Решение – или сделать «Local_esx1» доступным со второго сервера (не всегда возможно), или перенести ВМ или ее диск, расположенные на «Local_esx1», в другое хранилище, доступное обоим серверам;

Q «vMotion is disabled» на esxi2 означает, что на этом сервере нет ни одного интерфейса VMkernel, в свойствах которого разрешен трафик vMotion. Решение – создать такой интерфейс или поставить соответствующий флажок в свойствах существующего интерфейса.

Для того чтобы понять, какие группы портов и какие хранилища доступны с обоих серверов, поможет Home ? Maps. На рис. 6.58 вы видите пример такой карты.

Если все проблемы решены, то карта vMotion должна выглядеть примерно так, как показано на рис. 6.59.

Рис. 6.57. Maps для ВМ, которая не может мигрировать на горячую

Рис. 6.58. Карта связей хранилищ с серверами

Рис. 6.59. Maps для ВМ, которая может мигрировать на горячую

Обратите внимание, что через Maps не отображается информация о RDMдисках ВМ. Виртуальную машину с RDM мигрировать с помощью vMotion возможно, однако подключенный как RDM LUN должен быть презентован обоим серверам. Проверить это через Maps нельзя. Впрочем, если к ВМ будет подключен RDM LUN, видимый лишь текущему серверу, об этом вам скажут на первом шаге мастера vMotion.

Единственным файлом ВМ, который не обязан лежать на общем хранилище, является файл подкачки (VMkernel swap). Даже если он расположен на приватном для первого сервера ресурсе, при миграции ВМ будет создан файл подкачки на диске, видимом второму серверу, и содержимое будет перенесено. Но на том диске, где второй сервер располагает файлы подкачки работающих на нем ВМ, должно быть достаточно свободного места, иначе vMotion не произойдет.

Запустить сам процесс миграции можно, выбрав Migrate в контекстном меню ВМ, затем выбрав Change host на первом шаге мастера. Чаще проще перетащить ВМ на нужный ESX(i) – тогда в мастере vMotion будет меньше вопросов. Останутся лишь:

Q Select Resource Pool – помещать ли ВМ в какой-то пул ресурсов, и если да, то в какой;

Q vMotion Priority – резервировать ли ресурсы под перемещаемую ВМ на сервере назначения (выбрано по умолчанию). Или не резервировать. Второй вариант позволит мигрировать ВМ в условиях недостатка ресурсов, пусть даже сама миграция займет больше времени.

По умолчанию с каждого сервера можно одновременно мигрировать 4 (8 для 10 Гбит сети) ВМ. С учетом значительно переработанного и улучшенного компо-

нента, отвечающего за vMotion, даже четырех одновременных миграций, скорее всего, для вас будет достаточно.

Обратите внимание. Имеется в виду именно vMotion, для Storage vMotion и миграции выключенных ВМ параметры по умолчанию другие.

Источник: Михеев М. О. Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.