LINUX.ORG.RU
ФорумAdmin

RHEV: отказоустойчивость хоста

 ,


0

2

Всем привет.

Изучаю возможности отказоустойчивости RHEV. Имею один сервер rhev-m и два сервера rhev-h подключенных к СХД по файберу. В серверах по одному блоку питания. На хостах настроен Power managment и фенсинг через ILO. Провел ряд экспериментов: 1. Выдергиваю файбер из хоста - ВМ заморозились и остались на хосте в состоянии паузы 2. выдергиваю провод из блока питания - rhev пытается убить хост через ilo, но он тоже не доступен, т.к. питания нет. ВМ никуда не перехали.

Вопрос к гуру rhev можно ли изменить поведение в данных ситуациях? Чтобы ВМ со сбойного хоста запустились на живом.

п.2 тут можно было бы придумать чтото типа кворумного диска , неужели редхат не продумал такую ситуацию?


1. Выдергиваю файбер из хоста - ВМ заморозились и остались на хосте в состоянии паузы

и какие проблемы? их можно разморозить (по моему в свежих версиях это само происходит) как только файбер вернется

2. выдергиваю провод из блока питания - rhev пытается убить хост через ilo, но он тоже не доступен, т.к. питания нет.

в 3.2 есть вторичный fence device, например управляемый APC.

п.2 тут можно было бы придумать чтото типа кворумного диска , неужели редхат не продумал такую ситуацию?

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

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

и какие проблемы? их можно разморозить (по моему в свежих версиях это само происходит) как только файбер вернется

верно, так и происходит, но хотелось бы чтобы ВМ перезапускалась на хосте, где сторадж доступен.

в 3.2 есть вторичный fence device, например управляемый APC.

к сожалению такого нету. остается использовать два блока питания, ну или скрипт для вторичного fence device заменить на свой :)

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

все-таки использование общего диска для разруливания подобных ситуаций было бы лучше, в той же VmWare есть Datastore Heartbeat

apmucm ()
Ответ на: комментарий от apmucm

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

напишите в саппорт, если скажут что этого нет - откройте фичер реквест. обычно запросы от клиентов попадают к разрабам с высоким приоритетом. А пока что, написать простенький API скрипт тоже не сложно: шлем запрос на статус ВМ, если кто то из них paused, то шлем ей power down и start. я бы даже конкретные команды написал, но под рукой нет рабочей системы

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

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

RHEV пока не куплен

А пока что, написать простенький API скрипт тоже не сложно: шлем запрос на статус ВМ, если кто то из них paused, то шлем ей power down и start. я бы даже конкретные команды написал, но под рукой нет рабочей системы

Была такая идея, через REST API проверять статус стораджа на хостах и ВМ в состоянии паузы на нем, далее перезагружать на другом хосте. Но это все костыли, хочется в коробке:) Ну да лан, придумаю что нибудь, этож не ВМВаря, которую своими фишками хрен дополнишь.

apmucm ()
Ответ на: комментарий от apmucm

можно залезть на канал #rhev на freenode, там многие разрабы и саппорты сидят. или, если есть аккаунт на rhn написать в rhev user groups.

а API скрипты писать сейчас одно удовольствие - особенно на пайтоне.

dyasny ★★★★★ ()

То, что ты хочешь, невозможно. В системах с общими данными доступность(читай, чтобы хосты переехали) несовместима с устойчивостью к фрагментации сети, которое, в описанной ситуации, очень трудно отличить от выключения узла. Другими словами, для обеспечения доступности хоста ты должен гарантировать доступность всех остальных участников процесса (iLO, кворумный диск, whatever), как минимум возле момента падения хоста. Что не всегда является намного более простой задачей. Потому решения с консистентными данными не интересны. А другие «onse size fits all» решения пока не известны.

DonkeyHot ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.