LINUX.ORG.RU
ФорумAdmin

Что нынче есть из реального универсального HA для Linux?


4

7

Что-то всё что попробовал - не впечатляет вообще.

Дано:
2 одинаковых железки.
1 гостевая система.

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

Самое приличное что удалось поднять - Xen+Remus+DRBD. Оно даже работает и даже никто не замечает что одна из тачек сдохла.

Но во-первых, имеются некислые проблемы с версиями ядер которые нужны Xen и DRBD. А во-вторых, есть очень некислые проблемы именно с поднятием умершей тачки - master-master в DRBD работает через задницу, миграция на поднятую машину автоматически не происходит и всё такое. В общем, при подключении второй машины весьма велика вероятность завалить гостя.

Кроме того, DRBD и прочие сильно разочаровали в тесте с выдёргиванием шнурка из винта (эмуляция сдыхания диска) - при этом часто херится содержимое диска и на нетронутой машине.

На самом деле VM не критична, в идеале вообще хотелось бы что-то типа kerrighed но без «головной» машины и чтобы при сдыхании одной ноды процессы c неё прозрачно мигрировали на другую.

В общем, вопрос такой - есть чо?

★★★★★

Ответ на: комментарий от tazhate

In simple words, if a virtual machine (VM) is configured as HA and the physical host fails, the VM is automatically restarted on one of the remaining Proxmox VE Cluster nodes.

А надо чтобы VM не рестартовала, а продолжала работать как ни в чём ни бывало. C Xen+Remus+DRBD мне удалось этого добиться, но вторая часть марлезонского балета, а именно включение умершей железки - сыра до безобразия.

Ну и работать должно на количестве машин от 1 до N.

Stanson ★★★★★
() автор топика
Последнее исправление: Stanson (всего исправлений: 2)

чтобы при сдыхании одной ноды процессы c неё прозрачно мигрировали на другую.

и чтобы нагрузка распараллеливалась сама, а программист палец о палец не ударил.

эх мечты, мечты.

dimon555 ★★★★★
()

Ээээ... %)

А если подыхает процессор в момент исполнения каких-то инструкций, или серверный мост в момент пересылки данных?

Chaser_Andrey ★★★★★
()
Ответ на: Ээээ... %) от Chaser_Andrey

А если подыхает процессор в момент исполнения каких-то инструкций, или серверный мост в момент пересылки данных?

И что? Штатная ситуация для серьёзных систем виртуализации вроде vSphere

router ★★★★★
()

HA
чтобы гостевая система всегда была доступна и никогда не перезагружалась что бы ни происходило с одной из железок

ЕМНИП, это уже не HA ( High Availability ), а FT ( Fault Tolerance )

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

чтобы при сдыхании одной ноды процессы c неё прозрачно мигрировали на другую.

и чтобы нагрузка распараллеливалась сама, а программист палец о палец не ударил.

эх мечты, мечты.

Ну как бы первое вполне работает, причём хорошо работает, единственное внешнее проявление такой автоматической миграции, если наблюдать за гостевой ОС посредством пинга и тупо вырубить ту тачку на которой гость живёт в данный момент - 1 пинг будет со временем около 100-200мс. Для подавляющего большинства сервисов это совершенно незаметно.

Распараллеливание нагрузки мне нафиг не надо.

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

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

ЕМНИП, это уже не HA ( High Availability ), а FT ( Fault Tolerance )

Ну как бы FT приводит к HA :) Терминологические тонкости в данный момент не сильно важны.

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

А если вместо master-master DRDB попробовать общий storage ( хотя бы iscsi ) и кластерную ФС?

А как? DRDB на обоих машинах даёт один и тот же /dev/drdb который в свою очередь физически располагается на 2-х машинах и в общем-то синхронизирован. Remus, грубо говоря, постоянно копирует состояние памяти и процессора VM на другую тачку. При сдыхании той тачки, на которой живёт VM, вторая стартует VM у себя с момента последней синхронизации. А диск уже есть, тот же самый /dev/drbd

Как то же самое сделать в случае iSCSI? Чтобы диск на обоих машинах был один и тот же, но располагался на двух в виде зеркала. И чтобы никакого master-slave не было, чтоб физические диски были равноценными.

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

Ну как бы FT приводит к HA :) Терминологические тонкости в данный момент не сильно важны.

Это не просто терминологические тонкости, там адское падение перформанса и ЕМНИП только с одним vCPU машину можно делать с FT

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

Это не просто терминологические тонкости, там адское падение перформанса и ЕМНИП только с одним vCPU машину можно делать с FT

Перформанс сильно зависит от частоты с которой remus копирует состояние на другую машину. При периодичности 100мс у меня производительность падает процентов на 30-40. Что в общем-то не так уж и страшно и является вполне приемлемой ценой за неубиваемость. А vCPU - пофиг, хоть все что есть.

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

ESXi текущей версии не может более 1 vCPU для FT, и даже в следующей версии вроде не предвидится.

Может у них есть больше vCPU для FT исключительно за денежку?

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