Рекомендации по настройке хостов Microsoft Hyper-V

Как человек, работающий с Microsoft Hyper-V со времен Windows Server 2008, я настроил больше хостов Hyper-V, чем могу себе представить. Таким образом, я хотел воспользоваться возможностью, чтобы рассказать о некоторых из лучших практик, которые я перенял на этом пути.

Server Core и Windows Desktop Experience

Одним из наиболее известных передовых методов для хостов Hyper-V является запуск конфигурации Server Core в операционной системе хоста. По большей части я согласен с этой конкретной передовой практикой. В конце концов, аппаратные ресурсы, которые обычно используются для запуска Windows Desktop Experience (GUI), вместо этого могут быть задействованы для размещения виртуальных машин. Кроме того, развертывания Server Core имеют меньшую кодовую базу, чем серверы с полной функциональностью рабочего стола Windows, и поэтому, возможно, более безопасны.

Единственное предостережение, которое я хотел бы сделать в отношении этой конкретной передовой практики, заключается в том, что запуск конфигурации Server Core не является лучшим выбором для каждой организации. Небольшие магазины с двумя или тремя серверами Hyper-V и очень ограниченным ИТ-персоналом могут обнаружить, что использование полной версии рабочего стола Windows упрощает их работу. В моей собственной организации, например, в настоящее время у меня есть три хоста Hyper-V, и на каждом из них я запускаю возможности рабочего стола Windows.

Выделенные сегменты сети

Еще один рекомендуемый метод — избегать объединения всех физических сетевых соединений в одном сетевом адаптере или группе сетевых адаптеров. Определенные типы связи должны быть изолированы для выделенного сетевого адаптера, когда это возможно. Это поможет обеспечить оптимальную производительность и повысить безопасность.

Первый тип трафика, который я рекомендую изолировать в выделенный физический сегмент сети, — это трафик управления хостом. Честно говоря, трафик управления хостом обычно составляет очень небольшой процент от общего сетевого трафика сервера Hyper-V. Тем не менее, я рекомендую изолировать трафик управления хостом просто из соображений безопасности. Всегда полезно по возможности избегать смешивания трафика управления и пользовательского трафика общего назначения.

Это само собой разумеется, но если ваш хост Hyper-V использует что-то другое, кроме хранилища с прямым подключением (например, хранилище с подключением через iSCSI), то чрезвычайно важно как с точки зрения безопасности, так и с точки зрения производительности направлять трафик хранилища через выделенную сеть. сегмент. В моей собственной организации, например, мои серверы Hyper-V подключены к внешним массивам хранения через серию выделенных каналов Ethernet 10 ГБ.

Также важно использовать выделенные сегменты физической сети для трафика отказоустойчивого кластера, трафика динамической миграции и трафика репликации виртуальных машин. Следует признать, что Hyper-V не предоставляет механизма для маршрутизации трафика репликации ВМ по определенному сегменту (по крайней мере, если вы не работаете в кластерной среде), но в зависимости от конфигурации вашего оборудования есть несколько окольных способов форсировать трафик репликации. использовать определенную ссылку. Независимо от цели, сетевой трафик, проходящий по любому из выделенных каналов, в идеале должен быть зашифрован IPSec.

Разделение административных ролей

Говоря о безопасности, я также думаю, что есть что сказать о разделении административных ролей. В небольших организациях совершенно нормально и обычно необходимо, чтобы пара администраторов имела полный доступ ко всем ИТ-ресурсам организации. Однако в более крупных организациях рекомендуется разделить административные обязанности на части. Это удерживает любого отдельного администратора от слишком больших полномочий.

Один из лучших способов добиться этого — создать выделенный домен Active Directory (или даже выделенный лес Active Directory), который используется исключительно для управления узлами Hyper-V организации. Прелесть этого подхода в том, что он позволяет различать администраторов узла Hyper-V и администраторов, которые контролируют рабочие нагрузки, выполняемые на виртуальных машинах.

Несмотря на то, что я единственный администратор в своей организации, я создал выделенный лес Active Directory для своих хостов Hyper-V. Причина, по которой я это сделал, на самом деле не имела ничего общего с безопасностью. Когда-то у меня было значительно больше серверов Hyper-V, чем сейчас. Группировка всех хостов Hyper-V в выделенный домен Active Directory значительно упростила массовое управление этими серверами.

Операционная система хоста

Когда дело доходит до операционной системы хоста серверов Hyper-V, я твердо верю в то, что все должно быть как можно проще. Простые конфигурации, как правило, менее проблематичны. Два моих основных руководящих принципа при настройке операционной системы хоста — сделать ее максимально безопасной и избегать запуска каких-либо приложений или служб, которые мне абсолютно не нужны.

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

Обычно единственная роль, которую вы должны выполнять на узле Hyper-V, — это роль Hyper-V. Сказав это, однако, можно привести аргументы в пользу запуска роли файловых служб и служб хранения, особенно если виртуальные машины хранятся в хранилище с прямым подключением.

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

Еще один сторонний компонент, который следует учитывать, — это программное обеспечение для защиты от вредоносных программ. Есть много людей, даже в Microsoft, которые рекомендуют вам не запускать антивирусное программное обеспечение в операционной системе хоста Hyper-V. Для этого есть две основные причины. Во-первых, при неправильной настройке антивирусное программное обеспечение может повредить Hyper-V. Во-вторых, предполагая, что операционная система хоста действительно используется исключительно как хост Hyper-V, она никогда не должна контактировать с вредоносными программами.

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

И если вы хотите прочитать похожую статью о передовых методах настройки виртуальных машин Hyper-V, ознакомьтесь с ней здесь.