Vmware vcpu что это

Управление числом vCPU и ядер в виртуальной машине

10.02.2020

itpro

Hyper-V, KVM, VMware, Windows 10, Виртуализация

комментария 2

При создании виртуальных машин на различных гипервизорах (VMWare, KVM, Hyper-V и т.д.) вы можете обратить внимание, что иногда виртуальная машина может не видеть все выделенные ей виртуальные ядра (vCPU). В нашем случае виртуальной машине на KVM были выделены 8 vCPU, на нее установлена Windows 10. Однако Windows определяла эти ядра как отдельные процессоры, из которых можно использовать только 2 vCPU.

Виртуальная машина Windows 10 не видит все ядра

Если открыть диспетчер устройств Windows, можно убедится, что все выделенные ядра видны в качестве 8 отдельных виртуальных процессоров типа QEMU Virtual CPU version 2,5.

При этом в свойствах Windows 10 (Computer -> Properties) и в Task Manage видно, что на компьютере доступны только 2 процессора QEMU Virtual CPU.

То есть сколько бы вы не добавили виртуальных ядер, Windows 10 все равно сможет использовать только два. При этом соседний виртуальный сервер с Window Server 2016 на этом же гипервизоре видит все 16 выделенных ему vCPU.

Количество поддерживаемых процессоров в Windows 10

Проблема заключается в том, что в десктопных редакциях Windows (Windows 10/8.1/7) есть ограничение на максимальное количество физических процессоров (сокетов), которое компьютер может использовать:

• Windows 10 Home – 1 CPU
• Windows 10 Professional – 2 CPU
• Windows 10 Workstation – до 4 CPU
• Windows Server 2016 – до 64 CPU

Однако это ограничение не распространяется на ядра. Т.е. для повышения производительности вы можете использовать процессор с большим количеством ядер. Большинство гипервизоров умеют предоставлять vCPU в виде процессоров, процессорных ядер или даже потоков. Т.е. вместо 8 виртуальных CPU вы можете предоставить vCPU в виде 2 сокетов по 4 ядра в каждом. Рассмотрим, как в различных системах виртуализации выделить виртуальные процессоры в виде ядер и как это связать с архитектурой NUMA, использующейся в современных процессорах.

Управление виртуальными ядрами и vCPU в KVM

В моей виртуальной машине KVM c Windows 10, все назначенные виртуальные ядра считаются отдельными процессорами.

Чтобы использовать все ресурсы CPU, выделенные виртуальной машине нужно, чтобы виртуальная машина видела не 8 процессоров, а один 8-ядерный процессор, 2 процессора по 4 ядра или 1 процессор с 4 ядрами по 2 потока. Попробуем изменить способ назначения виртуальных ядер для ВМ на KVM.

Выключите виртуальную машину:

# virsh shutdown server.vpn.ru – где server.vpn.ru это имя виртуальной машины.

Особенности управления ВМ в KVM из консоли сервера с помощью virsh.

Выведите текущую XML конфигурацию виртуальной машины KVM:

# virsh dumpxml server.vpn.ru

Нам интересен блок с описанием процессоров:

8 1000  /machine  hvm      

Как видим, у нас указано просто 8 vCPU. Изменим конфигурацию:

# virsh edit server.vpn.ru

И после добавим:

• host-passthrough — режим эмуляции при котором на виртуальной машине будет показан физический процессор узла кластера (ноды).
• sockets=’1′ — указываем что процессор 1
• cores=’4′ — указываем, что процессор имеет 4 ядра
• threads=’2′ — указываем, что ядра у нас по 2 потока

Сохраните конфигурационный файл и запустите ВМ. Авторизуйтесь в гостевой ВМ с Windows 10 и в Task Manager или Resource Monitor проверьте, что ОС видит все выделенные виртуальные ядра.

Также в свойства системы теперь стал отображаться физический процессор хоста Intel(R) Xeon(R) Silver 4114 CPU, а не виртуальный.

Так нам удалось решить проблему с нагрузкой на ВМ, так как двух ядер не хватало для полноценной работы приложений.

Настройка виртуальных процессоров и количества ядер в VMWare

