Да. Я использую Ceph для моего общего хранилища и довольно регулярно делаю живую миграцию без простоя. Это работает только с KVM, использование контейнеров требует перезапуска во время миграции.

Ну, полного отсутствия простоев не бывает. Простои около миллисекунд (секунд). Меньше секунды — в большинстве случаев нормально. Но всё зависит от того, сколько у тебя клиентов и какое приложение они используют. Ещё одна идея — использовать HAProxy для этой ВМ, чтобы в случае длительного простоя HAProxy мог перенаправлять клиентов на другую ВМ. Ещё могу сказать, что OSPF может помочь, если ты можешь его использовать, в сочетании с коммутаторами, поддерживающими OSPF...

Заметка к обсуждению, на всякий случай. — Бесперебойная миграция в Proxmox, на самом деле, не связана с меньшим или большим временем простоя, чем в Xen, VMware и т.д. Всегда есть какой-то «разрыв» на уровне миллисекунд при переходе от состояния <старый выключен> к <новый включен>. Обычно задержка настолько незначительна, что вы можете ее заметить или не заметить, если постоянно пингуете целевой хост, который переносится с помощью live migration. Как всегда, live migration зависит от простого факта: активность внутри мигрируемой ВМ генерирует дельты оперативной памяти на исходном хосте. И, возможно, дельты на прикрепленных дисках тоже (зависит от использования дисков в стиле shared-san; или нет). Эти изменения необходимо перенести с Исходного хоста>>Целевой хост перед переходом миграции. Если скорость изменения внутри мигрируемой ВМ превышает пропускную способность между двумя физическими серверами, которые являются источником и целевым хостом, то ваша live migration растянется. Исходный сервер останется онлайн, дельты будут копироваться постепенно/итеративно, пока целевой хост не «догонит» исходный. Так что: Если ваш исходный сервер «слишком занят» по сравнению с «доступной пропускной способностью для передачи дельт», то live migration на самом деле никогда не произойдет. Время перехода просто постоянно откладывается в будущее. Я видел это в различных средах (OpenStack KVM, Proxmox и т.д.) — это вопрос не попыток сделать невозможное. Ведь это невозможно. Обратите внимание, что Proxmox, как и большинство современных реализаций KVM, имеет эту функцию — позволяет проводить «live migration» с использованием не-shared storage. Но вам нужно терпеливо ждать, пока блоки дисков не будут скопированы сначала с исходного хоста на целевой. Некоторым людям не нравится ждать, поэтому они используют shared-storage только при live migrations. Но это возможно, просто требуется терпение, в зависимости от скорости соединения между узлами Proxmox и размера образов ВМ, передаваемых по каналу. Tim

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

Просто хотел добавить, я согласен, что live-migration кластера из 2 узлов возможна, но наличие 3 узлов или третьего 'witness / QDevice' было бы неплохо, если возможно. Но это не обязательно. Tim