Как сделать кластер виртуалок QEMU/KVM безопасным для виртуалок?

Всем привет

Допустим, имеется кластер, на котором предполагается запускать виртуальные вашины с использованием qemu-kvm. Естественно, требуется некое общее хранилище, где будут лежать образы. В случае, если хост завис (или подох), это будет обнаружено кластерным ПО и все виртуалки с этого хоста будут перезапущены. А вопрос в следующем: ведь если хост издох, то и данные в образы корректно дописаться не успели, так? И при перезапуске виртуалки мы получим ФС со сбоем, так? Даже более того, если корректно реализован STONITH, то в случае, допустим, отказа только сетевого интерфейса (уборщица отключила кабель) и при сохранении работоспособности линка в SAN, нода будет грубо застрелена в голову.

Как избежать такой ситуации?

Заранее спасибо
  • Вопрос задан
  • 3465 просмотров
Решения вопроса 1
@dyasny
надо рассмотреть каждую ситуацию в частности.

1. если хост работает, но контрольная сеть упала и до него не достучаться. в таком случае будет stonith который для виртуалки ничем не будет отличаться от полноценного reset железа, или не будет ничего, пока админ сам не восстановит сеть (это уже зависит от настроек). типичный failover cluster в принципе сводит все сбои к упавшему железу и перезапуску сервисов на другом хосте, и плоха та виртуалка которая не способна пережить reset без серьезных потерь.

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

3. если упал сторедж - место кончилось, fabric отказал - не важно со стороны хоста или стореджа или свичей. любая проблема которая выдасть при попытке писать или читать виртуальный диск error (EIO, ENOSPACE если в терминах ядра). qemu-kvm в этом случае моментально отправляет VM в паузу, чтоб не генерировать IO и дополнительные сбои. Таким образом in flight IO замораживаются а не теряются. Чиним сторедж, выводим VM из паузы, и щсе продолжается как будто ничего не случилось.

Кстати, #3 это главная причина использования nfs hard mount под виртуалки, чтоб проблемы с доступом к дискам сразу отображались гипервизором а не уходили в буфер.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
gbg
@gbg
Баянист. Тамада. Услуги.
Ситуация "хост издох" для сервера виртуалок - событие маловероятное (примерно такое же, как насильное выключение обычного сервера), так что не пускайте уборщицу в серверную и проблем не будет.
Ответ написан
opium
@opium
Просто люблю качественно работать
Каким ещё кластерным по?
Вообще в облаке подразумевается что перезапуск инстанса не проблема, ну побилась фс сделали проверку и поехали, не поехали запустили новый и накатили сценарий или бекап со старого.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы