LINUX.ORG.RU

CRIU 3.4

 


4

3

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

Нововведения:

  • Поддержка архитектуры s390x.

Улучшения:

  • При падении восстановленных процессов записывается более подробный лог.
  • Слияние множества образов содержащих информацию о файлах в один большой files.img
  • Когда вспомогательная утилита не работает (ip, iptables, tar), ее имя выводится в лог.

Основные исправления:

  • Ошибка компиляции на новых glibc (ucontext_t)
  • Падение вспомогательных утилит может «заморозить» процесс восстановления.
  • Переменные в makefile не настраивались для сборки дистрибутива.
  • Наличие SIT (ipv6-to-v4 tunnel) на хосте блокирует дамп контейнеров.

>>> Github проекта

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

★★★★

Проверено: jollheef ()

Вот бы из этого сделали штуку, чтобы я на десктопе закрыл приложение и открыл на том же месте с теми же документами и в том же состоянии, совсеми ундами и прочее. И чтобы созранялось это или локально или на сервере и на другом компе продолжить. Иногда так не хватает.

Deleted ()

Этот проект в virtuozzo пилят, несколько я знаю.

beck ()

Штука крутая и нужная.

Гуёвые проги оно научилось восстанавливать?

Ivan_qrt ★★★★★ ()

О, оно похоже умеет сохранять и восстанавливать процессы, запущенные через mpi. Там даже как один из сценариев сохранение состояния числодробилки каждые N часов чтобы при сбое не потерять результаты длинных расчётов. Надо опробовать.

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

Судя по информации на wiki, если ещё не научилось, то собирается.

Quasar ★★★★★ ()

А восстановить расчеты на видео-картах оно может?

anonymous ()

Интересно как люди это используют. Особенно если оно не поддерживает графические приложения. Возможно, одним из применений была бы прозрачная миграция задач в клауде (скажем, для балансировке), но работа с сокетами и их «восстановлением» лично у меня не внушает доверия.

У меня была задумка использовать cryopid для приложения которое долго инициализируется (чтобы можно было его быстро разморозить вместо нового запуска и инициализации), но оно не взлетело на моей системе.

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

https://xakep.ru/2017/05/30/virtuozzo-work-for-unixoid/#toc04.

Павел Емельянов, главный архитектор Virtuozzo

... расскажу историю появления CRIU. Изначально все модификации Virtuozzo не шли в основную ветку ядра (так называемый upstream) — то есть в ядро Linux. Они были открытыми, но это, по сути, у нас была своя собственная ветка ядра. В какой-то момент мы начали отправлять всю эту функциональность Линусу Торвальдсу. Так появились подсистемы cgroups и namespaces, которыми сейчас все пользуются. А еще был третий компонент — живая миграция, которая у нас была целиком в ядре. Чем-то похожим занимались не только мы, но и IBM и еще несколько исследователей из Колумбийского университета.

Несколько лет команда разработчиков ядра не принимала эти патчи: все говорили, что это слишком большая подсистема, которая выворачивает наизнанку все ядро. Вы, мол, пока работайте, но отдельно от нас. Постепенно мы стали вытаскивать некоторые компоненты наружу, в user space. То есть была утилита, которая дергала один-единственный вызов в ядре, типа восстановить или сохранить. Но вытащить все в user space невозможно, и мы продолжали писать патчи для ядра.

В какой-то момент Линусу все это надоело, и он сказал: «Все, дальше можете даже не пытаться, я это брать не буду». Тогда я решил попробовать вынести в пользовательское пространство максимум. И написал прототип, который впоследствии и превратился в CRIU. Не помню, сколько в нем было строк, но даже тысячи, кажется, не набиралось. Он сохранял и восстанавливал программку, которая работала с открытым файлом. У нее не было ни сокетов, ни пайпов, ни сигналов, никаких хитрых отображений в памяти — несколько небольших патчей для получения о процессе то ли памяти, то ли регистров и для создания процесса с заданным идентификатором (PID). Это можно было сделать в режиме отладчика, но тогда операции происходили бы побайтово, а мне была важна скорость. В общем, в результате появилось два патча и та малюсенькая программулинка. Народ посмотрел и решил, что это интересно — всего два патча, а возможностей открывается масса. Попросили развить эту идею.

