Опубликован выпуск инструментария CRIU 3.18 (Checkpoint and Restore In Userspace), предназначенного для сохранения и восстановления процессов в пространстве пользователя. Инструментарий позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Код проекта распространяется под лицензией GPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59024
Каким образом это нововведение возможно применить в девопсе?
Какое именно? И зачем именно в девопсе? Как мне видится невозможность сдампить GUI приложения несколько ограничивает применимость на десктопе, но всё же. Да и вроде говорили что для иксов анриал, но для вейланда возможно. Так уж получается, что какой-нибудь блендер иногда неплохо бы остановить по разным причинам.
Правильная, ядерная (никаких изменений в системном и прикладном ПО не требуется) реализация SSI кластера балансировки нагрузки между узлами (прозрачная миграция процессов) и правильная, реализация сохранения и восстановления процессов для Linux (прозрачное восстановление абсолютно всех процессов,включая все графические процессы): https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../Исходники: https://sourceforge.net/projects/monitoring/files/hardened-o.../
> и вроде говорили что для иксов анриалЛгут тебе. Выше ссылки на LiveCD и исходники ядра Linux, все оттестировано и работает.
Жаль, не смогли протолкнуть эти, ПРАВЕЛЬНЫЕ, технологии в официальное ядро. Победила красная шляпа с cgroups, namespaces, systemd+dbus+polkit.
Дела давно минувших лет - преданье старины глубокой.
> и вроде говорили что для иксов анриал, но для вейланда возможноНасколько помню события 15-летней давности там разрабы поругались с технологиями cgroup, namespaces если их выкинуть с ядра, то уже есть реализация и для X11: https://sourceforge.net/projects/monitoring/files/hardened-o.../
А вейленд такое же нинужгое зло как и сыстемды с дбас.
> А вейленд такое же нинужгое злоА есть какой-то другой способ окна рисовать?
>А есть какой-то другой способ окна рисовать?Ты не поверишь…
X11, он более универсален, поддерживает сеть, многоголовость (DMX). Хотя и DMX в иксах недавно похерели. Наверно производители железа приплатили.
> X11, он более универсален, поддерживает сеть, многоголовость (DMX). Хотя и DMX в
> иксах недавно похерели. Наверно производители железа приплатили.Его же усиленно выпиливают и везде рекомендуют от него отказываться.
Было бы неплохо смигрировать вживую контейнер с одной машины на другую, например.
М?
Прикладники научились писать софт, который не требует перезапусков раз в эн времени?
Или 640 петабайт оперативы уж точно должно хватить всем?
А что драйверов на расте писать не собираются? или системы не состоят из контейнеров внутри виртуалок, потому что никто низачто не отвечает?
Жду пока в Proxmox VE добавят живую миграцию LXC контейнеров. Ранее в Promox VE работала живая миграция
OpenVZ контейнеров. После того как разработчики в Proxmox VE добавили LXC вместо OpenVZ, то они сломали живую миграцию контейнеров.
Для QEMU-контейнеров работает.
LXC оборачивает то что умеет ядро с cgropus.
Там некому (пока?) контролировать состояние памяти (чтобы построить поверху миграцию). Максимум что можно — зафризить SIGSTOP и потом тащить всю память, до победного.
Второй проблемой будет перенос состояния CPU в новую точку запуска контейнера. И вот его в CRIU как-то сумели решить, как я понял из новости.
* "Тапки", fd etc. не упоминаю т.к. в целом тривиально.
Я minecraft приостанавливал посылая SIGSTOP через htop, чтоб проц не грузил, когда на паузе
> через htopСотонист, не иначе.
# pkill -STOP -f XXX
# pkill -CONT -f XXX
А что происходит с файловыми дескрипторами? Например, программа пишет что-то в файл на нфс-шаре, мы её резко снэпшотим. Потом - восстанавливаем на другой машине с такой же нфс-шарой. Сможет ли она продолжить писать в тот же файл?
Также сокеты иксов и пульсов. Допустим я хочу перенести граф-приложение с машины на машину. Persistent storage - тот же нфс.
Отслеживание открытых файлов и маппинг на удаленной машине?
Дамп небольших файлов целиком с переносом образа процесса на удаленную машину?
Резолв соединений к БД на уровне внешних процессов-брокеров?> Потом - восстанавливаем на другой машине с такой же нфс-шарой. Сможет ли она продолжить писать в тот же файл?
Если пути и окружение совпадает - то почему бы и нет? Главное - синхронизировать состояние целефого файла, гарантируя, что не было разрушающих формат дозаписей, т.к. снять мы можем в произвольный момент времени.
> А что происходит с файловыми дескрипторами?
Это как раз наименьшая проблема. Тут гораздо большая проблема с окружением (которое по умолчанию может быть очень отличным от машины, на которой сняли снапшот).
это ж как мне кажется напоминает ceph из proxmox`a
> Тут гораздо большая проблема с окружением (которое по умолчанию может быть очень отличным от машины, на которой сняли снапшот).Допустим у нас контейнер, содержимое которого рсинхаем перед расснапшочиванием.
Главное чтобы файл за это время измениться не успел.
Иначе будет ПРИКОЛЬНО111!!!
кеши сделабт много прикольного
уже умеют много прикольного без всяких нововведений
Фантом ОС изобретают :)
Нет. Иначе повторят его судьбу.
Лол, Фантому надо было родиться на западе, чтобы эпфийцы заценили его :) как и все остальное давным-давно изобретенное, но не оцененное.
> в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений.Это что за чёрная магия? Как это работает?
>> в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений.
> Это что за чёрная магия? Как это работает?За натом работает, видимо. У меня отваливались по таймауту. Если программа рассчитана на обновление соединения то всё будет работать при этом, а так вообще никто ничего не заметит.
Да а в чём магия-то? Дескриптор сокета и прочее переносится со всей сопутствующей инфой.
Если удалённая сторона стаймаутится не успеет - всё будет ок. У меня так SSH-сеансы после часовой отлучки в хибернейт поднимаются.
т.е если подобную штуку запустить и на другом компе, то получится что к одному удалённому источнику установлено 2 одинаковых подключения с разных машин ?И как тогда они будут одинаковыми, если у новой машины даже адрес будет другой ?
IP-адрес тоже придётся переносить
А так - да, могут даже смешаться до степени смешения, и будет весело
Удалённому источнику там пофиг, что у кого установлено, он тупо пакетики получает с энным адресом
В переносе ip адреса как минимум магия.
Ну и так по мелочи.
А в чём магия-то?
Снял IP на одной системе, поднял на другой.
Или роутинг изменил, а IP на lo.
Идея хорошая, а вот с реализацией проблемы. После нескольких заморозок процесс начинает глючить. Лучшее решение - это использование виртуализации и снапшотов.
Вообще сама идея мне честно говоря нравится. Можно перетащить большой долгоживущий процесс с машины на машину и машину обслужить.Другое дело, что лично мне оно вообще почти не надо, потому что я строго соблюдаю принцип "одна машина - одна задача" + дублирование/кластеризацию, а контейнерщикам со всякими мокросервисами не надо вообще - их проще грохнуть и перезапустить. Но вот когда у тебя есть какая-то махровая проприетарь или щастье, которое ни задублировать, ни погасить на время обслуживания хост-системы, может быть интересно.
Надо с астериском попробовать - кто-нибудь пробовал?
Э, зачэм астериск? © анекдот про гусей.
Немного не понял смысл упражнения. Не, ну перетащить "прогретую" jvm с одного физ. хоста (без гипервизора-прослойки потому что HFT /а почему тогда java?/ или ещё какая фигня) наверное ок.
Но астер-то зачем вот так???
Это смотря что у вас на астериске.
У нас есть больничные кол-центры, которые даже блин не раскидать по нодам - там столько стейта, что обмениваться этим стейтом между узлами синхронно очково - малейший чих, и звонки встанут. Обновлять хост-систему на таких нодах - очень лютая тема.
> У нас есть больничные кол-центры, которые даже блин не раскидать по нодамДа, "положить" дежурную больницу — отдельная песТня, перед заходом на "посадку".
Я такие штуки прокладывал xen (ну и qemu в DM, как без него). Потому что там легче доказать свою невиноватость. (И такой подход впоследствии отлично зашёл в PCI-DSS.)Но, т.к. x86-железо (да хотя бы и ARM|Power|etc., протекающему PJSIP [20 байт на входящий по последним замерам] вообще пофиг) в нашей унылой реальности "складывается" примерно всегда. Проектировал так чтобы "сложившийся" узел оборвал текущие звонки. (В этом месте никого не привлекут если все регламенты проведены по журналам.) А новые сразу шли на резерв. Чего и вам желаю.
* Если в системе нет регламента для штатного (без сбоев в обслуживании) вывода из нагрузки, то я даже не знаю что сказать…
Идея хороша, хотя бы для обновления ядра без остановки компа ...
Продумать, чтоб новое ядро перехватывало процессы и вуаля - правильные 24/7
Что только не делают. лишь бы Plan9/Inferno не пилить
А на них так можно разве?
Ждем в proxmox для ha lxc контейнеров
Почему нельзя просто скопировать machine1:/proc/$pid1 на machine2:/proc/$pid2?
В демке они игры на лету между датацентрами по планете перекидывали и игра не осианавливалась