Меня часто спрашивают, как правильно измерять производительность и нагрузку на виртуальные машины в 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 показывает загруженность физического процессора данной гостевой ОС. Именно в этом и есть отличие. Если вы измеряете нагрузку, которую оказывает ваша виртуальная машина на реальные ресурсы сервера, вам следует пользоваться счетчиками в родительской ОС. Если вас интересует загрузка виртуального процессора неким приложением в гостевой ОС, тогда следует измерять производительность именно в виртуальной машине. Цифры будут разными, так как отражают разные понятия — физический и виртуальный процессор.
Microsoft обещает выпускать офисные продукты раз в три года. Office 2007 стал доступен volume заказчикам в ноябре 2006 (а сотрудникам летом 2006). Значит через год у нас будет установлен финал 2009.
Ближайшей осенью нас ждет Service Pack 2 для Office 2007, ориентироваться заказчикам сейчас следует на него, а не на еще не вышедший даже в широкое бета тестирование продукт.
Я же всегда сидел на предварительных версиях и ОС, и офис..
Денис, я уточнил, есть жесткое ограничение на 50 снапшотов для VM.
То есть если вам нужны снапшоты, придется написать скрипт, который будет удалять старые.
Так, например, чтобы хранились все старые – раз в месяц, плюс по одному за каждый день последней недели + раз в час за последний день.
На PowerShell делается несложно, нужно лишь оттестировать будет скрипт.
Техническое ограничение сделано как раз из-за того, что диски дифференциальные. Возникают длинные цепочки, которыми сложно управлять.
Увы, быстро сделать инкрементальный образ (не от последнего, а от базового образа) невозможно, – потребуется время на его генерацию, потому и выбраны дифференциальные диски.
Партнерам на откуп отдан SDK, кто-то может (например вы) изменить это значение (в разумных пределах, скажем до 255). Но это выйдет за рамки поддерживаемой конфигурации, так что предлагаемый мной подход со скриптом будет оптимален.
Если напишите скрипт и вам будет его не жалко, можно будет запостить для аудитории, думаю что много кому это интересно.
Вопрос в необходимости и производительности длинных цепочек дифференциальных дисков.
Не уверен, что количество звеньев в цепочке неограничено.
Еще помните, что снимки сохраняются не параллельно, а последлвательно.
про 2009 Word – это серьезно? in next year? )
Еще есть вопрос про производительность. Скажите, насколько для физ.и вирт. машин трудоемок процесс сохранения снимков, к примеру раз в час или чаще даже? Пример: мощний сервер с 4-я ВМ, каждая делает снимок каждые пол часа.
Спасибо, пишу скрипт.
Интересно, с чем связано тех. ограничение, ведь вполне могли одать вопрос на откуп заказчику, т.е. на его дисковые ресурсы.
Мониторинг CPU хоста Hyper-V задача достаточно актуальная, особенно сейчас, в эпоху виртуализации всего и вся .
В статье я сделаю небольшой обзор групп счетчиков производительности CPU, которые созданы специально для мониторинга ЦП в виртуальных средах (все группы имеют префикс Hyper-V Hypervisor …).
Если вам интересны счетчики производительности Windows, рекомендую обратиться к основной статье тематики — Счетчики производительности.
Мониторинг CPU хоста Hyper-V
Актуальные (2008-2016) на сегодняшний день серверные операционные системы Windows изобилуют счетчиками производительности — отдельные группы счетчиков есть как для каждой роли, так и для целых продуктов (например Exchange). Различные вариации счетчиков есть и для отдельных компонентов системы — например для мониторинга показателей CPU существуют целых две группы с разными наборами (Счетчики производительности процессора), при анализе которых, к тому же, всплывают и некоторые нюансы (Изменения счетчиков производительности CPU).
Во-первых, стандартные счетчики групп Процессор (Processor) и Сведения о процессоре (Processor Information) вам не помогут в принципе, потому что они отображают потребление ресурсов CPU только процессами корневой (хостовой) системой. То есть те ресурсы ЦП, которые потребляют гостевые операционные системы (проще говоря сами виртуалки), не будут отражены в показателях. Это действительно проблема, поскольку очень часто стоит элементарная задача узнать сколько ресурсов съедают все виртуалки враз.
Косвенно задача решается суммированием загрузки ЦП всех виртуалок в пересчете на то количество виртуальных процессоров, которые им выделены. Дело это, мягко говоря, неблагодарное.
Однако удобное решение есть. Для роли Hyper-V добавляются несколько новых групп счетчиков CPU:
- Hyper-V Hypervisor Logical Processor — Логический процессор низкоуровневой оболочки Hyper-V
- Hyper-V Hypervisor Root Virtual Processor — Корневой виртуальный процессор низкоуровневой оболочки Hyper-V
- Hyper-V Hypervisor Virtual Processor — Виртуальный процессор низкоуровневой оболочки Hyper-V
Несмотря на очень похожие названия, по сути счетчики предназначены для разных целей. Рассмотрим подробнее каждую группу.
Hyper-V Hypervisor Logical Processor
По большому счету виртуальные машины не волнует (если честно, то не всегда) ресурсы каких ядер или даже процессоров для них используются, им больше важна сама возможность их своевременного получения. Чтобы абстрагировать виртуальную среду от реального оборудования, между физическими и виртуальными процессорами создана логическая прослойка. Этой прослойкой и управляет гипервизор, запрашивая ресурсы реального ЦП и предоставляя их виртуальным процессорам. Как раз для мониторинга этой логической прослойки ЦП и создана группа счетчиков Hyper-V Hypervisor Logical Processor. Каждый логический процессор соответствует ядру/потоку реального процессора.
Вот и получается, что для отслеживания реальной загрузки ЦП мы должны обращаться к показателям загрузки логических процессоров, но не к чему-либо другому. Конкретно для этого нам подойдет счетчик Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time (зеленая линия):
Красная линия на графике — это счетчик Processor Information(_Total)\% Processor Time. Как вы видите, его показания абсолютно бесполезны и не отражают реальной загрузки сервера. Будьте внимательны.
Hyper-V Hypervisor Root Virtual Processor
Переходим к полностью виртуальному представлению, ведь группа счетчиков Hyper-V Hypervisor Root Virtual Processor отвечает за мониторинг показателей производительности ЦП корневого раздела. Корневой раздел — это как раз та хостовая ОС, на которой вы и разворачиваете виртуальные машины.
Но почему бы не отслеживать производительность хоста через известные нам группы счетчиков Processor и Processor Information? В принципе можно, но все-таки правильнее это делать через Hyper-V Hypervisor Root Virtual Processor. Объясняю почему: суть гипервизора в том, что он предоставляет равноправный доступ к ресурсам как хостовому разделу, так и гостевым. То есть ресурсы для виртуальных машин выделяет не хостовый раздел, а именно гипервизор. Это хорошо видно на иллюстрации с официального ресурса 1 :
Такие вот тонкости.
Hyper-V Hypervisor Virtual Processor
В данной группе счетчиков отображается каждый виртуальный процессор (с принадлежностью к ВМ) каждой виртуальной машины на вашем сервере Hyper-V. Виртуальный процессор в данном случае — это эквивалентная одному процессорному ядру (или потоку — при использовании гипертридинга или его аналогов) вычислительная мощность.
Чтобы лучше было понятно дальнейший ход мыслей, хочу привести пример: имеем сервер с одним ЦП, у которого 8 потоков. На этом сервере крутятся 3 виртуальные машины и у каждой из них по 4 виртуальных процессора. Учитывая тот факт, что 1 виртуальный процессор = 1 ядру/потоку реального ЦП, то виртуалки по суммарной мощности вылезают в 1,5 раза из мощности ЦП хоста. Тем не менее, вы запросто можете назначить каждой виртуалке хоть 8 vCPU, чтобы общее количество виртуальных процессоров составило 24 штуки.
Я на своем домашнем Core i7 могу создать с десяток виртуалок, назначить каждой по несколько vCPU так, чтобы их общее количество явно выходило за пределы 8 потоков реального процессора и вот что получится:
Как вы видите, список виртуальных процессоров достаточно внушительный, но реальная загрузка хостового процессора выглядит смешной, поскольку мои виртуальные машины особо не нагружены:
Отслеживать показатели производительности ЦП виртуальных машин через счетчики хоста в принципе удобно в некоторых случаях, но не всегда.
Вывод
Каким же образом гипервизор распределяет нагрузку между ядрами? Есть несколько ключевых моментов:
1. Дело в том, что для каждой конкретной виртуальной машины он не резервирует процессорную мощность, а высвобождает имеющиеся ресурсы только при необходимости;
2. Виртуальный процессор никоим образом не привязан к реальному физическому ядру. Из этого следует, что каждый виртуальный процессор может «размываться» по нескольким физическим ядрам, взяв от каждого какую-либо величину;
3. Также надо отметить, что на данный момент нет никакого способа узнать какой процент мощности от того или иного реального ядра отнимает каждый виртуальный процессор.
Серьезные проблемы у вас начнутся в том случае, если все виртуалки начнут отжирать максимально выделенную им процессорную мощность. По факту ЦП каждой ВМ будет нагружен на 10-15%, а хост ляжет с 95-98% загрузкой ЦП.
История из личного опыта: подобная ситуация у меня как-то была при тестировании виртуального сервера 1С+СУБД и терминального сервера. Все они располагались на одном и том же хосте виртуализации и им было выделено максимальное количество vCPU. Когда на терминалке запустили с десяток толстых клиентов 1С и сымитировали закрытие месяца, то терминалка показывала примерно 60% загрузки, 1С+СУБД всего лишь 40%, но хост лег наглухо — загрузка ЦП стремилась к 100%.
Вывод прост — не размещайте на одном хосте несколько требовательных к производительности виртуальных серверов, лучше разнесите их по разным хостам и разбавьте чем-то не ресурсоемким (например файловыми серверами или контроллерами домена).
По идее на серверах в продакшене нормой будет средняя загрузка не более 60%, но это уже совсем другая история.
Процессорное время является одним из основных аппаратных ресурсов, поэтому мониторинг загрузки процессора крайне важен для стабильной работы сервера. И здесь стоит знать, что мониторинг процессора на серверах Hyper-V отличается от мониторинга обычного сервера приложений. Это связано с особенностями архитектуры гипервизора.
Дело в том, что после установки роли Hyper-V в системе создаются изолированные разделы (партиции, partitions). Для работы виртуальных машин используются гостевые (guest) разделы, сама хостовая ОС работает в отдельной, родительской (root) партиции, а распределением аппаратных ресурсов (процессора, памяти и т.п.) занимается гипервизор, а не операционная система.
Поскольку стандартные счетчики производительности мониторят только состояние хостовой ОС, то их показания могут не отображать реальную нагрузку. Особенно это заметно при мониторинге нагрузки процессора, в связи с чем для мониторинга Hyper-V необходимо использовать специальные счетчики, отличные от счетчиков производительности для мониторинга обычного сервера приложений.
Для мониторинга загрузки процессора в Hyper-V есть три группы счетчиков:
• Hyper-V Hypervisor Logical Processor;
• Hyper-V Hypervisor Virtual Processor;
• Hyper-V Hypervisor Root Virtual Processor.
Hyper-V Hypervisor Logical Processor
Это основная группа счетчиков Hyper-V, которая показывает нагрузку на процессор в привязке к логическим процессорам. Напомню, что под логическим процессором система понимает физические ядра процессора или вычислительные потоки (при использовании Hyper-Threading).
Примечание. Посмотреть количество логических процессоров можно в Task Manager, в разделе Performance. Так в нашем сервере установлено 2 процессора по 4 ядра в каждом (всего 8 физических ядер) и включен Hyper-Threading, что в общей сложности дает 16 логических процессоров.
Hyper-V Hypervisor Logical Processor позволяет выводить как общую нагрузку (_Total), так и по каждому логическому процессору (LP) отдельно. Основные счетчики для мониторинга общей нагрузки, это:
% Guest Run Time — нагрузка на процессор, создаваемая виртуальными машинами;
% Hypervisor Run Time — нагрузка на процессор, создаваемая самим гипервизором, т.е. процент процессорного времени, которое затрачено гипервизором на обслуживание виртуальных машин;
% Total Run Time — общая нагрузка на процессор, представляет из себя сумму двух предыдущих счетчиков.
Если посмотреть на график загрузки и сравнить результат с тем, что нам показывает традиционный счетчик загрузки процессора (% Processor Time), то складывается интересная ситуация. Если по традиционному счетчику загрузка процесора находится в районе 4%, то счетчик гипервизора (% Total Run Time) показывает среднюю нагрузку 40%. Как говорится, почувствуйте разницу 🙂
Hyper-V Hypervisor Virtual Processor
Под виртуальными процессорами понимаются те же ядравычислительные потоки, что и логические процессоры, но с точки зрения гипервизора.
Hyper-V Hypervisor Virtual Processor показывает нагрузку на процессор, создаваемую виртуальными машинами. Виртуальные процессоры (VP) группируются по принадлежности к виртуальным машинам, что позволяет оценить нагрузку, создаваемую каждой отдельной машиной, а общее значение (_Total) показывает суммарную нагрузку, создаваемую гостевыми ОС.
Виртуальные процессоры имеют большое количество различных счетчиков, но основные те же, что и в предыдущем случае:
% Guest Run Time — процент процессорного времени, затраченный виртуальными машинами на собственные задачи, не связанные с гипервизором;
% Hypervisor Run Time — процент процессорного времени, затраченный виртуальными машинами на задачи, связанные с гипервизором;
% Total Run Time — общая нагрузка на процессор, создаваемая виртуальными машинами. Представляет из себя сумму двух предыдущих счетчиков.
Для наглядности графики нагрузки, создаваемой виртуальными машинами.
Hyper-V Hypervisor Root Virtual Processor
Hyper-V Hypervisor Root Virtual Processor содержит такой же набор счетчиков, как и Hyper-V Hypervisor Virtual Processor. Отличие их в том, что Hyper-V Hypervisor Root Virtual Processor содержит счетчики только для хостовой ОС, которая работает в основном разделе (Root partition):
% Guest Run Time — процент процессорного времени, затраченный хостом на задачи, не связанные с гипервизором;
% Hypervisor Run Time — процент процессорного времени, затраченный хостовой системой на обслуживание гипервизора;
% Total Run Time — общая нагрузка на процессор, создаваемая хостовой ОС. Представляет из себя сумму предыдущих счетчиков.
На суммарном графике видно, что если суммировать % Total Run Time для Root Virtual Processor и Virtual Processor, то получим значение % Total Run Time для Logical Processor, а % Total Run Time для Root Virtual Processor примерно совпадает со значением стандартного процессорного счетчика % Processor Time.
Делаем вывод, что на стандартный счетчик процессора % Processor Time ориентироваться не стоит, так как он показывает нагрузку только хостовой системы, без учета виртуальных машин. Наиболее точные результаты по загрузке процессора показывает набор счетчиков Hyper-V Hypervisor Logical Processor, который и нужно использовать для мониторинга нагрузки на серверах Hyper-V.
