Рейтинг:0

Что не так с портом ESXi VMKernel в конфигурации Active/Active?

флаг ng

У меня есть следующая упрощенная конфигурация:

введите описание изображения здесь

По сути, у меня есть хост ESXi с двумя физическими сетевыми адаптерами. Каждый адаптер подключается к отдельному коммутатору. Каждый коммутатор подключается через магистральный порт. ПК подключен к одному из коммутаторов. vSwitch с портом VMKernel и портами виртуальных машин настроен на использование обеих физических сетевых карт в конфигурации «активный/активный»:

введите описание изображения здесь

я побежал esxtop и видим, что хост ESXi выбрал физический сетевой адаптер, подключенный к коммутатору 2, в качестве порта VMKernel. С ПК, если я пропингую IP-адрес управления хоста ESXi, эхо-запросы будут прерывистыми. Они идут вверх и вниз.

Если я покажу таблицу MAC-адресов на каждом коммутаторе, я увижу, что коммутатор 2 всегда имеет MAC-адрес VMKernel, назначенный порту коммутатора, подключенному к хосту ESXi. Но коммутатор 1 постоянно добавляет и удаляет MAC-адрес VMKernel на соответствующем физическом порту. Каждый раз, когда коммутатору 1 назначается MAC-адрес VMKernel для физического порта, проверка связи завершается неудачно.

Причина провала очевидна.Вопрос в том, почему Switch 1 регулярно получает MAC-адрес порта ESXi VMKernel. Хост ESXi выбрал интерфейс, подключенный к коммутатору 2, в качестве активного порта. Интерфейс, подключенный к коммутатору 1, должен быть неактивен. Но может показаться, что он, возможно, отвечает на запросы ARP?

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

Что в этой конфигурации неправильно? Я ищу какую-то документацию или объяснение поверх решения этой проблемы. Я знаю, что установка порта VMKernel в режим Active/Standby, вероятно, решит проблему. Но я не могу найти ничего задокументированного, почему эта текущая конфигурация является проблемой.

ОБНОВЛЕНИЯ:

  • Я отключил CDP на vSwitch, думая, что это может вызывать связь через неактивную сетевую карту.
  • Я переопределил настройки vSwitch для порта VMKernel и настроил его на использование явного аварийного переключения и режима Active/Standby. Я также поместил резервную сетевую карту в неиспользуемый пул. Ничего из этого не помогло. Что действительно решило проблему, так это изменение порядка портов. Итак, когда порт, подключенный к коммутатору 1, становится активным, я не вижу проблемы. MAC-адрес вообще не становится активным на коммутаторе 2. Это две существенно разные сетевые карты, и мне интересно, не является ли это какой-то проблемой с драйвером.

Что-то должно быть причиной того, что MAC-адрес VMKernel виден на порту коммутатора 1, но он появляется и исчезает каждые несколько секунд.

Конфигурации коммутатора для STP и портов: Переключатель 1

!
режим связующего дерева
spanning-tree portfast edge по умолчанию
связующее дерево расширяет системный идентификатор
!
интерфейс Port-channel1
 доступ к порту коммутатора vlan 11
 инкапсуляция магистрали коммутатора dot1q
 магистраль режима switchport
!
интерфейс GigabitEthernet1/0/7
 доступ к порту коммутатора vlan 11
 доступ в режиме switchport
!
интерфейс GigabitEthernet1/0/23
 доступ к порту коммутатора vlan 11
 инкапсуляция магистрали коммутатора dot1q
 магистраль режима switchport
 желателен режим группы каналов 1
!
интерфейс GigabitEthernet1/0/24
 доступ к порту коммутатора vlan 11
 инкапсуляция магистрали коммутатора dot1q
 магистраль режима switchport
 желателен режим группы каналов 1

Переключатель 2

!
режим связующего дерева
spanning-tree portfast edge по умолчанию
связующее дерево расширяет системный идентификатор
!
интерфейс Port-channel1
 доступ к порту коммутатора vlan 11
 инкапсуляция магистрали коммутатора dot1q
 магистраль режима switchport
!
интерфейс GigabitEthernet1/0/3
 доступ к порту коммутатора vlan 11
 доступ в режиме switchport
