Как сбалансировать нагрузку SQL Server 2008 для приложений ASP.NET с высокой нагрузкой?


12

Представьте, что у вас есть успешное веб-приложение, которое использует ASP.NET и IIS 7. Оно генерирует много обращений к базе данных SQL Server 2008 и, как ожидается, будет общедоступным с временем работы 99,9% (время простоя 8 часов, 45 минут на год).

Наши цели:

  • Установите обновления Windows на сервер, не вызывая простоев у наших клиентов
  • Предотвращение сбоев оборудования на сервере от замедления приложений ASP.NET из-за тайм-аутов

В отличие от балансировки нагрузки приложения ASP.NET, балансировка нагрузки SQL кажется гораздо более сложной задачей. Каковы ваши рекомендации по настройке простого кластера SQL Server 2008 R2 с балансировкой нагрузки для микро-ISV, использующего стек Microsoft?


Несколько замечаний: мы написали приложения ASP.NET, которые могут работать в автономном режиме без подключения к базе данных, когда время ожидания истекло. Он превращается в «базовый» сервис вместо полнофункционального приложения. Я также читал о вдохновляющем подходе Netflix Chaos Monkey: readwriteweb.com/cloud/2010/12/…

Каковы ваши обстоятельства? Вы находитесь в размещенной среде с ограниченными серверами или размещаете свои собственные вещи с доступом к наличным деньгам и возможностью расширить свои номера серверов?

@Jay: Как и многие микро-ISV, у нас есть два выделенных сервера, которые переводятся на хостинг Rackspace Cloud. Мы могли бы позволить себе два выделенных блока SQL Server, если бы нам это понадобилось, но мне интересно, есть ли лучший подход.

Переместите свою базу данных в SQL Azure. После этого вы освобождаетесь от ночных кошмаров сбоев серверов, закупок и обновлений. Ваши данные дублируются дважды в дополнение к вашей рабочей копии, и аспект балансировки нагрузки также обрабатывается для вас за долю реальной стоимости внедрения / управления SQL Server, например, аппаратное обеспечение, лицензирование программного обеспечения, время поддержки сервера и т. Д. И т. Д. И т. Д. И т. Д. .
Бретт Rigby

Ответы:


4

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

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

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

Больше чтения:

Ознакомьтесь с книгами Аллана Хирта об Apress, посвященных высокой доступности SQL Server 2005 и репликации Pro SQL Server 2005/2008 от Apress.

Масштабируемые общие базы данных: http://technet.microsoft.com/en-us/library/ms345392.aspx


2

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

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


0

Хорошо, поехали. НЕ МОЖЕТ БЫТЬ СДЕЛАНО. Не без изменений приложения.

  • Установите обновления - используйте кластеризацию или зеркалирование, чтобы убедиться, что у вас есть две базы данных, которые работают или могут переключиться на другой компьютер быстрее. Зеркальное отображение сильно предпочтено.
  • Перепишите приложение, чтобы справиться с этим (т. Е. Сбой соединения, необходимо прозрачное переподключение, чтобы затем подключиться к копии).

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


0

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


-1

Позвольте мне дать вам юрский ответ. Если ваши цели включают в себя «установку обновлений Windows», вы не спасетесь.

У меня седая борода, и я могу вспомнить время, когда приложение могло работать 10 лет без необходимости «обновлений операционной системы». Срок полезного использования приложения измерялся десятилетиями, а не годами.

Поэтому мой совет: установите рабочую версию базы данных и приложения SQL Server и изолируйте сервер базы данных от обновлений MICROSOFT. Если это не сломано, не исправляйте это.

Используйте горячую замену дисков RAID.

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


3
Тим, это все равно, что говорить, зачем даже использовать базу данных, когда можно хранить результаты в файле Excel? В ОС существует множество уязвимостей, и не рекомендуется регулярно устанавливать обновления / не обновлять антивирусные программы / правила брандмауэра. Не рекомендуется на любом уровне.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.