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

== Аннотация ==
;Докладчик: {{Speaker|Павел Емельянов}}
<blockquote>
Доклад о том, как делать живую миграцию виртуальной среды вообще, и контейнеров в частности.

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

== Видео ==
{{vimeoembed|134705192|800|450}}

{{youtubelink|pHVnqoUz5PM}}
{{letscomment}} -->

== Слайды ==
[[File:Живая миграция контейнеров — плюсы, минусы, подводные камни (Павел Емельянов, OSSDEVCONF-2015).pdf|left|page=-|256px]]

{{----}}

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

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

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

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

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

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

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

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

Несмотря на все сложности, технология миграции контейнеров была реализована в рамках проектов CRIU и P.Haul.
== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

{{fblink|1657548144498200}}                                          
{{vklink|5}}                                          
<references/>

[[Category:OSSDEVCONF-2015]]
[[Category:Open-source projects]]

<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2021-08-31T17:01:34.213618|vimeo_comments=0|vimeo_plays=37|youtube_plays=0}}