Одним из столпов виртуализации является vMotion – живая миграция виртуальных машин между хостов.
95% нагрузок перемещаются без каких-либо последствий, но 5% могут иметь занимательные проблемы – я бы назвал это похмельным синдромом перемещения.
В чём он выражается? Во время миграции вы ощущаете лёгкое отупление как от употребления алкоголя в чуть повышенной дозе, а потом жесточайшие тормоза, длящиеся от пары до пары десятков минут.
vMotion имеет длительную историю, но для меня ключевыми вехами стали версии 5 и 7 (новый функционал релизнули в 7u1). Например, в 5-ке появился целый набор технологий – Mirror [Copy] Driver, Stun During Page Send и Multi-NIC vMotion.
Лучшее доступное описание по архитектуре и настройке читайте в блоге Frank Denneman:
Part 1 – Designing your vMotion network
Part 2 – Multi-NIC vMotion failover order configuration
Part 3 – Multi-NIC vMotion and NetIOC
Part 4 – Choose link aggregation over Multi-NIC vMotion?
Part 5 – 3 reasons why I use a distributed switch for vMotion networks
В 7-ке разработчики озадачились миграцией виртуальных машин с большой нагрузкой и выкатили Monster VM vMotion, о чём подробно можно почитать в документе:
vMotion Innovations in VMware vSphere7.0 U1 .
Теперь вернёмся к причине похмельного синдрома после перемещения – приведу короткую цитату из Sensitive Virtual Machines become impacted by vMotion stun time:
some highly sensitive applications like Database or Banking applications have been known to encounter crash’s or persistent performance impact due to the stun or suspend resume time they experienced as part of the vMotion.
Что же вредного делает этот stun? А он при перемещении ВМ понижает частоту виртуальных процессоров до уровня, когда миграция начинает успевать передавать изменённые страницы памяти с хоста на хост и чем интенсивнее приложение меняет содержимое памяти, тем сильнее приходится прижимать ресурсы процессора. В итоге, мы видим резкий рост очередей на процессор. Пример проблемы на графике: на 20 процессоров две очереди во время миграции составляют по 600 сессий, а потом ~15 минут в районе 300 сессий из-за накопительного эффекта + наложилась борьба за 101% памяти на хосте.
Как сократить время миграции и нивелировать действия stun? Я выбрал старый метод – расширить канал с использованием Multi-NIC vMotion!
У меня есть два сегмента с проблемной миграцией – обычные машины плохо едут по 1 Гбит/с, тяжёлые машины плохо едут по 10 Гбит/с.
Открываем вышеуказанные ссылки плюс статью Multiple-NIC vMotion in vSphere и настраиваем отдельные VMkernel-интерфейсы с сетевыми картами в режиме Active-Standby первый, в режиме Standby-Active второй в политике Teaming and Failover.
У меня ситуация с 10-ками получилась не очень – сетевухи уже 25 Гбит/с, а свитчи всё ещё 10 Гбит/с. Но тяжелые ВМ-ки у меня в 2-узловом кластере, соответственно, интерфейсы под vMotion переключаем на DAC и получаем 2 по 25 Гбит/с.
Результаты
Примечание. Тюнинг vMotion не использовался. Конфигурация железа разная в vSphere 6.7 и в 8.0.
Переход с 6.7 на 7.0 – один канал vMotion на 10 Гбит/с, проверяем улучшения в 7-ке. Миграция ВМ с работающей под высокой нагрузкой системой управления базами данных Oracle DB (20 виртуальных процессоров и 242 гигабайта оперативной памяти) была перемещена за 3 минуты 47 секунд по сравнению с 4 минутами 8 секундами в версии 6.7 – ускорение составило порядка 10%.
Меняем 7-ку на 8-ку, постепенно изменяем конфигурацию сети vMotion:
| ВМ СУБД Oracle DB, низкая нагрузка (64 ГБ, 4 vCPU) |
| Скорость сети, Гбит/с |
Время миграции, сек |
Пиковая скорость |
| 10 |
51 |
1,2 ГБ/с |
| 25 |
23 |
1,8 ГБ/с |
| 2*25 |
14 |
2,7 ГБ/с |
| ВМ СУБД Oracle DB, низкая нагрузка (320 ГБ, 20 vCPU) |
| Скорость сети, Гбит/с |
Время миграции, сек |
Пиковая скорость |
| 2*25 |
76 |
5,3ГБ/с |
| ВМ СУБД Oracle DB, высокая нагрузка (320 ГБ, 20 vCPU) |
| Скорость сети, Гбит/с |
Время миграции, сек |
Пиковая скорость |
| 10 |
~5 1 минута |
~1,2 ГБ/с |
| 2*25 |
61 |
6,2 ГБ/с |
В результате тестов стало ясно, что скорость vMotion растёт практически линейно, если есть что перемещать, – мы получили ускорение до 5 раз при переходе с 10 на 2*25. Для не слишком тяжёлых виртуальных машин не хватает разгона, так как основное время занимают сервисные операции. Если широкого канала хватает для покрытия скорости изменения памяти, то stun не используется и не влияет на время миграции, также мы не видим каких-то особо выраженных пиков по очередям процессора во время начала и конца миграции, да и похмелья у ВМ-ки нет.
