Как поддерживать состояние на нескольких веб-серверах?

Могу ли я иметь несколько веб-серверов, подключенных к кластеру SQL Server, и при этом поддерживать сеанс пользователя?

Я думал о различных подходах. На сайте Microsoft предлагается использовать response.redirect на «правильный» сервер. Хотя я могу понять причины этого, это кажется недальновидным.

Если балансировщик нагрузки отправляет вас на сервер, который в настоящее время испытывает наименьшую нагрузку, вы, как разработчик, должны это учитывать?

Существуют ли какие-либо рекомендации, которым следует следовать в этом случае? Если это так, я был бы признателен, если бы узнал, что они из себя представляют, и какие-либо идеи о плюсах и минусах их использования.


architecture web-applications iis scalability
person BobTheBuilder    schedule 13.10.2009    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Некоторые варианты:

Балансировщик нагрузки можно настроить на фиксированные сеансы. Убедитесь, что время ожидания сеанса вашего приложения меньше, чем у балансировщиков нагрузки, иначе вы получите непредсказуемые результаты.

Вы можете использовать назначенный сервер состояния для обработки сеанса. Тогда не будет иметь значения, куда их отбросит LB.

Вы можете использовать SQL-сервер для управления сеансом.

Проверьте это при сбое сервера. https://serverfault.com/questions/19717/load-balanced-iis-servers-with-asp-net-inproc-session

person Community    schedule 13.10.2009
comment
балансировщик нагрузки? Как уйти от этой единственной точки отказа? Если балансировщик нагрузки умрет, что тогда? Есть реальный способ избежать этого или нет? - person BobTheBuilder; 13.10.2009
comment
Что касается использования SQL-сервера для управления сеансом, не приведет ли это к проблемам с масштабируемостью? т. е. нужно извлекать пользовательские данные из базы данных при каждом обновлении страницы? - person BobTheBuilder; 13.10.2009
comment
На самом деле я не использовал SQL-сервер для управления, поэтому я не могу говорить о масштабируемости. У меня не было бы только одного LB - у меня было бы минимум 2 и, возможно, целых 5 (2x prod, 2x test, 1x dev) - person ; 13.10.2009
comment
@bobthebuilder-Если бы вы использовали SQLServer, это было бы отличным разделением для разделения на второй сервер базы данных. Где основные данные будут на одном сервере БД, а управление состоянием на другом. - person John MacIntyre; 13.10.2009

arrow_upward
2
arrow_downward

Я опираюсь на свой опыт работы с серверами приложений Java, некоторые из которых имеют очень сложные алгоритмы балансировки.

Разумным общим предположением является то, что "Session Affinity" предпочтительнее балансировки каждого запроса. Если мы распределяем первоначальный запрос для каждого пользователя с некоторым уровнем знаний о рабочей нагрузке (или даже на случайной основе), а население приходит и уходит, мы получаем разумное поведение. Помните, что цель состоит в том, чтобы дать каждому пользователю хороший опыт, а не в конечном итоге с равномерно используемыми серверами!

В случае сбоя сервера мы можем увидеть, как наши запросы перемещаются куда-то, и мы ожидаем, что наш сеанс будет передан. Для этого существует множество способов (сеанс в БД, состояние сеанса передается с помощью высокоскоростного обмена сообщениями...).

person djna    schedule 13.10.2009
comment
Итак, это приводит к вопросам о распространении состояния сеанса, если исходный сервер выйдет из строя или выйдет из строя. Существуют ли какие-либо передовые методы для достижения этого? - person BobTheBuilder; 13.10.2009
comment
+1, отличный (IMO) ответ, у меня было почти то же самое. - person AnthonyWJones; 13.10.2009
comment
@BobTheBuilder: Один из вариантов - не надо, примите это к подбородку и двигайтесь дальше. Серьезно, если важно, чтобы пользователь не потерял то, что мы в противном случае считали бы летучим, в случае сбоя сервера, тогда объект Session не является подходящим местом для этих данных. - person AnthonyWJones; 13.10.2009

arrow_upward
0
arrow_downward

Вероятно, это не тот ответ, который вы ищете, но можете ли вы устранить НЕОБХОДИМОСТЬ для состояния сеанса? Мы сделали все возможное, чтобы закодировать все, что нам может понадобиться между запросами на самой странице. Таким образом, я не беспокоюсь о состоянии всей фермы или проблемах масштабируемости, связанных с необходимостью цепляться за что-то, принадлежащее кому-то, кто может никогда не вернуться.

person n8wrl    schedule 13.10.2009
comment
Мы тоже думали об этом и, возможно, действительно пойдем по этому пути, так что я не хочу это слышать. Просто я пока не готов принять такое решение. Я хотел, чтобы все варианты были на столе, чтобы я мог принять обоснованное решение. Я подумал, что это также будет полезно для других разработчиков. - person BobTheBuilder; 13.10.2009

arrow_upward
0
arrow_downward

Хотя вы можете использовать «липкие» сеансы в балансировщике нагрузки, более оптимальным путем является использование сеансом сервера состояний вместо InProc. В этот момент все ваши веб-серверы могут указывать на один и тот же сервер состояния и совместно использовать сеанс.

http://msdn.microsoft.com/en-us/library/ms972429.aspx В MSDN есть что сказать по этому поводу :D

ОБНОВИТЬ:

State Server — это служба на ваших серверах Windows, но да, она создает единую точку отказа.

Кроме того, вы можете указать сериализацию сеанса на SQL Server, что не будет единой точкой отказа, если вы его обработаете.

Я не уверен, насколько «тяжелой» является рабочая нагрузка для сервера состояний, есть ли у кого-нибудь еще какие-либо показатели?

person JustLoren    schedule 13.10.2009
comment
Не приведет ли наличие единого сервера состояния не только к единой точке отказа, но и к тому, что он также будет работать для каждого запроса страницы на всех ваших серверах? Как вы обходите эту проблему? - person BobTheBuilder; 13.10.2009