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

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

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

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

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

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

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

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

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

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

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

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

• каждый из четырех серверов имеет собственную копию данных.
• в спокойное время выключите два сервера (т. е. измените балансировщик HA, чтобы удалить их).
• обновление двух офф-лайн сервера.
• измените балансировщик HA, чтобы начать использовать два новых сервера, а не два старых сервера.
• проверьте это, чтобы обеспечить правильность.
• обновите два других сервера, затем включите их в сеть.

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

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

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

Что вы получаете на NLB с 4IIS вы теряете его с узким местом с сервером приложений.

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

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

надеюсь, что это помогает!

с уважением!

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

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

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

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

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

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

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

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

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

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

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

о

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

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