Вы можете изменить способ презентации vCPU для виртуальной машины VMWare из интерфейса vSphere Client.

1. Выключите ВМ и откройте ее настройки;
2. Разверните секцию CPU;
3. Изменим конфигурацию ВМ так, чтобы гостевая ОС видела 2 процессора по 4 ядра. Измените значение Cores per Socket на 4. Это означает, что гостевая ОС будет видеть два четырех –ядерных процессора (2 сокета по 4 ядра);
4. Сохраните изменения и запустите ВМ.

Архитектура NUMA и виртуальные vCPU

Есть еще несколько аспектов назначения vCPU и ядер виртуальным машинам, которые нужно понимать.

При назначении ядер на сокете учитывайте наличие NUMA архитектуры (используется в большинстве современных CPU). Не рекомендуется назначать вашей ВМ количество ядер на сокет (и общее количество vCPU) больше, чем доступно ядер на вашем физическом сокете/процессоре (ноде NUMA). При размещении на одной физической ноде NUMA, виртуальная машина сможет использовать быструю локальную RAM, доступную на конкретной ноде NUMA. Иначе для выполнения операции процессам придется ждать ответа от другой ноды NUMA (что несколько более долго).

Если вы назначаете для ВМ два отдельных виртуальных сокета, то гипервизор может их запускать на разных нодах NUMA. Что не лучшим образом скажется на производительности ВМ.

Если количество требуемых vCPU превышает количество ядер на 1 физическом сокете (ноде NUMA), нужно создать несколько виртуальных сокетов (процессоров) с необходимым количество ядер. Также не желательно использовать нечетное количество процессоров (лучше добавить 1 vCPU)

Это позволит сохранить производительность виртуальной машины.

Например, для 2 процессорного хоста с 10 ядрами (суммарно доступно 40 vCPU с учетом Hyper—Threading), при настройке vCPU для ВМ оптимально использовать такие конфигурации:

Требуемое количество vCPU	Количество виртуальных сокетов в настройках ВМ	Количество ядер на виртуальном процессоре в настройках ВМ
1	1	1
……
10	1	10
11	Не оптимально
12	2	6
……
20	2	10

В бесплатной версии ESXi вы не можете создать ВМ более чем с 8 vCPU.

Например, ВМ с Microsoft SQL Server 2016 Enterprise Edition 16 vCPU в конфигурации 8 сокетов по 2 ядра будет работать хуже, чем в конфигурации 2 сокета по 8 ядер.

Также не забывайте, что некоторые приложения лицензируются по физическим сокетам (так было в старых версиях SQL Server). Иногда вам просто выгоднее лицензировать один многоядерный процессор, чем несколько процессоров с меньшим количеством ядер.

Современные версии Windows Server лицензируются в среде виртуализации по-особому. Также есть свои особенности лицензирования процессоров в VMWare vSphere.

Предыдущая статья Следующая статья

Каждому по потребностям: как мы решали задачу с «нарезкой» vCPU

Всем привет! Возникал ли у вас вопрос, как можно ограничить виртуальную машину по используемым CPU?

У нас в Selectel он возник, когда мы хотели сделать облачную платформу гибче и удешевить инфраструктуру для клиентов. В результате получилась линейка виртуальных машин Shared Line. Это облачные серверы с гарантированной долей производительности ядра — их арендуют те, кому не нужна полная загрузка CPU.

Под катом расскажу, как мы учились «резать» мощности облачных серверов на кусочки.

Зачем нужно управление производительностью виртуальных машин

Можно выделить пару сценариев, где будет полезно управлять производительностью виртуалок:

1. Хотим ограничивать доступный объем ресурсов.

Подобное требование может возникнуть, когда необходимо быть уверенным, что виртуальная машина не потребует весь доступный ресурс по CPU и оперативной памяти. В таком случае мы говорим о жестком ограничении на используемые ресурсы.

2. Хотим приоритизировать процессы.

С приоритизацией все интереснее, так как здесь мы не ограничиваем виртуальную машину напрямую, а лишь устанавливаем ее приоритет в очереди на использование ресурсов.

Зачем это пользователям

