Jump to content
Калькуляторы

Распределение нагрузки между мостами

Имеются два вилана А и Б, в них серверы А1, А2, ..., Б1, Б2, ...

Виланы соединены мостами М1, М2, ...

Как сделать так, чтобы трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д.

При отключении одного из мостов трафик должен идти через один из оставшихся.

Если это принципиально - мосты на FreeBSD.

Share this post


Link to post
Share on other sites

что-то типа lagg(4) с протоколом failover

Share this post


Link to post
Share on other sites
что-то типа lagg(4) с протоколом failover
Каким образом это даст
трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д.

 

Share this post


Link to post
Share on other sites
что-то типа lagg(4) с протоколом failover
Если бы было неважно, через какой мост пойдут пакеты,

лишь бы нагрузка между мостами распределялась равномерно

и при отказе одного моста передавалась на другие,

то такая идея имела бы смысл: на коммутаторе в один транк

объединяются интерфейсы всех мостов, глядящие в сеть А,

во второй транк - интерфейсы всех мостов, глядящие в сеть Б.

 

К сожалению, при делении трафика на несколько мостов непонятно,

как сделать них шейпирование, поэтому нужно,

чтобы трафик между одной парой серверов всегда шёл через один и тот же мост,

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

Share this post


Link to post
Share on other sites
Имеются два вилана А и Б, в них серверы А1, А2, ..., Б1, Б2, ...

Виланы соединены мостами М1, М2, ...

Как сделать так, чтобы трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д.

При отключении одного из мостов трафик должен идти через один из оставшихся.

Если это принципиально - мосты на FreeBSD.

на свичах это MSTP

Share this post


Link to post
Share on other sites
К сожалению, при делении трафика на несколько мостов непонятно,

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

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

Все просто. Создаете таблицы IP-адресов и правила для динамических пайпов, и нужные очереди создадутся на шейперах автоматически. В EtherChannel кстати есть возможность определять packet distribution mode (port-channel load-balance ...), если не устраивает стандартный алгоритм, применяемый в LACP. В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.
Edited by photon

Share this post


Link to post
Share on other sites
К сожалению, при делении трафика на несколько мостов непонятно,

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

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

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

Ага, и если трафик от клиента распараллелится по двум мостам, он получит удвоенную скорость, а если по трём - то утроенную.

Не годится.

Share this post


Link to post
Share on other sites
В EtherChannel кстати есть возможность определять packet distribution mode (port-channel load-balance ...), если не устраивает стандартный алгоритм, применяемый в LACP. В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.
Во-первых, у нас коммутатор D-Link, у него в настройках есть LACP, но нет EtherChannel.

Правда, там есть такая весчь:

#config link_aggregation algorithm ?
Command: config link_aggregation algorithm      
Next possible completions:                      
mac_source          mac_destination     mac_source_dest     ip_source           
ip_destination      ip_source_dest

Насколько можно понять, в моём случае оптимальный выбор - mac_source_dest, но это необходимо проверять.

Интересно, почему нет варианта для равномерной загрузки по числу пакетов/байтов?

Share this post


Link to post
Share on other sites

Надо какой-то из алгоритмов по ip, потому что мост при отправке пакета меняет mac-адрес на свой. А с другой стороны такой же коммутатор? Иначе может не заработать. Вообще, неплохо бы почитать современную версию стандарта на LACP, может там уже внесли выбор алгоритма, и это не вендор-специфическое расширение.

Edited by photon

Share this post


Link to post
Share on other sites
Ага, и если трафик от клиента распараллелится по двум мостам, он получит удвоенную скорость, а если по трём - то утроенную.

Не годится.

Ничего подобного. У меня на прошлой работе так сделана балансировка с несколькими шейперами (без вланов и на EtherChannel, т.к. Cisco), и работает отлично.
Edited by photon

Share this post


Link to post
Share on other sites

То есть итоговая схема получается такой:

все порты, через который мосты воткнуты в первую сеть,

на коммутаторе объединены с помощью LACP в один транк,

а порты, через который они воткнуты во вторую сеть - в другой транк.

Алгоритм агрегации устанавливается в ip_source_dest.

 

That's right? :)

Share this post


Link to post
Share on other sites
В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.
Могу ошибаться, но по-моему к методу балансировки LACP вообще никакого отношения не имеет, зависит исключительно от коммутатора.

 

Интересно, почему нет варианта для равномерной загрузки по числу пакетов/байтов?
Потому что при таком подходе есть вероятность изменения порядка пакетов в каждом потоке, что есть большой грех.

 

ИМХО в таком "кривом" случае лучше не использовать LACP вообще если есть возможность и использоваться статический link aggregation. С LACP как-то некрасиво получается - мосты должны пропускать LACP PDU насквозь.

 

Алгоритм агрегации устанавливается в ip_source_dest.
Нет, или только source или только destination. Если по обоим сразу - тогда будет удвоенная скорость т.к. два разных соединения в ряде случаев пойдут по разным каналам.

 

 

А может все-таки роутинг? :)

 

Share this post


Link to post
Share on other sites
или только source или только destination
для трафика в мир - source, для трафика из мира - destination.

 

Share this post


Link to post
Share on other sites
ИМХО в таком "кривом" случае лучше не использовать LACP вообще если есть возможность и использоваться статический link aggregation.
Насколько я понимаю, при статическом LA коммутатор не отреагирует на отключение моста.

 

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

 

А может все-таки роутинг? :)
Роутинг используется сейчас. Хочется проверить, насколько повысится быстродействие, если заменить его на бриджинг.

 

или только source или только destination
для трафика в мир - source, для трафика из мира - destination.

Умеет ли это D-Link???

Share this post


Link to post
Share on other sites
Надо какой-то из алгоритмов по ip, потому что мост при отправке пакета меняет mac-адрес на свой.
Ой ли? Мост - это не proxy arp, он работает в promisc-режиме.

Сейчас специально проверил Вашу "гипотезу" посредством "tcpdump -e" на компьютерах,

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

 

В принципе, использование proxy arp вместо моста меня бы вполне устроило,

но не вполне понятно, как это реализовать на FreeBSD (linux+ebtables rocks?):

1) на ARP-запросы "who_has IP_сервера_А1 tell Б1" и "who_has IP_сервера_Б1 tell А1" мост возвращает свой MAC-адрес,

2) ARP-запросы от A2,A3,,Б2,Б3,... игнорируются - на них отвечают другие мосты,

3) при поступлении пакета от А1 или Б1 мост меняет MAC-адрес получателя на MAC-адрес Б1 или А1 соответственно,

4) после этого пакет отправляется дальше без обработки на layer3.

Share this post


Link to post
Share on other sites
или только source или только destination
для трафика в мир - source, для трафика из мира - destination.
Умеет ли это D-Link???

ip_source и ip_destination это что по-вашему? Не знаю, реально работает оно у вас или нет, но "весчь" есть.

Во-первых, у нас коммутатор D-Link, у него в настройках есть LACP, но нет EtherChannel.Правда, там есть такая весчь:
#config link_aggregation algorithm ?
Command: config link_aggregation algorithm
Next possible completions:
mac_source mac_destination mac_source_des ip_source ip_destination ip_source_dest

Share this post


Link to post
Share on other sites
или только source или только destination
для трафика в мир - source, для трафика из мира - destination.
Умеет ли это D-Link???

ip_source и ip_destination это что по-вашему? Не знаю, реально работает оно у вас или нет, но "весчь" есть.

Вопрос был - умеет ли D-Link использовать разные алгоритмы для разных транков?

Насколько я понял, "config link_aggregation algorithm xxx" действует на все транки сразу,

поэтому оптимальный алгоритм по прежнему под вопросом. Наверное, всё же "mac_source_dest".

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this