8 vcpus что это

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

date

10.02.2020

user

itpro

Виртуальная машина 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 - количесвто ядер на процессор в виртуальной машине

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

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

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

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

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

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

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

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

Например, для 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.

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

Гипервизор: что это такое, роль в виртуализации, типы и сравнение

Гипервизор — технология развертывания программного обеспечения на физическом оборудовании с использованием виртуализации. Инструмент ускоряет и упрощает разработку, тестирование и поддержку программного обеспечения, а также экономит ресурсы на развертывании дорогостоящих серверных систем. Selectel предлагает современные технологии виртуализации серверов (VPS/VDS), а также рабочих мест (VDI). Мы используем аппаратные ресурсы на базе процессоров Intel® Xeon®, а также SSD-накопителей, […]

Изображение записи

Гипервизор — технология развертывания программного обеспечения на физическом оборудовании с использованием виртуализации.

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

Selectel предлагает современные технологии виртуализации серверов (VPS/VDS), а также рабочих мест (VDI). Мы используем аппаратные ресурсы на базе процессоров Intel® Xeon®, а также SSD-накопителей, обеспечивая минимальное время отклика, высокую производительность и надежность. Для серверной виртуализации применяются решения VMware и KVM.

Основные задачи гипервизора:

эмуляция аппаратных ресурсов;
безопасное выполнение машинных инструкций;
предотвращение выполнения команд гостевых операционных систем в режиме супервизора на хост-машине (исключение перехвата и анализа команд).

История гипервизоров

Технологии виртуализации начали активно использоваться разработчиками с конца 60-х годов прошлого века. Мейнфреймы IBM первыми стали поддерживать виртуализацию и предоставлять разработчикам гипервизоры в составе встроенного ПО. Первоначально команды разработки применяли их для эмуляции системных процессов компьютера, тестирования различных операционных систем и улучшений для них.

Повышение интереса IT-сообщества к гипервизорам приходится на середину нулевых. В этот период технологии виртуализации начинают активно использоваться в UNIX-подобных системах. В первую очередь, это было обусловлено ростом производительности серверного оборудования. Также значительную роль сыграла оптимизация архитектуры самих гипервизоров, сделавшая их более надежными и безопасными.

Помимо этого, виртуализация позволяла разворачивать и запускать требующие наличия ОС приложения в различных программных или функциональных средах. А в 2005 году технологии виртуализации начинают поддерживаться на аппаратном уровне в процессорах архитектуры x86, что позволяет использовать их как в серверных, так и в домашних системах.

Проблемы безопасности гипервизоров

В IT-сообществе ведутся дискуссии на тему безопасности виртуализации. Основная проблема — это возможность создания злоумышленниками вредоносного ПО, устанавливаемого на ОС под видом гипервизоров. Этот процесс получил название «гиперджекинг». Его сложно отследить, поскольку вредоносные алгоритмы работают под управлением ОС и перехватывают ее действия (например, авторизацию, запросы к сервисам и пр.).

В настоящее время разрабатываются различные подходы по обнаружению руткитов на базе гипервизоров:

концепция вредоносного ПО: SubVirt, Blue Pill;
антируткиты: Hooksafe (защита ОС без потерь производительности).

Контейнеры или гипервизоры

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

Гипервизор виртуализирует необходимые для работы ОС аппаратные ресурсы. При использовании гипервизоров возрастает потребность в наращивании аппаратных мощностей (дисковых устройств, CPU, памяти и пр.).

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

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

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

Также стоит обратить внимание и на Jailhouse. Решение компании Siemens работает на «железе», при этом запускается из-под работающей ОС Linux. При работе контейнер создает в ОС изолированные разделы для выполнения пользовательских приложений.

Типы гипервизоров

Существует два основных вида гипервизоров. Гипервизоры первого типа (сюда входят решения Hyper-V, KVM, ESXi) работают на аппаратном уровне без необходимости установки какой-либо ОС на хост. Поэтому их еще называют аппаратными. Гипервизорам второго типа (VMware Workstation, Oracle Virtual Box, OpenVZ) необходима ОС для доступа монитора виртуальных машин к аппаратным ресурсам хоста.

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

Сравнение гипервизоров

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

Hyper-V: для серверного оборудования под управлением Windows Server есть базовая роль Hyper-V. Кроме того, на рынке есть специальное решение Hyper-V Server. Операционная система Windows Server может поставляться в двух редакциях — Datacenter и Standard. Стандартная версия на одной лицензионной копии позволяет развернуть только две виртуальные машины. В версии Datacenter их число не ограничивается.

В соответствие, с актуальной лицензионной политикой Microsoft, действующей с 2016 года, стоимость лицензии на ПО зависит от количества физических ядер. Если речь идет о виртуализации Linux-машин на серверах под Windows Server, то их количество в стандартной редакции не ограничено. Если же требуется виртуализация Windows-машин, то необходимо решить вопрос с лицензированием ОС на них.

Специально для такой аудитории и был создан Hyper-V. Он позволяет организовать виртуализацию, не платя за лицензию на ОС. Решение доступно бесплатно, при этом и нет каких-либо ограничений на процедуры. Тем не менее, функционал продукта имеет и свои особенности:

настройка и отладка через удаленную консоль: графический интерфейс не предусмотрен;
лицензирование: необходимо лицензировать все виртуальные машины под управлением Windows;
отсутствие поддержки: Microsoft не предоставляет техническую поддержку, но при этом регулярно обновляет продукт.

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

