vMotion под капотом

Это перевод статьи Niels Hagoort The vMotion Process Under the Hood. Публикуется с разрешения автора.

VMware vSphere vMotion на сегодня одна из самых важных возможностей для виртуализированной инфраструктуры. С момента появления в 2002 и релиза в 2003 vMotion позволяет нам мигрировать включенные, активные виртуальные машины с одного физического ESXi хоста на другой. Сегодня возможность бесшовной живой миграции виртуальных машин является неотъемлемой частью почти любой платформы виртуализации. Переносимость рабочих нагрузок является ключевой возможностью для адаптации гибридного облака, необходимой для их перемещения между on-premises инфраструктурой и публичным облаком с применением VMware Hybrid Cloud Extension (HCX). Технология vSphere vMotion по-прежнему остается и всегда будет оставаться одним из самых значительных изменений в ИТ-индустрии.

Для поддержки новых технологий за все эти годы было проделано много работы и изменений внутри vMotion.

Этот пост будет посвящен только технологии живой миграции вычислительных нагрузок, стандартной vMotion, позволяющей перенести активное состояние включенной виртуальной машины с одного ESXi хоста на другой. Также имеется возможность выполнить Storage vMotion, который в сочетании со стандартным vMotion (Compute vMotion) называется XvMotion. Другими вариантами миграции являются Long Distance vMotion и Cross vCenter vMotion, которые в основном уже являются процессами vCenter Server поверх процесса vMotion со стороны ESXi хостов.

Прочитав эту статью, вы лучше поймете “магию”, которая происходит под капотом vSphere, когда вы выполняете миграцию виртуальных машин.

Процес vMotion

Когда запускается миграция виртуальной машины, vCenter Server запускает так называемую долгосрочную задачу миграции, которая и осуществляет миграцию. Первым шагом будет произведена проверка совместимости. Возможно ли будет запустить виртуальную машину на целевом хосте? Подумайте о возможных ограничениях, которые могут помешать живой миграции. Далее необходимо сообщить исходному и целевому ESXi хостам, что происходит. Создается так называемая спецификация миграции, которая содержит следующую информацию:

• Виртуальная машина, подлежащая живой миграции;
• Конфигурация этой виртуально машины (Virtual Hardware, VM настройки и т.д.);
• Исходный ESXi хост;
• Целевой ESXi хост;
• Сетевые настройки vMotion.

vCenter Server обеспечивает распространение спецификации миграции между исходным и целевым ESXi хостами, гарантируя доставку всей необходимой информацией для запуска процесса миграции. vCenter Server обменивается с ESXi хостами информацией используя Virtual Provisioning X Daemon (VPXD), который общается с Virtual Provisioning X Agent (VPXA), работающим на ESXi хостах. VPXA ожидает сообщения от VPXD и получив спецификацию миграции он передает ее процессу VMX через hostd. Host Daemon (hostd) обеспечивает доступ к хосту для управления и поддерживает актуальной информацию о конкретном хосте, включая телеметрию виртуальных машин, например, VMstate. Когда миграция запущена, hostd переводит виртуальную машину в промежуточное состояние, именно поэтому ее конфигурация не может быть изменена во время миграции.

Virtual Machine Monitor (VMM) процесс отвечает за управление памятью виртуальной машины и передает запросы ввода-вывода и сетевого ввода-вывода виртуальной машины в VMkernel. Все остальные, не критичные к производительности, запросы ввода-вывода VMM пересылает в VMX. VMX (Virtual Machine Extension) процесс работает в VMkernel и отвечает за обработку операций ввода-вывода для устройств, некритичных к производительности. Обратите внимание, что VMM во время миграции используется только на исходном ESXi хосте, потому что именно там находится активная память виртуальной машины.

После того, как все подготовительные работы будут закончены, модуль миграции VMkernel на исходном ESXi хосте откроет сокеты в сети vMotion, чтобы установить связь с целевым ESXi хостом.

От подготовки до предварительного копирования (Pre-Copy)

Теперь все подготовлено для начала живой миграции. Фаза подготовки полностью посвящена тому, чтобы целевой ESXi хост зарезервировал вычислительные ресурсы для виртуальной машины, подлежащей миграции. Кроме того, создается виртуальная машина на целевом ESXi хосте, но она маскируется. Вся информация о конфигурации виртуальной машины уже известна, поскольку она была включена в спецификацию миграции.

После завершения этапа подготовки процесс миграции переходит к этапу предварительного копирования (Pre-Copy Phase), где содержимое памяти передается из исходного на целевой ESXi хост. Появляется необходимость следить за всеми страницами памяти виртуальной машины на исходном ESXi хосте. Процесс vMotion следит и знает, какие страницы памяти перезаписываются во время миграции, они называются грязными страницами, их vMotion должен будет повторно отправить на хост назначения.

Трассировка страниц памяти

На этапе предварительного копирования страниц, vCPU, используемые виртуальной машиной, кратко приостанавливаются, для установки трассировщика страниц. Модуль миграции VMkernel просит VMM запустить трассировку страниц, поскольку VMM владеет состоянием таблицы размещения страниц памяти виртуальной машины. Следующая диаграмма показывает, что происходит, когда гостевая ОС записывает данные в память во время vMotion:

Итерационное предварительное копирование памяти

