Отказоустойчивый кластер Hyper-V 2012

[@4c74356b41]

Это не отказоустойчивый кластер. Это кластер перехода по отказу.

[@RazorBlade]

А что по вашему «отказоустойчивый кластер»? В данном случае, в случае выхода из строя одной ноды, виртуальные машины переедут на живую ноду, правда с перезагрузкой ВМ. Либо можно перевезти ВМ с одной живой ноды на другую живую, практически без потери связи.

[@navion]

А что по вашему «отказоустойчивый кластер»?

VMware Fault Tolerance или Stratus ftServer, которые переживают отказ без прерывания сервиса, а тут рассматривается высокодоступный кластер.

Либо можно перевезти ВМ с одной живой ноды на другую живую, практически без потери связи.

Увенены, что за 4 минуты ВМ успеют загрузиться на запасном узле?

[@RazorBlade]

Ок, это все трактовки, главное, что бы было понятие, что будет происходить в конкретных случаях.

Уверены, что за 4 минуты ВМ успеют загрузиться на запасном узле?

Откуда взялась цифра в 4 минуты я не знаю, однако этот функционал работал еще на прошлом кластере Hyper-V 2008, и проводил подобные опыты и ВМ поднимались на рабочей ноде.

[@4c74356b41]

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

[@navion]

Пардон, почему-то вспомнилось про таймаут tcp, но при падении сервера это не будет иметь значения.

[@RazorBlade]

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

[@de1m]

Либо я чего-то не понимаю, либо автор делает свой велосипед. Если у вас есть отдельное хранилище, то можно без проблем использовать Shared Storage, специально для Hyper-V было придумано.

[@RazorBlade]

Так оно и есть, хранилище, а точнее даже LUN одновременно используется двумя нодами.

[@de1m]

Так машины виртуальные не должны тогда прерываться?

[@RazorBlade]

Если оба узла работают, то переезд ВМ проходит без перезагрузки ВМ, однако, если один узел отключится (сгорел сервер, например), то ВМ переедет на рабочий узел с перезагрузкой ВМ, т.е. фактически ВМ аварийно выключится и включится уже на другом узле.

[@navion]

Коммутатор, а лучше два в стеке, с поддержкой LACP, в моем случае — это стек из двух Cisco 2960S

Ещё лучше коммутаторы с поддержкой RDMA.

[@de1m]

Я этим летом делал похожий проект, правда у нас не было общего хранилища. Поэтому у нас не получилось сделать НА кластер, остановились на кластере с миграцией вм каждые 5 минут.

В вашем случае(когда есть общее хранилище для данных) можно без проблем построить НА-кластер. На оба сервера устанавливаете hyper-v и failover cluster, добавляете sas-диски, настраиваете их как shared storage и добавляете к failover кластеру вм роль. Что-то похожее описывается тут.

По поводу RDMA (тоже была это тема в связке с hyper-v). Это всё очень повышает скорость и доступность. Проблема в том, что если нельзя делать кластер с hyper-v и самба3 на одном сервере.