Я читал о запуске кластера SQL в среде Hyper V, и, похоже, есть несколько вариантов:
Установите гостевой кластер на 2 виртуальные машины, которые сами являются частью отказоустойчивого кластера.
Установите кластер SQL на 2 виртуальных машины, но сами виртуальные машины не являются частью базового кластера.
С вариантом 1 это немного сложнее, поскольку фактически задействовано два кластера, но это добавляет некоторую гибкость в том смысле, что я могу свободно переносить виртуальные машины между и физическими блейд-серверами в их кластере для физического обслуживания, не влияя на статус гостевой SQL кластер, который работает внутри них.
С вариантом 2 настройка немного проще, поскольку в миксе всего 1 кластер, но мои виртуальные машины привязаны к физическим лезвиям, на которых они настроены (я проигнорирую тот факт, что я могу вручную перемещать виртуальные жесткие диски для целей этого вопроса).
Есть ли еще какие-то факторы, которые я должен учитывать здесь, когда решаю, какой вариант выбрать?
Я могу опробовать оба варианта и, вероятно, сделаю это, но если у кого-то есть опыт работы с этими настройками и он может предложить какой-то вклад, это было бы здорово.
Редактировать:
Были подняты хорошие вопросы о добавлении зеркального отображения к смеси для добавления второй копии базы данных. Я обдумываю, стоит ли просто использовать 2 экземпляра SQL и использовать только зеркалирование, поскольку этот бэкэнд будет использоваться для одного приложения, поскольку это будет довольно стабильная настройка в отношении пользователей и т. Д.
Однако суть этого вопроса была конкретно связана с настройкой кластера. то есть лучше
a) На хостах Hyper V создайте отказоустойчивый кластер виртуальных машин, а затем внутри самих виртуальных машин настройте второй кластер и установите кластер SQL - гостевой кластер поверх кластера хоста.
или
б) Просто настройте кластер SQL на виртуальных машинах и не настраивайте базовый отказоустойчивый кластер на самих хостах Hyper V.
Я видел сторонников обоих вариантов, но я не совсем понимаю плюсы и минусы каждого подхода.
Предполагая, что вы используете Windows 2008 R2 и SQL 2008, тогда:
не так уж и сложно настроить, как только ваше хранилище и хост-кластер будут готовы, осталось всего несколько минут, чтобы настроить sql-кластер.
живая миграция - тоже неплохое решение, так как вы не будете привязаны к блейд-серверу в кластере.
Используйте 2, а затем используйте MIRRORING для обеспечения высокой доступности. Это дает вам больше, чем кластер SQL, потому что он дает вам две копии данных.
Это одно из слабых мест SQL-кластера - если база данных умирает так, что повреждает файл базы данных (и это происходит - не совсем часто, но если вы стремитесь к высокой доступности, вы этого не хотите), тогда кластер происходит сбой, и новый запускаемый процесс SQL .... не загружает базу данных или аварийно завершает работу.
При зеркалировании второй сервер выбирает свою собственную копию данных.
Предлагается третий (МАЛЕНЬКИЙ) SQL-сервер в качестве «свидетеля» (чтобы было 3 экземпляра, что делает переключение при отказе более стабильным).
Лично я считаю (после нескольких месяцев работы в службе поддержки MS SQL Server на Microsoft), что использование кластера SQL для обеспечения высокой доступности в качестве первой линии защиты - это в значительной степени пренебрежение. Через 3 месяца у меня был подобный случай в месяц, когда отказоустойчивость не удалась по РАЗЛИЧНЫМ причинам (одна, включая систему SAN, данные удерживались при сбое). Это действительно заставляет вас оценить двойную копию данных о жизни зеркального экземпляра.