Resource pool vmware что это

Обновлено: 03.07.2024

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

Limit, shares, reservation - это настройки, которыми мы указываем, как распределять ресурсы. А теперь поговорим о том, благодаря каким механизмам ESX(i) умеет эти настройки претворять в жизнь и как устроено распределение ресурсов сервера между виртуальными машинами.

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

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

- логические (logical, LCPU). Это ядра физического процессора. Физические ядра или, в случае hypertreading, ядра логические. Каждый LCPU - это одна очередь команд;

- виртуальные (virtual, VCPU). Один vCPU - это один процессор виртуальной машины. Напомню, что процессоров на виртуальную машину может быть до восьми.

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

- один vCPU работает на одном LCPU. То есть виртуальная машина с одним виртуальным процессором работает на одном ядре. То есть даже если у вас однопроцессорный восьмиядерный сервер, на котором работает только одна ВМ с одним процессором, - она задействует только одно ядро;

- а вот если эта ВМ с восемью vCPU, то она задействует все восемь ядер -ESX(i) в обязательном порядке разводит по разным ядрам процессоры одной ВМ;

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

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

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

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

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

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

Операционная система ожидает, что все ее процессоры будут работать одновременно. В случае физических серверов так и происходит. Но в случае виртуализации процессоры, видимые гостевой ОС, являются виртуальными процессорами, которыми управляет гипервизор. В частности, гипервизор перераспределяет ресурсы физических процессоров (ядер) между многими процессорами виртуальными. И именно из-за того, что на каждом физическом ядре работают несколько виртуальных процессоров, гипервизору и неудобно выделять такты виртуальным процессорам одной ВМ одновременно (ведь нагрузка на разные физические ядра разная, где-то в данный момент есть свободные такты, где-то нет). А если выделять их не одновременно, то гостевые ОС как минимум будут получать пенальти по производительности, а как максимум - падать в BSOD и Kernel panic.

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

- Any - когда виртуальный процессор этой ВМ работает на каком-то ядре, то на втором логическом ядре этого физического ядра могут работать другие vCPU этой и других виртуальных машин;

- Internal - настройка доступна лишь для многопроцессорных виртуальных машин. Когда ВМ с несколькими vCPU, то они могут работать на разных логических ядрах одного физического ядра. Для ВМ с одним процессором такое значение этой настройки эквивалентно значению None;

- None - когда vCPU этой ВМ начинает выполняться на каком-то физическом ядре, то он захватывает его полностью. Второе логическое ядро простаивает. На данном ядре выполняется только этот один vCPU этой одной ВМ.

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

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

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

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

You can create a child resource pool of any ESXi host, resource pool, or DRS cluster.

About this task

If a host has been added to a cluster, you cannot create child resource pools of that host. If the cluster is enabled for DRS, you can create child resource pools of the cluster.

When you create a child resource pool, you are prompted for resource pool attribute information. The system uses admission control to make sure you cannot allocate resources that are not available.

Prerequisites

The vSphere Web Client is connected to the vCenter Server system.

Procedure

In the vSphere Web Client navigator, select a parent object for the resource pool (a host, another resource pool, or a DRS cluster).
Right-click the object and select New Resource Pool .
Type a name to identify the resource pool.
Specify how to allocate CPU and memory resources.

The CPU resources for your resource pool are the guaranteed physical resources the host reserves for a resource pool. Normally, you accept the default and let the host handle resource allocation.

Specify shares for this resource pool with respect to the parent’s total resources. Sibling resource pools share resources according to their relative share values bounded by the reservation and limit.

Select Low , Normal , or High to specify share values respectively in a 1:2:4 ratio.

Select Custom to give each virtual machine a specific number of shares, which expresses a proportional weight.

Specify a guaranteed CPU or memory allocation for this resource pool. Defaults to 0.

A nonzero reservation is subtracted from the unreserved resources of the parent (host or resource pool). The resources are considered reserved, regardless of whether virtual machines are associated with the resource pool.

When the check box is selected (default), expandable reservations are considered during admission control.

If you power on a virtual machine in this resource pool, and the combined reservations of the virtual machines are larger than the reservation of the resource pool, the resource pool can use resources from its parent or ancestors.

