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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С уважением!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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