KirillShusherin
Contributor
Contributor

Отказоустойчивость сети

Jump to solution

Добрый день.

Возник такой вопрос. Есть vSphere 5, несколько хостов, в каждом по 4е сетевых карты, две смотрят в один физический блейд-свитч, две другие в другой. Портгруппам на VDS розданы сетевухи смотрящие в разные свитчи для обеспечения отказоустойчивости.

При физическом выключении любого из свитчей vmware видит это и виртуальные машинки начинают топать через другой свитч. Т.е. в плане проблем с физикой отказоустойчивость работает. Но вот если зачистить конфигурации свитча, то Vmware продолжает лупить в этот свитч, а дальше пакеты не уходят, ибо vlan не настроены на физике. А с точки зрения vmware все ок. Вопрос - как сделать, чтобы была проверка не только физики, а и логики тоже? Например, проверка пинга до какого-нить далекого шлюза через каждый из свитчей...

Заранее спасибо.

0 Kudos
1 Solution

Accepted Solutions
VMadmin4eg
Hot Shot
Hot Shot

В настройках группы портов можно изменить Teaming and Failover Policies с Link Status only на Beacon Probing.

Подробности здесь: Edit Distributed Port Teaming and Failover Policies

View solution in original post

0 Kudos
15 Replies
VMadmin4eg
Hot Shot
Hot Shot

В настройках группы портов можно изменить Teaming and Failover Policies с Link Status only на Beacon Probing.

Подробности здесь: Edit Distributed Port Teaming and Failover Policies

View solution in original post

0 Kudos
urbas
Enthusiast
Enthusiast

KirillShusherin wrote:

Вопрос - как сделать, чтобы была проверка не только физики, а и логики тоже?

Вообще проверка возможна только по Link Status или Beacon Probing.. Но для правильной работы Beacon Probing нужно больше двух интерфейсов, т.к. при этом типе проверки каждый аплинк посылает бродкасты, которые должны приходить на другой аплинк, тогда считается, что линк рабочий. Если у Вас один из свичей сломается, то ни от одного бродкасты не будут приходить, ни от другого.. То есть непонятно, какой из аплинков потерян.. В этом случае трафик должен вроде посылаться по обоим аплинкам.. попробуйте, будет работать?  + с Beacon Probing нельзя использовать балансировку based on IP hash.

А свичи стекируемые у вас? Поддерживают cross stack агрегацию интерфейсов?

KirillShusherin
Contributor
Contributor

Блейдовые свитчи не стекируемые, и вообще довольно простые в плане конфига...

Общая схемы выглядит так. Все аплинки порт группы в состоянии active.

444.jpg

0 Kudos
KirillShusherin
Contributor
Contributor

Вот тут говорят о невозможности использовать beaconing в случае когда две сетевухи смотрят в один физ.свитч.

  • Don’t use Beacon Probing if more than one pNIC in the vSwitch is connected to the same pSwitch. This could result in the same MAC address being presented on two or more ports on the pSwitch which is “a very bad thing”.

The Great vSwitch Debate – Part 4 | Ken's Virtual Reality

0 Kudos
urbas
Enthusiast
Enthusiast

KirillShusherin wrote:

Вот тут говорят о невозможности использовать beaconing в случае когда две сетевухи смотрят в один физ.свитч.

  • Don’t use Beacon Probing if more than one pNIC in the vSwitch is connected to the same pSwitch. This could result in the same MAC address being presented on two or more ports on the pSwitch which is “a very bad thing”.

ИМХО, бред говорят. Сами же пишут о том, что бекон-фрейм посылается с использованием мака аплинка.. Как этот мак может оказаться на двух или более портах (если нет колец, конечно)? Кажется, невозможно воткнуть один аплинк в 2 физических порта.

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

0 Kudos
KirillShusherin
Contributor
Contributor

Я так понимаю, что в случае блокировки одной физ карты из двух в данном свитче, мак адрес ВМ может быть перекинут на другую физ карту в том же свитче. И тогда мак адрес ВМ может быть одновременно виден по двум портам одного свитча (старому, где была ВМ и новому, куда ВМ перекинуло).

Поможет ли в данном случае, если один из двух аплинков в один физ свитч перевести в stand by, а два аплинка в разные свитчи оставить active? Но что-то мне кажется не поможет.

0 Kudos
VMadmin4eg
Hot Shot
Hot Shot

Я не нашёл ограничений в KB с описанием работы Beacon Probing: VMware KB: What is beacon probing?

Другое дело что если ошибка в конфиге вышестоящего физ. свитча (в вашем случае Cisco), то погасится может возможно единственно работающий аплинк подключенный в блэйдовый свитч.

