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

Кто поддерживает Network Teaming и почему?  

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

Но если вы обратитесь в техническую поддержку Microsoft, то — будь то обычный PSS или Premier Support — в качестве первой меры к решению проблемы вам, скорее всего, порекомендуют избавиться от Network Teaming. Разумеется, это касается только тех случаев, когда проблема возникает с сетевой подсистемой. Если симптомы будут проявляться чём-то другом, например в работе дисковой подсистемы, — то никто, конечно, напрасно покушаться на Teaming не станет.

Network Teaming против виртуализации 

Все сказанное выше касается большинства традиционных серверных ОС и приложений. Но в случае с Hyper-V ситуация еще хуже — или, по крайней мере, была таковой до недавнего времени. Microsoft (да и мы сами) неоднократно заявляла, что Hyper-V не просто «не поддерживает» Teaming — но и вообще не работает с ним. Если кто-то из вас пробовал создавать внешний виртуальный коммутатор (External Virtual Switch) на основе сетевого адаптера, полученного с использованием Network Teaming — наверняка вы столкнулись с некоторыми проблемами. Обычно они проявляются либо в том, что что виртуальные машины вообще не получают связи с внешними серверами, либо просто не срабатывает переход по отказу (Failover) при отключении одного из портов или адаптеров.

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

Задача и решение

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

Сетевые подключения и безопасность — лучшие практики

В заключение напомню, что Microsoft по соображениям безопасности не рекомендует подключать родительский раздел в один и тот же сетевой сегмент с виртуальными машиами. При этом подразумевается, что родительский раздел вообще не должен иметь доступа ни в производственную сеть, ни тем более в Интернет. Поэтому не следует использовать один и тот же сетевой интерфейс как для виртуальных машин, так и для работы родительского раздела. Эта рекомендация справедлива вне зависимости от того, используете вы самостоятельные интерфейсы или объединяете их с помощью Network Teaming.

Для того, чтобы следовать этому принципу, потребуется отвязать все сетевые службы и протоколы от того интерфейса (или интерфейсов), который связывает родительский раздел с виртуальным коммутатором. Сам этот интерфейс затем можно будет вовсе отключить — но это уже не обязательно. Следовательно, если вы намереваетесь задействовать два сетевых адаптера на сервере для того, чтобы объединить их в Network Team и создать на его основе отказоустойчивое подключение для виртуальных машин — вам потребуется также третий выделенный адаптер для того, чтобы отдельно подключить к сети родительский раздел.

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