![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
robopet3Еще раз про VMware, vswitch и LAG (Etherchannel, bonding)
Коллеги регулярно читают какие-то смутные переводы, а скорее пересказы концепции «два провода лучше одного» и собирают в Vmware Link aggregation (LAG / (Etherchannel)). Эта статья – попытка в очередной раз разобраться, нужен ли он для связи сервера esxi и физического коммутатора, и если нужен, то зачем.
Сначала немного общей теории.
Сам процесс сборки группы описан в стандарте IEEE 802.3ad https://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf и статье на википедии https://en.wikipedia.org/wiki/Link_aggregation
С точки зрения сети он существует в 2 видах – для L2 сетей и коммутаторов, и для L3. Поскольку виртуальный коммутатор (vswitch \ dvswitch) не является L3 устройством, то есть не выполняет маршрутизацию*, то все что связано с L3 для данной статьи не актуально. L2 LAG существует в трех вариантах – 1) статическая сборка, 2) стандартизированный протокол LACP 3) проприетарные (вендорские) варианты протоколов – Cisco EtherChannel and Port Aggregation Protocol, Juniper's Aggregated Ethernet, и так далее.
* Примечание: это не мешает виртуальному коммутатору смотреть в пакеты и делать балансировку на основе - Route Based on IP Hash.
Если рассмотреть связь коммутатор-коммутатор (когда по умолчанию с одной стороны трафика на 8-12-и до 48 портов, в модульных коммутаторах – наследниках Cisco 6500 – 9400 – 9500 – и существенно больше), то в таких случаях LAG повышает совокупную производительность связи. Однако LAG и добавляет проблем, если с обеих сторон установлены стеки устройств или регулярно разваливающийся MLAG с split-brain. Но это уже проблемы сетевиков, как и понимание что такое UDLD/BFD и работа RFC 7130 - Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces. Подробности можно прочитать тут:
John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread)
https://twitter.com/Lost_Signal/status/1368775901157224449
Тем не менее, если рассматривать одинокую сессию, между двумя серверами, у которых постоянно одинаковые IP, MAC и порт сессии – то есть, если приложение не умеет оперировать несколькими сессиями (как SMB Multichannel) – то, вне зависимости от алгоритма, одинарная сессия все равно окажется на одном порту, и максимальная скорость одинарной сессии будет равна скорости одинарного физического порта. О чем вам с удовольствием поведает iPerf.
Ключевые отличия vswitch \ dvswitch (VMware vSphere Distributed Switch (VDS)) от физического коммутатора.
Прежде всего, это не физический коммутатор – поэтому его скорость работы внутри одного хоста не ограничена жестко портами, а ограничивается скоростью работы оперативной памяти. Аналогично, даже между физическими хостами vmxnet3 с заявленными 10G может выдать 20-25G, см. тесты Testing vmxnet3 speed (2020) https://vinfrastructure.it/2020/03/testing-vmxnet3-speed/
Во вторых, поскольку это не физический свитч, то никакой пересылки «сразу» между портами не будет, и без многочисленных ухищрений (причем, не на уровне vswitch) вы петлю НЕ соберете*. То есть МОЖНО И НУЖНО включать 2 и более физических порта в vswitch, НЕ собирая LAG.
Примечание: такая хорошая ситуация существует в ESXi и Hyper-V. Какие-то одаренные в 2021 году смогли сделать так, что в каком-то варианте импортозаместительной виртуализации – петля на виртуальном коммутаторе Linux собирается. Возможно, уже проблему закрыли, но она была.
Итак, зачем обычно пытаются собрать LAG, руководствуясь, зачастую, общими принципами «2 > 1» ?
Отказоустойчивость (два канала же) и скорость (без уточнений). Знающие люди еще добавляют про скорость сходимости при сбое (и потом мерзко хихикают).
Отказоустойчивость: для работы одновременно 2 сетевых карт в Vmware никакой сборки LAG не нужно – достаточно на виртуальном свиче сделать группу (Team Physical Adapters), и добавить туда сетевые карты – хоть в Active-Active, хоть как.
Данная конфигурация описана в документации, разделы
What is Teaming and Failover Policy
https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html
- Add and Team Physical Adapters in a vSphere Standard Switch https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-DFE769C9-9A9C-4CDB-A0BC-2B17931B75A5.html
- Teaming and Failover Policy https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html
- Configure NIC Teaming, Failover, and Load Balancing on a vSphere Standard Switch or Standard Port Group https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html
- Load Balancing Algorithms Available for Virtual Switches
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-959E1CFE-2AE4-4A67-B4D4-2D2E13765715.html#GUID-959E1CFE-2AE4-4A67-B4D4-2D2E13765715
Поэтому, если не рассматривать скорость сходимости, а точнее восстановления доступа при сбое порта с любой стороны и настройку Changing the network teaming failback delay fails in ESXi (2014075) https://kb.vmware.com/s/article/2014075 - то особых плюсов для отказоустойчивости LAG не дает.
Что со скоростью?
Со скоростью в рамках одного потока – внезапно, но то же самое. Проблема в том, что если мы пойдем по стеку чуть выше, и начнем рассматривать TCP сессию, то она подразумевает, что очень желательно, чтобы пакеты приходили почти по порядку, см. Etherchannels And LAGs https://networkdirection.net/articles/routingandswitching/etherchannelsandlags/
Там это упомянуто очень косвенно, как “A major advantage of ‘pinning’ a traffic flow to a single link is that it limits the possibility of TCP packets being received out of order, and needing to be reassembled.”
То есть при работе в несколько потоков (что умеют далеко не все приложения) рост скорости будет, а вот при работе в малого размера инфраструктуре – будет то, что описано в документации:
Route Based on IP Hash: However, if your environment has a small number of IP addresses, the virtual switch might consistently pass the traffic through one uplink in the team. For example, if you have a database server that is accessed by one application server, the virtual switch always calculates the same uplink, because only one source-destination pair exists.
Но при этом вы все равно получаете проблему необходимости сборки LAG - Route Based on IP Hash: ESXi hosts support only 802.3ad link aggregation in Static mode . You can only use a static Etherchannel with vSphere Standard Switches. LACP is not supported. If you enable IP hash load balancing without 802.3ad link aggregation and the reverse, you might experience networking disruptions.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-523FDFBD-EAEC-44A5-9451-F63EB792F156.html
Configure NIC Teaming, Failover, and Load Balancing on a Distributed Port Group or Distributed Port : IP-based teaming requires that the physical switch is configured with EtherChannel.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-73AB2E00-FE02-4D1B-970F-7D2F21F52825.html
Неприятное, лежащее чуть глубже в документации
Understanding IP Hash load balancing (2006129): https://kb.vmware.com/s/article/2006129
Route Based on Originating Port ID - A single virtual NIC cannot use more than a single physical NIC's bandwidth. For example, if four 1 Gb NICs are in a team, a virtual machine with a single virtual NIC cannot use more than 1 Gb of bandwidth via a single adapter.
Route Based on IP Hash: Route based on IP Hash load balancing requires that the physical switch ports be combined into an EtherChannel (sometimes called an aggregation bond, port-channel). This ensures that the same hashing algorithm is used for traffic returning in the opposite direction. Beacon probing is not supported with IP Hash. Only link status can be used as a failure detection method. If a link fails without the link state going down, there is no way to avoid network communication issues on the vSwitch.
Но при этом метод определения состояния линка Link status only имеет ряд ограничений: Teaming and Failover Policy: However, link status does not detect the following configuration errors:
Physical switch port that is blocked by spanning tree or is misconfigured to the wrong VLAN .
Pulled cable that connects a physical switch to another networking devices, for example, an upstream switch .
И еще неприятное:
Кроме проблем с отладкой и ошибочными настройками на стороне коммутаторов и проблем с самими коммутаторами, на данный момент для RDMA не работает LAG в следующих случаях:
The Basics of Remote Direct Memory Access (RDMA) in vSphere: PVRDMA does not support NIC teaming. The HCA must be the only uplink on the vSphere (Distributed) Switch
vSphere RDMA: vSAN with RDMA supports NIC failover, but does not support LACP or IP-hash-based NIC teaming.
Agents: If Link Aggregation Control Protocol (LACP) is used on an ESXi host that is a member of a vSAN cluster, don’t restart ESXi management agents with the services.sh command.
Use /etc/init.d/module restart to restart the independent services.
Чего делать-то??
Ранее упомянутый текст John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread)
https://twitter.com/Lost_Signal/status/1368775901157224449
содержит ответы на основные вопросы - What else can I do instead?
1. MPIO for iSCSI
2. Multiple VMKernel ports for vMotion.
3. LBT (Load Based Teaming) for most other things.
4. Active/passive comfigs (vSAN down path A, vMotion down path B and cross failover).
5. Remember to turn on NIOC.
6. Tag backups to lower COS.
7. Turn on the vSAN performance service and update vSphere and realize your LAG is the cause of all those network metrics looking ugly.
8. Commit today, to stop buying 10Gbps. 25Gbps at worst, and 100Gbps from here on out.
9. Stop using FEXs
10. Don’t use the native VLAN.
11. Recognize that RDMA is going to sneak into your DC soon, and if you think LAGs suck, try making them work with RCoEv2
Подводя итог.
В самом по себе LAG в вариантах выше ничего плохого нет. Но его использование
- усложняет отладку (troubleshooting)
- усложняет сетевую конфигурацию и на свичах, и на хостах.
- в случае сбоев MLAG и стека вы получите или просто проблемы, или потерю сети.
- не дает в ряде сценариев, где он бы был так нужен, каких-то плюсов по скорости
- не может быть использован в ряде современных сценариев (RDMA, vSAN)
- теоретическая польза от него появляется только при использовании Distributed vSwitch (DVS, dvswitch), а DVS сам по себе добавляет проблем и с очень осторожным конфигурированием, и с ephemeral port binding.
- лично я не очень люблю DVS, в ряде случаев может оказаться проще один раз написать конфигурацию хоста через Get-VirtualPortGroup \ New-VirtualPortGroup \ Set-VirtualPortGroup и затем из единого хранилища конфигурации одннобразно управлять разными хостами. Но, иногда у DVS есть и плюсы, оправдывающие закупку соответствующих лицензий
- У некоторых протоколов – iSCSI, SMB – есть MPIO, позволяющее гораздо лучше балансировать поток данных. При этом у некоторых СХД (Netapp) при работе с NFS (который изначально не поддерживал MPIO) можно получить проблемы в связи с тем, что время переключения выше таймаута в Vmware и можно получить All path down. MPIO в NFS появился только в NFS 4.1
То есть, перед внедрением LAG необходимо перечитать литературу по списку ниже, проверить рабочие сценарии обработки отказа, выписать себе в таблицу плюсы и минус внедрения, и в обязательном порядке собрать тестовый стенд, где проверить реальную скорость и сети через iperf, и СХД (в случае iCSI \ NFS) через DiskSPD, Atto и прочие HCI – получили ли, что хотели, и будет ли рост скорости в том сценарии, для которого это затевалось. См. список литературы.
Литература к обязательному изучению.
Заранее извините, что часть ссылок на документацию ведет на 7, а часть уже на 8-ю версию.
M-LAG как альтернатива STP и стека - https://habr.com/ru/company/muk/blog/225479/
Объединяй коммутаторы и властвуй — сравниваем Stack и MLAG https://habr.com/ru/company/selectel/blog/676740/
vSwitch Load Balancing: Source MAC Hash https://babarmunir.wordpress.com/2021/05/12/vswitch-load-balancing-source-mac-hash/
Etherchannels And LAGs https://networkdirection.net/articles/routingandswitching/etherchannelsandlags/
Configuring LAG Settings on a Switch through the Command Line Interface (CLI)
https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-550x-series-stackable-managed-switches/smb5848-configuring-lag-settings-on-a-switch-through-cli.html
vSphere Distributed Switch - Lightning Lab (HOL-2210-91-SDC) - https://hol.vmware.com/catalog/
Testing vmxnet3 speed (2020) https://vinfrastructure.it/2020/03/testing-vmxnet3-speed/
Maximum traffic for a vmxnet3 (2015) https://communities.vmware.com/t5/Virtual-Machine-Guest-OS-and-VM/Maximum-traffic-for-a-vmxnet3/td-p/969636
vSphere Distributed Switch Part 19 – Understanding vSwitch Network Load Balancing policies
http://www.idz.vn/2016/03/vsphere-distributed-switch-part-19_25.html
Setting the vSwitch load balance policy using command line on an ESX host (1005833)
https://kb.vmware.com/s/article/1005833
John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread)
https://twitter.com/Lost_Signal/status/1368775901157224449
Understanding IP Hash load balancing (2006129) https://kb.vmware.com/s/article/2006129
vSwitch Load Balancing: Source MAC Hash https://babarmunir.wordpress.com/2021/05/12/vswitch-load-balancing-source-mac-hash/
Add and Team Physical Adapters in a vSphere Standard Switch
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-DFE769C9-9A9C-4CDB-A0BC-2B17931B75A5.html
Configure NIC Teaming, Failover, and Load Balancing on a vSphere Standard Switch or Standard Port Group
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html
NIC teaming in ESXi and ESX (1004088)
https://kb.vmware.com/s/article/1004088
Changing the network teaming failback delay fails in ESXi (2014075)
https://kb.vmware.com/s/article/2014075
The Basics of Remote Direct Memory Access (RDMA) in vSphere
https://core.vmware.com/resource/basics-remote-direct-memory-access-rdma-vsphere#section1
Configure Remote Direct Memory Access Network Adapters
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-C44D4A9D-FEAA-4BA9-9C3C-FC8CC3DE4837.html
Configure VMkernel Binding for the RDMA Adapter
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-EADAE1EF-1DE6-44C9-9DB6-051F88958D8F.html
Host requirements for link aggregation (etherchannel, port channel, or LACP) in ESXi (1001938)
https://kb.vmware.com/s/article/1001938
About vSAN Network Design (особенно в части Air gap)
https://docs.vmware.com/en/VMware-vSphere/7.0/vsan-network-design-guide/GUID-40DE7266-BBE8-49DB-907E-DF2DE16AA716.html
Understanding Network Air Gaps
https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-network-design-guide/GUID-69DD2619-B768-46CB-89A3-8C1FD1F46B61.html
Pros and Cons of Air Gap Network Configurations with vSAN
https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-network-design-guide/GUID-954378E3-03C3-4FAD-B67E-90C6633F6F9E.html
Static (non-ephemeral) or ephemeral port binding on a vSphere Distributed Switch (1022312)
https://kb.vmware.com/s/article/1022312
VSphere Standard Switch vs. Distributed Switch: The differences
https://www.techtarget.com/searchvmware/tip/VSphere-Standard-Switch-vs-Distributed-Switch-The-differences
NFS Multipathing
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-0C797E03-F68D-4BE1-BA35-74337F3DBE5A.html
Best practices for performing the storage performance tests within a virtualized environment (2019131)
https://kb.vmware.com/s/article/2019131
Testing virtual machine storage I/O performance for ESX and ESXi (1006821)
https://kb.vmware.com/s/article/1006821
Command line tool for datastore performance test in ESXi 6
https://communities.vmware.com/t5/ESXi-Discussions/Command-line-tool-for-datastore-performance-test-in-ESXi-6/m-p/1777185
What is the latency stat QAVG?
https://www.codyhosterman.com/2018/03/what-is-the-latency-stat-qavg/
Как устроена цепочка сетевого стека VMware ESXi на уровне виртуального коммутатора - Network IOChain.
https://www.vmgu.ru/news/vmware-vswitch-networking-iochain
Полезные утилиты для решения проблем в сетевом стеке VMware vSphere.
https://www.vmgu.ru/news/vmware-vsphere-esxi-useful-network-tools
Коллеги регулярно читают какие-то смутные переводы, а скорее пересказы концепции «два провода лучше одного» и собирают в Vmware Link aggregation (LAG / (Etherchannel)). Эта статья – попытка в очередной раз разобраться, нужен ли он для связи сервера esxi и физического коммутатора, и если нужен, то зачем.
Сначала немного общей теории.
Сам процесс сборки группы описан в стандарте IEEE 802.3ad https://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf и статье на википедии https://en.wikipedia.org/wiki/Link_aggregation
С точки зрения сети он существует в 2 видах – для L2 сетей и коммутаторов, и для L3. Поскольку виртуальный коммутатор (vswitch \ dvswitch) не является L3 устройством, то есть не выполняет маршрутизацию*, то все что связано с L3 для данной статьи не актуально. L2 LAG существует в трех вариантах – 1) статическая сборка, 2) стандартизированный протокол LACP 3) проприетарные (вендорские) варианты протоколов – Cisco EtherChannel and Port Aggregation Protocol, Juniper's Aggregated Ethernet, и так далее.
* Примечание: это не мешает виртуальному коммутатору смотреть в пакеты и делать балансировку на основе - Route Based on IP Hash.
Если рассмотреть связь коммутатор-коммутатор (когда по умолчанию с одной стороны трафика на 8-12-и до 48 портов, в модульных коммутаторах – наследниках Cisco 6500 – 9400 – 9500 – и существенно больше), то в таких случаях LAG повышает совокупную производительность связи. Однако LAG и добавляет проблем, если с обеих сторон установлены стеки устройств или регулярно разваливающийся MLAG с split-brain. Но это уже проблемы сетевиков, как и понимание что такое UDLD/BFD и работа RFC 7130 - Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces. Подробности можно прочитать тут:
John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread)
https://twitter.com/Lost_Signal/status/1368775901157224449
Тем не менее, если рассматривать одинокую сессию, между двумя серверами, у которых постоянно одинаковые IP, MAC и порт сессии – то есть, если приложение не умеет оперировать несколькими сессиями (как SMB Multichannel) – то, вне зависимости от алгоритма, одинарная сессия все равно окажется на одном порту, и максимальная скорость одинарной сессии будет равна скорости одинарного физического порта. О чем вам с удовольствием поведает iPerf.
Ключевые отличия vswitch \ dvswitch (VMware vSphere Distributed Switch (VDS)) от физического коммутатора.
Прежде всего, это не физический коммутатор – поэтому его скорость работы внутри одного хоста не ограничена жестко портами, а ограничивается скоростью работы оперативной памяти. Аналогично, даже между физическими хостами vmxnet3 с заявленными 10G может выдать 20-25G, см. тесты Testing vmxnet3 speed (2020) https://vinfrastructure.it/2020/03/testing-vmxnet3-speed/
Во вторых, поскольку это не физический свитч, то никакой пересылки «сразу» между портами не будет, и без многочисленных ухищрений (причем, не на уровне vswitch) вы петлю НЕ соберете*. То есть МОЖНО И НУЖНО включать 2 и более физических порта в vswitch, НЕ собирая LAG.
Примечание: такая хорошая ситуация существует в ESXi и Hyper-V. Какие-то одаренные в 2021 году смогли сделать так, что в каком-то варианте импортозаместительной виртуализации – петля на виртуальном коммутаторе Linux собирается. Возможно, уже проблему закрыли, но она была.
Итак, зачем обычно пытаются собрать LAG, руководствуясь, зачастую, общими принципами «2 > 1» ?
Отказоустойчивость (два канала же) и скорость (без уточнений). Знающие люди еще добавляют про скорость сходимости при сбое (и потом мерзко хихикают).
Отказоустойчивость: для работы одновременно 2 сетевых карт в Vmware никакой сборки LAG не нужно – достаточно на виртуальном свиче сделать группу (Team Physical Adapters), и добавить туда сетевые карты – хоть в Active-Active, хоть как.
Данная конфигурация описана в документации, разделы
What is Teaming and Failover Policy
https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html
- Add and Team Physical Adapters in a vSphere Standard Switch https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-DFE769C9-9A9C-4CDB-A0BC-2B17931B75A5.html
- Teaming and Failover Policy https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html
- Configure NIC Teaming, Failover, and Load Balancing on a vSphere Standard Switch or Standard Port Group https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html
- Load Balancing Algorithms Available for Virtual Switches
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-959E1CFE-2AE4-4A67-B4D4-2D2E13765715.html#GUID-959E1CFE-2AE4-4A67-B4D4-2D2E13765715
Поэтому, если не рассматривать скорость сходимости, а точнее восстановления доступа при сбое порта с любой стороны и настройку Changing the network teaming failback delay fails in ESXi (2014075) https://kb.vmware.com/s/article/2014075 - то особых плюсов для отказоустойчивости LAG не дает.
Что со скоростью?
Со скоростью в рамках одного потока – внезапно, но то же самое. Проблема в том, что если мы пойдем по стеку чуть выше, и начнем рассматривать TCP сессию, то она подразумевает, что очень желательно, чтобы пакеты приходили почти по порядку, см. Etherchannels And LAGs https://networkdirection.net/articles/routingandswitching/etherchannelsandlags/
Там это упомянуто очень косвенно, как “A major advantage of ‘pinning’ a traffic flow to a single link is that it limits the possibility of TCP packets being received out of order, and needing to be reassembled.”
То есть при работе в несколько потоков (что умеют далеко не все приложения) рост скорости будет, а вот при работе в малого размера инфраструктуре – будет то, что описано в документации:
Route Based on IP Hash: However, if your environment has a small number of IP addresses, the virtual switch might consistently pass the traffic through one uplink in the team. For example, if you have a database server that is accessed by one application server, the virtual switch always calculates the same uplink, because only one source-destination pair exists.
Но при этом вы все равно получаете проблему необходимости сборки LAG - Route Based on IP Hash: ESXi hosts support only 802.3ad link aggregation in Static mode . You can only use a static Etherchannel with vSphere Standard Switches. LACP is not supported. If you enable IP hash load balancing without 802.3ad link aggregation and the reverse, you might experience networking disruptions.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-523FDFBD-EAEC-44A5-9451-F63EB792F156.html
Configure NIC Teaming, Failover, and Load Balancing on a Distributed Port Group or Distributed Port : IP-based teaming requires that the physical switch is configured with EtherChannel.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-73AB2E00-FE02-4D1B-970F-7D2F21F52825.html
Неприятное, лежащее чуть глубже в документации
Understanding IP Hash load balancing (2006129): https://kb.vmware.com/s/article/2006129
Route Based on Originating Port ID - A single virtual NIC cannot use more than a single physical NIC's bandwidth. For example, if four 1 Gb NICs are in a team, a virtual machine with a single virtual NIC cannot use more than 1 Gb of bandwidth via a single adapter.
Route Based on IP Hash: Route based on IP Hash load balancing requires that the physical switch ports be combined into an EtherChannel (sometimes called an aggregation bond, port-channel). This ensures that the same hashing algorithm is used for traffic returning in the opposite direction. Beacon probing is not supported with IP Hash. Only link status can be used as a failure detection method. If a link fails without the link state going down, there is no way to avoid network communication issues on the vSwitch.
Но при этом метод определения состояния линка Link status only имеет ряд ограничений: Teaming and Failover Policy: However, link status does not detect the following configuration errors:
Physical switch port that is blocked by spanning tree or is misconfigured to the wrong VLAN .
Pulled cable that connects a physical switch to another networking devices, for example, an upstream switch .
И еще неприятное:
Кроме проблем с отладкой и ошибочными настройками на стороне коммутаторов и проблем с самими коммутаторами, на данный момент для RDMA не работает LAG в следующих случаях:
The Basics of Remote Direct Memory Access (RDMA) in vSphere: PVRDMA does not support NIC teaming. The HCA must be the only uplink on the vSphere (Distributed) Switch
vSphere RDMA: vSAN with RDMA supports NIC failover, but does not support LACP or IP-hash-based NIC teaming.
Agents: If Link Aggregation Control Protocol (LACP) is used on an ESXi host that is a member of a vSAN cluster, don’t restart ESXi management agents with the services.sh command.
Use /etc/init.d/module restart to restart the independent services.
Чего делать-то??
Ранее упомянутый текст John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread)
https://twitter.com/Lost_Signal/status/1368775901157224449
содержит ответы на основные вопросы - What else can I do instead?
1. MPIO for iSCSI
2. Multiple VMKernel ports for vMotion.
3. LBT (Load Based Teaming) for most other things.
4. Active/passive comfigs (vSAN down path A, vMotion down path B and cross failover).
5. Remember to turn on NIOC.
6. Tag backups to lower COS.
7. Turn on the vSAN performance service and update vSphere and realize your LAG is the cause of all those network metrics looking ugly.
8. Commit today, to stop buying 10Gbps. 25Gbps at worst, and 100Gbps from here on out.
9. Stop using FEXs
10. Don’t use the native VLAN.
11. Recognize that RDMA is going to sneak into your DC soon, and if you think LAGs suck, try making them work with RCoEv2
Подводя итог.
В самом по себе LAG в вариантах выше ничего плохого нет. Но его использование
- усложняет отладку (troubleshooting)
- усложняет сетевую конфигурацию и на свичах, и на хостах.
- в случае сбоев MLAG и стека вы получите или просто проблемы, или потерю сети.
- не дает в ряде сценариев, где он бы был так нужен, каких-то плюсов по скорости
- не может быть использован в ряде современных сценариев (RDMA, vSAN)
- теоретическая польза от него появляется только при использовании Distributed vSwitch (DVS, dvswitch), а DVS сам по себе добавляет проблем и с очень осторожным конфигурированием, и с ephemeral port binding.
- лично я не очень люблю DVS, в ряде случаев может оказаться проще один раз написать конфигурацию хоста через Get-VirtualPortGroup \ New-VirtualPortGroup \ Set-VirtualPortGroup и затем из единого хранилища конфигурации одннобразно управлять разными хостами. Но, иногда у DVS есть и плюсы, оправдывающие закупку соответствующих лицензий
- У некоторых протоколов – iSCSI, SMB – есть MPIO, позволяющее гораздо лучше балансировать поток данных. При этом у некоторых СХД (Netapp) при работе с NFS (который изначально не поддерживал MPIO) можно получить проблемы в связи с тем, что время переключения выше таймаута в Vmware и можно получить All path down. MPIO в NFS появился только в NFS 4.1
То есть, перед внедрением LAG необходимо перечитать литературу по списку ниже, проверить рабочие сценарии обработки отказа, выписать себе в таблицу плюсы и минус внедрения, и в обязательном порядке собрать тестовый стенд, где проверить реальную скорость и сети через iperf, и СХД (в случае iCSI \ NFS) через DiskSPD, Atto и прочие HCI – получили ли, что хотели, и будет ли рост скорости в том сценарии, для которого это затевалось. См. список литературы.
Литература к обязательному изучению.
Заранее извините, что часть ссылок на документацию ведет на 7, а часть уже на 8-ю версию.
M-LAG как альтернатива STP и стека - https://habr.com/ru/company/muk/blog/225479/
Объединяй коммутаторы и властвуй — сравниваем Stack и MLAG https://habr.com/ru/company/selectel/blog/676740/
vSwitch Load Balancing: Source MAC Hash https://babarmunir.wordpress.com/2021/05/12/vswitch-load-balancing-source-mac-hash/
Etherchannels And LAGs https://networkdirection.net/articles/routingandswitching/etherchannelsandlags/
Configuring LAG Settings on a Switch through the Command Line Interface (CLI)
https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-550x-series-stackable-managed-switches/smb5848-configuring-lag-settings-on-a-switch-through-cli.html
vSphere Distributed Switch - Lightning Lab (HOL-2210-91-SDC) - https://hol.vmware.com/catalog/
Testing vmxnet3 speed (2020) https://vinfrastructure.it/2020/03/testing-vmxnet3-speed/
Maximum traffic for a vmxnet3 (2015) https://communities.vmware.com/t5/Virtual-Machine-Guest-OS-and-VM/Maximum-traffic-for-a-vmxnet3/td-p/969636
vSphere Distributed Switch Part 19 – Understanding vSwitch Network Load Balancing policies
http://www.idz.vn/2016/03/vsphere-distributed-switch-part-19_25.html
Setting the vSwitch load balance policy using command line on an ESX host (1005833)
https://kb.vmware.com/s/article/1005833
John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread)
https://twitter.com/Lost_Signal/status/1368775901157224449
Understanding IP Hash load balancing (2006129) https://kb.vmware.com/s/article/2006129
vSwitch Load Balancing: Source MAC Hash https://babarmunir.wordpress.com/2021/05/12/vswitch-load-balancing-source-mac-hash/
Add and Team Physical Adapters in a vSphere Standard Switch
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-DFE769C9-9A9C-4CDB-A0BC-2B17931B75A5.html
Configure NIC Teaming, Failover, and Load Balancing on a vSphere Standard Switch or Standard Port Group
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html
NIC teaming in ESXi and ESX (1004088)
https://kb.vmware.com/s/article/1004088
Changing the network teaming failback delay fails in ESXi (2014075)
https://kb.vmware.com/s/article/2014075
The Basics of Remote Direct Memory Access (RDMA) in vSphere
https://core.vmware.com/resource/basics-remote-direct-memory-access-rdma-vsphere#section1
Configure Remote Direct Memory Access Network Adapters
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-C44D4A9D-FEAA-4BA9-9C3C-FC8CC3DE4837.html
Configure VMkernel Binding for the RDMA Adapter
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-EADAE1EF-1DE6-44C9-9DB6-051F88958D8F.html
Host requirements for link aggregation (etherchannel, port channel, or LACP) in ESXi (1001938)
https://kb.vmware.com/s/article/1001938
About vSAN Network Design (особенно в части Air gap)
https://docs.vmware.com/en/VMware-vSphere/7.0/vsan-network-design-guide/GUID-40DE7266-BBE8-49DB-907E-DF2DE16AA716.html
Understanding Network Air Gaps
https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-network-design-guide/GUID-69DD2619-B768-46CB-89A3-8C1FD1F46B61.html
Pros and Cons of Air Gap Network Configurations with vSAN
https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-network-design-guide/GUID-954378E3-03C3-4FAD-B67E-90C6633F6F9E.html
Static (non-ephemeral) or ephemeral port binding on a vSphere Distributed Switch (1022312)
https://kb.vmware.com/s/article/1022312
VSphere Standard Switch vs. Distributed Switch: The differences
https://www.techtarget.com/searchvmware/tip/VSphere-Standard-Switch-vs-Distributed-Switch-The-differences
NFS Multipathing
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-0C797E03-F68D-4BE1-BA35-74337F3DBE5A.html
Best practices for performing the storage performance tests within a virtualized environment (2019131)
https://kb.vmware.com/s/article/2019131
Testing virtual machine storage I/O performance for ESX and ESXi (1006821)
https://kb.vmware.com/s/article/1006821
Command line tool for datastore performance test in ESXi 6
https://communities.vmware.com/t5/ESXi-Discussions/Command-line-tool-for-datastore-performance-test-in-ESXi-6/m-p/1777185
What is the latency stat QAVG?
https://www.codyhosterman.com/2018/03/what-is-the-latency-stat-qavg/
Как устроена цепочка сетевого стека VMware ESXi на уровне виртуального коммутатора - Network IOChain.
https://www.vmgu.ru/news/vmware-vswitch-networking-iochain
Полезные утилиты для решения проблем в сетевом стеке VMware vSphere.
https://www.vmgu.ru/news/vmware-vsphere-esxi-useful-network-tools
