Живая миграция контейнеров: плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015)

Материал из 0x1.tv

(перенаправлено с «20151017G»)

Аннотация

Докладчик
Павел Емельянов.jpg
Павел Емельянов

Доклад о том, как делать живую миграцию виртуальной среды вообще, и контейнеров в частности.

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

Видео

on youtube

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

-->

Слайды

Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf

Расширенные тезисы

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

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

Тем не менее, как и в случае с телепортацией, ошибки при миграции могут привести к непредсказуемым или нежелательным последствиям, по-этому для решения этих задач могут применяться другие средства. Например, в ряде случаев балансировку нагрузки можно производить перебрасывая сетевые потоки с сервера на сервер. Обновление ПО или железа можно делать «по расписанию», заранее предупредив всех заинтересованных лиц о временном выключении, или по мере внеплановых остановок серверов, то есть, по просту, падений или зависаний. Кроме того перенос среды можно заменить её перезапуском в случае, если вся система выполнена в архитектуре микросервисов — небольших программ, не имеющих важного внутреннего состояния, допускающих частые перезапуски и сосуществование нескольких запущенных экземпляров («клонов»).

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

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

Для контейнеров задача усложняется. Заморозка контейнера — это сбор и остановка всех процессов, причём в течение этого действия неостановленные ещё процессы могут порождать новые. Сбор состояния контейнера — это сбор информации о графе объектов: процессов, файлов, сетевых соединений, памяти (которой в Линукс может быть 4 типа), и т. д. Количество объектов в графе на несколько порядков может превышать количество виртуальных устройств в машине, а процедура сбора их состояния не универсальна и зависит от вида и особенностей предоставляемого ядром интерфейса. Восстановление состояния контейнера — это восстановление состояния графа, причём возможности создания новых объектов в нём строго ограничены (задача по сложности сходна с задачей разбора контекстно-зависимой аттрибутной грамматики).

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

Несмотря на все сложности, технология миграции контейнеров была реализована в рамках проектов CRIU и P.Haul.

Примечания и отзывы


Plays:37   Comments:0