LINUX.ORG.RU
ФорумAdmin

Interface bonding, как-то криво работает..


1

1

Есть 2 абсолютно одинаковых сервака в плане ОС и железа - стоит Debian 6, в каждом серваке по две гигабитных сетевухи. Воткнуты оба сервака в один гигабитный свич алиед телесис. Недавно поднял бондинг, но почему-то картина мне до конца не ясна - более гигабита между хостами получить не получается, причем бондинг судя по всему работает только при передаче сетевого трафика, на получение всегда работает только одна сетевуха - например если копировать по НФС с хоста А на хост Б то получается что хост А шлет трафик через обе свои сетевухи по ~500 мегабит с каждой, а вот хост Б принимает весь гигабит только в одну сетевуху.. Подскажите что может быть не так, конфиг бондинга ниже.

# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto bond0
iface bond0 inet static
	address  192.168.0.111
	netmask  255.255.255.0
	slaves eth0 eth1
	bond_miimon 100
	bond_mode balance-rr
	mtu 9000

auto vmbr0
iface vmbr0 inet static
	address  192.168.0.11
	netmask  255.255.255.0
	gateway  192.168.0.1
	bridge_ports bond0
	bridge_stp off
	bridge_fd 0

Соотв-но на втором хосте все один в один только IP адреса другие из той же сети.

★★★

Скорее всего AT умеет балансировать нагрузку в Etherchannel используя MAC/IP источника/назначения, порты L4 и VLAN Id (в лучшем случае). Карусель (как в бондинге на серверах) не поддерживается. У пакетов от А к Б всё одинаковое, поэтому со свича они отправляются в один интерфейс.

Если так оно и есть, то теоретически помогло бы настроить бондинг на серверах так, чтобы пакеты уходили с двух разных MAC-ов. (В предположении, что АТ достаточно разумен для того, чтобы отправлять пакеты для МАС выученного на интерфейсе X1 в любой из интерфейсов Etherchannel X).

frob ★★★★★
()
Ответ на: комментарий от frob

Вот и у меня закрадываются мысли что дело в свиче. Не подскажешь как настроить чтобы ходили пакеты с разных маков?

FreeBSD ★★★
() автор топика
Ответ на: комментарий от dyasny

802.3ad который? Да вроди поддерживается, но с ним вроди как всё работает точно также - принимает через одну сетевуху.. Пробывал выставлять настройки транка в «Active», «Passive» и «Manual».

FreeBSD ★★★
() автор топика
Ответ на: комментарий от FreeBSD

он самый, должно работать. если не пашет - возможно появилась регрессия в ядре дистра, у меня на RHEL все пашет

dyasny ★★★★★
()
Ответ на: комментарий от FreeBSD

не знаю, свичи - дело сетевиков, я им только говорю какие порты мне надо в бонд собрать

dyasny ★★★★★
()
Ответ на: комментарий от FreeBSD

Не подскажу — не настраивал серверную сторону никогда.

На самом деле если ты всё это «для тестирования» делаешь, то возможно используешь неправильный подход.
В нормальной ситуации у тебя даже если сервер один, то клиентов всё равно несколько. Сервер отдаёт в разные физические интерфейсы как сумеет (например каруселью, как у тебя), а свич отдаёт серверу в разные интерфейсы хэшируя MAC-и и/или IP клиентов.

frob ★★★★★
()
Ответ на: комментарий от beastie

Похоже у меня не взлетит бондинг как надо.. скорее всего дело в свиче. Перепробывал разные методы - xor, rr, 802.3ad в купе с разными настройками транков на свиче - результата в 2хгигабита добиться не получилось, лучшее это с balance-rr - отдает с 2-х сетевух, получает на одну, среднее это когда пинги теряются и ходят дубликаты пакетов, ну и самое паршивое это когда вообще ничего не работает. Видимо каждый вендор реализует транки по-своему, отсюда и проблемы при использовании разнородного оборудования.

FreeBSD ★★★
() автор топика
Ответ на: комментарий от FreeBSD

balance-rr тупо отправляет пакеты последовательно чередуя интерфейсы, свичи такой бондинг не умеют. Но это единственный способ получить более гигабита на одну TCP сессию, но при этом ты скорее всего будешь иметь проблемы с пакетами, приходящими вне очереди. Для TCP это в общем не критично. Чтобы этот режим работал, нужно запихать каждую пару интерфейсов с серверов (1 с первого и 1 со второго) в разные вланы, чтобы траффик ходил равномерно. Ну либо соеденить серваки напрямую кроссовером.

blind_oracle ★★★★★
()
Ответ на: комментарий от FreeBSD

По поводу понимания транков вендорами - есть стандарт 802.3ad и если свичи его поддерживают значит будут работать друг с другом и с линупсом.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Если «запихать каждую пару интерфейсов ... в разные вланы» на стороне свича, то Etherchannel не получится.

frob ★★★★★
()
Ответ на: комментарий от frob

Вам шашечки или ехать? Я описываю как получить рабочий balance-rr в конфигурации со свитчем. Etherchannel (в терминологии цыско) это LACP/PgAP/Static режимы. Первые два подразумевают согласование режима с другим девайсом, последний - нет. В этих режимах траффик идёт на интерфейс, номер которого в группе выбирается хэшем полей из заголовка пакета (айпи, мак и т.п.). В этом режиме нельзя получить скорость для одной TCP сессии более скорости одного порта. А так как я написал выше - можно. Свичу знать об этом совершенно необязательно. Нам нужно только чтобы пакеты отправляемые с 1 порта 1 сервера приходили на 1 порт 2 сервера и аналогично со 2 портами. Будет какой-то % пакетов приходящих вне очереди, но это не критично. На 4 гигабитных интерфейсах можно получить где-то 2.5Гбита траффика.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Мне-то ехать, но не всё равно куда. Не пробовали подумать что будет при отказе любого из задействованных 8 интерфейсов?

frob ★★★★★
()
Ответ на: комментарий от frob

Ну т.к. конфигурация нестандартная то всё зависит от того, что нужно автору.

Можно соеденить напрямую кроссом как я уже писал. Можно заюзать фишку цысковских свичей Link-state-tracking, которая при падении линка на одном интерфейсе положит линк на его партнёре. А проще всего заюзать arp-мониторинг в линуховом бонде, который пометит интерфейс как дохлый как только пир перестанет отвечать на арп-запросы при падении любого из интерфейсов.

Как видно, вариантов масса.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Соединение «напрямую кроссом» означает, что для любых других подключений нужны дополнительные интерфейсы.
У «автора» АТ, а не Cisco.
ARP-запросы? Стандартный таймаут ARP на линуксе — 1 минута. Его уменьшение потенциально ведёт к увеличению числа ненужных контрольных пакетов. Если использованные для соединения двух серверов VLAN-ы используются для чего-то ещё, то мусор будут получать и остальные. Если же сервера изолированны в своих VLAN-ах, то «см. пункт 1» или используй InterVLAN routing (в предположении, что используемый автором AT — L3 switch). Во втором случае агрессивная настройка ARP timeouts будет означать DoS на собственный коммутатор.

Как видно, у ваших таблеток от головной боли изрядные побочные эффекты, т.ч. исправлять «вылеченное» будет дороже чем вовсе не лечиться.

frob ★★★★★
()
Ответ на: комментарий от frob

Таймауты в линуксе тут не причем, bonding генерирует свои арп-запросы на обозначенные ip-адреса и слушает на них ответы. Хоть пять раз в секунду. 5 арп-запросов в секунду это не много, совсем немного, для гигабитного линка. Никому от них плохо не будет. Ни коммутатору, ни серверам, какой тут DDOS? А падение линка будет видно сразу.

Насчёт intervlan-роутинга - можно придумать еще один костыль - повесить bonding поверх VLAN-интерфейсов. Таким образом можно траффик между серверами пускать через бондинг с выделенными вланами, а иной траффик пускать напрямую через другие вланы.

Как видно, моя таблетка частично решает задачу в условиях автора. Не меняя условий проблему иначе не решить. Хочешь больше гигабита на одном TCP-соединении? Делай костыли в виде кроссовера или вланов, или покупай 10Гбит сетевухи и свичи. Благо нынче оно стоит достаточно недорого.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

«Товарисч не понимает»... ARP идёт свичу в control plane. Нет никакой технической необходимости делать keepalive-ы бродкастами и грузить CPU свича лишней фигнёй.
«Какой ты DDOS?» — а кто сказал _D_DOS? При пяти пакетах в секунду и стандартной практике «три попытки» падение будет видно чуть больше чем через 600 мс, а не «сразу».

можно придумать еще один костыль
Делай костыли

И так уже на полный экзоскелет набралось, куда ж ещё-то?

frob ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.