Поделиться через

Пулы ресурсов Hyper-V в Windows Server 2012: Теория

  • Статья

О стандарте и его терминах

Терминология пулов ресурсов описана в стандарте  DMTF DSP1041. Данный стандарт определяет правила разделения ресурсов узла между виртуальными машинами. Согласно данному стандарту вводятся следующие определения:

  • Тип ресурса (resource type): обобщенная классификация типов ресурсов. Примеры: процессор, память, сетевой интерфейс.
  • Предоставленный ресурс (allocated resource): (аппаратный или эмулируемый) ресурс эксклюзивно, или разделяемо предоставленный в результате запроса.
  • Пул ресурсов (resource pool): абстрактное представление наборов ресурсов узла, выделяемых клиентам по запросу.
  • Корневой пул ресурсов (primordial resource pool): пул ресурсов определенного типа, не имеющий родительского пула, агрегирующий все ресурсы данного типа на узле.
  • Дочерний пул ресурсов (child resource pool): абстрактное подмножество корневого пула ресурсов, не содержащее никаких физических ресурсов, но позволяющее произвести подсчет потребляемых ресурсов, выделенных на основе запросов.
    Для каждого типа ресурса существует только один корневой пул, и может быть создано любое количество дочерних пулов.
  • Выделенный ресурс (dedicated virtual resource): виртуальный ресурс, эксклюзивно предоставленный клиенту (виртуальной машине) или группе клиентов, и не может быть совместно использован другими клиентами/группами.

Первая версия стандарта была принята DMTF более пяти лет назад. Изначально она разрабатывалась совместно IBM и VMware, к которым в версии 1.1 подключилась масса компаний. Понятие пула ресурсов, описываемое стандартом, совсем не похоже на то, что термином "resource pool" называет ось зла в своих продуктах. Microsoft же, напротив, реализует пулы ресурсов Hyper-V в Windows Server 2012 максимально близко к стандарту. Так что, если в процессе чтения описания, вас будет мучать идея, что это не пулы ресурсов, а некая пародия, то вы переели каких-то сфер, которые не следуют стандартам, городя свой огород. То, что там называют пулами ресурсов Microsoft предоставляет средствами VMM, речь об этом пойдёт в другой раз.

Реализация Microsoft в Windows Server 2012

Итак, Hyper-V в Windows Server 2012 вводит понятие пулов ресурсов - возможность измерить потребление различных типов ресурсов одной или несколькими виртуальными машинами. Управление ресурсными пулами требует от вас базовых знаний PowerShell или же использования VMM. В RTM версии Windows Server 2012 поддерживаются восемь типов пулов ресурсов, соответственно, при установке роли Hyper-V мы можем ожидать наличия восьми корневых (primordial) пулов ресурсов, которые всегда есть в системе. Увидеть список существующих в системе пулов можно, выполнив командлет Get-VMResourcePool:
 
http://virtualization.su/img/Resource_pools_01.png

