Как ограничить ресурсы виртуальной машины Vmware ESXI 5.5

Обновлено 11.03.2022

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

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

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

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

• Shares
• Reservation
• Limit

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

Параметр 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.

Однако такая ситуация может случиться только с ОС Linux, которая по мере загрузки и роста нагрузки адресует страницы памяти, а вот Windows - обнуляет всю свою память при загрузке, что сразу же приводит к достижению уровня Reservation для виртуальной машины.

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

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

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

• High
• Medium
• Low
• Custom

Они обозначают соотношение приоритетов использования ресурсов 8000:4000:2000 (4:2:1) соответственно. Чем больше значение Shares - тем больше VM получит ресурсов в пределах пула или отдельного хоста ESXI. Можно задать значение Custom и все значения проставить так как вам нужно.

Данная фишка начинает функционировать, когда у вас начинается нехватка ресурсов процессора или памяти, которая находится между 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 для пулов происходит на их уровне, а не на уровне отдельных виртуальных машин.