Лучший способ масштабировать приложение IIS/SQL Server

Кластер SQL Server - это не решение для масштабируемости, а решение с высокой доступностью. В кластере SQL Server только один узел активен и обрабатывает нагрузку, все остальные узлы просто пассивны, ожидая, если у активного узла произойдет сбой оборудования. В качестве такого кластера SQL Server вы в лучшем случае получаете производительность одного экземпляра SQL Server. Иногда вы найдете ссылки на так называемое "Active-Active" развертывание, но это не кластер SQL Server. Так называемый "Active-Active" - это два отдельных кластера, которые используют узлы друг друга в противоположных ролях (один кластер активен на узле A и пассивен на B, другой активен B и пассивен на A).

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

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

Обновлено после того, как вы отредактировали ОП с объяснением проблем, связанных с масштабированием.

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

Кластеры серверов Microsoft поддерживаются только в кластерных решениях, которые перечислены в каталоге Windows Server в разделе "Кластерные решения". Чтобы просмотреть каталог Windows Server, посетите следующий веб-сайт Microsoft: http://www.windowsservercatalog.com/

Это не означает, что вы не можете запустить кластер на любой аппаратной паре / группе, которая имеет общую шину SCSI. Это означает, что вы не сможете запросить поддержку у Microsoft CSS, если у вас есть проблема на оборудовании, которая не одобрена.

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

Что касается вопроса о том, сколько баз данных может работать кластер, в конечном счете, кластер может иметь только один активный экземпляр в любой момент, поэтому ограничения для одного экземпляра также применимы к кластеру. Присоединение тысячи баз данных не так уж и важно, реальный вопрос заключается в том, сколько пользователей будет одновременно выполнять запросы. Чтобы получить приблизительную область чисел, учтите, что тесты TPC-C, опубликованные для SQL Server, предназначены для примерно 1,2 млн транзакций в минуту на 64-стороннем Superdome, что означает примерно 16 тыс. Транзакций в секунду. Вы ожидаете около 5 000 подключенных клиентов, что дает вам маржу в 3 запроса на клиента в секунду, и для этого вам понадобится довольно изящное оборудование и исключительно хорошо настроенное приложение.

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

С точки зрения стратегии реального масштаба, я думаю, что возможная установка для вас может выглядеть примерно так:

1) все веб-файлы клиентов находятся на всех веб-серверах

2) все сайты клиентов настроены в IIS на всех серверах

3) изменения любых веб-файлов клиентов синхронизируются со всеми веб-серверами

4) следующий веб-конфиг

          - - - - - - - - - - - - - -
         |      Load Balancer       |
          - - - - - - - - - - - - - -
                        |
                        |
 - - - -    - - - -     - - - -     - - - -
| web |   | web |   | web |   | web |
 - - - -    - - - -     - - - -     - - - -
    |            |             |            |
          - - - - - - - - - - - - - -
         |      SQL Cluster          |
          - - - - - - - - - - - - - -
                      |
                      |
          - - - - - - - - - - - - - -
         |    Warm SQL Cluster    |
          - - - - - - - - - - - - - -

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

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

Кроме того, мы позволяем серверам баз данных делать то, что у них получается лучше всего, и как только они начинают увязать, мы добавляем новый сервер \ кластер в смесь, чтобы сбалансировать работу. Тёплый SQL Server дает вам некоторую степень избыточности, хотя со мной могут быть некоторые разногласия относительно того, действительно ли это будет необходимо.

Недавно появилась статья о Foursquare и о том, как они балансируют свои нагрузки. Они используют подход, при котором они в основном распределяют своих пользователей по разделам, которые в MongoDB являются отдельными серверами. Это работало очень хорошо для них, пока группа пользователей, которые все являются активными пользователями и на одном и том же разделе (осколке), не убрала осколок, заставив его выйти за свои пределы. Конечно, это было немного больше, но суть была в том, чтобы распределять между машинами и отслеживать использование, чтобы вы знали, когда нужно разделить и сбалансировать нагрузку снова.

во всяком случае.... это мои 2 цента.

Возможно, вы захотите рассмотреть облачное решение, такое как Amazon Web Services EC2 и дополнительные базы данных и службы хранения. Это очень легко масштабировать и полностью программируемо. Вы можете создать собственную панель управления для управления всеми своими серверами и масштабировать их по мере необходимости. Вы платите только за то, что используете, и они поддерживают платформы Windows и Linux, включая IIS. Вы можете создавать свои собственные пользовательские образы, если вам нужно масштабировать до нескольких серверов или обеспечить географическую избыточность, размещая серверы на восточном и западном побережье или даже в Европе. У Rackspace есть похожее решение, но я не уверен, что они выпустили поддержку Windows - они могут иметь. Я попробовал оба варианта и обнаружил, что Amazon более гибок и понятен, но, поскольку вы уже используете Rackspace, это может иметь больше смысла. Удачи!