Vmware notify switches что это
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- VMware Technology Network
- :
- Cloud & SDDC
- :
- VI 3.X
- :
- VI: VMware ESX™ 3.5 Discussions
- :
- Notify Switches - Any reasons why I should not set.
dahvaio
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I understand when Notify Switches would be set to No (NLB and Unicast); however, how does it impact the VM environment? I have to set it to NO in order to use NLB but I would like to know if setting it to NO is a negative thing.
Are there any problems which could arise by setting Notify Switches to NO? Could Virtual Machines go offline if a there is a NIC Failure? Or is it more of a nice to have features?
Any examples would be great.
PacketRacer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Yes, setting "Notify Switches" to No is a bad thing.
Here's why. Your VMware hosts are connected to physical network switches (hopefully at least two different ones for redundancy). Those switches have MAC address forwarding tables. The tables associate each MAC address to a physical switch port. When a frame comes in, the switch will look up the destination MAC address in the table and decide which physical port to send the frame to.
If a NIC failover occurs, your VMs will be talking through a different physical NIC. That also means a different port on the physical network switches. If you don't notify the network switches that something has changed they will continue to look up the old information from the tables and send the frames to the old port. Because the virtual machine is no longer at the old port, it won't get the frames. You will lose network connectivity.
That can continue for a little while - anywhere from a couple of seconds to a minute or two, until the switches update their tables. For more details, look up gratuitous ARP.
If you are running NLB, you need to do one of two things:
1) Set aside two physical NICs in each and every host, and dedicate those to NLB. Create a new vSwitch, assign the dedicated NLB NICs to this new vSwitch, and make sure your NLB servers use that switch only. This vSwitch using NLB will the only one where Notify Swtiches is set to No.
2) For large installs, if you have many NLB servers, you can just set aside two or three hosts and makes them a separate cluster. You can turn off HA in that cluster if you want. Then you can set Notify Switches to No and not worry about affecting the rest of your VMs.
В данной статье рассматриваются назначения 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
Settings: Network Failure Detection
Use the default setting: Link status only . Do not use Beacon probing for link failure detection. Beacon probing requires at least three physical NICs to avoid split-brain scenarios. For more details, see VMware KB 1005577.
Settings: Failback
This option determines how a physical adapter is returned to active duty after recovering from a failure. A failover event triggers the network traffic to move from one NIC to another. When a link up state is detected on the originating NIC, traffic automatically reverts to the original network adapter when Failback is set to Yes . When Failback is set to No , a manual failback is required.
Setting Failback to No can be useful in some situations. For example, after a physical switch port recovers from a failure, the port might be active but can take several seconds to begin forwarding traffic. Automatic Failback has been known to cause problems in certain environments that use the Spanning Tree Protocol. For more information about Spanning Tree Protocol (STP), see VMware KB 1003804.
VMkernel Port
Для каждого сервиса (vMotion, Management, NFS, FT) рекомендуется создавать отдельный VMkernel Port. Vmk для NFS-трафика (Available Services остается пустым) необходимо создавать в той же подсети, где будут находиться NFS-экспорты. В нашем случае:
VMkernel port | Available Services | Network Label | VLAN ID | MTU |
vmk0 | vMotion | vMotion | 1 | 9000 |
vmk1 | Management | Management | 2 | 9000 |
vmk2 | - | NFS | 3 | 9000 |
Для vMotion vmkernel-адаптера HP рекомендует установить «failover order» режим в Active/Standby:
«As this Scenario is based on an Active/Active configuration, to ensure that ALL VMotion traffic between servers within the enclosure is contained to the same module, on each server edit the VMotion vSwitch properties and move one of the Adapters to Standby. This will ensure that ALL VMotion traffic will occur on the same Virtual Connect module.»
Route based on source MAC hash
Данная опция схожа по принципу работы с Route based on IP hash, за исключением того, что политика рассматривает только MAC-адрес источника в кадре Ethernet.
Active 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
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.
Several load-balancing techniques are available for NIC teaming, and each technique has its pros and cons.
Failover Order
Данная опция отвечает за отказоустойчивость и имеет 3 разных статуса адаптера:
Use explicit failover order
Данная опция в действительности не выполняет никакой балансировки нагрузки и если у вас используется для подключения несколько физических портов то в любой момент времени использоваться будет только один. Сначала система пытается использовать первый активный физический сетевой порт. Если использовать первый физический порт не удаётся, то используется следующий активный физический порт и так далее.
Route Based on Physical NIC Load
Route Based on Physical NIC Load is based on Route Based on Originating Virtual Port , where the virtual switch monitors the actual load of the uplinks and takes steps to reduce load on overloaded uplinks. This load-balancing method is available only with a vSphere Distributed Switch, not on vSphere Standard Switches.
The distributed switch calculates uplinks for each VMkernel port by using the port ID and the number of uplinks in the NIC team. The distributed switch checks the uplinks every 30 seconds, and if the load exceeds 75 percent, the port ID of the VMkernel port with the highest I/O is moved to a different uplink.
No physical switch configuration is required.
Although vSAN has one VMkernel port, the same uplinks can be shared by other VMkernel ports or network services. vSAN can benefit by using different uplinks from other contending services, such as vMotion or management.
As vSAN typically only has one VMkernel port configured, its effectiveness is limited.
The ESXi VMkernel reevaluates the traffic load after each time interval, which can result in processing overhead.
Setting Failover Order
Failover order determines which links are active during normal operations, and which links are active in the event of a failover. Different supported configurations are possible for the vSAN network.
Active/Standby uplinks : If a failure occurs on an Active/Standby setup, the NIC driver notifies vSphere of a link down event on Uplink 1. The standby Uplink 2 becomes active, and traffic resumes on Uplink 2.
Active/Active uplinks : If you set the failover order to Active/Active, the virtual port used by vSAN traffic cannot use both physical ports at the same time.
If your NIC teaming configuration for both Uplink 1 and Uplink 2 is active, there is no need for the standby uplink to become active.
Note: When using an Active/Active configuration, ensure that Failback is set to No . For more information, see VMware KB 2072928.
В данной статье я хотел бы представить полезную информацию, собранную при проектировании и внедрении отказоустойчивой среды виртуализации. Особое внимание уделено нюансам работы HP Virtual Connect FlexFabric и конфигурации гипервизора VMware vSphere 5.5 при использовании Ethernet 10 Gbit и NFS в качестве Datastore.
Схема сетевого взаимодействия
«Железо»
Блейд-корзина «HP BladeSystem c7000» c парой модулей «HP VC FlexFabric 10/24».
Сервера «HP BL460c Gen8» со встроенной сетевой картой «HP FlexFabric 10Gb 536FLB».
Сетевые коммутаторы «Cisco Nexus 5k».
Система хранения данных «NetApp FAS8020».
Виртуальные коммутаторы
Рекомендуется разделять трафик виртуальных машин от трафика управления (vMotion, Management, NFS, FT). Для повышения надежности виртуальной среды мы использовали стандартный коммутатор для трафика управления, а не распределенный, хоть он и имеет ряд преимуществ (например, поддержка LACP).
Route based on IP hash
Данная опция используется совместно с группой агрегации каналов LAG, так же называется EtherChannel или Port Channel. Когда трафик попадает на vSwitch, политика балансировки каналов создаёт в пакете хеш IP-адреса источника и назначения. Результирующий хеш указывает какой физический порт будет использоваться.
Smart Link
Режим Smart Link должен быть включен для всех vNet (Ethernet Network) в конфигурации FlexFabric. Это необходимо, чтобы гипервизор правильно отработал балансировку в виртуальном коммутаторе.
Выдержка из документации: «HP’s Virtual Connect supports a feature called Smart Link, a network enabled with Smart Link automatically drops link to the server ports if all uplink ports lose link. This feature is very similar to the Uplink Failure Detection (UFD) that is available on the HP GbE2, GbE2c and most ProCurve switches. I believe there is a similar feature available on Cisco switches called Link State Tracking.»
Notify Switches
По умолчанию данный пункт установлен как "YES" и он позволяет уведомить коммутатор о том, что виртуальная машина использует другой физический порт, посылая специальный Reverse Address Resolution Protocol фрейм принимающим физическому коммутаторы для обновления таблицы MAC-адресов коммутатора.
Route based on the originating virtual port
Данная опция является стандартным для любого только что созданного vSwitch и каждая виртуальная машина и VMkernel порт на vSwitch подключён к виртуальному порту. Когда vSwitch получает трафик от подключённых к нему объектов он назначает виртуальный порт и физический порт и использует его для передачи данных. Выбранный физический порт не меняется до тех пор пока не произойдёт какая либо ошибка или виртуальная машина не выключится или не мигрирует на другой сервер.
Standby adapter
Адаптеры в режиме ожидания, используются если активные адаптеры дали сбой.
Flow Control
В вопросе использования механизма «Flow Control» мы решили придерживаться рекомендации NetApp и отключить его на всех «уровнях» (ESXi, FlexFabric, Network, Storage).
Рекомендация NetApp: «Modern network equipment and protocols handle port congestion better than those in the past. NFS and iSCSI as implemented in ESXi use TCP. TCP has built-in congestion management, making Ethernet flow control unnecessary. Furthermore, Ethernet flow control can actually introduce performance issues on other servers when a slow receiver sends a pause frame to storage and stops all traffic coming out of that port until the slow receiver sends a resume frame. Although NetApp has previously recommended flow control set to send on ESXi hosts and NetApp storage controllers, the current recommendation is to disable flow control on ESXi, NetApp storage, and on the switches ports connected to ESXi and NetApp storage.»
В конфигурации модулей «HP VC FlexFabric» Flow Control по умолчанию включен только на downlink-ах (значение «Auto»), а на uplink-ах выключено.
«ON» — all ports will advertise support for flow control (if autoneg), or flowcontrol turned on (non-autoneg).
«OFF» — all ports will advertise *no* support for flow control (if autoneg), or flowcontrol turned off (non-autoneg).
«Auto» — all uplink/stacking links will behave like «OFF», and all server links behave like «ON».
Unused adapters
Неиспользуемые для передачи трафика адаптеры.
Failback
Данная опция отвечает за активацию физического порта, который находится в режиме ожидания если больше нет ни одно активного физического порта. Опция представляет своего рода активацию запасного порта на случай сбоя активного порта. Так же система переводит "запасной" порт в режим ожидания если соединение по "основному" порту восстановлено.
Cisco Discovery Protocol
К сожалению, CDP не поддерживается модулями «HP VC FlexFabric», поэтому включать ее поддержку на гипервизоре смысла нет.
Выдержка из документации: «Virtual Connect does not support CDP. VC does support the industry standard protocol called Link Layer Discovery Protocol (LLDP) by default. LLDP is functionally equivalent to CDP, although the two protocols are not compatible.»
vSphere vSwitch Load Balancing
В подобной конфигурации в виртуальных коммутаторах рекомендуется использовать режим балансировки нагрузки «Route based on the originating virtual port id».
Режим «Route Based on IP Hash» (рекомендация NetApp) использоваться не может, так как для этого требуется объединение его uplink-ов (виртуального коммутатора) в транк по протоколу 802.3ad, а HP VC FlexFabric не предоставляет такую возможность для downlink к серверам.
Остальные настройки Load Balancing Policy:
Network failure detection: Link status only.
Notify switches: Yes.
Failback: Yes.
Route Based on Originating Virtual Port
In Active/Active or Active/Passive configurations, use Route based on originating virtual port for basic NIC teaming. When this policy is in effect, only one physical NIC is used per VMkernel port.
This is the simplest NIC teaming method that requires minimal physical switch configuration.
This method requires only a single port for vSAN traffic, which simplifies troubleshooting.
A single VMkernel interface is limited to a single physical NIC's bandwidth. As typical vSAN environments use one VMkernel adapter, only one physical NIC in the team is used.
Jumbo Frames
Чтобы получить максимальную выгоду от 10 Gbit рекомендуется включать Jumbo Frames на всех уровнях:
VMkernel port | vSwitch | FlexFabric | Network | Storage | |
Значение | 9000 | 9000 | 9216 | 9216 | 9000 |
Значение MTU в HP Virtual Connect «зашито» на значение 9216 и не может быть изменено.
Агрегирование каналов
Агрегация каналов является одним из основных средств достижения высокой отказоустойчивости виртуальной среды, поэтому необходимо использовать это на всех уровнях прохождения трафика. В нашем случае:
ESXi | FlexFabric | Network | Storage |
vSphere vSwitch в режиме «Port ID» | Shared Uplink Set + режим «Auto» (LACP) | EtherChannel (LACP) | lif |
Settings: Notify Switches
Use the default setting: Yes . Physical switches have MAC address forwarding tables to associate each MAC address with a physical switch port. When a frame comes in, the switch determines the destination MAC address in the table and decides the correct physical port.
If a NIC failover occurs, the ESXi host must notify the network switches that something has changed, or the physical switch might continue to use the old information and send the frames to the wrong port.
When you set Notify Switches to Yes , if one physical NIC fails and traffic is rerouted to a different physical NIC in the team, the virtual switch sends notifications over the network to update the lookup tables on physical switches.
This setting does not catch VLAN misconfigurations, or uplink losses that occur further upstream in the network. The vSAN network partitions health check can detect these issues.
link status only
Данная опция позволяет определить ошибки, вызванные отключением кабеля или проблемой физического интерфейса и не способна определять конфигурационный ошибки, такие как если физический коммутатор заблокировал порт из-за ошибок конфигурации VLAN,spanning tree или отключения кабеля на другой стороне физического коммутатора.
Beacon probing
Данная опция отправляет и слушает специальные пакеты-маяки на все физические интерфейсы в группе и использует полученную информацию. В дополнение так же использует статус физического порта для определения проблемы подключения. Данная опция способна более точно определить проблему в отличие от link status only.
Не используйте Beacon probing вместе с Route based on IP hash чтобы избежать ложных срабатываний.
NFS Advanced Settings
Рекомендуется изменять стандартные значения некоторых параметров работы с NFS-экспортами. Для каждого vSphere хоста в Advanced Settings устанавливаем следующие значения:
NFS.HeartbeatFrequency = 12
NFS.HeartbeatTimeout = 5
NFS.HeartbeatMaxFailures = 10
Net.TcpipHeapSize = 32
Net.TcpipHeapMax = 512
NFS.MaxVolumes = 256
NFS.MaxQueueDepth = 64
Network Failure Detection
Данный пункт отвечает за определение ошибок в подключении физических портов и имеет две опции.
Читайте также: