vmware notify switches что это
Include two or more physical NICs in a team to increase the network capacity of a vSphere Standard Switch or standard port group. Configure failover order to determine how network traffic is rerouted in case of adapter failure. Select a load balancing algorithm to determine how the standard switch distributes the traffic between the physical NICs in a team.
Configure NIC teaming, failover, and load balancing depending on the network configuration on the physical switch and the topology of the standard switch. See Teaming and Failover Policy and Load Balancing Algorithms Available for Virtual Switches for more information.
If you configure the teaming and failover policy on a standard switch, the policy is propagated to all port groups in the switch. If you configure the policy on a standard port group, it overrides the policy inherited from the switch.
Procedure
IP-based teaming requires that the physical switch is configured with EtherChannel.
Relies only on the link status that the network adapter provides. This option detects failures such as removed cables and physical switch power failures.
Sends out and listens for beacon probes on all NICs in the team, and uses this information, in addition to link status, to determine link failure. ESXi sends beacon packets every second.
The NICs must be in an active/active or active/standby configuration because the NICs in an unused state do not participate in beacon probing.
If failback is set to No for a standard port, a failed adapter is left inactive after recovery until another currently active adapter fails and must be replaced.
NIC Teaming в VmWare ESXi
Общая
В данной статье рассматриваются назначения 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
Данная опция является стандартным для любого только что созданного 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
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
The vSwitch “Notify Switches” setting
On the vSphere virtual switch we have the possibility to enable or disable the option of “Notify Switches”. In this post we shall see what this setting actually does and how it works, as well as discussing if the RARP protocol is important.
To see the current setting or to change it, select Properties on a vSwitch, then Edit and then the NIC Teaming tab.
When having the value set to Yes it will basically give ESXi the permission to sometimes send faked frames on behalf of the Virtual Machines running on the host.
The goal for sending these frames is to make sure the physical switches in the network learns the location of the Virtual Machines. A physical switch does this learning by observing each incoming frame and make a note of the field called Source MAC Address. Based on that information the switches build tables with mappings between MAC addresses and the switch port where this address could be found.
There are at least three different occasions where these messages are sent by ESXi:
1. When a Virtual Machine is powered on the ESXi host will make sure the network are aware of this new VM and its MAC address as well as its physical location (switch port).
2. When a Virtual Machine is moved by vMotion to another host it will be very crucial to rapidly notify the physical network of the new placement of the virtual server.
3. If a physical NIC on the host loses the connection, but we had at least two vmnics as uplinks on the vSwitch all traffic from the VMs will be “moved” to the remaining interface. Also in this situation the ESXi host must very quickly inform the network of the new correct uplink to reach the VM.
The protocol used is RARP – Reverse Address Resolution Protocol. Sometimes in texts about vSphere it is implied that RARP itself is important and actually does something in this process. However, RARP is a very old and obsolete protocol which almost no operating systems or devices has support for today.
So why send frames that almost nobody could read? The reason is that it is only important that all physical switches sees the Source MAC address and learn the new location and in reality the payload (in this case RARP) could be almost anything.
Here we see a virtual machine with a certain MAC address. This VM is being migrated with vMotion and with Wireshark we shall see which RARP frames being sent.
In this packet trace we can notice that the ESXi host is sending RARP frames with the VM as source MAC and also that it wants to be very certain that every switch has been reached by this new information – and actually sends the frame ten times. First several times close together and then more spread in time, with the last frame almost one minute after the first information frame.
How could we be sure that all switches on the physical network does see these frames? This is because of the destination is the special broadcast address FF-FF-FF-FF-FF-FF. The broadcast address forces all switches to forward the frame on all ports and makes the whole broadcast domain aware of the new location.
If the Notify Switches settings for some reason is set to No then the behavior is changed and the host will be silent when actions like VM power-on, vMotion and vmnic link failure take place. It will likely still work, but a much higher risk of packet loss in the above situations.
In summary, the Notify Switches function is very useful and should be set to Yes to allow the ESXi host acting as the virtual machines and sends faked frames to make sure all physical switches MAC-to-port mapping tables are quickly updated.
nic teaming. группировка сетевых контроллеров
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Если зайти в настройки вКоммутатора или группы портов, то последней закладкой мы увидим «NIC Teaming», группировка контроллеров. Она нам потребуется в том случае, если к вКоммутатору у нас подключен более чем один физический сетевой контроллер сервера (vmnic).
Обратите внимание. Если мы подключаем к одному виртуальному коммутатору, стандартному или распределенному, несколько физических сетевых контроллеров, то они должны быть из одного домена широковещательной рассылки. VMware не рекомендует подключать к одному вКоммутатору сетевые карты, подключенные в разные физические сети или разные VLAN: коммутаторы виртуальные обрабатывают только кадры Ethernet (второй уровень модели OSI) и не могут осуществлять маршрутизацию.
Если у вКоммутатора только один физический сетевой контроллер, то сам этот контроллер, его порт в физическом коммутаторе и физический коммутатор целиком являются единой точкой отказа. Поэтому для доступа в сеть критичных ВМ более чем правильно использовать два или более vmnic, подключенных в разные физические коммутаторы.
Рекомендуется выставлять в Yes для того, чтобы физические коммутаторы максимально быстро узнавали о том, на каком их порту доступен MAC-адрес ВМ. Однако некоторые приложения потребуют выключения этой функции, например кластер Microsoft NLB.
Network Failover Detection. Каким образом ESX(i) будет определять, что физический сетевой контроллер неработоспособен? Вариантов два:
Такой подход не поможет определить сбой сети в случае неправильной настройки порта, например внесение его в неправильный VLAN и т. п. Также он не поможет в случае, если обрыв сети произошел где-то за физическим коммутатором;
Рис. 2.33. Пример конфигурации сети, при которой имеет смысл использовать Beacon Probing
Наконец, самая интересная настройка.
Load Balancing. В этом выпадающем меню вы можете выбрать, по какому алгоритму будет балансироваться трафик виртуальных машин между каналами во внешнюю сеть виртуального коммутатора, к которому они подключены.
Последний нюанс: если у вас один коммутатор виртуальный подключен к нескольким физическим (из соображений отказоустойчивости), то далеко не с любыми физическими коммутаторами получится использовать этот тип балансировки нагрузки в такой конфигурации.
ESX(i) не поддерживает автоматической настройки группировки портов с помощью Link Aggregation Control Protocol (LACP).
Link Aggregation (Etherchannel) на физическом коммутаторе должен быть настроен, только если на виртуальном коммутаторе используется балансировка нагрузки по IP;
Если не подходят и Route based on ip hash, и Route based on physical NIC load, используйте Route based on the originating port ID.
Для распределенных виртуальных коммутаторов все так же, с поправкой на абстрактность каналов во внешнюю сеть, для которых выполняется эта настройка.
Записки виртуального админа
Новости, обзоры и заметки о виртуальных машинах и платформах виртуализации.
среда, 20 октября 2010 г.
Существует много статей о том, как сконфигурировать сеть на VMware ESX, но они по большей части на английском, либо затрагивают возможности тонкой настройки сети. Судя по вопросам, чаще всего задаваемым мне, у многих российских администраторов не хватает как раз базовых знаний и понимания, как все работает. Постараюсь в нескольких постах раскрыть тему сетей в VMware vSphere.
На одном ESX хосте можно создать до 248 Standard vSwitch (vSphere 4.0 Configration Maximums). Следующий рисунок показывает довольно распространенный вариант использования нескольких vSwitch для разделения трафика.
Так выглядит отказоустойчивость в физической среде.
Легко заметить, что количество сетевых портов сократилось с 8 до 2 при сохранении эффективного уровная отказоустойчивости.
Небольшой пример. Скажем, у нас есть сервер, которому требуется доступ в несколько VLAN’ов.
Если мы сделаем то же самое в виртуальной инфраструктуре, картинка будет такой.
Обратите внимание, что для виртуальной машины не требуется Storage VLAN, он обрабатывается на уровне ESX и предоставляется ВМ в форме SCSI устройств.
А если машин становится больше, то дополнительных портов нам все равно не требуется.
Краткое представление и VLANах и EST режиме мы получили, теперь перейдем к VST режиму. Для включения VST режима достаточно указать VLAN ID в свойствах портгруппы. Обратите особое внимание, что для работы в VST режиме ваш физический коммутатор, к которому подключен ESX, должен уметь работать с 802.1Q трафиком!
Теперь мы можем избавиться от лишних сетевых интерфейсов, пустив весь трафик по одному транку. vSwitch автоматически определит кому предназначен трафик, отрежет VLAN тэг и направит пакет в требуемый vNIC.
А помните что мы говорили об уровне L2 и vSwitch? vSwitch не может маршрутизировать трафик между разными VLAN, поэтому для того, чтобы ВМ из VLAN 100 смогли работать с ВМ из VLAN 200, пакеты должны выйти из vSwitсh по аплинк-порту (pNIC) и добраться до L3 устройства (маршрутизатора).
При написании статьи использованы материалы «The Great vSwitch Debate» by Ken Cline.