Аппаратные против программных балансировщиков нагрузки: просто вопрос стоимости?

Если бы стоимость не была проблемой, будет ли какая-то польза от развертывания программного балансировщика нагрузки для веб-трафика по сравнению с аппаратным?

Различие между «аппаратными» и «программными» балансировщиками нагрузки больше не имеет смысла. Так называемый «аппаратный» балансировщик нагрузки - это ЦП класса ПК, сетевые интерфейсы с возможностями обработки пакетов и некоторое программное обеспечение, связывающее все это вместе. «Программный» балансировщик нагрузки, реализованный на хорошем сервере с современными сетевыми картами, - это то же самое.

Что вы получаете с коммерческими предложениями высокого класса, такими как F5 или Citrix Netscaler, это:

• Богатый и глубокий набор функций. Их решение является зрелым и может быстро удовлетворить все общие потребности, а также некоторые необычные.
• Отличная статистика. Типы управления любят статистику, а сетевые специалисты понимают, что статистика также может быть полезна при устранении неполадок.
• Единственный поставщик, который захлебывается, когда что-то не работает, т.е. поддерживает контракт напрямую с поставщиком решения.
• Низкие расходы на зарплату. Устройство в основном просто работает, а его управление не занимает так много часов.

С (открытым исходным кодом) программными балансировщиками нагрузки вы не получите противоположного, что вы получите, зависит от программного обеспечения, которое вы выбираете, и от того, как вы это делаете. Тем не менее, как правило, вы увидите:

• Больше времени, чтобы настроить первоначальное решение. Особенно, если вам нужно больше, чем просто балансировка нагрузки, кэширование FX + перезапись контента + HA, тогда настройка программного обеспечения с открытым исходным кодом занимает больше человеко-часов.
• Вы строите это, у вас есть это. Если ваша компания устанавливает балансировщики нагрузки программного обеспечения с открытым исходным кодом с помощью собственных технических специалистов, то вы сами на 100% отвечаете за решение. Документация, путь обновления, аварийное восстановление и т. Д. Должны быть рассмотрены и, возможно, реализованы вами .

Различие не в «аппаратном», а в «программном». Он заключается в том, чтобы «купить проверенный технологический стек как устройство», а не «построить его самостоятельно». Конечно, при принятии окончательного решения необходимо учитывать множество переменных (затраты, внутренние навыки, допустимое время простоя, будущий рост и т. Д.).

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

С другой стороны, если вы знаете, что ваш трафик не будет слишком высоким, программные балансировщики нагрузки на самом деле работают достаточно хорошо. Если вы можете сделать это с помощью Layer 4 LB, Linux LVS + Keepalived является очень хорошим вариантом. Если вам нужна мощность LB уровня 7, вы можете попробовать HAProxy.

Таким образом, в общем, HW LB обычно масштабируются лучше, чем SW LB.

Надеюсь это поможет!

Несколько мыслей:

Плюс: машина, на которой вы запускаете балансировщик нагрузки, может иметь гораздо более мощное аппаратное обеспечение, поэтому будет быстрее и налагает меньше дополнительной задержки (хотя в зависимости от скорости ваших ссылок на внешний мир это может не иметь большого значения).

Против: аппаратный балансировщик нагрузки, скорее всего, будет обладать не большей вычислительной мощностью, чем ему нужно (он может работать на чипе на базе Atom или ARM, а не на мощном ЦП Intel / AMD, например), поэтому будет потреблять меньше энергии и генерировать меньше высокая температура.

Pro: установка вашего собственного программного балансировщика нагрузки может дать вам больше гибкости в настройке и последующих обновлениях / изменениях, где аппаратное решение может быть гораздо более закрытым решением «черного ящика». Хотя, если вы покупаете управляемый сервис для реализации программного балансировщика, это не будет иметь большого значения.

Против: если вы не управляете программным балансировщиком (то есть задача передается на аутсорсинг, или вы покупаете услугу как часть более крупного соглашения об управляемом хостинге), вы можете посчитать, что административные сборы за поддержку установки означают готовое оборудование Решение будет дешевле в долгосрочной перспективе. Кроме того, не забывайте учитывать свое время на любых затратах, если вы или ваша компания будете управлять балансировщиком нагрузки.

Я бы принял во внимание и эти моменты:

Если в компании есть ИТ-отдел с сетевым специалистом, то аппаратный LB может помочь снизить нагрузку на обслуживание команды разработчиков.

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

Команда разработчиков будет ненавидеть аппаратное решение, если они планируют подчеркнуть особенности балансировщика нагрузки, например, принять непрерывное развертывание.

Очевидно, что HW LB могут улучшить обработку соединений SSL и, следовательно, сократить общее количество необходимых серверов приложений:

http://highscalability.com/blog/2010/8/12/strategy-terminate-ssl-connections-in-hardware-and-reduce-se.html