Глупые вопросы про кластеры HA

HolyBoy> Разбираюсь с кластерами HA.
HolyBoy> Правильно ли я понимаю, что общепринятым путём для повышения надёжности является запуск отдельных сервисов в отдельных виртуальных машинах, которые распределяются между нодами кластера его системой управления и при необходимости эти виртуалки мигрируют с одной ноды на другую? Если так, то что в таком случае с производительностью/потреблением оперативки и т.д. на нодах? Это неизбежное зло?

HA на чем? VMWare, Linux-HA, AIX etc?
Лайв миграция машин по принципу распределения ресурсов это не HA, в терминологии VMWare это DRS -
Distributed resource scheduler, в другой Load Balancing.
HA в чистом виде failover, т.е. в случае выхода из строя какой то ноды перебросить ресурсы на живую, ну и средства арбитража во избежание split brain.
В случае виртуальной среды с шареным на несколько хостов гипервизора сторадж, машинки просто рестартуют на другом, по тем или иным правилам распределения, зависящим от вендора.

В этой теме я задаю общие вопросы, чтобы составить представление о том, что можно сделать.

Ylytch> HA на чем? VMWare, Linux-HA, AIX etc?

Linux.

Планирую Pacemaker+libvirt+руки.

Ylytch> Лайв миграция машин по принципу распределения ресурсов это не HA, в терминологии VMWare это DRS -
Ylytch> Distributed resource scheduler, в другой Load Balancing.

Понял. Буду глядеть.

Ylytch> HA в чистом виде failover, т.е. в случае выхода из строя какой то ноды перебросить ресурсы на живую, ну и средства арбитража во избежание split brain.

Что-то жёстко: т.е. случаи с намеренным отключением ноды для техработ не рассматриваются?

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

Т.е. с SAN или NAS?


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

HolyBoy> Разбираюсь с кластерами HA.
HolyBoy> Правильно ли я понимаю, что общепринятым путём для повышения надёжности является запуск отдельных сервисов в отдельных виртуальных машинах, которые распределяются между нодами кластера его системой управления и при необходимости эти виртуалки мигрируют с одной ноды на другую? Если так, то что в таком случае с производительностью/потреблением оперативки и т.д. на нодах? Это неизбежное зло?

Исторически, HA была реакция на failover, как отметил Ylytch — что-то отказало, сразу же переклюк на другое и продолжаем работать. Hotswap с RAID из той же серии — всё чиним на лету, система работает. Потом начали применять такую вещь и для защиты от всяких DDOS атак и просто большой нагрузки — так появился load balancing полный. После простого load balancing-а народ стал присматриваться к multitier balancing — это когда разные машины несли разные ф-ции и балансировать надо уже не просто по входящему запросу, а в зависимости от внутренних потребностей. Да и синхронизация уже нужна не полная, а частичная. И балансинг и его стратегии идут уже отдельно для каждого уровня.

Добавление машины в кластер всегда несло с собой риск сваливания всего кластера. Всякие гипервизоры позволяют поднимать машинку, логически добавлять, а потом уже мигрировать в боевой класстер. Ну и гибкость тут в управлении — это гипервизор берёт многие вещи на себя при старте VM-ок. Т.е. частичная автоматизация процесса. Вплоть до того, что запускаются машинки в режиме on-demand.

HolyBoy> Что-то жёстко: т.е. случаи с намеренным отключением ноды для техработ не рассматриваются?
В чистом вида HA и Load Balancing редко встречаются, файл-кластеры например,чаще имеет место быть либо комбинация этих технологий, либо какие то способы ручного управления ресурсами, посредством того же interconnect/heartbeat etc. на выделенном интерфейсе Ethernet\Infiniband etc. позволяющих переместить инстансы или вирт.машинки на другие ноды для обслуживания.
Чаще всего отсутствие balancing при наличии interconnect/heartbeat связано с лицензионными ограничениями.
Ylytch>> В случае виртуальной среды с шареным на несколько хостов гипервизора сторадж, машинки просто рестартуют на другом, по тем или иным правилам распределения, зависящим от вендора.
HolyBoy> Т.е. с SAN или NAS?
Именно.
HolyBoy> В целом хочется снизить время простоя сервисов во время обслуживания до 0 и повысить надёжность. И тут непонятно вот что: если с отдельными нодами всё просто, достаточно только перевести запущенные на ней сервисы на другую ноду, а затем перезагружать-обновлять и тд, то как быть со службами, в частности, с запущенными виртуальными машинами? Есть ли возможность, к примеру, создав копию текущей гостевой системы и обновив её, постепенно перевести на неё сетевые соединения с оригинала так, чтобы пользователям это было незаметно? Или всё равно будет какой-то перерыв в обслуживании, очень маленький, но тем не менее?

Можно: VMWare vMotion & Xen XenMotion. Но это не совсем то что вы описали, это Live Migration виртуальных машин на ходу с ноды на ноду. Перегоняются с ноды на ноду только содержимое активных страниц памяти и создается так называемой memory bitmap, карта памяти ВМ с протоколированием изменений в процессе копирования, стоп копи, исходная машинка уходит в суспенд, на вторую ноду передается уже dirty memory, т.е мемори пейджес указанные в bitmap, по окончанию копирования ВМ энейблится из своего суспенд состояния на новой ноде, кластер через RARP регистрирует на свитче MAC, все мгрейшн окончен. Перерыв в обслуживании один-два пинга)))))))))))) Запущенные копии виртуалок это что то типа Fault Tolerance от VMWare. Или, что вернее, больше похоже на механизм лайв миграции KVM, в котором я не копенгаген.

Вообще, советовал бы приглядется к Xen Cloud Platform, если, конечно, функционал не избыточен, и нет привязки к конкретному решению.

.

Ну что-ж.

Сделано: HA-кластер СХД. Раздаёт диски по iSCSI, внутри себя синхронизируется по DRBD, там всё просто и надёжно; HA-кластер виртуальных машин, диски берёт с СХД по iSCSI же, работает живая миграция с одной ноды на другую, а также, разумеется, файловер.

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

HolyBoy> К сожалению, по пока что непонятным причинам, виртуалки с виндовсами работают нестабильно. Как эта проблема решится, можно будет и в работу пускать.

Наблюдал нечто подобное да базе Linux HA, DRDB и VMWare Server в котором жила Win2K3 + MS SQLServer. FailOver для базы всегда являлся "стрессом"