Представим человека, который хочет развернуть виртуальную машину и разместить там pet-проект. Если проект будет крутиться на домашнем компьютере (все же дома используют Linux, да?), то может не хватить ресурсов на другой pet-проект, браузер или катку в Dota. А если разворачивать такой проект в облаке, то под него пришлось бы брать целый процессор.

Если на начальном этапе больших нагрузок не предвидится, даже минимальная конфигурация «виртуалки» может быть избыточна — будем платить за простаивающие ресурсы. И тут как раз пригодилась бы возможность создать виртуальную машину с определенной долей ядра.

А организациям пригодится?

Рассмотрим сферическую компанию в вакууме. Допустим, она содержит свою или арендует облачную инфраструктуру у провайдера. На виртуальных машинах развернуто суперважное ПО — например, Jira и Confluence, а также ряд сервисов поменьше — какой-нибудь телеграм-бот для напоминаний. Возможно, есть еще ряд экспериментальных служб и приложений — отдельные сотрудники сделали себе удобные инструменты.

Для надежности каждое приложение или сервис запущено на своей виртуальной машине. Со временем сервисов будет становиться все больше. Какие-то из них станут тяжелее. Часть хостов нужно будет выключать на обслуживание и, рано или поздно, наступит момент, когда ресурсы в инфраструктуре закончатся. Проблема.

Ответ тем, кто умеет в микросервисы и Kubernetes
Даже оркестрация контейнеров и подобные фокусы все равно не гарантируют полной утилизации мощностей.

Самое очевидное, что можно сделать — докупить мощностей если вам не перестали продавать. Это рабочее решение, но не все могут его себе позволить.

Если не докупать, то придется оптимизировать использование ресурсов. Здесь как раз пригодится ограничение виртуальных машин по производительности.

Нетребовательные или редко используемые сервисы можно перевезти на виртуалки с ограничением по CPU и памяти без ухудшения качества работы. Важным сервисам, в свою очередь, можно повысить приоритет, чтобы у них всегда было достаточное количество ресурсов.

И вот мы уже сэкономили на аренде новых серверов, более мудро распределив существующие ресурсы. При этом качество работы сервисов не снизилось, даже еще место освободилось. Win!

А провайдерам инфраструктуры это зачем?

Если обуться в ботиночки облачного провайдера (допустим, Selectel), появится еще несколько причин управлять производительностью виртуальных машин.

Более плотная утилизация ресурсов

Не секрет, что виртуальные машины создаются на специальных «железных» хостах облачного провайдера. В них много памяти и ядер. Иногда возникают ситуации, когда на хосте есть свободные ресурсы, но их столько, что адекватная конфигурация для еще одного виртуального сервера не помещается. То есть вроде бы и в железе есть ресурс, но ни одна конфигурация в него не лезет по параметрам (память, ядра).

В итоге эти «остатки» просто не используются.

Чтобы избежать такой ситуации, провайдеру приходится играть в тетрис (нет, правда). Перекладывать виртуальные машины с хоста на хост, чтобы более плотно упаковать их. Это очень затратный процесс.

Возможность создавать более дешевую инфраструктуру в облаке

Если будет возможность управлять производительностью виртуальных машин, то можно будет оптимизировать стоимость виртуалок. Так, например, в линейке Shared Line можно арендовать 10% мощности сервера с 1 CPU, 512 МБ RAM и сетевым диском на 5 ГБ за 193,60 ₽/мес. При правильных подсчетах можно сэкономить на запуск еще одного проекта.

Итак, зачем это все, мы немного определились. Теперь рассмотрим, какие существуют инструменты и способы ограничения виртуальных машин по использованию ресурсов.

Способы ограничения ВМ по использованию CPU

Сразу оговоримся, что речь в основном пойдет о способах управления производительностью в ОС Linux. Почему так? В лучших традициях ответим мемом:

При разработке линейки Shared Line у нас не было готового ответа, какой именно инструмент использовать. Перед реализацией проводили исследование существующих способов. По понятным причинам в основном искали опенсорсные решения.

В самом начале поисков стало понятно: мы не первые, у кого возникла подобная задача. Сходу нашлось несколько способов ограничения виртуальных машин по используемым ядрам.

