В чем обратная сторона липких сеансов с балансировщиками нагрузки?
У нас есть веб-ферма машин IIS7, которые отлично работают. Перед ними F5 Большой IP аппаратный балансировщик нагрузки, тоже нормально работает :)
(источник: www.f5.com)
В настоящее время мы используем ASP.NET State Service справиться с нашими OutProc штат. Это необходимо, если у вас есть веб-ферма для обслуживания любого типа информации о сеансе.
Мне было интересно, могли бы мы липкие сессии на F5 Big-IP и, следовательно, перейти с OutProc обратно на InProc? Если да, то в чем заключается обратная сторона этого? Я знаю обратную сторону InProc и OutProc, поэтому не беспокойтесь об этом. Меня больше интересует плюсы / минусы липких сессий без F5 Big-IP.
Может ли кто-нибудь пролить свет и / или опыт?
Есть два основных недостатка:
Ваша нагрузка распределяется неравномерно. Прикрепленные сеансы будут прилипать, отсюда и название. Хотя первоначальные запросы будут распределяться равномерно, вы можете в конечном итоге получить значительное количество пользователей, проводящих больше времени, чем другие. Если все они изначально настроены на один сервер, этот сервер будет иметь гораздо большую нагрузку. Как правило, это не окажет большого влияния, и его можно смягчить, увеличив количество серверов в вашем кластере.
Прокси-серверы объединяют пользователей в один IP-адрес, и все они будут отправляться на один сервер. Хотя обычно это не вредит, опять же, кроме увеличения нагрузки на отдельные серверы, прокси также могут работать в кластере. Запрос в ваш F5 из такой системы не обязательно будет отправлен обратно на тот же сервер, если запрос исходит от другого прокси-сервера в их прокси-кластере.
В какой-то момент AOL использовала прокси-кластеры и действительно испортила балансировщики нагрузки и липкие сеансы. Большинство балансировщиков нагрузки теперь будут предлагать закрепленные сеансы на основе диапазонов сетей C-класса или, в случае F5, закрепленные сеансы на основе файлов cookie, которые сохраняют конечный узел в файле cookie веб-запроса.
Хотя сеансы на основе файлов cookie должны работать, у меня были некоторые проблемы с ними, и я обычно выбираю сеансы на основе IP. ОДНАКО: Я в основном работаю над внутренними приложениями - пробег DMZ может отличаться.
При этом мы добились большого успеха с сайтами, работающими после F5 с липкими сессиями и сессиями In-Proc.
Вы также можете взглянуть на одну из систем распределенного кэширования в памяти, например Memcached или скорость в качестве альтернативы хранению сеанса в SQL или службе памяти вне процедуры. Вы приближаетесь к скорости внутрипроцессной памяти с возможностью работы с несколькими серверами.
Недавно я прочитал в TechNet отличную статью о «Обеспечении масштабируемости для приложений ASP.NET». Были рассмотрены плюсы и минусы каждого возможного решения. Прочтите:
TechNet, июнь 2009 г. - Обеспечение масштабируемости для приложений ASP.NET
Помимо отличного ответа Кристофера, липкие сеансы означают, что вы потеряли пару огромных преимуществ резервных серверов - возможность отключить один или несколько серверов для обслуживания и прозрачность перед лицом сбоя системы.
Я считаю липкие сеансы сильным признаком плохой архитектуры приложения и / или плохого программирования. «Избегать любой ценой» - мой девиз.