Вот такая ситуация. Я хотел бы подключить свои серверы Linux к единой сети, используя двойное соединение для обеспечения отказоустойчивости и балансировки нагрузки. На серверах есть 2 или более 1-гигабайтных сетевых карт, и я планирую подключить каждый из них к другому коммутатору, который находится в одном стеке (то есть к одному виртуальному коммутатору). Все коммутаторы - Juniper EX4200 или EX4500.
Я знаю, что могу использовать любой из режимов связывания Linux, и мне интересно, какой из них лучший. Раньше я использовал режим активного резервного копирования, потому что некоторые серверы подключались к коммутаторам без стека, но теперь у нас есть новая и согласованная сеть, и я хотел бы использовать режим связывания, который предлагает балансировку нагрузки в дополнение к отказоустойчивости.
Я подумал, что лучшим режимом для использования является 802.3ad (LACP), потому что этот стандарт используется на всем сетевом оборудовании, но, как оказалось, в тот момент, когда я настраиваю набор портов как канал LACP на стороне коммутатора, соединение разрывается, пока я не также правильно настройте серверную часть. Это значительно усложняет наши задачи системного администрирования, потому что перед установкой нового сервера мы должны удалить конфигурацию LACP на коммутаторе (потому что такие вещи, как загрузка PXE и сетевая установка, не работают на портах LACP), и после установки нам необходимо изменить коммутатор. настройки снова, но только после того, как сервер будет настроен на использование LACP, иначе соединение прекратится.
Другие режимы соединения, такие как balance-alb, не требуют какой-либо специальной настройки на стороне переключателя, тогда как на бумаге такие же преимущества.
Есть ли причина выбирать 802.3ad вместо balance-alb?
В balance-alb загрузка и отправка, и получение кадров балансируются с использованием трюка изменения MAC-адреса. Это может вызвать проблемы на уровне приложений. Не все приложения подходят для этого режима.
Чтобы решить вашу первоначальную проблему. Вот что я делал раньше.
Чакри -
Я не очень хорошо знаком с коммутаторами Juniper, но вам не нужно настраивать на них LACP; который является точка LACP. Если это не так, что-то не так с вашей конфигурацией коммутатора.
LACP указывает только протокол для динамического агрегирования портов. Он не определяет политику планирования портов (куда отправляется и принимается трафик). Эта политика устанавливается отдельно. Я не помню процесс в Linux, но я знаю, что Linux поддерживает указание нескольких разных политик, вероятно, похожих на balance-alb.
Balance-alb имеет определенные недостатки. В основном то, что он полуинтеллектуально выбирает исходящий порт для новых подключений, и они привязаны к этому порту на весь срок существования соединения (на самом деле это делается по MAC, а не по порту, если порт выходит из строя, MAC назначается другому порту. , что позволяет продолжить соединение).
Однако это не совсем «агрегация» портов, так как соединения не смогут использовать более одного порта. Таким образом, если у вас есть 2 порта 1GbE, одно соединение по-прежнему ограничено 1GbE. LACP обычно решает эту проблему, хотя это зависит от вашей политики планирования и количества активных портов, поддерживаемых на каждом конце.
LACP великолепен, когда он работает, и обеспечивает почти вдвое большую производительность по сравнению с одной сетевой картой. Если у вас небольшое количество машин с подключенными сетевыми адаптерами, сделайте это.
Но один из недостатков этого заключается в том, что у вас небольшой бюджет и поэтому при использовании коммутаторов более низкого уровня им, как правило, не хватает достаточного количества групп LACP и функций MLAG или SMLT. Как минимум, большинство коммутаторов от HP и аналогичных, похоже, предлагают столько же групп соединения, сколько и половины портов. Некоторые предлагают даже меньше. Супермикро-коммутатор 2k, который мы использовали в какой-то момент, имел только 8 групп LACP, несмотря на 52 порта. Я предполагаю, что это число относительно произвольно. Никто не думал, что вам понадобится больше, чем 1/2 количества портов коммутатора. Вероятно, это просто жестко закодированный номер в прошивке и, вероятно, занимает немного больше памяти.
Но это действительно огромное ограничение, если вы используете SR-IOV, связывание и виртуальные машины.
Если вы поставщик, который хочет разместить в стойке, возможно, сотни или тысячи машин, вам не обязательно тратить десятки тысяч долларов на высокопроизводительный коммутатор, который важен, но излишне дорог, чтобы обеспечить избыточность и производительность для единая стойка машин. Я понимаю, почему такие компании, как facebook, хотят создавать свои собственные переключатели.
Так что в этом типе сценария я бы выбрал другой режим, возможно, balance-alb.
Если вы установили LACP на портах, к которым ваши боксы подключаются, чтобы использовать LACP, единственная «правильная» настройка на стороне хоста - использовать LACP. EX будет балансировать в соответствии с MAC-адресами источника и назначения Ethernet для трафика Ethernet и будет учитывать IP-адрес источника / назначения / порта для IP-трафика, если в ваших кадрах есть IP-пакеты. Пожалуйста, прочтите Можжевельник KB22943 для получения подробной информации об алгоритмах хеширования. Если ваш коммутатор поддерживает межстековый LACP (что имеет место для 4XXX EX), используйте LACP, если у вас есть стек. Также может быть проще отлаживать, если у вас более сложная топология L2 с петлями для каждой VLAN и т. Д.