Что такое синхронизация конфигурации ВМ между серверами гипервизора?

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

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

Ну и что же там бегает туда-сюда?

• Метаданные ВМ: Это как паспорт твоей машины. Файлик (типа .vmx или .xml), где прописано, сколько ей ядер, оперативки, какие диски прицеплены и куда сетевая морда тычется. Эта бумажка должна быть актуальной на всех хостах в кластере.
• Состояние ВМ (самое интересное): Вот это уже для live-миграции. Когда ты на лету перегоняешь машину, чтобы юзеры даже чихнуть не успели. Тут синхронизируется уже не только бумажка, а вся её оперативка и что процессор в этот момент делал. Сложно, овердохуища данных, но работает!
• Сами данные (диски): А вот это обычно лежит на общем хранилище (SAN, Ceph и прочая магия). Чтобы с какого бы хоста ВМ ни стартанула, она видела один и тот же диск. Или эти диски синхронно реплицируются между хостами — чтобы не было конфуза, когда на одном узле данные есть, а на другом — хуй с горы.

Как это выглядит в жизни?

1. VMware vSphere: Там за всем следит vCenter. Она — главная барышня, у неё в своей базе все конфиги. Хосты только спрашивают у неё: «Мам, а какую ВМ запускать?». А диски — на общем хранилище (VMFS), чтобы любой хост мог к ним подъехать.
2. KVM с Proxmox/oVirt: Тут конфиги либо в общей базе данных (PostgreSQL), которую все узлы видят, либо тоже на общем хранилище раскидывают. Главное — чтобы все читали одну и ту же книжку, а не свою собственную.
3. Live Migration (KVM): Вот тут начинается цирк. Команда простая, а под капотом — адский труд.

   virsh migrate --live --persistent web-server qemu+ssh://node2/system

   Ты этой строчкой говоришь: «Эй, чувак web-server, собирай чемоданы, переезжаем на node2, и чтобы никто не заметил!». Система начинает тихонько, не останавливая работу, переливать содержимое оперативки на новый хост. В самый последний момент делает финальный снимок, доливает остатки — и хоп, ВМ уже работает на новом железе. Для юзера — просто пинг подрос на миллисекунду. Волнение ебать, а результат гладкий.

Зачем тебе, как DevOps-у, это всё в зубах вертеть?

• Плановое обслуживание железа: Нужно перезагрузить сервер? Не вопрос. Гоняешь все ВМ с него на другие узлы (evacuate), и юзеры даже не узнают, что их сервис на пять минут остался без крова. Работаешь спокойно, не бздишь, что что-то упадёт.
• Когда всё летит в пизду: Хост взял и умер. Без этой синхронизации конфигов и общего хранилища каждая упавшая ВМ — это часовой восстановительный танец с бубном. А с HA система сама подхватит конфиги с общего склада и запустит виртуалки на живом железе. Автоматом. Терпения ноль ебать, а система работает.
• Балансировка нагрузки (DRS): Система видит, что на одном хосте ядер не хватает, а на другом — малина. Берёт и сама, без твоего участия, перетаскивает парочку ВМ на более свободное железо. Чтобы всё ресурсы жрало равномерно и не было очереди. Умно, блядь.

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