Отказоустойчивость сетевых подключений в Windows 2008 server и Hyper-V

Для обеспечения отказоустойчивости сети, наиболее понятный путь – объединение нескольких интерфейсов в одну группу, в Linux  эта процедура называется бондинг, в Windows эта функция не заложена в ОС и требует дополнительных компонент для своей работы, компоненты эти предоставляются производителями сетевых карт. Соответственно сколько производителей сетевых карт, столько технологий объединения. Для меня представляет определенный интерес сетевые адаптеры broadcom, поскольку именно их встраивают в свои сервера все основные вендоры: IBM, HP, Dell, Fuji. Встраивают в основном карты NetXtreme I или II. Понятно что при необходимости можно добавить карты Intel, но зачастую это не позволяет сделать конструктив, к примеру в Blade системах, либо в другой ситуации оказываешься перед фактом – есть то железо которое есть. Как известно добавляют сетевые карты в сервера сверх встроенных – нечасто.

Итак о какой задаче пойдет речь – необходимо реализовать полную отказоустойчивость сервера на уровне локальной сети - 1GB Ethernet. При том, что сервер работает в кластере и используется для работы Microsoft hyper-v.

Зачем нужна отказоустойчивость сети

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

По большому счету платформа виртуализации представляет собой 3 больших блока – вычислительная часть, сетевая (I/O) и система хранения данных для виртуальных машин. Отказоустойчивость для вычислительной части на 100% процентов для х86 систем невозможна, к ней можно приблизиться путем создания Failover Cluster в Microsoft. С точки зрения отказоустойчивости системы хранения можно отметить что, отказоустойчивость самой системы рационально реализовать с помощью надежного конструктива собственно СХД и дублирования её компонент, к Microsoft и операционной системе это отношения не имеет. Отказоустойчивость путей подключения сервера к СХД реализуется с помощью встроенного в Windows 2008 MPIO либо с помощью ПО производителя СХД, тут тоже все работает без каких либо сложностей. Остается отказоустойчивость сети. Как я писал выше единственно возможный путь здесь – объединение карточек в одну группу и настройка отказоустойчивости канала в этой группе. В системах виртуализации Vmware и Citrix это встроенный функционал реализованный внутри самой системы, в Microsoft Hyper-V необходимо использовать сторонний софт. Как я писал выше я пытаюсь реализовать эту схему на сетевых картах Broadcom.

Реализация Broadcom

В ПО предлагаемом Broadcom есть 3 варианта организации Teaming:
1. Проприетарный вариант имени Broadcom. (называется - “SLB”)
2. LACP 802.11 ad
3. Generic Trunking

Несколько слов о том чем они отличаются:
1. Работает на уровне драйвера, поддержки от коммутатора не требует. теоретически в настройках есть два режима – балансировка и отказоустойчивость.
2. Требует поддержки от свитча соответствующей технологии.
3. Похоже на второй вариант, отличается жесткой организацией транка. (Более подробно в документации)

Надо сказать что независимо от того какой вариант будем собирать, я отключаю все расширенные настройки в свойствах сетевой карты с помощью утилиты от Broadcom - BACS, через эту же утилиту и настраивается тиминг.

Настройки сетевой карты. В общем случае должно быть все также, только Locally Administered Address будет пустой. Это скриншот с уже собранного тиминга.

Первичная проверка и способ тестирования работы

Итак, чтобы с чего то можно было начать, был сделан самый просто вариант тиминга SLB из двух сетевых карт одна из которых была в режиме standby. То есть был собран самый просто режим отказоустойчивости. Эта процедура была проведена на двух серверах на которых стояла ОС w2008 server SP2 ent x64, на этих серверах был настроен hyper-v и оба они были в составе одного Failover Cluster. В кластере было 3 виртуальные машины, одна с домен контроллером для кластера и две с установленной 2008 Windows в качестве демо нагрузки. В обоих узлах кластера было по две сетевые карты broadcom BCM5708S NetExtreme II, версия драйвера 4.8.5.0, версия прошивки 4.6.0 на момент проверок это были наиболее актуальные версии взятые с сайта производителя.

Проверка осуществлялась следующим образом – на каждой из двух демо машин создавался скрипт с одной строкой “shutdown –s –t 40” этот скрипт ставился на выполнение после загрузки ОС на каждой виртуальной машине. Естественно обе машины были в кластере.

Что получалось таким образом? Виртуальная машина включалась, грузилась, а через 40 секунд выключалась. Кластерный сервис воспринимал это как аварию и включал эту виртуальную машину на другом сервере. Там происходило все с самого начала и машина опять выключалась.

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

Да, надо сказать о настройке самого кластера – в нем два узла-сервера, находящихся в одной подсети. В  качестве внешнего стораджа используется FC система, на ней хранятся виртуальные машины и кворум кластера. В кластере используется одна сеть вида 192.168.199.0/24 в этой подсети и находятся оба узла. Использование этой сети для кластера – разрешено. Режим работы кластера – “Node and Disk Majority”.

Результат первой проверки

После порядка 40 переключений ВМ, или около часа времени постоянных переключений виртуальных машин один из узлов вылетел в BSOD. В результате образовался minidump который был разобран и получен следующий результат:

C:\Users\admin\Desktop\kdfe>kdfe.cmd "teaming BASP Mini072909-01.dmp"
Analyzing "C:\Users\admin\Desktop\kdfe\teaming BASP Mini072909-01.dmp", please wait... Done.

Crash date:         Wed Jul 29 17:54:58.282 2009 (GMT+4)
Stop error code:    0x7f_8
Process name:       System
Probably caused by: NETIO.SYS ( NETIOMatchValues+14e )

Эта стоп ошибка – описана в KB842465 если коротко – ошибка вычислений CPU. По большому счету показывает что произошла критическая ошибка в вычислениях.

Затем было произведено переконфигурение тиминга в режим LACP, сделаны нужные настройки на свитче куда включались интерфейсы и повторен тест, система упала в BSOD еще быстрее в результате был получен следующий minidump:

C:\Users\admin\Desktop\kdfe>kdfe.cmd LACP_Mini073009-05.dmp
Analyzing "C:\Users\admin\Desktop\kdfe\LACP_Mini073009-05.dmp", please wait... Done.

Crash date:         Thu Jul 30 14:01:32.501 2009 (GMT+4)
Stop error code:    0x7f_8
Process name:       System
Probably caused by: NETIO.SYS ( NETIOMatchValues+14e )

ошибка полностью повторяет первую.

Здесь я чуть позже размещу ссылки на описание этой утилиты и её возможностей, а в следующем посте опишу свои злоключения с ней.