Как создать веб-ферму ASP.NET?
Если Вы должны делать этот парсинг, я уверен, что Вы получите много хороших предложений здесь.
Мое предложение - , не делают этого парсинга .
Вместо этого создайте свои поля ввода так, чтобы информация была уже выделена. Имейте отдельные поля для заголовка, имени, средней начальной буквы, фамилии, суффикса, и т.д.
4 ответа
1) Есть ли специальное стандартное программное обеспечение для создания веб-фермы ASP.NET?
Нет.
2) Или мы должны создать веб-ферму сами, передавая запросы между разными веб-серверами вручную (с использованием ASP.NET / C #)?
Нет.
Чтобы построить веб-ферму, вам понадобится какая-то форма балансировки нагрузки. Примерно для 8 серверов вы можете использовать балансировку сетевой нагрузки (NLB), встроенную в Windows. Для более чем 8 серверов вам следует использовать аппаратный балансировщик нагрузки.
Однако балансировка нагрузки на самом деле является лишь верхушкой айсберга. Есть много других проблем, которые вы должны решить, включая такие вещи, как:
- Управление состоянием (файлы cookie, ViewState, состояние сеанса и т. Д.)
- Кэширование и аннулирование кэша
- Загрузка базы данных (управление циклами приема-передачи, разбиение на разделы, диск подсистема и т. д.)
- Управление пулом приложений (WSRM, сброс пула, разбиение на разделы)
- Развертывание
- Мониторинг
Если это может быть полезно, я освещаю многие из этих вопросов в своей книге: Ultra -Fast ASP.NET: создание сверхбыстрых и сверхмасштабируемых веб-сайтов с помощью ASP.
I'd say you should configure an NLB cluster (Network Load Balancing), which basically splits all requests between cluster nodes (And as an added benefit detects if things are down and stops sending them requests). There's features built into windows for this, but they don't compare to a hardware device for performance or scalability. If you're using Windows 2008 it really is simple to set one up. If you do this make sure you have a shared machine key or you'll start getting exceptions for viewstate being invalid (When 1 server submits the form and it posts to the other and they're using different keys to encode the data).
You can also use DNS round-robin but at 20 servers presumably in 1 datacenter I wouldn't see a point to going to such crazy lengths. If you've got multiple data centers though this is definitely worth considering (As NLB won't really work well between data centers).
You'll also want to be sure if a user swaps servers they don't loose their session. The simplest way would be to use a Session State database (Configurable in the web.config, or you can do it server-wide in IIS's configs). If you don't use sessions though just turn them off in the Pages directive of the web.config and call it a day. You could also use a session state server, but I don't have any experience with this.
It may also be worth considering spending some time optimizing the code or adding caching directives to static content - it can be very cost-effective even if you only trim the need for a few of those servers.
Hope that helps.
If you keep your server stateless, it is easy with a good router that implements some round-Robbin protocol (that send each call to the single published server ip to a different web server).
if it is not stateless (like - if a login is required, or ssl) than you need to keep each session to the same server.
Here is some info about MS Application Request Routing - you will get everything there:
Я бы не рекомендовал №2. Вам будет намного лучше с балансировщиком нагрузки.
Обратите внимание на управление состоянием сеанса. Если вы не сконфигурируете балансировщик нагрузки так, чтобы каждый пользователь находился на одном и том же веб-сервере, вам придется использовать сервер состояния сеанса или базу данных.
Кроме того, проверьте использование вашим кодом переменных приложения и кэша. Они будут разными на каждом веб-сервере. Если эти значения статичны, возможно, у вас нет проблем. Но если они могут измениться, вы можете получить разные значения на каждом веб-сервере.
Раньше была проблема с ViewState в 1.x, , как описано здесь . Я не уверен, существует ли эта проблема.
Затем необходимо внести некоторые изменения в машинный ключ в web.config, как описано здесь .