!
интерфейс GigabitEthernet1/0/23
 доступ к порту коммутатора vlan 11
 инкапсуляция магистрали коммутатора dot1q
 магистраль режима switchport
 желателен режим группы каналов 1
!
интерфейс GigabitEthernet1/0/24
 доступ к порту коммутатора vlan 11
 инкапсуляция магистрали коммутатора dot1q
 магистраль режима switchport
 желателен режим группы каналов 1
Рейтинг:3
флаг in

vmk управления в ESXI предполагает MAC-адрес сетевого адаптера в первом слоте PCI во время первоначальной настройки. Вот как это работало всегда. Это может сломать ситуацию только тогда, когда физическое устройство также начнет отправлять пакеты. Обычно этого не происходит, физические ники не отправляют трафик, они пропускают трафик. На это поведение также следует обратить внимание, если вы решите переместить физические сетевые адаптеры с одного хоста на другой, это приводит к разрыву двух хост-соединений, когда физический коммутатор выходит из строя. Я предполагаю, что этот Nic начал сообщать о трафике CDP/LLDP, и именно тогда ваш коммутатор видит дублирование MAC. Самое простое решение - пересобрать вмк через командную строку. Это нужно будет сделать из прямого доступа к консоли (DCUI) (KVM, ILO, IDRAC и т. д.).

Вот команды; (Настройте IP-адреса/маску подсети/имя группы портов и т. д. в соответствии с вашими потребностями.)

сетевой IP-интерфейс esxcli удалить --interface-name=vmk0

esxcli network vswitch стандартная группа портов add -p Management_Network -v vSwitch0

esxcli network ip interface add --interface-name=vmk0 --portgroup-name=Management_Network

Стандартный набор портов сети esxcli vswitch -p Management_Network --vlan-id 50

esxcli сетевой IP-интерфейс ipv4 set --interface-name=vmk0 --ipv4=192.168.50.116 --netmask=255.255.255.0 --gateway=192.168.50.1 --type=static

Тег сетевого IP-интерфейса esxcli add -i vmk0 -t Management

Это перестроит vmk управления с MAC-адресом VMware, чтобы устранить эту проблему. Тем не менее, я бы порекомендовал вам обратиться к поставщику/производителю оборудования для процесса отключения CDP/LLDP, исходящего от физической карты. Это решит эту проблему с одним хостом ESXi, но в конечном итоге это произойдет с другими, если вы позволите картам продолжать выполнять эту функцию. Если бы это была такая большая проблема, как вы изначально думали, VMware не была бы гигантской компанией, это не очень распространено...

Appleoddity avatar
флаг ng
В точку. Проблема заключается в том, что агент LLDP на аппаратном уровне отправляет пакеты LLDP с тем же MAC-адресом. Теперь мне нужно выбрать лучший способ решить проблему. Ваше решение вполне разумно, просто у меня нет простого физического доступа к серверу. Я могу обновить свою лицензию iDrac или использовать удаленные руки и глаза. Но если я это сделаю, я также могу войти в BIOS и отключить агент LLDP (очевидно). Какая боль. Еще раз спасибо.
Рейтинг:2
флаг ru

Я использовал очень похожую настройку в течение многих лет без каких-либо проблем.

Как вы настроили порты коммутатора? Ничего особенного делать не надо(нет (M)LAG/LACP), поскольку обо всем позаботится ESXi. Коммутаторы можно объединять в стек, просто не объединяйте порты, не настраивайте зеркалирование состояния канала и т.п.

Коммутатор 2 должен постоянно иметь MAC-адрес порта VMkernel на порту, обращенном к ESXi, а коммутатор 1 — на порт, обращенный к коммутатору 2.

Колебание MAC-адресов взад и вперед может быть вызвано другой проблемой, например частыми изменениями топологии STP (которые обычно не видны ESXi, но все же могут быть). Проверьте журналы коммутаторов на наличие аномалий.

Вопрос в том, почему Switch 1 регулярно получает MAC-адрес порта ESXi VMKernel.

Без какой-либо LAG это могло произойти только в том случае, если хост действительно отправлял кадры с MAC-адресом порта VMK на коммутатор 1. Обычно этого не происходит, если связь с коммутатором2 не удалась.

Интерфейс, подключенный к коммутатору 1, должен быть неактивен.

Для порта ВМК да. К одной и той же группе портов может быть подключен трафик ВМ.

Но может показаться, что он, возможно, отвечает на запросы ARP?

ARP или нет, фреймы с MAC-адресом порта VMK не исходят из другого порта без причины.

Appleoddity avatar
флаг ng
Спасибо за ответ. Коммутаторы представляют собой стандартные порты доступа. Ничего особенного. Я вижу миллионы BDPU, отправленных с коммутатора 1 на коммутатор 2. Я не уверен, что это связано. Мне кажется, что коммутатор 1 видит трафик с подключенного к нему интерфейса ESXi и временно добавляет MAC в свою таблицу.Но этот адаптер должен быть «неактивным». Я думал, что что-то сделал, отключив CDP на физическом адаптере, но это не имело никакого значения. Не изменился и переход VMKernel в режим Active/Standby. Другими словами, наличие чего-либо на vSwitch в режиме Active/Active вызывает эту проблему.
Zac67 avatar
флаг ru
*миллионы BDPU, отправленные с коммутатора 1 на коммутатор 2*, не кажутся нормальными - BPDU обычно отправляются только на назначенные порты (= к корневым портам) каждые 2 секунды. Кроме того, адаптеры не активны, когда вы работаете в режиме «активный-активный». vNIC подключаются по номеру виртуального порта (примерно случайным образом) и остаются там. Если вы хотите активный-пассивный, вам нужно переместить один порт вниз к *резервным адаптерам*. Нет, CDP/LLDP не имеет значения, я бы оставил его активным. Проблема с активным/резервным режимом *очень сильно* указывает на проблему с конфигурациями коммутатора.
Zac67 avatar
флаг ru
Не могли бы вы добавить очищенные конфиги (по крайней мере, части, относящиеся к портам и STP) к вашему вопросу? Журналы коммутатора что-нибудь показывают?
Appleoddity avatar
флаг ng
Привет. Спасибо за вашу помощь в этом. Ваши обновления точны, и мы согласны. Пакеты от неактивной карты не должны быть видны на коммутаторе 1, но он есть. Я обновил свой оригинальный пост. Если я изменю порядок портов - т.е. сделаю NIC на Switch 1 активной, то проблема исчезнет и Switch 2 не увидит трафик от неактивной NIC. Если я поменяю их обратно, проблема снова появится. Это две существенно разные сетевые карты. Мне интересно, если это какая-то проблема с драйвером. Я ценю внимание к коммутаторам, но по какой-то причине все указывает на кадры, поступающие от неактивного сетевого адаптера ???
Appleoddity avatar
флаг ng
добавлены конфиги коммутатора. Это довольно простая конфигурация коммутатора. Ничего особенного. STP включен только потому, что есть подключение к другому стеку коммутаторов через 2 кабеля Ethernet, и эти два коммутатора в обсуждении не объединены в стек. Опять же, использование `show mac address-table interface gi1/0/7` показывает появление и исчезновение MAC-адреса VMKernel. Где, как и на другом коммутаторе, MAC стабилен, как и ожидалось.
Zac67 avatar
флаг ru
Есть ли у вас четко определенный корневой мост? Другие коммутаторы также используют RPVST+ или RSTP/MSTP? Порты 23 и 23 в качестве канала порта являются каналом стекирования? А 7 и 4 это ссылки хоста?
Рейтинг:1
флаг tr

Опубликованная вами конфигурация порта коммутатора показывает, что вы используете канал порта на коммутаторах Catalyst.

Просто не делай этого! Для автономных хостов ESXi это не поддерживается. ESXi самостоятельно заботится о балансировке нагрузки и отказоустойчивости только в программном обеспечении. Если вы абсолютно хотите использовать каналы портов на основе внешних коммутаторов, то для этого необходимо использовать vCenter и распределенный коммутатор.

Видеть https://kb.vmware.com/s/article/82609 и https://kb.vmware.com/s/article/1001938 для получения дополнительной информации.

Appleoddity avatar
флаг ng
Спасибо за ответ. Канал порта не настроен ни на одном порту, подключенном к ESXi. Это транки между коммутаторами Cisco.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.