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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

SQL Server 2008 поддерживается в среды виртуальных машин работают на роль Hyper-V в Windows Server 2008 R2 и Windows Server 2008 Стандарт, Предприятие и Центр обработки данных издания.

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

Answer 4

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

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