Настройки распределения ресурсов для ВМ. Пулы ресурсов

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

6.1.1. Настройки limit, reservation и shares для процессоров и памяти

Для процессоров и памяти виртуальных машин мы можем задавать настройки limit, reservation и shares. По-русски их можно обозвать как «максимум», «минимум» и «доля» соответственно. Поговорим про них по порядку. В конце приведены мои соображения и рекомендации по планированию этих настроек.

Limit, reservation и shares для процессора

Если вы зайдете в настройки ВМ ? закладка Resources, то увидите настройки

ресурсов для этой ВМ. Выделим настройки процессорной подсистемы (рис. 6.1).

Reservation – это количество мегагерц гарантированно закрепляется за данной ВМ в момент ее включения. Обратите внимание: резерв – это блокирующая настройка. Если у сервера недостаточно мегагерц, чтобы обеспечить резерв ВМ, то виртуальная машина не включится с соответствующим сообщением об ошибке (рис. 6.2)

Рис. 6.1. Настройки ресурсов для процессоров ВМ

Рис. 6.2. Сообщение о нехватке ресурсов для обеспечения резерва процессора ВМ

Limit. Для процессоров это – максимальное количество мегагерц, которое может быть выделено для этой ВМ на все ее процессоры. По умолчанию стоит флажок Unlimited – это означает, что искусственно мы не ограничиваем процессорные ресурсы ВМ, они ограничены только физически. Один виртуальный процессор не может получить мегагерц больше, чем предоставляет одно ядро процессора физического.

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

Shares. Однако как быть в ситуации, когда ресурсов сервера достаточно для покрытия резервов всех работающих ВМ, однако недостаточно для удовлетворе ния их аппетитов (и они не уперлись в свои лимиты)? В таких ситуациях работает настройка Shares (доля). Какую долю составляет количество shares одной ВМ относительно суммы shares всех претендующих на ресурс ВМ – такую долю этого ресурса ВМ и получит. Shares – это именно доля, это безразмерная величина.

Пример: на одном ядре сервера оказались три однопроцессорные ВМ. Shares у них одинаковый, по 1000. Всего 3000 = 1000 ? 3, значит, доля любой ВМ – одна

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

Еще раз напомню: механизм shares работает, когда ВМ:

Q уже превысила свой резерв;

Q еще не достигла своего лимита;

Q ресурсов не хватает на все претендующие на них ВМ.

Если для какой-то ВМ увеличить или уменьшить shares – ей немедленно увеличат или уменьшат долю ресурса, выключения ВМ для этого не требуется.

В поле shares вы можете выбрать одну из трех констант – Low, Normal или High, соответствующие 500, 1000 или 2000 shares. Или выбрать Сustom и указать произвольное их число. Данные константы введены для вашего удобства – ведь все равно у вас будут типовые, более и менее важные ВМ.

Обратите внимание на мой пример: «На одном ядре оказались три ВМ…». Это важный нюанс – процессорный ресурс дискретен. Реально бороться за ресурсы процессора ВМ будут, лишь оказавшись на одном ядре. Также для ВМ с одним виртуальным процессором максимально доступная производительность – это производительность одного ядра. Задирать резерв или лимит выше – бессмысленно.

Соображения по поводу использования этих настроек см. в п. 6.1.3 «Рекомендации по настройкам Limit, Reservation и Shares».

Limit, reservation и shares для памяти

Если вы зайдете в настройки ВМ ? закладка Resources, то увидите настройки

ресурсов для этой ВМ. Выделим настройки памяти (рис. 6.3).

На первый взгляд, все точно так же, как и для процессора, но есть нюанс.

Рис. 6.3. Настройки ресурсов для памяти ВМ

Reservation – это количество мегабайт гарантированно закрепляется за данной ВМ в момент ее включения. Обратите внимание: резерв – это блокирующая настройка. Если у сервера недостаточно мегабайт, чтобы обеспечить резерв ВМ, то ВМ не включится с соответствующим сообщением об ошибке.

