xamza
Contributor
Contributor

nic teaming method на физическом свитче

Jump to solution

Добрый вечер,

Почему при использовании алгоритма балансировки route based on ip hash я не могу использовать другой метод на стороне коммутатора? к чему это приведет? при соединении двух свитчей между такое возможно

0 Kudos
1 Solution

Accepted Solutions
moshkow
Hot Shot
Hot Shot

> А как быть с этой статьей?

Там написано, что в версиях 5.5 и выше в VDS можно LACP'ой конфигурить LAG'и с произвольными алгоритмами балансировки.

> В итоге настроил на esxi ip-src-dst, а на циске src-mac и почему то РАБОТАЕТ)) или я тупой или лыжи не едут)


Ну а IP-hash -  настолько прост и туп, что совмещается практически с любой балансировкой на физическом конце.

Там ведь суть проста - линки собираются в группу, для которой в таблице MAC'ов ровно один список. А по какому порту с физика вверх пускать пакет - решает алгоритм балансировки заданный на стороне физика. Виртуальному же свитчу без разницы, с какого порта снизу вошел пакет - он ведь вообще не запоминает маков.

P.S. И да, если у физика LACP, то "CP" должен быть статический, ибо виртуальный свитч никак не реагирует на контрольные пакеты, что приведет к регулярным лагам, фризам и потерям пакетов в моменты, когда физику хочется заняться переустановкой/реконфигурацией LAG, а "в ответ тишина", и таймауты.

View solution in original post

0 Kudos
15 Replies
Umlyaut
Expert
Expert

Почему при использовании алгоритма балансировки route based on ip hash я не могу использовать другой метод на стороне коммутатора?

Так, давайте начнём с аксиоматики (сиречь базовых понятий дискуссии).

Метод "route based on ip hash" работает в рамках стандарта 802.3ad и представляет собою Варину реализацию используемого в коммутаторах объединения физических каналов на уровне Ethernet -  технологию Link Aggregation (или Static Link Aggregation после появления протокола LACP, используемого для Dynamic Link Aggregation - напомню, кстати, что со стороны физ.коммутатора при обсуждаемой балансировке на стороне Сферы включать LACP вместо LA как минимум неполезно, а как максимум вредно).

Многие так же знакомы с проприетарным аналогом LA у оборудования Cisco - технологией агрегирования каналов EtherChannel (в лице FEC (FastEtherChannel) и GEC (GigabitEtherChannel)).

А остальные "другие методы" (из набора методов балансировки виртуального коммутатора Сферы - vSwitch), альтернативные методу route based on ip hash:

- Route based on the originating virtual port ID

- Route based on source MAC hash

- Use explicit failover order

есть чисто Варевские "примочки" и просто отсутствуют в коммутаторах в этой реализации.

Поэтому "на стороне коммутатора" никакого "другого метода" Вы использовать и не можете.

при соединении двух свитчей между такое возможно

Я не очень понял - это вопрос или утверждение (бывают, люди теряют знаки пунктуации).


Но в любом случае ожидать от "соединения двух свитчей" с разными (включенными) методами/протоколами нормального взаимодействия (по одному из этих разных методов/протоколов) лично я бы не стал. Smiley Happy  А соединение свитчей несколькими линками в условиях отсутствия/неработоспособности механизмов, предотвращающих неизбежное образование петли - это практически гарантированная проблема.

Извините, в отсутствие более детального описания добавить пока больше нечего.



0 Kudos
xamza
Contributor
Contributor

Но в любом случае ожидать от "соединения двух свитчей" с разными (включенными) методами/протоколами нормального взаимодействия (по одному из этих разных методов/протоколов) лично я бы не стал.

Извините, но причем тут метод балансировки трафика и протокол, по которому узлы договариваются о поднятии агрегированного линка?! В некоторых случаях только использование разного load balance и имеет смысл (EtherChannel considerations - PacketLife.net)

Просто в случае с ESXi ввело в заблуждение утверждение:

  • Supported switch Aggregation algorithm: IP-SRC-DST (short for IP-Source-Destination)

почему то решил, что здесь имеется ввиду, что линк вообще не поднимется, тогда как подразумевалось, что при использовании на стороне свитча метода отличного от ip-src-dst такая схема не имеет смысла, или может и здесь ошибаюсь

0 Kudos
Umlyaut
Expert
Expert

xamza написал(а):

Но в любом случае ожидать от "соединения двух свитчей" с разными (включенными) методами/протоколами нормального взаимодействия (по одному из этих разных методов/протоколов) лично я бы не стал.

