Кластер Hyper-V VS обычный кластер

Нам нужно выбирать между Hyper-V и обычными кластерными технологиями. В чем преимущество и недостаток этих подходов?

Обновить:

У нас есть физические серверы, и мы хотим построить надежное решение с использованием кластерного подхода. Нам нужно кластеризовать наше приложение и БД (MS SQL). Мы знаем, что можем использовать:

Обычная служба кластеров Windows. Приложение и БД будут переноситься с одного узла на другой.
Отказоустойчивый кластер Hyper-V. Виртуальная машина будет мигрировать с одного узла на другой.
Комбинированный вариант. Зеркальное отображение БД для MS SQL и Hyper-V для нашего приложения.

Нам нужно сделать выбор между этим подходом. Итак, нам нужно знать преимущества и недостатки этих подходов?

Кластеризация хостов и кластеризация гостей дают аналогичные преимущества. Если одна физическая машина выйдет из строя, другая предоставит платформу для возобновления вашей рабочей нагрузки.

Основные различия заключаются в том, как управляются кластеры, и в том, что именно происходит в момент аварийного переключения.

Кластеризация хостов:

Вы можете настроить группы хостов, на которых может работать любая виртуальная машина.
Сбой хоста приводит к перезагрузке виртуальной машины, размещенной на другом физическом компьютере.
Требуется общее хранилище
Управление кластером осуществляется на уровне хоста и довольно однородно. Всем рабочим нагрузкам предоставляются свойства высокой доступности.
Связь внутри кластера происходит очень надежно. Его нельзя прервать, потому что виртуальная машина не получила процессорного времени или доступа к вводу-выводу.
Живая миграция зависит от кластеризации хостов, поэтому вы, вероятно, уже на пути к ее включению.

Гостевая кластеризация:

Каждую отдельную виртуальную машину необходимо настроить как часть кластера.
Каждый кластер зависит от типа рабочей нагрузки. Если рабочая нагрузка не поддерживает кластеризацию, вы не можете кластеризоваться на этом уровне.
Общее хранилище, вероятно, потребуется, но может и не потребоваться.
Связь внутри кластера труднее гарантировать, поэтому переключение на другой происходит без необходимости, особенно во время динамической миграции. Это может иметь для вас значение, а может и не иметь значения.
Аварийное переключение, когда это происходит, может быть несколько быстрее, поскольку ОС не должна загружаться. Однако для баз данных это обычно не большая часть времени отработки отказа.

Раньше я думал, что вы всегда должны кластеризоваться на гостевом уровне, если можете. Затем люди познакомили меня с усилиями по управлению, связанными с этим, и показали, что кластеризация на уровне хоста часто имеет смысл.

Я не могу вспомнить много случаев, когда обеспечение высокой доступности на уровне машины лучше, чем обеспечение высокой доступности на уровне приложений. Если у вас есть бюджет, и ваше приложение поддерживает его (например, SQL), тогда обеспечьте высокую доступность на уровне приложения.

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

Есть несколько замечательных вещей, которые вы можете сделать с HA на уровне приложения, которые HA на уровне машины вам не позволит:

Вы можете обновить операционную систему без значительного простоя. HA на уровне машины по-прежнему требует перезагрузки виртуальной машины для установки обновлений. Это потребует больше времени простоя, чем простая отработка отказа службы.
Поддерживайте работу системы даже в случае сбоев на уровне ОС.
Уметь противостоять сбоям на уровне приложений. Если у вас произошел сбой службы и вы отказываетесь только от виртуальной машины, вы все равно не работаете.