На встрече с преподавателями кафедры сетей связи СПбГУТ им. Бонч-Бруевича один из них честно признался, что именно эту часть разговора «критически конспектирует». Речь шла про живую миграцию виртуальных машин — аналог технологии vMotion из мира VMware. Тема, на которой видно зрелость платформы, и тема, на которой мы ответили без маркетингового глянца. Разберём по порядку.
Что такое живая миграция виртуальных машин
Живая миграция (live migration) — это перенос *работающей* виртуальной машины с одного физического узла на другой без её остановки. Пользователь внутри ВМ продолжает работать, открытые приложения не закрываются, сетевые соединения не рвутся — а сама виртуалка в это время «переезжает» на соседний сервер.
В экосистеме VMware эта функция называется vMotion и считается одной из ключевых. Поэтому первый вопрос при выборе российской платформы закономерен: есть ли аналог vMotion, и работает ли он так же прозрачно.
Зачем она нужна на практике
Живая миграция решает три повседневные задачи администратора:
- Обслуживание без простоя. Нужно обновить прошивку или заменить память на сервере — переносим все ВМ на соседние узлы, гасим освободившийся хост, обслуживаем, возвращаем нагрузку обратно. Пользователи ничего не заметили.
- Балансировка нагрузки. Один узел перегружен, другой простаивает — часть ВМ автоматически или вручную переезжает туда, где есть ресурсы.
- Эвакуация перед аварией. Узел начал «сыпать» ошибками памяти или дисков — ВМ уводят с него заранее, не дожидаясь полного отказа.
Без живой миграции каждая из этих операций означает остановку виртуальных машин — то есть простой сервисов.
Живая миграция в Inscale: что нужно знать
Доступность живой миграции и поддерживаемые конфигурации зависят от версии платформы — для конкретной инсталляции это уточняется на демонстрации. Преподавателям мы ответили так же прямо: студентам полезно видеть реальное состояние разработки, а не глянцевую презентацию.
От живой миграции не зависит отказоустойчивость. При отказе сервера его виртуальные машины автоматически перезапускаются на доступных узлах кластера — для этого нужны общее хранилище и запас ресурсов. Без живой миграции плановое обслуживание сервера означает перезапуск его машин на других узлах в согласованное окно.
Что нужно для живой миграции в любом кластере
- Общее хранилище, доступное обоим серверам: диски машины не копируются, переносится её состояние.
- Совместимые процессоры. Машина продолжает работу на другом сервере, поэтому набор инструкций процессора должен совпадать; для разнородного парка это учитывают при проектировании кластера.
- Сеть между серверами с запасом пропускной способности: оперативная память машины передаётся по сети.
- Проброшенные устройства. Устройства, подключённые к машине напрямую, — USB, графический ускоритель — усложняют перенос; такие машины планируют отдельно.
Где живая миграция и отказоустойчивость пересекаются
Живую миграцию часто путают с отказоустойчивостью (HA), но это разные вещи:
- Живая миграция — *плановый* перенос работающей ВМ (вы сами решаете, когда и куда).
- Отказоустойчивость (HA) — *аварийный* автоматический перезапуск ВМ при внезапном отказе узла.
Как устроена вторая половина — HA-кластер, сценарий Split-Brain и автоматическое восстановление кворума — мы разобрали в отдельной статье про отказоустойчивость виртуальных машин. А о том, на каком ядре всё это построено, — в материале про российский гипервизор на базе KVM.
Коротко
Живая миграция виртуальных машин — это перенос работающей машины между серверами без её остановки, аналог vMotion. В Inscale доступность живой миграции и поддерживаемые конфигурации зависят от версии платформы; отказоустойчивость от неё не зависит — при отказе сервера машины перезапускаются на других узлах. Хотите посмотреть, как платформа ведёт себя вживую, — запросите демо-доступ и попробуйте интерфейс сами.
Живая миграция ВМ в кластере Inscale.
