8 vcpus что это
Перейти к содержимому

8 vcpus что это

  • автор:

Каждому по потребностям: как мы решали задачу с «нарезкой» 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% ядра (ну а вдруг именно столько вам нужно).

Вопрос по гарантированным ресурсам VPS (KVM без оверселлинга)

WapGraf:
Мне вот что интересно, как вы из vCPU (виртуального ядра) смогли получить выделенное ядро?
Вам продать 1000 «выделенных» виртуальных ядер на ноде с E3-1230?

Виртуальное выделенным быть не может априори!

What are the dedicated vCPU server plans?
Every dedicated vCPU instance has its own dedicated CPU resources (1 vCPU = 1 hyper-thread), so these CCX servers offer you predictably high CPU performance. We recommend them for systems with high production loads and CPU intensive applications. They are only available with local (NVMe SSD) storage. They utilize the same high performance hardware as our other Hetzner cloud servers, with a generous allocation of I/O and network power.

Маркетинг, такой маркетинг. dedicated vCPU в Hetzner это тоже самое что vCPU у любого другого провайдера. Боюсь представить их будущий оверселл по не dedicated vCPU

Выбираем IaaS: что такое vCPU, и сколько ядер вам нужно

От виртуальных процессоров во многом зависит производительность облачной инфраструктуры. Что такое vCPU, как рассчитать количество процессоров под конкретный проект, и в чем отличие от физических CPUs — рассказал Сергей Афанасьев, тимлид команды Compute в Selectel.

Что такое vCPU и какова его производительность

vCPU — это виртуальный процессор, который «отрезает» гипервизор от физического CPU при создании виртуальных машин (ВМ). vCPU содержит минимум одно ядро.

От количества ядер виртуального процессора зависит количество потоков, которыми может оперировать приложение, а следовательно — его возможности.

Гипервизор наряду с другими ресурсами может нарезать vCPU и отдавать его виртуальным машинам. Основная задача — правильно распределить время физических CPU между vCPU.

Чтобы собралась полная картина, сейчас необходимо ввести еще пару терминов.

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

Еще важно знать про потоки обработки. Этим термином называют выделенную область внутри физического ядра процессора. Ресурсы ядра разделяются по потокам. Это позволяет обрабатывать параллельно несколько последовательностей команд.

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

Сам факт такого деления возможен, потому что даже самые интенсивные задачи не используют 100% ЦП все время. По этой причине vCPU иногда рассматривают не как отдельный процессор, а как часть времени, проведенного в ядре процессора.

Сколько vCPU выбрать в зависимости от проекта

Оценить производительность vCPU можно на примере параметра CPU Usage. Он как раз показывает процент использования CPU за заданный период времени. Если ядра виртуальной машины стабильно нагружаются до 80% и выше, то такие показатели говорят о том, что она близка или находится на пике своей нагрузки. В таком случае можно посоветовать увеличить количество vCPU или же мигрировать ВМ на сервер с более производительными процессорами. Второй путь сложнее, поскольку не каждый провайдер может предоставить подходящую конфигурацию.

Важно понимать, что ядра виртуальной машины не должны нагружаться до своего пика, всегда должен быть запас (в 40-50%). В противном случае виртуальная машина может не справиться с поступающей на нее нагрузкой, которая может внезапно резко возрасти.

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

Например, в случае с интернет-магазином нагрузка прямо пропорциональна количеству активных пользователей: чем их больше, тем выше нагрузка. Вряд ли на старте в один момент у него окажется 10000 пользователей, которые обеспечат высокую нагрузку. Поэтому вкладываться заранее в ресурсы неэффективно. Масштабироваться следует постепенно, в зависимости от фактической нагрузки на сайт или приложение. Важно, чтобы со стороны провайдера этот процесс был выстроен максимально комфортно: панель управления интуитивно понятна, поддержка работает 24/7.

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

Стоит также обратить внимание на параметр CPU Steal Time. Он показывает время, в течение которого виртуальная машина должна была получать ресурсы от хостовой ОС, но что-то пошло не так, и по итогу они не были получены. А значит и вычисления ВМ также не были выполнены. Нормой для этого параметра считаются значения не более 5-10%.

Причин возникновения steal может быть несколько: одна из них — высокая загруженность хоста виртуализации. Это может быть спровоцировано системными задачами хоста или же большим количеством других виртуальных машин, которые тоже его нагружают. В таком случае увеличение количества vCPU никак не поможет в решении этой проблемы, от этого ВМ никак не станет производительнее.

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

Можно ли управлять количеством и производительностью vCPU в виртуальной машине

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

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

С облачными серверами Shared Line ситуация намного проще. В этой линейке можно выбрать любую производительность ядра: 10%, 20% или 50% в зависимости от задач и не платить за остальное. Если остальные ресурсы ядра доступны, то производительность увеличивается вплоть до 100% без каких-либо доплат. Этого вполне хватает для поддержки dev-сред, хостинга простых сайтов, чат-ботов/Telegram-ботов или квизов.

Если оставшуюся часть сервера никто в этот момент не использует — производительность может доходить до 100%.

Главное, что следует учитывать при распределении vCPU — историю наблюдений и фактор сезонности, а также маркетинговые активности (например, можно зарезервировать ресурсы перед началом распродажи).

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

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

date

10.02.2020

user

itpro

directory

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

comments

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

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

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

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

Виртуальные процессоры QEMU Virtual CPU version 2 в оборудовании виртуальной машины.

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

Windows не видит все выделенные виртуальные процессоры

То есть сколько бы вы не добавили виртуальных ядер, 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 проверьте, что ОС видит все выделенные виртуальные ядра.

несколько виртуальных ядер в Windows 10

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

виртуальная машина KVM с гостевой Windows 10 видит два физических процессор с несколькими ядрами

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

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

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

vmware - количесвто ядер на процессор в виртуальной машине

  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)

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

vCPU и процессорная архитектура NUMA

Например, для 2 процессорного хоста с 10 ядрами (суммарно доступно 40 vCPU с учетом HyperThreading), при настройке 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.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *