Меню

Vmware lacp lag настройка

Настройка LACP на Distributed Switch в VMware vSphere

Выполняем настройку групп агрегации каналов (Link Aggregation Groups) с использованием LACP на распределённом коммутаторе vSphere (vSphere Distributed Switch)

В данной статье мы рассмотрим пример настройки агрегации для VMware vSAN.

Агрегация каналов позволяет объединять несколько сетевых подключений параллельно для увеличения пропускной способности и обеспечения избыточности. Когда группирование сетевых адаптеров настроено с помощью LACP, происходит распределение нагрузки сети vSAN по нескольким аплинкам. Однако это происходит на сетевом уровне, а не через vSAN.

Ознакомиться с общей информацией об агрегировании каналов можно в одной из моих статей про Агрегирование каналов Cisco

В то время как объединение каналов является очень свободным термином, для целей этой статьи основное внимание будет уделяться протоколу управления объединением каналов или LACP. В то время как IEEE имеет свой собственный стандарт LACP 802.3ad, некоторые производители разработали проприетарные типы LACP. Например, PAgP (протокол агрегации портов) похож на LAG, но является собственностью Cisco. Таким образом, руководство поставщика имеет решающее значение, и следует всегда придерживаться лучших практик поставщиков.

Основным выводом при реализации LACP является то, что он использует отраслевой стандарт и реализован с использованием port-channel. Там может быть много алгоритмов хеширования. Политика группы портов vSwitch и конфигурация канала порта (хэш) должны совпадать и соответствовать.

Добавляем LAG

Переходим в наш распределённый коммутатор и создаём новую группу агрегации. Указываем имя, количество портов агрегации, режим работы, а так же режим балансировки.

Обратите внимание, что если хост и коммутатор находятся в пассивном режиме, LAG не будет инициализирован, так как нет активной части, которая инициировала бы соединение.

Назначаем LAG для PortGroup

Назначаем созданную группу агрегации необходимой порт группе и переводим LAG в режим ожидания (Standby).

При подтверждение изменений появится предупреждающее окно, о том, что использование комбинации активных аплинков и LAG в режиме ожидания поддерживается только для переноса физических адаптеров между LAG и автономными аплинками. Нажимаем ОК.

Проверяем, что LAG добавился.

Настраиваем адаптеры на хостах

Переходим в меню “Добавление и редактирование хостов” нашего распределённого коммутатора, выбираем пункт “Редактирование хостов”, добавляем хосты, которые подключены к данному distributed switch.

Назначаем LAG-порты к соответствующим vmnic. По аналогии назначаем порты для других хостов.

Создаём PortChannel на Cisco

Тема конфигурации PortChannel затронута в одной из моих статей по настройке объединения портов (bonding) Cisco IOS и CentOS LACP

Рассмотрим пример нашего тестового стенда:

Проверьте какой алгоритм балансировки используется на физическом коммутаторе.

Проверяем состояние PortChannel.

Переводим LAG в активный режим

Обратите внимание, что когда LAG выбран, как основной аплинк, режим балансировки порт группы наследуется от режима балансировки, указанного в LAG, о чём нас дополнительно информируют.

Ещё раз проверяем топологию сети.

Особое внимание хочу уделить тому факту, что данная настройка не увеличивает пропускную способность, а выполняет роль отказоустойчивости и балансировки нагрузки.

Источник

Виртуализация. VMware vSphere

Тут собираю интересное по интересующей меня теме виртуализации.

Страницы

Подпишись на обновления по RSS

Посты по email

Обо мне

Михаил Москва, Russia Кроме званий VCP по четырем поколениям продуктов этой компании, удостоен звания VMware vExpert. Являюсь автором книги «Администрирование VMware vSphere».
С февраля 2012 работаю в компании VMware.
Адрес моей электронной почты mikhail.mikheev@vm4.ru.

Читайте также:  Anytone at 300m настройка

Все высказанное здесь представлено “как есть” и не предоставляет каких-либо гарантий и прав. Позиция автора может не совпадать с позицией работодателя. Просмотреть профиль

Рекомендую

Последние комментарии

Подпишись на комментарии

Популярные посты за месяц

Популярные посты за все время

Архив блога

Подписчики

Ярлыки

среда, 30 марта 2011 г.

LACP, 802.3ad, load based IP hash и все такое

У нас есть виртуальный коммутатор, у него несколько физических интерфейсов, через которые он подключен к двум физическим коммутаторам
(такая схема, с поправкой на число аплинков(физических сетевых контроллеров), видится мне типовой).
См. рис.1:

Рис. 1. Иллюстрация компонентов сети

От сетевых контроллеров e1000 и vmxnet2 производительности стоит ожидать меньшей, чем у vmxnet3, но больше номинального гигабита. Но и нагрузка на процессор от них должна быть побольше.

Немного теории: для настройки nic teaming мы должны указать тип группировки (рис. 2).

А если эти условия не выполняются, т.е. трафик надо передавать через физический коммутатор? Это означает, что даже при наличии быстрого канала до виртуального коммутатора, бутылочным горлышком могут стать его гигабитные интерфейсы. Вернее, тот один, через который пойдет трафик при настройках по умолчанию.

Есть для ESX(i) такая настройка виртуального коммутатора, как Load Balancing, балансировка нагрузки (рис. 3)

Рис. 3. Варианты балансировки нагрузки для вКоммутатора

От второго ожидают лучшего распределения трафика.

Мне хочется проговорить аккуратно и конкретно о второй настройке балансировки нагрузки для виртуального коммутатора, и связанных со всем этим вещах.

Мы меняем настройку балансировки нагрузки на «Load based IP hash».
Если виртуальный коммутатор будет балансировать нагрузку по алгоритму «Load based IP Hash», то это означает, что виртуальный коммутатор трафик от любой одной ВМ может выпускать сразу по все аплинкам одновременно. MAC-адрес этой ВМ будет на нескольких портах физического коммутатора – без объединения этих портов в группу по стандарту 802.3ad( или EtherChannel) сеть работать не будет.

Так что чтобы сеть не перестала работать после включения «Load based IP hash» на виртуальном коммутаторе, к этому моменту на физическом коммутаторе должна быть настроена статичная группировка портов по стандарту 802.3ad. Вот об этом и хочу поговорить.

Еще может быть «PAgP, Port Aggregation Protocol», но это примерно то же что и LACP, только LACP – отраслевой стандарт, а PAgP – закрытый стандарт от Cisco. Примерно та же разница между EtherChannel и 802.3ad – первое разработка Cisco, второе – отраслевой стандарт. Суть одна. В данном тексте и в данном контексте 802.3ad и EtherChannel означают одно и то же, как и LACP/PAgP.

Вот примерный список:
dst-ip Dst IP Addr
dst-mac Dst Mac Addr
dst-mixed-ip-port Dst IP Addr and TCP/UDP Port
dst-port Dst TCP/UDP Port
src-dst-ip Src XOR Dst IP Addr
src-dst-mac Src XOR Dst Mac Addr
src-dst-mixed-ip-port Src XOR Dst IP Addr and TCP/UDP Port
src-dst-port Src XOR Dst TCP/UDP Port
src-ip Src IP Addr
src-mac Src Mac Addr
src-mixed-ip-port Src IP Addr and TCP/UDP Port
src-port Src TCP/UDP Port

Выводы
Если нужна гарантированная полоса пропускания, близкая к 10 Гбит\с, в том числе к единому клиенту, то стоит задуматься или о невиртуализации такой задачи, или о пробросе выделенной 10Гбит сетевой карте при помощи VMDirectPath.

Читайте также:  Windows vista как восстановить заводские настройки

За консультации и помощь в подготовке материала биг thx Денису Батурину и Евгению Ковальскому.
Комментарии приветствуются.

Источник

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

Приветствую всех. Сегодня я постараюсь внести ясность в такую неоднозначную и вызывающую много споров тему, как агрегирование каналов в 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

channel-group номер_группы mode
Это другие возможные режимы работы, но они нам не интересны, т.к. используют для согласования проприетарный протокол 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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

Источник