Кластеризация SQL или образы виртуальных машин

Question

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

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

Я не эксперт по sql Server и разбираюсь в кластеризации только на базовом уровне, но что-то подсказывает мне, что эта "идея" виртуальной машины, которую они придумали, не совсем корпоративное решение.По-моему, это звучит как Микки Маус.Я здесь собираюсь пообедать?Какие аргументы я могу привести в поддержку своей точки зрения?

Answer 1

Чтобы определить, использовать ли виртуальное или кластерное решение, необходимо подробно описать требования к отказоустойчивости.Должно ли решение учитывать сбой оборудования, сбой хранилища или сбой экземпляра?Если сервер выйдет из строя, насколько простым/сложным должен быть процесс восстановления?Каково запланированное использование аппаратных ресурсов?

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

Нужно ли приложению запускаться сразу после сбоя?Если посреди ночи произойдет сбой, какой уровень взаимодействия необходим для возобновления работы приложения.Должно ли оно быть автоматическим или ручным?Если это должно быть автоматическим, должно ли это быть встроено в технологию или что-то закодировано?

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

Извините, в основном ответы состоят из вопросов, но они укажут вам подходящее решение.

Answer 2

Я бы с вами согласился - если они указывают на один и тот же диск, что произойдет, если (когда) этот диск выйдет из строя?

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

Answer 3

Все дело в деньгах!Виртуальные машины обычно также находятся в сети SAN с несколькими узлами кластера, если у вас, скажем, есть сервер ESX с большим количеством виртуальных машин.Итак, если у вас есть кластер виртуальных машин из 4 узлов с серверной частью SAN, вы можете разместить там 40 виртуальных машин.Вы по-прежнему отказоустойчивы и т. д.

НО, пройдя через виртуализацию SQL Server, это было медленно, чисто и просто.Нам не хватало количества операций ввода-вывода в секунду или достаточного количества памяти и процессора.Если вам нужна достойная производительность, скажем, для стресс-тестирования больших объемов, выберите кластер.Имейте в виду, что вам нужны 2 сервера, хранилище SAN и лицензирование SQL/Windows, так что вам придется нелегко.:-(

Наверное, я разрываюсь на эту тему.Мне, как администратору базы данных, нравится, когда мои серверы работают.Нашим тестовым серверам это все еще нужно, но наши серверы разработки обычно не слишком загружены.Вам нужно выступление?(Конечно, кто бы сказал нет)

Answer 4

На самом деле это довольно распространенное явление и выполнимо.Кластерные решения на виртуальных машинах дешевы в развертывании.Более того, SQL Server фактически официально поддерживается на Hyper-V:

SQL Server 2008 поддерживается в средах виртуальных машин, работающих с ролью Hyper-V в Windows Server 2008 R2 и Windows Server 2008 редакциях Standard, Enterprise и Datacenter .

Вопрос только в производительности.Очевидно, что развертывание на базе Hyper-V будет медленнее, чем на "голом металле", но я видел много сайтов, прекрасно работающих на виртуальных машинах.