vMotion 5

 

Что интересного я вычитал в документе VMware vSphere vMotion Architecture, Performance and Best Practices in VMware vSphere 5.

 

В пятерке механизм живой миграции улучшился в низкоуровневом техническом плане.

В чем это выражается:

Для начала взяли тестовый веб-сервер:

The test scenario for this case study includes the following:
• A Rock Web/JSP server deployed in a single virtual machine configured with four vCPUs and 12GB memory
• SUSE Linux Enterprise Server 11 x64 as the guest OS
• A benchmark load of 12,000 support users, which generated nearly 6Gbps Web traffic

При использовании 10 Гбит сетевого контроллера, миграция одной и той же ВМ быстрее в vSphere 5 чем в vSphere 4.1:

Притом машинка испытывает меньший негативный эффект от миграции.

Это для vSphere 4.1:

Это для vSphere 5:

 

Однако интересно, что высоконагруженные ВМ по гигабиту мигрируют на пятерке медленнее, чем на четверке:

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

 

После этого тесты начали проводится над ВМ с нагрузкой почтового сервера. В пятерке все лучше.

 

А потом взялись за базы данных.

Конфигурация тестовой ВМ:

Microsoft SQL Server was deployed in a single virtual machine configured with four vCPUs and
16GB of memory.
• The DS2 workload used a database size of 50GB with 50,000,000 customers.
• A benchmark load of 12 DS2 users was used.
Test 2: Multiple-Instance SQL Server Deployment
• Microsoft SQL Server was deployed in two virtual machines. Each virtual machine was configured with
four vCPUs and 16GB of memory.
• The DS2 client ran on two client machines, with each client talking to a unique SQL Server virtual machine.
• The load on both the SQL Server virtual machines was identical, with the aggregate load of 24 DS2 users.
• The total database size was 100GB, with 100,000,000 users.

В пятерке все лучше само по себе, а еще пятерка научилась использовать под одну миграцию сразу несколько сетевых контроллеров, что позволяет мигрировать за приемлемое время даже самые тяжелые ВМ:

Влияние миграции на производительность также измерялась.

Для vSphere 4.1:

Для vSphere 5:

 

А теперь – VDI.

Берем 64 ВМ, Win7, 1 Гб памяти. Слегка нагружаем, массово мигрируем через 10 Гбит:

 

Рекомендации:

• Контроллеры 10 Гбит\с под живую миграцию – это хорошо.
• Если используется reservation, то процентов 30 ресурсов процессора серверов должно оставаться незарезервированным.
• NIOC поможет разрулить нагрузку на сеть, если vMotion работает не через выделенный контроллер\ы.

VMotion ||

Недавно был вброс на тему "Hyper-V отстой", с ответом "Hyper-V рулез". Ссылки ставить лениво, тем более что интересующийся темой человек с такими вбросами может ежедневно сталкиваться.

Одним из фактов является лишь один процесс живой миграции для хоста, что иногда бывает маловато - когда с хоста хочется убрать все ВМ. Вернее, когда с хоста ХОЧЕТСЯ СРОЧНО ААААА!! убрать все ВМ. Такое бывает.

Примеры ситуаций когда 2 миграции за раз мало например тут - VMotion performance.

Так вот, у ESX, по моему, по дефолту до 2 миграций параллельно.
Если этого мало, то:
1) идем на машину где установлен vCenter
2) Открываем C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg
3) между <vpxd></vpxd> вставляем
<resourcemanager>
<maxcostperhost>12</maxcostperhost>
</resourcemanager>
И ребут службы vCenter.

12 это количество "слотов". VMotion занимает 4 слота, так что прописав 12 мы разрешаем до 3 одновременных миграций для хоста. А 24 - до 6.

По ссылке выше кроме этого рецепта еще и иллюстрация:

Секция 1 - это миграция 16 ВМ по 6 за раз.
Секция 3 - их же туда же по 2 за раз.
Время - 3.30 и 6.36.
Как видно, гигабитный интерфейс узким местом не стал.

Moscow's Distance VMotion

Из комментариев к посту Long Distance VMotion:

Admino комментирует...

Проверено не на сотне километров, но на разных окраинах Москвы:
ЦОД-Офис связаны ethernet линком 1Gbs, ping в среднем 1ms, В ЦОДе СХД EMC CX4 FC, lun xxx 0.5Tb, этот же LUN по iSCSI презентован хосту в Офисе.
Этап 1: VMotion виртуальной машины (2cpu/4Gb mem) из ЦОДа в Офис. (около 4 минут)
Этап 2: Storage Vmotion дисков виртуальной машины на локальную СХД. (странно, но данная операция НЕ нагружает канал)


