Для этого приложения меня меньше заботит высокая доступность, чем общая пропускная способность. У меня есть один IP-адрес на стороне сервера, и я хочу иметь возможность отправлять с сервера более 1 гигабита трафика. Сервер имеет две 1-гигабитные карты и подключен к паре коммутаторов. Приложение включает в себя тысячи удаленных клиентов по всему миру, подключающихся к серверу (то есть не к локальной сети).
В настоящее время связывание настраивается с использованием режима 5 (balance-tlb), но в результате пропускная способность для каждого порта не будет превышать 500 Мбит / с. Как я могу преодолеть этот предел? Предположим, что у меня нет доступа к коммутаторам, поэтому я не могу реализовать 802.3ad.
(Я надеялся добавить тег «связывание», но я не могу добавить новые теги, так что это «объединение».)
Маловероятно, что вы достигнете 2 гигабит без взаимодействия на уровне коммутатора, и даже тогда это может быть сложно с одной лишь комбинацией IP-адреса источника / назначения. Большинство команд настроены на IP-хеширование, при котором каждому источнику / получателю выделяется один путь NIC. Таким образом, вы получите только 1 гигабит. Существуют циклические схемы, но вы часто можете обнаружить, что поступление пакетов не в порядке, что делает его нежелательным, если и хост, и место назначения не поддерживают эту схему.
Тебе понадобится Агрегация портов на портах коммутатора (необходимо объединить два порта коммутатора доступа, которые подключены к 2-гигабитным портам на вашем компьютере). Но, как только это будет достигнуто, вы должны приблизиться к пути 2 Гбит / с (ограниченному возможностями машины).
Если агрегация портов на коммутаторе соответствует логическому порту 2 Гбит / с драйвера связывания, вы будете использовать мультиплексированный резервный путь только с одним IP-адресом на машине.
Вот несколько интересных заметок, которые я наткнулся на это сейчас, Вот .
У этой замечательной функции связующего драйвера Linux есть и обратная сторона - он работает только с сетевыми интерфейсами, которые позволяют изменять MAC-адрес, когда интерфейс открыт. Режим balance-alb зависит от уловки быстрого ARP, чтобы обмануть ядро и заставить его думать, что два физических интерфейса являются одним целым, путем перезаписи MAC-адреса на лету. Поэтому драйвер интерфейса должен поддерживать это, а многие из них нет.
Но это еще не все, что умеет связывать драйвер. Опция режима дает вам семь вариантов, и вам не нужно беспокоиться о совместимости интерфейса. Однако вам нужно учитывать, что поддерживают ваши коммутаторы. Для режимов balance-rr, balance-xor и широковещательной передачи порты коммутатора должны быть сгруппированы вместе. Это происходит под разными именами, поэтому ищите «группировку магистралей», «etherchannel», «агрегацию портов» или что-то подобное. 802.3ad требует поддержки 802.3ad в коммутаторе.
Во-первых, вы, вероятно, знаете, что на самом деле никогда не достигнете 2 Гбит / с. Накладные расходы TCP / IP ограничивают вас, вероятно, 90% от максимума.
Во-вторых, даже если вы используете механизм разгрузки TCP, стек над уровнем 3 определенно влияет на то, где находится узкое место. Другими словами, как вы передаете данные? Я мог бы иметь сетевые карты 10 Гбит / с и кроссовер между ними, и я бы не получил более нескольких сотен Мбит / с, если бы использовал rsync через туннель ssh.
Что еще вы можете рассказать о топологии? Вы сказали, что сервер подключен к паре коммутаторов и что удаленные клиенты находятся по всему миру. У вас есть соединения WAN> 500 Мбит / с (совокупно)?
Мы действительно не решили эту проблему. Что мы сделали, так это настроили два сервера, один из которых привязан к IP-адресу на каждом интерфейсе, а затем выполнили приведенные здесь инструкции, чтобы заставить трафик выходить на порт, на который он пришел:
http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/
Немного доработан для нашей ситуации. В этом примере шлюз 192.168.0.1, а IP-адреса сервера 192.168.0.211 и 192.168.0.212 на eth0 и eth1 соответственно:
printf "1\tuplink0\n" >> /etc/iproute2/rt_tables
printf "2\tuplink1\n" >> /etc/iproute2/rt_tables
ip route add 192.168.0.211/32 dev eth0 src 192.168.0.211 table uplink0
ip route add default via 192.168.0.1 dev eth0 table uplink0
ip rule add from 192.168.0.211/32 table uplink0
ip rule add to 192.168.0.211/32 table uplink0
ip route add 192.168.0.212/32 dev eth1 src 192.168.0.212 table uplink1
ip route add default via 192.168.0.1 dev eth1 table uplink1
ip rule add from 192.168.0.212/32 table uplink1
ip rule add to 192.168.0.212/32 table uplink1