Живая миграция контейнеров: плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015)
Материал из 0x1.tv
Аннотация
- Докладчик
- Павел Емельянов
Доклад о том, как делать живую миграцию виртуальной среды вообще, и контейнеров в частности.
Я расскажу о том, почему живая миграция является более сложной задачей, чем простое копирование содержимого памяти процессов, об её особенности в случае с контейнерами и о существующих готовых решениях.
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Слайды
Расширенные тезисы
Живая миграция — это процедура переноса виртуальной среды с одного компьютера на другой. В широком смысле данная тема не является новой и достаточно хорошо освещена в научной фантастике, где она называется телепортацией — объект помещается в гипотетическое устройство-телепортатор, сканируется, информация передаётся на пункт-приёмник, после чего объект оказывается в другом месте пространства. Применительно к виртуальным средам этот процесс выглядит точно так же — среда анализируется, её состояние сохраняется в специальном формате, передаётся на принимающий компьютер, после чего среда восстанавливается. Для стороннего наблюдателя это выглядит как «перемещение» среды с одного компьютера на другой.
Применение таких манипуляций на практике может быть оправдано. Во-первых, живой перенос рабочих программ с компьютера на компьютер производит сильное впечатление на неподготовленного пользователя. Во-вторых, возможность передвигать виртуальные среды между компьютерами позволяет перераспределять нагрузку между последними. В-третьих, освободив компьютер от выполняющихся на нём программ, можно произвести обновление системного ПО или аппаратуры.
Тем не менее, как и в случае с телепортацией, ошибки при миграции могут привести к непредсказуемым или нежелательным последствиям, по-этому для решения этих задач могут применяться другие средства. Например, в ряде случаев балансировку нагрузки можно производить перебрасывая сетевые потоки с сервера на сервер. Обновление ПО или железа можно делать «по расписанию», заранее предупредив всех заинтересованных лиц о временном выключении, или по мере внеплановых остановок серверов, то есть, по просту, падений или зависаний. Кроме того перенос среды можно заменить её перезапуском в случае, если вся система выполнена в архитектуре микросервисов — небольших программ, не имеющих важного внутреннего состояния, допускающих частые перезапуски и сосуществование нескольких запущенных экземпляров («клонов»).
Тем не менее, технология живой миграции существует и реализована в рамках проекта CRIU. Для понимания особенностей живой миграции контейнеров проведём её сравнение с живой миграцией более простого объекта — виртуальной машины. Для корректности сравнения, отметим, что полная процедура миграции включает в себя много стадий, а именно — заморозка контейнера, сбор и сохранение состояния, копирование состояния на принимающий сервер, восстановление состояния и разморозка.
Все эти этапы в случае миграции виртуально машины оперируют небольшим количеством объектов и достсточно просто раскладываются на ряд несложных действий. А именно: заморозка машины — это процедура погружения её в сон, сбор состояния — это последовательный обход конечного набора виртуальных устройств и сохранение информации о них, восстановление — создание устройств и запись в их виртуальные регистры или области памяти, разморозка — простое продолжение работы виртуальных процессоров.
Для контейнеров задача усложняется. Заморозка контейнера — это сбор и остановка всех процессов, причём в течение этого действия неостановленные ещё процессы могут порождать новые. Сбор состояния контейнера — это сбор информации о графе объектов: процессов, файлов, сетевых соединений, памяти (которой в Линукс может быть 4 типа), и т. д. Количество объектов в графе на несколько порядков может превышать количество виртуальных устройств в машине, а процедура сбора их состояния не универсальна и зависит от вида и особенностей предоставляемого ядром интерфейса. Восстановление состояния контейнера — это восстановление состояния графа, причём возможности создания новых объектов в нём строго ограничены (задача по сложности сходна с задачей разбора контекстно-зависимой аттрибутной грамматики).
Кроме того, важно отметить, что при таком простом подходе размер собранного «состояния» может оказаться огромным из-за присутствия в нём содержимого памяти процессов. Это, в свою очередь, может привести к тому, что время передачи состояния займёт слишком много времени, в течение которого контейнер будет остановлен (заморожен). Для преодоления этого недостатка применяются две технологии — предварительного или последующего копирования памяти. Обе технологии возможно реализовать как для виртуальных машин, так и для контейнеров, но, в последнем случае, сложность будет выше. Связано это, в первую очередь, с тем, что память машины — это память одного процесса-гипервизора, а память контейнера — это память «разбросанная» по дереву процессов.
Несмотря на все сложности, технология миграции контейнеров была реализована в рамках проектов CRIU и P.Haul.
Примечания и отзывы
Plays:37
Comments:0