Состояние сеанса в сценарии с балансировкой сетевой нагрузки

Question

В настоящее время мы настроили текущий сервер для сайта:

• Сервер 1: Система администрирования и база данных
• Сервер 2: Открытый сайт
• Сервер 3: общедоступный сайт

Сервер 2 и 3 управляется с помощью системы балансировки сетевой нагрузки Windows.Они оба являются работающими копиями общедоступного кода сайта.

Сайты сильно зависят от сессий, потому что они работают с логинами пользователей, мой вопрос таков:

Как мне сохранить состояние между серверами?

Файл web.config для общедоступных сайтов в настоящее время выглядит следующим образом:

<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=localhost:42424"/>

Конечно, это всего лишь случай смены «localhost» на IP, где я хочу сохранить сеанс?Я подумываю об использовании сервера базы данных для хранения сессии, так что это выглядело бы так:

<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=databaseserverIP:42424"/>

Было бы разумно?

Я нашел много противоречивой документации посубъект и был бы признателен всем, кто расскажет о том, как они это делали до того, как / сделают это.

Также (пока я здесь!) система администратора позволяет загружать изображения для статей.Я думал о настройке виртуального каталога на серверах 2 и 3, что указывало бы на сопоставление общего сетевого ресурса с каталогом загрузки на сайте администратора. Есть ли причина, по которой это будет вызывать недовольство?

Извинениядля моего невежества, это неизведанная территория для меня!

Спасибо, Шон

Answer 1

Зависит от того, какую службу состояний вы хотите.

Обычно в сценарии с балансировкой нагрузки вы выбираете сеанс SQL Server или службу состояний ASP.NET.

У каждого есть свои плюсы / минусы (сеанс SQL Server требует сериализации / десериализации, но поддерживает состояние в случае сбоя сервера, состояние ASP.NET не поддерживает состояние в случае сбоя сервера, но происходит намного быстрее из-за отсутствиясериализация / десериализация).

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

Обсуждение этих двух вопросов требует дальнейшего изучения вашегочасть - поскольку вы в первую очередь заботитесь о доступности или скорости.

Имейте в виду, что если вы хотите разделить сеанс между веб-серверами (т.е. веб-фермой), вам необходимо обновить настройки machineKey для каждого сервера, чтобыбыть идентичным.

Вот хорошая статья о состоянии сеанса ASP.NET (и о проблеме machineKey, о которой я упоминал).

Answer 2

Вы должны использовать базу данных SQL для хранения сеанса. Установите mode = "SqlServer" и запустите aspnet_regsql, чтобы добавить таблицы сеансов в вашу базу данных.

Кроме того, вам необходимо убедиться, что любые объекты, хранящиеся в сеансе, помечены как [Сериализуемые]

Answer 3

Другой подход, который следует учитывать, - это «липкие» сессии.

Здесь вы настраиваете свои балансировщики нагрузки, чтобы всегда направлять данный «сеанс» в один и тот же блок. Большинство, если не все, коммерческие балансировщики нагрузки поддерживают это. В основном они вставляют свой собственный cookie-файл сеанса или заголовок http, который используется для идентификации данного пользовательского сеанса. Этот сеанс всегда будет перенаправлен на один и тот же ящик (если он не завершится).

Преимуществом этого подхода является то, что вы можете продолжать использовать простое состояние сеанса, что упрощает настройку и настройку сервера.

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

Answer 4

Если вам нужна доступность (т. Е. Сеансы доступны на любом сервере независимо от сбоя сервера), то путь SQL - это путь, но вы также можете взглянуть на ScaleOut SessionServer (http://www.scaleoutsoftware.com/pages/products/scaleout-sessionserver.php)

Cheers

Кошка