Vmware notify switches что это
Обновлено: 17.05.2024
В рамках работы над MITIGATOR на ESXi приходиться собирать различные извращенные схемы сети. В том числе с участием виртуальных L2 transparent устройств, нескольких vMX, переходом трафика из реальной сети в вирутальную, и целой пачки vSwitch. И чаще всего сеть на этом всём виртуальном зоопарке работает не так как ожидается.
Не так как ожидает обычный сетевик.
Во-первых, чудят сами виртуальные устройства.
Во-вторых, не вся функциональность железных собратьев перенесена в виртуалки.
В-третьих. Оказалось vSwitch на ESXi есть принципиальное отличие от обычного switch, но из настроек это не понять. А почти за 10 лет работы с ESXi ни разу не натыкался на описание.
vSwitch имеет ряд настроек которые хорошо описаны и нормально ложатся в парадигму обычного сетевика. В том числе security настройки:
*Promiscuous Mode* — дает доступ ко всем фреймам проходящим через vSwitch, либо в рамках VLAN.
*MAC Address Changer* — разрешает принимать фреймы у которых dst MAC не соответствует MAC адресу интерфейса VM. Такое может быть, когда уже внутри VM через ОС поменяли MAC адрес на интерфейсе.
*Forget Transmit* — позволяет отправлять фреймы у которых src MAC не принадлежит VM.
Но с пониманием работы этих опций, и даже с их перебором — сеть не работает как ожидается. Потому что в моей картине мира не хватало следующей информации:
“Когда некий кадр поступает в любой физический коммутатор, его получатель определяется определённым номером порта коммутатора, соответствующим MAC адресу его получателя в имеющейся у данного физического коммутатора таблице MAC адресов. Если у вас нет возможности найти некую запись в данной таблице MAC адресов, он направляет данный кадр во все порты, отличающиеся данного порта источника.
Осознание такового поведения vSwitch не помогло починить текущую схему, нужно делать совершенно другой дизайн. Но зато теперь могу объяснить почему не работает.
- VMware Technology Network
- :
- Global
- :
- Russian
- :
- Russian Discussions
- :
- vMotion, Notify Switches, ARP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
По поводу что происходит : The vSwitch “Notify Switches” setting почитайте
По поводу, что делать проверить галку Notify Switches и если стоит, разбираться с firmware (и настройками) свича.
Более конкретно не подскажу - я слаб в Allied Telesys да и формулировка "Basic Layer 3" как то напрягает, хотелось бы понимать, в чем отличие от просто "Layer 3"
urbas- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Спасибо, более подробного описания не находил.
Попробовал заменить Allied Telesis на Cisco 3750X. На циске миграция проходит нормально. Так что проблема в телесине. Странное у него понимае arp.. Запись выглядит так:
интересно, что в arp делает физический порт. И прошивки все везде последние стоят. Придется обращаться в поддержку. Вообще очень не рекомендую коммутаторы Allied Telesis 94xx. Проблем не оберётесь. VTsukanov- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Да нет все нормально с записями ARP. Какой порт вы хотели бы видеть в ARP, учитывая что это протокол канального уровня?
Вот c поддержкой RARP действительно видимо что то не так
urbas- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
вот я и не хочу как раз видеть этот порт) arp - протокол канального уровня и "связывает" 3 и 2 уровень.. то есть к первому отношения не должен иметь. То есть имеет, но уже через таблицу мак-адресов. То есть должно быть так: в arp таблице IP-MAC соответствие, в mac таблице MAC-PORT соответствие.. А RARP, посылаемый после vMotion, уведомляет только 2 уровень о том, что машина на новом порте, и этого достаточно, потому что соответствие IP-MAC не меняется, то есть и arp не должна меняться, в циске все именно так. Но телесисщики прикрутили физ. порт в arp..(кстати в таблице MAC порт после вмошн исправляется на нужный, то есть RARP свою работу делает) Может проблема конкретных моделей, конечно.. Я тут углядел, что они сняты с производства вообще. В любом случае спасибо за ссылку, она внесла ясность.
Вот как получается:
Arp запись машины до миграции: 10.10.200.132 0050.5696.2075 vlan200-0 port1.2 Dynamic
Запись в таблице мак адресов до миграции: 200 port1.2 0050.5696.2075 Forward Dynamic
Arp запись машины после миграции: 10.10.200.132 0050.5696.2075 vlan200-0 port1.2 Dynamic (Она осталась такой-же!)
Запись в таблице мак адресов после миграции: 200 port1.4 0050.5696.2075 Forward Dynamic (А машина теперь вот за этим портом!)
В данной статье рассматриваются назначения NIC Teaming в сетевой конфигурации VmWare ESXi и приводится пример настройки на основе Route based on IP hash.
NIC Teaming это агрегирование каналов, то есть объединение физических каналов в логические.
Load Balancing
Первым пунктом в настройке является load-balancing policy. Говоря по простому мы выбираем как vSwitch будет обрабатывать исходящий трафик.
Имеется 4 варианта обработки трафика:
- Route based on the originating virtual port
- Route based on IP hash
- Route based on source MAC hash
- Use explicit failover order
Route based on the originating virtual port
Данная опция является стандартным для любого только что созданного vSwitch и каждая виртуальная машина и VMkernel порт на vSwitch подключён к виртуальному порту. Когда vSwitch получает трафик от подключённых к нему объектов он назначает виртуальный порт и физический порт и использует его для передачи данных. Выбранный физический порт не меняется до тех пор пока не произойдёт какая либо ошибка или виртуальная машина не выключится или не мигрирует на другой сервер.
Route based on IP hash
Данная опция используется совместно с группой агрегации каналов LAG, так же называется EtherChannel или Port Channel. Когда трафик попадает на vSwitch, политика балансировки каналов создаёт в пакете хеш IP-адреса источника и назначения. Результирующий хеш указывает какой физический порт будет использоваться.
Route based on source MAC hash
Данная опция схожа по принципу работы с Route based on IP hash, за исключением того, что политика рассматривает только MAC-адрес источника в кадре Ethernet.
Use explicit failover order
Данная опция в действительности не выполняет никакой балансировки нагрузки и если у вас используется для подключения несколько физических портов то в любой момент времени использоваться будет только один. Сначала система пытается использовать первый активный физический сетевой порт. Если использовать первый физический порт не удаётся, то используется следующий активный физический порт и так далее.
Network Failure Detection
Данный пункт отвечает за определение ошибок в подключении физических портов и имеет две опции.
link status only
Данная опция позволяет определить ошибки, вызванные отключением кабеля или проблемой физического интерфейса и не способна определять конфигурационный ошибки, такие как если физический коммутатор заблокировал порт из-за ошибок конфигурации VLAN,spanning tree или отключения кабеля на другой стороне физического коммутатора.
Beacon probing
Данная опция отправляет и слушает специальные пакеты-маяки на все физические интерфейсы в группе и использует полученную информацию. В дополнение так же использует статус физического порта для определения проблемы подключения. Данная опция способна более точно определить проблему в отличие от link status only.
Не используйте Beacon probing вместе с Route based on IP hash чтобы избежать ложных срабатываний.
Notify Switches
По умолчанию данный пункт установлен как "YES" и он позволяет уведомить коммутатор о том, что виртуальная машина использует другой физический порт, посылая специальный Reverse Address Resolution Protocol фрейм принимающим физическому коммутаторы для обновления таблицы MAC-адресов коммутатора.
Failback
Данная опция отвечает за активацию физического порта, который находится в режиме ожидания если больше нет ни одно активного физического порта. Опция представляет своего рода активацию запасного порта на случай сбоя активного порта. Так же система переводит "запасной" порт в режим ожидания если соединение по "основному" порту восстановлено.
Failover Order
Данная опция отвечает за отказоустойчивость и имеет 3 разных статуса адаптера:
Active adapters
Адаптеры, используемые для передачи трафика.
Standby adapter
Адаптеры в режиме ожидания, используются если активные адаптеры дали сбой.
Unused adapters
Неиспользуемые для передачи трафика адаптеры.
Пример настройки
Пример показывает как с помощью vSphere Client можно настроить NIC Teaming на хосте с использованием Route based on IP hash.
В моем случае все физические порты ESXi хоста подключены к коммутатору Cisco, на котором уже собран EtherChannel
1. Выбираем необходимы хост и переходим во вкладку Configuration - Networking. По умолчанию в системе всегда уже имеется стандартный vSwitch - его свойства мы и откроем нажав на кнопку Properties.
2. В появившемся окне выбираем vSwitch и нажмем кнопку редактировать Edit
3. В появившемся окне откроем вкладку NIC Teaming и укажем следующие параметры:
Опцию Load Balancing установим в Route based on IP hash
Опцию Network Failure Detection установим в link status only
Опцию Notify Switches установим в Yes
Опцию Failback установим в Yes
Так же проследим, что все физические порты активированы и переведены в раздел Active Adapters
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Если зайти в настройки вКоммутатора или группы портов, то последней закладкой мы увидим «NIC Teaming», группировка контроллеров. Она нам потребуется в том случае, если к вКоммутатору у нас подключен более чем один физический сетевой контроллер сервера (vmnic).
А зачем мы можем захотеть, чтобы к одному вКоммутатору были подключены несколько vmnic? Ответ прост: для отказоустойчивости в первую очередь и для повышения пропускной способности сети - во вторую.
Обратите внимание. Если мы подключаем к одному виртуальному коммутатору, стандартному или распределенному, несколько физических сетевых контроллеров, то они должны быть из одного домена широковещательной рассылки. VMware не рекомендует подключать к одному вКоммутатору сетевые карты, подключенные в разные физические сети или разные VLAN: коммутаторы виртуальные обрабатывают только кадры Ethernet (второй уровень модели OSI) и не могут осуществлять маршрутизацию.
Если у вКоммутатора только один физический сетевой контроллер, то сам этот контроллер, его порт в физическом коммутаторе и физический коммутатор целиком являются единой точкой отказа. Поэтому для доступа в сеть критичных ВМ более чем правильно использовать два или более vmnic, подключенных в разные физические коммутаторы.
Но здесь встает вопрос политики их использования. Мы можем использовать конфигурацию, дающую лишь отказоустойчивость - когда работает только один vmnic, а остальные ожидают его выхода из строя, чтобы подменить его. Или мы можем задействовать сразу несколько сетевых контроллеров сервера, тем или иным образом балансируя между ними нагрузку.
Взглянем на окно настроек - рис. 2.32.
Failover Order. Самое нижнее поле позволяет выбрать используемые (Active Adapters), запасные (Standby Adapters) и неиспользуемые (Unused Adapters) физические сетевые контроллеры из подключенных к этому вКоммутатору. Если вы хотите, чтобы какие-то vmnic стали резервными и не были задействованы в нормальном режиме работы, тогда перемещайте их в группу Standby. Все (или несколько) оставляйте в Active, если хотите балансировку нагрузки. Ну а Unused обычно нужна на уровне групп портов - когда у вКоммутатора много каналов во внешнюю сеть, но трафик именно конкретной группы портов вы через какие-то пускать не хотите ни при каких обстоятельствах.
Failback. Эта настройка напрямую относится к Failover Order. Если у вас vmnic3 Active, а vmnic2 Standby, то в случае выхода из строя vmnic3 его подменит vmnic2. А что делать, когда vmnic3 вернется в строй? Вот если Failback выставлен в Yes, то vmnic2 опять станет Standby, а vmnic3 - опять Active. Соответственно, если Failback = No, то даже когда vmnic3 опять станет работоспособным, он станет Standby. Каким образом ESX(i) понимает, что vmnic неработоспособен? См. пункт Network Failover Detection.
Notify Switches. Эта настройка включает (Yes) или выключает (No) оповещение физических коммутаторов об изменениях в MAC-адресах ВМ на ESX(i). Когда вы создаете новую ВМ и подключаете ее к группе портов (как вариант -добавляете в ВМ еще один виртуальный сетевой контроллер) или когда трафик ВМ начинает идти через другой vmnic из-за сбоя ранее задействованного - тогда ESX(i) отправит пакет rarp с оповещением вида «Такой-то MAC-адрес теперь доступен на этом порту».
Рис. 2.32. Окно настроек группировки контроллеров -NIC Teaming
Рекомендуется выставлять в Yes для того, чтобы физические коммутаторы максимально быстро узнавали о том, на каком их порту доступен MAC-адрес ВМ. Однако некоторые приложения потребуют выключения этой функции, например кластер Microsoft NLB.
Network Failover Detection. Каким образом ESX(i) будет определять, что физический сетевой контроллер неработоспособен? Вариантов два:
- Link Status Only - когда критерием служит лишь наличие линка, сигнала. Подобный режим позволит обнаружить такие проблемы, как выход из строя самого vmnic, отключенный сетевой кабель, обесточенный физический коммутатор.
Такой подход не поможет определить сбой сети в случае неправильной настройки порта, например внесение его в неправильный VLAN и т. п. Также он не поможет в случае, если обрыв сети произошел где-то за физическим коммутатором;
- Beacon Probing - эта функция нужна только тогда, когда у вКоммутатора несколько внешних подключений (рис. 2.33) к разным физическим коммутаторам. При этой настройке, кроме проверки статуса подключения, виртуальный коммутатор еще рассылает (с интервалом порядка 5-10 секунд) через каждый свой vmnic широковещательные пакеты, содержащие MAC-адрес того сетевого интерфейса, через который они ушли. И ожидается, что каждый такой пакет, посланный с одного vmnic, будет принят на других vmnic этого вКоммутатора. Если этого не происходит - значит где-то по каким-то причинам сеть не работает.
Рис. 2.33. Пример конфигурации сети, при которой имеет смысл использовать Beacon Probing
В этом примере пакеты, посланные через vmnic5, не дойдут до клиентов, подключенных к «дальним» физическим коммутаторам. Если для определения отказов сети используется «Link status only» - то ESX(i) не сможет определить такую неработоспособность сети. А beaconing сможет - потому что широковещательные пакеты от vmnic5 не будут приняты на vmnic3 и vmnic2.
Но обратите внимание: если beacon-пакеты отправляются и не принимаются в конфигурации с двумя vmnic на вКоммутаторе, то невозможно определить, какой из них не надо использовать - ведь с обоих beacon-пакеты уходят и на оба не приходят.
Тогда вКоммутатор начинает работать в режиме «Shotgun», что здесь можно перевести как «двустволка», - начинает отправлять весь трафик через оба подключения, мол, через какой-то да дойдет.
Конечно, такой ситуации лучше избегать. Сделать это можно правильной структурой физической сети, чтобы какие-то проблемы в ней решались за счет Spanning Tree. Вообще, механизм beaconing позиционируется как крайнее сред ство - если вы не можете повлиять на правильность конфигурации сети на физической стороне, то подстрахуйтесь от сбоев с помощью beaconing. Но эффективнее, когда подобные сбои в сети устраняются средствами этой сети и beaconing вам не нужен.
Наконец, самая интересная настройка.
Load Balancing. В этом выпадающем меню вы можете выбрать, по какому алгоритму будет балансироваться трафик виртуальных машин между каналами во внешнюю сеть виртуального коммутатора, к которому они подключены.
- Route based on the originating port ID - балансировка по номеру порта. У каждой ВМ (у каждого виртуального сетевого контроллера в ВМ) есть порт в вКоммутаторе, к которому она подключена. При данном варианте настройки балансировки нагрузки трафик будет делиться по этим портам - весь трафик от одного порта вКоммутатора будет идти в какой-то один vmnic; трафик из другого порта - через другой vmnic и т. д. Выбор очередного vmnic осуществляется случайным образом, не по его загрузке. Данный метод балансировки нагрузки используется по умолчанию и является рекомендуемым. Рекомендуемым он является потому, что дает какую-никакую балансировку нагрузки, а накладные расходы на анализ трафика минимальны. Однако трафик от одного виртуального контроллера не получит полосы пропускания больше, чем дает один физический интерфейс, выступающий каналом во внешнюю сеть. Косвенный вывод отсюда - виртуальная машина с несколькими виртуальными сетевыми контроллерами сможет задействовать несколько каналов во внешнюю сеть;
- Route based on source MAC hash - балансировка по MAC-адресу источника. В этом случае трафик делится на основе MAC-адреса источника пакета. Таким образом, исходящий трафик делится точно так же, как и в случае балансировки по портам. На практике метод практически не применяется;
- Route based on ip hash - балансировка по хэшу (контрольной сумме) IP. Здесь критерием разделения трафика считается пара IP-источника - IP-получателя. Таким образом, трафик между одной ВМ и разными клиентами, в том числе за маршрутизатором, может выходить по разным vmnic. Этот метод балансировки нагрузки является самым эффективным, однако он может вызвать большую нагрузку на процессоры сервера, так как именно на них будет вычисляться хэш IP-адресов для каждого пакета.
Также этот метод балансировки требует настроенной группировки портов (известной как link aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) на физическом коммутаторе, к которому подключен коммутатор виртуальный. Это вызвано тем, что при данном методе балансировки нагрузки MAC-адрес одной ВМ может одновременно числиться на нескольких vmnic, как следствие - на нескольких портах коммутатора физического. Что не является допустимым в штатном режиме работы, без группировки портов.
В обратную сторону - если вы хотите настроить группировку портов между физическим и виртуальным коммутаторами, то вы настраиваете ее на физическом; а на виртуальном ставите балансировку по хэшу IP для нужных групп портов - и все.
Последний нюанс: если у вас один коммутатор виртуальный подключен к нескольким физическим (из соображений отказоустойчивости), то далеко не с любыми физическими коммутаторами получится использовать этот тип балансировки нагрузки в такой конфигурации.
ESX(i) не поддерживает автоматической настройки группировки портов с помощью Link Aggregation Control Protocol (LACP).
Link Aggregation (Etherchannel) на физическом коммутаторе должен быть настроен, только если на виртуальном коммутаторе используется балансировка нагрузки по IP;
- Route based on physical NIC load - этот метод балансировки нагрузки доступен только для распределенных коммутаторов и только начиная с ESX(i) версии 4.1. Суть данного механизма напоминает работу первого варианта балансировки - по Port ID. Однако есть и значительные различия. Во-первых, при принятии решения, через какой pNIC выпускать очередную «сессию», выбор осуществляется в зависимости от нагрузки на этот pNIC, а не случайным образом. Во-вторых, выбор повторяется каждые 30 секунд (в то время как во всех прочих вариантах однажды осуществленный выбор не меняется до выключения ВМ).
Резюме: рекомендуемым в общем случае является Route based on the physical NIC load - по совокупности характеристик. Он дает балансировку нагрузки с минимальными накладными расходами (но использовать этот метод балансировки возможно только на распределенных коммутаторах, и только начиная с версии 4.1). В случае если вы твердо уверены, что вам необходима большая эффективность балансировки, используйте Route based on ip hash. Пример такой ситуации - одна ВМ, генерирующая большой объем трафика и работающая с большим количеством клиентов. Однако если нет возможности настроить etherchannel на физическом коммутаторе, то Route based on ip hash использовать невозможно.
Если не подходят и Route based on ip hash, и Route based on physical NIC load, используйте Route based on the originating port ID.
Более эффективную балансировку нагрузки рекомендуется ставить лишь для той группы портов, для которой она необходима, - с целью свести к минимуму накладные расходы в виде нагрузки на CPU сервера.
Для распределенных виртуальных коммутаторов все так же, с поправкой на абстрактность каналов во внешнюю сеть, для которых выполняется эта настройка.
Читайте также: