Для лиги лени. Какая-то заумь про то, что не нужно, потому что все равно давно у нормальных людей все приложения в облаках на микросервисах, и прекрасно работают.
Часть 4. Что из этого следует, и как устроен планировщик в KVM или KVM- QEMU. Тут тоже не будет ничего нового, но будет масса ошибок.
Ранее:
Часть 1 Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Часть 2 Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by Broadcom
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 3: Hyper-V
Архитектура KVM
Как сказано выше:
у ESXi сначала загружается ESXi, затем все остальное. Просто и легко. Желающие могут при загрузке нажать пару кнопок и наблюдать за загрузкой.
У MS Hyper-V сначала грузится корневой раздел виртуализации, уже внутри его загружается GUI, и затем стартуют остальные разделы.
У KVM – в целом что-то похожее. Вот картинка от AWS с kernel и хостовая ОС живет отдельно. RH вместо картинок размещает ролик про то, что RH это хорошо.
Парой абзацев ниже на AWS написана откровенная чушь -
Kernel-based Virtual Machine (KVM) and VMware ESXi both provide virtualization infrastructure to deploy type 1 hypervisors on the Linux kernel.
Почему чушь
ESXi давным давно, лет 15, НЕ linux kernel, читать про VMkernel тут. При этом vCenter использует Photon OS, которая все же Linux. Раньше (давно) vCenter на Windows был, потом решили сэкономить. ESX (без i) был давно-давно, последние следы Linux выкинули после судебного разбирательства про использование GPL вместе с изменением модели драйверов в версии 7 (выкинули vmklinux driver API) – о чем было известно с 2017 года.
KVM (наконец-то)
Общеизвестно, что KVM живет в связке с QEMU, и треды (или нити, как лучше сказать то?) распределяются через стандартный планировщик (раньше был O(1) scheduler, потом – с 2007 - Completely Fair Scheduler (CFS), про него даже на хабре была статья CFS vs O(1) scheduler.
В 2016 году вышел патч и статья «"The Linux Scheduler: A Decade of Wasted Cores"» - сохранилась тут или тут.
Работа по построению дерева задач описана в разделе CFS Scheduler.
Год назад вышел Earliest eligible virtual deadline first (EEVDF).
При этом что планировщик, что QEMU как-то странно дружат с распределением и по полноценным ядрам, и по HT узлам, и по NUMA нодам, поэтому у RH отведено две страницы в документации на тему «как смотреть что случилось, и какие ручки крутить» в разделе Identifying CPU and NUMA topology.
Про новый планировщик можно почитать тут и тут - Earliest Eligible Virtual Deadline First : A Flexible and Accurate Mechanism for Proportional Share Resource Allocation - Ion Stoica, Hussein Ab del-WahabDepartment of Computer Science, Old Dominion University Norfolk, Virginia, 23529-016
А дальше .. а дальше начинаются проблемы. Потому что статьи типа этой (Earliest Deadline First (EDF) CPU scheduling algorithm ) набиты отборным маркетингом:
Responsiveness: EDF provides a high level of responsiveness for time-critical tasks. It ensures that tasks are scheduled and executed promptly, reducing response times and improving system performance.
Predictability: EDF provides predictability in terms of task execution times and deadlines. The scheduling decisions are deterministic and can be analyzed and predicted in advance, which is crucial for real-time systems.
От статьи Scheduling: Earliest Deadline First не легче ни разу – потому что из статьи не понятно, как планировщик задачи на 10-20 ядер поведет себя, если часть задач из гостевой операционной системы выполнилась, а часть нет. 10-ms слоты упомянуты тут - Composing Scheduling Policies
Therefore, providing a CPU reservation of 5 ms / 33 ms, or 15% of the CPU, using EEVDF requires allocating 45% of the processor bandwidth when the EEVDF scheduler uses a 10 ms quantum. Clearly, this degree of over-reservation is not acceptable in general. EEVDF’s error bounds are optimal, so it is impossible for a different proportional share scheduler to do better than this. To reduce the level of pessimism, the only parameter available to adjust is the scheduler quantum size.
Но найти механизм отрезания Minroot – я не сразу смог. Его, надо сказать, просто так, от скуки, отрезать даже на Windows не нужно, можно внезапно узнать о том, что для обработки сетевого трафика больше чем просмотр Хабра – одного, даже 4 ГГц ядра – недостаточно. Между тем Linux Minroot есть, описан в статье KVM Real Time Guest Config , раздел Host partitioning plan
Остальное управление реализовано через virt-install и содержит достаточно богатый набор настроек в части CPU – cpuset, numatune и даже что-то вместо Enhanced vMotion Compatibility – ключ cpu. И на этом как бы все. Описание ключей тут
Дальше идет специфика – у кого есть cpuunits и affinity (proxmox и openvz), а у кого нет.
Какой-то методики тестирования, как я уже писал – нет, и быть не может как по административным причинам, так и по техническим – у всех свой набор задач и виртуальных машин, и кто как работает и кто кому мешает – сложно.
Мониторинг
Самое сложное в таких сравнениях, это определиться с мониторингом под нагрузкой. Если в ESXi есть достаточно подробно описанные esxtop, то в KVM получить срезы задержек по компонентам \ пути прохождения данных – сложно. Отладка случаев «что-то в драйвере подтекало и дисковая система стала тормозить» может быть очень интересной.
Хотя у RH есть документация на Monitoring Performance in Virtual Machine Manager
и на Virtual machine performance monitoring tools с использованием perf - perf kvm stat live
или взять какие-то шаблоны отсюда - Monitoring VMs on OpenStack (or KVM) using Graphite + Collectd (Last update: 2020-05-14T08:13:47 )
Все это обещает быть очень интересным в ближайшие пару месяцев, в связи со свежей уязвимостью - GhostRace CPU vulnerability threatens all major architectures — IBM and VU Amsterdam researchers detail new cross-platform speculative execution attack.
