Broadcom ESXi для самых маленьких. Часть 1. Выдача процессоров виртуальным машинам
В очередной раз столкнулся в интернете с отсутствием понимания «что такое виртуализация и как она работает с ядрами и процессором». Вспомнил себя тупого* и решил написать статью «как оно там в ESXi». Чтобы было на что ссылаться.
*Умнее не стал.
Общее состояние
У первый раз столкнувшихся с виртуализацией ESXi by Broadcom, практически нет возможности что-то почитать по теме на русском, а — как показывает практика — нажать кнопку «перевод» в хроме многие брезгуют. Вышедшая на русском 1 (одна) приличная книга по ESXi — Администрирование VMware vSphere 5 — вышла еще в 2012 году. Изложенные в ней общие принципы не изменились, но все же книге 12 лет. Остальные книги по теме (серия Deep dive) — на русском не выходили. Написание книг по ИТ в РФ экономически не оправдано — число реальных покупателей — единицы, проще скачать без смс и на высокой скорости, кстати вот мой телеграмм канал. Читать (бесплатно, скомпоновано, актуализировано, просто и легко, на русском) нечего, а базовые курсы в РФ достаточно дорогие. HOL — слишком сложно.
Я, первый раз столкнувшись с виртуализацией, думал, что система работает как-то так — у меня в системе есть 6 физических \ 12 виртуальных ядер на 2 сокета, я указываю что виртуальная машина (VM) 1 работает на физическом ядре 1, виртуальная машина (VM) 2 — на ядре 2 и 3, и так далее, пока физические или виртуальные ядра не закончатся. Где при этом работает сама ОС \ гипервизор — я как-то не задумывался, какой там Minroot.
Конечно, назначить VM конкретное ядро в ESXi тоже можно (см. Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by Broadcom), но это не режим работы по умолчанию.
Гипертрейдинг или многопоточность
Достаточно часто вводящая в заблуждение функция. С одной стороны, в некоторых задачах этот «второй поток к физическому ядру» может добавить 20–30% производительности, в других — наоборот, скорее вредит. Каких-то однозначных цифр, например «добавляет 10% в среднем для VDI» — нет. По слухам, в следующих версиях Intel может ее и убрать.
Какие задачи решает виртуализация — почему сделано НЕ так, как написано выше
Виртуализация, кроме прочего, решает задачу «нагрузить сервер реальными задачами». Если на вышеуказанный сервер (2 сокета по 6 физических ядер) поставить 6 виртуальных машин по 2 ядра, причем 2\3 времени эти машины будут считать «ничего», то совокупная нагрузка на процессор будет процентов, ну может, 10. Кроме случаев установки обновлений, работы антивируса, работы вируса или попытки админа заработать немного денег на производстве цифровой валюты — есть, в том числе на Хабре, любители заработать небольшую премию, кроме основной работы по цифровой валюте в ведущем банке страны*.
* Это если не надо вклады СССР отдавать, тогда «это не мы».
В остальных случаях имеет смысл поставить еще 10 виртуальных машин, главное разнести тяжелые вычислительные задачи на разное время.
Чаще всего нет смысла в жесткой привязке «эта виртуальная машина исполняется только на этом ядре», и «это ядро исполняет задачи только от этой виртуальной машины».
Какие настройки CPU предоставляет ESXi by Broadcom для виртуальных машин
Согласно статье Setting the number of cores per CPU in a virtual machine (1010184) для VM можно настроить число CPU и Cores per Socket. Может показаться, что это настройка сокетов и ядер, но ESXi пытается отвязать физическую инфраструктуру от предоставляемой внутрь VM, уже давно и с переменным успехом.
Как было раньше (до выхода 6.5)
«Раньше» — в 2013 году — эта настройка называлась Number of virtual sockets и Number of cores per socket и имела огромное значения для производительности, о чем можно почитать тут — Does cores per socket Affect Performance? . Сделано это было, в том числе, из соображений лицензирования.
Как стало теперь (6.5 и после)
К 2016 году и версии 6.5 ситуация в интерфейсе и логике поменялось — стало возможно настроить CPU и Cores per Socket, и, поделив первое на второе, получить число сокетов, о чем пишет тот же автор (Mark Achtemichuk) в статье Virtual Machine vCPU and vNUMA Rightsizing — Guidelines. Почему так? Потому что, начиная с версии 6.5 — изменилось поведение распределение NUMA, о чем автор и пишет,
Essentially, the vNUMA presentation under vSphere 6.5 is no longer controlled by the Cores per Socket value. vSphere will now always present the optimal vNUMA topology unless you use advanced settings.
Ссылаясь на широко известного Frank Denneman
Так как это работает
Если коротко, и не очень корректно — вы не можете, и не должны «просто так», вручную, управлять распределением VM по физическим процессорам. В общих случаях, которых 80–90%, начинайте с 1–2 CPU и 1 cores per socket per VM. Исключение — если производитель того ПО, которое будет работать внутри виртуальной машины, пишет «как надо правильно» или же у вас есть набор готовых тестов для проверки гипотез «как лучше» — потому что некоторое ПО (MS SQL Server например) пытается сам оптимизироваться под среду исполнения. Или, если у вас сверху руководство точно знает как надо и хочет все процессоры сразу.
Огромная часть программ не может нормально обрабатывать многопоточные задачи, поэтому выделение «большего числа ядер», зачастую, вредно. Почему?
Потому, что чем меньше у вас выделено ядер на виртуальную машину, тем легче планировщику найти свободные таймслоты на нескольких ядрах, для синхронного выполнения задач, поступивших в планировщик ресурсов CPU.
Но, если у вас вдруг возникла задача «гарантированно не использовать HT» — еще раз прочитайте короткие заметки и ссылки из них:
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by Broadcom
И разделы:
Enabling this option will result in the vSphere UI reporting only a single logical processor per physical core; halving the number of logical processors if Hyperthreading was previously enabled. In addition Hyperthreading may be reported as 'Disabled' in various configuration tabs.
Из статьи VMware response to «L1 Terminal Fault — VMM» (L1TF — VMM) Speculative-Execution vulnerability in Intel processors for vSphere: CVE-2018–3646 (55806)
Logical processors on the same core have consecutive CPU numbers, so that CPUs 0 and 1 are on the first core together, CPUs 2 and 3 are on the second core, and so on. Virtual machines are preferentially scheduled on two different cores rather than on two logical processors on the same core.
Из раздела VMware vSphere / vSphere Resource Management — Hyperthreading and ESXi Hosts Вместе с темой Set Hyper Threading on ESXi
Что еще почитать по теме
Setting the Number of VMware CPU Cores Per Socket: Best Practices
Прочие чем-то связанные заметки
Тормозящая виртуализация на x86. Небольшая попытка разобраться Часть 4. KVM
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 3: Hyper-V
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Заранее неправильные ответы — 2 или неправильные ответы, которые многие хотят услышать на техническом интервью: Сети (в ESXi)
PS. В комментариях к прошлой заметке, вызвавшей (внезапно для меня, я не хотел) шквал плюсов — задали вопрос » Какая цель статьи?» (там еще всплыла тонна размороженного копиума, но его обсуждать — только время терять, люди не смогли найти перечень самолетов \ бортов пятью статьями ниже).
Так вот, именно у этой статьи цель — тыкать в нее носом коллег — «вот же, все написано, почему не хотите читать».
