LINUX.ORG.RU
ФорумAdmin

[bonding][load sharing] Соединение через управляемый свитч.

 


0

1

Здравствуйте.

Пытаюсь настроить сабж для конфигурации ХОСТ - СВИТЧ - ХОСТ.

На каждом хосте по 2 сетевые карты. Свитч поддерживает addressed-based algorithms:

L2 — Based on layer 2 MAC (default);

L3_L4 — Based on layer 3 IP and layer 4 port;

lacp — link aggregation group handled by LACP

Из документации по режимам bonding: balance-rr — не подходит, работает только при прямом соединении сетевых карт; active-backup — не подходит по условиям; balance-xor — может быть и подошло бы… если бы свитч поддерживал; broadcast — не подходит по условиям задачи; 802.3ad — синхронизируется, подключается, но при работе почему-то используется только один канал (даже если нагружаю iperf с ключом -P 2), соответственно, скорость выше 115 MBytes/sec не поднимается; balance-tlb и balance-alb не пробовал пока что, но указано, что они для свитчей без поддержки агрегации каналов, так что, думаю, что заработает оно. Однако, хочется пока понять, можно ли поднять скорость, используя в т.ч. и возможности свитча.

Итак, в моём случае, похоже, единственным вариантом остаётся 802.3ad. Умеет ли этот протокол load balancing и если да, то что виновато в отсутствии этой балансировки: настройки

Ethernet Channel Bonding Driver: v3.7.0 (June 2, 2010)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 1001
        Partner Mac Address: AAAAAA

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: BBBBBB
Aggregator ID: 2
Slave queue ID: 0

Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: BBBBBBB
Aggregator ID: 2
Slave queue ID: 0
, драйвер сетевых карт r8169 или свитч?



Последнее исправление: HolyBoy (всего исправлений: 1)

Не ответ, но может поможет

Я как-то сделал Bond из 6 сетевых карт все Гигабит. Одна карта интел 4 головая и две встроенные реалтеки такие же. Так вот долго гадал (пока Mi-Aya не подсказал) почему в таком толстом канале так все медленно. Протестировали и поняли что именно реалтеки вызывали неверную работу bond. Убрали реалтеки и получили почти 4 гигабита. Может они друг с другом и хорошо работают конечно. Отдельно их не пробовал объединять. Режим был balance-rr.

petav ★★★★★
()
Ответ на: Не ответ, но может поможет от petav

Ну ладно, подожду, когда приедут сервера с сетевыми картами от интела.

Однако, в моём случае, balance-rr не годится, т.к. соединение через свитч идёт. Напрямую риалтеки нормально 2 гигабита давали.

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

Через свич ты не получишь умножения скорости через ОДНО tcp-соединение.
Выбор порта передачи на свиче и хостах идёт используя хеш ip-адресов, маков и портов - читай документацию (bonding.txt).
Циски например хешируют только айпи адреса, так что при передаче с одного айпи на другой будет юзаться только один канал.

Хочется ускорить одно соединение - только кроссовером + balance-rr & co.

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

Или как извращенный вариант - выделить на каждую пару портов от хоста1 и хоста2 на свиче свой приватный влан и получить аналог прямого соединения с balance-rr

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

Ага, я это уже в субботу испробовал. Вроде работает. Сегодня протестирую некоторые нюансы: если будет нормально, то этот вариант и пойдёт в работу.

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

>> balance-rr — не подходит, работает только при прямом соединении сетевых карт

Через свич ты не получишь умножения скорости через ОДНО tcp-соединение.


http://www.mjmwired.net/kernel/Documentation/networking/bonding.txt

balance-rr or 0

Round-robin policy: Transmit packets in sequential
order from the first available slave through the
last. This mode provides load balancing and fault
tolerance.

balance-rr: This mode is the only mode that will permit a single
      TCP/IP connection to stripe traffic across multiple
      interfaces. It is therefore the only mode that will allow a
      single TCP/IP stream to utilize more than one interface's
      worth of throughput. This comes at a cost, however: the
      striping generally results in peer systems receiving packets out
      of order, causing TCP/IP's congestion control system to kick
      in, often by retransmitting segments.
   
      It is possible to adjust TCP/IP's congestion limits by
      altering the net.ipv4.tcp_reordering sysctl parameter. The
      usual default value is 3, and the maximum useful value is 127.
      For a four interface balance-rr bond, expect that a single
      TCP/IP stream will utilize no more than approximately 2.3
      interface's worth of throughput, even after adjusting
      tcp_reordering.

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

Ну вот, проверил: взял три хоста, соединил их парными линками со свитчем. Создал на свитче два VLAN, назначил каждый линк из каждой пары в один из этих нетегированных VLAN. На хостах создал bond-интерфейс, поверх него — VLAN-интерфейс. На свитче создал третий VLAN, назначил его всем линкам как тегированный.

Вроде, всё работает как положено: пинги не пропадают, скорость высокая.

Другое дело, что, как я и ожидал, появились такие неприятные штуки, как двойные пакеты:

# ping -f fs_1
PING fs_1 (172.16.0.1) 56(84) bytes of data.                                                                                                                       .^C
--- fs_1 ping statistics ---
36588 packets transmitted, 36587 received, +2 duplicates, 0% packet loss, time 34755ms
rtt min/avg/max/mdev = 0.210/0.822/3.572/0.182 ms, pipe 2, ipg/ewma 0.949/0.776 ms

Насколько это серьёзно? Можно ли забить на такое или это грозит проблемами при передаче TCP/UDP?

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

В принципе для TCP это пофиг, он спроектирован чтобы работать на хреновых линках, где дупы не редкость. Так что 2 дупа из 36 тысяч пакетов это не критично ИМХО.

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

Кстати сейчас сильно подешевели сетевухи 10Гбит, так что если не хочется геморроится с бондингом можно взять их + пассивный SFP-кабель или просто с RJ45...

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

Проблема не в этом.

Сетевые может и подешевели, но свитчи — нет. Никто у нас не будет менять активное оборудование только из-за этого. Кроме того, balance-rr прекрасно работает на соединениях типа хост-хост. Это с хост-свитч-хост проблемы и извращения всякие лезут.

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

TCP — да, может и пофиг, а вот UDP (а он там будет местами) — нет. Поэтому я и хочу уйти от костыля с VLAN.

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

Если соединять два-три хоста, то можно и напрямую их.
У меня так три ESXi хоста с виртуалками подключены напрямую к хранилищу, в котором 3 двухпортовых 10Гбит карты, всё работает на ура.

Сэкономлено 300-400 тыщ на покупке свича 10Гбит...

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