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

Question

UPDATE 2009-05-21

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

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

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

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

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

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

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

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

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

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

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

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

UPDATE 2009-03-05

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

Answer 1

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

Вы не хотите, чтобы эта точка разглашения была либо при развертывании, ни в этой единственной точке отказа в производстве.

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

Что вы получаете на NLB с помощью 4IIS, вы теряете его с BottleNeck с сервером приложений.

Для обеспечения масштабируемости я рекомендую приложения на веб-серверах с интерфейсом.

Здесь, в моей компании, мы реализуем это решение. Приложение .NET в начале и сервер APP для Sharepoint + кластер SQL 2008.

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

привет!

Answer 5

Используйте инструмент развертывания с процессом, который развертывает по одному, а остальная часть системы продолжает работать (как сказал Муфака). Это проверенный процесс, который будет работать как с файлами содержимого, так и с любым скомпилированным фрагментом приложения (который развертывает вызывает переработку процесса asp.net).

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

Обновление: О вопросах в комментарии. Это настраиваемое решение, основанное на моем опыте с тяжелыми/длительными процессами, которые требуют контроля скорости обновления. У меня не было необходимости использовать этот подход для сценариев развертывания, так как для такого динамического контента я обычно использую комбинацию БД и кеша на разных уровнях.

Очередь не должна содержать полную информацию, она просто должна иметь соответствующую информацию (ids/paths), которая позволит вашему процессу передавать информацию, чтобы начать процесс публикации с помощью внешнего инструмента. Поскольку это настраиваемый код, вы можете присоединиться к опубликованной информации, поэтому вам не придется иметь дело с этим в процессе публикации/инструменте.

Изменения в БД будут выполняться во время процесса публикации, вам просто нужно знать, где находится информация о необходимых изменениях, и пусть процесс публикации/инструмент обрабатывает ее. Что касается того, что нужно использовать для очереди, то основными из них я использую msmq и пользовательскую реализацию с информацией на сервере sql. Очередь находится там, чтобы контролировать скорость обновлений, поэтому вам не нужны что-либо специально предназначенное для развертывания.

Обновление 2: убедитесь, что ваши изменения в БД обратно совместимы. Это действительно важно, когда вы нажимаете изменения в реальном времени на разные серверы.

Answer 6

У нас схожая ситуация с вами, и наше решение заключается в использовании модели издателя/подписчика. Наше приложение CMS хранит фактические файлы в базе данных и уведомляет службу публикации, когда файл был создан или обновлен. Затем этот издатель уведомляет все подписные веб-приложения, а затем отправляется и получает файл из базы данных и помещает его в свои файловые системы.

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

Вы можете использовать UNC для хранения, мы выбрали БД для удобства и переносимости между производственными и тестовыми средами (мы просто копируем базу данных обратно, и у нас есть все файлы в реальном времени, а также данные).

Answer 7

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

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

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

Answer 8

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

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

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

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

Answer 9

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

Это стоит потратить время, чтобы сравнить его.

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

VPP For ZIP via #ZipLib.

VPP for ZIP via DotNetZip.

Answer 10

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

Answer 11

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

Answer 12

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

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

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

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

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

Answer 13

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