Живая миграция контейнеров: взгляд изнутри

    Сегодня мы рассмотрим тему, которая не в полной мере раскрыта в современном мире ИТ: живая миграция контейнеров, как она работает за кулисами и какие проблемы решает. Спрос на данную технологию продолжает стремительно расти, поскольку она открывает новые возможности, предоставляя больше свободы в управлении жизненным циклом приложений.

    Живая миграция – что это?


    Живая миграция контейнеров подразумевает собой процесс перемещения приложения между разными физическими машинами или облаками без прерывания работы приложения и разрыва связи с пользователем. Память, файловая система и сетевое соединение контейнеров, запущенные поверх «голой» аппаратуры, передаются от исходного хост-компьютера к месту назначения, поддерживая рабочее состояние без прерывания работы.
    image


    Проблемы, которые решает живая миграция


    Существует несколько проблем, которые может решить живая миграция:

    • Период простоя во время обслуживания аппаратуры
    Для того, чтобы модифицировать/заменить аппаратное оборудование, системный администратор должен перенести всех пользователей с одного аппаратного узла на другой без простоя и прерывания работы, что само по себе является сложно-выполнимой, а зачастую и вообще невозможной задачей.

    • Несбалансированная загрузка кластера
    При слишком высокой нагрузке на аппаратный узел, необходимо выполнить процесс ребалансировки, для чего нужно будет внедрить специфические конфигурации приложения, что в свою очередь сузит/уменьшит выбор рабочих нагрузок, которые могут хоститься в кластере

    • Проблемы с облаком
    На современном ИТ рынке представлено много разных облачных решений, и время от времени у них случаются различные казусы, такие как период простоя, изменение ценовой политики или даже ухудшение качества предоставляемых услуг. В большинстве случаев, невозможно мигрировать приложение с одного облачного провайдера на другой.

    Альтернативные Решения


    Все выше упомянутые проблемы можно решить, и сейчас мы расскажем несколько вариантов решения данных проблем без помощи живой миграции.

    • Запланированные периоды простоя. Для выполнения технических работ по обслуживанию кластера, нужно пройти три шага:

      1. Заранее уведомить пользователей (владельцев приложений) об окне обслуживания и возможном периоде простоя
      2. Отключить аппаратное оборудование
      3. Подключить обратно только после того, как все необходимые изменения будут выполнены. В этом случае проблемой является относительно большой период простоя.

    • Перенаправление трафика. Чтобы выполнить обслуживание кластера необходимо восстановить копию каждого приложения в другом аппаратном узле, затем перенаправить трафик к этой новой копии и закрыть предыдущую. В этом случае проблемой является сложность данного процесса — необходимо иметь специально разработанные приложения для получения высокой доступности и синхронизации данных. Кроме того, для выполнения этой задачи может потребоваться больше аппаратных ресурсов.

    • Микросервисы. Детальное деление сервисов приложений на отдельные контейнеры и их распределение по различным физическим серверам помогает избежать периодов простоя в случае сбоя аппаратного обеспечения. Вышедшие из строя контейнеры будут автоматически восстановлены в активном аппаратном узле. Однако в этом случае проблемой является опять же сложность данного процесса, поскольку приложения в кластере должны быть разработаны таким образом, чтобы можно было управлять высокой доступностью и восстановлением процесса после сбоя.

    Как Работает Живая Миграция


    Давайте рассмотрим процесс живой миграции с технической стороны на примере следующей схемы:

    image

    • Исходный Узел (Source Node) — местоположение контейнера перед живой миграцией
    • Узел назначения (Destination Node) — местоположение контейнера после живой миграции

    Чтобы выполнить миграцию, платформа замораживает контейнер в исходном узле, блокируя память, процессы, файловую систему и сетевые соединения, и сохраняет состояние этого контейнера. После этого он копируется в узел назначения. Платформа восстанавливает состояние и размораживает контейнер в данном узле. Затем, в исходном узле осуществляется процесс быстрой очистки данных мигрирующего контейнера.

    Всё довольно таки просто: вы получаете, копируете и восстанавливаете состояние контейнера. Однако, в этом случае нужно принимать во внимание период заморозки, который нужно учитывать при разработке (архитектуры) приложений, так как этот момент может оказаться критическим для некоторых из них.

    Существует два способа осуществления живой миграции. Одним из них является предварительное копирование памяти. Если вы хотите перенести контейнер, платформа направит отслеживаемую память на исходный узел, и будет копировать эту память одновременно с узлом назначения до тех пор, пока различие не станет минимальным. После этого платформа замораживает контейнер, получает оставшееся состояние, переносит его на узел назначения, восстанавливает и размораживает его.

    image

    Другой способ — пост-копирования памяти, или другими словами — ленивая миграция. Система вначале замораживает контейнер в исходном узле, получает состояние наиболее быстро меняющихся страниц памяти, переносит состояние на узел назначения, восстанавливает его и размораживает контейнер. Остальная часть состояния в фоновом режиме копируется из исходного узла на узел назначения.

    image

    Обычно, в зависимости от приложения, время замораживания для каждого контейнера занимает от 5 до 30 секунд. Это действительно короткий срок по сравнению с возможными часами простоя во время обслуживания кластера.

    Примеры Использования Живой Миграции


    • Обслуживание аппаратных средств без периода простоя
    Во время периода обслуживания контейнеры могут быть перенесены в режиме реального времени с одного узла физического сервера на другой в рамках одного центра обработки данных, что не приведёт к периоду простоя.

    • Перераспределение загрузки
    Живая миграция позволяет пере-балансировать (равномерно распределить) нагрузку с помощью миграции контейнеров с одного аппаратного узла в другой. Этот сценарий также можно автоматизировать, активирован специальный алгоритм диспетчеризации и соответствующие триггеры.

    image

    • Высокая доступность между зонах доступности в центрах обработки данных (ЦОД)
    Провайдер облачных услуг может предварительно сконфигурировать и предложить набор зон доступности аппаратных средств внутри одного или нескольких центров обработки данных. Как результат, конечные пользователи получают больше возможностей для обеспечения высокой доступности, осуществляя живую миграцию контейнеров без участия администраторов системы из одной зоны доступности в другую.

    • Переход к другому облачному провайдеру
    Живая миграция предоставляет пользователям свободу выбора — они не привязаны к определённому облачному провайдеру, и могут перенести свои приложения на альтернативное облако, без изменений конфигурации и повторного развертывания во время миграции.

    image

    Подводные Камни и Возможные Недостатки


    При всех преимуществах живой миграции, также существуют несколько недостатков, которые нужно принимать во внимание перед началом миграции:

    • Во время живой миграции вы можете заметить некоторое снижение производительности пока контейнер находится в состоянии заморозки. Для некоторых приложений это критический недостаток, так как они не приемлют любое снижение производительности (к примеру, монолитные высоконагруженные онлайн приложения). Однако, кратковременная заморозка не является серьёзным недостатком для большинства приложений в интернете, особенно если говорить о веб-приложениях.

    • Другая сложность связана с большим объемом быстро-меняющихся данных, которые не так легко перенести от одного облачного провайдера к другому. Период ожидания и большой объем данных могут препятствовать успешному выполнению живой миграции.

    • Публичные IP-адреса в мульти-облаке. Невозможно перенести контейнеры с публичным IP-адресом от одного облачного провайдера к другому, поскольку IP-адрес привязан к конкретному провайдеру.

    • Если приложение внутри контейнера использует проприетарный API или проприетарные облачные сервисы конкретного облачного провайдера, выполнить живую миграцию с одного облака на другое может быть очень сложно или даже невозможно.

    Живая Миграция на Современном IT-Рынке


    Какие компании предлагают живую миграцию контейнеров на сегодняшний день?

    • Virtuozzo – эта компания, на самом деле, создала технологию живой миграции контейнеров; они были пионерами в этой области и на сегодняшний момент предлагают движок живой миграции, позволяющий проводить атомарную миграцию контейнера с одного физического хоста на другой.

    • runC от Open Containers Initiative является еще одним многообещающим контейнерным решением с поддержкой живой миграции на базе CRIU.

    • Jelastic предлагает платформу с оркестрацией контейнеров, которая предоставляет живую миграцию как атомарных контейнеров, так и приложений со сложной топологией развертывания между аппаратными хостами, зонами доступности, центрами обработки данных и облачными провайдерами.

    Демо: Миграция Minecraft в Режиме Реального Времени


    Для того, чтобы увидеть процесс миграции приложения Minecraft из AWS на Azure в режиме реального времени без простоев, просмотрите следующее видео:



    Живая миграция контейнеров все еще является относительно новой технологией на рынке. Тем не менее, преимущества этой технологии для современного бизнеса очевидны — никаких простоев во время обслуживания, не нужно тратить много усилий на подготовку и проверку рабочей среды в другом облаке. Именно поэтому живая миграция является отличным решением для лучшей доступности и гибкости. Поделитесь своим опытом миграции контейнеров между облаками или датацентрами в режиме реального времени.
    Jelastic
    41.44
    Jelastic DevOps PaaS для хостеров и ISV
    Share post

    Comments 35

      +1
      Расскажите пожалуйста, на чём построен у вас PaaS, какая именно система оркестрации контейнеров?
        0
        Оркестратор так и называется — Jelastic. Есть бесплатный триал на 14 дней почти у всех хостинг-сервис провайдеров, через которые продается сервис. Детали есть на сайте компании.
        +4
        Всё-таки, у вас заголовок совершенно не совпадает с содержимым. Прочитайте сами: «живая миграция контейнеров: взгляд _изнутри_». Мне даже интересно стало. А вы дали взгляд _снаружи_. Что достаточно очевидно. А вот взгляд изнутри контейнера наверняка содержит множество интересных технических ньюансов.
          0
          Действительно, изнутри работает все очень интересно, когда-то в руки мне попала диссертация Павла Емильянова как-раз по этому проекту, CRIU, еще немало усилий вложил Кирилл Колышкин, сейчас оба работают в компании Virtuozzo. Если у Вас есть какие-то конкретные вопросы относительно нюансов — буду рад на них дать ответ, в рамках своего понимания конечно же.
            0
            Конкретных вопросов нет, я не в теме. Но хотел бы послушать чьи-нибудь рассказы, чтобы понять, насколько это страшно — живая миграция изнутри, надо ли её бояться, чего может отвалится и прочее. Потому что пока по косвенным источникам я для себя пометил живую миграцию как сомнительную технику с возможными осложнениями и предпочитаю думать, что надёжно можно перенести только отключённую машину, а запущенную — как повезёт.
              +2
              есть особенности, которые надо соблюдать при живой миграции:
              — общий домен коллизий в сети, где жил src контейнер и где будет жить dst контейнер (решается оверлейной сетью если разные провайдеры железа)
              — чем реже данные будут изменяться в памяти — тем меньше freezetime, который в любом случае неизбежен во время синка последней дельты изменяющихся данных, тем лучше, ну и приложение должно быть готово к этому маленькому окну (хорошая новость в том, что пакеты сетевые при TCP-соединении не потеряются, и эстеблишить новый конект клиенту не нужно, работает фича ядра linux — tcp-rapair режим)
              — важна целостность данные при переезде процесса (именно данных, на которые дескрипторы были отрыты т.е. файл на сорс ноде до заморозки должен быть такой же точно и на dst-ноде после разморозки процесса)
              +1
              вот, кстати, можно посмотреть сессию Павла Емильянова по этой тематике https://www.youtube.com/watch?v=bnvbq0ePqfs
              +1
              Да, чувствуешь себя обманутым. Ожидаешь какой-то хитрый модуль ядра и код утилит, который это делает, а получаешь красивые и бесполезные картинки и триал на 15 дней…
                0

                .

              • UFO just landed and posted this here
                  0
                  на этом ролике играю я, дело в том, что намеренно я ничего не выполнял т.к. совершенно НЕ умею играть в майнкрафт, что касается таймаутов, то они не такие уж и большие, мы проводили много тестов по результатам которых увидели, что если сервер у клиента забрать больше чем на 3 секунды (вне зависимости от того, что происходит в игре), то игра вываливается с сообщением «Connection Lost», можете сами попробовать
                  • UFO just landed and posted this here
                      +2
                      в ядре Linux есть tcp-rapair режим, он позволяет разморозить процесс с уже установленными сетевыми соединениями в таком виде, в котором они были до заморозки, перед моментом фриза контейнер перестает отвечать «TCP-квитанциями» о получении пакетов новых, потом dst-контейнер делает ARP-реанаунс, после чего получает повторно отправленные клиентом пакеты и уже отвечает нормально на них, таким образом при TCP-соединении пакеты не теряются если не умирают по таймауту (в случае если freezetime окно оказалось слишком большим, к примеру в RAM были частоизменяющиеся данные)
                      0
                      Таймаут по-умолчанию в майне 30 секунд — в это время сервер может вообще выпасть из сего мира и вернуться обратно. Поверьте мне, я занимался разработкой модифицированных ядер майнкрафта одно время.
                        0
                        верю, я тоже когда-то пересобирал и сервер и клиент для тестов через mc-dev, Вы сейчас говорите о ReadTimeout, который и правда стоит в 30 секунд, но вылетает оно не по нему, еще есть SocketTimeout и IdleTimeout, т.е. Вы можете выставить ReadTimeout по обе стороны хоть в пару минут, это не спасет, клиент будет плевать ConnectionLost по истечении нескольких секунд от которых сервер ему не ответит (возможно еще и зависит от действий клиента, о которых писал izzholtik)
                      0
                      можете также просмотреть ролики с использованием других приложений во время миграции
                      https://www.youtube.com/watch?v=Yij5gmpTJzg
                      https://www.youtube.com/watch?v=Ebzf9RvsLCQ
                      • UFO just landed and posted this here
                          0
                          можете зарегистрироваться на одном из наших хостинг партнеров, например, Mirhosting https://jelastic.cloud/details/mirhosting
                          у них две недели триала и доступны докеры
                            0
                            с VLC действительно проще т.к. есть буфер и он кеширует стрим на клиенте, потому для этого юзкейса это решение можно назвать «безопасным» и уместным
                            0

                            Могли бы вы записать совсем простой синтетический сценарий(клиент — серверное приложение), где клиент стабильно бы делал 'ping' к серверу скажем раз в секунду. Интересно было бы увидеть статистику со стороны клиента во время живой миграции такого сервера(для pre- и post- copy).

                              0
                              технически возможно, но все, что будет видно — это время сколько клиент «не видел» сервер, т.к. пакеты при echo-запросе с TTL в 1с и окном больше 1с будут пропадать в никуда, ну а время окна само будет зависеть от того, что изменяется за определенный промежуток времени в RAM, если скажем минимальный ванильный контейнер с данными в RAM 6mb (на примере Jelastic), которые практически не меняются, то и фризтайм будет порядка той секунды, за которую мы на этом примере ничего не увидим, в том числе и разницы между pre/post copy режимами, более того, нельзя сказать, что один из режимов лучше другого (pre/post), все зависит от конкретного приложения и его данных, иногда быстрее срабывает при одном режиме, иногда при другом…
                                0

                                Я думаю время этого окна одна из метрик важных для живой миграции: в зависимости от того что выполняется в контейнере(условно cattle/pets/pandas) оператор и принимает решение о допустимости миграции, не знаю насколько это валидно для контейнеров, но для виртуальных машин(qemu), post-copy в случае фэйла выключает домен.

                                  0
                                  все верно, при этом есть приложения, которые относительно безопасно мигрировать в 99% случаев, такие как:
                                  — большинство веб-приложений (за исключением случаев когда браузер что-то очень оперативно в реалтайме обрабатывает и запоздание на секунду-вторую есть критичным)
                                  — streaming servers (какие как Red5)
                                  — слейвы баз данных с асинхронной репликацией (т.к. догнать свое состояние они могут уже после переезда, пару секунд не решают ничего)
                                  — MQS (сервера очереди сообщений)
                                  и т.д.
                                  живая миграция не есть панацеей абсолютно от всех проблем, но если применять эту технологию там, где это возможно, то это может очень здорово упростить жизнь

                          0

                          Интересно было бы прочитать про особенности работы живой миграции в двух режимах приведенных в статье:
                          Что в данном случае происходит с контейнером во время frozen time, — равносильно ли это "паузе" для контейнера?
                          Что если для pre-copy режима довести копирование страниц памяти до порогового значения так и не получится? Какие методы оптимизации будут использоваться?
                          Что произойдет с контейнером в случае ошибки во время post-copy миграции? Как реализован rollback на исходный узел?
                          Как происходит подготовка к миграции? настройка сети, например? Будут ли отличия в post- и pre- copy?

                          0
                          Почитав статью и посмотрев видео с миграцией minecraft сервера между облачными провайдерами, я не смог понять одну вещь. Клиент игры подрубается к серверу на определённом IP, когда контейнер был перенесён в другое облако, как переносится соединение?

                          Возможно, мой вопрос сформулирован не верно, но очень хотелось бы узнать ответ.
                            +1
                            После миграции контейнера, где живет процесс серверного приложения, IP-адреc остается такой же точно как бы до миграции (даже если этот адрес внутренний), в случае если миграция происходила в другое облако, то между облаками тянется оверлейная сеть (грубо говоря внутри физической внешней сети делается другая, уже логическая сеть, инкапсулированная в физическую), таким образом между облаками контейнеры существуют в одном домене коллизий и чувствуют себя как бы в одной сети. Что касается «точки входа» в этом случае (ноды, где будет прибит уже белый IP), то это может быть обычный шлюз, который включен в эту же самую «логическую» оверлейную сеть.
                            0
                            Мне кажется, или иллюстрации pre-copy и post-copy нарисованы неправильно? В первом случае операция freeze должна быть после копирования основной части памяти, а во втором случае unfreeze должен происходить до ленивого копирования, и тогда описание будет соответствовать иллюстрациям.
                              0
                              Вы все верно подметили, благодарю за подсказку, завтра же подправим. Спасибо! )
                              0
                              почему текст статьи и иллюстрации большей частью взяты отсюда https://www.infoq.com/articles/container-live-migration
                              без указания источника?
                                0
                                потому что автор один — Руслан Синицкий, Jelastic CEO
                                +1

                                Исправьте, пожалуйста, временную шкалу на иллюстрациях: общая оценка времени 1-10 секунд, Frozen Time 10-30

                                  0
                                  уже исправили, спасибо, что подметили!
                                  0
                                  А почему Frozen Time такое большое? У той же VMware до секунды в лучшем случае (при низкой загрузке, небольшой ВМ), до 5 секунд в худшем случае (большая загрузка хостов, большая ВМ)
                                    0
                                    ну здесь все очень относительно
                                    1) vMotion у VMware иногда может фризиться и на полторы минуты, особенно если у виртуалки много дисков и много снапшотов или очень медленная сеть, все зависит от ситуации
                                    2) vMotion катает виртуальный машины, CRIU катает standalone процессы, это разные подходы для решения одной задачи, каждый имеет свои плюсы и минусы: к примеру, вероятность успешной миграции VM гораздо ниже чем вероятность успешного переезда одного лишь процесса, переезд виртуальной машины в общем занимает больше времени

                                  Only users with full accounts can post comments. Log in, please.