Тут началась та же история, что и с попыткой занести все в ядро. Я добавил что-то еще — пайпы в том числе. Потом мне сказали: «Зачем тебе модифицировать proc-файл для доставания памяти, доставай как отладчик». Мы переделали это, я тогда подключил к работе еще одного сотрудника.

По сути, это был мой собственный проект, потому что в Virtuozzo никто не считал, что мой план сработает, а я тратил на это много времени. Мне советовали оставить это дело: раз не идет в ядро, значит, будем реализовывать при помощи модулей, нам не сложно. В общем, года два никто не принимал эту затею всерьез. А потом случился какой-то переломный момент.

На одной из конференций ко мне подошел один известный мейнтейнер ядра — Эндрю Мортон. Он спросил: «Долго вы еще будете всем этим заниматься-то? Может, релиз сделаете, я бы все эти патчи тогда взял и Линусу сдал в ядро». Они постоянно расширяют ядерный интерфейс, и наши наработки оказались бы полезными для всех.

Так мы сделали CRIU 0.1. Мортон влил патчи в ядро, об этом были написаны статьи, я выступил на конференции с докладом. Тогда в Virtuozzo поняли, что, видимо, мы наконец-то выкинем из нашего ядра checkpoint restore (это та самая живая миграция) и перейдем на мой вариант. Так CRIU перестал быть моим pet project и стал поддерживаться официально.

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

Ну что-ж, удачи парням. Но это как-то идёт в разрез с современной философией облаков (stateless, всё такое). Уверен, своя ниша у проекта найдётся («если пилят значит кому-то нужно»), но очень узкая, имхо.

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

раз не идет в ядро, значит, будем реализовывать при помощи модулей, нам не сложно

А почему бы изначально не следовать этой идеи? Может кто-нибудь объяснить, зачем все пытаются протащить всё в ядро? Чем так плоха идея модульности?

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

Поддержка же

Может кто-нибудь объяснить, зачем все пытаются протащить всё в ядро?

Если втащить свой код в ядро, то его интерфейс постараются не сломать при следующем обновлении и воспевании мантры «stable API nonsense». Если не втащить, то даже стараться не станут.

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

Монолитный Linux

Чем так плоха идея модульности?

Идея-то хороша. Вот только на практике Linux — монолитное ядро. Развивать модуль вне ядра затратно, потому что в любой момент фоннаты «stable API nonsense», сломают API.

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

Ну вот у меня сервер, в нём драйвер проприетарный. Есть версии только для дистрибутивных ядер RHEL, Ubuntu 12.04, SLES. Причём даже не для всех версий, обновлю случайно ядро, а оно уже не загрузится. Если бы этот драйвер был в ядре, таких проблем не было бы в принципе: ставь что хочешь, обновляй что хочешь. Причём, очевидно, в какой-то момент разработчик перестанет обновлять этот драйвер и куча серверов останутся без обновлений, по сути можно только выкинуть и всё из за проприетарного драйвера.

Legioner ★★★★★ ()

Годный проект, очень годный. Рад, что проект развивается.

lucentcode ★★★★★ ()

без разрыва уже установленных сетевых соединений

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

quester ()

Вопрос от нуба: есть ли более низкоуровневые (например, аппаратные) реализации выгрузки абсолютно всего из озу (и еще наверно регистров) на диск и обратной загрузки?

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

Как-как... Берут - и восстанавливают сокеты с их состоянием. Они ж там возможность исполнения паразитного кода процессом в ядро пропихнули не просто так.

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

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

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

Вот бы из этого сделали штуку, чтобы я на десктопе закрыл приложение и открыл на том же месте с теми же документами и в том же состоянии, совсеми ундами и прочее. И чтобы созранялось это или локально или на сервере и на другом компе продолжить. Иногда так не хватает.

в общем случае, очень трудно реализуемо. одно дело процесс в памяти, и другое - какие еще ресурсы задействованы (файлы, сокеты, другие процессы, итдитп)

anonymous ()

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

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

Как сохранение состояния виртуальной машины, только в железе.

anonymous ()

без разрыва уже установленных сетевых соединений

А как такое вообще возможно? Соединение ведь может быть разорвано другой стороной, обнаружившей, что сервис не откликается, например. Или я чего-то не понимаю?

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

А как такое вообще возможно? Соединение ведь может быть разорвано другой стороной, обнаружившей, что сервис не откликается, например.

А может быть и не разорвано. У меня ssh-сессии спокойно работают после многочасовых суспендов ноутбука.

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