0 Kudos
VMadmin4eg
Hot Shot
Hot Shot

KirillShusherin wrote:

Я так понимаю, что в случае блокировки одной физ карты из двух в данном свитче, мак адрес ВМ может быть перекинут на другую физ карту в том же свитче. И тогда мак адрес ВМ может быть одновременно виден по двум портам одного свитча (старому, где была ВМ и новому, куда ВМ перекинуло).

Поможет ли в данном случае, если один из двух аплинков в один физ свитч перевести в stand by, а два аплинка в разные свитчи оставить active? Но что-то мне кажется не поможет.

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

0 Kudos
KirillShusherin
Contributor
Contributor

Ну хорошо) Спасибо за помощь.

Попробую такой вариант и проверю в нерабочее время отрабатывает ли он или нет.

Почему тему как решенную, и если что заново подниму)

Всем спасибо.

0 Kudos
urbas
Enthusiast
Enthusiast

KirillShusherin wrote:

Я так понимаю, что в случае блокировки одной физ карты из двух в данном свитче, мак адрес ВМ может быть перекинут на другую физ карту в том же свитче. И тогда мак адрес ВМ может быть одновременно виден по двум портам одного свитча (старому, где была ВМ и новому, куда ВМ перекинуло).

Поможет ли в данном случае, если один из двух аплинков в один физ свитч перевести в stand by, а два аплинка в разные свитчи оставить active? Но что-то мне кажется не поможет.

Как Вам уже ответили, тут вступает Notify Switches, который оповещает физ.свитч о том, что вм на другом порте.. Просто пакетик посылает ему, а тот правит свою таблицу маков, как известно, по source mac пришедшего на порт пакета... Notify Switches должен быть включен всегда (за исключением использования NLB кластеров из вм). Если Notify Switches выключен, то физ.свитч поймёт, что вм за другим портом только тогда, когда вм инициирует трафик. Этого можно прождать вечно, а можно и меньше секунды. Галочку вобщем надо ставить.

А чтобы вообще на 2х и более портах свича был один мак - это как? Прыгать он может быстро с одного на другой.. но чтобы на двух сразу..

0 Kudos
Totopolis
Contributor
Contributor

Не побоясь срока давности, все же спрошу:

Как в итоге получилось решить проблему? У нас схожая ситуация, данным путем не получается пока решить.

0 Kudos
wwwtank
Enthusiast
Enthusiast

присоединяюсь к поднятому вопросу, тоже интересует, стоит ли переходит с link only на beacon only, если у меня два линка в одном коммутаторе, а два в другом?

(у меня vSphere Essential plus, vds нет, я про аналогичные настройки в свойствах vSwitch0 )

0 Kudos
Finikiez
Champion
Champion

KB vmware в явном виде говорит, что неи смысла в beacon probig при наличии двух аплинков к одному физическому коммутатору VMware Knowledge Base

Я думаю, что защищаться от вычещенной таблицы VLANов на физическому коммутаторе надо несколько иными способами и не администратору среды виртуализации Smiley Happy

pastedImage_1.png

0 Kudos
wwwtank
Enthusiast
Enthusiast

Спасибо.  Правильно ли я понимаю, что если я имею 2 физических  коммутатора на 4 линка, мне бесполезно настраивать варианты Link/Beacon?

Ибо режим link only на vSwitch  спасет только от смерти ближайшего физического коммутатора: если линк останется, а связь дальше коммутатора порвется, то гипервизор продолжит лупить в ближайший живой, но оторвавшийся от сети коммутатор. Если в этом случае я переславляю на beacon only, гипервизор так же продолжить лупить в тот же коммутатор, считая связь живым из-за того, что рядом найдет живой соседний линк в том же оторвавшемся от сети коммутаторе.

0 Kudos
Finikiez
Champion
Champion

В любом случае при настройке параметра Network Failure detection нужно что-то выбрать. При вашей конфигурации логично и правильно установить 'Link status only'.

Для примера, если используется блейд шассии HP и Virtual Connect для подключения к сети, у virtual connect есть возможность настроить отключение внутренних портов к лезвиям при отключении аплинка к следующему физическому коммутатору.

Но это все равно не решит задачу, если у вас вдруг пропали все VLANы. Задачу с неправильной конфигурацией VLAN можно попробовать решить через настройку Health Check, которая имеется только на распределенном коммутаторе. Почитать можно вот тут vSphere Distributed Switch Health Check Но как там написано, нужно учитывать размеры инфраструктуры и размер таблицы MAC адресов на физических коммутаторах.