Пулы ресурсов призваны измерять потребление виртуальными машинами тех или иных ресурсов. Это необходимо для Chargeback и биллинга. Пулы ресурсов оперируют абсолютными значениями потребленных ресурсов. Значения аккумулируют статистику от начала измерения или последнего сброса статистики, до текущего момента или остановки измерения. Глобально восемь типов пулов ресурсов (ResourcePoolType) подразделяются на четыре категории: процессор, память, сеть и дисковые ресурсы. К последним мы относим сразу четыре корневых пула: VHD, VFD, FibreChannelPort и FibreChannelConnection. Рассмотрим подробнее, как измеряются потребляемые ресурсы в том или ином пуле, а после уже поговорим о том, как создавать дочерние пулы, предоставлять виртуальным машинам ресурсы из конкретных пулов и включать измерение ресурсов для той или иной машины. Основные пулы:

  • Процессор (Processor): Измеряет потребленные ресурсы процессора в мегагерцах. Может показаться странным, почему в мегагерцах, а не процентах или попугаях. Но в действительности, физические процессоры бывают разными, машины могут иметь несколько виртуальных процессоров, машины могут переезжать между узлами с разными процессорами, и так далее. Общим для любых процессоров в аспекте измерения является частота. Рассмотрим простой пример. Виртуальная машина имеет два процессора. На одном физическом узле стоят 3ГГц процессоры, на втором узле процессоры с частотой в 1ГГц. Виртуальная машина один час работала на первом узле и имела загруженность в 25%, после чего была перемещена на второй узел, где (в виду меньшей частоты физических процессоров) была в течении двух часов загружена на 50%. Сколько потребила виртуальная машина ресурсов процессоров на двух узлах за эти три часа? На первом узле двухпроцессорная машина потребляла 25% от 3ГГц в течении 1 часа: 2 * 3ГГц * 0.25 * 1час = 1.5 гигагерц-часов. На втором узле двухпроцессорная машина потребляла 50% от 1ГГц в течении 2 часов: 2 * 1ГГц * 0.50 * 2 = 2 гигагерц-часа. Итого за три часа измерения она потребила 3.5 гигагерц-часов. Именно за это значение и будет платить владелец машины, в случае, если нам необходимо Chargeback решение
  • Память (Memory): Позволяет измерять минимальное (minimum), среднее (average) и максимальное (maximum) использование памяти виртуальной машиной в мегабайтах. Очевидно, что минимальное значение, равное нулю в то время, когда машина выключена, нам не интересно, равно как и среднее значение за время простоя машины, мы считаем значения только в то время, пока машина работает. Наиболее полезным является среднее значение, где использование памяти будет рассчитываться исходя из статистики в гигабайт-часах.
  • Сеть (Network): Позволяет измерять трафик виртуальной машины в мегабайтах. Существует возможность разделять трафик входящий и исходящий. При помощи правил, которые создаются командлетом Add-VMNetworkAdapterAcl с параметром –Action Meter и определением IP сетей посредством -RemoteIPAddress, нам дана возможность настроить измерение не для всего трафика, а лишь для его части. Можно создать несколько правил. Правила, считающие внутренний трафик, например, уходящий на адреса 10.0.0.0/8 будем тарифицировать очень дешево, как локальный, определяя его через отдельное правило, созданной командлетом, указанным выше. А весь остальной трафик, попадающий под определение *.*, но не попадающий в остальные правила, будем считать трафиком внешним и тарифицировать, как более дорогой.
  • Диск (Storage): Сюда попадают сразу четыре типа измеряемых ресурсных пулов. Все результаты - в мегабайтах. Тут мы можем посчитать общее предоставленное (а не используемое внутри VHD) пространство. Увы, для динамического диска с максимальным размером в 100ГБ и текущим используемым пространством в 30ГБ я получу такой же результат в 100ГБ, как и для фиксированного диска. Если мой диск, однако, имеет снапшоты, то размер снапшотов для динамических дисков учитывается динамически. То есть 100ГБ диск, где использовалось 30ГБ плюс снапшот, в котором отличий на 20ГБ тарифицируется в 120ГБ. Для фиксированных дисков дочерние также являются фиксированными, так что каждый снапшот будет потреблять полный размер диска, и в ситуации выше тарифицировано будет уже 200ГБ. Тут мы не измеряем Pass-through диски и диски, подключенные по iSCSI. Для дисков, презентованных через Fibre Channel есть отдельный тип пула ресурсов.

Использование пулов ресурсов как абстракции

Кроме того, что пулы ресурсов помогают определить количество потребленных виртуальными машинами ресурсов, для которых включено измерение, они также помогают нам несколько абстрагироваться в настройке виртуальной машины от настроек сервера виртуализации. Хорошим примером будет использование виртуальной машиной сетевых коммутаторов. В традиционной схеме при миграции машины между узлами мы требуем, чтобы на всех узлах существовали одинаково названные виртуальные коммутаторы Hyper-V, к которым будет подключены сетевые адаптеры машины. В противном случае, мы не сможем произвести миграцию. Наличие пулов, позволяет указать для сетевого интерфейса машины, к какому пулу она принадлежит, без указания имени виртуального сетевого коммутатора. При наличии такого пула на другом узле машина станет работать с сетевым коммутатором того пула, вне зависимости от его имени. Если сетевые ресурсы машины принадлежат лишь к корневому пулу, который существует всегда и везде, то нам вообще не принципиально название сетевого коммутатора, конечно, при условии, что он один на узле.