Комментарии 35
Расскажите пожалуйста, на чём построен у вас PaaS, какая именно система оркестрации контейнеров?
Всё-таки, у вас заголовок совершенно не совпадает с содержимым. Прочитайте сами: «живая миграция контейнеров: взгляд _изнутри_». Мне даже интересно стало. А вы дали взгляд _снаружи_. Что достаточно очевидно. А вот взгляд изнутри контейнера наверняка содержит множество интересных технических ньюансов.
Действительно, изнутри работает все очень интересно, когда-то в руки мне попала диссертация Павла Емильянова как-раз по этому проекту, CRIU, еще немало усилий вложил Кирилл Колышкин, сейчас оба работают в компании Virtuozzo. Если у Вас есть какие-то конкретные вопросы относительно нюансов — буду рад на них дать ответ, в рамках своего понимания конечно же.
Конкретных вопросов нет, я не в теме. Но хотел бы послушать чьи-нибудь рассказы, чтобы понять, насколько это страшно — живая миграция изнутри, надо ли её бояться, чего может отвалится и прочее. Потому что пока по косвенным источникам я для себя пометил живую миграцию как сомнительную технику с возможными осложнениями и предпочитаю думать, что надёжно можно перенести только отключённую машину, а запущенную — как повезёт.
есть особенности, которые надо соблюдать при живой миграции:
— общий домен коллизий в сети, где жил src контейнер и где будет жить dst контейнер (решается оверлейной сетью если разные провайдеры железа)
— чем реже данные будут изменяться в памяти — тем меньше freezetime, который в любом случае неизбежен во время синка последней дельты изменяющихся данных, тем лучше, ну и приложение должно быть готово к этому маленькому окну (хорошая новость в том, что пакеты сетевые при TCP-соединении не потеряются, и эстеблишить новый конект клиенту не нужно, работает фича ядра linux — tcp-rapair режим)
— важна целостность данные при переезде процесса (именно данных, на которые дескрипторы были отрыты т.е. файл на сорс ноде до заморозки должен быть такой же точно и на dst-ноде после разморозки процесса)
— общий домен коллизий в сети, где жил src контейнер и где будет жить dst контейнер (решается оверлейной сетью если разные провайдеры железа)
— чем реже данные будут изменяться в памяти — тем меньше freezetime, который в любом случае неизбежен во время синка последней дельты изменяющихся данных, тем лучше, ну и приложение должно быть готово к этому маленькому окну (хорошая новость в том, что пакеты сетевые при TCP-соединении не потеряются, и эстеблишить новый конект клиенту не нужно, работает фича ядра linux — tcp-rapair режим)
— важна целостность данные при переезде процесса (именно данных, на которые дескрипторы были отрыты т.е. файл на сорс ноде до заморозки должен быть такой же точно и на dst-ноде после разморозки процесса)
вот, кстати, можно посмотреть сессию Павла Емильянова по этой тематике https://www.youtube.com/watch?v=bnvbq0ePqfs
Да, чувствуешь себя обманутым. Ожидаешь какой-то хитрый модуль ядра и код утилит, который это делает, а получаешь красивые и бесполезные картинки и триал на 15 дней…
.
НЛО прилетело и опубликовало эту надпись здесь
на этом ролике играю я, дело в том, что намеренно я ничего не выполнял т.к. совершенно НЕ умею играть в майнкрафт, что касается таймаутов, то они не такие уж и большие, мы проводили много тестов по результатам которых увидели, что если сервер у клиента забрать больше чем на 3 секунды (вне зависимости от того, что происходит в игре), то игра вываливается с сообщением «Connection Lost», можете сами попробовать
НЛО прилетело и опубликовало эту надпись здесь
в ядре Linux есть tcp-rapair режим, он позволяет разморозить процесс с уже установленными сетевыми соединениями в таком виде, в котором они были до заморозки, перед моментом фриза контейнер перестает отвечать «TCP-квитанциями» о получении пакетов новых, потом dst-контейнер делает ARP-реанаунс, после чего получает повторно отправленные клиентом пакеты и уже отвечает нормально на них, таким образом при TCP-соединении пакеты не теряются если не умирают по таймауту (в случае если freezetime окно оказалось слишком большим, к примеру в RAM были частоизменяющиеся данные)
Таймаут по-умолчанию в майне 30 секунд — в это время сервер может вообще выпасть из сего мира и вернуться обратно. Поверьте мне, я занимался разработкой модифицированных ядер майнкрафта одно время.
верю, я тоже когда-то пересобирал и сервер и клиент для тестов через mc-dev, Вы сейчас говорите о ReadTimeout, который и правда стоит в 30 секунд, но вылетает оно не по нему, еще есть SocketTimeout и IdleTimeout, т.е. Вы можете выставить ReadTimeout по обе стороны хоть в пару минут, это не спасет, клиент будет плевать ConnectionLost по истечении нескольких секунд от которых сервер ему не ответит (возможно еще и зависит от действий клиента, о которых писал izzholtik)
можете также просмотреть ролики с использованием других приложений во время миграции
https://www.youtube.com/watch?v=Yij5gmpTJzg
https://www.youtube.com/watch?v=Ebzf9RvsLCQ
https://www.youtube.com/watch?v=Yij5gmpTJzg
https://www.youtube.com/watch?v=Ebzf9RvsLCQ
НЛО прилетело и опубликовало эту надпись здесь
можете зарегистрироваться на одном из наших хостинг партнеров, например, Mirhosting https://jelastic.cloud/details/mirhosting
у них две недели триала и доступны докеры
у них две недели триала и доступны докеры
с VLC действительно проще т.к. есть буфер и он кеширует стрим на клиенте, потому для этого юзкейса это решение можно назвать «безопасным» и уместным
Могли бы вы записать совсем простой синтетический сценарий(клиент — серверное приложение), где клиент стабильно бы делал 'ping' к серверу скажем раз в секунду. Интересно было бы увидеть статистику со стороны клиента во время живой миграции такого сервера(для pre- и post- copy).
технически возможно, но все, что будет видно — это время сколько клиент «не видел» сервер, т.к. пакеты при echo-запросе с TTL в 1с и окном больше 1с будут пропадать в никуда, ну а время окна само будет зависеть от того, что изменяется за определенный промежуток времени в RAM, если скажем минимальный ванильный контейнер с данными в RAM 6mb (на примере Jelastic), которые практически не меняются, то и фризтайм будет порядка той секунды, за которую мы на этом примере ничего не увидим, в том числе и разницы между pre/post copy режимами, более того, нельзя сказать, что один из режимов лучше другого (pre/post), все зависит от конкретного приложения и его данных, иногда быстрее срабывает при одном режиме, иногда при другом…
Я думаю время этого окна одна из метрик важных для живой миграции: в зависимости от того что выполняется в контейнере(условно cattle/pets/pandas) оператор и принимает решение о допустимости миграции, не знаю насколько это валидно для контейнеров, но для виртуальных машин(qemu), post-copy в случае фэйла выключает домен.
все верно, при этом есть приложения, которые относительно безопасно мигрировать в 99% случаев, такие как:
— большинство веб-приложений (за исключением случаев когда браузер что-то очень оперативно в реалтайме обрабатывает и запоздание на секунду-вторую есть критичным)
— streaming servers (какие как Red5)
— слейвы баз данных с асинхронной репликацией (т.к. догнать свое состояние они могут уже после переезда, пару секунд не решают ничего)
— MQS (сервера очереди сообщений)
и т.д.
живая миграция не есть панацеей абсолютно от всех проблем, но если применять эту технологию там, где это возможно, то это может очень здорово упростить жизнь
— большинство веб-приложений (за исключением случаев когда браузер что-то очень оперативно в реалтайме обрабатывает и запоздание на секунду-вторую есть критичным)
— streaming servers (какие как Red5)
— слейвы баз данных с асинхронной репликацией (т.к. догнать свое состояние они могут уже после переезда, пару секунд не решают ничего)
— MQS (сервера очереди сообщений)
и т.д.
живая миграция не есть панацеей абсолютно от всех проблем, но если применять эту технологию там, где это возможно, то это может очень здорово упростить жизнь
Интересно было бы прочитать про особенности работы живой миграции в двух режимах приведенных в статье:
Что в данном случае происходит с контейнером во время frozen time, — равносильно ли это "паузе" для контейнера?
Что если для pre-copy режима довести копирование страниц памяти до порогового значения так и не получится? Какие методы оптимизации будут использоваться?
Что произойдет с контейнером в случае ошибки во время post-copy миграции? Как реализован rollback на исходный узел?
Как происходит подготовка к миграции? настройка сети, например? Будут ли отличия в post- и pre- copy?
спасибо за вопросы, немного выше Игорь рассписал некоторые детали https://habrahabr.ru/company/jelastic/blog/313512/#comment_9877176
дайте знать, если еще что-то интересует
дайте знать, если еще что-то интересует
Почитав статью и посмотрев видео с миграцией minecraft сервера между облачными провайдерами, я не смог понять одну вещь. Клиент игры подрубается к серверу на определённом IP, когда контейнер был перенесён в другое облако, как переносится соединение?
Возможно, мой вопрос сформулирован не верно, но очень хотелось бы узнать ответ.
Возможно, мой вопрос сформулирован не верно, но очень хотелось бы узнать ответ.
После миграции контейнера, где живет процесс серверного приложения, IP-адреc остается такой же точно как бы до миграции (даже если этот адрес внутренний), в случае если миграция происходила в другое облако, то между облаками тянется оверлейная сеть (грубо говоря внутри физической внешней сети делается другая, уже логическая сеть, инкапсулированная в физическую), таким образом между облаками контейнеры существуют в одном домене коллизий и чувствуют себя как бы в одной сети. Что касается «точки входа» в этом случае (ноды, где будет прибит уже белый IP), то это может быть обычный шлюз, который включен в эту же самую «логическую» оверлейную сеть.
Мне кажется, или иллюстрации pre-copy и post-copy нарисованы неправильно? В первом случае операция freeze должна быть после копирования основной части памяти, а во втором случае unfreeze должен происходить до ленивого копирования, и тогда описание будет соответствовать иллюстрациям.
почему текст статьи и иллюстрации большей частью взяты отсюда https://www.infoq.com/articles/container-live-migration
без указания источника?
без указания источника?
Исправьте, пожалуйста, временную шкалу на иллюстрациях: общая оценка времени 1-10 секунд, Frozen Time 10-30
А почему Frozen Time такое большое? У той же VMware до секунды в лучшем случае (при низкой загрузке, небольшой ВМ), до 5 секунд в худшем случае (большая загрузка хостов, большая ВМ)
ну здесь все очень относительно
1) vMotion у VMware иногда может фризиться и на полторы минуты, особенно если у виртуалки много дисков и много снапшотов или очень медленная сеть, все зависит от ситуации
2) vMotion катает виртуальный машины, CRIU катает standalone процессы, это разные подходы для решения одной задачи, каждый имеет свои плюсы и минусы: к примеру, вероятность успешной миграции VM гораздо ниже чем вероятность успешного переезда одного лишь процесса, переезд виртуальной машины в общем занимает больше времени
1) vMotion у VMware иногда может фризиться и на полторы минуты, особенно если у виртуалки много дисков и много снапшотов или очень медленная сеть, все зависит от ситуации
2) vMotion катает виртуальный машины, CRIU катает standalone процессы, это разные подходы для решения одной задачи, каждый имеет свои плюсы и минусы: к примеру, вероятность успешной миграции VM гораздо ниже чем вероятность успешного переезда одного лишь процесса, переезд виртуальной машины в общем занимает больше времени
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Живая миграция контейнеров: взгляд изнутри