При переходе с одного сервера на веб-фермы, каковы наилучшие методы решения проблем с подключением к БД, файлов журналов и других проблем.
Я отмечаю, что оба ответа до сих пор не указали явно настройка MachineKey.
Это смехотворно важно в сценарии фермы, где запросы могут быть отправлены на любой сервер - без этого запросы, отправленные на другой сервер, будут вызывать исключения, если не удается расшифровать состояние просмотра страницы и любые зашифрованные токены сеанса.
Также обратите внимание, что при переходе из состояния сеанса InProc могут возникнуть другие проблемы, если вы полагаетесь на такие события, как SessionEnd в global.asax - это не сработает, если вы не используете сеансы InProc.
Еще одна вещь, которую следует учитывать, - это создание единой учетной записи для приложений, под которой будут запускаться, вместо учетной записи по умолчанию IUsr_MachineName - упрощает управление соединениями с БД (например, в SQL требуется только одна учетная запись) и исключает ошибки типа "неправильный вход" везде .
Вот несколько вещей, на которые следует обратить внимание при переходе на веб-ферму:
Тем не менее, это большая тема, и на самом деле это лишь верхушка айсберга. Если это может быть полезно, я напишу подробнее в своей книге: Сверхбыстрый ASP.NET.
Одна из серьезных проблем, о которых стоит беспокоиться, - это сеансы без сохранения состояния и с сохранением состояния.
Если у вас нет состояния, то уровень кластеризации может направить HTTP-запрос на любой из ваших серверов. Необходимо учитывать другое состояние сеанса, чтобы направить второй, третий и т. Д. Запросы обратно на тот же сервер. Таким образом, вы можете закончить рефакторинг битов своего кода, чтобы в конечном итоге он остался без состояния. например Пока пользователь просматривает таблицу, текущий курсор можно сохранить в скрытой переменной страницы браузера, чтобы отправить обратно в «ферму» для следующей или предыдущей страницы.
Соединения с БД обычно управляются событиями. Каждый сервер «фермы» получает запрос http / ajax, подключается к БД, получает данные, отключается. Только при интенсивном трафике может быть кэшировано соединение с БД, но для управления этим необходимо написать больше кода, чтобы пойти не так.
Лог-файлы. Каждый сервер «фермы» должен сбрасывать свои собственные файлы журнала себе, поскольку центральный сервер в кластере - плохая идея, поскольку если он не работает, то дополнительный код должен принимать решения. Ваш пакет просмотра журнала может опрашивать все серверы «фермы» на предмет данных журнала в диапазонах дат и времени.
Мои 64 цента (инфляция) стоят