Извините, но причем тут метод балансировки трафика и протокол, по которому узлы договариваются о поднятии агрегированного линка?!

"Причём" (или "не причём") - не совсем "прозрачное" определение.

Да, LA - это протокол агрегации линков.

Да, одним из его свойств/достоинств (помимо редундантности) является возможность балансировки трафика между линками-мемберами, составляющими агрегированный линк.

Да, со стороны хоста Сферы (его сетевых настроек) LA между vSwitch и физ.коммутатором "выглядит" как метод route based on ip hash в наборе настроек балансировки.

Возможно, корректнее было бы, если б интерфейс хоста Сферы в явном виде указывал бы на "сцепленность" в данном случае данного метода балансировки и способа/протокола агрегации линков (LA) - но уж что есть, то есть.


В некоторых случаях только использование разного load balance и имеет смысл (http://packetlife.net/blog/2010/jan/18/etherchannel-considerations/EtherChannel considerations - PacketLife.net)

Просто в случае с ESXi ввело в заблуждение утверждение:

  • Supported switch Aggregation algorithm: IP-SRC-DST (short for IP-Source-Destination)

почему то решил, что здесь имеется ввиду, что линк вообще не поднимется, тогда как подразумевалось, что при использовании на стороне свитча метода отличного от ip-src-dst такая схема не имеет смысла

Глянул Вашу ссылку... гм-ммм... полагаю, к теме данного поста она имеет довольно опосредованное отношение.

Т.е. у нас с Вами не "некоторый случай", а вполне конкретная ситуация: когда обсуждаемый метод баласировки трафика для хоста Сферы, будучи выбранным в настройках хоста, автоматом "взводит" LA для vSwitch`a этого самого хоста - и если из портов физ.коммутатора, к которым коннектятся pNIC`и, ассоциированные с данным vSwitch`ем, НЕ организовать LA-группу, то последствия нас не обрадуют - от "просто" не работающей балансировки до сетевых проблем (хоста и/или коммутатора).

Вот как-то так...

0 Kudos
Akopylov
Commander
Commander

Да, LA - это протокол агрегации линков.

Что-то первый раз слышу про такой протокол, Link Aggregation просто общее название технологии (в терминологии Cisco это EtherChannel). Не раз собирал лаги на различном оборудовании, ни разу не видел такого протокола ни на procurve, ни на cisco, ни на всяких руских поделках вроде eltex, даже в vyatta нет упоминания такого протокола. Может ссылочку на ieee или rfc предоставите? Есть LACP, есть тот же проприетарный PAgP, видел даже поддержку non-protocol trunk не многих L2 устройствах, но не использовал в виду доступности LACP. Это я к тому, что фраза:

при обсуждаемой балансировке на стороне Сферы включать LACP вместо LA как минимум неполезно, а как максимум вредно

совершенно не понятна, т.к. на выбор у человека только пара известных протоколов: LACP и PAgP.

Все это без придирок, сам не прочь понять как все-таки работает агрегирование в vSphere, ибо даже в документации невнятно написано, но вы оперируете не существующими терминами, от того не понятно, какая настройка нужна на коммутаторе, в который смотрят ники ESXi.

P.S. procurve, например, различает static LACP и dynamic LACP, но принцип работы и методы балансировки абсолютно одинаковы, различие только в поддержке standby линков, т.е. в одну bond (lag) группу можно включить не 8, а больше линков (до 16), но начиная с 9го они будут standby. Т.е. по факту это совмещение реального агрегирования с active/standby бондингом.

0 Kudos
xamza
Contributor
Contributor

но вы оперируете не существующими терминами, от того не понятно, какая настройка нужна на коммутаторе, в который смотрят ники ESXi

Насколько я понял под LA коллега имеет ввиду статическую агрегацию, языком циски channel-group 1 mode ON, согласен,с самого начала вводит в заблуждение такая формулировка, тоже без придирок)

Но не в этом вопрос, а в том почему при такой настройке, на стороне физ коммутатора нельзя выбрать метод балансировки отличный от ip-src-dst

0 Kudos
Umlyaut
Expert
Expert

Что-то первый раз слышу про такой протокол, Link Aggregation просто общее название технологии

Гляньте стандарт 802.3ad Smiley Happy

К слову - после появления LACP статическое объединение каналов ещё стали (в некоторых источниках) именовать SLA.

Например: IEEE 802.3AD Switch Configurations


Это я к тому, что фраза:

при обсуждаемой балансировке на стороне Сферы включать LACP вместо LA как минимум неполезно, а как максимум вредно

совершенно не понятна, т.к. на выбор у человека только пара известных протоколов: LACP и PAgP.


"На выбор" где?  На Цыске? Это странно - пусть роется в доках на Цыску (сам я ему не помощник, давно с "кошками" не работаю, позабыл уже половину команд Smiley Happy)

На моих коммутаторах (DLink, AT, Netgear) везде в секции, отвечающей за агрегацию портов (статическую), обязательно была опциональная возможность включить/выключить режим LACP (динамическую агрегацию то бишь). Осторожно предположу, что наличие у коммутатора LACP (DLA) при отсутствии LA (SLA) - нонсенс.


А отцитированные Вами мои слова насчёт "не включать на физ.коммутаторе LACP, ограничиваясь LA" я неоднократно встречал в источниках по Сфере - например Sample configuration of EtherChannel / Link Aggregation Control Protocol (LACP) with ESXi/ESX and Ci...

или

Записки виртуального админа: Что лучше: Etherchannel и IP Hash или Load Based Teaming?

сам не прочь понять как все-таки работает агрегирование в vSphere, ибо даже в документации невнятно написано, но вы оперируете не существующими терминами, от того не понятно, какая настройка нужна на коммутаторе, в который смотрят ники ESXi.

Я оперирую существующими терминами (см.выше).

Как говорится по приведённым мною линкам, на коммутаторе - в случае стандартного vSwitch`a, что характерно для большинства паттернов использования Сферы - должна быть настроена статическая агрегация линков (LA), динамическую - LACP - включать не нужно.

Динамическая агрегация портов физ.коммутатора - начиная с 5.1 - поддерживается VDS или Nexus 1000v (см. всё те же ссылки).

P.S. procurve, например, различает static LACP и dynamic LACP, но принцип работы и методы балансировки абсолютно одинаковы, различие только в поддержке standby линков, т.е. в одну bond (lag) группу можно включить не 8, а больше линков (до 16), но начиная с 9го они будут standby. Т.е. по факту это совмещение реального агрегирования с active/standby бондингом.

А у НР вообще своеобразный (проприетарный) "лексикон" по этой части - одно то, что они, ничтоже сумняшеся, называют "стекированием" объединение двух (своих) коммутаторов через обычный (штатный) порт, а не через соединение фабрик бэкплейн-линком, уже заставляет с настороженностью относиться к их вариантам толкования тех или иных отраслевых стандартов и технологий. Так что я не готов комментировать Ваш постскриптум. Smiley Happy

0 Kudos
Umlyaut
Expert
Expert

По формулировкам см. объяснение выше, в моём ответе коллеге AKopylov`у.

почему при такой настройке, на стороне физ коммутатора нельзя выбрать метод балансировки отличный от ip-src-dst

Опять семантика? Smiley Wink

Выбрать другой метод на физ.коммутаторе - можно.

Нормально работать при этом с ip hash балансировкой на vSwitch Сферы - нельзя.

Выбирая эту балансировку на хосте Сферы, Вы тем самым включаете на vSwitch режим SLA (static link aggregation) - и для нормальной работы обязаны использовать на физ.коммутаторе тоже SLA (то бишь балансировку ip-src-dst).

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

0 Kudos
Akopylov
Commander
Commander

Линки, которые вы привели ни с rfc, ни с ieee, я сам навыдумываю протоколов и терминов, а потом в бложике напишу. SLA, LA, hp вообще называют это "static non-803.ad trunk" или "static non-protocol trunk" (такое прям в документации к procurve x61xx видел). С каких пор LACP стал соотноситься с какой-то "динамикой"? Если приводить сторонние линки касательно сетевых технологий, то можно приводить линки на специализированные ресурсы, Агрегирование каналов — Xgu.ru, где статьи пишут специалисты в этой области, и там про динамический LACP говорится только в контексте standby линков в procurve (о чем я говорил раньше). А вообще http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf, IEEE P802.3ad Link Aggregation Task Force public archive area - ни слова там не нашел про SLA, static или dynamic.

Мне не понятно, что за лютые ограничения касательно агрегирования в ESXi, когда даже на самом вшивом линуксе спокойно можно использовать LACP, а тут непонятно как использовать, так еще и купи лицензию ent+ для dvs. Как вообще может быть интересен какой-то нон-протокол транк (т.е. названия протокола даже нет, т.к. протокола нет) или, как вы называете, SLA, когда LACP внедряется уже больше 10 лет, я LACP не видел из того что держал в руках только на лохматом 3com superstack2.

0 Kudos
xamza
Contributor
Contributor

Выбирая эту балансировку на хосте Сферы, Вы тем самым включаете на vSwitch режим SLA (static link aggregation) - и для нормальной работы обязаны использовать на физ.коммутаторе тоже SLA (то бишь балансировку ip-src-dst).

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

Вы упорно не хотите понимать, что способ установки агрегированного канала НИКАК не связан с методом балансировки, который выбирается после установки etherchannel (или называйте его как хотите). Допустим установили мы на esxi SLA, на коммутаторе тоже статическую агрегация, и? это не значит, что сейчас мы не можем поменять метод балансировки ТРАФИКА ВНУТРИ ЭТОГО SLA НА СТОРОНЕ ФИЗИЧЕСКОГО КОММУТАТОРА

Нормально работать при этом с ip hash балансировкой на vSwitch Сферы - нельзя.

Если вы поняли предыдущие слова, то поехали дальше, почему нельзя???!!! объясните, что будет

0 Kudos
Umlyaut
Expert
Expert

Спокойнее, товарищ, не надо вкладывать столько сердца! Smiley Happy

ОК, Вас не устраивает "моя" терминология (хотя я привёл примеры, откуда я её "взял") - ну не пользуйтесь ею, бога ради.

Вы высказывали интерес к источникам моей осведомлённости насчёт LA и Сферы - я тоже привёл примеры. Хотели разобраться в этом - вэлкам в Варину КВ из процитированного. Не вижу, где я ещё мог бы быть Вам полезным.

Мне не понятно, что за лютые ограничения касательно агрегирования в ESXi, когда даже на самом вшивом линуксе спокойно можно использовать LACP, а тут непонятно как использовать, так еще и купи лицензию ent+ для dvs.

А Варя решила использовать static LA с vSwitch и dynamic LA - с VDS (или Nexus).

Как вообще может быть интересен какой-то нон-протокол транк (т.е. названия протокола даже нет, т.к. протокола нет) или, как вы называете, SLA, когда LACP внедряется уже больше 10 лет, я LACP не видел из того что держал в руках только на лохматом 3com superstack2.

Во-первых, Вы как-то странно на мой вкус трактуете понятие "протокола".

Набор правил, по которым действует SLA (ip-src-dst и вот это вот всё) и есть протокол (как и любой другой набор правил обмена иного плана будет протоколом - TCP, SCSI и пр.).

Дипломатический протокол, тоже, кстати, набор правил. Smiley Happy

Ладно, чёрт с ней, с семантикой, но отчего столько отчаяния насчёт "(не)интересности" SLA, "когда LACP внедряется уже больше 10 лет"???

Ну вот так решил вендор (Варя) - на "простом" vSwitch`e пользуем LA, на "непростом" (VDS, Nexus) можем использовать так приглянувшийся Вам LACP.

Ранее Вы апеллируете к линуксу и пр. - ну хорошо, используйте linux based hypervisors и настраивайте редундантность с балансировкой нативными линуховыми методами, в чём проблема-то?

Вы ж не спрашиваете, чего это господь или природа попустили восход круглого жёлтого солнца на востоке, а не квадратного зелёного на западе? Smiley Wink

Вот так жизнь в этом месте устроена. Топикстартер поинтересовался конкретикой - я ответил, как мог, чисто в прикладном аспекте (мол, "делай так и будет тебе счастье").

Принимать мои ответы, или торить свою тропу в дебрях познания - личное дело каждого. Я не навязываюсь. :smileygrin:

0 Kudos
Umlyaut
Expert
Expert

Вы упорно не хотите понимать

Пожалуйста, не говорите мне, чего я понимать хочу или не хочу. Smiley Happy Договорились?

Допустим установили мы на esxi SLA, на коммутаторе тоже статическую агрегация, и? это не значит, что сейчас мы не можем поменять метод балансировки ТРАФИКА ВНУТРИ ЭТОГО SLA НА СТОРОНЕ ФИЗИЧЕСКОГО КОММУТАТОРА

Ага, кажется, начинаю что-то подозревать...

Дело в том, что я, как и многие другие (админы) ленив и нелюбопытен Smiley Happy придерживаюсь принципа разумной минимизации прикладываемых усилий.

Из-за этого лично я лезу в CLI моих коммутаторов тогда, когда этого не избежать (при начальной настройке - например, стека - или когда ГУЙ-интерфейс чего-то не позволяет). Соответственно, когда я выставляю на физ.коммутаторе SLA, то штатный ГУЙ не позволяет при этом ещё и "поменять метод балансировки ТРАФИКА ВНУТРИ ЭТОГО SLA НА СТОРОНЕ ФИЗИЧЕСКОГО КОММУТАТОРА".

Ну а поскольку я свято чту Первое Правило Админа ("работает - НЕ ТРОГАЙ!"), то лезть после ГУЯ в CLI, чтобы сменить дефолтную балансировку для SLA на что-то другое мне и в голову не приходит - бо вендор (Варя) в явном виде всё, что мне нужно в данном случае, указал.

Вы же, как я понял, работая с цЫской, воленс-ноленс вынуждены использовать CLI во всём его разнообразии (тут я задавил свою ностальгию по Каталистам и прочей роскоши Smiley Happy), соответственно, можете сходу раздельно устанавливать методы агрегации и балансировки. Отсюда Ваше недоумение, предполагаю.

Нормально работать при этом с ip hash балансировкой на vSwitch Сферы - нельзя.

Если вы поняли предыдущие слова, то поехали дальше, почему нельзя???!!! объясните, что будет

Думаю, что ничего полезного (в любом смысле).

Как-то я протуканил и впопыхах поставил LA-группе физ.коммутатора режим "LACP" ("навстречу" LA-группе со стороны хоста Сферы) - было неприятно: сеть стохастически фризилась и лагала, пока я не очнулся и не убрал режим "LACP" с агрегированного линка.

Как себя поведёт Ваша(?) цЫска, я не знаю, но Вы можете попробовать и рассказать (я без иронии).

Надеюсь, коллега, наше с Вами общение не слишком сказалось на Вашем душевном равновесии - у меня не было цели кого-то эпатировать или провоцировать, просто поделился определённой информацией со своей "кочки зрения". Как говориться, была бы польза.

0 Kudos
xamza
Contributor
Contributor

))) да нормально все, приношу извинения если вдруг что)

Просто меня мучает вопрос почему они пишут supported только ip-src-dst, и еще больше вот:

Итак, группа портов на физическом коммутаторе у нас есть. Но это еще не все.

Есть вот какой нюанс: при одной и той же группировке по стандарту 802.3ad на физических коммутаторах могут применяться разные алгоритмы непосредственно балансировки.

Вот примерный список:
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

И на стороне физического коммутатора обязательно должна быть балансировка нагрузки по IP (IP-Source-Destination) - потому что балансировку только лишь по такому алгоритму поддерживает коммутатор VMware, а алгоритм должен быть одинаков на "обоих концах" агрегированных каналов.

Как справочную информацию см. очень полезную, имхо, статью базы знаний - http://kb.vmware.com/kb/1004048.


взял отсюда LACP, 802.3ad, load based IP hash и все такое : Виртуализация. VMware vSphere

В итоге настроил на esxi ip-src-dst, а на циске src-mac и почему то РАБОТАЕТ)) или я тупой или лыжи не едут)

0 Kudos
moshkow
Hot Shot
Hot Shot

> Почему при использовании алгоритма балансировки route based on ip hash я не могу использовать другой метод на стороне коммутатора?

Можете использовать. ip hash нормально работает с большинством режимов физкоммутаторов, как бы они не назывались: EC, LA, _static_ LACP, Trunk, 802.3ad, bond, and so on, you name it...

Использовать в качестве источника информации статью  LACP, 802.3ad, load based IP hash и все такое : Виртуализация. VMware vSphere

не совсем разумно, ибо она писалась давно, надежнее обращаться напрямую к кб'шкам.

0 Kudos
xamza
Contributor
Contributor

Спасибо за ответ

А как быть с этой статьей?

Sample configuration of EtherChannel / Link Aggregation Control Protocol (LACP) with ESXi/ESX and Ci...

0 Kudos
moshkow
Hot Shot
Hot Shot

> А как быть с этой статьей?

Там написано, что в версиях 5.5 и выше в VDS можно LACP'ой конфигурить LAG'и с произвольными алгоритмами балансировки.

> В итоге настроил на esxi ip-src-dst, а на циске src-mac и почему то РАБОТАЕТ)) или я тупой или лыжи не едут)


Ну а IP-hash -  настолько прост и туп, что совмещается практически с любой балансировкой на физическом конце.

Там ведь суть проста - линки собираются в группу, для которой в таблице MAC'ов ровно один список. А по какому порту с физика вверх пускать пакет - решает алгоритм балансировки заданный на стороне физика. Виртуальному же свитчу без разницы, с какого порта снизу вошел пакет - он ведь вообще не запоминает маков.

P.S. И да, если у физика LACP, то "CP" должен быть статический, ибо виртуальный свитч никак не реагирует на контрольные пакеты, что приведет к регулярным лагам, фризам и потерям пакетов в моменты, когда физику хочется заняться переустановкой/реконфигурацией LAG, а "в ответ тишина", и таймауты.

View solution in original post

0 Kudos