Comments 35
— общий домен коллизий в сети, где жил src контейнер и где будет жить dst контейнер (решается оверлейной сетью если разные провайдеры железа)
— чем реже данные будут изменяться в памяти — тем меньше freezetime, который в любом случае неизбежен во время синка последней дельты изменяющихся данных, тем лучше, ну и приложение должно быть готово к этому маленькому окну (хорошая новость в том, что пакеты сетевые при TCP-соединении не потеряются, и эстеблишить новый конект клиенту не нужно, работает фича ядра linux — tcp-rapair режим)
— важна целостность данные при переезде процесса (именно данных, на которые дескрипторы были отрыты т.е. файл на сорс ноде до заморозки должен быть такой же точно и на dst-ноде после разморозки процесса)
.
https://www.youtube.com/watch?v=Yij5gmpTJzg
https://www.youtube.com/watch?v=Ebzf9RvsLCQ
у них две недели триала и доступны докеры
Могли бы вы записать совсем простой синтетический сценарий(клиент — серверное приложение), где клиент стабильно бы делал 'ping' к серверу скажем раз в секунду. Интересно было бы увидеть статистику со стороны клиента во время живой миграции такого сервера(для pre- и post- copy).
Я думаю время этого окна одна из метрик важных для живой миграции: в зависимости от того что выполняется в контейнере(условно cattle/pets/pandas) оператор и принимает решение о допустимости миграции, не знаю насколько это валидно для контейнеров, но для виртуальных машин(qemu), post-copy в случае фэйла выключает домен.
— большинство веб-приложений (за исключением случаев когда браузер что-то очень оперативно в реалтайме обрабатывает и запоздание на секунду-вторую есть критичным)
— streaming servers (какие как Red5)
— слейвы баз данных с асинхронной репликацией (т.к. догнать свое состояние они могут уже после переезда, пару секунд не решают ничего)
— MQS (сервера очереди сообщений)
и т.д.
живая миграция не есть панацеей абсолютно от всех проблем, но если применять эту технологию там, где это возможно, то это может очень здорово упростить жизнь
Интересно было бы прочитать про особенности работы живой миграции в двух режимах приведенных в статье:
Что в данном случае происходит с контейнером во время frozen time, — равносильно ли это "паузе" для контейнера?
Что если для pre-copy режима довести копирование страниц памяти до порогового значения так и не получится? Какие методы оптимизации будут использоваться?
Что произойдет с контейнером в случае ошибки во время post-copy миграции? Как реализован rollback на исходный узел?
Как происходит подготовка к миграции? настройка сети, например? Будут ли отличия в post- и pre- copy?
дайте знать, если еще что-то интересует
Возможно, мой вопрос сформулирован не верно, но очень хотелось бы узнать ответ.
без указания источника?
Исправьте, пожалуйста, временную шкалу на иллюстрациях: общая оценка времени 1-10 секунд, Frozen Time 10-30
1) vMotion у VMware иногда может фризиться и на полторы минуты, особенно если у виртуалки много дисков и много снапшотов или очень медленная сеть, все зависит от ситуации
2) vMotion катает виртуальный машины, CRIU катает standalone процессы, это разные подходы для решения одной задачи, каждый имеет свои плюсы и минусы: к примеру, вероятность успешной миграции VM гораздо ниже чем вероятность успешного переезда одного лишь процесса, переезд виртуальной машины в общем занимает больше времени
Живая миграция контейнеров: взгляд изнутри