Specify the upper limit for this resource pool’s CPU or memory allocation. You can usually accept the default ( Unlimited ).

To specify a limit, deselect the Unlimited check box.

Results

After you create a resource pool, you can add virtual machines to it. A virtual machine’s shares are relative to other virtual machines (or resource pools) with the same parent resource pool.

Creating Resource Pools

Assume that you have a host that provides 6GHz of CPU and 3GB of memory that must be shared between your marketing and QA departments. You also want to share the resources unevenly, giving one department (QA) a higher priority. This can be accomplished by creating a resource pool for each department and using the Shares attribute to prioritize the allocation of resources.

The example shows how to create a resource pool with the ESXi host as the parent resource.

In the Create Resource Pool dialog box, type a name for the QA department’s resource pool (for example, RP-QA).

Specify Shares of High for the CPU and memory resources of RP-QA.

Create a second resource pool, RP-Marketing.

Leave Shares at Normal for CPU and memory.

If there is resource contention, RP-QA receives 4GHz and 2GB of memory, and RP-Marketing 2GHz and 1GB. Otherwise, they can receive more than this allotment. Those resources are then available to the virtual machines in the respective resource pools.

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

Для оценки потребления ресурсов пула нам пригодятся его закладки Summary и Virtual machines. Давайте взглянем на них.

Закладка Summary, рис. 6.41.

Для процессора здесь отображаются показатели:

- Consumed - текущее потребление ресурсов процессора ВМ этого пула;

Рис. 6.41. Summary для пула ресурсов

- Active - максимальное количество ресурсов, которое может быть выделено для ВМ в этом пуле. Если для пула настроен limit для процессора, то Active не будет больше limit;

- Resource Settings - здесь указаны настройки limit, reservation и shares для этого пула. Самое интересное - это значение Worst case allocation - приблизительный подсчет того, сколько ресурсов будут потреблять все включенные ВМ этого пула, если они начнут потреблять по максимуму из того, что им разрешено. Учитываются настройки limit, reservation и shares на уровне каждой ВМ, а также доступные физические ресурсы сервера и пула ресурсов.

- Private - столько мегабайт выделено для ВМ из физической оперативной памяти, и эти страницы памяти не общие;

- Shared - столько мегабайт памяти выделено для ВМ из физической оперативной памяти, но эти страницы одинаковые хотя бы для двух ВМ, и одинаковые страницы для разных ВМ адресуются в одну страницу в физической памяти. Это экономия памяти механизмом Transparent Memory Page sharing. Обратите внимание: если у трех ВМ одинаково по 10 Мб в памяти, то shared для них будет равно 30 Мб, хотя этими совпадающими данными реально в памяти сервера будет занято 10 Мб;

- Swapped - столько памяти переадресуется в VMkernel swap;

- Ballooned - столько памяти занято баллоном в гостевых ОС;

- Unaccessed - столько памяти сервера не выделено ни для одной ВМ, то есть свободно;

- Active - столько памяти активно задействуется гостевыми ОС;

Обратите внимание: если пул ресурсов создан в DRS-кластере, то он свою долю отсчитывает от всех ресурсов кластера, от суммы мегагерц и мегабайт всех серверов в нем.

Закладка Virtual Machines, рис. 6.42.

Здесь нам доступна разнообразная информация - особо обратите внимание на пункт View Column контекстного меню.

Рис. 6.42. Закладка Virtual Machines

К ресурсам непосредственно относятся столбцы Host CPU, Host Mem и Guest Mem:

- Host CPU - сколько мегагерц гипервизор выделяет ВМ сейчас;

- Host Mem - сколько мегабайт выделяется ВМ сейчас плюс накладные расходы памяти на нее. Величину накладных расходов можно посмотреть на закладке Summary для ВМ ^ Memory Overhead;

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

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

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

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

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 работает, когда ВМ:

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

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

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

Если для какой-то ВМ увеличить или уменьшить 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 равным нулю, при включении каждой ВМ создается файл размером с ее оперативную память. Выводов отсюда два:

- если на хранилище для файлов подкачки (по умолчанию файл подкачки создается в каталоге ВМ) недостаточно места для создания этого файла -ВМ не включится;

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

Читайте также: