Если бы стоимость не была проблемой, была бы какая-нибудь выгода от развертывания программного балансировщика нагрузки для веб-трафика по сравнению с аппаратным?
Различие между «аппаратными» и «программными» балансировщиками нагрузки больше не имеет смысла. Так называемый «аппаратный» балансировщик нагрузки - это ЦП класса ПК, сетевые интерфейсы с возможностями обработки пакетов и некоторое программное обеспечение, связывающее все это вместе. «Программный» балансировщик нагрузки, реализованный на хорошем сервере с современными сетевыми адаптерами, - это ... то же самое.
Что вы получаете с высококачественными коммерческими предложениями, такими как F5 или Citrix Netscaler, это:
С программными балансировщиками нагрузки (с открытым исходным кодом) вы не получите противоположного: то, что вы получите, зависит от программного обеспечения, которое вы выберете, и от того, как вы это делаете. Тем не менее, обычно вы увидите:
На самом деле, разница не в «аппаратном» и «программном». Речь идет о «купите проверенный технологический стек в качестве устройства», а не «соберите его самостоятельно». Конечно, при принятии окончательного решения необходимо учитывать множество переменных (затраты, набор навыков, допускаемое время простоя, будущий рост и т. Д.).
Аппаратные балансировщики нагрузки обычно имеют более богатый набор функций, особенно когда вы переходите к таким большим, как F5. У вас также есть дополнительное преимущество большей масштабируемости за счет разгрузки оборудования.
С другой стороны, если вы знаете, что ваш трафик не будет слишком большим, программные балансировщики нагрузки действительно работают достаточно хорошо. Если у вас есть LB уровня 4, Linux LVS + Keepalived - очень хороший вариант. Если вам нужна мощность Layer 7 LB, вы можете попробовать HAProxy.
Таким образом, HW LB обычно масштабируются лучше, чем SW LB.
Надеюсь это поможет!
Несколько мыслей:
Pro: машина, на которой вы запускаете балансировщик нагрузки, может иметь гораздо более мощное оборудование, поэтому будет работать быстрее и вызывать меньше дополнительных задержек (хотя в зависимости от скорости ваших ссылок на внешний мир это может иметь небольшое значение).
Против: аппаратный балансировщик нагрузки, скорее всего, не будет иметь больше вычислительной мощности, чем ему нужно (он может работать на чипе на базе Atom или ARM, а не на массивном высокопроизводительном процессоре Intel / AMD, например), поэтому будет потреблять меньше энергии и выделять меньше тепла.
Pro: установка собственного программного балансировщика нагрузки может дать вам большую гибкость в настройке и последующих обновлениях / изменениях, когда аппаратное решение может быть в большей степени закрытым решением «черного ящика». Хотя, если вы покупаете управляемую услугу для реализации программного балансировщика, это не имеет большого значения.
Против: если вы не управляете программным балансировщиком (т.е. задача передана на аутсорсинг или вы приобретаете услугу как часть более крупного управляемого хостинга), вы можете обнаружить, что административные сборы за поддержание настройки означают, что готовое аппаратное решение будет будет дешевле в долгосрочной перспективе. Также не забудьте учесть ваш время на любые затраты, если вы или ваша компания будете управлять балансировщиком нагрузки.
Я бы также принял во внимание эти моменты:
Если в компании есть ИТ-отдел со специалистом по сетям, то аппаратная LB может помочь снизить нагрузку на обслуживание со стороны группы разработчиков.
Иногда, особенно для крупных компаний, внедрение нового оборудования, с которым никто не умеет работать, подразумевает наем дорогостоящих консультантов или даже новую работу.
Команда разработчиков возненавидит аппаратное решение, если они планируют усилить функции балансировщика нагрузки, например, чтобы внедрить непрерывное развертывание.
Очевидно, HW LB могут улучшить обработку SSL-соединений и, следовательно, уменьшить общее количество необходимых серверов приложений: