Представьте, что у вас есть успешное веб-приложение, использующее ASP.NET и IIS 7. Оно генерирует множество обращений к базе данных SQL Server 2008 и, как ожидается, станет общедоступным с временем безотказной работы 99,9% (время простоя 8 часов, 45 минут на год).
Наши цели:
В отличие от балансировки нагрузки приложения ASP.NET, балансировка нагрузки SQL кажется намного более сложной. Каковы ваши рекомендации по настройке простого кластера SQL Server 2008 R2 с балансировкой нагрузки для Micro-ISV, использующего стек Microsoft?
Если вам нужна высокая доступность, то решения для кластеризации 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
Системы реляционных баз данных редко подвергаются балансировке нагрузки так же, как веб-серверы. Проблема с классическим подходом к балансировке нагрузки заключается в том, что все ваши базы данных должны находиться в постоянной синхронизации. Реляционная модель бесполезна, если два сервера не имеют одинакового состояния в любой момент времени.
Судя по вашему вопросу, не похоже, что вы даже пытаетесь выполнить балансировку нагрузки, которая в первую очередь является мерой производительности, чтобы гарантировать, что только столько пользователей попадает на каждый сервер, сколько этот сервер может обработать. Похоже, вы хотите кайфа доступность настроить. Поскольку вы говорите, что используете SQL Server, я бы посмотрел на отказоустойчивость. Это означает, что если первичная база данных недоступна, клиенты будут пытаться получить доступ к серверам аварийного переключения. SQL Server обрабатывает синхронизацию основного экземпляра и каждого аварийного переключения, а также выполняет повторную синхронизацию основного экземпляра с аварийным переключением, когда основной возвращается в оперативный режим из автономного режима.
Рентабельный ответ здесь довольно часто заключается в том, чтобы буферизовать базу данных с помощью недорогих стандартных служб хостинга сбалансированного серверного уровня, которые обеспечивают логическую обработку и хранение данных, которые в противном случае ограничили бы ресурсы базы данных. Очевидно, это требует некоторого размышления о нестабильности данных и стратегиях кэширования.
Хорошо, поехали. НЕВОЗМОЖНО СДЕЛАТЬ. Не обошлось и без изменений в приложении.
Поймите, что вам все равно нужно отключить приложение для обслуживания при развертывании новой копии / внесении изменений в схему БД.
Позвольте дать вам юрский ответ. Если в ваши цели входит «установить обновления Windows», вам уже не спасать.
У меня седина в бороде, и я могу вспомнить время, когда приложение могло работать 10 лет без «обновлений операционной системы». Срок службы приложения измеряется десятилетиями, а не годами.
Итак, мой совет: установите рабочую версию вашей базы данных + приложения SQL Server и ИЗОЛИРУЙТЕ СЕРВЕР БАЗЫ ДАННЫХ ОТ ОБНОВЛЕНИЙ MICROSOFT. Если он не сломан, не чините его.
Используйте диски RAID с возможностью горячей замены.
Имейте под рукой сервер базы данных зеркального отображения (по совету TomTom) на случай, если ваше оборудование сломается.