«Hyper-V Hypervisor Logical Processors» — один из важнейших наборов счетчиков для оценки производительности виртуальных машин Hyper-V. Кроме того, это один из немногих наборов, на которые не действуют странности работы таймера в виртуальных машинах. Перед тем, как начать рассматривать данный набор, я напомню, что логические процессоры — это ядра физического процессора и потоки Hyper-Threading (при его наличии), которыми гипервизор управляет как самостоятельными процессорами. Так, двухпроцессорный четврехъядерных сервер без HT имеет восемь логических процессоров, а он же с HT — уже шестнадцать.
Для каждого логического процессора существует свой набор счетчиков. Также вы можете рассмотреть суммарную загрузку всех логических процессоров, выбрав в Performance Monitor в качестве экземпляра логического процессора значение _Total. Рассмотрим же сами счетчики данного набора:
%Guest Run Time
Показывает загрузку логического процессора задачами виртуальной машины. Например, запустив процессороемкую задачу на однопроцессорной ВМ в системе с двумя логическими процессорамми, вы увидите загрузку около 95% на счетчике LP(0), нулевую загрузку на счетчике LP(1) и общую загрузку 47.5% на экземпляре _Total.
%Hypervisor Run Time
Указывает загрузку логического процессора задачами гипервизора. Этот счетчик похож на «% Kernel Run Time» в семействе счетчиков Processor.
%Idle Run Time
Указывает процент времени, в которое логический процессор не занят и ожидает задачи.
%Total Run Time
Суммирует значения «%Guest Run Time» и «% Hypervisor Runtime». Может немного (до 1%) превысить значение 100% — в виду того, что значения слагаемых вычисляется в два разных такта, и за время между ними нагрузка может немного перераспределиться.
%C1 Time
C1 — один из энергосберегающих режимов работы процессора. Значение «%C1 Time» для каждого логического процессора показывает процент времени, когда он находится в энергосберегающем состоянии C1. Для экземпляра _Total счетчик показывает усредненное значение по всем логическим процессорам. (Если вас интересуют энергосберегающие режимы работы Windows, почитайте Processor Power Management in Windows Vista and Windows Server 2008).
%C2 Time
С2 — более жесткий энергосберегающий режим. Данный счетчик аналогичен предыдущему — разница в типе энергосберегающего состояния.
%C3 Time
Соответственно, С3 — самый жесткий энергосберегающий режим. Данный счетчик аналогичен двум предыдущим — разница лишь в типе энергосберегающего состояния.
C1 Transitions / Sec
Показывает, сколько раз в секунду логический процессор переходил в состояние C1.
C2 Transitions / Sec
Аналогичен предыдущему — разница лишь в типе энергосберегающего состояния.
C3 Transitions / Sec
Hardware Interrupts / Sec
Количество аппаратных прерываний, обработанных логическим процессором за секунду. Виртуальным процессорам корневого раздела аппаратные прерывания передаются от соответствующих им логических процессоров в момент получения. Прерывание создает, например, сетевая карта при получении пакета.
Total interrupts / sec
Количество всевозможных прерываний, получаемых логическим процессором. Экземпляр _Total показывает суммарное количество всех прерываний, происходящих в вашей системе за секунду.
Monitor Transition Cost
Cтоимость (время) отправки прерывания от логического процессора до гипервизора. В обычном случае прерывание заставляет систему переходить из пользовательского режима (User mode) в режим ядра (Kernel mode) и наоборот. Для виртуальных сред Hyper-V прерывание переводит систему из режима пользователя или ядра в специальный режим, называемый режимом гипервизора («Hypervisor», иногда также встречается название режима «Virtual Machine Monitor»). Соответственно, чем меньше значение этого счетчика — тем лучше. Счетчик совершенно не показательный в терминах производительности системы, однако помогает сравнить относительную производительность разных процессоров.
Context Switches / sec
Показывает, сколько раз виртуальных процессор был привязан к какому-нибудь логическому процессору. Значение экземпляра _Total покажет полное количество таких привязок. Значения районе тысячи на одну виртуальную машину являются хорошим показателем. Высокое значение вызвано тем, что даже при отсутствии задач процессор будет исполнять инструкции «Halt», производя переключения на другие задачи, ожидающие исполнения.
Scheduler Interrupts / sec
Прерывания, отправляемые планировщиком задач гипервизора от одного логического процессора к другим логическим процессорам с целью анализа их загрузки очередью на выполнение различными виртуальными процессорами. Также данные прерывания могут при необходимости «разбудить» логический процессор, находящийся в энергосберегающем режиме.
Inter-processor interrupts sent /sec
Прерывания, отправляемые от одного процессора другому (в связи с архитектурой кэша, когерентности общей памяти, TLB и так далее). Высокие значения (более 20 на логический процессор) говорят о том, что виртуальная машина ведет операции постраничного чтения/записи.
Inter-processor interrupts /sec
Количество межпроцессорных прерываний, принятых логическим процессором за секунду.
Timer interrupts / sec
Hyper-V поддерживает свой набор таймеров (APIC timer, PM Timer и так далее). Данный счетчик показывает, сколько раз логический процессор прерывался для выполнения прерывания от таймера.
Мы завершили рассмотрение семейства счетчиков, описывающего логические процессоры. Впереди еще два семейства с процессорами виртуальными. Stay tuned.
Мы много писали про тонкости схем лицензирования продуктов Microsoft в виртуальных средах. Вся эта информация доступна и в других местах, при желании вы всегда можете изучать первоисточники — документы, на которые даны ссылки в наших заметках. Если же вы хотите получить обобщённое представление по этой теме, или у вас остались нерешёнными конкретные вопросы — в четверг, 31 июля Microsoft проводит часовой вебкаст под названием «Understanding Microsoft’s Licensing in Virtualized Environments». Мероприятие всемирное, будет проходить на английском языке в восемь утра по тихоокеанскому времени — это семь вечера по Москве. Будут затронуты следующие темы:
Регистрация на вебкаст: https://training.partner.microsoft.com/plc/details.aspx?publisher=12&delivery=248725
Доступ для участников: https://www.livemeeting.com/cc/msevents/join?id=WNS37AAL&role=attend&pw=IKL459
Код доступа: IKL459
Вебкаст проводится по традиционной технологии LiveMeeting. Если вы ещё не принимали участия в таких мероприятиях, рекомендуется заранее проверить свою систему на соответствие системным требованиям и установить клиентское приложение Live Meeting 2007.
Когда Алексей опубликовал вводную заметку о компоненте обмена данными (Data Exchange) из комплекта служб интеграции (Integration Services) Hyper-V, это неожиданно вызвало целый ряд вопросов о том, что же именно можно передавать из родительской системы в ВМ и обратно. Поэтому теперь я собираюсь рассказать об этой возможности подробнее. Официально она называется «Компонент интеграции обмена парами ключ-значение» (Key Value Pair, KVP Exchange Integration Component). Этот компонент реализован в виде службы в гостевой ОС и позволяет передавать некоторую ограниченную информацию из ВМ в родительскую ОС и обратно.
Вначале давайте остановимся только на внутренних (intrinsic) KVP, которые уже существуют по умолчанию в виртуальных машинах с установленными компонентами интеграции. А именно, нам доступны следующие KVP, названия которых довольно понятно описывают их предназначение: FullyQualifiedDomainName, OsName, OsVersion, CSDVersion, OsMajorVersion, OsMinorVersion, OsBuildNumber, OsPlatformID, ServicePackMajor, SuiteMask, ProductType, ProcessorArhitecture.
Для получения текущих значений KVP воспользуемся сценарием PowerShell, а затем рассмотрим, как интерпретировать каждое из них. Сценарий начинается с блока, похожего на функцию. Но это не функция, а фильтр PowerShell, который берет поток XML, называемый в WMI «embedded instance», и конвертирует его в объекты. Чтобы понять, насколько удобен этот маленький фильтр, просто удалите «|Import-CimXml» из последней строки сценария — и увидите XML в необработанном виде.
Как работает сценарий? Давайте на минуту проигнорируем фильтр. Тогда первая строка ($Vm = Get-Wmi...) выглядит вполне обычно: мы получаем объект WMI Msvm_ComputerSystem для ВМ «Server 2008 - Test1». Вторая строка интереснее: мы выполняем ассоциативный запрос (Association query), чтобы получить объект WMI Msvm_KvpExchangeCompoents для этой ВМ. Ассоциации представляют собой вид запросов к WMI, которые следует воспринимать подобно оператору объединения в SQL: «пожалуйста, дайте мне все X, которые соответствуют критерию Y». Третья строка просто берет атрибут GuestIntrinsicExchangeItems объекта Msvm_KvpExchangeCompoents и направляет его по конвейеру на вход фильтра Import-CimXml, описанного выше. А сам фильтр использует запросы XML xpath к каждому узлу «Instance/Property», добавляя его имя и значение к объекту CimObj, а затем возвращает сам объект.
Сценарий PowerShell WMIKVP.ps1
filter Import-CimXml{ $CimXml = [Xml]$_ $CimObj = New-Object -TypeName System.Object foreach ($CimProperty in $CimXml.SelectNodes("/INSTANCE/PROPERTY")) { $CimObj | Add-Member -MemberType NoteProperty -Name $CimProperty.NAME -Value $CimProperty.VALUE } $CimObj}
$Vm = Get-WmiObject -Namespace root\virtualization -Query "Select * From Msvm_ComputerSystem Where ElementName='Server 2008 - Test1'"
$Kvp = Get-WmiObject -Namespace root\virtualization -Query "Associators of {$Vm} Where AssocClass=Msvm_SystemDevice ResultClass=Msvm_KvpExchangeComponent"
$Kvp.GuestIntrinsicExchangeItems | Import-CimXml
Пример вывода сценария WMIKVP.ps1
PS C:\> . 'D:\BlogsDemo\powerShell\Demo\WMIKVP.ps1'
Caption : Data : AUTOBVT-M02LJSS Description : ElementName : Name : FullyQualifiedDomainName Source : 2
Caption : Data : Windows Server (R) 2008 Enterprise Description : ElementName : Name : OSName Source : 2
Caption : Data : 6.0.6001 Description : ElementName : Name : OSVersion Source : 2
Caption : Data : Service Pack 1 Description : ElementName : Name : CSDVersion Source : 2
Caption : Data : 6 Description : ElementName : Name : OSMajorVersion Source : 2
Caption : Data : 0 Description : ElementName : Name : OSMinorVersion Source : 2
Caption : Data : 6001 Description : ElementName : Name : OSBuildNumber Source : 2
Caption : Data : 2 Description : ElementName : Name : OSPlatformId Source : 2
Caption : Data : 1 Description : ElementName : Name : ServicePackMajor Source : 2
Caption : Data : 0 Description : ElementName : Name : ServicePackMinor Source : 2
Caption : Data : 274 Description : ElementName : Name : SuiteMask Source : 2
Caption : Data : 3 Description : ElementName : Name : ProductType Source : 2
Caption : Data : 9 Description : ElementName : Name : ProcessorArchitecture Source : 2
Как же теперь расшифровать полученные значения — такие как SuiteMask? Все эти данные, за исключением «Fully Qualified Domain Name», получаются с помощью функции Windows API GetVersionEx. Но нам интереснее взлянуть на структуру OSVERSIONINFOEX. Она документирует каждое из полученных нами значений. Например, мы получили значение SuiteMask, равное 274 (или 0x112). В соответствии с описанием это значит, что гостевая ОС является изданием Windows Server Enterprise, в ней включена поддержка «Удалённого рабочего стола» (Remote Desktop support) и установлены службы терминалов.
Не секрет, что одним из главных конкурентных преимуществ Hyper-V являются не технические показатели — и даже не цена, а имя производителя. Очевидно ведь, что от решений одного поставщика можно ожидать лучшей совместимости друг с другом и условий поддержки. Однако, в период подготовки к выпуску Hyper-V, а также сразу после выпуска некоторые конкуренты Microsoft намекали, что ясность позиций компании о поддержке своих продуктов в собственных же средах виртуализации оставляет желать лучшего. Сегодня мы можем увидеть, как эта ситуация меняется к лучшему.
Вчера было выпущено руководство по установке и использованию BizTalk Server 2006 R2 в среде виртуализации Hyper-V. Он предназначен для специалистов партнёров и заказчиков, уже имеющих необходимую подготовку и опыт работы с BizTalk. Цель документа — дать им представление о преимуществах и недостатках использования виртуальных сред. Источником материала при написании руководства послужили собственные опыты и тестирование, которые заняли у сотрудников Microsoft полтора месяца. Ожидается, что этот документ будет обновляться с выходом новых версий BizTalk Server. Сегодня руководство затрагивает следующие темы.
Ссылки на рукодство по использованию BizTalk Server 2006 R2 с Hyper-V.
Мы уже обсуждали общие вопросы модели делегирования Authorization Management Framework и Authorization Manager, используемый в Hyper-V. Сейчас пришло время более детально рассмотреть некоторые наиболее насущные вопросы. Большинство заказчиков, которым я рассказываю про модель делегирования в Hyper-V первым делом спрашивают меня, возможно ли делегировать пользователю или группе некоторые права на конкретную виртуальную машину. В Virtual Server 2005 единственным способом предоставления доступа к ограниченному набору ВМ являлось использование NTFS ограничений на конфигурационные файлы, так чтобы пользователи могли работать лишь с теми виртуальными машинами, на которые у них достаточно NTFS прав. Модель, используемая в Hyper-V позволяет настраивать это более гибко.
Одним из фундаментальных терминов Authorization Management Framework является Область (Scope). Что это такое я уже рассказывал, - очевидно, что для задачи делегирования прав на конкретные виртуальные машины следует создать область, содержащую данные машины. Создается область в консоли Authorization Manager.
Далее вам нужно поместить в данную область необходимые виртуальные машины. В некоторых случаях удобно для каждой ВМ создавать отдельную область, - когда вы хотите разным группам пользователей дать доступ к разным пересекающимся наборам ВМ. Иногда удобно виртуальные машины группировать в области по ролям - контроллеры, Exchange серверы, тестовые серверы отделов.
Следующим шагом станет помещение самих виртуальных машин в созданную область. Увы, этот шаг совсем не тривиален, по крайней мере пока у вас не установлен и настроен System Center Virtual Machine Manager 2008. Средств помещения виртуальной машины в заданную область в MMC консоли AzMan нет (в ней вообще не фигурируют сами ВМ), возможностей сделать это из командной строки в версии Hyper-V RC1 я не знаю. Однако, я знаю как это можно сделать через WMI запросы, а значит, это можно сделать и средствами PowerShell. Во вложении к статье вы найдете два скрипта, которые автоматизируют эту задачу. Первый скрипт - Getscope.vbs в качестве параметра требует имя виртуальной машины, а возвращает название области, которой она принадлежит. Если возвращенное значение пустое, значит виртуальная машина принадлежит к области по умолчанию (default scope). Второй скрипт Setscope.vbs в качестве параметров требует имя виртуальной машины и название созданной области, в которую вы хотите поместить виртуальную машину. В результате работы скрипта виртуальная машина переместится в указанную область.
Наиболее сложная часть на этом закончена. Далее потребуется лишь описать Задачи (Tasks) и Роли (Roles) в данной области, и связать роли с доменными пользователями или группами. Об этом я расскажу в следующий раз. Если знатоки PowerShell помогут переписать мои скрипты в виде cmdlet'ов, буду очень признателен.
Мы уже много писали про разные варианты организации дисковой подсистемы в виртуальных машинах. В будущем мы планируем развить тему хранилищ, но уже с точки зрения «родительской» системы. То есть описать подходы к хранению самих файлов виртуальных дисков. А пока что, в качестве вводной темы, приглашаю всех посмотреть завтра вебкаст под названием «Deep Dive into Windows Server 2008 File Services» (глубокое погружение в файловые службы Windows Server 2008). Конечно, предмет этого вебкаста — не только и не столько виртуализация, сколько обзор базовых технологий, так или иначе связанных с хранением данных и появившихся или получивших развитие в Windows Server 2008:
Вебкаст будет проходить завтра, 17 июля, и займёт полтора часа — с 9:30 до 11:00 по тихоокеанскому времени. Это с 20:30 до 22:00 в Москве. Язык проведения — английский, причём ожидается много технической информации: уровень сложности обозначен как 300.
Некоторое время назад мы уже подробно описывали Offline Virtual Machine Servicing Tool. Напомню вкратце, что это бесплатный набор инструментов и документации (так называемый Solution Accelerator), предназначенный для поддержания виртуальных машин в соответствии с требованиями к установке обновлений ПО. В качестве источника обновлений используется либо WSUS, либо System Center Configuration Manager. В случае необходимости, OVMST сам запустит выключенные или приостановленные ВМ, инициирует установку обновлений, а затем вернёт ВМ в исходное состояние.
Недавно была выпущена окончательная версия Offline Virtual Machine Servicing Tool, готовая для промышленной эксплуатации. Для управления виртуальными машинами эта версия OVMST использует только System Center Virtual Machine Manager 2007. Это автоматически означает, что в качестве платформы виртуализации сейчас поддерживается только Virtual Server 2005 R2. Очевидно, что после выхода Virtual Machine Manager 2008 будет выпущено обновление для OVMST, которое добавит возможность использования Hyper-V — а также, возможно, и других платформ, поддерживаемых VMM 2008.
Ссылки на Offline Virtual Machine Servicing Tool
В середине мая для Virtual Server 2005 стало доступно обновление 948515, обеспечившее поддержку новых ОС на «родительском» сервере и в виртуальных машинах. Однако, не все оказалось идеально с данным обновлением. На некоторых системах замечены проблемы с подключением VHD дисков при помощи утилиты VHDMount.exe. Примером проблемы может являться появление ошибки:
The specified operation could not be completed as an unexpected error has occurred.
при выполнении команд vhdmount /m vhd file или vhdmount /p vhd file.
Исследование данных инцидентов показало, что на некоторых системах при установке обновления 948515 не обновляется драйвер «Microsoft Virtual Server Storage Bus». Новый драйвер при этом присутствует в системе, вам лишь необходимо вручную из консоли Device Manager найти данное устройство, уточнить версию драйвера, и в случае, если у вас установлена версия 1.1.594.0, а не 1.1.623.0 вручную его обновить из папки VHDMount инсталляции Virtual Server 2005. Подробнее об этом можно почитать в статье базы знаний 953482.
«Hyper-V Hypervisor» — хороший набор счетчиков для начала оценки производительности вашей системы и получения общей информации о том, что и как работает в Hyper-V. Этот набор содержит следующие счетчики.
Logical Processors
Здесь просто считается количество логических процессоров, которыми являются ядра физического процессора (или потоки — при наличии функции Hyper-Threading). Двухпроцессорный четырехъядерный сервер без HT покажет наличие восьми логических процессоров, при включении HT — шестнадцати логических процессоров. В настоящий момент количество логических процессоров жестко фиксируется при загрузке ОС. В будущем планируется реализовать горячее добавление процессоров, что сделает данный счетчик более динамичным
Partitions
Каждая запущенная виртуальная машина работает в некотором контейнере, иначе называемом разделом (Partition, что иногда «переводится» как «партиция»). Если в данный момент не запущено ни одной ВМ — значение счетчика будет равно единице, поскольку основная ОС (Host, Parent) работает в так называемом «корневом» разделе (Root Partition). При запуске каждой виртуальной машины значение будет увеличиваться на единицу. Таким образом, данный счетчик позволяет отследить динамику количества одновременно используемых виртуальных машин.
Total Pages
Для управления виртуальными машинами гипервизор использует некоторый объем памяти. Таблица трансляции памяти виртуальной машины в физическую память, распределение виртуальных процессоров — все эти данные необходимо где-то хранить. Размер страницы памяти равен 4 КБ. Значение этого счетчика не равно количеству памяти, используемой для поддержки гостевой ОС, В дополнение к нему следует замерить количество памяти, используемое рабочим процессом (worker process, vmwp.exe) и памятью, используемой Vid.
Virtual Processors
После установки роли Hyper-V любые операции как корневого раздела с основной ОС, так и гостевых разделов с виртуальными машинами выполняются на виртуальных процессорах. В вырожденном случае существует по одному виртуальному процессору для каждого логического процессора — когда не запущено ни одной ВМ, все и виртуальные процессоры обслуживают основную ОС в корневом разделе. При запуске виртуальных машин им выделяются виртуальные процессоры. Именно их и считает данный счетчик. Например, двухпроцессорный четырехъядерный сервер без HT с одной запущенной двухпроцессорной виртуальной машиной будет насчитывать десять виртуальных процессоров: по одному для каждого из восьми логических процессоров в корневом разделе плюс два для работы в виртуальной машине.
Monitored Notifications
Корневой раздел Hyper-V постоянно отслеживает запросы на прерывания от гостевых разделов. Например, для передачи данных через сетевую карту виртуальная машина могла бы отправлять по отдельному запросу на передачу каждого пакета — так работают эмулируемые устройства. В случе использования синтетических устройств она отправляет один запрос на начало передачи потока данных — так, чтобы они непрерывно обрабатывались до самого конца потока. Это помогает снизить накладные расходы на виртуализацию. Данный счетчик показывает именно количество таких потоков прерываний от гостевых разделов к корневому в момент времени.
Возвращаясь к счетчику Total Pages, я хотел бы вкратце описать, как гипервизор получает необходимую для создания раздела память. Когда пользователь включает виртуальную машину, Vid посредством драйвера winhv.sys делает гипервызов к гипервизору на создание гостевого раздела. Для создания виртуальных процессоров и буферов т��ансляции TLB гипервизору требуется память, которую он запрашивает у winhv.sys. Winhv.sys находит память и делает гипервызов, выделяя ее на создание раздела. Мы еще встретимся с термином «выделения ресурсов» в описаниях работы счетчиков. Надеюсь, приведенный пример дает начальное понимание того, как это происходит на уровне архитектуры Hyper-V.
Пару дней назад я получил такой вопрос: почему даже после установки вручную окончательной версии Hyper-V, при проверке обновлений через Windows Update всё равно предлагается более старая версия — Hyper-V RC1? А объяснение очень простое: 26 июня Hyper-V RTM выпущен в общий доступ через Microsoft Download Center — но не сразу же был добавлен на Windows Update.
Как и было обещано, на Windows Update Hyper-V RTM появился вчера — восьмого июля. Теперь именно эта версия предлагается в качестве рекомендуемого (Recommended) обновления для всех совместимых изданий Windows Server 2008. Так что можно сказать, что с сегодняшнего дня все предварительные версии устарели окончательно, и больше никаких недоразумений быть не должно.
Следующие несколько заметок этого цикла будут посвящены счетчикам производительности Hyper-V. Сегодня поговорим о них в общем — какие счетчики существуют и когда используются. В дальнейшем мы остановимся на основных наборах счетчиков и сосредоточимся на том, когда и как их использовать.
В бета-версии Hyper-V, вышедшей вместе с Windows Server 2008, различные счетчики Hyper-V не были сгруппированы, а оказались разбросаны — что затрудняло поиск. Начиная с версии RC0 ситуация исправилась — появились наборы счетчиков с очевидным префиксом «Hyper-V». Таким образом, бывший набор счетчиков «Hypervisor» теперь называется «Hyper-V Hypervisor», а все остальные наборы идут вслед за ним. В окончательной версии Hyper-V в систему счетчиков производительности внесены финальные штрихи. Исчез довольно бесполезный набор счетчиков «Hyper-V VMMS Task Manager Summary». Названия некоторых счетчиков были уточнены — например, в основных наборах «Hyper-V Hypervisor…» в названии конкретных счетчиков добавилось «/sec», показывая явно единицу измерения. Некоторые дублируемые счетчики были убраны.
В окончательной версии Hyper-V присутствует 24 набора счетчиков. Перечислю их с кратким описанием.
Hyper-V Hypervisor
Общая информация о гипервизоре и его состоянии.
Hyper-V Hypervisor Logical Processor
Детальная информация о том, что происходит с логическими процессорами.
Hyper-V Hypervisor Partition
Каждая ВМ запущена в своем разделе. Данный набор покажет распределение памяти и процессоров между разделами.
Hyper-V Hypervisor Root Partition
Детальная информация о корневом (родительском) разделе, его ОС, используемыми памяти и процессорами.
Hyper-V Hypervisor Root Virtual Processor
Детальная информация о виртуальных процессорах корневого раздела. Каждый логический процессор представлен виртуальным. Логическим процессором является каждое ядро или HT.
Hyper-V Hypervisor Virtual Processor
Детальная информация о виртуальных процессорах гостевых разделов (виртуальных машин).
Hyper-V Legacy Network Adapter
Информация об эмулируемых сетевых интерфейсах, статистике их использования и потоках данных, проходящих через них.
Hyper-V Virtual Network Adapter
Информация о синтетических сетевых интерфейсах. (Более быстрые устройства, чем эмулируемые, однако требуют установки служб интеграции)
Hyper-V Virtual Switch
Виртуальный коммутатор — может быть ассоциирован с одним из физических сетевых интерфейсов. Каждый эмулируемый или синтетический интерфейс подключается к одному из виртуальных коммутаторов. Данный набор счетчиков дает информацию о работе коммутатора и потоках отсылаемых/принимаемых им данных.
Hyper-V Virtual Switch Port
Информация, похожая на информацию о виртуальном коммутаторе, однако собираемая о конкретном виртуальным сетевом интерфейсе, который использует данный коммутатор.
Hyper-V Virtual IDE Controller
Детальная информация о командах, очередях и скорости потоков данных через виртуальный контроллер IDE.
Hyper-V Virtual Storage Device
Информация об операциях чтения/записи на виртуальных дисках.
Hyper-V Virtual Machine Health Summary
Индикатор состояния виртуальной машины. Имеет два значения: Health Critical & Health OK.
Hyper-V Virtual Machine Summary
Общая информация о всех виртуальных машинах. Какие запущены, стартуют, останавливаются. Дает картину того, чем занята система в данный момент.
Hyper-V Task Manager Detail
Информация и детали о времени операций импорта, экспорта, сохранения виртуальных машин.
Hyper-V Virtual Machine Bus
Информация о работе шины VMBus, прерываниях, скорости обмена информацией.
Hyper-V VM IO APIC
Информация о работе IO APIC в виртуальных машинах.
Hyper-V VM Vid Driver
Детально описывает типы памяти, используемой виртуальными машинами.
Hyper-V VM Vid Message Queue
Дополнительная информация об организации Vid.
Hyper-V VM Vid Numa Node
Информация о том, как Vid управляет разделяемой памятью при помощи технологии NUMA.
Hyper-V VM Vid Partition
Похоже на «Hyper-V Hypervisor Partition», однако гостевые разделы рассматриваются не со стороны гипервизора, а со стороны корневого раздела.
Hyper-V VM Remoting*
Отслеживает количество пикселей, записанных в виртуальный кадровый буфер (frame buffer).
Hyper-V VM Save, Snapshot, and Restore*
Информация о времени операций по созданию и применению снимков, сохранению и загрузке сохраненного состояния.
Hyper-V VM Worker Process Memory Management*
Информация по распределению рабочих процессов в памяти. Рабочий процесс (worker process) создается для каждого эмулированного устройства.
* Последние три набора в настоящий момент существуют, но не реализованы. Возможно, они исчезнут в будущих версиях Hyper-V или произойдут другие изменения.
В следующих заметках мы более подробно остановимся на ключевых наборах «Hyper-V Hypervisor», «Hyper-V Hypervisor Logical Processor», «Hyper-V Hypervisor Virtual Processor» и «Hyper-V Hypervisor Root Virtual Processor», их счетчиках и рекомендациях по использованию.
Думаю, что никто не станет спорить с тем, что основная цель виртуализации — это консолидация серверов. Иными словами, благодаря этой технологии мы можем расширить количество решаемых задач, при этом не увеличивая, а снижая общий объём и запросы необходимого оборудования. Исторически виртуализация развивалась как решение для больших центров обработки данных, где позволяла эффективно использовать ресурсы мощных систем путём совмещения разных типов полезной нагрузки. Этот подход зародился на мейнфреймах ещё до появления архитектуры х86.
Сегодня у виртуализации есть все шансы выйти из центров обработки данных и ступить на новый рынок. Как бы удивительно это не звучало на первый взгляд, я говорю об удалённых филиалах и просто офисах небольших компаний. Действительно, для крупных корпораций эффективность использования ресурсов — это обычно не более чем возможность улучшить финансовые показатели или продемонстрировать заботу об окружающей среде. Но для небольших фирм, экономия — это зачастую то, без чего просто невозможно выжить в условиях конкуренции. И как раз в таком случае виртуализация серверов оказывается как никогда кстати.
Если вы искали способ построения инфраструктуры филиала или небольшого офиса вчера — вам, вероятно, приходилось выбрать один из следующих приоритетов и принести его в жертву двум другим:
Не самый приятный выбор. Согласитесь, что виртуализация позволила бы здорово смягчить описанные негативные эффекты. Теперь это стало вполне реально благодаря сочетанию двух ключевых технологий Windows Server 2008. Речь идёт во-первых о Hyper-V, которая предоставляет экономичное решение виртуализации, а во-вторых о BitLocker, которая позволит сделать это решение весьма защищённым.
Microsoft не хуже нас с вами понимает, что удалённые офисы или необольшие филиалы — часто не тот случай, когда можно расcчитывать на квалифицированный обслуживающий персонал, работающий на постоянной основе. И именно поэтому одно из первых официальных руководств по внедрению Hyper-V посвящено именно этой больной теме — установке автономного защищённого сервера. Этот недавно опубликованный документ не претендует на особую техническую глубину, но представляет собой максимально подробную пошаговую инструкцию по настройке роли Hyper-V вместе с функцией BitLocker. А именно, раскрыты такие темы как
Все шаги, кроме последнего, описаны действительно очень подробно и с картинками. Надо полагать, что выполнить такую инструкцию сможет даже совсем неопытный специалист. В конце концов, вы всегда сможете доработать её под свою ситуацию. Но если сама идея построения инфраструктуры филиалов с использованием виртуализации для вас нова — я уверен, что она заслуживает самого пристального рассмотрения.
Загрузить документ: Windows Server 2008 Hyper-V and BitLocker Drive Encryption.
Меня часто спрашивают, как правильно измерять производительность и нагрузку на виртуальные машины в Hyper-V. Основным источником таких вопросов является... таймер. Давайте рассмотрим первопричину вопросов и попробуем разобраться в ситуации.
Мы уже знаем, что Hyper-V имеет родительскую (основную, root, host в разной терминологии) операционную систему и гостевые (guest) ОС в виртуальных машинах. Родительская ОС работает с большинством устройств напрямую, в ней устанавливаются драйверы; в ней же существуют Virtual Service Providers, которые предоставляют доступ к устройствам для гостевых ОС, через их Virtual Service Clients. В архитектуре процессоров x86, однако, существуют элементы, к которым невозможно предоставлять совместный доступ. Таким образом, они не могут находиться под контролем родительской ОС, и гипервизор эмулирует эти элементы как для родительской, так и для гостевых ОС. Примером такого элемента является таймер, на основе которого, в частности, в компьютере работают часы.
Теперь рассмотрим один из важнейших наборов счетчиков производительности Windows — % Processor Time. Эти счетчики показывают суммарный процент загрузки процессора (есть ли свободные ресурсы для выполнения задач без ожидания в очереди) и процент загрузки процессора конкретным процессом (например, насколько интенсивно Microsoft Word 2009 использует процессор пока я пишу данную заметку для блога).
А теперь рассмотрим эти счетчики одновременно из родительской и гостевой ОС, заметим разницу в показаниях и выясним, кто прав, а кто врёт. Картинка ниже отражает ситуацию, когда в виртуальной машине я запустил программу, генерирующую стопроцентную загрузку процессора. Performance Monitor в гостевой ОС реально показывает загрузку процессора в 100%. Однако, в это же время в родительской ОС я вижу загрузку процессора в 85% в счетчике Hyper-V Hypervisor Guest Run Time для конкретной виртуальной машины.
Итак, кто же прав? Как ни странно — оба. Гостевая ОС использует 100% процессорных ресурсов, предлагаемых ей гипервизором, и все процессорное время, отданное данной гостевой ОС тратится на вычислительную задачу, генерирующую стопроцентную загрузку виртуального процессора.
При этом, счетчик Hyper-V Hypervisor Guest Run Time показывает загруженность физического процессора данной гостевой ОС. Именно в этом и есть отличие. Если вы измеряете нагрузку, которую оказывает ваша виртуальная машина на реальные ресурсы сервера, вам следует пользоваться счетчиками в родительской ОС. Если вас интересует загрузка виртуального процессора неким приложением в гостевой ОС, тогда следует измерять производительность именно в виртуальной машине. Цифры будут разными, так как отражают разные понятия — физический и виртуальный процессор.
Я недавно описывал способ резервного копирования виртуальных машин при помощи утилиты Diskshadow и Hyper-V VSS Writer. Такой подход, на мой взгляд, является оптимальным для использования до выхода System Center Data Protection Manager 2007 Service Pack 1, поддерживающего Hyper-V. Однако реальное использование такого подхода потребует доработки сценариев, а также умения работы с командной строкой и планировщиком задач. Поэтому я ожидал просьб описать сценарии управления Diskshadow. Но вместо этого получил несколько вопросов о возможности выполнения резервного копирования виртуальных машин при помощи Windows Server Backup. Сразу скажу, такая возможность есть. Но это не поддерживаемый на данный момент способ.
Очевидно, что копировать виртуальные машины как обычные файлы можно и без дополнительных настроек. Однако для этого их придется выключать. Если же вы хотите-таки воспользоваться преимуществами службы Volume Shadow Copy и заниматься резервным копированием виртуальных машин при помощи Windows Server Backup (WSB) без их остановки, вам потребуется некоторая подготовка. Возможно, после выхода окончательной версии Hyper-V появится и обновление для WSB, включающее поддержку таких операций по умолчанию, однако пока я таких заявлений не слышал.
Итак, что вам нужно сделать на своем сервере для того, чтобы корректно выполнять операции резервного копирования запущенных виртуальных машин при помощи Windows Server Backup? Потребуется зарегистрировать Hyper-V VSS Writer в Windows Server Backup. Это делается изменением реестра. Следует добавить ветвь реестра и один ключ:
Path
Key or Type
Value
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}
Key
n\a
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier
REG_SZ
Hyper-V
Эти настройки WSB описаны на MSDN. Обратите внимание, что я использую тот же Hyper-V VSS Writer ID, что и в утилите Diskshadow. Идентификатор конкретных VSS Writer на всех серверах всегда одинаков. Способ узнать ID всех доступных VSS Writers описан в предыдущей статье.
Следует помнить, что для корректного выполнения задачи резервного копирования виртуальной машины вам потребуется указать все диски, на которых располагаются ее файлы. То есть, если конфигурация виртуальной машины находится в папке C:\ProgramData\Microsoft\Windows\Hyper-V, а виртуальные диски — в папке D:\VHDs, то вам требуется выбрать для резервного копирования оба диска C:\ и D:\.
У такого подхода на данный момент есть известные проблемы с резервным копированием виртуальных машин, в которых установлен Exchange Server. Единственной рекомендацией в этом случае будет временно приостановить (Pause, Save или Stop) виртуальную машину на время выполнения копирования.
При всей простоте использования Windows Server Backup, я бы все-таки рекомендовал до выхода SCDPM 2007 SP1 пользоваться Diskshadow как единственным поддерживаемым методом.
Совсем недавно мы писали о публичной бета-версии MAP 3.1. И вот вчера этот продукт стал доступен в окончательной версии. Полный список нововведений опубликован в предыдущей заметке — а здесь просто упомняну, что нас, конечно, интересуют две особенности.