Esxi настройка виртуальной машины cpu

Esxi настройка виртуальной машины cpu

Добрый день, товарищи, продолжаем разбираться в гипервизоре Vmware ESXI 5.5. О многом мы уже с вами говорили, но пока еще не рассматривали вопросы, о том как ограничить ресурсы виртуальной машины Vmware ESXI 5.5. Для чего это может быть, представим ситуацию, что у вас есть хост, с хорошими ресурсами, пока их хватает все виртуалки на них живут и не знают бед, но представим, что одна из них стала прожорливой и скушала, все что было, и ей этого мало. Она начинает свопить диск, да и еще процессор весь скушала, начинает полная жопа со всеми жителями хоста, а вот если бы мы правильно спланировали и подрезали ее заранее, то такого бы не было, смотрим как этого достичь.

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

И так с термином ограничение ресурсов мы познакомились, теперь практика и только практика. По свой работе, точнее по умолчанию, все виртуальные машины на ESXI 5.5, равноправны, что означает, ресурсы используют без всяких приоритетов, более подробно что такое виртуализация vmware почитайте по ссылке, будет полезно. Наша задача, посмотреть как назначаются приоритеты и лимиты. Выбираем любую виртуальную машину, единственное условие, она должна быть включена, щелкаем по ней правым кликом и выбираем Edit settings.

Переходим на вкладку Resources, первое что мы рассмотрим это ресурсы CPU, справа в области Resource Allocation вы видите три пункта

ниже мы рассмотрим что каждая из них означает.

Параметр Limit в ограничении ресурсов

И так параметр Limit в настройках ресурсных пулов или отдельных виртуальных машин, по сути жестко ограничивает виртуальную машину по данному виду ресурсов будь то память или процессор, сколько поставили, столько и будет максимальный потолок. По умолчанию стоит Unlimited. Простой пример у вас хост с одним процессором и 4 ядрами, вы запускаете виртуальные машины, у которых допустим, 8 логических ядер, виртуалки живут все хорошо, процессорные мощности справляются и гипервизор успевает перекидывать операции между ядрами, и тут в один момент одна из тестовых виртуалок начинает использовать, много ресурсов, в итоге все начинает проседать, параметр Limit и дает возможность так вот ограничить, дойдет до потолка и выше уже не скушает. Если мы говорим о продакшене, то иногда это помогает снять нагрузку с хоста, и уменьшить аппетиты какой той виртуальной машины, чтобы другие могли работать, но жесткое ограничение не совсем правильно, например когда ресурсов много и они есть в данный момент, то они могли использоваться, а не простаивать, более правильно конечно делать приоритеты, но для тестовых вещей это самое то.

И так снимаем галку Unlimited и выставляем нужную, цифру мегагерц, которой вы хотите ограничить, у меня это 5000, будь хоть у вас у виртуальной машины 2 процессора по 5 ядер, суммарно они не смогут дать более 5000 мегагерц.

если бы рассматриваем уже работу оперативной памяти и параметра linit в esxi 5.5, то тут немного иначе. При CPU вы не поднимаетесь выше того лимита, что стоит, у памяти вот как, допустим вы выделили виртуальной машине ОЗУ 8 гб, в параметре limit вы выставили, ограничение, 4 гб, что будет. Будет, то что вы получите от реальной физической оперативной памяти 4гб, все остальное гипервизор для виртуальной машины, доберет с локальных дисков в виде свопа, что в свою очередь, нагрузит дисковую подсистему, что не есть хорошо (более подробно о том как устроена дисковая архитектура vmware esxi 5.5 почитайте по ссылке, а так же посмотрите про снапшоты и своп файлы esxi), так что такое ограничение ресурсов, нужно тоже продумывать, особенно при слабой дисковой подсистеме, если конечно у вас ssd, это улучшит конечно положение, но ssd в сотни раз медленнее ОЗУ и это нужно помнить.

Рассмотрим, теперь вопрос про виртуальные диски, тут на вкладке Disk, можно выставить только одно ограничение по ресурсам, а именно количество операций ввода/вывода (iops), по умолчанию это безлимит, не для кого не секрет, что это самое узкое место в нынешних системах, если проседает дисковая подсистема, автоматически нагружается процессор, так как операционная система пытается компенсировать недостаток ресурсов, если у вас есть кто то прожорливый и вдруг получилось так исторически что ресурсов по дискам не хватает, я про iops, то можно кого то подрезать.

