Кластер Hyper-V VS регулярный кластер

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

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

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

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

Гость, кластеризирующийся:

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

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

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

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

Существуют некоторые большие вещи, можно сделать с прикладным уровнем HA, что уровень машины HA не позволит Вам:

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