Network Teaming для серверов виртуализации Hyper-V. Часть третья — практическая, частный случай. Серверы HP

Пару дней назад мы начали разговор о Network Teaming. Сначала поговорили о том, что это вообще такое, зачем может понадобиться и как относятся к этой технологии разные производители и поставщики. Затем рассмотрели общий случай — включение Network Teaming с помощью утилиты, поставляемой производителем сетевых адаптеров. Сегодня речь дошла и до более частного примера.

Ни для кого не секрет, что крупные производители серверов часто используют готовые компоненты, произведённые третьими сторонами. Так, например, HP встраивает в свои серверы сетевые адаптеры Broadcom. С другой стороны, производитель сервера не хочет поддерживать тучу разномастных утилит, которые поставляются с теми или иными компонентами. Вместо этого к серверу обычно прилагается стандартизированный пакет драйверов и утилит, которые выпускаются и поддерживаются именно производителем сервера, а не каждого компонента в отдельности. Такой пакет обычно проще в использовании и установке, а также имеет унифицированный интерфейс. Который одинаков во всей линейке текущих продуктов этого производителя — даже если они собраны из разных компонентов. Минусом здесь является то, что унифицированный пакет может реализовать не все узкоспециальные функции, заложенные производителем в ту или иную модель отдельного компонента. А также очевидно, что унифицированные утилиты выпускаются производителем сервера позднее, чем поставщик компонента выпустит на рынок своё решение.

Тандем HP-Broadcom не стал исключением из этого правила. Ещё недавно единственным способом собрать работающую конфигурацию с использованием Network Teaming на серверах HP было использование набора утилит Broadcom. Стандартная HP Network Configuration Utility вызывала ошибку в работе Hyper-V. Собственно, именно поэтому мы первым делом попробовали и описали способ с использованием инструментов Broadcom — как лучше проверенный временем и имеющий более широкую область применения (ведь он годится не только для серверов HP).

Описанная ситуация c HP Network Configuration Utility продолжалась вплоть до версии 9.20.0.0 (8 Jul 2008), которая поставлялась вместе с ProLiant Support Pack версии 8.10 (A) (9 Jul 2008). Об этом прямо сказано в документе, который называется «Implementing Microsoft Windows Server 2008 Hyper-V on HP ProLiant servers. Integration note».

Windows Server 2008 Hyper-V does not support the Network Configuration Utility (NIC Teaming). Deselect this component before beginning the installation of PSP components.
Currently, there are no plans to add support for NIC teaming.

Справедливости ради надо отметить, что текущая версия данного документа вышла в июле этого года и поэтому описывает именно ProLiant Support Pack версии 8.10. А между тем, сравнительно недавно вышло очень важное обновление интересующих нас компонентов. Это HP Network Configuration Utility версии 9.30.0.0 (7 Aug 2008), которая поставляется вместе с ProLiant Support Pack версии 8.11 (A) (15 Sep 2008). Зачем я так подробно остановился на этом вопросе? К сожалению, в описаниях новых версий не были перечислены все внесённые изменения. И текст документа по интеграции Hyper-V с серверами HP по-прежнему содержит процитированное мной примечание о несовместимости с Network Teaming. Это служит причиной многих досадных недоразумений. Которые, признаться честно, совсем недавно разделяли и мы.

Однако проведённые нами тесты показали, что теперь, с последней версией драйверов и ПО, Hyper-V совершенно корректно работает с Network Teaming при использовании HP Network Configuration Utility. Поэтому сегодня я расскажу о том, как выполнить такую настройку на примере лезвий HP ProLiant BL460c. В них встроены сетевые адаптеры HP NC373i. (Они же в действительности — BroadCom NetXtreme II 5708S, на которых мы тестировали утилиты Broadcom для предыдущей статьи). Как и прежде, я предполагаю, что вы установили Windows Server 2008 x64 вместе со всеми текущими обновлениями. А таже обновили микрокод (Firmware) компонентов сервера до версии не ниже 8.20 и установили последнюю версию ProLiant Support Pack. Кроме того, вы установили роль Hyper-V, но пока не создавали виртуальных коммутаторов.

Сама настройка Network Teaming в данном случае выполняется очень просто — с помощью мастера и принятия настроек по умолчанию. Поэтому я немного усложнил задачу и собираюсь показать, как настроить конфигурацию с использованием VLAN Tagging в соответствии со стандартом IEEE 802.1q. Согласитесь, это будет весьма полезно для тех случаев, когда предстоит использовать всего два сетевых адаптера, которые встроены в сервер. И при этом хотелось бы получить возможность подключать виртуальные машины в разные сегменты сети. Скажу по секрету — именно такая схема практикуется Microsoft IT для организации внутренней инфраструктуры компании, а также хостинга веб-сайтов TechNet и MSDN (то есть, в промышленной эксплуатации).

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

1. Настройка Network Teaming