я для примера сделал ограничение 20 iops, это очень мало, но для linux тачек пойдет, особенно не критичных.

Параметр Reservation в ограничении ресурсов

И так функция Reservation, ее основное предназначение, это указать ресурсному пулу или виртуальной машине, то количество ресурсов которое ей выделено, сто процентов. Вот я для примера, отдал vm машине 5000 мегагерц, выше лимита поставить не получиться, это значит, что 5000 принадлежат только ей, данные ресурсы под нее зарезервированы.

Если рассматривать ОЗУ, то тут принцип тот же,единственное, что когда вы резервируете память, то то количество, что отдано под резерв, будет отнято от размера свопа на дисках. Если у вас у vm машины 4 гб ОЗУ и вы в Reservation стоит тоже 4 гб, то на датасторе в каталоге с виртуальной машиной у вас не будет своп файла. За счет такого метода ограничения ресурсов, можно увеличить работу дисковой подсистемы.

раметр используется планировщиками VMware DRS (в настройках кластера) и VKernel (в пределах хоста ESX), а также компонентом Admission Control кластера VMware HA

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

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

Параметр Shares в ограничении ресурсов

Shares указывает приоритет использования ресурсов виртуальными машинами в рамках ESXI хоста или ресурсного пула. Shares имеют значение только тогда, когда ощущается нехватка ресурсов в рамках хоста VMware ESXI, пула ресурсов или кластера DRS. Дання настройка имеет 4 значения

Данная фишка начинает функционировать, когда у вас начинается нехватка ресурсов процессора или памяти, которая находится между Reservation (обеспечено физическими ресурсами) и сконфигурированной памятью или CPU виртуальной машины (заданной в настройках). На скриншоте ниже при значении normal, shares 40960

если выставить low, то видите стало в два раза меньше.

Также shares есть и для виртуальных дисков

Еще хочу обратить внимание, на то что нужно правильно планировать shares для resourse pool. И так на картинке у нас есть кластер А, в нем есть два ресурсных пула, для пула RP-01 мы выставили значение share 2000, для пула RP-02 в 1000. То есть соотношение по процентам 66 к 33, но на первом RP-01 пуле, работает 6 виртуальных машин, что означает 66/6=11, а у второго 33/3=11, и как видите, все одинаково.

Ведь управление ресурсами в пределах кластера VMware DRS для пулов происходит на их уровне, а не на уровне отдельных виртуальных машин.

Источник

Настройка Resource Allocation для виртуальных машин

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

Shares

Для этого параметра возможно установить 4 значения:

Данный параметр будет устанавливать приоритет использования всех ресурсов для ВМ на хосте. Разбиение по группам приоритетов следующее: Normal имеет в два раза больший приоритет по сравнению с Low, а High в два раза больший приоритет по сравнению с Normal. Численно это будет равно:

Этот параметр вступает в силу только в том случае, когда выделенных ресурсов начинает не хватать.

Reservation

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

Limit

Если Reservation определял минимальное потребление ресурсов, то Limit определяет максимальное потребление ресурсов виртуальной машиной. В отличие от Reservation, параметр Limit не будет играть роль при расчете Share, то есть, если мы установим лимит по памяти, ВМ при любых условиях не сможет его перейти, даже если ей будет выделено больше. Параметр Limit будет устанавливать верхнюю планку для параметров ВМ.

Другими словами, Reservation устанавливает нижнюю планку использования ресурсов, а Limit – верхнюю.

Resource Allocation

Параметр Reservation устанавливает нижнюю планку использования ресурсов для ВМ на хосте ESX.
Параметр Limit устанавливает верхнюю планку использования ресурсов для ВМ на хосте ESX.
Параметр Share задает приоритет использования ресурсов для ВМ на хосте ESX.

Последовательность выставления параметров
Для простоты решения мы будем использовать лишь настройки Resource Allocation для RAM на хосте ESX.

Какие исходные данные нам нужны:

Последовательность действий при настройке параметров Share, Reservation, Limit:

Пример
Есть 1 хост ESX, с 6Гб RAM. На нем исполняются 2 ВМ для поддержки VCenter и View (им выделено по 4Гб памяти каждой), 1 машина с AD (3 Гб памяти), а также 4 ВМ, использованные под рабочие столы View (по 1Гб каждая).

Существует два варианта развития событий:

