The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Linux Active-backup поверх 2х LACP"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Linux привязка)
Изначальное сообщение [ Отслеживать ]

"Linux Active-backup поверх 2х LACP"  +/
Сообщение от es (??), 26-Дек-19, 08:39 
Коллеги, доброго времени!

Подскажите собственно как организовать сабж?
Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как это организовать?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от fantom (??), 26-Дек-19, 10:58   +/
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?
> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?

1. STP вроде именно для таких случаев придуман был.
2. что мешает собрать LACP из 4-х интерфейсов? LACP много всякого разного, в том числе и бекап интерфейсы.

Ну и постановку решаемой проблемы не мешало бы,

Ответить | Правка | Наверх | Cообщить модератору

2. Сообщение от fantom (??), 26-Дек-19, 11:00   +/
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?
> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?

И кстати - LACP и bond вот совсем не одно и то же.

Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от pofigist (?), 26-Дек-19, 11:42   +/
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?
> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?

Забудь про bond - используй team.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от ACCA (ok), 26-Дек-19, 19:03   +/
>> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
>> это организовать?
> Забудь про bond - используй team.

И забудь про LACP в линухе для параллеливания трафика. Не работает, глюки.

Хочешь много проводов - используй другие протоколы. Сильно советую забираться L3+ уровни. Лучше всего на L7.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #6

5. Сообщение от Licha Morada (ok), 26-Дек-19, 21:00   +/
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?

Непонятно, зачем именно "поверх 2х LACP".
Посмотрите секцию "2. Bonding Driver Options" в https://www.mjmwired.net/kernel/Documentation/networking/bon... выбирайте на вкус.

> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?

"В лоб" пробовали?
Не думаю что это будет оптимально, но вы ничего не написали про конкретную задачу которыю вы пытаетесь решить.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

6. Сообщение от pofigist (?), 09-Янв-20, 16:34   +/
> И забудь про LACP в линухе для параллеливания трафика. Не работает, глюки.

C bond - не работает, да и не должно, с team - вроде как работает... Коммутатор на той стороне какой?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #7

7. Сообщение от fantom (??), 10-Янв-20, 13:24   +/
>> И забудь про LACP в линухе для параллеливания трафика. Не работает, глюки.
> C bond - не работает, да и не должно,

С чего вдруг??
xmit_hash_policy умеет 5 разных вариантов, в том числе layer3+4 , т.е. балансит на основе IP+Port (для TCP & UDP) и прекрасно работает.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от pofigist (?), 10-Янв-20, 13:54   +/
https://github.com/jpirko/libteam/wiki/Bonding-vs.-Team-feat...

load-balancing for LACP support NO для bound

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от fantom (??), 13-Янв-20, 11:41   +1 +/
> https://github.com/jpirko/libteam/wiki/Bonding-vs.-Team-feat...
> load-balancing for LACP support NO для bound

Первоисточники говорят обратное

https://www.kernel.org/doc/Documentation/networking/bonding.txt

Практика кстати тоже....

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от pofigist (?), 13-Янв-20, 12:19   +1 +/
>> https://github.com/jpirko/libteam/wiki/Bonding-vs.-Team-feat...
>> load-balancing for LACP support NO для bound
> Первоисточники говорят обратное
> https://www.kernel.org/doc/Documentation/networking/bonding.txt
> Практика кстати тоже....

Ну так пожалуйста внимательно читайте первоисточники - LACP, он же - 802.3ad, он же - mode 4 и в ее описание нет НИ СЛОВА про load-balancing. Хотя в описаниях mode 0, 2, 5 и 6 - он явно упоминается. Но только они - ну ни разу не LACP и не являются с ними совместимыми.

