Механизмы перераспределения  ресурсов в ESX(i) – ЧАСТЬ 1

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

6.2.1. CPU

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

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

Q  логические (logical, LCPU). Это ядра физического процессора. Физические

ядра  или, в случае  hypertreading, ядра  логические.  Каждый  LCPU  – это одна очередь команд;

Q  виртуальные (virtual, VCPU). Один vCPU – это один процессор виртуаль-

ной машины.  Напомню,  что процессоров  на виртуальную машину может быть до восьми.

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

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

Q  а вот если эта ВМ с восемью vCPU,  то она задействует  все восемь ядер –

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

Q  на одном ядре может выполняться несколько  vCPU разных виртуальных

машин (рис. 6.23).

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

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

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

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

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

Варианты настройки:

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

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

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

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

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

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

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

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

6.2.2. Memory

Вот у нас есть сервер ESX(i), для простоты один. У него есть сколько-то оперативной памяти для виртуальных машин («Доступная память сервера»), и на нем работает  сколько-то  виртуальных машин. Каждой из виртуальных машин выделено сколько-то  памяти («Настроенная память ВМ»), и каждая какую-то долю от настроенной памяти  потребляет  («Потребляемая память ВМ»).  Что можно рассказать про это?

Несколько общих слов

Доступная память сервера – это все гигабайты памяти сервера минус:

Q  память,  которую  гипервизор  тратит  на себя. ESXi создает в памяти RAM диск для своей работы. ESX отрезает 300–800 Мб для Service Console. Виртуальным  коммутаторам, iSCSI-инициатору и прочим компонентам  также нужны ресурсы для своей работы;

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

процесса  виртуальной машины.  Overhead,  говоря  в терминах  счетчиков нагрузки.  Когда мы создаем  виртуальную машину   и  указываем  для  нее 1 Гб памяти, гипервизор  ей выдает часть или 100% этого гигабайта. И даже в случае стопроцентного выделения еще 100–150 Мб гипервизор  тратит на накладные  расходы. Притом  100–150  Мб накладных  расходов  – это для гигабайта настроенной памяти. Если для виртуальной машины  настроить  64 Гб памяти, накладные  расходы составят примерно 1,5–2 Гб;

Q  кластер  VMware  HA  может  резервировать сколько-то  памяти  под  свои нужды.

Настроенная память ВМ – это тот объем памяти, который мы указываем в настройках  ВМ на вкладке  Hardware. Именно  этот объем видит  гостевая  ОС. Это максимум,  который гостевая ОС может использовать.  Однако гипервизор  может выделить  для ВМ из реальной оперативки  и меньший  объем, чем «показал»  ей памяти. То, что гостю выделено лишь, например, 400 Мб из показанного гигабайта, изнутри  не заметить.  По каким причинам  гипервизор  будет так поступать, поговорим чуть позже.

Потребляемая память ВМ – это сколько  реальной  оперативной памяти  использует  виртуальная машина.  Или,  правильнее  сказать, какой объем реальной памяти выделил ей гипервизор. В  терминах мониторинга это Consumed.

Memory Overcommitment

При  обсуждении  работы  с памятью  разных  гипервизоров часто встречается термин  «Memory  Overcommitment». Притом  нередко  под ним понимаются разные вещи. Мы же под данным словосочетанием будем понимать  ситуацию, когда суммарная  «настроенная память» (столбец  Memory Size) всех включенных  ВМ на сервере больше, чем «доступная  память сервера» (поле Capacity) (рис. 6.25).

На рис. 6.25 вы можете увидеть MO в действии  – на сервере esx1.vm4.ru  до-

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

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий