Моя установка - это два сервера Dell R720, каждый из которых подключен через 4 гигабитных порта к коммутатору Cisco WS-C2960S-24TS-L, который, в свою очередь, подключен к Интернету через 100 Мбит.
На серверах работает Wheezy с ядром openvz (redhad): 2.6.32-openvz-042stab081.3-amd64
Я хочу более быструю передачу файлов между двумя серверами и некоторый уровень отказоустойчивости.
Мне удалось настроить бондинг и попробовать режимы бондинга balance-rr, 802.3ad и balance-alb. Все работало с точки зрения возможности подключения к серверам. Но я не получаю ускорения при передаче данных между ними.
(УДАЛЕНО: я понимаю, что balance-rr работает только с кабелем xover.)
Глядя на количество трафика ifconfig и отдельных интерфейсов, я вижу:
802.3ad: исходящий трафик с использованием только первого интерфейса. Это верно даже при переходе на другой хост с другим MAC-адресом.balance-alb: исходящий трафик "как-то" неравномерно распределен между интерфейсами, но входящий трафик только на одном интерфейсеДокументы ядра говорят мне, что balance-rr режим требует: The balance-rr, balance-xor and broadcast modes generally require that the switch have the appropriate ports grouped together.
The nomenclature for such a group differs between switches, it may be
called an "etherchannel"
Итак, вопрос:
Какой режим мне лучше всего использовать и как мне настроить его, чтобы он работал?
Если это вообще невозможно, это поможет каким-то образом иметь настройку, которая будет использовать разные интерфейсы для соединений сервер / сервер и сервер / Интернет. Но это должно использовать связывание, а не разные внутренние / внешние IP-адреса. (Потому что это, в свою очередь, сделало бы настройку openvz излишне сложной)
Заранее спасибо!
ОБНОВИТЬ: Поигравшись с переключателем, я настроил два etherchannels для двух серверов в «активном» режиме (это правильно?). Но, используя 802.3ad в качестве метода связывания на стороне Linux, я не заметил никаких изменений в поведении / скорости.
ОБНОВЛЕНИЕ2: Сожалею. Похоже, теперь исходящий трафик использует разные интерфейсы. Вероятно, в зависимости от MAC-адреса назначения. Это лучшее, что я могу сделать?
ОБНОВЛЕНИЕ 3: Только чтобы показать, о чем я говорю:
root@warp2:/ssd/test# iperf -c 10.0.0.1
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 23.8 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.2 port 55759 connected with 10.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 2.16 GBytes 1.85 Gbits/sec
root@warp2:/ssd/test# iperf -c x.x.x.x
------------------------------------------------------------
Client connecting to warp1, TCP port 5001
TCP window size: 23.8 KByte (default)
------------------------------------------------------------
[ 3] local 80.190.169.17 port 54861 connected with x.x.x.x port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 944 Mbits/sec
Первый тест проводится с двумя сетевыми адаптерами с использованием balance-rr и в настоящее время с двумя виртуальными локальными сетями (по одному на каждую пару сетевых адаптеров, имитирующих кабели x-link).
Второй тест - с двумя сетевыми адаптерами, использующими 802.3ad и EtherChannel.
Использование агрегации ссылок (etherchannel) не ускорит передачу одного файла. Разные соединения могут использовать разные интерфейсы в одном и том же эфирном канале для увеличения максимальной пропускной способности для одновременных передач, но при одной передаче всегда можно будет использовать только один интерфейс, что и является поведением, которое вы описываете.
Я экспериментировал с подобной настройкой и думаю, что понимаю решение. В моем случае у меня есть два сервера, каждый с двумя гигабитными сетевыми картами, подключенными через коммутаторы 3com 3824 уровня 2.
После экспериментов с различными вариантами я обнаружил, что мне нужно создать VLAN для каждой сетевой карты 1: 1 между серверами (например, VLAN, которая содержала порты коммутатора для server1: eth0 и server2: eth0, еще одну VLAN для server1: eth1 и server2: eth1. ). Это потребовало некоторой дополнительной настройки и маршрутизации, однако это привело к почти двукратному увеличению пропускной способности, как я ожидал.
Пока я не полностью усвоил детали; однако, поскольку 802.11ad использует один и тот же MAC-адрес для всех сетевых адаптеров в агрегированном канале, я предполагаю, что коммутатор будет отдавать предпочтение отправке трафика для конечного Mac через один порт, а не распределению нагрузки по всем портам агрегированного канала. Разделив каждую ссылку на свою собственную VLAN, коммутатор будет пересылать данные так же, как они отправляются - если отправитель балансирует передачу по двум портам, коммутатор пересылает их через две VLAN на два принимающих порта.
Вне всяких сомнений, единственный компромисс - это дополнительная конфигурация, позволяющая неагрегированным узлам сети получать доступ к этим серверам. Мне все еще нужно провести тестирование избыточности - есть вероятность, что если eth0 на одном сервере и eth1 на другом выйдут из строя, они потеряют связь. Однако я считаю, что это маловероятно - он должен проходить по тому же пути, что и другие хосты, и пересекать сети VLAN (также, поскольку у меня только два сетевых адаптера на сервер, потеря любого одного сетевого адаптера нарушает цель настройки, и это становится спорным точка).
Отнеситесь ко всему этому с недоверием. Я повозился с множеством опций и настроек, и я считаю, что ваш коммутатор также поддерживает уровень 3, но я вполне уверен, что объединение интерфейсов в отдельные VLAN - это билет для использования всей доступной пропускной способности.
Боюсь, вы не сможете использовать несколько ссылок ваших облигаций в такой простой настройке во время обмена трафиком между этими двумя серверами. Причина: этот коммутатор Cisco выполняет балансировку нагрузки на основе IP и MAC. То есть даже несколько передач файлов будут отображаться на один и тот же физический путь.
Он может использовать прямые перекрестные кабели. Настройка не должна быть сложной, как вы боитесь. Я считаю, что настройка openvz с переключением (Veth) здесь не нужна. Думаю, VENET и простых статических маршрутов должно хватить.
Настройка сети может выглядеть следующим образом:
10.10.0.0/24 - subnet for direct interconnect.
10.20.1.0/24 - range for VEs on Server1
10.20.2.0/24 - range for VEs on Server2
Server1:
bond1: IP=10.10.0.1/24
VE1: IP=10.20.1.1/24
VE2: IP=10.20.1.2/24
...
route 10.20.2.0/24 -> 10.10.0.2
Server2:
bond1: IP=10.10.0.2/24
VE1: IP=10.20.2.1/24
VE2: IP=10.20.2.2/24
...
route 10.20.1.0/24 -> 10.10.0.1
И iptablesРазумеется, разрешить весь этот штат и не пытаться нац / маскировать шалости.
UPD:
При переносе контейнеров лучше использовать настройку Veth… намного лучше;)