VMware cores per socket и vCPU какой алгоритм верный?
Всем привет, возник вопрос как правильнее распределять ресурсы при создании виртуальной машины и чем руководствоваться. В статьях пишут о том, что количество ядер VM не должно превышать количества ядер на хосте, но при этом на тестовом стенде получается следующее: стенд 4 ядра с 8 потоками
1 случай: CPU 8; Cores per Socket 2; получаем 2 процессора по 4 ядра Bench CPU 4.8
2 случай: CPU 8; Cores per Socket 8; получаем 1 процессор по 8 ядер Bench CPU 5.05
3 случай: CPU 4; Cores per Socket 4; получаем 1 процессор по 4 ядра Bench CPU 3.79
Чем чревато превышение логических ядер над физическими или в логике VMWare Logical processors (в моем случае 8) это и есть кол-во логических ядер которое мы распределяем?
Моя первая виртуальная машина: как не накосячить
Итак, вот перед вами свеженькая организация в vCloud Director, и вам только предстоит создать свою первую виртуальную машину. Сегодня расскажу, какие настройки выбирать при создании виртуальной машины, чтобы она работала и не просила есть. Поехали!
Источник: drive2.ru
Операционная система. Выбирайте современные дистрибутивы. Если берете Windows 2008 R2 и более старую или Linux до ядра 4.19.x, ждите проблем. Каких? Ну, например, вендор уже перестал поддерживать актуальное состояние Windows 2008 R2 аж в 2013 году (EOL). Это означает, что он больше не разрабатывает драйвера под вышедшее с тех пор железо, не модифицирует ОС под новое что угодно. С древними операционками вы точно не сможете использовать все возможности, которые предоставляет современный гипервизор. А уже в эти новогодние праздники остро встанет проблема с безопасностью, так как 14 января 2020 года заканчивается расширенная поддержка Windows Server 2008 R2 и перестанут выходить Security Update.
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% ВМ в облаке содержат одну или сразу несколько описанных ошибок.
- виртуальная машина
- vcloud director
- vmware
- Блог компании DataLine
- IT-инфраструктура
- Виртуализация
- Облачные вычисления
- Облачные сервисы
Как изменить параметры виртуальной машины?
В разделе Compute в пункте Virtual Machines выбираем необходимую и нажимаем Details.
Открывается окно с четырьмя основными вкладками: General, Hardware, Guest OS Customization, Advanced. Рассмотрим каждую из них подробнее. В инструкции будут описаны только те опции, которые вы сможете редактировать самостоятельно.
1. Параметры вкладки General:
- Name – имя виртуальной машины;
- Computer Name – DNS-имя сервера внутри гостевой операционной системы;
- Description – описание виртуальной машины;
- Operating System – версия ОС, установленной внутри виртуальной машины. Данный параметр определяет то, какой образ будет подключен гипервизором для установки vmware tools;
- Boot Delay – пауза между окончанием инициализации BIOS и загрузкой ОС;
- Storage Policy– тип системы хранения данных, на которой будут находиться конфигурационные файлы ВМ (swap, снимки состояния) и ее диски;
- Enter BIOS Setup – если этот флаг активен, при следующей загрузке будет принудительно вызвано меню BIOS;
2. Параметры вкладки Compute:
- Sizing Policy – тип физических серверов, на которых будет работать ВМ;
- Number of virtual CPUs – суммарное количество ядер CPU ВМ;
- Cores per socket – параметр распределения ядер по сокетам. Если у вас нет специальных требований, например к лицензированию ПО, рекомендуем данный параметр оставить в значении 1.
- Virtual CPU hot add – возможность добавления CPU без отключения ВМ. Использование данного функционала может негативно повлиять на производительность ВМ, используйте с осмотрительностью.
- Expose hardware-assisted CPU virtualization to guest OS – проброс функций аппаратной виртуализации процессора в гостевую ОС.
- Total Memory – объем оперативной памяти виртуальной машины;
- Memory hot add – возможность добавления памяти без отключения ВМ;
- Кнопка ADD – добавление новых виртуальных дисков;
- Size – размер виртуального диска;
- Policy – тип СХД, на которой будут расположены диски;
- Bus Type – тип виртуального дискового контроллера. Рекомендуем оставлять данный параметр по умолчанию.
- Bus Number, Unit Number – параметры, определяющие адресацию шины дисков;
- Кнопка с изображением корзины – удаление виртуального диска.
- Кнопка ADD – добавление новых виртуальных сетевых адаптеров;
- Primary NIC – если флаг активен, то к данному адаптеру будут применяться параметры спецификации виртуальной сети (DNS, Default Gateway);
- Connected – подключение/отключение виртуального адаптера к виртуальной сети;
- Network Adapter Type – модель виртуального сетевого адаптера. Данный параметр можно выбрать только в момент добавления адаптера к ВМ. Рекомендуем использовать VMXNET3.
- Network – имя сети уровня vApp или организации, к которой необходимо подключить адаптер;
- IP Mode – выбор режима назначения IP-адреса адаптеру;
- IP Address – поле для ручного определения адреса адаптера, доступно только в режиме Static – Manual;
- MAC Address – MAC-адрес виртуального адаптера;
- Кнопка с изображением корзины – удаление виртуального адаптера.
3. Параметры вкладки Guest OS Customization рассмотрены в инструкции «Как кастомизировать виртуальную машину».
4. Параметры вкладки Advanced позволяют создать дополнительные параметры ВМ, например, для создания сценариев автоматизации. Также тут определяются параметры управления конкуренцией за ресурсы CPU и RAM, однако данный функционал недоступен для пользователей в нашей инфраструктуре.
Cores per socket что это
VMware — Как изменить CPU у виртуального сервера?
Ограничения:
— на работающем виртуальном сервере можно только увеличить количество socket
— на работающем виртуальном сервере можно увеличить количество socket, если включена опция «Virtual CPU hot add«
— каждый vCPU содержит «Cores per socket«, поэтому квант изменения равен это величине
Рекомендация: на сервер нужно устанавливать такое количество ядер при котором утилизация CPU в ОС в рабочее время будет 60-80%. С «запасом» брать ядра не следует.
Включение опции «Virtual CPU hot add»
1. Зайдите в свойства VM: Compute — Virtual Machines — найдите нужную VM — Details
2. Перейдите на вкладку Hardware — Compute
3. Проверьте включена ли опция «Virtual CPU hot add«
4. Если она «Disabled«, то измените на «Enable«. Для этого нажмите Edit в блоке CPU и измените положение переключателя «Virtual CPU hot add» и нажмите Save.
Примечание, изменить можно только если виртуальный сервер выключен.
Изменение количество vCPU
1. Зайдите в свойства VM: Compute — Virtual Machines — найдите нужную VM — Details
2. Перейдите на вкладку Hardware — Compute
3. В блоке CPU нажмите Edit.
4. Измените количество vCPU. В данном примере у виртуального сервера 2 vCPU (ядра), каждый сокет содержит по 2 ядра (Cores per socket), поэтому у сервера 1 сокет (Number of sockets).
Поэтому нужно выбирать 4,6,8 и т.д. Можно выбрать другое число vCPU, но система выдаст ошибку, так как добавляются к виртуальному серверу сокеты, а у сокета vCPU. Нажмите кнопку Save