Перечислю инструменты в порядке их обнаружения.

CPUTool

Эту утилиту поисковик выдал первой. Очень простой инструмент, который позволяет установить ограничение сверху на потребление CPU для любого процесса по его Process ID. Также утилита умеет устанавливать ограничение при достижении заданного load-average.

Принцип работы

В официальном мануале есть немного информации о принципе работы и примерах использования.

Утилита распределяет процессорное время через механизм таймслайсов. Длительность таймслайса составляет 100 мс. Каждому процессу/группе процессов под управлением CPUTool дается возможность работать только в течение какой-то части таймслайса. Рабочая доля времени внутри него определяется переданным значением аргумента —cpu-limit.

В рамках одного таймслайса CPUTool отправляет процессу сигналы SIGSTOP и SIGCONT. Первый останавливает процесс, а второй — возобновляет.

Плюсы

• Простой и понятный инструмент.
• Может ограничивать потребление процессорного времени.
• Умеет учитывать загрузку системы и останавливать процесс, если нагрузка в системе больше заданного значения.

Минусы

• К каждому процессу добавляется еще и контролирующий процесс cputool. Сам процесс cputool может упасть, и никаких ограничений не останется.
• Постоянно шлет сигналы SIGCONT и SIGSTOP. Обработка большого количества сигналов может сильно нагрузить систему.
• SIGCONT может быть обработан приложением, из-за чего эта утилита подойдет не каждому приложению. Обычно заранее неизвестно, перехватывает ли приложение какие-то сигналы и как их обрабатывает. При использовании CPUTool придется помнить эту особенность.

Вывод

Утилита CPUTool отлично подойдет, когда нужно запустить пару приложений, которые не должны мешать друг другу. Контролировать виртуальные машины с помощью такого инструмента можно, но, какой будет эффект, неясно.

Этот вариант мы отбросили из-за минусов с большим количеством сигналов и необходимостью запускать процесс cputool и следить за ним.

cgroups

Второй находкой был механизм контрольных групп в ядре Linux.

Принцип работы

Механизм cgroups предоставляет возможность объединять процессы в группы. Группами можно управлять, и мониторить потребляемые ресурсы.

Интерфейс контрольных групп представляет собой псевдофайловую систему cgroupfs. То есть настройку работы можно вести через запись значений в специальные файлы. Группировка процессов реализована в коде ядра, а отслеживание потребления и ограничение ресурсов предоставляются набором подсистем — memory, CPU и другими.

Более подробно про cgroups можно прочитать в официальной документации. Вообще возможности cgroups намного шире, чем просто управление потреблением CPU, но мы сконцентрируемся на решении нашей задачи.

Контрольные группы содержат несколько частей, которые вместе дают возможность квотировать CPU у процессов, — Freezer и CPU controller.

Freezer

Для остановки/возобновления работы процесса есть Freezer. Эта подсистема была введена, так как отправка сигналов SIGSTOP/SIGCONT — ненадежный способ остановки и возобновления процесса (пруф).

Проблема с этими сигналами в том, что они видны процессу, в который их отправляют. Более того, сигнал SIGCONT может быть перехвачен и кастомно обработан. Таким образом, остановка/возобновление может сломать приложение, которое перехватывает сигналы.

Подсистема Freezer, в свою очередь, использует внутренние механизмы ядра для остановки и возобновления процессов. Поэтому ее работа не видна процессу, на который он воздействует.

СPU controller

Для управления и мониторинга использования процессора в контрольных группах есть CPU controller. Он позволяет задавать параметры планировщика для группы процессов.

Как вариант, для ограничения процессов по потреблению CPU можно использовать два параметра — cpu.cfs_period_us и cpu.cfs_quota_us. Первый параметр задает период времени, после которого должно произойти перераспределение ресурсов — таймслайс. Второй параметр — cpu.cfs_quota_us — задает доступное для работы время в рамках этого периода. Все показатели времени задаются в микросекундах (на это намекает суффикс _us, но лучше уточнить).

Еще можно использовать параметр cpu.shares.

В этом файле для каждой группы процессов содержится ее вес, который определяет, какую долю процессорного времени может использовать группа. По умолчанию этот параметр равен 1024 единицам для каждой группы. Самое интересное, что реальный, действующий вес определяется исходя из суммы всех весов на текущем уровне иерархии (завернул нормально).

Более наглядно показать особенности работы cpu.shares можно с помощью такой иллюстрации:

Здесь такое поведение, что левой виртуальной машине будет доступно 2/3 ресурсов хоста, а правой — только 1/3. При этом доступный ресурс по CPU для правой виртуальной машины будет делиться поровну между каждым ее ядром.

Действующее значение cpu_shares ядер правой машины будет равно 512/4 = 128, или 8,3% от общего времени. Действующее значение cpu_shares ядра левой машины будет равно 1024, или 66% общего времени.

Поддержка в OpenStack Nova

Облако Selectel построено на базе OpenStack. Поэтому при поиске инструмента мы также оценивали затраты на внедрение в OpenStack.

Нам повезло, и в проекте OpenStack уже предусмотрели использование контрольных групп (дока, дока2). По ходу тестов мы выяснили, что в Nova указанное значение cpu.shares применяется на всю виртуальную машину (пруф). Ну выяснили и выяснили, в чем проблема-то? А проблему будет проще показать на примере.

Посмотрим внимательнее на кусок кода, в котором происходит установка значения cpu_shares для виртуальной машины. На строке 18 видно, что по умолчанию значение cpu_shares для виртуалки масштабируется в зависимости от количества ядер.

Однако далее, в цикле на 22 строке, выполняется проверка наличия кастомного значения cpu_shares в характеристиках ВМ. Если проверка проходит успешно, то есть мы указали свое значение для cpu_shares, указанное значение не масштабируется на количество ядер и устанавливается как есть (строка 23).

Подобное поведение не очень удобно для использования из коробки.

Мы смогли придумать пару вариантов обхода такого поведения:

1. Подправить код так, чтобы переданное значение cpu_shares тоже масштабировалось
2. Заранее учитывать количество ядер и сразу задавать правильное значение cpu_shares в конфигурации виртуальной машины

Второй же вариант ближе тем, кто любит говорить «Работает – не трогай». Можно же просто держать в голове эту особенность и не писать никакого кода. Просто напиши в конфигурацию нужный вес и все. Profit!

Плюсы

• Нативное решение для ОС Linux.
• Работает незаметно для процесса, которым управляет.
• Поддерживается в OpenStack из коробки.
• Не ограничивает виртуальную машину, если есть свободные ресурсы. Следовательно, виртуалка может работать без ограничений, если есть свободный ресурс.

Минусы

• Нужно учитывать иерархичность cpu.shares при использовании.
• Может показаться, что, установив веса для всех vCPU, мы добьемся успеха по ограничению потребления CPU виртуальной машиной. Однако такой трюк сработает не так, как ожидается. На самом деле сработает, только если указать корректное значение cpu_shares для всей виртуальной машины.
• В случае с OpenStack нужно проделать работу для масштабирования значения cpu_shares. Согласен, правка кода небольшая, но нужно будет хорошенько протестировать это решение.

Вывод

Очень классное решение, которое подойдет для управления большим числом процессов или виртуальных машин. Хорошо масштабируется и автоматизируется.

Ограничиваем «на коленке»

Есть еще более простое решение без использования дополнительного ПО.

Принцип работы

В самом простом варианте можно попробовать запустить больше виртуальных ядер, чем «железных» на хосте. Так, если на хосте шесть CPU, то, запустив шесть виртуальных машин с 2 vCPU, можно считать, что каждое vCPU будет иметь в распоряжении только 0,5 CPU.

В таком подходе отсутствует гибкость в виде установки разных ограничений разным виртуальным машинам. Но это лучше жесткого ограничения на потребление сверху, как в случае с —cpu-limit.

Этот способ хорошо масштабируется за счет добавления хостов. Виртуальные машины не будут ограничены в принципе и будут испытывать steal time, только когда всем резко потребуется процессорное время.

Плюсы

