Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 3: Hyper-V
Для лиги лени. Какая-то заумь про то, что не нужно, потому что все равно у нормальных людей все приложения давно в облаках на микросервисах, и прекрасно работают.
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by Broadcom
Часть 3. Что из этого следует, и как устроен планировщик нормального человека в Hyper-V. Тут не будет ничего нового для тех, кто открывал документацию про корневой раздел (root partition)
Если в ESXi by Broadcom существует отдельно операционная система, в которой есть свой vsish, esxtop, и которая запускает и процессы (из которых важнейшими являются vpxa и hostd) и worlds, то MS Hyper-V с первого взгляда выглядит как «обычная операционная система». Но MS не были бы сами собой, если бы и тут не выступили, устроив гипервизор не первого и не второго типа. Хотя AWS и пишет, что это «гипервизор первого типа»
Как и сами MS пишут в разделе Архитектура — Hyper-V architecture — Hyper-V features a Type 1 hypervisor-based architecture.
Архитектура MS Hyper-V.
Для начала, где-то в самом начале загружается сам гипервизор — Hyper-V. Гипервизор создает корневой (или родительский) раздел (root partition), где загружается ОС, и уже ОС управляет остальными виртуальными машинами, с использованием:
Virtualization Service Provider (VSP) — работает в корневом разделе
Virtualization Service Consumer (VSC) — работает в прочих разделах
VMBus — шина взаимодействия
Hypercall — интерфейс взаимодействия гостевой ОС и хоста.
Планировщик (CPU) в MS Hyper-V
Может быть одним из 3, на выбор:
The classic scheduler. Использовался по умолчанию до Windows Server 2016, включительно.
The core scheduler. Используется по умолчанию, начиная с Windows Server 2019. Обеспечивает бОльшую изоляцию и не только.
The root scheduler. Используется начиная с Windows 10.1803
Взаимоотношения планировщика и основной операционной системы.
Поскольку основная операционная система (хоста) живет в отдельном разделе, то можно покрутить ручки под названием Minroot, отделив «что там делает на ядрах сама ОС» от «что там делают виртуальные машины. Настройка описана в разделе Hyper-V Host CPU Resource Management.
Взаимоотношения с таймером.
В системе используется сразу 4 разных таймера, из них основной и прикрученный намертво — на 100nS, описан в разделе Hypervisor Specification \ Timers
Из этого вытекает некоторая боль с RTC приложениями, голосовыми в основном. То есть, откручивая Minroot и поиграв (и проиграв) неравный бой с таймером в 10nS вместо 100nS, что описано нигде. И в глубине притаился HPET — High Precision Event Timer, он делает очень, очень больно, например в cloud pbx. Будете кушать — узнаете.
Выделение ресурсов.
Сделано через выделение группы процессоров — Virtual Machine Resource Controls. При этом управление такой функцией доступно только через Hyper-V Host Compute Service. Ссылка на Microsoft Virtualization team’s blog из статьи Managing CPU Groups ведет в никуда, вместо блога.
У ESXi есть относительно схожая, но иначе сделанная функция — Resource Pools.
Кроме этого, можно отдельно покрутить и настройки VM — VM cap. Про это есть отдельный раздел в Virtual Machine Resource Controls \ Setting CPU Caps on Individual VMs
В остальных моментах надо сказать, что настройки для классов сервиса (Classes of Service) и VM, описанные в статье Managing CPU resources for Hyper-V virtual machines — писали норкомане, явно не из нашей галактики, и в их мозг надо лучами проникать. Возможно, так удобнее для Azure и его локальных вариантов, но очень скудно описано.
Все вышесказанное приводит к необходимости читать всякое про таймеры, типа
Windows system timer granularity
Clocks, Timers and Virtualization
Timekeeping Virtualization for X86-Based Architectures
Остальные настройки раскиданы по разным местам документации, и вообще описаны почти нигде.
Сети.
Нырять в рамках изначально короткой статьи в глубины Virtual Machine Multiple Queues (VMMQ) , Dynamic VMMQ и проблему Linux Network Performance мне уже не хочется.
Итого.
Hyper-V тормозит точно так же, как ESXi, но делает больно иначе, управляется по другому, и масса статей и заметок утрачена вместе с проведенной чисткой старого technet. Для более подробного сравнения и описания документации недостаточно, необходимо обязательно разворачивать тестовый стенд. Аналог Hands-on lab существует только для Azure — Azure CLX.
Для того, чтобы понять, насколько в ваших условиях Hyper-V лучше или хуже ESXi — необходимо полноценное пилотное тестирование, с вашими нагрузками.
Бонусы.
Случайно нашел. Архивы Virtualization Team Blog
Interview with «Mr Hyper V» Ben Armstrong
Ignite: In Chicago and online: November 18–22, 2024
