Виртуализация: рекомендации ведущих собаководов

Для серверов, у которых нет аппаратных средств удаленного управления рекомендуется один из сетевых интерфейсов оставлять незадействованным в виртуальных сетях, исключительно для задач управления. Это сильно снизит риск ситуации, когда при чрезмерной утилизации или же из-за неправильных настроек сетевого интерфейса пропадает возможность удаленного управления сервером. Сделать это можно либо на этапе инсталляции роли Hyper-V, сняв галочку с одного из сетевых интерфейсов, либо же после инсталляции – удалив виртуальную сеть, привязанную к сетевому интерфейсу, который будет использоваться для управления. Кроме этого, на уровне хоста прямо таки необходимо установить как можно более «свежие» драйверы для сетевых адаптеров. Это нужно для того, чтобы воспользоваться специальными функциями сетевых адаптеров – VLAN, Teaming, TCP Offloading, VMQ (при условии, что сами сетевые адаптеры это поддерживают – как правило, это специализированные серверные сетевые адаптеры).

Сетевые нагрузки

Предположим, что наши три виртуальные машины какое-то время уже поработали, и анализ трафика показал, что две из них не особо сильно нагружают сетевой интерфейс, а вот третья генерирует очень большие объемы трафика. Наилучшим решением будет «выпустить в мир» виртуальную машину, генерирующую большой объем трафика, через отдельный сетевой интерфейс. Для этого можно создать две виртуальные сети типа External: одну – для тех виртуальных машин, которые не нагружают сеть, и отдельную – для третьей виртуальной машины. Кроме этого, можно создавать виртуальную сеть с выходом «наружу», при этом не создавая виртуальный сетевой адаптер в родительской партиции. Делается это с помощью скриптов. В подробности я вдаваться не буду, а просто дам ссылку: blogs.msdn.com/b/robertvi/archive/2008/08/27/howto-create-a-virtual-swich-for-external-without-creating-a-virtual-nic-on-the-root.aspx

iSCSI

Если планируется использовать системы хранения данных с интерфейсом iSCSI – крайне рекомендуется выделить для работы iSCSI отдельный сетевой интерфейс, а то и два – для работы MPIO. Если LUN’ы будут монтироваться в хостовой ОС – то нужно просто оставить один или два интерфейса не привязанными к виртуальным сетям. Если же iSCSI-инициаторы будут работать внутри виртуальных машин – для них нужно создать одну или две отдельных виртуальных сети, которые будут использоваться исключительно для трафика iSCSI.

VLAN-тегирование

VLAN-тегирование (IEEE 802.1q) означает «маркировку» сетевых пакетов специальным маркером (тегом), благодаря которому пакет может быть ассоциирован с определенной виртуальной сетью (VLAN). При этом хосты, принадлежащие к разным VLAN, будут находиться в разных широковещательных доменах, хотя и подключаться физически к одному и тому же оборудованию. Виртуальные сетевые адаптеры в Hyper-V так же поддерживают тегирование VLAN. Для этого нужно зайти в свойства виртуального адаптера в настройках виртуальной машины и прописать там соответствующий VLAN ID.

Активное оборудование

До сих пор мы говорили о сетевых интерфейсах и виртуальных сетевых адаптерах в пределах хоста. Но необходимо так же учитывать и пропускную способность активного оборудования – к примеру, коммутаторов, к которым наши хосты будут подключаться. Простой пример: если имеется 8-портовый коммутатор 1Gbps, и каждый из портов утилизирует весь 1Gbps пропускной способности – то 1Gbps-аплинк физически не сможет пропускать такие объемы трафика, что приведет к падению производительности. Особенно это приходится учитывать при использовании iSCSI – нагрузки там могут быть высоки, а задержки пакетов могут быть достаточно критичны для производительности. Поэтому при использовании iSCSI крайне рекомендуется пускать iSCSI-трафик через отдельные коммутаторы.

Рекомендации для хостовой ОС

Меньший объем обновлений
Меньшая поверхность атаки для потенциальных злоумышленников
Меньшая нагрузка на процессор и память в родительской партиции

Запуск других приложений в хостовой ОС

Запуск в гостевой ОС сторонних (не имеющих отношения к Hyper-V) приложений, а так же установка других серверных ролей помимо Hyper-V может привести к сильному падению производительности, а так же к снижению стабильности. Дело в том, что из-за особенностей архитектуры Hyper-V, все взаимодействие виртуальных машин с устройствами проходит через родительскую партицию. Поэтому высокие нагрузки или «падение в синий экран» в родительской партиции обязательно приведут к падению производительности или просто к «падению» всех запущенных виртуальных машин. Сюда же можно (и нужно) отнести антивирусное ПО. Нужно ли оно вообще на хосте, который не будет заниматься ничем, кроме, собственно, виртуализации – это, конечно, тот еще вопрос. Тем не менее, если антивирус все же установлен – первое, что необходимо сделать – исключить из списка проверки все папки, где могут находиться файлы виртуальных машин. В противном случае, при сканировании может замедлиться производительность, а если в каком-нибудь VHD-файле обнаружится что-то похожее на вирус – то при попытке лечения антивирусный пакет может испортить сам VHD. Подобные случаи наблюдались и с базами MS Exchange, и потому первая рекомендация – не ставить вообще на серверах Exchange файловые антивирусы, а если и ставить – то добавить папки с базами в исключения.

Рекомендации для виртуальных машин

Шаги, которые необходимы предпринять для повышения производительности самих виртуальных машин – зависят от приложений, которые будут на них выполняться. У Microsoft имеются рекомендации (best practices) для каждого из приложений – Exchange, SQL Server, IIS, и других. Аналогичные рекомендации существуют для ПО других вендоров. Здесь я дам лишь общие рекомендации, не зависящие от конкретного ПО. Здесь будет рассказано, почему нужно устанавливать Integration Services в гостевой ОС, как упростить развертывание новых виртуальных машин с помощью библиотеки VHD, и как поддерживать эти VHD в актуальном состоянии с выпуском новых патчей.

📎📎📎📎📎📎📎📎📎📎