• Не требует дополнительной разработки.
• Простое в понимании.
• Точно так же, как с cgroups, у виртуалки будет возможность занимать больше процессорного времени, чем заявлено, если будет свободный ресурс.

Минусы

• Нужно следить, сколько виртуальных машин запущено на хосте и не превышать заданное соотношение CPU/vCPU. При нарушении соотношения мы рискуем получить виртуалки с меньшим гарантированным процентом, чем заявлено.
• Масштабируется только добавлением новых хостов. Так как виртуальные машины по сути ограничены только параметрами железа, на котором они запущены. Если виртуальную машину, ограниченную через cgroups, можно будет запустить где угодно, то в текущем решении только на специальных хостах.

Вывод

Такой способ организации процентных инстансов удобен тем, что очень прост в реализации и понимании. Несмотря на потерю гибкости в выборе гарантированной доли CPU, можно быстро проверить востребованность подобных виртуальных машин.

Какой путь выбрали мы и почему

Иииии… мы приняли решение использовать ограничение «на коленке».

Почему?

Потому что для начала нам нужно было проверить гипотезу ценности услуги — понять, нужны ли вообще кому-то дешевые серверы с частичной мощностью ядра.

В разработке облачной платформы Selectel мы всегда стараемся найти баланс между профитом и трудозатратами. То есть можно было бы угореть и сделать контрольные группы, наткнувшись по пути на парочку ограничений. Внести патч в OpenStack Nova либо заранее заложить в flavor нужное значение shares.

Но все это было бы нерационально без подтверждения востребованности процентные инстансов у клиентов. Мы сделаем и будем молодцами, а время, потраченное на разработку, не окупится.

Поэтому на данный момент процентные инстансы в Selectel – это виртуальные машины, запущенные на хостах с определенным соотношением CPU/vCPU.

Визуально это выглядит как на картинке:

К слову, благодаря такому решению у Shared Line есть ощутимый профит. В таком варианте нет явного ограничения сверху на потребление CPU. Виртуалка может потреблять хоть 100% CPU до тех пор, пока не возникнет борьба за ресурс. В случае, когда есть конкуренция за ресурсы, всем будет выдано одинаковое количество процессорного времени, но ни в коем случае не меньше выбранного процента производительности — он гарантирован.

Планы

В целом, видно, что интерес к более дешевым виртуальным машинам есть. Shared Line сейчас можно арендовать в Москве и Санкт-Петербурге.

Кстати, если у вас есть мысли, почему вам такой сервер не подойдет, пишите в комментариях!

В дальнейшем, конечно же, мы хотим заехать на использование контрольных групп. Да, в OpenStack можно задать cpu.shares и cpu.cfs_period_us с cpu.cfs_quota_us из коробки. Но для грамотного использования нужно либо патчить OpenStack Nova, либо иначе адаптировать решение.

Переход на контрольные группы чуть облегчит архитектуру решения. Так, например, сейчас под Shared Line у нас выделены отдельные хосты. Рабочая схема, но при ней мы даем гибкость клиентам и отчасти лишаем гибкости себя.

Контрольные группы дадут следующие преимущества:

• можно будет помещать процентные виртуальные машины на любой хост, рядом с любыми другими,
• не нужно будет выделять отдельные хосты под линейку,
• откроется путь к более гибким конфигурациям — например, к 83% ядра (ну а вдруг именно столько вам нужно).

Ограничение количества vCPU для ВМ

Для оптимизации производительности виртуальных машин (ВМ) и минимизации задержек при вычислениях, необходимо учитывать количество создаваемых vCPU и не выходить за лимиты, указанные в статье: Ограничения для параметров виртуальных машин.

Пример сопоставления CPU и NUMA-узла

В CPU применяется логическая структура — NUMA -узел. Часто NUMA-узел назначается в соотношении 1:1 к физическому процессору. Если на сервере имеются два процессора по 28 ядер и 1,5 ТБ памяти, то один физический NUMA-узел будет иметь 28 ядер и 768 ГБ RAM.

Определение количества vCPU для ВМ

Что необходимо учесть при определении количества vCPU для ВМ:

Гипервизор VMware, Inc. применяет виртуальные NUMA-узлы, которые назначает к физическим сокетам (процессорам).

