Назад | Перейти на главную страницу

Политика объединения сетевых адаптеров ESXI x 2 физических коммутатора x Shaper \ BGP router

У меня есть BPG / Shaper с 2 интерфейсами, настроенными в Bond0 (Loadbalance-RoundRobin), затем подключите по одному к каждому коммутатору (один в красном в синем).

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

В этом сценарии у меня 50% потерь пакетов, потому что политика объединения сетевых карт - «Маршрутизация на основе идентификатора исходного виртуального порта», когда они выбирают один vmnic, трафик всегда остается на той же плате. Я считаю, что если я подключу кабель между коммутаторами, я решу свою проблему, но если коммутатор перестанет работать, но продолжит ведущее соединение, зондирование маяка (Network Failover Detection) обнаружило проблему? Мне нужно, чтобы связующее дерево было активным?

Таким образом, исходя из приведенного выше изображения, как вы посоветуете мне использовать политики объединения Bound и NIC в моей среде, чтобы у меня вообще была избыточность?

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

Вы правильно описываете «Маршрутизация на основе идентификатора исходного виртуального порта»: конкретный vNIC всегда будет оставаться на том же порту коммутатора, если не произойдет аварийного переключения.

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

Затем при балансировке нагрузки между всеми этими виртуальными сетевыми адаптерами трафик должен выровняться. В качестве альтернативы вы, конечно, можете использовать только один vNIC для каждой виртуальной машины и равномерно распределять их по группам портов.

Если оба коммутатора используются для одной и той же VLAN / подсети, они должны иметь возможность общаться друг с другом - если шейпер не соединяется между собой, вам необходимо соединение между ними.

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

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

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