Окончательный выпуск Hyper-V и ограничения конфигураций


Конечно, если кого-то интересует производительность, то какие-либо выводы на этот счёт можно делать только после выхода окончательной версии продукта. Иными словами, сейчас наступает самое время проводить нагрузочное тестирование по всем сценариям, какие подскажет вам фантазия.


Многих в этой связи интересует вопрос о максимальных поддерживаемых конфирурациях оборудования для Hyper-V. Эта тема подробно раскрывается в официальной документации — а конкретно, Hyper-V Deployment Guide (Руководстве по развёртыванию Hyper-V). Однако, поскольку этот документ ещё не опубликован, приведу в вольном переводе выдержки из него, касающиеся максимальных конфигураций.


Требования к операционной системе сервера (установленной на физическом оборудовании)



  • Windows Server 2008 Standard x64;

  • Windows Server 2008 Enterprise x64;

  • Windows Server 2008 Datacenter x64.

Ещё раз обращаю ваше внимание на то, что технология Hyper-V доступна только для архитектуры x64. Это не тот случай, когда существует ознакомительная версия для платформы x86 (как с Exchange Server), а также не тот случай, где архитектура Intel Itanum обеспечивает максимально возможную производителность и масштабируемость (как с SQL Server). Hyper-V попросту не существует и никогда не разрабатывался для всех остальных платформ, кроме x64.


Требования к оборудованию (Мы подробно писали о них в заметке «Утилиты для проверки поддержки Hyper-V на вашей системе»)




  • Процессор с поддержкой аппаратной виртуализации — Intel VT или AMD-V;


  • аппаратная защита от выполнения данных (Data Execution Protection, DEP) — Intel XD bit (eXecute Disabls) или AMD NX bit (No eXecute).

Архитектура виртуальных машин




  • 32-битные (x86) или 64-битные (x64) гостевые операционные системы;


  • в разных ВМ могут быть одновременно запущены ОС с разными архитектурами.

Оперативная память




  • Windows Server 2008 Enterprise и Datacenter — до 1 TB физической оперативной памяти на сервере;


  • Windows Server 2008 Standard — до 32 GB физической памяти на сервере, из которых около 31,5 GB можно выделить для всех ВМ;


  • каждая ВМ может использовать до 64 GB оперативной памяти (но не больше, чем выделяется из физической памяти сервера).

Процессоры




  • До 16 логических процессоров на физическом сервере, где логический процессор — ядро или поток при включённом Hyper-Threading. Например,



    • один двухъядерный физический процессор — два логических процессора;


    • один четырёхъядерный физический процессор — четыре логических процессора;


    • два двухъядерных физических процессора — четыре логических процессора;


    • два четырёхъядерных физических процессора — восемь логических процессоров;


    • четыре двухъядерных физических процессора — восемь логических процессоров;


    • четыре двухъядерных физических процессора с Hyper-Threading — шестнадцать логических процессоров;


    • четыре четырёхъядерных физических процессора — шестнадцать логических процессоров и так далее;


    • если в физическом сервере будет установлено больше шестнадцати логических процессоров — система будет работать, но Hyper-V сможет использовать только первые шестнадцать логических процессоров.


  • до четырёх виртуальных процессоров в каждой ВМ.

Сеть




  • До 12 виртуальных сетевых адаптеров в каждой ВМ, из них



    • восемь синтетических сетевых адаптеров и


    • четыре эмулируемых сетевых адаптера.


  • Каждый виртуальный сетевой адаптер может использовать как статический, так и динамический адрес MAC;


  • каждый виртуальный сетевой адаптер имеет встроенную поддержку VLAN и может иметь собственную привязку;


  • неограниченное количество виртуальных коммутаторов;


  • неограниченное количество ВМ, подключённых к каждому виртуальному коммутатору.

Физическая система хранения. Широкая поддержка накопителей, включая




  • хранилища прямого подключения (Direct Attach Storage, DAS) — SATA, eSATA, PATA, SAS, SCSI, USB, IEEE 1394 (FireWire);


  • сети хранения данных (Storage Area Network, SAN) — iSCSI, Fibre Channel, SAS;


  • хранилища, подключённые к сети (Network Attached Storage, NAS).

Виртуальные диски (подробнее смотрите в нашем блоге по метке «Storage»)




  • Динамически расширяемые виртуальные жёсткие диски — тип диска по умолчанию, максимальный размер 2040 GB;


  • виртуальные жёсткие диски фиксированного размера — максимальный размер 2040 GB;


  • диски прямого доступа (Pass-Through) — нет жёстких ограничений, кроме возможностей гостевой ОС.

Виртуальные контроллеры дисков




  • Виртуальные контроллеры IDE



    • до четырёх устройств в каждой ВМ;


    • как минимум одно устройство в каждой ВМ для загрузки гостевой ОС.


  • Виртуальные контроллеры SCSI



    • до четырёх контроллеров в каждой ВМ;


    • до 64 дисков на каждом контроллере;


    • итого до 256 дисков в каждой ВМ.

Виртуальная система хранения




  • Максимальный объём хранилища для каждой ВМ



    • используя виртуальные жёсткие диски — до 512 TB для каждой ВМ;


    • используя диски прямого доступа (Pass-Through) — объём хранилища ВМ ограничен только возможностями гостевой ОС.


  • До 50 снимков (Snapshots) каждой ВМ.


  • Загрузка виртуальных машин возможна только с виртуального контроллера IDE. Однако виртуальные диски, подключённые к этому контроллеру, могут физически находиться на любом доступном Hyper-V хранилище (см. выше).


  • В отличие от физических аналогов, производительность виртуальных дисков и контроллеров IDE и SCSI примерно равна (при установке Служб интеграции в гостевой ОС). Однако, некоторые дополнительные условия могут сделать использование дисков SCSI предпочтительным.

Виртуальные накопители CD/DVD




  • Используют только контроллеры IDE. Учитывая, что для загрузки ВМ необходим как минимум один виртуальный жёсткий диск, подключённый к такому контроллеру, остаётся не более трёх виртуальных приводов CD/DVD в каждой ВМ.


  • Привод CD/DVD с прямым доступом (Pass-Through) — использует накопитель CD/DVD физического сервера, но только в одной ВМ на даном сервере одновременно.


  • Виртуальный привод CD/DVD — позволяет читать образы накопителей в формате ISO. 

Виртуальные последовательные порты (COM)




  • Каждая ВМ поддерживает до двух виртуальных последовательных портов, которые могут быть использованы для связи с локальным или удалённым физическим сервером через именованый канал (named pipe).

Виртуальный привод гибких дисков




  • Один виртуальный привод гибких дисков в каждой ВМ.

Количество виртуальных машин




  • До 128 одновременно запущенных ВМ на физическом сервере;


  • до 512 созданных ВМ на физическом сервере.

 


Приходится признать, что многие из приведённых показателей сегодня выглядят более теоретическими, чем достижимыми в реалистичных сценариях. С чем же можно сравнить производительность Hyper-V на практике? Уверен, что в самом ближайшем будущем нас ждёт много интересных публикаций о результатах нагрузочных тестов с использованием самых разных задач и моделей оборудования.


А прямо сегодня есть такой интересный пример. На одном физическом сервере в восемнадцати виртуальных машинах параллельно запущена установка восемнадцати экземпляров ОС Windows Server 2008 на восемнадцати языках, на которых сегодня доступен Hyper-V. При этом осталось ещё немного ресурсов, и их использовали чтобы дополнительно запустить установку Windows Web Server 2008.



Но самое интересное здесь — конечно, характеристики физического сервера. Возьму на себя смелость охарактеризовать их как весьма средние на сегодня.




  • Два четырёхъядерных процессора Intel Harpertown Processors — всего восемь ядер;


  • 16 GB физической оперативной памяти;


  • выделенный диск для ОС в качестве «Родительского раздела» (Parent Partition);


  • два дополнительных диска SATA в RAID 0 для дистрибутивов и ВМ;


  • каждая ВМ настроена с одним процессором и 640 MB оперативной памяти.

P.S. Алекс работает над серией статей, посвящённых вопросам тестирования производительности Hyper-V. Первая заметка этого цикла уже опубликована под названием «Hyper-V и производительность. Часть 1 — как тестировать?». Следите за нашим блогом, окончательный выпуск Hyper-V ещё не означает, что у нас закончатся темы для обсуждения!