Используются два основных типа ВМ , в которых:

• количество vCPU /RAM не превышает количество vCPU в NUMA-узле;
• количество vCPU и/или RAM превышает количество vCPU /RAM в NUMA-узле.

ВМ размещается в рамках одного физического NUMA-узла и получает максимум производительности.

ВМ , в которых количество vCPU и/или RAM превышает количество vCPU /RAM в NUMA-узле.

VMware vSphere Server, начиная с версии 6.5, умеет выравнивать ресурсы ВМ по физическим NUMA-узлам, чтобы минимизировать интерконнект. Взаимодействие процессора и памяти осуществляется таким образом, что каждый процессор обращается только к памяти, которая взаимодействует непосредственно с ним. В этом случае задержки на вычисления возникают только при обращении через IO-шину.

В решении размеры RAM и L3 Cache не предопределены. Поэтому при создании ВМ с vCPU (pSocket CPUs) необходимо указать параметр «cores/socket» так, чтобы виртуальные сокеты ВМ равнялись количеству физических сокетов (обычно 2). В этом случае vNUMA-узлы обращаются к своей памяти и к своему L3-cache, что важно для приложений критичных к задержкам (latencу). Для этого необходимо вручную править данный параметр и знать на каких процессорах будут размещены ВМ.

Рекомендуется не использовать опцию горячего добавления vCPU . При включении опции горячего добавления vCPU отключается механизм автоматического распределения ВМ по NUMA-узлам. В этом случае необходимо ручное выравнивание ресурсов ВМ по физическим NUMA-узлам, иначе производительность ВМ может быть существенно снижена.

VMware, Inc. выработали правила размещения ВМ:

1. While there are many advanced vNUMA settings, only in rare cases do they need to be changed from the defaults.
2. Always configure the virtual machine vCPU count to be reflected as Cores per Socket, until you exceed the physical core count of a single physical NUMA node OR until you exceed the total memory available on a single physical NUMA node.
3. When you need to configure more vCPUs than there are physical cores in the NUMA node, OR if you assign more memory than a NUMA node contains, evenly divide the vCPU count across the minimum number of NUMA nodes.
4. Don’t assign an odd number of vCPUs when the size of your virtual machine, measured by vCPU count or configured memory, exceeds a physical NUMA node.
5. Don’t turn on vCPU Hot Add unless you’re okay with vNUMA being turned off.
6. Don’t create a VM larger than the total number of physical cores of your host.

Эти правила можно считать официальной рекомендацией VMware, Inc., так как на них ссылаются Performance Best Practices for VMware.

Возможен еще один тип ВМ , в котором количество vCPU больше, чем количество CPUs на хосте. Это нежелательный сценарий, так как такая ВМ разбалансирована. Но иногда подобный сценарий применяется, когда приложения используют в ВМ не сами CPU, а L3-cache этих CPU.

Источники

• Virtual Machine vCPU and vNUMA Rightsizing – Guidelines
• Setting corespersocket can affect guest OS topologies (81383)
• Performance Best Practices for VMware vSphere 7.0
• NUMA / vNUMA / Should we consider “Cores per socket” VM configuration in vSphere?
• Using Virtual NUMA
• Decoupling of Cores per Socket from Virtual NUMA Topology in vSphere 6.5
• vSphere 7 Cores per Socket and Virtual NUMA

Как изменить vCPU speed?

vCPU speed (скорость виртуального процессора) – это параметр, который определяет частоту ядра для всех серверов вашего виртуального ЦОДа. Вы не можете самостоятельно изменить его. Если по каким-то причинам Вам необходимо изменить это значение, пожалуйста обратитесь к менеджеру, который оформлял Ваш заказ.

Обращаем Ваше внимание на то, что для изменения vCPU speed все серверы вашего ЦОДа потребуется выключить.

Содержимое

• Виртуальный выделенный сервер (VPS)
• Облачный ЦОД
• Облачный сервер
• Резервный ЦОД
• Облачный офис
• Сети
• Резервное копирование и репликация (BaaS)
• Безопасность
• Kubernetes
• ФЗ-152
• Размещение оборудования в ЦОД