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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

1/Каждый из четырех серверов имеет свою собственную копию данных.

2/В спокойное время приведите два сервера в автономном режиме (т.е. измените балансировщик HA, чтобы удалить их).

3/Обновите два автономных сервера.

4/Измените балансировщик HA, чтобы начать использовать два новых сервера, а не два старых сервера.

5/Проверьте, чтобы обеспечить правильность.

6/Обновите два других сервера, затем принесите их в сеть.

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

У нас было бы восемь серверов (в то время у нас было больше денег, чем вы могли бы вытащить палку). Когда придет время перехода, четыре автономных сервера будут настроены с новыми данными.

Затем балансировка HA будет изменена, чтобы использовать четыре новых сервера и прекратить использование старых серверов. Это сделало переход (и, что более важно, переключением, если мы наполнили) очень быстрый и безболезненный процесс.

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

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

Ответ 7

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

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

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

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

привет!

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

Ответ 13

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