1.1. Итак, первое, что нам потребуется сделать, это собрать Team из двух имеющихся сетевых адаптеров. Для этого запускаем HP Network Configuration Utility либо из Панели управления, либо из области уведомлений, которая находится справа от панели задач. Выделяем последовательно оба адаптера и нажимаем на кнопку «Team»

По умолчанию новая Network Team получит имя «HP Network Team #1». Для того, чтобы переименовать её, выделите новую Network Team, нажмите кнопку «Properties» и измените значение поля «Team Name». В наших примерах используется имя по умолчанию.

1.2. В принципе, если вам не нужен VLAN Tagging, на этом можно было бы остановиться. Но для целей сегодняшнего эксперимента мы нажмём кнопку «VLAN (802.1q)» и создадим несколько VLAN с понятными описаниями. VLAN ID должны совпадать с теми, которые настроены на вашем сетевом оборудовании.

Один из созданных нами VLAN будет назначен «VLAN по умолчанию». Это значит, что он будет получать все пакеты, для которых явно не указано назначение. Подключать что-либо в такую сеть — не самая удачная идея, поэтому пользоваться ей мы не будем.

Теперь нажмите кнопку «ОК», что приведёт заданные настройки в исполнение. Если вы подключаетесь к серверу удалённо, связь на время переконфигурации пропадёт — но затем должна восстановиться самостоятельно. Конечно, в том случае, если ваши коммутаторы корректно настроены на обработку заданных вам VLAN IDs. (На моих скриншотах ниже это ещё не сделано, поэтому все интерфейсы отображаются как не подключённые к сети).

1.3. Заглянем в список сетевых подключений. Как видим, для каждого из VLAN был создан отдельный сетевой интерфейс. Имя каждого интерфейса состоит из имени VLAN, которые мы создавали на шаге 1.2, и имени Network Team, о которой шла речь на шаге 1.1.

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

2. Создание виртуальных коммутаторов

Эта операция выполняется совершенно стандартным способом — с помощью оснастки Консоли управления Microsoft (MMC) «Hyper-V Management». Тип коммутатора, конечно, везде следует указывать «внешний» (External). Чтобы нигде не запутаться, я предлагаю давать виртуальным коммутаторам точно такие же имена, как и VLAN, которые были заданы на шаге 1.2 и отображаются в именах сетевых интерфейсов.

На всякий случай напоминаю, что если вы собираетесь объединять родительские разделы в кластер для повышения доступности виртуальных машин — то у всех серверов в кластере должны совпадать как VLAN ID, так и имена виртуальных коммутаторов.

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

В нашем случае мы создали по коммутатору для всех интерфейсов, кроме «Default» и «Host Clustering» — причины для этого были озвучены выше. После применения все описанных настроек в родительском разделе образовалось весьма пугающее количество сетевых интерфейсов. Попытаемся разобраться в них, а попутно выставим необходимые привязыки сетевых протоколов и служб.

3. Привязка сетевых служб и протоколов

3.1. Итак, во-первых, мы видим два сетевых интерфейса. Для них поле «Device Name» отображает модель реального оборудования. Это говорит о том, что перед нами — те самые физические сетевые адаптеры, которые на самом деле установлены в нашем сервере. Все остальные интерфейсы — в той или иной степени виртуальны. Физические интерфейсы используются исключительно для того, чтобы сформировать Network Team. А значит, к ним должна быть привязана одна лишь служба под названием «HP Network Configuration Utility». Так оно и есть по умолчанию.

3.2. Следующая группа интерфейсов — это те, у которых в поле «Device Name» указано сначала имя VLAN, а затем имя Network Team. Эти интерфейсы предсталяют в родительском разделе различные VLAN, к которым подключена наша Network Team. Для понимания привязки сетевых служб и протоколов такие интерфейсы имеет смысл мысленно разделить на три подкатегории.

3.2.1. VLAN, к которым должен иметь доступ только родительский раздел. Это самый простой случай. В нашем примере таким VLAN является «Host Clustering». К нему должны быть привязаны во-первых «HP Network Configuration Utility», а во-вторых те протоколы и службы, которые будут использоватья родительским разделом в данном VLAN.

3.2.2. VLAN, к которым должны иметь доступ только виртуальные машины. У нас таких VLAN оказалось два — это «Test» и «Guest Clustering». Для того, чтобы виртуальные машины получили доступ в эти VLAN, мы создали виртуальные коммутаторы на основе соответствующих интерфейсов. А значит — к ним должен быть привязан протокол «Microsoft Virtual Network Switch», а также вездесущая «HP Network Configuration Utility». Родительскому разделу в таких VLAN делать нечего — а значит, никаких других протоколов и служб привязывать к этому интерфейсу не надо.

3.2.3. VLAN, к которым должен иметь доступ как родительский раздел, так и виртуальные машины. Как я уже неоднократно упоминал, таких конфигураций следует избегать. Но мы всё-таки покажем, как она настраивается. В нашем примере таким VLAN будет «Production». Может показаться, что раз этот интерфейс сочетает свойства двух предыдущих типов — к нему должны быть привязаны все перечисленные выше протоколы и службы. Это неверно. Дело в том, что если на основе интерфейса создаётся виртуальный коммутатор — то в случае, если родительскому разделу потребуется доступ в соответствующую сеть, он также будет работать через этот коммутатор. А значит, настройка такого интерфейса повторяет случай из предыдущего пункта. К нему привязаны только «Microsoft Virtual Network Switch Protocol» и «HP Network Configuration Utility».

3.3. Теперь разберёмся с последней группой интерфейсов. Это как раз то, что связывает родительский раздел с виртуальными коммутаторами. В поле «Device Name» такого интерфейса будет отображаться именно название коммутатора. А его мы специально задали таким же, как имя соответствующего VLAN. В результате получается, что от предыдущего типа эти интерфейсы будут отличаться отсутствием имени Network Team в поле «Device Name».

Обратите внимание на то, что протокол «Microsoft Virtual Network Switch» всегда будет отвязан от интерфейсов этого типа. Ведь здесь интерфейс подключён к виртуальному коммутатору, а не коммутатор создан на основе интерфейса. Здесь можно выделить две подкатегории.

3.3.1. VLAN, к которым должны иметь доступ только виртуальные машины. Это, как мы помним по пункту 3.2.2, VLAN с именами «Test» и «Guest Clustering». И здесь всё оказывается очень просто. Поскольку родительскому разделу нечего делать в соответствующих VLAN — использовать данные виртуальные коммутаторы, а значит и соответствующие интерфейсы ему совершенно не требуется. Следовательно — надо как минимум отвязать от таких интерфейсов все сетевые протколы и службы. А как максимум — просто отключить («Disable») эти интерфейсы. (Правда, отвязать службу «HP Network Configuration Utility» у вас не получится — пусть это вас не смущает). Собственно говоря, это единственный тип интерфейсов, где вам действительно потребуется изменять вручную привязку служб и протколов. Во всех остальных случаях нужные настройки будут применятся по умолчанию.

3.3.2. VLAN, к которым должны иметь доступ как родительский раздел, так и виртуальные машины. А вот здесь нам как раз нужны те службы и протоколы, которые потребуются родительскому разделу в том или ином сетевом сегменте. Примером тамого VLAN в нашей конфигурации является «Production». Привязывайте и отвязывайте службы и протоколы по своему усмотрению. По умолчанию в свойствах интерфейса этого типа присутствует стандартный набор.

3.4. Теперь без внимания остался только один несчастный интерфейс, который привязан к VLAN по умолчанию. Если вы ещё не забыли, мы договорились вообще не использовать его. А значит, этот интерфейс можно смело отключить («Disable») в родительском разделе. Итоговая картина выглядит примерно следующим образом.

Для проверки можно убедиться, что поля «Connectivity» и «Network Category» заполнены только у тех интерфейсов, к которым должен иметь доступ родительский раздел. Чем таких интерфейсов меньше — тем больше вероятность, что всё настроено правильно. Один или два — оптимальное количество. Все остальные интерфейсы используются для того, чтобы передавать данные по цепочке от физических сетевых адаптеров в Network Team, затем в виртуальные коммутаторы и наконец в виртуальные машины.

4. Настройка виртуальных машин

До цели остался всего один шаг — настройка сами виртуальных машин. Ведь ради них всё и затевалось. Для каждой сетевой карты вам потребуется выполнить следующую процедуру в настройках виртуальной машины. Во-первых, выбрать нужный виртуальный коммутатор. А во-вторых, указать правильный VLAN ID, который будет совпадать с настройками этого VLAN, заданными на этапе 1.2.

Теперь, если всё сделано правильно, ваши виртуальные машины получат доступ именно в те сегменты сети, которые вы им назначили.

В заключение замечу, что HP Network Configuration Utility по умолчанию использует автоопределение типа создаваемой Network Team. По возможности будет использоваться стандарт IEEE 802.3ad, в соответствии с которым данные передаются через все физические сетевые адаптеры, которые учавствуют в Team. В нашем случае, когда таких адаптеров два, это удвоит пропускную способность Network Team по сравнению с обычной ситуацией, когда используется только один физический сетевой адаптер. Однако для такой работы требуется, чтобы все адаптеры, которые составляют Network Team, были подключены к одному и тому же физическому коммутатору. Или нескольким коммутаторам, объединённым в стек. В противном случае, если сетевые адаптеры, составляющие Network Team, подключены к самостоятельным физическим коммутаторам, использование стандарта IEEE 802.3ad невозможно. В такой конфигурации в каждый момент времени для передачи данных станет использоваться только один физический сетевой интерфейс, а остальные будут находиться в горячем резерве.

Добавлено в 14:10. Вот диаграмма, которая показывает итоговое состояние родительского раздела. Изображены взаимосвязи между следующими компонентами.

• Все сетевые интерфейсы, которые отображаются в списке сетевых подключений;
• Network Team;
• внешние виртуальные коммутаторы (External Virtual Switches) Hyper-V;
• подключение виртуальных машин.