Я разработал веб-приложение. Он будет работать на ферме из пяти серверов IIS. Абсолютно важно, чтобы после установления сеанса с сервером в ферме дальнейшие HTTP-запросы в рамках этого сеанса направлялись на тот же сервер до конца сеанса.
Сегодня я обнаружил веб-сайт F5 и узнал о «липких сессиях». Из-за того, что большинство моих пользователей будут мобильными (например, iPhone), возможно, что их IP-адрес может измениться в разгар одного сеанса. Это означает, что исходный IP-адрес не может использоваться для идентификации уникальных сеансов. Официальные документы предполагают, что устройство F5 LTM предоставляет решение для этого, позволяя мне использовать контент в самом HTTP-запросе [или файле cookie] для определения идентичности сеанса.
Все идет нормально. Но потом я подумал… Это устройство F5 - единственная точка отказа. Кроме того, что, если я резко увеличу емкость и захочу добавить больше устройств F5? Создание кластера из них имеет смысл. Но, несмотря на то, что я стараюсь гуглить, я не могу найти официальный документ, описывающий базовые концепции того, как кластер функционирует «под капотом».
Рассмотрим… Допустим, я покупаю два устройства F5. У них общий «виртуальный» IP-адрес на внешнем (выходящем в Интернет) интерфейсе моей сети. Приходит HTTP-соединение, и каким-то образом два устройства определяют, что F5 # 1 должен ответить на вызов. У F5 # 1 теперь есть карта в памяти, которая связывает идентификатор этого сеанса [скажем, через cookie] с внутренним веб-сервером # 4. Две минуты спустя тот же клиент инициирует новое HTTP-соединение как часть того же сеанса. «Виртуальный» IP-адрес назначения такой же, но его исходный IP-адрес изменился. Как я могу гарантировать, что F5 # 1 получит это соединение вместо F5 # 2? Если первый получает его, мы в хорошей форме, потому что у него есть карта в памяти для идентификации сеанса. Но если последний получит его, он не узнает, что сеанс связан с веб-сервером №4.
Два устройства F5 как-то обмениваются информацией друг с другом, чтобы это работало? Или конфигурация, которую я описываю, просто не является практичным / распространенным способом работы?
Извините за вопросы новичка ... все это для меня в новинку.
Большинство F5 входят в пары HA, поэтому они будут сгруппированы. Как только один F5 выходит из строя, IP-адреса принимает другой F5 в паре, поэтому простоя не возникает. По вашему вопросу, каждый IP-адрес назначается только одному F5 за раз и не является действительно активным / активным для обоих.
Это ваше решение, теперь следующий вопрос, который вы должны задать: что произойдет, если весь сайт выйдет из строя, где размещены оба F5? (А затем изучите глобальную балансировку нагрузки).
Я не верю, что вы действительно можете «кластеризовать» два переключателя содержимого F5, хотя я считаю, что они работают над этой функцией, но я могу ошибаться. Кластеризация балансировщиков нагрузки - это огромная инженерная задача: как они обмениваются информацией на уровне 4 или 7, как они обмениваются данными на уровне 2 или уровне 3 и как кластеризация и совместное использование информации включаются, не влияя на производительность, поскольку балансировщики нагрузки должны работать по существу на скорости провода.
Подумайте о брандмауэрах в старые времена, брандмауэры на основе прокси всегда были автономными узлами, потому что они так много делали на уровне 7, и было практически невозможно обмениваться этой информацией между узлами без снижения производительности, тогда как фильтры пакетов с отслеживанием состояния должны были передавать только уровень 4. информация и даже это накладные расходы. Балансировщики нагрузки обычно развертываются с большей частью своей конфигурации, как в вашем случае с виртуальными IP-адресами, действующими в качестве конечной точки, и поэтому весь сеанс TCP перезаписывается, и балансировщик нагрузки становится клиентом для сервера (то есть, по сути, существует два потока и это одна из причин, по которой фактический клиент не может выполнять конвейерную обработку http напрямую к внутреннему серверу).
С HA вы не достигнете желаемого масштабирования, поэтому вам придется масштабировать балансировщик нагрузки, чтобы справиться с нагрузкой и т. Д. Такие поставщики, как и с масштабированием, обычно (не всегда, как иногда вы может включить дополнительный ЦП с обновлением лицензии) означает, что новый, более крупный блок HA действительно обеспечивает отказоустойчивость и надежность, хотя, очевидно,. С HA у вас обычно есть распространение команд, синхронизация конфигурации и некоторый элемент обмена сеансами (который может быть настроен до определенной степени, поскольку это может вызвать нагрузку).
Вы можете посмотреть на масштабирование путем балансировки нагрузки ваших балансировщиков нагрузки (например, LB -> LB -> Web Farm), но это не очень хорошо, может вызвать задержку, (очень) дорого, и ваша инфраструктура имеет еще одну точку отказа, хотя я это видел успешно реализовано.
Вы можете использовать что-то вроде VRRP, который почти похож на квазикластер. В этой реализации у вас может быть два набора пар балансировщиков нагрузки HA перед вашей веб-фермой, назовите их HA1 и HA2. С помощью VRRP вы можете создать два виртуальных IP-адреса, один из которых находится на HA1 (vip1), а другой - на HA2 (vip2) из-за более высокой конфигурации приоритета VRRP. И vip1, и vip2 могут переключаться на другую пару HA через VRRP либо автоматически (на основе мониторов и т. Д.), Либо вручную, понижая приоритет VRRP.
У большинства поставщиков есть статьи базы знаний по вышеуказанным конфигурациям. Я считаю, что есть один поставщик, у которого есть настоящая кластеризация в своем продукте, но для этого я позволю вам погуглить.
Все балансировщики нагрузки имеют различные формы сохраняемости, которые вы применяете к ассоциации внутреннего сервера. Сегодня популярными формами являются файлы cookie и хеш (на основе 4-кортежей и одного или двух других элементов). Когда балансировщик нагрузки действует как конечная точка, как в вашем сценарии, после того, как TCP-соединение будет полностью установлено, он по существу создаст буфер управления протоколом, который будет содержать информацию о соединении (по сути, 4-кортеж и несколько других вещей очередной раз). Таких буферов два, по одному с каждой стороны соединения, и этот буфер находится в памяти балансировщика нагрузки до завершения сеанса, когда они очищаются, чтобы освободить память для повторного использования.
Citrix NetScaler кажется наиболее продвинутым решением для балансировки нагрузки, особенно в области кластеризации. Вам не нужно устанавливать пару HA, просто используйте кластер из двух блоков. Затем, если вы хотите расти, просто добавьте больше ящиков в кластер. Они также могут кластеризовать балансировщики нагрузки, работающие на виртуальных машинах.
Для всех балансировщиков нагрузки можно настроить пару HA, чтобы предотвратить единую точку отказа. Так было всегда. Большой IP стоит дорого. Вы рассматривали Citrix NetScaler. Есть версия для виртуальной машины, которая намного дешевле. На самом деле есть бесплатная версия, которую вы можете использовать в производственной среде с ограниченной пропускной способностью. Не только это, но и при необходимости вы можете развернуть NetScaler VPX на тех же серверах, что и ваше приложение. Просто мысль. напишите мне, если хотите более подробную информацию.
У вас в основном есть два варианта здесь, на платформе F5, в зависимости от типа настраиваемого VIP. На VIP уровня 4 (фактически NAT) вы можете настроить зеркальное отображение подключения, которое позволяет не прерывать сеанс TCP во время события высокой доступности. Это невозможно для VIP уровня 7 - просто существует слишком много состояний для «резервного копирования» в резервный режим в реальном времени - но вы можете зеркалировать записи сохраняемости файлов cookie, которые будут гарантировать, что после аварийного переключения HA, когда клиент повторно подключится, он будет перенаправлен на тот же внутренний сервер.
У меня нет информации из первых рук, но я считаю, что Netscaler имеет аналогичные возможности.
Тем не менее, схема, полностью зависящая от этого типа постоянства, будет иметь проблемы, особенно если у вас есть внутренние серверы, которые входят и выходят из ротации VIP на любой регулярной основе. Я бы посоветовал вам исследовать создание общего кеша (memcached отлично подходит для этого), который любой член вашего пула серверов может запросить для проверки файла cookie при входящем запросе. Это проще, чем вы думаете :)