На Хабре уже выходила статья, приуроченная к выходу CRIU 0.1. Эта версия продукта была недостаточно функциональна и скорее демонстрировала работоспособность уникальной технологии, разрабатываемой компанией Parallels.
С тех пор была проделана большая работа и возможности CRIU вплотную приблизились к главной цели: сохранение и восстановление Linux контейнера. Несмотря на то, что пока поддерживается только пустой контейнер со стандартным набором процессов, есть все основания полагать, что проект обречён на успех.
А если вас не интересуют контейнеры, то вам, возможно, понравится ещё одна новая возможность — поддержка сохранения и восстановления псевдотерминалов, для иллюстрации которой хорошо подходит screen сессия. Для начала необходимо запустить несколько приложений, например top и vim и отключиться от сессии. После сохранения и восстановления screen-сессии и дочерних процессов при помощи CRIU можно снова подключиться к screen-сессии и убедиться, что запущенные процессы сохранили своё состояние. Для пущей убедительности, между моментами сохранения и восстановления можно перезагрузить компьютер или восстановить screen-сессию на другом машине.
По ссылке доступен видео-ролик, демонстрирующий, как CRIU сохраняет и восстанавливает состояние vncserver-а co screensaver'ом, к которому подключён клиент:
Этот пример примечателен тем, для во время сохранения и восстановления состояния сервера восстанавливается также и соединение с клиентом. То есть для клиента всё происходит прозрачно (за исключением короткой задержки в обслуживании).
Я решил немного разбавлять статьи о новых версиях CRIU интересными моментами из процесса разработки проекта. Сегодня я расскажу о тестировании и о формате дамп-файлов.
Понятно, что для успеха проекта не обойтись без качественного тестирования. Поэтому мы решили, что автоматическое тестирование должно быть внедрено на самых ранних этапах разработки. За основу были взяты наработки, тестирующие ту же функциональность в проекте OpenVZ. После доработки в рамках проекта мы создали комплексную систему для unit-тестирования. Каждый тест запускается отдельно и проходит 3 стадии: подготовка окружения, «демонизация» и ожидание сигнала (который необходимо послать извне после сохранения и восстановления теста), проверка результата. Тесты условно разделены для две группы. Первая группа — это статические тесты, которые подготавливают некое постоянное окружение или состояние и «засыпают» в ожидании сигнала. Вторая группа — потоковые тесты, которые постоянно меняют своё состояние и/или окружение (к примеру пересылаются данные через TCP соединение).
Сегодня система unit-тестирования CRIU насчитывает порядка 70 отдельных тестовых программ. При этом система позволяет запускать каждый из тестов как в текущем, так и в изолированном пространстве имён (то есть фактически в контейнере).
Архитектурные аспекты программы необходимо тщательно обдумать на этапе проектирования, так как потом менять что-либо будет очень сложно. Формат сохранения данных был одним из таких архитектурных аспектов для CRIU. Было необходимо решить две главные задачи, а именно:
Мы рассмотрели все наиболее распространённые и популярные форматы и остановились на protobuf (Protocol Buffers), разработанный компанией Google, так как он поддержан библиотеками для разных языков программирования и его формат позволяет добавлять новые поля при поддержке обратной совместимости.
К сожалению, иногда приходится не только добавлять новые поля, но и менять структуру данных. Поэтому файлы дампов версифицированны.
Компания Parallels активно развивает проект CRIU и наша следующая важнейшая цель — научиться сохранять и восстанавливать состояние OpenVZ-контейнера. Это позволит избавиться от поддержки миграции OpenVZ-контейнера в ядре, высвободить ресурсы разработчиков и тем самым ускорить развитие проекта OpenVZ.
habrahabr.ru/post/148413
ru.wikipedia.org/wiki/CRIU
lwn.net/Articles/517079
criu.org/LXC
С тех пор была проделана большая работа и возможности CRIU вплотную приблизились к главной цели: сохранение и восстановление Linux контейнера. Несмотря на то, что пока поддерживается только пустой контейнер со стандартным набором процессов, есть все основания полагать, что проект обречён на успех.
А если вас не интересуют контейнеры, то вам, возможно, понравится ещё одна новая возможность — поддержка сохранения и восстановления псевдотерминалов, для иллюстрации которой хорошо подходит screen сессия. Для начала необходимо запустить несколько приложений, например top и vim и отключиться от сессии. После сохранения и восстановления screen-сессии и дочерних процессов при помощи CRIU можно снова подключиться к screen-сессии и убедиться, что запущенные процессы сохранили своё состояние. Для пущей убедительности, между моментами сохранения и восстановления можно перезагрузить компьютер или восстановить screen-сессию на другом машине.
По ссылке доступен видео-ролик, демонстрирующий, как CRIU сохраняет и восстанавливает состояние vncserver-а co screensaver'ом, к которому подключён клиент:
Этот пример примечателен тем, для во время сохранения и восстановления состояния сервера восстанавливается также и соединение с клиентом. То есть для клиента всё происходит прозрачно (за исключением короткой задержки в обслуживании).
Несколько особенностей разработки CRIU.
Я решил немного разбавлять статьи о новых версиях CRIU интересными моментами из процесса разработки проекта. Сегодня я расскажу о тестировании и о формате дамп-файлов.
Unit-тесты
Понятно, что для успеха проекта не обойтись без качественного тестирования. Поэтому мы решили, что автоматическое тестирование должно быть внедрено на самых ранних этапах разработки. За основу были взяты наработки, тестирующие ту же функциональность в проекте OpenVZ. После доработки в рамках проекта мы создали комплексную систему для unit-тестирования. Каждый тест запускается отдельно и проходит 3 стадии: подготовка окружения, «демонизация» и ожидание сигнала (который необходимо послать извне после сохранения и восстановления теста), проверка результата. Тесты условно разделены для две группы. Первая группа — это статические тесты, которые подготавливают некое постоянное окружение или состояние и «засыпают» в ожидании сигнала. Вторая группа — потоковые тесты, которые постоянно меняют своё состояние и/или окружение (к примеру пересылаются данные через TCP соединение).
Сегодня система unit-тестирования CRIU насчитывает порядка 70 отдельных тестовых программ. При этом система позволяет запускать каждый из тестов как в текущем, так и в изолированном пространстве имён (то есть фактически в контейнере).
Формат файлов с данными
Архитектурные аспекты программы необходимо тщательно обдумать на этапе проектирования, так как потом менять что-либо будет очень сложно. Формат сохранения данных был одним из таких архитектурных аспектов для CRIU. Было необходимо решить две главные задачи, а именно:
- формат должен быть расширяемым с возможностью сохранения обратной совместимости;
- формат должен быть распространённым, чтобы обеспечить простой доступ к данным из других приложений.
Мы рассмотрели все наиболее распространённые и популярные форматы и остановились на protobuf (Protocol Buffers), разработанный компанией Google, так как он поддержан библиотеками для разных языков программирования и его формат позволяет добавлять новые поля при поддержке обратной совместимости.
К сожалению, иногда приходится не только добавлять новые поля, но и менять структуру данных. Поэтому файлы дампов версифицированны.
Заключение
Компания Parallels активно развивает проект CRIU и наша следующая важнейшая цель — научиться сохранять и восстанавливать состояние OpenVZ-контейнера. Это позволит избавиться от поддержки миграции OpenVZ-контейнера в ядре, высвободить ресурсы разработчиков и тем самым ускорить развитие проекта OpenVZ.
habrahabr.ru/post/148413
ru.wikipedia.org/wiki/CRIU
lwn.net/Articles/517079
criu.org/LXC