Gotchas: Обновление с отдельных серверов на веб-фермы

Question

В нашей компании в настоящее время работают два сервера Windows 2003 (веб-сервер & сервер базы данных MSSQL 8). Мы планируем добавить еще пару серверов для целей резервирования/доступности в настройке веб-фермы. Наши веб-сайты в основном представляют собой ASP.NET, у нас есть несколько сайтов PHP, но они в основном статичны без БД.

Кто-нибудь, кто прошел через этот процесс, имеет какие-либо проблемы или другие моменты, о которых я должен знать? И будет ли использование Windows Server 2008 дополнительными преимуществами для этой ситуации (так что я могу убедить моего босса обновить :)?

Спасибо.

Answer 1

Если у вас динамическая балансировка нагрузки (то есть мой первый запрос отправляется на сервер X, но мой следующий запрос может перейти на сервер Y или Z), вы обнаружите, что сеансы In-Proc не работают. Таким образом, вам понадобятся липкие сеансы (ваш балансировщик будет ВСЕГДА отправлять мне (= мой сеанс) на сервер X) или внепроцессные сеансы (т. Е. Хранятся на SQL Server).

Answer 2

Как Майкл говорит, вам нужно будет заботиться о своей сессии. Идеально заставляйте его опираться и хранить вне процесса. У вас будет аналогичная проблема с кешем в зависимости от того, как вы его используете, и может быть заинтересована в поиске более надежной технологии кеширования, если вы используете только кэширование asp.

Не забывайте о таких машинных ключах и валидации в вашем web.config. MachineKeys должны быть совместимы с серверами.

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

Веб-ферма может предоставить вам возможности и проблемы с развертыванием, которые не следует упускать из виду.

Без специфического опыта для установки выше, но для общих ходов такого рода. Я бы рекомендовал поэтапный подход. То есть сначала перейдите в Windows 2008, а затем в ферму.

Answer 3

В дополнение к тому, что говорят другие, вы можете рассмотреть глядя на Ричарда Кемпбелла продукт (из .NET Rocks!):

http://www.strangeloopnetworks.com/

Answer 4

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

Например, предположим, что у вас есть четыре узла в вашей ферме. Вы вытаскиваете два из кластера, обновляете и проверяете, а затем заменяете два других, чтобы повторить? Определите, соответствует ли ваш текущий процесс развертывания вашим ответом. Просто потому, что у вас есть X раз количество серверов не означает, что вы хотите или нужно делать в X раз больше работы.

Просто пересматривая часть сообщения о кешировании на мгновение. Вы должны обязательно взглянуть на распределенное кэширование. Если вы предварительно кэшируете данные и используете обратные вызовы с изъятиями кэша, вы можете действительно наложить удар по базе данных, если не будете осторожны. Кроме того, многие распределенные кэширующие решения предлагают некоторый уровень управления состоянием сеанса. Мне очень понравился проект Microsoft Velocity, хотя это всего лишь второй выпуск CTP и не готов к производству.

Answer 5

Мы используем государственный сервер ASP.NET для обработки сеансов. Это бесплатно с сервером Windows 2003/2008.

Затем мы должны убедиться, что машинные клавиши одинаковы (настройка в файлах web.config).

Затем я вручную переношу каждый сайт в автономном режиме (используя app.offline или что-то вроде магического файла). Кроме того, вы можете использовать IIS и просто отключить сайт и отключить автономный сайт.

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

О, мы используем балансировщик нагрузки F5, который НЕ делает липких сеансов, поэтому нам нужно поддерживать наши сеансы. Именно поэтому мы используем государственный сервер ASP.NET.

Answer 6

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