Настройка процессоров в hyper v
Рекомендации по оборудованию для серверов под управлением Hyper-V, как правило, похожи на те, которые являются невиртуализованными серверами, но серверы с Hyper-V могут демонстрировать увеличение загрузки ЦП, потребляют больше памяти и требуют большей пропускной способности ввода-вывода в связи с консолидацией серверов.
Процессоры
Hyper-V в Windows Server 2016 представляет логические процессоры как один или несколько виртуальных процессоров для каждой активной виртуальной машины. Hyper-V теперь требует процессоров, поддерживающих технологии преобразования адресов второго уровня (SLAT), такие как расширенные таблицы страниц (EPT) или таблицы вложенных страниц (НПТ).
Cache
Hyper-V может выиграть от больших кэшей процессора, особенно для нагрузок с большим рабочим набором в памяти и в конфигурациях виртуальных машин, в которых отношение виртуальных процессоров к логическим процессорам велико.
Память
Физическому серверу требуется достаточно памяти для корневого и дочернего разделов. Корневой разделу требуется память для эффективного выполнения операций ввода-вывода от имени виртуальных машин и операций, таких как моментальный снимок виртуальной машины. Hyper-V обеспечивает достаточный объем доступной памяти для корневого раздела и позволяет назначить оставшийся объем памяти дочерним секциям. Размеры дочерних секций должны быть в зависимости от потребностей ожидаемой нагрузки для каждой виртуальной машины.
Хранилище
Оборудование хранилища должно иметь достаточную пропускную способность ввода-вывода и емкость для удовлетворения текущих и будущих потребностей виртуальных машин, размещенных на физическом сервере. Эти требования следует учитывать при выборе контроллеров и дисков хранилища и выборе конфигурации RAID. Размещение виртуальных машин с ресурсоемкими рабочими нагрузками на разных физических дисках может повысить общую производительность. Например, если четыре виртуальные машины используют один диск и активно используют его, каждая виртуальная машина может выдавать только 25% пропускной способности этого диска.
Виртуальные процессоры
Hyper-V в Windows Server 2016 поддерживает не более 240 виртуальных процессоров на каждую виртуальную машину. Виртуальные машины, для которых используются нагрузки, не требующие интенсивного использования ЦП, должны быть настроены на использование одного виртуального процессора. Это обусловлено дополнительными издержками, связанными с несколькими виртуальными процессорами, например дополнительными затратами на синхронизацию в гостевой операционной системе.
Увеличьте число виртуальных процессоров, если для виртуальной машины требуется более одного ЦП при пиковой нагрузке.
Virtual Machine Limit
Этот параметр похож на предыдущий — он так же задается в процентах от доступных виртуальной машине ресурсов и у него есть поле «Percent of total system resources». По умолчанию лимит не задан, и виртуалка при необходимости сможет забрать себе все свободные ресурсы процессора. Задавая значение Virtual Machine Limit мы говорим, что виртуальная машина не при каких условиях не должна использовать больше процессорных ресурсов, чем ей разрешено. Назначение этого параметра одно – ограничить «аппетиты» виртуальной машины, если на ней используются тяжелые, нагружающие процессор приложения.
Лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 4 процессорами и установлен лимит 50% — то она получит четыре виртуальных процессора, каждый из которых ограничивается 50%.
Обратите внимание, что в отличие от резервирования лимит задается жестко. Если Virtual Machine Limit равен 50% — виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено.
Обнаружение топологии ЦП
При запуске Кпуграупс с помощью Жеткпутопологи возвращаются сведения о текущей системе, как показано ниже, включая индекс LP, узел NUMA, к которому принадлежит LP, идентификатор пакета и ядра, а также индекс КОРНЕВого президента.
В следующем примере показана система с двумя сокетами ЦП и узлами NUMA, всего 32 LPs и включенной многопоточностью и настроенной для включения Минрут с 8 корневым ВПС, 4 из каждого узла NUMA. LPs с корневым ВПС имеет Рутвпиндекс > = 0; LPs с Рутвпиндекс из-1 недоступен для корневого раздела, но по-прежнему управляется гипервизором и запускает гостевой ВПС в соответствии с другими параметрами конфигурации.
Пример 6. Печать идентификаторов групп ЦП для всех виртуальных машин на узле
Relative Weight
Третий параметр, Relative Weight, представляет из себя безразмерную величину и может варьироваться в пределах от 0 до 10000. По умолчанию равен 100.
С помощью Relative Weight мы можем задать приоритет виртуальной машины при распределении ресурсов. До тех пор, пока у сервера имеются свободные системные ресурсы – значение Relative Weight не имеет особого значения. Будь у машины вес хоть 100, хоть 10000 – на ее работе это никак не отразится. Но как только ресурсы сервера подходят к концу — начинается самое интересное. Если виртуальные машины имеют одинаковый вес (к примеру, у всех 100), то каждая из них получит равную долю процессорного ресура. Если же у одной или нескольких виртуальных машин Relative Weight выше – это значит, что они получат больше процессорного ресурса, чем остальные. Причем, чем больше вес, тем выше приоритет и тем больше ресурсов может получить виртуальная машина.
Таким образом Relative Weight позволяет разделять виртуальные машины на более и менее критичные, при этом не боясь, что какая-то из них откажется запускаться из за отсутствия ресурсов.
Важный момент. Relative Weight не дает гарантий, что виртуальная машина в нужный момент получит необходимое ей количество процессорных ресурсов. Если какие-то из виртуальных машин являются особо критичными – лучше использовать Virtual Machine Reserve, который гарантирует выделение ресурсов.
В заключение скажу, что Hyper-V достаточно гибко распределяет процессорное время между виртуалками, поэтому дополнительные настройки не стоит трогать без крайней необходимости. И еще, все вышенаписаное относится как к Windows Server 2012, так и к Server 2008R2, по крайней мере серьезных отличий я не заметил.
В предыдущей статье был слегка затронут вопрос распределения процессорной мощности между виртуальными машинами. Как мне кажется, тема эта достаточно интересная и заслуживающая внимания. Поэтому сегодня мы попробуем детально разобраться в том, как происходит распределение физических ресурсов процессора, а также покрутим все имеющиеся настройки виртуальных процессоров и выясним, для чего они нужны и как работают.
В качестве подопытного возьмем сервер с двумя шестиядерными процессорами Xeon, что с учетом Hyper-threading дает нам 24 виртуальных процессора. Операционная система — Windows Server 2012.
Открываем оснастку Hyper-V Manager и заходим в настройки виртуальной машины, на вкладку Processor. Обратите внимание на параметр Percent of total system resources — он показывает, какой процент от общей процессорной мощности выделен конкретно этой виртуальной машине. В нашем случае это 1/24 = 4% . Если выделить машине второй процессор, то получим 8%, третий — 12% и т.д. Таким способом мы управляем распределением процессорных ресурсов между виртуальными машинами.
Надо понимать, что выделенные одной машине виртуальные процессоры могут параллельно использоваться и другими машинами. При наличии свободных ресурсов система динамически распределяет их между виртуальными машинами в зависимости от нагрузки.
На случай нехватки ресурсов есть дополнительные настройки, объединенные под общим названием Resource control. О них стоит рассказать поподробнее.
Отделение корневого ВПС от гостя ВПС
По умолчанию Hyper-V создаст привилегированный вице-президент на каждом базовом физическом процессоре LP. Эти корневые ВПС строго 1:1 сопоставляются с системой LPs системы и не переносятся, т. е. Каждый привилегированный вице-президент всегда будет выполняться на одном физическом LP. Гостевая ВПС может выполняться в любом доступном LP, а также предоставлять выполнение с правами root ВПС.
Тем не менее, может быть желательно полностью отделить действия привилегированных гостей от гостевых ВПС. Рассмотрим наш пример выше, где мы реализуем виртуальную машину уровня "A" Premium. Чтобы обеспечить ВПС виртуальной машины "A" с наименьшей возможной задержкой и "нарушением" или вариантом планирования, мы хотим запустить их на выделенном наборе LPs и убедиться, что корень не работает на этих LPs.
Это можно сделать с помощью комбинации конфигурации "минрут", которая ограничивает выполнение раздела ОС узла на подмножестве всех системных логических процессоров, а также с одной или несколькими группами ЦП привязаны.
Узел виртуализации можно настроить так, чтобы раздел узла был ограничен определенным LPs, при этом одна или несколько групп ЦП привязаны в остальные LPs. Таким образом, корневые и гостевые разделы могут работать на выделенных ресурсах ЦП и полностью изолированы без использования ЦП.
Дополнительные сведения о конфигурации "минрут" см. в разделе Управление ресурсами ЦП узла Hyper-V.
Virtual Machine Reserve
Этот параметр задает процент ресурсов, который будет зарезервирован за виртуальной машиной. Этот параметр играет роль в ситуации нехватки ресурсов, то есть когда физические процессоры используются на все 100%. В этом случае те из виртуальных машин, у которых задан этот параметр, должны гарантированно получить то, что за ними зарезервировано. По умолчанию Virtual Machine Reserve не задан и имеет значение 0%.
Работает этот параметр следующим образом. Возьмем виртуальную машину, выделим ей 2 виртуальных процессора и установим Virtual Machine Reserve равным 100. Это значит, что от физически имеющихся ресурсов этой виртуальной машине зарезервировано 100 % от 2 ядер, или 8% от общей процессорной мощности. Это значение отображается в поле «Percent of total system resources».
Регулировать резерв можно как через Virtual Machine Reserve, так и изменяя количество виртуальных ядер. Например, те же 8% можно получить при 8 ядрах по 25% каждое.
Резервирование не накладывает жестких ограничений на потребляемые ресурсы. Если одной из виртуальных машин потребуется больше ресурсов – они будут ей предоставлены, даже если все 100% зарезервированы. В Hyper-V свободный процессорный ресурс может легко выделяться виртуальным машинам, и так же легко у них забираться.
Параметр Virtual Machine Reserve вступает в дело только в ситуации нехватки системных ресурсов. Основное его назначение – гарантировать бесперебойную работу особо критичных виртуальных машин.
Выделенная роль сервера
Корневой раздел должен быть выделен для Hyper-V. Выполнение дополнительных ролей сервера на сервере под управлением Hyper-V может негативно сказаться на производительности сервера виртуализации, особенно если они потребляют значительный объем ресурсов ЦП, памяти или ввода-вывода. Минимизация ролей сервера в корневом разделе имеет дополнительные преимущества, такие как уменьшение уязвимой зоны.
Системным администраторам следует тщательно продумать, какое программное обеспечение установлено в корневом разделе, поскольку некоторое программное обеспечение может негативно сказаться на общей производительности сервера с Hyper-V.
Пример 12. Отмена привязки единственной виртуальной машины к группе ЦП и удаление группы
В этом примере мы будем использовать несколько команд для проверки группы ЦП, удаления отдельной виртуальной машины, принадлежащей этой группе, и удаления группы.
Сначала выполним перечисление виртуальных машин в нашей группе.
Мы видим, что этой группе принадлежит только одна виртуальная машина с именем G1. Давайте удалим виртуальную машину G1 из нашей группы, установив для идентификатора группы виртуальной машины значение NULL.
Virtual Machine Reserve
Этот параметр задает процент ресурсов, который будет зарезервирован за виртуальной машиной. Этот параметр играет роль в ситуации нехватки ресурсов, то есть когда физические процессоры используются на все 100%. В этом случае те из виртуальных машин, у которых задан этот параметр, должны гарантированно получить то, что за ними зарезервировано. По умолчанию Virtual Machine Reserve не задан и имеет значение 0%.
Работает этот параметр следующим образом. Возьмем виртуальную машину, выделим ей 2 виртуальных процессора и установим Virtual Machine Reserve равным 100. Это значит, что от физически имеющихся ресурсов этой виртуальной машине зарезервировано 100 % от 2 ядер, или 8% от общей процессорной мощности. Это значение отображается в поле «Percent of total system resources».
Регулировать резерв можно как через Virtual Machine Reserve, так и изменяя количество виртуальных ядер. Например, те же 8% можно получить при 8 ядрах по 25% каждое.
Резервирование не накладывает жестких ограничений на потребляемые ресурсы. Если одной из виртуальных машин потребуется больше ресурсов – они будут ей предоставлены, даже если все 100% зарезервированы. В Hyper-V свободный процессорный ресурс может легко выделяться виртуальным машинам, и так же легко у них забираться.
Параметр Virtual Machine Reserve вступает в дело только в ситуации нехватки системных ресурсов. Основное его назначение – гарантировать бесперебойную работу особо критичных виртуальных машин.
Управление группами ЦП
Управление группами ЦП осуществляется с помощью службы вычислений узлов Hyper-V или HCS. Подробное описание HCS, его женесис, ссылки на API HCS и многое другое можно найти в блоге группы виртуализации Майкрософт, посвященном публикации службы вычислений узла (HCS).
Для создания групп ЦП и управления ими можно использовать только HCS. интерфейсы управления WMI и PowerShell для диспетчера Hyper-V не поддерживают группы ЦП.
Корпорация Майкрософт предоставляет программу командной строки, cpugroups.exe, в центре загрузки Майкрософт , которая использует интерфейс HCS для управления группами ЦП. Эта служебная программа также может отображать топологию ЦП узла.
Пример 3. Печать одной группы ЦП
В этом примере мы будем запрашивать одну группу ЦП, используя GroupId в качестве фильтра.
Virtual Machine Limit
Этот параметр похож на предыдущий — он так же задается в процентах от доступных виртуальной машине ресурсов и у него есть поле «Percent of total system resources». По умолчанию лимит не задан, и виртуалка при необходимости сможет забрать себе все свободные ресурсы процессора. Задавая значение Virtual Machine Limit мы говорим, что виртуальная машина не при каких условиях не должна использовать больше процессорных ресурсов, чем ей разрешено. Назначение этого параметра одно – ограничить «аппетиты» виртуальной машины, если на ней используются тяжелые, нагружающие процессор приложения.
Лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 4 процессорами и установлен лимит 50% — то она получит четыре виртуальных процессора, каждый из которых ограничивается 50%.
Обратите внимание, что в отличие от резервирования лимит задается жестко. Если Virtual Machine Limit равен 50% — виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено.
Статистика ЦП
Hyper-V публикует счетчики производительности, чтобы помочь определить поведение сервера виртуализации и сообщить об использовании ресурсов. стандартный набор инструментов для просмотра счетчиков производительности в Windows включает системный монитор и Logman.exe, которые могут отображать и записывать в журнал счетчики производительности Hyper-V. Имена соответствующих объектов счетчиков начинаются с префикса Hyper-V.
Следует всегда измерять загрузку ЦП физической системы с помощью счетчиков производительности логического процессора гипервизора Hyper-V. Счетчики использования ЦП, которые диспетчер задач и отчет монитора производительности в корневых и дочерних разделах не соответствуют фактическому физическому использованию ЦП. Используйте следующие счетчики производительности для мониторинга производительности:
Логический процессор гипервизора Hyper-V (*) \% всего времени выполнения Общее время без простоя логических процессоров
Логический процессор гипервизора Hyper-V (*) \% времени выполнения гостевой работы Время, затраченное на выполнение циклов на гостевом компьютере или в узле
Логический процессор гипервизора Hyper-V (*) \% времени выполнения низкоуровневой оболочки Время, затраченное на выполнение в низкоуровневой оболочке
Корневой виртуальный процессор гипервизора Hyper-V (*) \ \* ИЗМЕРЯЕТ использование ЦП корневого раздела
Виртуальный процессор гипервизора Hyper-V (*) \ \* ИЗМЕРЯЕТ использование ЦП гостевыми секциями
В предыдущей статье был слегка затронут вопрос распределения процессорной мощности между виртуальными машинами. Как мне кажется, тема эта достаточно интересная и заслуживающая внимания. Поэтому сегодня мы попробуем детально разобраться в том, как происходит распределение физических ресурсов процессора, а также покрутим все имеющиеся настройки виртуальных процессоров и выясним, для чего они нужны и как работают.
В качестве подопытного возьмем сервер с двумя шестиядерными процессорами Xeon, что с учетом Hyper-threading дает нам 24 виртуальных процессора. Операционная система — Windows Server 2012.
Открываем оснастку Hyper-V Manager и заходим в настройки виртуальной машины, на вкладку Processor. Обратите внимание на параметр Percent of total system resources — он показывает, какой процент от общей процессорной мощности выделен конкретно этой виртуальной машине. В нашем случае это 1/24 = 4% . Если выделить машине второй процессор, то получим 8%, третий — 12% и т.д. Таким способом мы управляем распределением процессорных ресурсов между виртуальными машинами.
Надо понимать, что выделенные одной машине виртуальные процессоры могут параллельно использоваться и другими машинами. При наличии свободных ресурсов система динамически распределяет их между виртуальными машинами в зависимости от нагрузки.
На случай нехватки ресурсов есть дополнительные настройки, объединенные под общим названием Resource control. О них стоит рассказать поподробнее.
Пример 11. попытка удаления непустой группы ЦП
Можно удалить только пустые группы ЦП, т. е. группы ЦП без привязанных виртуальных машин. Попытка удалить непустую группу ЦП завершится ошибкой.
Пример 7. Отмена привязки виртуальной машины к группе ЦП
Чтобы удалить виртуальную машину из группы ЦП, присвойте параметру Кпуграупид виртуальной машины значение GUID. Это отменяет привязку виртуальной машины к группе ЦП.
Рекомендации по схеме управления питанием
Виртуализация — это мощное средство, которое полезно при увеличении плотности рабочих нагрузок серверов, уменьшая количество необходимых физических серверов в центре обработки данных, повышая эксплуатационную эффективность и уменьшая затраты на энергопотребление. Управление питанием является критически важным для управления затратами.
В идеальной среде центра обработки данных потребление энергии управляется путем консолидации работы на компьютерах до тех пор, пока они не будут заняты, а затем отключены на бездействующие компьютеры. Если этот подход непрактичен, администраторы могут использовать схемы управления питанием на физических узлах, чтобы гарантировать, что они не потребляют больше энергии, чем необходимо.
Методы управления питанием сервера поставляются с учетом затрат, особенно в том случае, если рабочие нагрузки клиента не являются доверенными для диктовки политики физической инфраструктуры поставщика услуг размещения. Программное обеспечение уровня узла оставляет возможность максимально увеличить пропускную способность и свести к минимуму энергопотребление. В основном на бездействующих машинах это может привести к тому, что физическая инфраструктура завершится с помощью средней мощности, что приведет к тому, что отдельные рабочие нагрузки клиента будут работать медленнее, чем в противном случае.
Windows Server использует виртуализацию в самых разных сценариях. с легко загруженного сервера IIS на умеренную SQL Server в облачный узел с Hyper-V, на котором запущены сотни виртуальных машин на каждом сервере. Каждый из этих сценариев может иметь уникальные требования к оборудованию, программному обеспечению и производительности. по умолчанию сервер Windows использует и рекомендует сбалансированную схему управления питанием, которая позволяет экономить электроэнергию путем масштабирования производительности процессора на основе загрузки цп.
При использовании сбалансированной схемы управления питанием самые высокие состояния питания (и наименьшие задержки ответа в рабочих нагрузках клиента) применяются только в том случае, когда физический узел относительно занят. При значении детерминированного ответа с низкой задержкой для всех рабочих нагрузок клиента следует рассмотреть возможность переключения с сбалансированной схемы управления питанием на высокопроизводительную схему управления питанием. Высокопроизводительная схема управления питанием быстро запустит процессоры с максимальной скоростью, эффективно отключив Demand-Based переключение вместе с другими методами управления питанием и оптимизируя производительность по сравнению с энергосбережением.
Для клиентов, которым удовлетворена экономия затрат от сокращения числа физических серверов и требуется обеспечить максимальную производительность для виртуализованных рабочих нагрузок, следует рассмотреть возможность использования высокопроизводительной схемы управления питанием.
Виртуальная топология NUMA
чтобы обеспечить виртуализацию больших рабочих нагрузок, Hyper-V в Windows Server 2016 развернутые ограничения масштабирования виртуальных машин. Одной виртуальной машине можно назначить до 240 виртуальных процессоров и 12 ТБ памяти. При создании таких крупных виртуальных машин, скорее всего, будет использоваться память из нескольких узлов NUMA в основной системе. В такой конфигурации виртуальной машины, если виртуальные процессоры и память не распределяются из одного узла NUMA, рабочие нагрузки могут иметь неплохое снижение производительности из-за невозможности воспользоваться преимуществами оптимизации NUMA.
в Windows Server 2016 Hyper-V представляет виртуальным машинам топологию NUMA. Виртуальная топология NUMA по умолчанию оптимизируется в соответствии с топологией NUMA основного компьютера. Предоставление топологии NUMA виртуальной машине позволяет гостевой операционной системе и установленным в ней приложениям с поддержкой NUMA использовать связанные с NUMA преимущества оптимизаций производительности точно так же, как если бы они работали на физическом компьютере.
Между виртуальной и физической архитектурой NUMA нет различий от перспективы рабочей нагрузки. Когда рабочая нагрузка на виртуальной машине выделяет локальную память для данных и обращается к этим данным на одном и том же узле NUMA, в соответствующей физической системе осуществляется быстрый доступ к локальной памяти. При этом потерь производительности в процессе доступа к удаленной памяти удается избежать. Только приложения, поддерживающие NUMA, могут использовать преимущества Внума.
Microsoft SQL Server является примером приложения, поддерживающего NUMA. Дополнительные сведения см. в разделе Общие сведения о доступе к неоднородной памяти.
Виртуальную архитектуру NUMA и функцию динамической памяти нельзя использовать одновременно. Виртуальная машина, для которой включена динамическая память, имеет только один виртуальный узел NUMA и ей не предоставляется топология NUMA вне зависимости от параметров виртуальной архитектуры NUMA.
Дополнительные сведения о виртуальной архитектуре NUMA см. в статье Общие сведения о виртуальной архитектуре NUMA Hyper-V.
В этой статье описываются ресурсы и элементы управления изоляцией Hyper-V для виртуальных машин. Эти возможности, которые мы будем называть группами ЦП виртуальных машин или просто "группами ЦП", были введены в Windows Server 2016. Группы ЦП позволяют администраторам Hyper-V лучше управлять ресурсами ЦП узла и распределять их между гостевыми виртуальными машинами. С помощью групп ЦП администраторы Hyper-V могут:
Создавайте группы виртуальных машин, каждая из которых имеет различные выделения ресурсов ЦП узла виртуализации, общие для всей группы. Это позволяет администратору узла реализовать классы служб для различных типов виртуальных машин.
Установите ограничения ресурсов ЦП для конкретных групп. Это «групповая политика» задает верхнюю границу для ресурсов ЦП узла, которую может использовать вся группа, фактически обеспечивая требуемый класс службы для этой группы.
Ограничьте запуск группы ЦП только в определенном наборе процессоров основной системы. Это можно использовать для изоляции виртуальных машин, принадлежащих разным группам ЦП, друг от друга.
Пример 10. Печать всех виртуальных машин для одной группы ЦП
Гостевые операционные системы
Hyper-V поддерживает и были настроены для нескольких операционных систем на виртуальной машине. Число виртуальных процессоров, которые поддерживаются на гостевых машинах, зависит от операционной системы на виртуальной машине. Список поддерживаемых гостевых операционных систем см. в статье Обзор Hyper-V.
Использование средства Кпуграупс
Рассмотрим несколько примеров использования средства Кпуграупс.
Параметры командной строки для средства Кпуграупс передаются с использованием только пробелов в качестве разделителей. Символы "/" и "-" не должны воздействовать на нужный параметр командной строки.
Настройка ограничений ЦП на отдельных виртуальных машинах
В дополнение к концу группы, каждая виртуальная машина может также иметь отдельную "заглушку" виртуальной машины. Элементы управления ресурсами ЦП для каждой виртуальной машины, включая ограничение использования ЦП, вес и резервирование, были частью Hyper-V с момента его введения. В сочетании с ограничением группы, ограничение виртуальной машины определяет максимальный объем ЦП, который может получить каждый вице-президент, даже если в группе есть доступные ресурсы ЦП.
Например, администратору узла может потребоваться разместить 10% Cap на виртуальных машинах C. Таким образом, даже если большинство "C" ВПС бездействующие, каждый вице — не более 10%. Без ограничения виртуальной машины "C" виртуальные машины могут рационально производительность по сравнению с уровнями, разрешенными их уровнями.
Установка основных серверных компонентов
Windows Server 2016 возможность установки основных серверных компонентов. Server Core предлагает минимальную среду для размещения выбранного набора ролей сервера, включая Hyper-V. Он занимает меньше места на диске для операционной системы узла, а также меньшей атаки и обслуживания. Поэтому мы настоятельно рекомендуем использовать для серверов виртуализации Hyper-V вариант установки Server Core.
установка Server Core предлагает окно консоли только в том случае, если пользователь вошел в систему, но Hyper-V предоставляет функции удаленного управления, включая Windows PowerShell , поэтому администраторы могут управлять ею удаленно.
Relative Weight
Третий параметр, Relative Weight, представляет из себя безразмерную величину и может варьироваться в пределах от 0 до 10000. По умолчанию равен 100.
С помощью Relative Weight мы можем задать приоритет виртуальной машины при распределении ресурсов. До тех пор, пока у сервера имеются свободные системные ресурсы – значение Relative Weight не имеет особого значения. Будь у машины вес хоть 100, хоть 10000 – на ее работе это никак не отразится. Но как только ресурсы сервера подходят к концу — начинается самое интересное. Если виртуальные машины имеют одинаковый вес (к примеру, у всех 100), то каждая из них получит равную долю процессорного ресура. Если же у одной или нескольких виртуальных машин Relative Weight выше – это значит, что они получат больше процессорного ресурса, чем остальные. Причем, чем больше вес, тем выше приоритет и тем больше ресурсов может получить виртуальная машина.
Таким образом Relative Weight позволяет разделять виртуальные машины на более и менее критичные, при этом не боясь, что какая-то из них откажется запускаться из за отсутствия ресурсов.
Важный момент. Relative Weight не дает гарантий, что виртуальная машина в нужный момент получит необходимое ей количество процессорных ресурсов. Если какие-то из виртуальных машин являются особо критичными – лучше использовать Virtual Machine Reserve, который гарантирует выделение ресурсов.
В заключение скажу, что Hyper-V достаточно гибко распределяет процессорное время между виртуалками, поэтому дополнительные настройки не стоит трогать без крайней необходимости. И еще, все вышенаписаное относится как к Windows Server 2012, так и к Server 2008R2, по крайней мере серьезных отличий я не заметил.
Виртуальная машина Integration Services включает драйверы поддержкой для устройств ввода-вывода, специфичных для Hyper-V, что значительно сокращает нагрузку на ЦП для операций ввода-вывода по сравнению с эмуляциями устройств. Следует установить последнюю версию виртуальной машины Integration Services на каждой поддерживаемой виртуальной машине. Службы уменьшают загрузку ЦП гостевых компьютеров, от бездействующих гостей до интенсивно используемых гостей и улучшают пропускную способность ввода-вывода. Это первый шаг в настройке производительности на сервере с Hyper-V. Список поддерживаемых гостевых операционных систем см. в статье Обзор Hyper-V.
Пример 4. Создание новой группы ЦП
Здесь мы создадим новую группу ЦП, указав идентификатор группы и набор LPs для назначения группе.
Теперь отобразите добавленную группу.
Пример 8. Привязка виртуальной машины к существующей группе ЦП
Здесь мы добавим виртуальную машину в существующую группу ЦП. Обратите внимание, что виртуальная машина не должна быть привязана к существующей группе ЦП, или задание идентификатора группы ЦП завершится ошибкой.
Теперь убедитесь, что виртуальная машина G1 находится в нужной группе ЦП.
Изоляция групп виртуальных машин для конкретных процессоров узла
Администраторам узлов Hyper-V также может потребоваться возможность выделения ресурсов вычислений виртуальной машине. Например, предположим, что администратор хочет предложить привилегированную виртуальную машину "A" с ограничением класса 100%. Эти виртуальные машины уровня "Премиум" также нуждаются в минимальных задержках и невозможности планирования. Это значит, что они не могут быть отпланированы другой виртуальной машиной. Чтобы добиться этого разделения, можно настроить для группы ЦП определенное сопоставление сопоставления LP.
Например, чтобы разместить виртуальную машину "A" на узле в нашем примере, администратор создаст новую группу ЦП и настроит соответствие процессора группы подмножеству LPs узла. Группы B и C будут привязаныы к оставшимся LPs. Администратор может создать одну виртуальную машину в группе A, которая будет иметь эксклюзивный доступ ко всем LPs в группе A, а предположительно более низкие группы B и C будут совместно использовать оставшиеся LPs.
Пример 9. Печать всех виртуальных машин, сгруппированных по идентификатору группы ЦП
Фоновое действие
Минимизация фоновых действий в бездействующих виртуальных машинах освобождает циклы ЦП, которые могут использоваться другими виртуальными машинами. Windows гости обычно используют менее одного процента от одного цп, когда они бездействуют. Ниже приведены некоторые рекомендации по минимизации фонового использования ЦП виртуальной машины.
Установите последнюю версию Integration Services виртуальной машины.
удалите эмулированного сетевого адаптера с помощью диалогового окна "параметры виртуальной машины" (используйте адаптер Microsoft Hyper-V).
Удалите неиспользуемые устройства, такие как компакт-диски и COM-порты, или отключите их носители.
при отсутствии использования и отключении заставки используйте Windows гостевой операционной системы на экране входа.
Проверьте запланированные задачи и службы, которые включены по умолчанию.
Проверьте поставщики трассировки событий Windows, которые включены по умолчанию, запустив logman.exe Query-ETS .
Улучшение серверных приложений для сокращения периодических действий (например, таймеров).
Закройте диспетчер сервера в основной и гостевой операционных системах.
Не выполняйте запуск диспетчера Hyper-V, так как он постоянно обновляет эскиз виртуальной машины.
ниже приведены дополнительные рекомендации по настройке версии клиента Windows на виртуальной машине для снижения общей загрузки цп.
отключите фоновые службы, такие как "упреждающая выборка" и "поиск Windows".
Отключите запланированные задачи, такие как запланированная дефрагментация.
Пример 2. Печать всех групп ЦП на узле
Здесь мы выведем список всех групп ЦП на текущем узле, их идентификатор группы, ограничение на использование ЦП группой и индиЦиес LPs, назначенных этой группе.
Обратите внимание, что допустимые значения закрепления ЦП находятся в диапазоне [0, 65536], и эти значения выражают ограничение группы в процентах (например, 32768 = 50%).
Как работают группы ЦП
Распределение вычислительных ресурсов узлов между группами ЦП обеспечивается гипервизором Hyper-V с помощью вычисленного ограничения группы ЦП. Ограничение группы ЦП — это часть общей мощности ЦП для группы ЦП. Значение ограничения группы зависит от класса группы или назначенного уровня приоритета. Вычисленное ограничение группы можно рассматривать как "количество времени ЦП в LP". Этот бюджет группы является общим, поэтому если активна только одна виртуальная машина, она может использовать выделение ресурсов всей группы.
Ограничение группы ЦП вычисляется как G = n x C, где:
- G — это количество узлов LP, которое необходимо назначить группе
- n — общее число логических процессоров (LPS) в группе.
- В — это максимальное выделение ресурсов ЦП, то есть класс службы, который требуется для группы, выраженный в процентах от общей вычислительной мощности системы.
Например, рассмотрим группу ЦП, настроенную с 4 логическими процессорами (LPs), и ограничение 50%.
- G = n * C
- G = 4 * 50%
- G = 2 время ЦП для всей группы в LP
В этом примере для группы ЦП «G» выделяется 2-е время ЦП.
Обратите внимание, что ограничение группы применяется независимо от числа виртуальных машин или виртуальных процессоров, привязанных к группе, и вне зависимости от состояния (например, завершения работы или запуска) виртуальных машин, назначенных группе ЦП. Таким образом, каждая виртуальная машина, привязанная к одной и той же группе ЦП, будет принимать долю общего количества ресурсов ЦП группы, и это изменится на число виртуальных машин, привязанных к группе ЦП. Таким образом, так как виртуальные машины привязаны к виртуальным машинам или не привязаны к ним из группы ЦП, необходимо перенастроить общее ограничение группы ЦП и настроить его для поддержки требуемого ограничения на виртуальную машину. Администратор узла виртуальной машины или программный уровень управления виртуализацией отвечает за управление групповыми политиками по мере необходимости для достижения требуемого распределения ресурсов ЦП для каждой виртуальной машины.
Пример 5. Установка ограничения для группы ЦП на 50%
Здесь мы установим ограничение для группы ЦП на 50%.
Теперь давайте подтверждаем настройку, отображая только что обновленную группу.
Примеры классов служб
Рассмотрим несколько простых примеров. Чтобы начать с, предположим, что администратор узла Hyper-V хочет поддерживать два уровня обслуживания для гостевых виртуальных машин:
Низкий уровень "C". Мы предоставляем этот уровень 10% от ресурсов для всего узла.
Уровень "B" среднего диапазона. Этот уровень выделяется 50% от ресурсов для всего узла.
На этом этапе мы будем утверждать, что никакие другие элементы управления ресурсами ЦП не используются, например отдельные ограничения виртуальной машины, веса и резервы. Однако отдельные ограничения виртуальной машины важны, так как мы увидим чуть позже.
Для простоты предположим, что каждая виртуальная машина имеет один вице — 1, а наш узел имеет 8 LPs. Начнем с пустого узла.
Чтобы создать уровень "B", узел админстартор устанавливает ограничение для группы на 50%:
- G = n * C
- G = 8 * 50%
- G = 4 время ЦП для всей группы
Администратор узла добавляет одну виртуальную машину "B" уровня. На этом этапе Наша виртуальная машина уровня "B" может использовать не более 50% ресурсов центрального процессора узла или эквивалент 4 LPs в нашем примере системы.
Теперь администратор добавляет вторую виртуальную машину "уровень B". Распределение группы ЦП — равномерно распределяется между всеми виртуальными машинами. В группе б имеется 2 виртуальных ВМ, поэтому каждая виртуальная машина теперь получает половину группы б всего 50%, 25% каждого или эквивалента 2 LPs времени вычислений.
Читайте также: