LINUX.ORG.RU

Вышла новая версия утилиты для «заморозки» и «разморозки» процессов в Linux — CRIU 2.0

 , ,


4

4

Доступен релиз инструментария для сохранения и восстановления состояния процессов в ОС Linux в пространстве пользователя — CRIU 2.0. При помощи утилиты CRIU (Checkpoint and Restore In Userspace) можно не только замораживать процессы на одной системе, но и сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции на другой машине без разрыва уже установленных сетевых соединений.

Проект CRIU имеет множество сценариев использования и используется для «живой» миграции Docker, LXC и Virtuozzo контейнеров.

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

Наиболее существенные изменения в новой версии:

  • исходный код проекта подготовлен под выделение отдельных компонент libsockcr и compel, о которых будет объявлено позднее;
  • сохранение состояния процесса пользователем без привилегий;
  • поддержка C/R для новой функциональности в ядре Linux.

Учитывая предыдущий опыт разработки CRIU, разработчики приняли решение изменить график выпуска новых версий и процесс разработки в проекте. После выпуска версии 2.0 в репозиторий добавили ветку devel, в которую будут попадать абсолютно все новые изменения. Основная ветка будет считаться стабильной, и изменения в нее будут добавлять только при абсолютной уверенности, что эти изменения не вносят никаких деградаций в существующую функциональность. Новые версии будут появляться каждый месяц из стабильной ветки. Дата выхода будет анонсирована чуть позднее.

>>> Подробности



Проверено: maxcom ()
Ответ на: комментарий от anonymous

вы про это «Доступен релиз инструментария для сохранения и восстановления состояния процессов в ОС Linux в пространстве пользователя» или это «сохранение состояния процесса пользователем без привилегий» ?

estet ()
Ответ на: комментарий от anonymous

Контейнерная виртуализация -> заморозили набор процессов, перекинули на другой хост -> разморозили

Естественно требует нетривиальной настройки, но, блин, кому сейчас легко?

Pinkbyte ★★★★★ ()
Ответ на: комментарий от anonymous

Увы, на деле оно пока для таких целей непригодно.
Близжайшая альтернатива - гиернация или запись состояния полной виртуальной машины с ядром. вроде vbox умеет.

mittorn ★★★★★ ()
Ответ на: комментарий от anonymous

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

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

В случае с полной системой (гибернация) это обычно работает, но доя отдельного процессса - беда.
я пытался мигрировать иксовае - получал bad mapping при восстановлении.
а вобще - это скорее всего возможно только при условии, что иксы остались те же и зависшее окно всё ещё на экране, а у приложения тот же адрес (что вроде неврзможно т.к после заморозки процесса он умирает и закрывает своп сокеты)

mittorn ★★★★★ ()

А каким образом возможна сама заморозка процесса, разделенного на потоки, хранимые и управляемые в ядре системы? Как возможно собрать процесс из потоков и затем обратно его «распараллелить»?

cazorla19 ()
Ответ на: комментарий от anonymous

Вы слышали о комнатах в KDE? Это что-то вроде рабочих столов, только процессы на одном рабочем столе «выключаются», а потом включаются по возвращению.

Я как-то пытался такое реализовать в FVWM, используя сигналы SIGSTOP и SIGCONT www.linux.org.ru/forum/desktop/8902361

Потом, когда процесс зависает, отжирая 100% процессора, а тебе «щя некогда», — посылаю ему SIGSTOP. Firefox любит зависать, обрабатывая JavaScript.

Spoofing ★★★★★ ()
Ответ на: комментарий от thriller

Запрещенный прием. Получится токмо с помощью Господней и при совместимости святых духов. Даем сигнал и вознося хвалу создателю хибернейтимся. Изымаем благодатный носитель из неблагодатной стойки и несем в новое святилище, где и запусчаем горение огня. Ву-а-ля! Профит!

adstudio ()
Ответ на: комментарий от Spoofing

kill -s SIGSTOP kill -s SIGCONT

После SIGSTOP может быть побочный эффект - если приложение использовало консоль, то она должна оставаться в том режиме как её установили до SIGCONT, иначе приложению может поплохеть.

alt-x ★★★★★ ()
Ответ на: комментарий от h31

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

tiandrey ★★★★ ()
Ответ на: комментарий от tiandrey

Расскажи, какие такие накладные расходы?
Старт виртуалки? У Интела был проект на основе KVM, там система за полсекунды стартовала. Производительность? На современных процессорах потери - считанные проценты. Память? С ballooning тоже не особо проблема.

h31 ★★★ ()
Ответ на: комментарий от h31

Операционная система в виртуалке должна запуститься? Должна. Память ей нужна? Нужна. Больше виртуалок запускаешь -> больше памяти уходит чисто на каждую виртуализируемую ОС.

Эмулировать работу железа нужно? Нужно, прямого доступа к железу в общем случае нет.

Потом идёт всякая двойная работа планировщиков (планировщик в реальной ОС и планировщик в виртуализируемой ОС работают), это плюс лишние переключения контекста.

Тут потери, там потери - кто-то может себе это позволить, а кто-то не может. Грубо говоря, у меня на этих «считанных процентах» потери производительности может ещё один контейнер работать на высоконагруженном сервере.

tiandrey ★★★★ ()
Ответ на: комментарий от tiandrey

Да я и не спорю, что виртуалки работают медленнее чем хост-система. Ну выиграем мы немного в производительности, зато серьёзно проиграем в безопасности (в первую очередь), разнообразии ОС в контейнерах и потенциально стабильности. Собственно ни LXC, ни Docker не гарантируют полной изоляции контейнеров. Docker вообще решето, так как docker-демон всегда работает от рута и любая его уязвимость становится дырищей в безопасности.

Грубо говоря, у меня на этих «считанных процентах» потери производительности может ещё один контейнер работать на высоконагруженном сервере.

Числа, друг мой, числа.

h31 ★★★ ()
Ответ на: комментарий от h31

Всё зависит от того, какую цель ты преследуешь. Разные цели - разные решения.

Хочешь поделиться ресурсами сервера со внешними клиентами (VPS, например) - юзай виртуалки, они тебе безопасность дадут, чтобы не похачили тебя злые юзвери.

Хочешь для своих внутренних нужд ресурсы сервера поделить и не потерять производительность - юзай контейнеры.

tiandrey ★★★★ ()
Ответ на: комментарий от anonymous

Так они по таймауту отвалятся. Шустрости ни в каком из случаев не будет. И если железо серверов идентичное, то все вполне себе заводится, божечка помогает (не знаю что да как для серваков с мульоном юзеров онлайн и тьмой сервисов, но для небольшой сети предприятия со стандартным набором ламп_пг_смб_ишокойчо - вполне себе). Время пришло.

adstudio ()