CRIU (application Checkpoint/Restore In Userspace) — это амбициозный, быстро развивающийся проект, который позволяет сохранить состояние программы в виде контрольной точки, и впоследствии возобновить работу приложения с этой точки.
Возможности применения программного обеспечения для создания контрольных точек достаточно разнообразны. К примеру, OpenVZ использует похожий механизм для “живой” миграции. Parallels Virtuozzo использует подобный механизм для быстрого возобновления работы контейнеров после обновления ядра. CRIU уже используется в высокопроизводительных кластерах для для сохранения промежуточных результатов вычислительных процессов, используемых для возобновления работы приложения в случае сбоя.
В этой статье рассказывается, как CRIU сохраняет и восстанавливает состояние программы, и почему этот проект может быть успешнее своих предшественников.
Немного истории
CRIU — это далеко не первая попытка реализовать некий механизм сохранения и восстановления программ в Linux. Существует как минимум две рабочие реализации C/R: OpenVZ и проект linux-cr, лидером которого является Oren Laadan.
Проблема обоих проектов в том, что они реализуют весь C/R практически полностью в пространстве ядра. Однако эти проекты не стали частью основного ядро Linux из-за большого объёма и сложного кода.
Лидер команды разработчиков OpenVZ Павел Емельянов предложил изменить сам подход к C/R и перенести основную работу в пространство пользователя. Сообщество хорошо приняло эту идею и появился проект CRIU.
Сохранение состояния приложения
Приложение может состоять как из одного, так и из множества запущенных процессов. CRIU поддерживает оба типа.
Для получения информации о состоянии процесса первое, что приходит на ум, это использование механизма, которым пользуется отладчик (ptrace). Но он не предоставляет всей информации. Часть состояния процесса можно почерпнуть из файловой системы procfs и системного вызова prctl, однако и этого недостаточно.
Для получения недостающей информации в проекте CRIU был использован механизм внедрения исполняемого кода в процесс (т.н. паразитный код), который был разработан и любезно предоставлен Tejun Heo, одним из основных на сегодняшний день разработчиков ядра Linux.
Восстановление состояния приложения
Для восстановления приложения с контрольной точки необходимо сначала создать дерево его процессов. Для этого в ядре Linux был разработан отдельный механизм для создания процессов с заданными идентификаторами. После старта каждый процесс восстанавливает свою память, открытые файлы, сокеты, пайпы, IPC и т д.
Однако на самом деле всё не так просто, ведь ресурсы могут быть общими для нескольких процессов.
Регионы адресного пространства процесса могут быть уникальны (MAP_PRIVATE) либо доступны одновременно несколькими процессами (MAP_SHARED). Первый тип восстанавливается достаточно просто (если не задумываться о технологии “copy on write” — она остаётся за скобками этой статьи).
В чем же проблема во втором варианте? Если у нас регион адресного пространства отображается в файл, то все в порядке — для восстановления такого куска адресного пространства можно использовать стандартные механизмы Linux.
Read more: Habrahabr.ru
QR: 