Многоцелевой отказоустойчивый сервер?

Question

Я не администратор баз данных, так что это может быть глупый вопрос, но я все равно задам его. Мы обновляем наши SQL-серверы с 2000 до 2005 года и, вероятно, будем использовать либо репликацию базы данных, либо зеркалирование базы данных. Наш администратор БД хотел бы «многоцелевой» резервный сервер, что означает, что он хотел бы увеличить наши возможности и емкость, запустив другие приложения базы данных на резервном сервере, поскольку «он все равно будет сидеть там» (его слова, а не мои) , Это такая хорошая идея? Прямо сейчас наш основной сервер приложений использует только один экземпляр, который содержит более 50 баз данных. Насколько я понимаю, то, что мы делаем сейчас и что предлагает наш администратор базы данных для отказоустойчивого сервера, является плохой идеей, поскольку все эти базы данных совместно используют память, процессоры и рабочие области. Если одно приложение начинает работать плохо, это может повлиять на другие БД.

Есть мысли?

Answer 1

Это действительно деловой вопрос, на который нужно ответить ?? медленное приложение лучше, чем нет, если вы не можете позволить себе расходовать дополнительное оборудование?

Резервные и зеркальные БД могут использоваться для отчетов. Использование его в качестве отказоустойчивой БД может работать, если у вас достаточно запаса (т. Е. Обе базы данных будут комфортно работать на сервере)

Answer 2

"это все равно будет сидеть там"

Он будет сидеть там, применяя транзакции ...

Обратите внимание на рекомендацию Джона Сэнсома. Помните, что для активного / активного кластера требуются две серверные лицензии sql, а для отказоустойчивого кластера / зеркала - только одна.

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

Answer 3

Зеркальное отображение базы данных не будет таким подходом, как мне кажется, поскольку оно обеспечивает избыточность только на уровне базы данных. Таким образом, вам необходимо настроить зеркальное отображение базы данных для 50 баз данных на основе предоставленной вами информации. Скорее всего, если одна БД, где все сбои, 50, вероятно, последует, поскольку сбои обычно происходят на аппаратном уровне, а не конкретной базы данных.

Мне кажется, что вы должны использовать технологию кластеризации SQL Server. Вы можете создать активный / активный кластер для поддержки ваших требований.

Что такое активный / активный кластер?

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

Применение этого к вашему сценарию

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

Дополнительная литература

Введение в кластеризацию SQL Server

Я подозреваю, что следующее чтение MSDN также полезно для чтения

Answer 4

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

Если вы рассматриваете это как базовую математику ресурсов, это не часто имеет смысл, если только ресурсы, которые вы используете в сценариях сбоев, не могут обработать всю ожидаемую нагрузку. Иногда это так, но не всегда. В этом случае, чтобы справиться с фактической нагрузкой, вам может понадобиться еще один сервер (например, RAID - возможно, для вашей нагрузки требуется минимум 5 серверов, но у вас есть ферма из 6, тогда вам нужен 1 резервный сервер на каждый сервер для терпеть неудачу выше 1). Иногда ферма может работать в плохом состоянии, но иногда они просто рвут и умирают.

А в случае нештатной работы вы часто сталкиваетесь с авариями, когда законный инцидент вызывает каскад проблем - например, Ваша резервная лента занята восстановлением сервера из резервной копии (даже в тестовой среде - нет реальных сбоев), теперь ваш sql-сервер или exhcange-сервер (или оба) не резервируются, и ваш журнал заполняется.

Answer 5

Будете ли вы зависеть от этих дополнительных приложений? Где они работают в случае сбоя?