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

У нас есть веб-ферма машин IIS7, которые прекрасно работают. Перед ними аппаратный балансировщик нагрузки F5 Big-IP , тоже отлично работающий :)

_{(источник: www.f5.com )}

В настоящее время мы используем ASP.NET State Serviceдля обработки нашего состояния OutProc . Это необходимо, когда у вас есть веб-ферма для поддержки любого типа информации о сеансе.

Мне было интересно, можем ли мы проводить липкие сессии на F5 Big-IP и, следовательно, перейти с OutProc обратно на InProc? Если так, то в чем заключается обратная сторона этого? Я знаю обратную сторону InProc против OutProc, поэтому не беспокойтесь об этом. Меня больше интересуют плюсы и минусы липких сессий без F5 Big-IP .

Может ли кто-нибудь пролить свет и / или опыт?

Есть два основных недостатка:

1. Ваша нагрузка распределяется неравномерно. Липкие сессии будут придерживаться, отсюда и название. Хотя первоначальные запросы будут распределяться равномерно, у вас может оказаться значительное количество пользователей, которые тратят больше времени, чем другие. Если все они изначально настроены на один сервер, этот сервер будет иметь гораздо большую нагрузку. Как правило, это не будет иметь большого влияния и может быть уменьшено, если в вашем кластере будет больше серверов.

2. Прокси объединяют пользователей в один IP, и все они отправляются на один сервер. Хотя это, как правило, не вредит, опять же, кроме увеличения нагрузки на отдельные серверы, прокси также могут работать в кластере. Запрос в ваш F5 от такой системы не обязательно будет отправлен обратно на тот же сервер, если запрос поступает с другого прокси-сервера в их прокси-кластере.

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

Хотя сеансы на основе файлов cookie должны работать, у меня были некоторые проблемы с ними, и я обычно выбирал сеансы на основе IP. БОЛЬШОЕ ОДНАКО: я в основном работаю над внутренними приложениями - DMZ может варьироваться.

После всего этого мы добились большого успеха на сайтах, работающих под управлением F5, с липкими сессиями и сессиями In-Proc.

Возможно, вы захотите взглянуть на одну из систем распределенного кэширования в памяти, такую ​​как Memcached или Velocity, чтобы найти альтернативу сеансу, хранящемуся в SQL, или службе out of proc. Вы приближаетесь к скорости встроенной памяти с возможностью запуска ее на нескольких серверах.

Недавно я прочитал отличную статью в TechNet на тему «Обеспечение масштабируемости для приложений ASP.NET». Это вошло в плюсы и минусы каждого возможного решения. Возьмите чтение:

TechNet, июнь 2009 г. - Обеспечение масштабируемости для приложений ASP.NET

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

Я считаю липкие сессии сильным индикатором плохой архитектуры приложений и / или плохого программирования. «Избегай любой ценой» - мой девиз.