none
При падении линка разваливается кластера Hyper-V 2012R2 RRS feed

  • Вопрос

  • Доброго времени суток .

    Имеем HyperV кластер о 8 хостах.  На каждом хосте 4 сетевые карточки сагрегированны в одну "группу не зависимую от коммутатора" поверх этой группы настроены несколько виртуальных сетевых адаптеров, в общем все по мануалу по созданию кластера Hyperv. Каждая сетевая карта подключена к своему коммутатору каждый коммутатор соответственно к вышестоящему. Есть правда наверное существенный нюанс коммутаторы неуправляемые!. Происходит следующая ситуация при падении  линка от кластерного коммутатора до вышестоящего коммутатора моментально начинает разваливаться кластер, пропадает сетевая связность между узлами, при восстановлении линка все возвращается в нормальное состояние. При физическом отключении одного или нескольких кластерных коммутаторов такого не происходит. Есть ощущение что при падении линка начинается бродкаст шторм на всех коммутаторах подключенных к кластеру. Что посоветуете делать?     


    Sergey Laptev

    1 апреля 2018 г. 9:04

Ответы

  • Если адаптеры объединены в team, то сеть, к которой они подключаются, тоже должна быть устойчивой к отказам коммутаторов и соединений между ними. Для вас это означало бы, что нужно было бы добавить ещё одинвышестоящий коммутатор, сделать дополнительные соединения от всех коммутаторов, к которым подключены адаптеры сервера, ко второму вышестоящему коммутатору, (необязательно)соединить вышестоящие коммутаторы друг с другом и включить на всех портах, связывающих коммутаторы, протокол моста (STP AKA 802.1D или его усовершенствованный вариант). Но так как у вас коммутаторы - неуправляемые, то вы этот вариант не реализуете.

    Так что вам придётся либо переходить на управляемые коммутаторы, либо разбивать team  на отдельные адаптеры, подключенные к отдельным сетям и довольствоваться той отказоустойчивостью, которую обеспечивает служба кластеризации Windows при отказе каждой отдельной сети.

     

    Слава России!


    • Изменено M.V.V. _ 5 апреля 2018 г. 9:17
    • Помечено в качестве ответа Sergey Laptev 5 апреля 2018 г. 14:01
    5 апреля 2018 г. 9:16

