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

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

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

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

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

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

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

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

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

Ответ 1

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

Нет.

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

Нет.

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

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

Управление состоянием (файлы cookie, ViewState, состояние сеанса и т.д.)
Кэширование и кэширование недействительности
Загрузка базы данных (управление обходами, разделение, дисковая подсистема и т.д.)
Управление пулами приложений (WSRM, сброс пула, разделение)
Развертывание
Мониторинг

В случае, если это может быть полезно, я затрагиваю многие из этих проблем в своей книге: Ультра-быстрый ASP.NET: построение Ultra-Fast и Ultra- Масштабируемые веб-сайты с использованием ASP.NET и SQL Server.

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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