Настройка виртуальной машины vmware cores per socket
Вторая часть моего осмысления гайда от VMware рассказывает о моментах, связанных с центральным процессором. Затрагиваются такие важные темы как Hyper-Threading, NUMA и Power Management.
ESXi General Considerations
Основные моменты, касающиеся гипервизоров:
- При планировании ресурсов на гипервизоре, необходимо так же учитывать нужды самого ESXi;
- Выделять виртуальным машинам столько ресурсов, сколько они требуют. Выделение большего, чем требуется, количества ресурсов иногда может снизить производительность машины, нежели увеличить. Так же это может сказаться на машинах, которые располагаются на том же хосте;
- Отключить неиспользуемое физическое оборудование. Сетевые порты, USB контроллеры, CD/DVD и т.п. Подобное оборудование может потреблять ресурсы CPU, некоторые PCI устройства могут потреблять так же ОЗУ;
- Неиспользуемое виртуальное оборудование в VM стоит так же отключить. Это может влиять на производительность;
- Рекомендуется использовать версию виртуального оборудования vHardware, которая поддерживается всеми хостами в кластере. Например, машина с версией оборудования 17 сможет запускаться только на хостах с vSphere 7.0.
ESXi CPU Considerations
Виртуализация CPU добавляет некоторые накладные расходы, в большинстве своем незначительные.
Производительность большинства систем будет сравнима с работой системы на «голом железе». Для малого процента рабочих нагрузок, сильно зависящих непосредственно от CPU, может быть замечена деградация в производительности.
В большинстве случаев ESXi позволяет осуществить переподписку – выполнение большего количества виртуальных процессоров, чем есть в наличии физических. Однако, в случае, если нагрузка на процессор будет существенной, некоторые «чувствительные» приложения могут работать хуже. В этом случае стоит снизить нагрузку на CPU, выключив некоторые виртуальные машины, либо мигрировать их на другой доступный и свободный хост.
Хорошая практика – периодически наблюдать за загрузкой CPU:
- В случае, если load average в esxtop больше 1 – система нагружена;
- В целом, загрузка процессора на хосте в районе 80% является разумным пределом. Загрузка CPU на 90% соответствует серьезной перегрузке.
Не стоит выделять виртуальной машине больше процессорных ресурсов, чем ей требуется. Это увеличивает накладные расходы и потенциально может негативно сказаться на производительности высоконагруженных систем.
Самый простой пример – однопотоковое приложение, работающее на многопроцессорной системе.
Даже если гостевая ОС не использует все доступные ей процессоры, некоторые процессорные инструкции выполняются даже на незадействованных ядрах, создавая нагрузку на хост.
Hyper-Threading
Hyper-Threading, который так же называют SMT (simultaneous multithreading) позволяет представлять процессорное ядро, как два логических процессора, позволяющих запускать два независимых потока на одном физическом ядре одновременно.
Количество процессорных ядер в консоли vSphere будет удвоено. CPU 0 и 1 будут относиться к первому физическому ядру, 2 и 3 ко второму и так далее.
Hyper-Threading не удваивает производительность, но добавляет ее небольшой, а иногда и ощутимый прирост.
Включить использование HT можно в настройках BIOS (он должен поддерживать данную технологию). Обычно, включен по-умолчанию.
При использовании CPU Affinity (привязка vCPU виртуальной машины к ядрам процессора), не стоит привязывать машину\машины к двум логическим ядрам одного физического ядра. Например, привязать машину к ядрам 0 и 1, которые в итоге будут являться одним физическим ядром. Это может негативно сказаться на производительности.
NUMA, или же Non-Uniform Memory Access — «неравномерный доступ к памяти», одна из первых вещей, которую стоит учитывать при определении ресурсов виртуальной машины.
Скорость доступа к «своей» памяти выше, чем к памяти «удаленной», поэтому в NUMA-системах стоит учитывать этот момент для минимизации доступа к удаленной памяти без необходимости.
Обычно, при правильной расстановке памяти в двухпроцессорных системах, половина памяти является для одного процессора локальной, а вторая – удаленной.
NUMA нода (не всегда, но в большинстве случаев) – один физический процессор и его локальная оперативная память.
Более подробно я бы рекомендовал прочесть про NUMA в книге Host Resources Deep Dive.
Как уже было сказано в прошлой части, за работу NUMA в BIOS отвечает параметр Node Interleaving. Значение Disabled для данного параметра включает NUMA, соответственно ESXi начинает определять локальную и удаленную память для каждого процессора. Если параметр включен, система работает в режиме UMA, разделения на локальную и удаленную память не производится.
Виртуальные машины могут быть поделены на две категории:
- Виртуальная машина, количество vCPU которой равно, либо меньше, количества физических ядер одной NUMA ноды;
- Виртуальная машина, количество vCPU которой больше, чем есть в одной NUMA ноде. Такие машины называются Wide VM.
У машин первой категории (которые вписываются в размер NUMA ноды), производительность может быть выше, чем у машин второй категории за счет более быстрой скорости доступа к оперативной памяти.
Однако, у машин, которым важна пропускная способность ОЗУ, производительность, при нахождении в нескольких NUMA нодах, может быть выше. Для этого можно использовать параметр maxPerMachineNode, который определяет количество vCPU, при достижении которого будет включаться технологии vNUMA (об этом будет далее).
При использовании Hyper-Threading, виртуальная машина с количеством vCPU большим, чем количество физических ядер в процессоре, но меньшим, чем количество логических процессоров в одной NUMA ноде (количество физических ядер * 2), может получить преимущества NUMA, при включенном флаге numa.vcpu.preferHT в конфигурационном файле VM. В таком случае, виртуальная машина будет исполняться (по крайней мере стараться) в рамках одного физического процессора, за счет логических ядер HT.
Например, у нас имеется сервер с двумя процессорами по 4 ядра. Соответственно, при включении HT у нас будет доступно 8 логических ядер на каждом из CPU. При использовании параметра preferHT, и количестве vCPU 6, машина будет выполняться на одном процессоре, а не на двух, попадая при этом в рамки NUMA узла. Стоит понимать, что при этом машина не получит производительность полноценных 6 ядер.
Добавлю от себя, что в большинстве случаев нужно стараться не выходить за рамки NUMA узла (как по количество vCPU, так и по количеству оперативной памяти), чтобы получить наилучшую производительность для виртуальной машины.
Snoop Mode Selection
Snooping – механизм, с помощью которого процессор проверяет локальный кэш и кэш удаленного процессора на наличие необходимых ему данных в одном из этих кэшэй.
Существует 5 методов:
- Early Snoop (ES);
- Home Snoop (HS);
- Home snoop with Directory and Opportunistic Snoop Broadcast (HS with DIS + OSB);
- Cluster-on-Die (COD);
- Sub-NUMA cluster (SNC).
Cluster-on-Die позволяет логически разбить процессор на несколько NUMA узлов, каждый из которых состоит из нескольких ядер данного CPU.
Sub-NUMA cluster похож на COD, с отличиями в использовании LLC (last level cache, кэш 3-го уровня).
AMD EPYC Processor NUMA Settings
Настоятельно рекомендую ознакомиться с архитектурой процессоров AMD EPYC.
Во втором поколении процессоров AMD EPYC появились некоторые и обновленные настройки BIOS:
- NUMANodesperSocket(NPS) – позволяет презентовать двухсокентную систему как одну NUMA ноду (NPS0), презентовать каждый CPU как NUMA ноду (NPS1), представлять каждый CPU как две NUMA ноды (NPS2), а так же как четыре ноды (NPS4);
- CCX(CoreCacheComplex)asNUMADomain – Если включен, представлять каждый CCX как NUMA домен, если выключен, представлять весь CPU как NPS.
Persistent Memory (PMem) in NUMA Systems
Про PMem уже говорилось в первой части. Несмотря на то, что каждый DIMM слот, в который подключена планка PMem является локальным к своему NUMA узлу, ESXi не ассоциирует PMem с NUMA нодой автоматически. Это необходимо сделать вручную.
Host Power Management in ESXi
ESXi поддерживает следующие политики для Power Management:
- High performance – не использует никакие технологии энергосбережения. Обеспечивает максимальную производительность для систем, при полной утилизации процессорных ресурсов;
- Balanced – политика по умолчанию. Уменьшает потребление энергии процессором с минимальным, либо вообще отсутствующим влиянием на производительность;
- Low power – Большее сохранение электроэнергии, но и большее влияние на производительность;
- Custom – Настраиваемая политика.
Используемая по умолчанию политика Balanced в большинстве случаев не оказывает влияния на производительность высокоинтенсивных приложений и систем. Но, как уже говорилось ранее, она может оказать влияние на работоспособность чувствительных к задержкам приложений. В данном случае рекомендуется использовать политику «High Performance», обеспечивающую максимальную производительность без включения техник энергосбережения.
На этом вторая часть подходит к концу. В следующей части обратим внимание на использование оперативной памяти, переподписку, использование файла подкачки и многое другое.
При создании виртуальных машин на различных гипервизорах (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, все назначенные виртуальные ядра считаются отдельными процессорами.
Выключите виртуальную машину:
Особенности управления ВМ в KVM из консоли сервера с помощью virsh.Выведите текущую XML конфигурацию виртуальной машины KVM:
Нам интересен блок с описанием процессоров:
Как видим, у нас указано просто 8 vCPU. Изменим конфигурацию:
И после </features> добавим:
Также в свойства системы теперь стал отображаться физический процессор хоста Intel(R) Xeon(R) Silver 4114 CPU, а не виртуальный.
Так нам удалось решить проблему с нагрузкой на ВМ, так как двух ядер не хватало для полноценной работы приложений.
Настройка виртуальных процессоров и количества ядер в VMWare
Вы можете изменить способ презентации vCPU для виртуальной машины VMWare из интерфейса vSphere Client.
- Выключите ВМ и откройте ее настройки;
- Разверните секцию 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 | Количество виртуальных сокетов в настройках ВМ | Количество ядер на виртуальном процессоре в настройках ВМ |
| 1 | 1 | 1 |
| …… | ||
| 10 | 1 | 10 |
| 11 | Не оптимально | |
| 12 | 2 | 6 |
| …… | ||
| 20 | 2 | 10 |
Например, ВМ с Microsoft SQL Server 2016 Enterprise Edition 16 vCPU в конфигурации 8 сокетов по 2 ядра будет работать хуже, чем в конфигурации 2 сокета по 8 ядер.
Также не забывайте, что некоторые приложения лицензируются по физическим сокетам (так было в старых версиях SQL Server). Иногда вам просто выгоднее лицензировать один многоядерный процессор, чем несколько процессоров с меньшим количеством ядер.
Предварительное планирование
Среди подготовительных мер, которые мы рекомендуем выполнить, особое внимание следует уделить сайзингу — размеру будущей инфраструктуры. В облачной инфраструктуре не всегда работает правило «больше, значит лучше», ресурсы необходимо выделять, проанализировав данные мониторинга. Полученные сведения позволят определить объем ресурсов, которые потребуются для будущих виртуальных машин в облаке провайдера.
Перенос приложений из локальной инфраструктуры в облачную требует обязательного контроля корректности работы программного обеспечения. Работа приложения внутри виртуальной машины может отличатся от локальной, прежде чем его запускать его в «продакшен» необходимо выполнить тестирование. Следующая методика позволит оценить корректность работы:
- Необходимо запустить ВМ на одном из серверов ESXi и зарезервировать на нем ресурсы процессора и памяти.
- Провести тестирование производительности и стабильности работы приложения.
- Результаты теста занести в baseline. Результаты должны содержать информацию о работе приложения на архитектуре виртуальной среды в отсутствии рабочей нагрузки на хосте.
- После сбора статистики хост нагружается — на нем запускаются дополнительные виртуальные машины, за каждой из которых также закреплены выделенные ресурсы процессора и памяти.
- Запускается новый тест производительности, а результаты сравниваются с записями в baseline.
- Анализируя полученные данные важно понять, остается ли производительность ВМ на уровне, достаточном для функционирования сервисов. Если это так, то можно добавлять еще нагрузки, отслеживать распределение ресурсов и выяснить предельную нагрузку для данного хоста.
Данная методика позволит грамотно рассчитать нагрузку на хост арендуемой виртуальной инфраструктур и не допустить падения производительности приложений в рабочем режиме.
Особенности правильной настройки виртуальных машин
Большинство облачных провайдеров используют платформу VMware для предоставления услуги виртуальной инфраструктуры IaaS. Настраивая виртуальные машины в этой среде, важно обратить внимание на число виртуальных процессоров. Рекомендуем не использовать больше 8 vCPU. Ограничения обусловлены использованием архитектуры неравномерного доступа к памяти — NUMA. Если виртуальной машине назначено больше ядер и оперативной памяти, чем физически приходится на один процессор, она начнет обращение к другому процессору, это процесс медленный и снижает производительность ВМ. В NUMA-архитектуре для каждого процессора выделяется собственная локальная память, совокупность CPU и RAM объединяется в NUMA-узел. Если ВМ не хватает ресурсов своего узла, она обращается к памяти другого, скорость такой транзакции медленнее чем при работе с локальной RAM. Идеально, когда виртуальная машина работает с одним физическим NUMA-узлом. Используя параметр cores per socket можно определить варианты отображения нескольких виртуальны процессоров внутри одной ВМ — один CPU с несколькими ядрами, несколько CPU с одним ядром и другие. Если ВМ будет работать на одном физическом NUMA-узле, тогда любой из вариантов cores per socket не скажется на производительности, работа конкретного приложения будет зависеть от его способности работать с многопроцессорной или многоядерной системой.
Для примера возьмем процесс переноса в облако IaaS базы данных SQL Server 2012 версии Standard. Даная база данных не может использовать больше 4 процессорных сокетов. Следовательно, для того чтобы запустить ее на виртуальной машине с 32 виртуальными процессорами или потоками, необходимо в настройках ВМ указать комбинацию 4 сокетов CPU по 8 ядер на каждом.
Как добавлять ресурсы ВМ на лету
Если в процессе работы виртуальной машины ее производительности становится недостаточно, платформа WMware позволяет добавить вычислительные ресурсы без остановки машины — на лету. Для этого необходимо воспользоваться опцией Hot Add, с помощью которой можно увеличить ресурсы процессора и объем назначенной оперативной памяти.
Однако, Hot Add для процессора (в настройках ВМ — Hot Plug) отключает vNUMA.
В результате, операционная система ВМ будет расценивать всю свободную память как доступную без разделения по узлам NUMA, что может привести к падению производительности, так как доступ к памяти другого процессора более медленный. Прежде чем включить Hot Add для процессора необходимо проанализировать как это скажется на конкретном приложении.
Разница в подходах масштабирования Scale UP и Scale OUT
Вариант вертикального масштабирования Scale UP выбирают, как наиболее простой и понятный. Все приложения и базы данных с одного мощного локального хоста переносят на одну виртуальную машину, а в случае, когда ее ресурсов начинает не хватать, администратор добавляет еще оперативной памяти и число процессоров или ядер. Подробнее о таком подходе можно прочитать в статье Виртуальный ЦОД.
В свою очередь при использовании горизонтального масштабирования — Scale OUT, мощность локального хоста распределяется между несколькими виртуальными машинам в составе одного кластера. К преимуществам такого похода можно отнести большую гибкость по управлению производительностью каждого из приложений, а также большую отказоустойчивость, так как в случае выхода из строя одной вычислительной единицы (виртуального сервера), остальная инфраструктура продолжает работать.
Настройка использования оперативной памяти
В процессе распределения оперативной памяти между виртуальными машинами следует помнить про обслуживание физического хоста. Для его нормального функционирования требуется зарезервировать несколько гигабайт RAM, который не будет задействован при создании ВМ.
Платформа VMware позволяет выделять виртуальным машинам виртуальной оперативной памяти больше, чем ее есть физической. Например, создав на хосте, оснащенном 140Гб физической оперативной памяти 5 виртуальных машин, каждой из которых назначены по 32Гб виртуальной памяти, конфигурация будет работать. Виртуальные машины будут обращаться к свободной в данный момент RAM и считать, что она доступна в полном объеме, но в случае пиковой нагрузки производительность резко упадёт. Такой сценарий лучше не использовать. Заранее спланируйте как будет распределяться доступная физическая память между созданными виртуальными машинами.
Заключение
Настройка виртуальных машин в облаке провайдера — это один из важных процессов миграции, от которого зависит успех переноса инфраструктуры и ее успешный запуск. Итоговый вариант конфигурации виртуальных машин будет сильно зависеть от компании и выбранной стратегии, однако, выполнение описанных рекомендаций позволит избежать ошибок, а также обеспечит максимальную производительность и эффективность переносимых приложений.
- VMware Technology Network
- :
- Global
- :
- Russian
- :
- Russian Discussions
- :
- Правильная настройка процессора
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Коллеги добрый день!
Помогите разобораться с настройкой процессора для виртуальных машин.
Есть в наличии сервер с 2 физицескими процессорами по 8 ядер. Всего 16 с Hyper-threading получаем 32.
При создании виртуальной машины К примеру Файловый сервер какие параметры я должен указывать. Количество CPU и количество Cores per Socket. Прочитал статьи, документы но так и не понял. Такая же ситуация с SQL сервером, оптимальная конфигурация, если приобретен SQL сервер с лицензией по ядрам SQLSvrStdCore 2017 RUS OLP 2Lic A Gov CoreLic в колличестве 4 шт
Finikiez- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
1. Если конфигурация 2 цпу с 8 ядрами в каждом, то не надо пытаться делать ВМ с более чем 16 vCPU (в любом сочетании виртуальных сокетов и виртуальны ядер)
Для разных нагрузок этот коэффициент может варьироваться.
3. Следуя из пункта 2, ваша логика конфигурации виртуальных машин неверна. Можно сделать несколько ВМ с 4 vCPU, если это нужно.
4. По поводу лицензий на MS SQL вроде бы так получается, но тут я не самый большой специалист.
Finikiez- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
- While there are many advanced vNUMA settings, only in rare cases do they need to be changed from defaults.
- 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.
- 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.
- 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.
- Don’t enable vCPU Hot Add unless you’re okay with vNUMA being disabled.
- Don’t create a VM larger than the total number of physical cores of your host.
Гипертрейдинг обычно не учитывается при сайзинге виртуальной инфраструктуры, скорее у вас играет роль коэффициент консолидации виртуальных процессоров на физическое ядро ЦПУ.
По поводу лицензии MS SQL - лучше прочитать гайд по лицензированию продуктов MS в вирутальной инфраструктуре, там не все так просто.
Viktor_2018- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Спасибо за статью! Из данной статьи я понял что не следует менять количество Cores Per Sockets если не превышено число физических ядер на процессоре.
Получается если у меня 2 процессора по 8 ядер.
На сервере esxi 6.7
Виртуальная машина 1: CPU4 , Cores Per Sockets 1
Виртуальная машина 2: CPU4 , Cores Per Sockets 1
Так как физические ядра закончились на процессоре, теперь использую 2 Сокета
Виртуальная машина 3: CPU8 , Cores Per Sockets 2
Виртуальная машина 4: CPU4 , Cores Per Sockets 2
Я правильно понял статью. Или же правильно добавлять только CPU - а система сама распределит. И количество CPU на всех виртуальных машинах данного сервера Не должно превышать 16?
По поводу лицензии для SQL прочитав статью понял что при лицензировании по ядрам. Запрещено перемещать станцию чаще чем один раз в 90 дней между серверами. Для лицензии по пользователям данного ограничения не нашел. Получается если у меня лицензия SQLSvrStdCore 2017 RUS OLP 2Lic A Gov CoreLic в колличестве 4 шт то я создаю виртуальную машину CPU4 , Cores Per Sockets 1?
Итак, вот перед вами свеженькая организация в vCloud Director, и вам только предстоит создать свою первую виртуальную машину. Сегодня расскажу, какие настройки выбирать при создании виртуальной машины, чтобы она работала и не просила есть. Поехали!
Cores per socket. Оставляйте 1 ядро на сокет, ставьте столько сокетов, сколько вам нужно виртуальных процессоров. Да, логично наоборот, но правильно так. Если у вас нет специализированных лицензионных требований. Например, вы платите за сокет, а больше сокетов означает больше лицензий. Не ставьте 2/2, чтобы получить 4. Сделайте 4/1. Такую машину гипервизор будет обслуживать оптимальным образом. Scheduler гипервизора будет меньше пенализировать такие ВМ.
Объясню на пальцах. Представьте, что проводник рассаживает пассажиров по вагону, вагон – как в Сапсане. В роли проводника scheduler, пассажиры – это ВМ. Пассажиров, которые едут в одиночку (однопроцессорные ВМ), ему распределить проще всего: их можно посадить на любое место. Семью из 4 человек (4-процессорные ВМ) уже сложнее. Им нужно найти 4 места в одном вагоне. А теперь представим, что все в семье хотят ехать только лицом друг другу, а таких групп мест – 4 вокруг стола – в вагоне только 2. С большой вероятностью такой семье придется пройти в следующий вагон (на следующий тик планирования). Это как раз та ситуация, как если бы вы выбрали 2 сокета по 2 ядра, чтобы получить 4. Скорее всего, придется подождать, чтобы нашлись подходящие места. Так же и с ВМ: ей придется ждать дольше, чем менее “прихотливым” ВМ с 1 сокетом и кучкой процессоров.
Хотя эта история актуальнее для старых версий ESXi. Начиная с 6.5 (но не ранее!) механизм vNUMA отвязан от количества виртуальных сокетов, и старая рекомендация “не плодить сокеты” не так категорична. Но все еще зависит от приложения внутри гостевой ОС.
Hot Add для CPU и Memory. Это опция добавления памяти CPU для работающей виртуальной машины. Казалось бы, прекрасная функция: не нужно гасить машину, чтобы докинуть ей ресурсов. Так вот, не все так просто, и не зря они по дефолту отключены. Лучше и не включать, если вы не знаете, что такое NUMA-топология. Допустим, под капотом облака у нас двухсокетный сервер. На каждом сокете 4 ядра. Работает это именно как 4+4, а не 8 ядер. Такая же тема с памятью: если на каждом сокете 128 ГБ, это не дает в сумме 256 ГБ. Каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти. Каждый сокет вместе с причитающейся ему процессором и памятью – это физическая NUMA-нода.
Если виртуальная машина влезает в размер физической NUMA-ноды, то она исполняется внутри этой ноды. Если виртуалка не умещается в NUMA-ноду, например по памяти, то она будет использовать память из соседней NUMA-ноды. Путь к удаленной памяти будет извилист – через межпроцессорную шину. Работать это будет не так быстро, как если бы виртуалка использовала ресурсы одной ноды.
Когда вы включаете добавления виртуальных процессоров и памяти на горячую, все это идет только в нулевую NUMA-ноду. Например, добавилось еще 4 процессора, и на NUMA-ноде 0 стало 6, а на NUMA-ноде 1 – 2 процессора. Машину немного перекосило, и работает она также косо. Это связано с тем, что при включении vCPU Hot-Plug перестает работать vNUMA, через которую vSphere старается оптимизировать топологию NUMA для ВМ. Поэтому, принимая решение о включении CPU Hot-Add, учитывайте физическую топологию NUMA для обеспечения производительности ВМ. Это очень критично, если по каким-либо причинам в ВМ имеется несколько виртуальных сокетов. В этом случае несоответствие физической топологии вызовет сильное падение производительности: CPU Scheduler сойдет с ума, пытаясь предоставить процессорное время такой ВМ, что вызовет рост CPU Ready и Co-Stop.
Все добавленные виртуальные процессоры (5-8) и память попали на NUMA-ноду 0.
Отдельная история в том, что будет происходить внутри ОС и приложения после таких “добавок”. Поэтому если уж решили пользоваться этой опцией, то проверьте, поддерживает ли ваша ОС такое. Non-NUMA-Aware приложения могут сильно просесть по производительности при расположении на нескольких NUMA-нодах.
Если вы все-таки добавили процессоры или память на горячую, сразу планируйте перезагрузку ВМ (не только ОС) на ближайший запланированный даунтайм.
Галочки не ставим.
Дисковый контроллер (Bus type). Для дисков выбирайте дисковый контроллер Paravirtual. Этот тип контроллера требует установки драйверов в ОС VMware Tools. Paravirtual – это специальное виртуальное устройство, которое создавалось для работы в виртуализации и не эмулирует работу какого-то другого аппаратного устройства. Любая эмуляция аппаратного устройства всегда работает медленнее.
Если вы не хотите использовать Paravirtual (но почему?), выбирайте LSI Logic SAS. Если ОС не поддерживает и его — LSI Logic Parallel. Никогда не используйте SATA и IDE. ВМ будет медленно работать, в итоге вы не получите производительности, за которой идут в облако.
При инсталляции ОС даже свежая версия Windows может не найти драйвер для Paravirtual адаптера. В этом случае примонтируйте к ВМ два ISO файла — ваш загрузочный образ Windows и диск с VMware tools. На последнем есть необходимый драйвер.
Сетевой адаптер. Правильный выбор – VMXNet3. VMXNet3, как и дисковый адаптер Paravirtual, это паравиртуальное устройство. Оно также требует драйверов, которые входят в VMware Tools.
Если вдруг VMXNet3 не подходит (проявляется какая-то несовместимость), то на крайний случай используйте E1000E. Но не ожидайте от адаптера E1000E производительности больше, чем 1 Гбит.
В общем, E1000E без прямых указаний вендоров не используйте. Казалось бы, оно новее, но сделано для обеспечения еще большей совместимости c legacy.
Вот не надо E1000E.
VMware Tools. Следите, чтобы они были установлены в ОС, запущены и актуальны. В VMware Tools входят драйвера устройств и разные другие компоненты, которые позволяют общаться ОС виртуальной машины с гипервизором, и наоборот. Через них происходит синхронизация времени ОС с хостом виртуализации (отключаемо), ходят heartbeat’ы, которые показывают гипервизору, что виртуалка жива, и прочее. Для работы ОС на виртуальной машине нужны как минимум драйверы сетевой карточки, дискового адаптера. Свежие версии всего вот этого входят в VMware Tools.
По умолчанию актуальные версии Windows и Linux имеют драйвера для работы с виртуальными устройствами VMware, но если у вас будут VMware Tools, то эти драйвера будут всегда свежими. Для Linux рекомендуется использовать open-vm-tools. Это не просто лучшая интеграция с ОС, но и обновление драйверов вместе с системой.
Отдельные диски для данных. Используйте разные виртуальные диски под данные и операционную систему. Да и на физических серверах стоит так делать. Вы сможете отдельно бекапить эти диски (с разным расписанием, например), сможете переключить диск с данными или его клон на другую ВМ и прочее.
Кроме того, новый виртуальный диск также получит дополнительную квоту на дисковую производительность.
Кастомизация. При первом включении ВМ нужно кастомизировать, чтобы все настройки из облака (например выданный облаком IP-адрес) применились к ОС. После уберите эту галку от греха подальше, чтобы нечаянно не сбросить настройки ОС: SID, пароль администратора и т. п.
Конечно, все вышесказанное – упрощенная картина, слова “капитана О” и, вообще, “все же это знают”. Но, как показывает практика, более 70% ВМ в облаке содержат одну или сразу несколько описанных ошибок.
Читайте также: