Уровень 4 против уровня 7 Балансировка нагрузки

Я пытаюсь решить, использовать ли решение балансировки нагрузки уровня 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 имеют простую функцию восстановления после отказа. Вы упомянули, что ваши требования не таковы, а не то, чем они являются, но если все, что вам нужно, это циклический перебор с отработкой отказа, если что-то не работает, вы можете использовать, например , Failover Zoneedit.com . В зависимости от ваших требований HA это может быть достаточно хорошим, и вы можете пропустить целый уровень в вашей архитектуре.