Масштабирование приложения ASP.NET

Question

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

1) Масштабирование ASP.NET и веб-компонента на пять серверов.

2) Переместить базу данных на ферму.

Не думаю, что у меня возникнут проблемы с базой данных, поскольку это касается только одного IP-адреса. Тем не менее, я сейчас обеспокоен по поводу ASP.NET и веб-уровня. Некоторые проблемы, о которых я уже беспокоюсь:

• Является ли самая простая модель для реализации просто балансировщика нагрузки, который будет обрабатывать запросы к каждому из пяти серверов в циклическом режиме?

• Есть ли проблемы с соединениями HTTPS и SSL, теперь, когда они могут завершаться на разных физических серверах каждый раз, когда делается запрос? (например, производительность?)

• Есть ли какие-либо опасения в отношении обслуживания сеанса (входа в систему) с помощью файлов cookie? Я думаю, нет, но не могу объяснить, почему ...; -)

• Есть ли какие-либо проблемы с самими данными сеанса (на стороне сервера)? Очевидно, мне нужно будет реплицировать состояние сеанса между серверами или каким-либо образом заставить запрос идти только на один сервер. В любом случае, я вижу здесь проблему ...

Answer 1

Как отмечает Дэвид, большая часть этого вопроса на самом деле носит административный характер и может быть полезна для ServerFault. Ссылка, которую он публикует, содержит полезную информацию.

Для ваших Session вопросов: вам может понадобиться либо служба состояния сеанса (поставляется с IIS как отдельная служба, которая поддерживает общее состояние между несколькими серверами), и / или сохранение состояния сеанса asp.net в База данных SQL. Оба варианта вы можете найти по ссылке Дэвида Страттона, я уверен.

Вообще говоря, после настройки состояния сеанса вне процесса оно становится прозрачным. Тем не менее, требуется, чтобы вы сохранили Serializable объектов в сеансе.

---

Round-Robin DNS - самый простой способ балансировки нагрузки в этой ситуации, да. Он не учитывает фактическую нагрузку на каждый сервер, а также не предусматривает каких-либо условий, когда один сервер может быть недоступен для обслуживания; любой, кто получит этот конкретный IP-адрес, увидит, что сайт «выключен», хотя могут работать четыре других сервера.

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

---

Файлы cookie не будут проблемой при условии, что все веб-серверы рекламируют себя как один и тот же веб-сайт (через заголовки узлов и т. Д.). Каждый сервер с радостью примет файлы cookie, установленные любым другим сервером, использующим то же доменное имя, не зная и не заботясь о том, какой сервер их отправил; Он основан на имени хоста сервера, к которому подключается веб-браузер, когда получает значение cookie.

Answer 2

Это довольно широкий вопрос, на который трудно ответить полностью на таком форуме, как этот. Я даже не уверен, принадлежит ли вопрос здесь, или это должно быть на serverfault.com. Однако ....

Microsoft предлагает множество рекомендаций по этому вопросу. Первый результат «масштабирования приложений asp.net» от BING подходит к этому.

http://msdn.microsoft.com/en-us/magazine/cc500561.aspx

Answer 3

Я просто хочу затронуть области, о которых вы должны заботиться о базе данных.

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

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

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

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

Если вы специально построили модель данных с учетом роли нескольких мастеров, тогда, пожалуйста, игнорируйте.;)

Относительно сессий: не доверяйте "липким" сессиям, липкая не является гарантией.Честно говоря, наши вещи обычно развертываются на фермах серверов, поэтому мы полностью отключаем состояние сеанса с самого начала.После перемещения в ферму практически нет причин использовать состояние сеанса, поскольку данные должны быть получены с сервера состояний, десериализованы, сериализованы и сохранены на сервере состояний при каждой загрузке страницы.

Если учесть, что БД и сетевой трафик просто так и что их целью было уменьшить дБ и сетевой трафик, тогда вы поймете, как они вам больше ничего не покупают.

Answer 4

База данных сеансов на сервере SQL может быть легко масштабирована с небольшими изменениями кода и конфигурации.Вы можете привязать сеансы asp.net к базе данных сеансов, и независимо от того, какой веб-сервер в вашей ферме обслуживает запрос, ваше сопоставление сервера состояний sql на основе идентификатора сеанса работает безупречно.Это, вероятно, один из лучших способов масштабирования состояния сеанса ASP.NET с использованием сервера SQL.Для получения дополнительной информации прочитайте ссылку Модель истинного масштабирования для состояния сеанса

Answer 5

Я видел некоторые проблемы, связанные с сеансами http / https циклического перебора. Мы привыкли использовать в сессиях процесса и сказали балансировщикам нагрузки сделать сессии слипшимися. (Я думаю, что они используют куки для этого).

Это позволило нам избежать сеансов SQL, но означало, что когда мы переключались с http на https, наши блоки F5 не могли сохранять липкость. В итоге мы перешли на сеансы SQL.

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