Comments (4)

  1. Exotic Hadron says:

    Спасибо!

    Однако вот здесь "добавлять процессоры имеет смысл только в том случае, когда в этом есть реальная потребность" не все понятно. Помнится, еще году в 2003 не то в мае, не то не помню когда (когда там был питерский лонч 2003 сервер) MSFT говорила, что нонче все серверы (и чуть ли и не все что на них работает) спокойно make use of SMP и прочая. Oily propaganda? Или это я что-то путаю?

    Ну вот, скажем, поставил я MOSS 2007 в Hyper-V и включил 2 процессора. Могу ли я априори сказать, что установка VM с поддержкой нескольких ядер даст результат. Или ответ можно получить только из статистики в каждом конкретном случае?

    Дело в том, что ходят слухи, будто-бы у VMware, например, проблемы с работой VM с несколькими ядрами.

    Ну и, собственно, хочется оценить, насколько такие слухи могут или не могут быть применимы к Hyper-V.

    А проблема в том, что все отзывы, которые я получаю от коллег, говорят, что Hyper-V еще очень сырая технология, а вот альтернативные варианты уже проверены годами.

    А вот у меня получается совсем другой вариант. Непроверенный "сырой" Hyper-V у меня работает очень резво, тогда как все "проверенное" пока оставляет надеяться на лучшее.

    Наверное, у меня такой MSFT-oriented PC...

    Спасибо.

  2. Pronichkin says:

    1. По поводу XD — это обязательное требование. Гипервизор так построен, что просто не будет работать без этой функции.

    2. Насчёт VT-d, насколько я понимаю, Hyper-V пока не поддерживает эту технологию. (Алекс, поправь меня, если я не прав).

    3. Насчёт одного процессора — это просто описание одного конкретного эксперимента. Понятно, что если мы хотим запустить максимальное количество ВМ, нам нужно предоставить каждой как можно меньше ресурсов. В действительности Hyper-V поддерживает до четырёх виртуальных процессоров на виртуальную машину с гостевой ОС Windows Server 2008. Но добавлять процессоры имеет смысл только в том случае, когда в этом есть реальная потребность. Каждый дополнительный виртуальный процессор приносит новые накладные расходы на гипервизор, и если этот процессор реально не загружен — эти расходы оказыаются бесполезными.

  3. Pronichkin says:

    > MSFT говорила, что нонче все серверы (и чуть ли и не все что на них работает) спокойно make use of SMP и прочая. Oily propaganda? Или это я что-то путаю?

    серверы (то есть, ОС и ПО в ВМ) — да. Но вот накладные расходы на виртуализацию (то есть нагрузка, которую гипервизор сам по себе создаёт на физический сервер) увеличиваются по мере добавления новых виртуальных процессоров в ВМ. Так что зачем же это делать без необходимости?

    Собственно, пресловутые «проблемы» VMware заключаются в том же самом. Да, делать многопроцессорные машины можно. Да, это эффективно при необходимости масштабировать большие нагрузки. Но если эти нагрузки на самом деле невелики — не стоит добавлять дополнительные виртуальные процессоры просто «чтобы было».

    Для Hyper-V общей рекомендацией является не превышать число физических ядер количеством виртуальных процессоров более, чем в два раза. Иными словами, N(всех виртуальных процессоров во всех запущенных ВМ) =< N(ядер во всех физических процессорах на сервере виртуализации)×2.

  4. Exotic Hadron says:

    Артем, спасибо за интересную информацию!

    1. Есть ли где-то информация зачем нужно включать IntelXD? Значит ли это, что работа гипервизора невозможна при отключенной защите? Или необходимость определена моделью безопасности?

    2. Есть ли смысл от включения VT Directed I/O?

    3. Вы написали, что "каждая ВМ настроена с одним процессором". Это вопросы организации данной конкретной среды или по каким-то причинам не рекомендуется (бессмысленно) испольовать в виртуальных машинах все или несколько доступных ядер (скажем, просто 2).

    Спасибо.

Skip to main content