Как создать веб-ферму ASP.NET?

Question

Я ищу информацию о том, как создать веб-ферму ASP.NET - то есть, как заставить приложение ASP.NET (изначально предназначенное для работы на одном веб-сервере) работать на 2 3, 10 и др. Серверов?

Мы создали веб-приложение, которое прекрасно работает, когда, скажем, 500 пользователей одновременно. Но теперь нам нужно, чтобы он работал на 10 000 пользователей (одновременно работая с веб-приложением).

Итак, нам нужно настроить 20 веб-серверов и сделать так, чтобы 10 000 пользователей могли работать с веб-приложением, введя "www.MyWebApp.ru" в своих веб-браузерах, хотя их запросы будут обрабатываться 20 веб-серверами, не подозревая об этом.

1) Существует ли специальное стандартное программное обеспечение для создания веб-фермы ASP.NET ?

2) Или мы должны сами создать веб-ферму , передавая запросы между различными веб-серверами вручную (используя ASP.NET / C #)?

Я нашел очень мало информации о веб-фермах ASP.NET и масштабируемости в сети: в большинстве случаев в статьях о масштабируемости рассказывается, как оптимизировать приложение ASP.NET и заставить его работать быстрее. Но я не нашел ни одного примера «Hello world» -подобного веб-приложения ASP.NET , работающего на 2 веб-серверах .

Было бы замечательно, если бы кто-то мог опубликовать ссылку на статью или, лучше, рассказать о своем собственном опыте в ASP.NET "веб-фермерстве" и решении проблем масштабируемости.

Спасибо, Михаил.

Answer 1

1) Существует ли специальное стандартное программное обеспечение для создания веб-фермы ASP.NET?

Нет.

2) Или мы должны создать вебобрабатывать себя вручную, передавая запросы между различными веб-серверами вручную (используя ASP.NET / C #)?

Нет.

Для создания веб-фермы вам потребуется некоторая форма загрузкибалансировка.Для до 8 серверов или около того вы можете использовать балансировку сетевой нагрузки (NLB), встроенную в Windows.Для более чем 8 серверов следует использовать аппаратный балансировщик нагрузки.

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

1. Управление состоянием (куки, ViewState, состояние сеанса и т.д.)* Загрузка базы данных (управление обходами, разбиением, дисковой подсистемой и т. Д.)
2. Управление пулом приложений (WSRM, сброс пула, разбиение)
3. Развертывание
4. Мониторинг

Если это будет полезно, я расскажу о многих из этих проблем в своей книге: Сверхбыстрый ASP.NET: создание сверхбыстрых и масштабируемых веб-сайтов с использованием ASP.NET и SQL Server..

Answer 2

Я бы сказал, что вам следует настроить кластер NLB (Network Load Balancing), который в основном разделяет все запросы между узлами кластера (и, как дополнительное преимущество, обнаруживает, что что-то не так, и прекращает отправлять им запросы). Для этого в Windows есть функции, но они не сравнимы с аппаратным устройством по производительности и масштабируемости. Если вы используете Windows 2008, его действительно легко настроить. Если вы сделаете это, убедитесь, что у вас есть общий машинный ключ , или вы начнете получать исключения из-за того, что viewstate является недействительным (когда 1 сервер отправляет форму и отправляет сообщение другому, и они используют разные ключи для закодировать данные).

Вы также можете использовать циклический перебор DNS, но на 20 серверах, предположительно в 1 центре обработки данных, я не вижу смысла идти на такие сумасшедшие отрезки времени. Если у вас есть несколько центров обработки данных, хотя это определенно стоит рассмотреть (поскольку NLB не очень хорошо работает между центрами обработки данных).

Вы также захотите убедиться, что пользователь меняет серверы, которые не теряют сеанс. Простейшим способом будет использование базы данных состояния сеанса (настраивается в web.config, или вы можете сделать это для всего сервера в конфигурациях IIS). Если вы не используете сессии, просто отключите их в директиве Pages файла web.config и называйте это днем. Вы также можете использовать сервер состояний сеанса, но у меня нет никакого опыта с этим.

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

Надеюсь, это поможет.

Answer 3

Если вы сохраняете свой сервер без сохранения состояния, это легко с хорошим маршрутизатором, который реализует некоторый протокол Round-Robbin (который отправляет каждый вызов на один опубликованный ip-сервер на другой веб-сервер).

если он не без сохранения состояния (например, если требуется вход в систему или ssl), то вам нужно хранить каждый сеанс на одном и том же сервере.

Вот некоторая информация о маршрутизации запросов приложений MS - там вы получите все:

Балансировка нагрузки IIS

Answer 4

Я бы не рекомендовал # 2. Вы добьетесь большего успеха с балансировщиком нагрузки.

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

Также проверьте использование в вашем коде переменных Application и Cache. Они будут разными на каждом веб-сервере. Если эти значения являются статическими, у вас может не быть проблем. Но если они могут измениться, вы можете получить разные значения на каждом веб-сервере.

Раньше была проблема с ViewState в 1.x, , как объяснено здесь . Я не уверен, что эта проблема все еще существует.

Затем необходимо внести некоторые изменения в ключ машины в web.config, как объяснено здесь .