LACP по сравнению с ручным разделением нагрузки

Я использую:

  • CoovaChilli (для присоединенного портала) - http://coova.org/CoovaChilli
  • FreeRADIUS (для источника аутентификационной информации) - http://freeradius.org/
  • DaloRADIUS (для ведения счетов) - http://daloradius.com/
  • MySQL (для бэкенда DB к FreeRADIUS и Dalo)
  • На TurnKey Linux. (Который является просто упрощенным дистрибутивом Ubuntu.)

Для Вашей установки Вы, вероятно, хотели бы установить центральный RADIUS/веб-сервер для хостинга логинов горячей точки и автора, затем просто CoovaChilli на шлюзах доступа. (DaloRADIUS включает некоторые достойные страницы начинающего для использования с Перцем чили под daloradius/contrib/chilli),

Подробнее:

0
задан 10 January 2014 в 05:49
2 ответа

Пропускная способность не должна быть единственным соображением - также рассмотрите избыточность.

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

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

Итак, какой из этих двух сценариев, по вашему мнению, будет более распространен в вашей среде? И вот ваш ответ.

(Например, с LACP у вас может быть 2 сервера, обращающихся к общему ресурсу NFS со скоростью 1 Гбит / с каждый. В то время как при ручном распределении нагрузки вы все равно получите только 0,5 Гбит / с на сервер, потому что они оба должны использовать один и тот же физический Но если вы хотите гарантировать, что для ваших общих ресурсов NFS и SMB гарантировано, по крайней мере, 1 Гбит / с каждый, то ручное разделение нагрузки может оказаться подходящим вариантом).

с LACP у вас может быть 2 сервера, обращающихся к общему ресурсу NFS со скоростью 1 Гбит / с каждый. В то время как при ручном распределении нагрузки вы по-прежнему получаете только 0,5 Гбит / с на сервер, потому что они оба должны использовать одну и ту же физическую ссылку. Но если вы хотите гарантировать, что ваши общие ресурсы NFS и SMB имеют гарантированный минимум 1 Гбит / с каждый, то ручное разделение нагрузки может оказаться подходящим вариантом). с LACP у вас может быть 2 сервера, обращающихся к общему ресурсу NFS со скоростью 1 Гбит / с каждый. В то время как при ручном распределении нагрузки вы все равно получите только 0,5 Гбит / с на сервер, потому что оба они должны использовать одну и ту же физическую ссылку. Но если вы хотите гарантировать, что для ваших общих ресурсов NFS и SMB гарантировано, по крайней мере, 1 Гбит / с каждый, то ручное разделение нагрузки может оказаться подходящим вариантом).

0
ответ дан 5 December 2019 в 14:28

Если ваш коммутатор настроен на балансировку на основе уровней 3 + 4 (IP и порт), вы, вероятно, увидите отдельный интерфейс, используемый для каждого потока данных. Предположим, у вас есть несколько подключений от одной конечной точки с использованием диапазона портов TCP. Коммутатор почти всегда выбирает отдельный интерфейс для каждого сеанса tcp. Я видел это только однажды в нескольких сотнях различных сред.

В этом случае LACP идеален, потому что вам не нужно управлять всеми отдельными IP-адресами, которые будут использоваться клиентами. Дополнительная избыточность - это дополнительный бонус.

0
ответ дан 5 December 2019 в 14:28

Теги

Похожие вопросы