Интересно... Я думал, там какой-нибудь таймаут по неактивности стоит...

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

Насколько я помню, это настраивается киданием пустых пакетиков раз в нное число минут.

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

Облака - это маркетинговый проходняк. Сдохнут как и появились.

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

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

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

По идее, если успеть до таймаута keep-alive, и если к примеру шлюз «знает», куда переехала виртуалка, то вполне возможно. Клиент получит лаг, но работа не прекратится.

Как-то так я это вижу.

Radjah ★★★★★ ()
Ответ на: Поддержка же от Camel

Если втащить свой код в ядро, то его интерфейс постараются не сломать при следующем обновлении и воспевании мантры «stable API nonsense». Если не втащить, то даже стараться не станут.

А в ядре перенесут в staging, сделают видимость, что собирается, но гарантии, что оно работает всё равно не будет. Если посыпятся жалобы, что не работает, код просто вынесут из ядра.

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

Облака - это маркетинговый проходняк. Сдохнут как и появились.

У меня для тебя плохие новости :). Ну, сам увидишь со временем...

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

облака уже сдохли, лечись от аутизма

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

Удовлетвори моё любопытство, в чём удовольствие писать тот тупняк что ты написал? Тебе нравится называть других аутистами? Или у тебя какое-то заболевание типа синдрома Туретта, но в письменной форме?

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

Облака в следствии регулярных тотальных факапов с потерей данных и потерь денег их клиентами завоевали соответствующую репутацию. Что то в облаке делают онли полные лошары.

anonymous ()

Краткая выжимка из https://criu.org/Usage_scenarios

  • Живая миграция контейнеров-то для чего это создавалось. Контейнер зачекпоинтился, образ перенесли на другую машину, там восстановили. Как я понимаю, при этом сценарии «без разрыва сетевых соединений» подразумевается, что между выключением старого контейнера и включением нового должно пройти совсем немного времени, тогда это взлетит (юзер заметит просто кратковременное зависание). Думаю, это киллер-фича и хотя она ещё не откатана, но такого нет ни у кого насколько я знаю.
  • Ускорение загрузки сервисов, которые обычно загружаются не быстро. Например, мы делаем чекпоинт в точке, когда сервис уже стартанул, затем при необходимости просто запускаем сервис из чекпоинта вместо запуска его с нуля. Например, VNC сервер+эклипс удалось запустить за 1.5 секунды вместо 30, это грубая оценка и все цифры взяты с сайта разработчика.
  • Бесшовное обновление ядра-тут я не осилил перевести, так как не знаю, что такое kexec

    When replacing a kernel on a box we can do it without stopping critical activity. Checkpoint it, then replace the kernel (e.g. using kexec) then restore services back. In a perfect world the applications memory shouldn't be put to disk image, but should rather be kept in RAM.

  • Балансировка сетевой нагрузки. Кусок проекта, который отвечает за TCP repair можно использовать, чтобы перераспределить запросы на уровне приложения на другой сервер.
  • High Performance Computing — опять-таки распределение нагрузки и своеобразные бэкапы
  • Сохранение в играх, где сохранений нет.
  • Дебаг продакшена без ущерба для продакшена (содрал процесс в другую виртуалку и насилуй его как хош)

Вроде как что-то и для иксов планируется, но будет делаться скорее всего в последнюю очередь, т.к. сложность Х-сервера и комерчески малоинтересно.

Pyzia ★★★★ ()
Последнее исправление: Pyzia (всего исправлений: 1)
Ответ на: комментарий от Quasar

Облака - это маркетинговый проходняк. Сдохнут как и появились.

Боюсь, что ты не прав. Маркетинговое говно - да, но это тот сорт говна, который слишком выгоден корпорациям.

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

А теперь уже попёрли онлайн-видеоредакторы, и это означает, что всё - дно пробито.

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

закрыл приложение и открыл на том же месте с теми же документами и в том же состоянии, совсеми ундами и прочее

В Vim это давно уже есть.

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

Здо́рово. А в нём можно уже фотки обрабатывать, чертить и снимать фильмы?

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

фотки обрабатывать, чертить и снимать фильмы

Может это уже есть в Emacs?

r3lgar ★★★★★ ()

Годно, в DragonFlyBSD такая фишка из коробки

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

Годно, в DragonFlyBSD такая фишка из коробки

пруфы?

Novel ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.