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

Question

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

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

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

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

Answer 1

Некоторые опции:

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

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

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

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

Answer 2

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

http://msdn.microsoft.com/en-us/library/ms972429.aspx MSDN есть много, чтобы сказать по теме: D

UPDATE:

Государственного Сервер сервис на Windows Server коробках, но да, это создает единую точку отказа.

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

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

Answer 3

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

Answer 4

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

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

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