А практика показывает что при mode 4 весь трафик прет через один интерфейс (коммутатор - настроен корретно если что) и единственное что обесточивает это fault tolerance, но не load balancing. При настройке team - работает и то и то.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от fantom (??), 13-Янв-20, 16:40   +1 +/
>[оверквотинг удален]
>> Практика кстати тоже....
> Ну так пожалуйста внимательно читайте первоисточники - LACP, он же - 802.3ad,
> он же - mode 4 и в ее описание нет НИ
> СЛОВА про load-balancing. Хотя в описаниях mode 0, 2, 5 и
> 6 - он явно упоминается. Но только они - ну ни
> разу не LACP и не являются с ними совместимыми.
> А практика показывает что при mode 4 весь трафик прет через один
> интерфейс (коммутатор - настроен корретно если что) и единственное что обесточивает
> это fault tolerance, но не load balancing. При настройке team -
> работает и то и то.

xmit_hash_policy

    Selects the transmit hash policy to use for slave selection in
    balance-xor, 802.3ad, and tlb modes.

Специально вот только что посмотрел на 2-х серверах с bond-ингом по 802.3ad и xmit_hash_policy=layer3+4

BONDING_OPTS="downdelay=0 miimon=100 mode=4 updelay=0 lacp_rate=1 xmit_hash_policy=layer3+4"

и распределение трафика за сутки между 2-мя интерфейсами 50.6% на 49,4%

Это нельзя назвать "чистым" лоадбалансером.
это разделение трафика на 2 потока по определенным критериям, но выбор критериев обеспечивает почти равномерную загрузку по обоим интерфейсам.
Как-то так.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #12

12. Сообщение от pofigist (?), 14-Янв-20, 11:05   +/
Ну соглашусь - накостылить некое подобие load balancing можно. Но именно тот load balancing, который предусмотрен в 802.3ad - не поддерживается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #14

14. Сообщение от fantom (??), 14-Янв-20, 13:04   +/
> Ну соглашусь - накостылить некое подобие load balancing можно. Но именно тот
> load balancing, который предусмотрен в 802.3ad - не поддерживается.

Ну для полноты картины -- с вас ссылка на описания "load balancing, который предусмотрен в 802.3ad" пожалуйста.

про 802.3ad:
Алгоритм распределения фреймов по каналам там жестко не задан и его реализация на совести вендора, например у juniper на некоторых EX-.... линейках он вообще "жестко зашит" (он есть такой, какой есть и иного не дано по определению), у дешёвых L2 железок основан исключительно на MAC адресах ну и т.д.

Есть там еще фича в виде резервных линков, типа объединять можно до 16 интерфейсов, но активных не более 8, и если какой-то активный "падает" - один из запасных встает в строй, и можно указать "минимальный порог", допустим при указании 4 -- если осталось менее 4-х рабочих интерфейсов то весь агрегат переходит в down состояние, так сказать обеспечить нужное качество.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15

15. Сообщение от pofigist (?), 14-Янв-20, 13:33   +/
Жестко не задан не значит что не определены его варианты :)
https://howdoesinternetwork.com/2018/lacp-link-aggregation
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

16. Сообщение от es (??), 21-Янв-20, 08:36   +/
> "В лоб" пробовали?
> Не думаю что это будет оптимально, но вы ничего не написали про
> конкретную задачу которыю вы пытаетесь решить.

Действительно условие криво звучит, уточним..

Есть Linux-сервер с двумя оптическими и с двумя медными линками, необходимо
- на оптике собрать первый интерфейс LACP 802.3ad
- на меди собрать второй интерфейс LACP 802.3ad

Из этих двух интерфейсов собрать один Active-Backup (primary=LACP-оптика primary_reselect=always)

Т.е. в штатной ситуации сеть ездит по оптике, при швахе уходит на медь, при восстановлении возвращается.

Teaming/Bonding не суть, приоритет отказоустойчивость, не балансировка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #17

17. Сообщение от fantom (??), 21-Янв-20, 13:43   +/
>[оверквотинг удален]
>> Не думаю что это будет оптимально, но вы ничего не написали про
>> конкретную задачу которыю вы пытаетесь решить.
> Действительно условие криво звучит, уточним..
> Есть Linux-сервер с двумя оптическими и с двумя медными линками, необходимо
>  - на оптике собрать первый интерфейс LACP 802.3ad
>  - на меди собрать второй интерфейс LACP 802.3ad
> Из этих двух интерфейсов собрать один Active-Backup (primary=LACP-оптика primary_reselect=always)
> Т.е. в штатной ситуации сеть ездит по оптике, при швахе уходит на
> медь, при восстановлении возвращается.
> Teaming/Bonding не суть, приоритет отказоустойчивость, не балансировка.

ДЫК spanning-tree !!!
именно для сего случая и придуманный вроде как.

И вы уверены в свиче на "той стороне" ???

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от es (??), 21-Янв-20, 15:19   +/
>>[оверквотинг удален]
> ДЫК spanning-tree !!!
> именно для сего случая и придуманный вроде как.
> И вы уверены в свиче на "той стороне" ???

Зачем здесь spanning-tree, зачем пытаться поменять задачу?

Организация описанной конфигурации на других серверных ОС вопросов не вызвала. Очень удивило, что столкнулся с этой проблемой на Linux'е, где решение в лоб, bond/team-интерфейс (active-backup) поверх двух других bond/team-интерфейсов(lacp 802.3ad), собрать не получилось, отсюда и возникла эта тема.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #19, #20

19. Сообщение от Licha Morada (ok), 21-Янв-20, 21:15   +/
>>>[оверквотинг удален]
>> ДЫК spanning-tree !!!
>> именно для сего случая и придуманный вроде как.
>> И вы уверены в свиче на "той стороне" ???
> Зачем здесь spanning-tree, зачем пытаться поменять задачу?

Если это меняет задачу, значит не хватает какого-то важного условия. Ожидаемый результат использования STP отвечает задаче которую вы описали. Что конкретно вас смущает?
Попробуйте собрать ваши интерфейсы попарно в два бонда, а их в бридж с включённым STP.

> Организация описанной конфигурации на других серверных ОС вопросов не вызвала. Очень удивило,
> что столкнулся с этой проблемой на Linux'е, где решение в лоб,
> bond/team-интерфейс (active-backup) поверх двух других bond/team-интерфейсов(lacp
> 802.3ad), собрать не получилось, отсюда и возникла эта тема.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

20. Сообщение от fantom (??), 22-Янв-20, 13:06   +/
>>>[оверквотинг удален]
>> ДЫК spanning-tree !!!
>> именно для сего случая и придуманный вроде как.
>> И вы уверены в свиче на "той стороне" ???
> Зачем здесь spanning-tree, зачем пытаться поменять задачу?
> Организация описанной конфигурации на других серверных ОС вопросов не вызвала. Очень удивило,
> что столкнулся с этой проблемой на Linux'е, где решение в лоб,
> bond/team-интерфейс (active-backup) поверх двух других bond/team-интерфейсов(lacp
> 802.3ad), собрать не получилось, отсюда и возникла эта тема.

Второй "хвост" патчкорда куда воткнут?? если в свич -- вроде подавляющее большинство свичей "LACP over LACP" НЕ УМЕЮТ! чесно говоря не припоминю такого функционала ни на одном из девайсов.
(или я ошибаюсь??)

как вариант можно использовать аналог цисковского "lacp min-bundle" и "lacp max-bundle"
т.е. объединены в агрегат все 4, но активны только 2.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #21

21. Сообщение от pavel_simple_not_logged_in (?), 24-Янв-20, 10:56   +/
> (или я ошибаюсь??)

не ошибаешься, то, что просит автор есть бред. Одно дело собирать LACP на 4 линках а другое это собирать на двух уже LACP интерфейсах.

учитывая то, что LACP по сути ethernet-фреймы такое в принципе вне стандарта и подразумевает какой-то слой тунелирования

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #22

22. Сообщение от fantom (??), 24-Янв-20, 16:07   +/
>> (или я ошибаюсь??)
> не ошибаешься, то, что просит автор есть бред. Одно дело собирать LACP
> на 4 линках а другое это собирать на двух уже LACP
> интерфейсах.
> учитывая то, что LACP по сути ethernet-фреймы такое в принципе вне стандарта
> и подразумевает какой-то слой тунелирования

Туннелирования куда?? кто второй стороной тунеля будет??  
"О прошлом разе" скорее всего реально было 2 LACP, объединенных в мост и STP им в помощь, как наиболее похожее, нормально поддерживаемое и реализуемое решение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру