Приветствую всех. Сегодня я постараюсь внести ясность в такую неоднозначную и вызывающую много споров тему, как агрегирование каналов в Vmware. Многие (в том числе и производители оборудования) для описания агрегирования каналов применяют такие термины как LACP, 802.3ad, Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Link Bundling, NIC bonding, EtherChannel,  link aggregation и некоторые другие. В целом, технология агрегирования каналов, это технология позволяющая объединить несколько физических каналов в один логический. Такое объединение позволяет увеличивать пропускную способность (он же Load Distribution или Load Balancing) и надежность канала (она же Failover). В данной статье, возможно, я сделал какие-то неверные выводы и буду благодарен за дополнения и комментарии. Для написания статьи я придерживался мануала Cisco IEEE 802.3ad Link Bundling, ибо только в нем нашел более менее систематизированные понятия.

Введение в агрегирование каналов (NIC Teaming)

Для начала, давайте разберемся в терминологии. В связи с большой путаницей в понятиях, я буду придерживаться следующего списка:

Агрегирование каналов – собственно, общее наименование любого из видов объединения физических каналов в логический.
EtherChannel – это просто название технологии Cisco, описывающей агрегацию каналов (не протокол ил стандарт).
Teaming (или NIC Teaming) – по аналогии с Cisco, это так же название технологии агрегации каналов в компании Vmware (и некоторых других, например Intel и HP).
Link Aggregation Control Protocol (LACP) – протокол агрегации каналов, имеющий возможности автоматически создавать агрегацию  (посредством пересылки LACP PDU пакетов). Протокол LACP описан в стандарте IEEE 802.3ad (как утверждает Microsoft, он же имеет маркировку IEEE 802.1ax, хотя в Cisco я не нашел упоминания 802.1ax).
IEEE 802.3ad – стандарт, описывающий протоколы и принципы агрегирования каналов. Так же, включает описание балансировки трафика агрегированных каналов.
LAG (Link Aggrigation Group) – в терминологии Vmware это и есть логический канал, объединяющий в себе uplink порты.

Далее, давайте рассмотрим что же такое агрегирование каналов без привязки к производителю. Из терминов выше – ясно, что это технология объединения физических интерфейсов в логический. Какую-то часть функционала данной технологии выполняет протокол STP, позволяющий использовать несколько физических интерфейсов для отказоустойчивости. Но данный протокол не позволяет осуществлять балансировку трафика и по сути в какой-то один момент времени использует только один физический линк для передачи данных. Хотя агрегирование позволяет увеличить пропускную способность канала, но не стоит рассчитывать на идеальную балансировку нагрузки между всеми  интерфейсами в агрегированном канале. Технологии по балансировке нагрузки в агрегированных каналах, как правило, ориентированы на балансировку по таким критериям: MAC-адресам, IP-адресам, портам отправителя или получателя (по одному критерию или их комбинации). Агрегирование каналов у многих производителей сетевого оборудования возможно только в режиме “точка-точка”. То есть возможно агрегировать каналы начинающиеся на одном устройстве и заканчивающиеся на другом устройстве. Т.к. цель данной статьи – рассмотреть NIC Teaming на Vmware, то для упрощения будем придерживаться ситуации, когда наш хост использует один физический коммутатор для агрегирования каналов.

Какие же требования необходимо выполнить, чтобы агрегирование каналов заработало корректно?

• Максимальное количество поддерживаемых интерфейсов в агрегированном канале определяется производителем оборудования. (наиболее частая цифра 4 или 8 интерфейсов, в Vmware на текущий момент – 32)
• Все физические интерфейсы в агрегированном канале должны иметь одинаковые настройки скорости и режима full-duplex. (при этом, LACP не поддерживает half-duplex mode).
• Все физические интерфейсы в агрегированном канале должны иметь одинаковые настройки протокола агрегирования (LACP, статический и др.).
• VMware поддерживает только один канал EtherChannel на vSwitch или vNetwork Distributed Switch (vDS)

Режим работы EtherChannel

Теперь давайте рассмотрим нюансы работы протокола LACP на примере оборудования Cisco (имеющие отношение к Vmware vSphere). Итак, оборудование Cisco, поддерживающее EtherChannel может настроить этот самый EtherChannel в нескольких режимах. За это отвечает команда channel-group (подробней – в ссылках в документе IEEE 802.3ad Link Bundling). Из всех возможных режимах в Cisco, Vmware поддерживает только 3 (до версии 5.5  – только 1). Рассмотрим режимы EtherChannel :

