Рекомендации по архитектуре для сайта ASP.NET с балансировкой нагрузки

Question

ОБНОВЛЕНИЕ 2009-05-21

Я тестировал метод №2 по использованию одного сетевого ресурса. Это приводит к некоторым проблемам с Windows Server 2003 под нагрузкой:

http://support.microsoft.com/kb/810886

конец обновления

Я получил предложение для веб-сайта ASP.NET, которое работает следующим образом:

Аппаратный балансировщик нагрузки -> 4 веб-сервера IIS6 -> БД SQL Server с отказоустойчивым кластером

Вот в чем проблема ...

Мы выбираем, где хранить веб-файлы (aspx, html, css, изображения). Было предложено два варианта:

1) Создайте идентичные копии веб-файлов на каждом из 4 серверов IIS.

2) Поместите одну копию веб-файлов в общую сетевую папку, доступную для 4 веб-серверов. Корневые узлы на 4 серверах IIS будут сопоставлены с одним общим сетевым ресурсом.

Какое решение лучше? Вариант 2, очевидно, проще для развертываний, поскольку он требует копирования файлов только в одно место. Однако мне интересно, возникнут ли проблемы с масштабируемостью, поскольку все четыре веб-сервера имеют доступ к одному набору файлов. Будет ли IIS кэшировать эти файлы локально? Будет ли это попадать в сетевую папку при каждом запросе клиента? Кроме того, доступ к общему сетевому ресурсу всегда будет медленнее, чем получение файла на локальном жестком диске? Увеличивается ли нагрузка на сетевой ресурс при добавлении большего количества серверов IIS?

Чтобы дать перспективу, это для веб-сайта, который в настоящее время получает ~ 20 миллионов посещений в месяц. На недавнем пике он получал около 200 обращений в секунду.

Пожалуйста, дайте мне знать, если у вас есть определенный опыт с такой установкой. Спасибо за ввод.

ОБНОВЛЕНИЕ 2009-03-05

Чтобы прояснить мою ситуацию - «развертывания» в этой системе происходят гораздо чаще, чем обычное веб-приложение. Веб-сайт является интерфейсом для CMS бэк-офиса. Каждый раз, когда контент публикуется в CMS, новые страницы (aspx, html и т. Д.) Автоматически помещаются на действующий сайт. Развертывания в основном "по требованию". Теоретически этот толчок может произойти несколько раз в течение минуты или более. Поэтому я не уверен, что было бы целесообразно развертывать один веб-сервер одновременно. Мысли?

Answer 1

Я бы разделил нагрузку между 4 серверами. Это не так много.

Вы не хотите ни единой точки раздора ни при развертывании, ни той единственной точки отказа в производстве.

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

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

Answer 2

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

Развертывание ваших веб-ресурсов в любом случае автоматизировано (верно?), Поэтому делать это несколькими способами не составляет большого неудобства.

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

Answer 3

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

Answer 4

В идеальной ситуации высокой доступности не должно быть единой точки отказа.

Это означает, что одно поле с веб-страницами на нем - нет-нет. Проделав работу HA для крупного телекоммуникационного оператора, я первоначально предложил бы следующее:

• Каждый из четырех серверов имеет свою собственную копию данных.
• В спокойное время переведите два сервера в автономный режим (т. Е. Измените балансировщик высокой доступности, чтобы удалить их).
• Обновление двух автономных серверов.
• Измените балансировщик высокой доступности, чтобы начать использовать два новых сервера, а не два старых сервера.
• Проверьте это, чтобы убедиться в правильности.
• Обновите два других сервера и подключите их.

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

• У нас было бы восемь серверов (в то время у нас было больше денег, чем можно было бы ткнуть). Когда придет время для перехода, четыре автономных сервера будут настроены с новыми данными.
• Тогда балансировщик высокой доступности будет модифицирован для использования четырех новых серверов и прекращения использования старых серверов. Это сделало переключение (и, что более важно, переключение обратно, если мы его запутали) очень быстрым и безболезненным процессом.
• Только когда новые серверы будут работать какое-то время, мы рассмотрим следующее переключение. До этого момента четыре старых сервера оставались в автономном режиме, но на всякий случай были готовы.
• Чтобы получить тот же эффект с меньшими финансовыми затратами, у вас могут быть дополнительные диски, а не целые дополнительные серверы. Восстановление не будет таким быстрым, поскольку вам придется выключить сервер, чтобы вернуть старый диск, но оно все равно будет быстрее, чем операция восстановления.

Answer 5

В IIS6 и 7 явно поддерживается сценарий использования единого сетевого ресурса на N подключенных машинах веб-серверов / серверов приложений. MS провела множество тестов, чтобы убедиться, что этот сценарий работает хорошо. Да, кеширование используется. С сервером с двумя сетевыми картами, один для общедоступного Интернета и один для частной сети, вы получите действительно хорошую производительность. Развертывание пуленепробиваемое.

Стоит потратить время на его тестирование.

Вы также можете оценить поставщика виртуальных путей ASP.NET, который позволил бы вам развернуть один ZIP-файл для всего приложения. Или, используя CMS, вы могли бы обслуживать контент прямо из базы данных контента, а не из файловой системы. Это представляет некоторые действительно хорошие варианты для управления версиями.

VPP Для ZIP через # ZipLib .

VPP для ZIP через DotNetZip .

Answer 6

Я отвечал за разработку игрового сайта, который посещал 60 миллионов человек в месяц. То, как мы это сделали, было вариантом № 1. Пользователь имел возможность загружать изображения и тому подобное, и они были помещены на NAS, который был разделен между серверами. Это сработало довольно хорошо. Я предполагаю, что вы также делаете кэширование страниц и так далее, на стороне приложения дома. Я бы также развернул по требованию новые страницы на всех серверах одновременно.

Answer 7

Мы очень рады использовать 4 веб-сервера, каждый с локальной копией страниц, и SQL Server с отказоустойчивым кластером.

Answer 8

Предполагая, что ваши серверы IIS работают под управлением Windows Server 2003 R2 или выше, обязательно посмотрите DFS Replication . Каждый сервер имеет свою собственную копию файлов, которая устраняет узкое место в общей сети, как многие другие предупреждали. Развертывание так же просто, как копирование ваших изменений на любой из серверов в группе репликации (при условии топологии полной сетки). Репликация позаботится об остальном автоматически, в том числе с помощью удаленного дифференциального сжатия, чтобы отправлять только дельты файлов, которые были изменены.

Answer 9

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

С помощью Mesh вы загружаете небольшую Службу Windows на каждую машину Windows, которую вы хотите в своей Mesh, и затем назначаете папки в вашей системе, которые являются частью сетки. Когда вы копируете файл в папку Live Mesh, что является точно такой же операцией, что и копирование на любой другой загрузчик в вашей системе, служба заботится о синхронизации этого файла со всеми другими участвующими устройствами.

В качестве примера я храню все исходные файлы кода в папке Mesh и синхронизирую их между работой и домом. Мне не нужно ничего делать, чтобы синхронизировать действия по сохранению файла в VS.Net, блокноте или любом другом приложении, которое запускает обновление.

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

Answer 10

Очень простой метод развертывания на нескольких серверах (после правильной настройки узлов) - это использование robocopy.

Предпочтительно, чтобы у вас был небольшой промежуточный сервер для тестирования, а затем вы «делали копии» на всех серверах развертывания (вместо использования общей сетевой папки).

robocopy включен в MS ResourceKit - используйте его с ключом / MIR.