Sdílet prostřednictvím

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

  • Článek

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

Многих в этой связи интересует вопрос о максимальных поддерживаемых конфирурациях оборудования для 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

  • Anonymous
    January 01, 2003
    Спасибо! Однако вот здесь "добавлять процессоры имеет смысл только в том случае, когда в этом есть реальная потребность" не все понятно. Помнится, еще году в 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... Спасибо.

  • Anonymous
    January 01, 2003

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

  • Anonymous
    January 01, 2003
    > MSFT говорила, что нонче все серверы (и чуть ли и не все что на них работает) спокойно make use of SMP и прочая. Oily propaganda? Или это я что-то путаю? серверы (то есть, ОС и ПО в ВМ) — да. Но вот накладные расходы на виртуализацию (то есть нагрузка, которую гипервизор сам по себе создаёт на физический сервер) увеличиваются по мере добавления новых виртуальных процессоров в ВМ. Так что зачем же это делать без необходимости? Собственно, пресловутые «проблемы» VMware заключаются в том же самом. Да, делать многопроцессорные машины можно. Да, это эффективно при необходимости масштабировать большие нагрузки. Но если эти нагрузки на самом деле невелики — не стоит добавлять дополнительные виртуальные процессоры просто «чтобы было». Для Hyper-V общей рекомендацией является не превышать число физических ядер количеством виртуальных процессоров более, чем в два раза. Иными словами, N(всех виртуальных процессоров во всех запущенных ВМ) =< N(ядер во всех физических процессорах на сервере виртуализации)×2.

  • Anonymous
    January 01, 2003
    Артем, спасибо за интересную информацию!

  1. Есть ли где-то информация зачем нужно включать IntelXD? Значит ли это, что работа гипервизора невозможна при отключенной защите? Или необходимость определена моделью безопасности?
  2. Есть ли смысл от включения VT Directed I/O?
  3. Вы написали, что "каждая ВМ настроена с одним процессором". Это вопросы организации данной конкретной среды или по каким-то причинам не рекомендуется (бессмысленно) испольовать в виртуальных машинах все или несколько доступных ядер (скажем, просто 2). Спасибо.