Рассчитываться значения параметров будут следующим образом:

Где N – объем памяти ESX хоста;
X – коэффициент расчета остаточного места;
A₁-A_n – коэффициенты всех приоритетов, присутствующие в настройках ВМ;
B₁-B_n – Параметры каждой ВМ (RAM или CPU);

После нахождения X (в нашем случае он равен 176.47), мы подставляем его в нашу формулу, каждая скобка будет равна объему памяти для соответствующей ВМ, например X*A₁*B₁=N₁, где N₁ будет равно высчитанному объему памяти первой ВМ:

Если сравнивать с параметрами Reservation, то все наши ВМ превышают установленный параметр, следовательно, у них так и останутся такие значения.

Напоследок, в показательных целях установим значение параметра Reservation для View – 2 Гб. Гипервизор все высчитает автоматически и назначит всем точное значение, нам же придется посчитать промежуточное значение (в некоторых случаях их может быть несколько) с учетом только параметров резервации для View. Если еще какой-то параметр будет меньше, придется и ему назначать точное значение. Мы просто отбросим View с точным значением 2Гб, остальные будем рассчитывать также, лишь будем брать ESX с 4 Гб (6-2):

Мы видим, что AD теперь уже не удовлетворяет заданным требованиям Reservation (1Гб). Проводим такую же операцию, назначив уже для AD параметр резервации 1Гб и не рассчитывая ни AD, ни View. Следовательно, распределение RAM будет следующее:

А далее для остальных считаем как для параметра Share:
VCenter – 2.4 Гб (при расчетах Share 2.4Гб удовлетворяют настройкам Reservation);
4 vDesktops – по 150 Мб.

Возможно, Вам будет также интересна следующая информация:

Источник

механизмы перераспределения ресурсов в esx(i)

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

С точки зрения ESX(i) процессоры бывают трех типов:

— физические (physical, PCPU). Это именно процессоры, иногда говорят «сокеты». В зависимости от их количества ESX(i) лицензируется;

Самое первое, что необходимо сказать:

— на одном ядре может выполняться несколько vCPU разных виртуальных машин (рис. 6.23).

Рис. 6.23. Иллюстрация работы с процессорной подсистемой Источник: VMware

На иллюстрации показан двухпроцессорный сервер, каждый процессор двухъядерный.

Гипервизор осуществляет балансировку нагрузки, с интервалом в 20 миллисекунд может переносить vCPU между LCPU для лучшей их утилизации. Service Console всегда работает на CPU0, то есть первом ядре первого процессора.

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

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

Для гипервизоров предыдущих поколений эта проблема решалась тем, что гипервизор отслеживал «рассинхронизацию», то есть ситуацию, когда какие-то vCPU работали, а какие-то нет. Когда разница во времени работы достигала порогового значения (несколько миллисекунд), гипервизор останавливал «убежавшие вперед» vCPU и ждал возможности выделить процессорные такты всем vCPU этой ВМ одновременно. Получалось, что значительную долю времени все несколько vCPU этой ВМ простаивали. Так поступал ESX версии 2.

Однако ESX(i), начиная еще с версии 3, использует механизм под названием «Relaxed coscheduling». Суть его заключается в том, что одновременно получать такты должны не все vCPU одной ВМ, а лишь те, что «отстали». Это уменьшает потери производительности из-за виртуализации, позволяя более эффективно утилизировать процессорные ресурсы сервера.

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

Обратите внимание. Консольная утилита esxtop (resxtop для vCLI) показывает время ожидания синхронизации в столбце %CSTP. Таким образом, эта величина характеризует накладные расходы на виртуализацию процессоров многопроцессорной ВМ.

Также в свойствах ВМ на закладке Resources есть строка Advanced CPU (рис. 6.24).

Здесь вы можете задать настройки Hyperthreaded Core Sharing и CPU Affinity.

Рис. 6.24. Настройки Advanced CPU

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

Обратите внимание. Нет четких данных по эффективности использования гипертрейдинга для ESX(i). Как правило, от включения гипертрейдинга производительность меняется незначительно. Вероятность ухудшения производительности от включения этой функции невелика.

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

Источник

Производительность VMware vSphere 5.5 и 6.0 — настройки, соображения. Perfomance Best Practices

Проштудировав документы Perfomance Best Practices for vSphere 5.5 и Perfomance Best Practices for vSphere 6.0, не выявил особых расхождений в настройке, как и чего-то дополнительно специфичного для vSphere 6.0.

Большая часть написанного умещается в стандартные рекомендации формата «используйте совместимое и сертифицированное оборудование» и «при сайзинге ВМ выделяйте ресурсы (vCPU, vRAM) в объёме не более необходимого».

Тем не менее, базовые вещи решил оформить отдельным постом, немного переструктурировав, избавив от «воды» и некоторых отсылок и замечаний, которые являются слишком специфичными и для большинства реализаций являются скорее вредными чем полезными. В сухом остатке остались рекомендации, советы и соображения, проверенные и протестированные на практике и применимые для 90% инфраструктур VMware vSphere и standalone ESXi. Разбавленные общими соображениями и дополнениями.

Хост ESXi

Общие рекомендации

Гипервизор

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

— для процесса vmx (VM eXecutable);
— для процесса vmm (VM Monitoring) — мониторинг состояния виртуального процессора, маппинг — виртуальной памяти и т.д.;
— для работы виртуальных устройств ВМ;
— для работы других подсистем — kernel, management agents.

Оверхед каждой машины более всего зависит от количества её vCPU и объёма памяти. Сам по себе он не большой, но стоит иметь ввиду. Например, если весь объём памяти хоста будет занят или зарезервирован виртуальными машинами, то может увеличиться время отклика на уровне гипервизора, а также возникнут проблемы с работой таких, например, технологий как DRS.

Виртуальные машины

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

— оверхед, описанный в предыдущем разделе;
— NUMA. Если количество vCPU соответствует количеству ядер в NUMA-сокете и объём памяти тоже не выходит за пределы NUMA-ноды, то гипервизор старается локализовать ВМ внутри одной NUMA-ноды. А значит доступ к памяти будет быстрее;
— Планировщик процессора. Если на хосте много ВМ с большим количеством vCPU (больше в сумме, чем количество физических ядер), то растёт вероятность появления такого явления как Co-Stop — притормаживание некоторых vCPU из-за невозможности обеспечить их синхронную работу в рамках отдельной ВМ, потому что количества физических ядер не хватает для одновременного цикла;
— DRS. Машины с небольшим количеством процессоров и памяти переносить с хоста на хост проще и быстрее. В случае внезапного скачка нагрузки легче будет перебалансировать кластер, если он состоит из небольших ВМ, а не из многогигабайтных монстров;
— Локализация кэша. Внутри ВМ гостевая ОС может переносить однопоточные процессы между различными процессорами и терять процессорный кэш.

Выводы и рекомендации:

Гостевая ОС

Хранение и хранилища

Главное, что стоит принять во внимание — ваше хранилище должно поддерживать vStorage API for Array Integration (VAAI). В этом случае будет поддерживаться следующее:

— Оффлоад процессов копирования, клонирования и переноса ВМ между LUN одного хранилища или между хранилищами, поддерживающими технологию. То есть процесс будет выполняться большей частью самим хранилищем, а не процессором хоста и сетью.
— ускорение зануления блоков при создании Thick Eager Zeroed дисков и при первичном наполнении Thick Lazy Zeroed и Thin дисков.
— Atomic Test and Set (ATS) — блокирование не всего LUN, при изменении метаданных, а только одного сектора на диске. Учитывая, что метаданные изменяются при таких процессах как включение/выключение ВМ, миграция, клонирование и расширение тонкого диска, LUN с большим количеством ВМ на нём может не вылезать из SCSI Lock’а.
— Unmap — «освобождение» блоков тонких LUN при удалении/переносе данных (касается только LUN, но не vmdk).

Соображения и рекомендации:

Инфраструктура виртуализации

DRS и кластеры

vMotion и Storage vMotion

По умолчанию, на каждый активный процесс vMotion гипервизор отъедает 10% одного ядра процессора. И на приёмнике и на источнике. То есть если на хосте все процессорные ресурсы находятся в резервировании, с vMotion могут быть проблемы. (С DRS точно будут).

При Storage vMotion с исходного датастора активно идёт чтение, а на целевой — запись. Кроме того, на оба датастора идёт синхронная запись изменений внутри ВМ. Отсюда вывод — если двигаем ВМ с медленного датастора на быстрый, эффект будет заметен только по окончанию миграции. А если с быстрого на медленный, то деградация производительности наступит сразу.

Источник