Трассировка страниц памяти — это непрерывный цикл. Он будет работать до момента полной сходимости памяти, используя несколько итераций предварительного копирования. Первая итерация (Pre-Copy Phase -1) скопирует память виртуальной машины. Следующие итерации (Pre-Copy Phase 0 to n) скопируют грязные страницы памяти, появившиеся на этапе предыдущей итерации.

Например, вот как могут выглядеть итерации, когда мы выполняем живую миграцию виртуальной машины с 24 ГБ памяти:

• Phase -1: Копируется 24 ГБ памяти виртуальной машины и работает трассировка. Пока происходит копирование, появляется 8 ГБ грязных страниц;
• Phase 0: Передаем 8 ГБ грязных страниц. За это время появляется еще 3 ГБ грязных страниц;
• Phase 1: Отправляет 3 ГБ. Пока предаем, виртуальная машины “испачкала” еще 1 ГБ;
• Phase 2: Отправляем последний 1 ГБ.

Страницы памяти копируются с исходного ESXi хоста на целевой ESXi хост, пока вся память не будет скопирована. VMM спрашивает VMkernel, можно ли прекратить процесс предварительного копирования (Pre-Copy) после каждой итерации. Это возможно только тогда, когда все изменения памяти (грязные страницы) будут скопированы на целевой хост. Частью алгоритма итеративного предварительного копирования памяти является сравнение всех целевых страниц памяти с их источниками. Начиная с нулевой страницы и вплоть до максимальной, последней страницы памяти, все они последовательно проверяются, чтобы убедиться, что целевые страницы синхронизированы с исходными.

Чтобы определить, можно ли прекратить предварительное копирование, нужно проверить, возможем ли завершить последнее копирование страниц памяти в окне <500 мс. Это можно рассчитать, используя следующую информацию (так называемый migration tax):

• Скорость передачи; С какой скоростью (GbE) мы копируем данные памяти между хостами?
• Скорость появления грязных страниц (ГБ/с); Сколько страниц памяти перезаписывается гостевой ОС?
• Сколько страниц нам осталось передать хосту назначения?

Если нет, происходит следующая итерация. Если результат будет положительным, модуль миграции VMkernel прекратит процесс предварительного копирования.

Что произойдет, если скорость появления грязных страниц выше, чем скорость передачи? Если это так, нет смысла делать следующую итерацию, потому что мы никогда не сможем достичь сходимости памяти, и миграция остановится. Вот почему мы и представили Stun During Page Send (SDPS) в vSphere 5.0. По сути, SDPS — это способ для VMkernel сказать VMM не выполнять запланированные инструкции, а очень коротко усыпить выполнение виртуальной машины. Это может выглядеть как влияние на производительность рабочей нагрузки, но пауза очень короткая. Мы говорим здесь о микросекундах, и именно благодаря этой очень маленьких временной задержке мы можем достичь сходимости памяти, и процесс vMotion будет успешным.

SDPS выполняется при каждой итерацией, если скорость появления грязных страницы > скорости передачи. Последующие итерации копируют только грязные страницы памяти, которые были изменены во время предыдущей итерации. Более короткая продолжительность итерации оставляет гостевой ОС меньше возможностей для модификации или “загрязнения” страниц памяти, что сокращает время следующей итерации. Несмотря на то, что SDPS снижает производительность, обычно SDPS незаметен для рабочей нагрузки. Цель состоит в том, чтобы гостевая ОС даже не подозревала о живой миграции.

Переключение

Поскольку предварительное копирование памяти прекращено VMM, все страницы памяти уже находятся на целевом хосте ESXi. Теперь VMM отправляет RPC вызов в VMX, чтобы он мог приостановить работу исходной виртуальной машины. VMX войдет в фазу контрольной точки (Checkpoint Phase), где он приостановит работу виртуальной машины на исходном хосте и отправит данные контрольной точки на целевой ESXi хост.

Виртуальная машина на целевом ESXi хосте будет демаскирована, и ее состояние будет восстановлено с использованием данных контрольной точки. Проще говоря, происходит следующее, виртуальная машина на целевом ESXi хосте включается, но процесс загрузки прерывается и переключается на страницы памяти, перенесенные с исходного ESXi хоста. Все это обычно происходит за 100–200 мс. Это время заморозки, когда виртуальная машина находится в нерабочем состоянии. Продолжительность времени заморозки зависит от множества факторов, таких как аппаратное обеспечение хоста и активность других гостевых нагрузок хоста.

Виртуальная машина совершила живую миграцию!

Заключение

Хотя я попытался подробно объяснить процесс vMotion, существует гораздо больше деталей, происходящих при живой миграции в фоновом режиме. Я надеюсь, что вы оцените этот пост. Большое спасибо нашей инженерной команде vMotion за предоставление этой бесценной информации.

Если вы собираетесь посетить VMworld, обязательно посетите сессию HBI2333BU — ‘How to Get the Most Out of vSphere vMotion’! Что монжо сделать для увеличения производительности vMotion в условиях растущих рабочих нагрузок? На этом сессии вы получите еще более подробную информацию о процессе vMotion, рекомендации по снижению времени миграции и поиску ошибок. Узнаете, как настроить vMotion для получения еще большей производительности с помощью 100GbE сетевых адаптеров.