Назад | Перейти на главную страницу

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

У нас есть приложение, которое мы разработали на ASP и SQL Server. Мы используем Rackspace для его размещения. У каждого из наших «клиентов» есть собственный сайт IIS и база данных SQL. У каждого клиента может быть дюжина или несколько сотен пользователей, обращающихся к приложению.

Сейчас у нас несколько сотен клиентов. До сих пор мы добавляли еще одну пару серверов (один IIS, один SQL), когда это необходимо по соображениям производительности. Сейчас у нас до четырех пар серверов.

Мы продолжаем привлекать новых клиентов и ищем альтернативные способы масштабирования без простого добавления пар серверов.

Один из подходов, который мы рассматриваем, - это наличие веб-фермы для стороны IIS и кластера SQL Server и SAN для стороны базы данных.

Это хороший подход? Сейчас у нас около 400 клиентов, каждый со своим сайтом IIS и базой данных SQL. Что, если мы вырастем до 1000? 5000? Может ли один кластер SQL обрабатывать многие тысячи баз данных?

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

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

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

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

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

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

Действительно, масштабирование и кластеризация предлагают решение высокой доступности. Существует два основных решения высокой доступности для 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 тысяч клиентов, что даст вам запас в 3 запроса на клиента в секунду, и для достижения этого вам понадобится довольно мощное оборудование и исключительно хорошо настроенное приложение.

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

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

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

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

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

4) следующая веб-конфигурация

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

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

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

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

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

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

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