VMware ESXi: в основе решения находится облегченное Linux-ядро VMkernel, содержащее необходимые для виртуализации технологии и приложения. Поставляется внутри продукта VMware vSphere. Лицензия покупается на каждый физический CPU сервера. Объем ОЗУ и виртуальных машин не учитываются при расчете стоимости лицензии.

VMware также предлагает и бесплатные решения для виртуализации, однако, они подходят только для любительского или полупрофессионального использования, поскольку имеют ряд существенных ограничений по функционалу. Так, например, бесплатная версия этого гипервизора 1 типа предоставляет API только для чтения данных. У виртуальной машины не может быть больше 8 vCPU, не предусмотрена работа с бэкапами с помощью продуктов Veeam и другие технологии, необходимые для корпоративного сегмента.

Основной недостаток Hyper-V по сравнению с VMware — это отсутствие USB Redirection. Она необходима для подключения USB оборудования к виртуальным машинам. Вместо нее в Hyper-V предлагается Discrete Device Assignment. Однако, Hyper-V может уменьшать дисковое пространство виртуальных машин, а не только расширять его, как VMware.

Hyper-V позволяет защищать виртуальные машины шифрованием. Однако, если требуется аппаратный проброс портов, то лучшим решением будет VMware, даже бесплатный.

При выборе гипервизора особое внимание следует уделить инструментам управления виртуальными машинами. У Hyper-V это Virtual Machine Manager (VMM), поддерживающий создание, клонирование, развертывание и другие операции с виртуальными машинами.

Инструмент управления от VMware называется vSphere. Он предполагает наличие ESXi хостов и vCenter Server для централизованного управления.

KVM — open-source гипервизор: предназначен для серверов на базе Linux/x86, поддерживает аппаратные расширения (Intel-VT и AMD-V).

Первоначально работал только с архитектурой x86, но актуальные версии KVM поддерживают различные CPU и гостевые ОС, в т.ч. Windows, Linux, BSD и пр.

Богатый функционал KVM сделал его популярным и широко распространенным. В настоящее время гипервизор активно используется во многих сетевых проектах (Wiki-ресурсы, финансовые сервисы, транспортные системы, государственный сектор и пр.).

Решение считается быстрым и за счет интеграции в ядро Linux.

Управление виртуальными машинами: встроенные сервисы не соответствуют по функционалу решениям для других гипервизоров. Чтобы расширить функционал, приходится использовать сторонние инструменты, например, панель SolusVM.
Стабильность и отказоустойчивость: этот недостаток проявляется при интенсивном вводе-выводе. Тем не менее KVM развивается и дорабатывается множеством независимых разработчиков, что положительным образом сказывается на работе гипервизора.

Xen (XenServer, Citrix Hypervisor): первый публичный релиз тонкого гипервизора был выпущен в 2003 году. В 2007 году проект был поглощен Citrix. Продукт является кроссплатформенным гипервизором с поддержкой аппаратной виртуализации и паравиртуализации (из-за этого его часто относят к гибридным гипервизорам). Объем кода минимален, т.к. большая часть модулей вынесена за пределы гипервизора. Исходный код открыт, что дает специалистам неограниченные возможности для модификаций продукта.

Oracle VM VirtualBox: кроссплатформенный модульный гипервизор для операционных систем Linux, macOS, FreeBSD и др. Создан в корпорации Sun Microsystems в 2007 году. После поглощения разработчика Oracle проект продолжил развитие под другим брендом. Исходный код базовой версии открыт и распространяется по лицензии GNU GPL, что послужило причиной высокой популярности гипервизора. Отличительная особенность гипервизора — возможность работы с 64-битными гостевыми ОС, даже если ОС хоста 32-битная.

VMware Workstation: первая версия гипервизора вышла в 1999 году. Решение является проприетарным для x86-64 ОС хоста Windows, Linux, Ubuntu, CentOS. Поддерживает более 200 гостевых операционных систем. Для ознакомления и тестирования предоставляется бесплатная версия с ограничениями по функциональности.

Гибридные гипервизоры: для улучшения стабильности, безопасности и производительности описанные выше подходы к виртуализации (непосредственная работа «на железе» и использование основной ОС хоста) комбинируются. В результате на рынке появляются гибридные решения. В последние годы в IT-сообществе к гибридным гипервизорам причисляют Xen и Hyper-V, поскольку их актуальные версии сочетают в себе оба подхода. Таким образом, просматривается тенденция к размытию границ между видами гипервизоров.

Отличия ядер Standard и Nova

для сервисов с невысокой нагрузкой и небольших сайтов.
Гарантированная производительность ядер — не менее 30%.

1 vCPU Nova
для высоконагруженных сервисов и приложений проектов.
Гарантированная производительность ядер — 100%

Ядра Standard

Гарантированная производительность виртуальных ядер Standard — от 30%. Это связано с тем, что 1 поток ядра процессора обслуживает несколько виртуальных серверов с ядрами Standard. Если на одном из них повысится нагрузка, производительность остальных снизится. Это не частый случай — обычно виртуальные серверы не загружены до пиковых значений. Большую часть времени сервер с ядрами Standard будет работать с полной производительностью. Однако рекомендуем использовать его для некритичных сервисом: небольших сайтов, почтовых серверов и другого нетребовательного ПО.

Ядра Nova

vCPU Nova — это виртуальные ядра со 100% производительностью — 1 vCPU равен 1 потоку физического ядра. Выбирайте ядра Nova при создании сервера для критических и высоконагруженных проектов: базы данных, 1с, тяжелое вычислительное ПО.

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

Вопрос по гарантированным ресурсам 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