Общие впечатления - без остановки сервисов были полностью перемещены 12 машин за сутки, без каких либо провалов в обслуживании.

Long Distance VMotion

Вам уже могла попадаться на глаза вот такая картинка:


Страшно?

Это про Long-Distance VMotion.
Немного подробностей про то, что надо для живой миграции ВМ за сотни километров - Long Distance VMotion.
Первые два:

• An IP network with a minimum bandwidth of 622 Mbps is required.
• The maximum latency between the two VMware vSphere servers cannot exceed 5 milliseconds (ms).

VMotion CPU Compatibility

Understanding CPU Compatibility Constraints For VMware VMotion - pdf от американской VMUG про совместимость процессоров для живой миграции. Доступно, понятно.

VMotion, CPU mask, EVC

VMotion. Очень хорошая штука. Из условий самое неприятное - требование совместимости процессоров хостов.
Если этой совместимости нет, а живой миграции хочется, что можно сделать:

Статья из kb VMware про все способы разрешить vMotion между хостами с разными процессорами - VMotion CPU Compatibility - Migrations Prevented Due to CPU Mismatch - How to Override Masks.
Статья в kb VMware про EVC - Enhanced VMotion Compatibility (EVC) processor support. В частности, там приводятся группы совместимости ЦП с т.зрения EVC.

vMotion CPU compatibility - EVC

Для живой миграции - vMotion - есть два самых потенциально проблематичных условия:
наличие разделяемой системы хранения
и совместимых процессоров.

К счастью, ситуация с процессорами давно и уверенно меняется к лучшему, и уже начиная с VI 3.5 U2 у нас появилась возможность пользоваться EVC - Enhanced VMotion Compatibility.

C т.зрения VI это свойство(или функция) DRS кластера. Когда мы для DRS кластера ее включаем - процессоры хостов настраиваются таким образом, чтобы обеспечить совместимость процессоров для vMotion.

Информация и ссылки по теме доступны в kb - Enhanced VMotion Compatibility (EVC) processor support.

В частности, там указаны модели процессоров Intel и AMD, которые обладают совместимостью по EVC(правда, смотрел смотрел я на эту табличку - так и не догнал что она пытается сказать %)

Обратите внимание:
Мигрировать МЕЖДУ Intel и AMD нельзя.
Мигрировать между Intel-Intel может быть можно, а может и нет - есть определенные границы совместимости. У AMD вроде как совместимость полная.
Если есть CPU с поддержкой EVC(это значит, в CPU есть фича Intel FlexMigration или AMD-V Extended Migration ), и процессоры без оной, то вроде как более новые процы сумеют таки подстроится под старые.

Количество одновременных VMotion

По умолчанию с каждого хоста может одновременно мигрировать 2 ВМ. Имеется в виду - на горячую, т.е. VMotion.
Теоретически, возможна ситуация, когда этого мало - на хосте много ВМ, нам нужно хост освободить(для перезагрузки после обновления), и ждать не хочется.
Есть возможность мигрировать больше ВМ за раз:

1. Логинимся на vCenter Server.

2. Открываем в WordPad файл vpxd.cfg
“C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter”
Имеет смысл сделать резервную копию.

3. Ищем теги <vpxd> </vpxd> И вставляем между ними
<ResourceManager>

<maxCostPerHost>12</maxCostPerHost>

</ResourceManager>

4. Теперь надо подумать, какую цифру вставлять в “maxCostPerHost”.

Холодная миграция имеет цену 1, VMotion имеет цену 4. Если поставить 12, то одновременно можно будет делать три(=12 делить на 4) VMotion миграции(с одного хоста). Автор поставил 24, и мог мигрировать одновременно 6 ВМ.
Максимальное значение этого параметра неизвестно, проверялось до 24.

6. Сохраняемся, выходим, перезагружаем vCenter.

Источник и подробности - Guest blog entry: VMotion performance.

MS Quick Migration и VMware VMotion

Демонстрация того, чем MS Quick Migration хуже VMware VMotion:

Наглядное видео:


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

трафик VMotion полезно держать изолированным

Пост в Security блоге VMware - о том, что трафик VMotion полезно держать изолированным. В частности, ссылаются на описание действий для получения доступа к и даже взаимодействию с ВМ в процессе LiveMigration(в этом документе говориться про Xen, но к VMware это тоже потенциально применимо).

VMotion обрывается по таймауту на 10 процентах

На курсах регулярно приходиться сталкивать с ситуацией:
запускаем VMotion, проходим мастер, запускается процесс. Прогресс бар доходит до 10 процентов, висит, висит, висит и вываливается по таймауту.
Скорее всего,из моего опыта, такое присходит из за того, что интерфейсы ядра для VMotion торчат в разные физические сети, примерно так:

Пороверяется такая ситуация пингом, но обычный ping не подойдет - он идет через vswif, интерфейсы SC. Используем команду vmkping - она как раз идет через интерфейсы ядра.
А вот камрад VMwareWolf на своем блоге приводит все возможные причины такой ошибки. 9 пунктов, со ссылками в kb. Смотрим тут.

после апгрейда до ESX 3.5. в некоторых случаях может слетать VMotion

Есть мнение, что после апгрейда до ESX 3.5. в некоторых случаях может слетать VMotion, в смысле - соответствующая галочка в настройках интерфейса ядра. Имеет смысл проверять, думаю.
Отсюда.

Надежность процесса VMotion

Часто приходится сталкиваться с вопросом - вот миграция работающей ВМ между хостами, то, что VMware называет VMotion - насколько это надежно?

Обычно я отвечаю - надежно, и весьма :). Теперь могу ответить более аргументированно.

Кратко:
Microsoft TechED в Барселоне. Win2003 64-bit. SQL 2005. Эта ВМ и 100 других - на 6 ESX серверах. SQL под нагрузкой DBhammer, эмулирующий примерно 1 200 запросов в секунду от 150 клиентов. Была написанна утлитка VMjuggler, задачей которой было мигрировать ВМ на другой хост каждые 10 секунд. Сам процесс VMotion занимал секунд 10, и через 10 секунд начиналась очередная миграция. За 5 дней(!) эта ВМ "прыгнула" более 10 000(!!) раз. Проблемы были. Проблемы были с написанной на коленке VMjuggler :), но Virtual Center ни на что не жаловался, SQL работал и DBhammer все так же генерировал нагрузку.



Более подробно - тут.

P.S. В конце заметки автор выражает удивление тем, что не раз у него просили утилитку VMjuggler. Обещает немного довести ее до ума и выложить. И ждет того, у кого ВМ первая наберет миллион миграций :)).

Еще раз к вопросу несовместимых CPU при VMotion,

Чрезвычайно уважаемый среди меня человек, Олег Кириллов, поделился рецептом решения проблем несовместимых CPU при VMotion. Цитирую:
"..
В программке VMotion Info в отладочном окошке можно посмотреть информацию CPUID всех процессоров кластера.
Когда VMotion ругается на конкретный регистр определенного уровня я беру значения этого регистра от обоих процессоров, открываю калькулятор Windows, переключаю его в научный режим и умножаю значения регистров друг на друга командой AND. Полученное значение загоняю в качестве маски.
В результате на обоих хостах виртуалка видит одинаковые процессоры с одним и тем же набором функций. Естественно, того CPU, который древнее.
Я списался с автором программки, он обещался в следующей версии сделать не только автоматический расчет масок, но и их установку указанным виртуалкам.
Обещанного три года ждут...
.."

Ранее, по этому вопросу писалось тут.

Проблемы при Cold migration.

Тут чувак описывает пару проблем, с которыми довелось столкнуться при холодной миграции ВМ между ESX.
Первая - мастер выдавал warning, что к ВМ подключен iso'шник с локального диска, но позволял двинуться дальше. Если двинуться дальше - на 99% операция прерывалась ошибкой примерно такой - “Invalid configuration for device 1″. Вывод - следует избегать даже предупреждений при инициации таких действий. После удаления отсылов на этот iso, операция проходила корректно.

Вторая - “The specified key, name, or identify already exists”. Возникала при миграции ВМ на хост, где уже есть ВМ с тем же именем. Вообще говоря, у каждой ВМ есть GUID, т.е. требования к уникальности имени нет. Но практика показала, что при миграции лучше бы одинаковых имен не допускать. Меняем имя, мигрируем, меняем имя взад.

Примерно так.

Как выбрать правильный набор лицензий.

Тут(на англ.) рассказано, какие лицензии бывают.
Вкратце:
Есть ESX, в двух вариантах - Starter и Standart. Первый не умеет работать с СХД кроме локальных дисков и NFS, максимум на 4х процессорном сервере будет работать.(список не полон).
Далее, отдельно покупаются:
VMotion
DRS
HA
VCB
VirtualCenter.

Набор из всех лицензий называется Enterprise, стоит дешевле, чем эти лицензии покупать поотдельности.

Это вкратце.

Неплохие обзоры?

Чувак отсюда сделал несколько интересных постов:

• Что привнесет в виртуализацию ESX3i?
  
• Как выбрать правильный набор лицензий VI3?
• Какие действия правильны с т.зрения безопасности VI3?
• Утилиты в составе VCB - что могут и как использовать?
  

VMotion, CPU Masking

Вы знаете, что такое VMotion?
Вы настроили его?
Он не заработал из за несовместимости CPU?

Тут пост, где должна была быть :) картинка про решение этой проблемы, и в нем ссылка на то место, откуда стоит начать узнавать что такое CPU masking и как им пользоваться.

CPU masking

Тут описывается опыт CPU masking.

добавил эту ссылку в пост про VMotion.

Настройка VMotion

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

Для того, чтобы у нас такое получилось, необходимо:

1. общий LUN, на котором лежат файлы тех ВМ, которые мы хотим мочь мигрировать.
2. Названия групп портов для ВМ должны называться одинаково обоих хостах . Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1.
3. Процессоры на хостах, между которыми осуществляется перенос - должны быть максимально одинаковы. Подробнее в Online Library, там - Basic System Administration : Migrating Virtual Machines : Migration with VMotion : VMotion Requirements. Даже если при инициации VMotion будет выдаваться ошибка на несовместимость CPU - это можно попробовать поправить, см. тут, и тут. Грубо - смотрим в сообщение об ошибке, на какой регистр ругается. Идем в свойства ВМ и помечаем этот регистр как неиспользуемый. Само собой, прощаемся с официальным суппортом для этой ВМ.
   UPD. можно еще тут почитать.
   
4. Гигабитная сеть между хостами под задачи самой миграции, в идеале - выделенная.

Итак, есть ВМ на общем LUN. Есть ESX1 и ESX2 - между ними хотим смигрировать. Что надо настроить:

1. Выбираем физическую сетевушку, через которую пойдет трафик VMotion. Цепляем ее к виртуальному свитчу. На нем создаем порт vmkernel(На этом виртуальном свитче могут быть и порты SC, и порты ВМ.). Даем ему настройки IP, не забываем ставить галочку "Enable VMotion". Эту операцию повторяем для обоих хостов. Важно - из консоли пробуем пингануть другой ESX командой vmkping - эта команда задействует сетевой интерфейс vmkernel, а не SC, как простой ping. Важно - пинговать надо IP интерфейса vmkernel для VMotion второго ESX. Если пинги идут - полдела сделано. Если нет - разбираемся почему.
   
2. Убеждаемся, что те LUN и группы портов, которые использует ВМ - доступны ей на обоих хостах. Проще всего это сделать, ткнув в эту ВМ и перейдя на закладку Map. Выглядеть это должно примерно так:
3. Если это не так - добейтесь такого результата и..на этом все.

Тыкаем правой кнопкой в ВМ, выбираем Migrate. Если ВМ включена - этот пункт и запустит VMotion. Выбираем хост, на который хотим смигрировать. Процесс начинается. Если все условия выполнены - скорее всего :) он заканчивается нормально.

По поводу того, что из себя представляет сам процесс, и что идет через сеть VMotion -
Как только мы запускаем миграцию, память нашей ВМ блокируется на запись. ВМ продолжает работать, но все изменения в ее оперативке пишутся "рядом" с заблокированным массивом.
Теперь эта память передается на другой ESX. Именно через интерфейс vmkernel, который мы задействуем под VMotion.
Как только вся передалась - ВМ блокируется полностью - и на второй ESX передается область памяти с изменениями. Т.к. он почти наверняка будет небольшой - время в течении которого ВМ полностью блокируется также невелико. Весьма невелико.
На этом этапе мы имеем два идентичных процесса, две идентичные ВМ на обоих ESX'ах. Теперь ВМ на исходном хосте убивается, по сети идет оповещение, что машина с этим MAC адресом доступна уже в другом месте. Все.
Если на каком то этапе идет сбой - то ВМ просто не убивается на исходном хосте.
Мне ни разу не приходилось даже слышать о падении ВМ из за VMotion - максимум сам процесс миграции закончится неудачей, значит ВМ как работала, так и будет работать.