Все ответы

  • Привет,

    Какая-нибудь ошибка наблюдается при возникновений проблемы? Можете предоставить, по какому мануалу Вы делали конфигурацию?


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий. Не забывайте помечать сообщения как ответы и полезные, если они Вам помогли.

    2 апреля 2018 г. 8:06
    Модератор
  • Вообще-то, агрегирование (teaming) сетевых адаптеров защищает только от отказа подключения к коммутатору и самого коммутатора. От отказа связи между коммутаторами оно не защищает и для защиты от него не предназначено. Для этого используются другое средство - избыточные подключения совместно с протоколом моста (STP) на коммутаторах - которое на неуправляемых коммутаторах не реализуется.

    Поэтому в вашем случае выход я вижу один - создание 4 (или меньше) отдельных сетей. Кластер легко может использовать их все для отслеживания состояния узлов и для миграции VM, но вот как обеспечивать в этой конфигурации отказоустойчивость клиентского доступа к VM при отказе одной  сети - это вопрос, на который я простого ответа не вижу.


    Слава России!

    2 апреля 2018 г. 9:29
  • Так а откуда система будет понимать, что у вас линк оборвался где-то там за кластерным коммутатором (я так понимаю это коммутатор в блейд-корзине).

    NicTeaming в вашем случае по факту видит, что физически линк от сервера до коммутатора активен - значит по нему можно отправлять пакеты. Вот и вся история. В случае отключения этого коммутатора - линк падает, NicTeaming видит это и заворачивает пакеты по другому каналу - соответственно поэтому всё работает. Так что подобное поведение в вашем случае нормальное.

    Если бы эти кластерные коммутаторы в свою очередь тоже объединялись в единую сущность (кластер) - то их аплинки тоже можно было бы собрать в общий агрегированный канал и было бы всё ок. Но в вашем случае я так понимаю коммутаторы довольно тупые - поэтому получаете то что есть.


    2 апреля 2018 г. 9:38
  • Мануал вряд ли смогу найти, давно это очень было. Но принцип такой 4 физических гигабитных адаптера объединяться в коммутаторо-независимый тиминг. На основе этого тиминга 3 виртуальных адаптера 1. для управления, 2.Heartbit ,3. LifeMigration. Каждый сетевой адаптер каждой ноды подключен к своему коммутатору , соответственно каждый коммутатор к вышестоящему.   Ошибками забит весь лог половина из них критическая, по собственному богатому опыту они все связаны с сетевой недоступностью. Т.е по сути при пропадании любого из линков до вышестоящего коммутатора кластер начинает разваливаться, проверенно эксперементально.

    _________________________________________________________________________________________

    Код события: 1135

    Узел "hvc5" лишен членства в активном отказоустойчивом кластере. Возможно, служба кластеров на этом узле была остановлена. Это также могло произойти из-за потери связи между данным узлом и другими активными узлами в отказоустойчивом кластере. Чтобы проверить параметры сети, запустите мастер проверки конфигурации. Если это не поможет, проверьте оборудование или программное обеспечение на наличие ошибок, связанных с сетевыми адаптерами на данном узле. Также проверьте работу других сетевых устройств, к которым подключен этот узел, таких как концентраторы, 

    ______________________________________________________________________________________

    Код события: 5120

    Общий том кластера "Volume2" ("Диск кластера 3") приостановлен на узле из-за "(c000020c)". Все операции ввода-вывода будут временно поставлены в очередь, пока путь к тому не будет установлен заново.


    Sergey Laptev

    3 апреля 2018 г. 8:00
  • В моем случае создано 3 виртуальные сети поверх  физического тиминга и проблема к сожалению не только в клиентском доступе, а в том что кластер вообще начинает разваливаться, ноды теряют связь друг с другом и начинает хаотически мигрировать виртуальные машины друг другу.   

    Sergey Laptev

    3 апреля 2018 г. 8:04
  • Нормально что начинает штормить все ноды подключенные к этим коммутаторам ?

    Sergey Laptev

    3 апреля 2018 г. 8:11
  • А почему вы решили, что у вас "штормит"? Вы смотрели скорость широковещательного трафика на каком-то порту коммутатора? А по сообытиям я вижу только пропадание heartbeat. И оно может быть вызвано как раз отказом связи с вышестоящим коммутатором.

    Слава России!

    3 апреля 2018 г. 13:28
  • Повторяю конфигурацию сети 4 сетевых адаптера подключены к 4 коммутаторам , каждый коммутатор имеет свое подключение к вышестоящему. А теперь объясните каким образом даже пропадание всех линков до вышестоящих может повлиять на Heatbeat если каждая нода одним из портов подключена к одному из коммутаторов и HeartBeat не маршрутизируется через внешнюю сеть?   Почему думаю что штормит , потому что наблюдал схожие симптомы в локальных сетях т.е. в данный конкретный момент все может замечательно работать на одном узле , а в другой момент моментально  отвалится и начать работать на другом , наблюдалась картина когда 3 из 5 нод переставали пинговаться , и кстати моментально начали пингаться когда был выключен коммутатор который потерял линк к вышестоящему, эксперементальным путем отрубали линк на другом коммутаторе и наблюдали схожую картину , при восстановлении линка все моментально восстанавливалось.  

    Sergey Laptev

    3 апреля 2018 г. 13:46
  • Чтобы понять - каким образом, достаточно знать несколько фактов про работу в режиме Switch-independent.

    1. NIC teaming выбирает для посылки каждого пакета только один адаптер. Причём, выбирает так, что трафик, направленный на один и тот же адрес назначения и порт идёт через один и тот же адаптер (по крайней мере - некоторое время (если используется динамическая стратеги), вполне достаточное, однако, для потери оповещений службой кластера).

    2. Весь трафик, направленный на NIC team, направляется на один выбранный адаптер по его MAC (этот тот адаптер, который имеет MAC, которым NIC teaming отвечает на запросы ARP). В случае, если для подключения к этому адаптеру обнаружен сбой, то этот MAC начинает использоваться другим адаптером, но у вас как раз сбой не обнаруживается.

    Вот сопоставив эти  факты, получаем картину происходящего: если посылающий адаптер на одном узле теряет связь с принимающим адаптером на другом (из-за разрыва связи между коммутаторами), то оповещения службы кластера доходить перестают, и возникают наблюдаемые вами проблемы.

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


    Слава России!

    3 апреля 2018 г. 14:14
  • Вполне возможно, но в таком случае каким образом должна выглядеть конструкция коммутаторов для получения отказоустойчивого кластера.

    Sergey Laptev

    4 апреля 2018 г. 12:29
  • Если адаптеры объединены в team, то сеть, к которой они подключаются, тоже должна быть устойчивой к отказам коммутаторов и соединений между ними. Для вас это означало бы, что нужно было бы добавить ещё одинвышестоящий коммутатор, сделать дополнительные соединения от всех коммутаторов, к которым подключены адаптеры сервера, ко второму вышестоящему коммутатору, (необязательно)соединить вышестоящие коммутаторы друг с другом и включить на всех портах, связывающих коммутаторы, протокол моста (STP AKA 802.1D или его усовершенствованный вариант). Но так как у вас коммутаторы - неуправляемые, то вы этот вариант не реализуете.

    Так что вам придётся либо переходить на управляемые коммутаторы, либо разбивать team  на отдельные адаптеры, подключенные к отдельным сетям и довольствоваться той отказоустойчивостью, которую обеспечивает служба кластеризации Windows при отказе каждой отдельной сети.

     

    Слава России!


    • Изменено M.V.V. _ 5 апреля 2018 г. 9:17
    • Помечено в качестве ответа Sergey Laptev 5 апреля 2018 г. 14:01
    5 апреля 2018 г. 9:16