Я пытаюсь выбрать между решением для балансировки нагрузки уровня 4 для моего центра обработки данных или решением уровня 7. К сожалению (для моего рассудка), мой вариант использования достаточно прост, чтобы оба решения работали хорошо, избегая большинства слабых мест и не используя сильные стороны другого. Какое бы решение мы ни использовали, оно должно иметь высокую доступность и высокую пропускную способность. Но мы планируем использовать его только для балансировки нагрузки по кластеру веб-серверов, ни один из которых не имеет никаких требований к «липкому» управлению сеансом (cookie или IP), сложным правилам перезаписи или, если на то пошло, любым правилам перезаписи на все.
Балансировщики нагрузки будут подключены к двум коммутаторам, оба с независимым подключением до уровня агрегации центра обработки данных и объединены вместе с помощью Rapid Spanning Tree и любого проприетарного протокола, который коммутаторы используют для виртуализации. Балансировщики нагрузки также будут связаны друг с другом перекрестным кабелем. Все серверы в кластере подключены к обоим коммутаторам. Все, что нужно сделать балансировщикам нагрузки, - это направить трафик поверх них.
Поскольку это просто HTTP, я могу использовать решение для балансировки нагрузки уровня 7, такое как HAProxy или nginx. Но я мог бы также использовать проект LVS с ldirectord, keepalived или чем-то еще.
Я попытался разделить все «за» и «против», как я их вижу, но все закончилось размыванием. Что бы вы порекомендовали и почему? Я что-то упускаю?
Одно из полезных преимуществ «L7», такого как haproxy, - это возможность использовать файлы cookie, чтобы один и тот же браузер работал с одним и тем же внутренним сервером. Это значительно упрощает отладку обращений клиентов.
Балансировка L4 может перебросить одного пользователя на несколько внутренних серверов. (что в некоторых случаях может быть выгодным, но с точки зрения отладки / профилирования использование «L7» гораздо более ценно.)
РЕДАКТИРОВАТЬ: Существует также потенциальное преимущество в скорости использования балансировки HTTP. С помощью keep-alives клиенты могут установить один сеанс TCP с вашим балансировщиком, а затем отправить множество HIT без необходимости повторно устанавливать новые сеансы TCP (трехстороннее рукопожатие). Точно так же многие LB поддерживают сеансы поддержания активности с серверными системами, избавляя от необходимости выполнять такое же рукопожатие на серверной части.
Строгая балансировка нагрузки TCP может не решить и то и другое так легко.
/ * FWIW: Я бы не сказал «L7» или «L4», я бы сказал HTTP или TCP. Но я сторонник того, чтобы избегать использования OSI для описания вещей, с которыми он не совпадает. * /
Я считаю, что если вы не знаете, что развертывать, выбирайте то, что кажется вам простым и естественным. Протестируйте его (используйте apache bench?) И убедитесь, что он работает для ваших нужд. Мне HTTP LB более естественен.
Учитывая отсутствие для вас преимуществ от балансировки L7, я бы вместо этого остановился на балансировке L4. Я большой поклонник того, чтобы все было как можно проще, не жертвуя слишком многим.
L7 требует, чтобы балансировщики проверяли заголовки http в пакетах, которые проходят через них, на предмет соответствующей маршрутизации, добавляя дополнительные накладные расходы и незначительное увеличение задержки для конечного пользователя. Мне это кажется бессмысленным расходом, если вы ничего от этого не выиграете.
Некоторые поставщики DNS имеют простую функцию аварийного переключения. Вы упомянули, чем не являются ваши требования, а не какими они являются, но если все, что вам нужно, это циклический перебор с переключением при отказе, если что-то не работает, вы можете использовать, например, Отказоустойчивость zoneedit.com. В зависимости от ваших потребностей в высокой доступности этого может быть достаточно, и вы можете пропустить целый уровень в своей архитектуре.