channel-group номер_группы mode active
Данный режим включает Link Aggregation Control Protocol (LACP) на интерфейсе постоянно. То есть Cisco в любом случае является источником LACP PDU пакетов. Скажем так – является активным инициатором.

channel-group номер_группы mode passive
LACP включается только когда обнаружено поступление LACP пакетов от другой стороны. Скажем так – является пассивным инициатором.

channel-group номер_группы mode on
Данный режим включает EtherChannel без использования каких-либо протоколов согласования. Это так называемый статический EtherChannel или статический NIC Teaming или статическая агрегация. Назвать данный режим LACP – нельзя. Т.к. для его работы не используется функционал протокола LACP. Т.е. не происходит автоматического согласование канала на основе обмена LACP пакетами.

channel-group номер_группы mode {auto [non-silent] | desirable [non-silent]}
Это другие возможные режимы работы, но они нам не интересны, т.к. используют для согласования проприетарный протокол PAgP и vSphere не поддерживаются.

Работа протокола LACP будет возможна, при следующих конфигурациях сторон:

Режим работы LACP	passive	active
passive	–	OK
active	OK	OK

То есть, неработающая конфигурация, когда обе стороны настроены в LACP passive режиме. Статическая агрегация IEEE 802.3ad возможна только когда обе стороны настроены в статическом режиме.

Балансировка нагрузки EtherChannel

Кроме собственно настроек агрегации каналов, необходимо определиться с алгоритмом балансировки нагрузки, который должен иметь одинаковые параметры на обоих сторонах линка. Балансировка может производится по различным параметрам (а точнее по различным полям сетевого пакета/кадра). Большинство производителей сетевого оборудования могут поддерживать следующие параметры: MAC-адреса, IP-адреса или номера портов TCP/UDP, а также режим источника, режим назначения или оба режима. Vmware, дополнительно поддерживает балансировку по VLAN, Port ID, а так же любые комбинации всех описанных способов. Описание алгоритмов распределения нагрузки выходит далеко за рамки данной статьи. Для понимания работы, рекомендую почитать Балансировка загрузки канала EtherChannel и избыточность на коммутаторах Catalyst в ссылках. Можно кратко отметить, что выбирать алгоритм балансировки нагрузки необходимо основываясь на топологии Вашей сети и логике обмена данными между клиентами, использующими агрегированный канал. Вот хороший пример с xgu.ru.

Например, на схеме, все устройства находятся в одном VLAN. Шлюз по умолчанию маршрутизатор R1. Если коммутатор sw2 использует метод балансировки по MAC-адресу отправителя, то балансировка выполняться не будет, так как у всех фреймов MAC-адрес отправителя будет адрес маршрутизатора R1. Аналогично, если коммутатор sw1 использует метод балансировки по MAC-адресу получателя, то балансировка выполняться не будет, так как у всех фреймов, которые будут проходить через агрегированный канал, MAC-адрес получателя будет адрес маршрутизатора R1.

Агрегация каналов (NIC Teaming) в VMware

Начнем с истории, а точнее, с версий vmware – до 5.5. Официально, до версии 5.5 в vSphere отсутствовала поддержка агрегирования каналов по протоколу LACP. Можете сравнить документы what’s new для версии 5.1 и 5.5. Хотя, в документации vSphere Networking Guide ESXi 5.1 уже есть упоминание о включении LACP на uplink интерфейсе. Будем считать, что полноценна поддержка появилась в 5.5.

NIC Teaming в Vmware vsphere до 5.5 (5.1.x, 4.x)

Примеров данных конфигураций в интернете полно. Пожалуй, лучшая статья, которая в достаточной степени описывает технологию и настройку NIC Teaming на Vmware (для версий VMware ESX 3.0.x,VMware ESX(i) 3.5.x, VMware ESX(i) 4.0.x, VMware ESX(i) 4.1.x, VMware ESXi 5.0.x и VMware ESXi 5.1.x) размещена на сайте Михаила Михеева – LACP, 802.3ad, load based IP hash и все такое (см.ссылки). Копипастить одно и то же смысла не вижу, поэтому – читайте ). Если все же есть непреодолимое желание использовать LACP с vSphere младше 5.5, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v).

NIC Teaming по протоколу LACP в Vmware vsphere 5.5.x

VMware ESXi 5.5.x, как и прошлые версии поддерживает работу в режиме статического тиминга. Настройка его ни чем не отличается от той, которая написана в статье LACP, 802.3ad, load based IP hash и все такое. Далее, нас интересует настройка NIC Teaming с использованием согласования по протокол LACP на Vmware. В чем же польза LACP по сравнению с static aggregation:

1. Возможность использовать Hot-Standby Ports. Если добавить физических портов больше чем поддерживает оборудование (по крайне мере в cisco), то есть возможность использовать лишние порты в качестве портов hot-standby mode. Если произойдет отказ активного порта, порт hot-standby автоматически заменит его. Этот пункт мало применим к ESX, но тем не менее. 

2. Проверка корректности конфигурации. Агрегация каналов

   с использованием LACP не активируется, если есть какие-то проблемы с конфигурацией. Это помогает убедиться, что все настроено корректно. Статическая агрегация не делает каких-либо проверок перед своим задействованием, то есть вам нужно заранее быть уверенными, что все сделано правильно.

3. Failover (обнаружение отказа). Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Архитектурно, LACP’ом в vSphere управляет модуль ядра, который взаимодействует с демоном lacp_uw. Ключевое отличие настройки статической агрегации от LACP на vSphere Distributed Switch заключается в следующем: При использовании NIC teaming в статической конфигурации на vSphere Distributed Switch мы создавали т.н. Uplink порты, которым сопоставляли физические vmnic интерфейсы хостов. А уже Uplink интерфейс использовали в качестве исходящего интерфейса взаимодействия с внешним миром. А виртуальные машины, работая на каком-либо из хостов выбирали из ассоциированного с Uplink физического интерфейса – нужный. При этом, группировка и балансировка происходила на уровне созданных Uplink интерфейсов в настройках распределенных порт-групп в разделе “Teaming and failover”. При настройке Link Aggregation Control Protocol мы создаем т.н. LAG (Link Aggrigation Group) – некая сущность, аналогичная Port Channel в Cisco – логический интерфейс, который объединяет физические интерфейсы и на уровне которой применяются настройки LACP (active-passive) и Load Balancing, к которой ассоциируются физические интерфейсы одного хоста. А Уже к этому самому LAG присоединяются/ассоциируются физические vmnic интерфейсы. И этот же LAG используется в качестве исходящего интерфейса. “На пальцах” тяжело понять данный абзац. Необходима практика )

Типовой пример настройки NIC Teaming по протоколу LACP

Давайте на практике посмотрим как это выглядит. Предположим, что у нас уже создан некий Distributed Switch 5.5.0. Со свичом ассоциированы необходимые хосты. Создана некая портгруппа виртуальных машин в конфигурациях по умолчанию. Например:

 Далее, перед настройкой LACP давайте рассмотрим некоторые аспекты настройки:

• Из физических NIC какого-то одного хоста возможно подключение одного физического NIC только к одному порту LAG, при этом, один порт LAG может включать в себя множество физических интерфейсов с различных хостов ассоциированных с данным распределенным коммутатором.
• Физические NIC хоста, включенные в LAG должны быть подключены к интерфейсам физического свича, которые (интерфейсы свича)  должны быть настроены на аналогичный агрегированный канал (port channel).
• При настройке LACP необходимо учитывать ограничения, актуальные для текущей версии:

  • LACP не совместим с software iSCSI multipathing.

  • LACP не поддерживается в host profiles.
  • LACP не получится настроить между хостами ESXi, запущенными внутри ESXi (т.н. nested ESXi).
  • LACP не работает с ESXi dump collector (?).
  • LACPне работает с port mirroring.
  • Проверка отказоустойчивости Teaming and failover не работает для LAG, т.к. протокол LACP имеет в своем составе механизмы проверки доступности.
  • LACP в версии 5.1 поддерживает только IP Hash load balancing и Link Status Network failover detection. 
  • LACP в версии 5.1  поддерживает только один LAG на vDS и/или хост.

Итак, последовательность настройки LACP на Vmware следующая:

1. Создать LAG (Link Aggrigation Group)

2. Назначить LAG как Standby интерфейс в настройке Teaming and Failover Order в Distributed Port Group.

3. Ассоциировать физические интерфейсы с LAG
4. Назначить LAG как Active интерфейс в настройке Teaming and Failover Order в Distributed Port Group.

Это рекомендованная мануалом последовательность. На самом деле, можно обойтись без шага №2. Просто задав ассоциацию свободных физических NIC к созданному LAG. Но тем не менее, давайте рассмотрим каждый шаг:

1. Создание LAG (Link Aggrigation Group)  в vSphere Web Client
   1. В vSphere Web Client переходим на наш созданный distributed switch.
   2. Выбираем Manage -> Settings.
   3. В разделе LACP, выбираем New Link Aggregation Group (зеленый крестик).
   4. Задаем параметры LAG:
      • Имя – используется для идентификации группы портов
      • Количество портов (потом можно поменять)
      • Выбрать режим согласования – active/passive в зависимости от параметров физического свича. Если свич работает в active, установите LAG в passive и наоборот.
      • Выбрать режим балансировки – должен соответствовать режиму балансировки на физическом свиче.
      • По желанию, можно указать настройки VLAN и NetFlow.
   5. Жмем Ок.
   6. Дожидаемся сообщения об успешном завершении “Update network configuration”. После завершения будет создан LAG и его конфигурация будет распространена по всем хостам, принадлежащим текущему distributed switch. Новый созданный порт LAG будет в режиме Unused в настройке Teaming and Failover Order в Distributed Port Group. Далее переходим к следующему шагу.
2. Назначаем LAG, как Standby интерфейс в настройке Teaming and Failover Order в Distributed Port Group.

   1. В vSphere Web Client переходим на наш созданный distributed switch.

   2. Из меню Actions выбираем Manage Distributed Port Groups.
   3. Выбираем Teaming and failover и жмем Next.
   4. Выбираем портгруппу, которая должна использовать LAG.
   5. В Failover order выбираем LAG и стрелками перемещаем его в Standby uplinks.
   6. Жмем Next, смотрим на получившуюся конфигурацию, улыбаемся и жмем OK.
   7. Жмем Finish.

3. Ассоциировать физические интерфейсы с LAG 

   1. !!! Убеждаемся, что все порты, которые планируется ассоциировать с LAG сконфигурированы и скоммутированы на физическом коммутаторе.
   2. !!! Убеждаемся, что все физические NIC имеют одинаковые настройки скорости и

      full duplex.

   3.  В vSphere Web Client переходим на наш distributed switch.
   4. Из меню Actions выбираем Add and Manage Hosts.
   5. Выбираем Manage host networking.
   6. Выбираем хосты, интерфейсы которых будут ассоциированы с LAG и жмем Next.
   7. На странице Select network adapter tasks выбираем Manage physical adapters и жмем Next.
   8. На странице Manage physical network adapters выбираем  NIC и жмем Assign an uplink.
   9. Выбираем LAG порт и жмем OK.
   10. Повторяем шаги h и i для всех физических адаптеров, которые будут ассоциированы с LAG портами.
   11. Переходим к следующему шагу.
4. Назначить LAG как Active интерфейс в настройке Teaming and Failover Order в Distributed Port Group.
   1. В vSphere Web Client переходим на наш distributed switch.
   2. Из меню Actions выбираем Manage Distributed Port Groups.
   3. Выбираем Teaming and failover и жмем Next.
   4. Выбираем нужную распределенную портгруппу, в которой LAG на прошлых шагах был установлен в Standby и жмем Next.

   5. В поле Failover order с помощью стрелок перемещаем наш созданный LAG в раздел Active, все остальные аплинки (если такие имеются) перемещаем в

      Unused. Standby должен остаться пустым.

   6. Жмем Next и Finish.
   7. В результате, должно получиться примерно следующее

Резюме

В текущей статье я постарался описать особенности работы с агрегированными каналами. Постарался описать статическую конфигурацию NIC Teaming и конфигурацию по протоколу LACP. Упор сделан не столько на практику, сколько на теорию и предоставление источников дальнейшего чтения для углубления изучения ) ИМХО, обзор получился несколько поверхностным, по возможности буду наполнять статью.

Ссылки

Cisco IEEE 802.3ad Link Bundling – http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/sbcelacp.html
Балансировка загрузки канала EtherChannel и избыточность на коммутаторах Catalyst – http://www.cisco.com/cisco/web/support/RU/9/92/92066_4.html
What’s new для версии 5.1 – http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Platform-Technical-Whitepaper.pdf
What’s new для версии 5.5 – http://www.vmware.com/files/pdf/techpaper/VMW-WP-vSPHR-5.5-PLTFRM.pdf
Статья Михаила Михеева “LACP, 802.3ad, load based IP hash и все такое” – http://www.vm4.ru/2011/03/lacp-8023ad-load-based-ip-hash.html
vSphere Networking Guide – http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-35B40B0B-0C13-43B2-BC85-18C9C91BE2D4.html
Пример настройки LACP на ESXi/ESX и коммутаторах Cisco/HP – http://kb.vmware.com/kb/1004048
Агрегирование каналов на xgu.ru – http://xgu.ru/wiki/Агрегирование_каналов
Замечание от Microsoft о именовании стандарта 802.1ax/802.3ad (спасибо комментатору gamelton) – http://technet.microsoft.com/ru-ru/library/hh831648.aspx

С Уважением, Mc.Sim!

---

Теги: network, vmware