Limit – это максимальное количество мегабайт, которое может быть выделено для этой ВМ. Но что означает стоящий по умолчанию флажок Unlimited?

И что за память тогда настраивается на закладке Hardware (рис. 6.4)?

Рис. 6.4. Настройка «Hardware» памяти

Что означает Reservation, если гостевая ОС в любом случае видит весь выделенный ей объем памяти?

С памятью ситуация следующая.

Верхней границей, то есть количеством памяти, которое видит гостевая ОС, является настройка памяти на закладке Hardware. Я ее в дальнейшем буду называть «hardware memory», и такое название вам может встретиться в документа ции. Таким образом, если вы хотите ограничить ВМ сверху, меняйте не настройку Limit, а количество памяти на закладке Hardware.

Reservation – столько мегабайт памяти гарантированно выделяется из фи-

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

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

Скорее всего, вы не будете использовать настройку Limit на уровне ВМ. Если вам необходимо выделить для ВМ меньше памяти – уменьшайте значение настройки Hardware memory. Ситуаций, в которых вам может потребоваться изменение настройки Limit, немного. Например, стоит задача протестировать приложение Х, у которого жесткие системные требования, и оно отказывается запускаться, если считает, что компьютер им не удовлетворяет (у него меньше А гигабайт ОЗУ). Если у сервера ESX(i) мало ресурсов, то можно настройкой hardware memory указать достаточное для запуска приложения X количество памяти. А настройкой Limit ограничить реальное потребление оперативной памяти сервера этой ВМ. Или, как вариант, вы сейчас не хотите выделять какой-то ВМ много памяти, но в будущем это может понадобиться. Для увеличения Hardware memory требуется выключение ВМ (за исключением случая использования тех гостевых ОС, которые поддерживают горячее добавление памяти), для увеличения Limit – нет.

Shares. Однако как быть в ситуации, когда ресурсов сервера достаточно для покрытия резервов всех работающих ВМ, однако недостаточно для удовлетворе ния их аппетитов (и они не уперлись в свои лимиты)? В таких ситуациях работает настройка Shares («доля»). Какую долю составляет количество shares одной ВМ относительно суммы shares всех претендующих на ресурс ВМ – такую долю этого ресурса ВМ и получит. Shares – это именно доля, это безразмерная величина. Обратите внимание: если для процессора константы Low, Normal и High соответствуют 500, 1000 или 2000 shares на ВМ, то для памяти это не так. Для памяти Low, Normal или High соответствуют 5, 10 или 20 shares на каждый мегабайт памяти ВМ.

Пример: на сервере оказались три ВМ. Объем памяти у двух равен 500 Мб, у третьей – 1000 Мб. Shares у них одинаковый, Normal, то есть по 10 на мегабайт. См. рис. 6.5.

Всего shares 20 000. Виртуальные машины А и Б имеют право на до четверти от всей памяти. ВМ В – на половину, при такой же настройке shares. И это логично, так как аппетиты ВМ В вдвое выше каждой из прочих.

Рис. 6.5. Описание примера распределения долей памяти

Еще раз напомню – механизм shares работает, когда ВМ:

Q уже превысила свой резерв;

Q еще не достигла своего лимита;

Q памяти не хватает на все претендующие на нее ВМ.

Если для какой-то ВМ увеличить или уменьшить shares, ей немедленно увеличат или уменьшат долю ресурса, выключения ВМ для этого не требуется.

Обратите внимание: если ВМ не задействует память – ESX(i) не адресует ее для этой ВМ. Посмотреть это можно на закладке Summary для виртуальной машины (рис. 6.6).

Рис. 6.6. Информация об объемах выделенной и используемой памяти

Выделена настройка Memory = 1 Гб. Столько памяти видит гостевая ОС, это настройка «Hardware memory». Справа показана «Active Guest Memory» – столько памяти активно использует гостевая ОС. А «Consumed Host Memory» показывает, сколько физической памяти ESX(i) выделил под данные этой ВМ. В упрощенной формулировке это означает, что ESX(i) может уменьшить Consumed Memory до Active Memory при необходимости, без ущерба для производительности ВМ.

Если выделить пул ресурсов, vApp, сервер, кластер или дата-центр и перейти на закладку Virtual Machines, то подобную информацию можно получить для всех ВМ выделенного объекта (рис. 6.7).

Рис. 6.7. Данные по использованию памяти для всех ВМ на одном сервере

По умолчанию вы увидите не совсем тот же набор столбцов. Это настраивается в контекстном меню данной закладки ? View Column.

Столбец Memory Size – это «hardware memory». Столбец Guest Mem % – какой процент от выделенной памяти активно использует гостевая ОС.

Если у сервера недостаточно памяти для удовлетворения резерва ВМ, то эта ВМ не включится. Если у сервера недостаточно памяти для удовлетворения аппетитов ВМ сверх резерва – то недостаток физической оперативной памяти будет компенсирован файлом подкачки. Механизмов подкачки используется два – файл подкачки гостевой ОС и файл подкачки VMkernel, создаваемый для каждой виртуальной машины при ее включении. Дальше про эти механизмы я расскажу чуть подробнее, здесь же хочу отметить – при включении ВМ создается файл .vswp. Именно в этот файл ESX(i) адресует часть памяти ВМ, если памяти физической не хватает. Как велика эта часть? В наихудшем случае это вся память сверх резерва до hardware memory. Размер файла подкачки как раз такой: «hardware memory» минус reservation. Таким образом, если оставить reservation равным нулю, при включении каждой ВМ создается файл размером с ее оперативную память. Выводов отсюда два:

Q если на хранилище для файлов подкачки (по умолчанию файл подкачки

создается в каталоге ВМ) недостаточно места для создания этого файла – ВМ не включится;

Q если вам необходимо освободить сколько-то места на разделах VMFS,

один из способов – это увеличение reservation для памяти ВМ: чем больше резерв, тем меньше места резервируется под файл .vswp, файл подкачки VMkernel (альтернатива этому – расположение файлов подкачки VMker nel на отдельном хранилище).

Иллюстрация работы механизма распределения ресурсов на примере памяти

Ситуация:

Q сервер, у сервера 16 Гб памяти. Расход памяти на сам ESX(i) как ОС, на накладные расходы опустим для простоты;

Q три ВМ. Каждой выделено по 10 Гб памяти (hardware memory):

•    у ВМ А shares = normal, reservation = 0;

•    у ВМ Б shares = normal, reservation = 5 Гб;

•    у ВМ В shares = high, reservation = 0.

Шаг 1 – рис. 6.8. Большая окружность – память сервера, 16 Гб. Три ВМ под маленькой нагрузкой – А и Б активно используют не более 3 Гб памяти, ВМ В – не более 6 Гб. Ресурсов хватает на всех, поэтому настройки reservation и shares не оказывают влияния на распределение ресурсов.

Рис. 6.8. Иллюстрация использования ресурсов. Шаг 1

Здесь пунктирными окружностями показаны 10 Гб, которые номинально выделены каждой ВМ.

Шаг 2 – рис. 6.9. Нагрузка на ВМ возрастает, и памяти сервера на всех уже не хватает. ESX(i) начинает рассчитывать доли ресурсов.

Шаг 3 – рис. 6.10. Ресурсы памяти разделены в соответствии с reservation и shares. За счет Shares виртуальные машины А и Б имеют право на 4 Гб памяти каждая, а виртуальная машина В – на 8 Гб. Но виртуальной машине Б досталось 5 Гб, так как такое значение имеет настройка reservation для этой ВМ. Оставшиеся 11 Гб делятся между ВМ А и ВМ В с учетом их shares. Всю недостающую память ВМ получают из файлов подкачки.

Рис. 6.9. Иллюстрация использования ресурсов. Шаг 2

Рис. 6.10. Иллюстрация использования ресурсов. Шаг 3

Соображения по поводу использования пулов ресурсов см. в п. 6.1.3 «Рекомендации по настройкам Limit, Reservation и Shares».

Источник: Михеев М. О. Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.