forum.opennet.ru - "Выпуск CRIU 3.18, системы для сохранения и восстановления состояния процессов в Linux" (46)

"Выпуск CRIU 3.18, системы для сохранения и восстановления состояния процессов в Linux"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск CRIU 3.18, системы для сохранения и восстановления состояния процессов в Linux"	+/–
Сообщение от opennews (??), 24-Апр-23, 23:03
Опубликован выпуск инструментария CRIU 3.18 (Checkpoint and Restore In Userspace), предназначенного для сохранения и восстановления процессов в пространстве пользователя. Инструментарий позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Код проекта распространяется под лицензией GPLv2... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59024
Ответить \| Правка \| Cообщить модератору

Оглавление

Каким образом это нововведение возможно применить в девопсе , Аноним (1), 23:03 , 24-Апр-23, (1) –9

Какое именно И зачем именно в девопсе Как мне видится невозможность сдампить G, Аноним (2), 23:11 , 24-Апр-23, (2) +3

Правильная, ядерная никаких изменений в системном и прикладном ПО не требуется , Аноним (21), 07:12 , 25-Апр-23, (21) –2
Лгут тебе Выше ссылки на LiveCD и исходники ядра Linux, все оттестировано и раб, Аноним (21), 07:19 , 25-Апр-23, (22) +2

Дела давно минувших лет - преданье старины глубокой , xoy (??), 21:45 , 11-Май-23, (69)

Насколько помню события 15-летней давности там разрабы поругались с технологиями, Аноним (21), 07:24 , 25-Апр-23, (23)

А есть какой-то другой способ окна рисовать , Илья (??), 19:17 , 26-Апр-23, (58)

Ты не поверишь 8230 , AlexYeCu (ok), 23:59 , 26-Апр-23, (60)
X11, он более универсален, поддерживает сеть, многоголовость DMX Хотя и DMX в, Аноним (63), 08:45 , 27-Апр-23, (63) –1

Его же усиленно выпиливают и везде рекомендуют от него отказываться , Илья (??), 17:34 , 01-Май-23, (68)

Было бы неплохо смигрировать вживую контейнер с одной машины на другую, например, Аноним (7), 23:42 , 24-Апр-23, (7) +4

М Прикладники научились писать софт, который не требует перезапусков раз в эн в, Dzen Python (ok), 23:57 , 24-Апр-23, (12)

А что драйверов на расте писать не собираются или системы не состоят из контейн, 48 (?), 00:40 , 25-Апр-23, (14)

Жду пока в Proxmox VE добавят живую миграцию LXC контейнеров Ранее в Promox VE , Ivan (??), 11:16 , 25-Апр-23, (40) +1

Для QEMU-контейнеров работает , ABATAPA (ok), 16:40 , 25-Апр-23, (48)

LXC оборачивает то что умеет ядро с cgropus Там некому пока контролировать со, PnD (??), 16:23 , 26-Апр-23, (54)

Я minecraft приостанавливал посылая SIGSTOP через htop, чтоб проц не грузил, ког, Аноним (4), 23:38 , 24-Апр-23, (4) +3

Сотонист, не иначе pkill -STOP -f XXX pkill -CONT -f XXX, PnD (??), 16:41 , 26-Апр-23, (55)

А что происходит с файловыми дескрипторами Например, программа пишет что-то в ф, Аноним (7), 23:41 , 24-Апр-23, (6)

Отслеживание открытых файлов и маппинг на удаленной машине Дамп небольших файлов, Dzen Python (ok), 23:56 , 24-Апр-23, (11) +1

это ж как мне кажется напоминает ceph из proxmox a, Аноним (18), 05:53 , 25-Апр-23, (18)
Допустим у нас контейнер, содержимое которого рсинхаем перед расснапшочиванием , Аноним (24), 08:24 , 25-Апр-23, (24)

Главное чтобы файл за это время измениться не успел Иначе будет ПРИКОЛЬНО111 , Tron is Whistling (?), 08:42 , 25-Апр-23, (26)

кеши сделабт много прикольногоуже умеют много прикольного без всяких нововведени, Олег (??), 21:33 , 28-Апр-23, (65)

Фантом ОС изобретают , Sw00p aka Jerom (?), 23:47 , 24-Апр-23, (8)

Нет Иначе повторят его судьбу , Аноним (24), 08:24 , 25-Апр-23, (25)

Лол, Фантому надо было родиться на западе, чтобы эпфийцы заценили его как и в, Sw00p aka Jerom (?), 09:36 , 25-Апр-23, (33)

Это что за чёрная магия Как это работает , Аноним (16), 01:06 , 25-Апр-23, (16)

За натом работает, видимо У меня отваливались по таймауту Если программа рассч, Аноним (2), 01:43 , 25-Апр-23, (17)

Да а в чём магия-то Дескриптор сокета и прочее переносится со всей сопутствующе, Tron is Whistling (?), 08:44 , 25-Апр-23, (27)

т е если подобную штуку запустить и на другом компе, то получится что к одному у, Бывалый смузихлёб (?), 16:31 , 25-Апр-23, (46)

IP-адрес тоже придётся переноситьА так - да, могут даже смешаться до степени сме, Tron is Whistling (?), 17:37 , 25-Апр-23, (49)
Удалённому источнику там пофиг, что у кого установлено, он тупо пакетики получае, Tron is Whistling (?), 17:38 , 25-Апр-23, (50)

В переносе ip адреса как минимум магия Ну и так по мелочи , Аночик (?), 15:08 , 26-Апр-23, (53) –1

А в чём магия-то Снял IP на одной системе, поднял на другой Или роутинг изменил,, Tron is Whistling (?), 08:22 , 27-Апр-23, (61)

Идея хорошая, а вот с реализацией проблемы После нескольких заморозок процесс н, Аноним (19), 06:34 , 25-Апр-23, (19)
Вообще сама идея мне честно говоря нравится Можно перетащить большой долгоживущ, Tron is Whistling (?), 08:47 , 25-Апр-23, (28)

Э, зачэм астериск анекдот про гусей Немного не понял смысл упражнения Не, ну, PnD (??), 16:55 , 26-Апр-23, (56)

Это смотря что у вас на астериске У нас есть больничные кол-центры, которые даже, Tron is Whistling (?), 08:26 , 27-Апр-23, (62)

Да, положить дежурную больницу 8212 отдельная песТня, перед заходом на пос, PnD (??), 11:59 , 27-Апр-23, (64) +1

Идея хороша, хотя бы для обновления ядра без остановки компа Продумать, чтоб , 1 (??), 09:18 , 25-Апр-23, (31)
Что только не делают лишь бы Plan9 Inferno не пилить, ZVVZ (?), 09:35 , 25-Апр-23, (32) +3

А на них так можно разве , Аноним (16), 13:01 , 25-Апр-23, (42) +1

Ждем в proxmox для ha lxc контейнеров, Аноним (35), 09:38 , 25-Апр-23, (35) +2
Почему нельзя просто скопировать machine1 proc pid1 на machine2 proc pid2 , Аноним (37), 10:16 , 25-Апр-23, (37) –1
В демке они игры на лету между датацентрами по планете перекидывали и игра не ос, Ддд (?), 12:04 , 25-Апр-23, (41) +1

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 24-Апр-23, 23:03 –9 +/–

Каким образом это нововведение возможно применить в девопсе?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #7

2. Сообщение от Аноним (2), 24-Апр-23, 23:11 +3 +/–

Какое именно? И зачем именно в девопсе? Как мне видится невозможность сдампить GUI приложения несколько ограничивает применимость на десктопе, но всё же. Да и вроде говорили что для иксов анриал, но для вейланда возможно. Так уж получается, что какой-нибудь блендер иногда неплохо бы остановить по разным причинам.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #21, #22, #23

4. Сообщение от Аноним (4), 24-Апр-23, 23:38 +3 +/–

Я minecraft приостанавливал посылая SIGSTOP через htop, чтоб проц не грузил, когда на паузе

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55

6. Сообщение от Аноним (7), 24-Апр-23, 23:41 +/–

А что происходит с файловыми дескрипторами? Например, программа пишет что-то в файл на нфс-шаре, мы её резко снэпшотим. Потом - восстанавливаем на другой машине с такой же нфс-шарой. Сможет ли она продолжить писать в тот же файл?
Также сокеты иксов и пульсов. Допустим я хочу перенести граф-приложение с машины на машину. Persistent storage - тот же нфс.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #26

7. Сообщение от Аноним (7), 24-Апр-23, 23:42 +4 +/–

Было бы неплохо смигрировать вживую контейнер с одной машины на другую, например.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12, #40

8. Сообщение от Sw00p aka Jerom (?), 24-Апр-23, 23:47 +/–

Фантом ОС изобретают :)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25

11. Сообщение от Dzen Python (ok), 24-Апр-23, 23:56 +1 +/–

Отслеживание открытых файлов и маппинг на удаленной машине?
Дамп небольших файлов целиком с переносом образа процесса на удаленную машину?
Резолв соединений к БД на уровне внешних процессов-брокеров?
> Потом - восстанавливаем на другой машине с такой же нфс-шарой. Сможет ли она продолжить писать в тот же файл?
Если пути и окружение совпадает - то почему бы и нет? Главное - синхронизировать состояние целефого файла, гарантируя, что не было разрушающих формат дозаписей, т.к. снять мы можем в произвольный момент времени.
> А что происходит с файловыми дескрипторами?
Это как раз наименьшая проблема. Тут гораздо большая проблема с окружением (которое по умолчанию может быть очень отличным от машины, на которой сняли снапшот).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #18, #24

12. Сообщение от Dzen Python (ok), 24-Апр-23, 23:57 +/–

М?
Прикладники научились писать софт, который не требует перезапусков раз в эн времени?
Или 640 петабайт оперативы уж точно должно хватить всем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #14

14. Сообщение от 48 (?), 25-Апр-23, 00:40 +/–

А что драйверов на расте писать не собираются? или системы не состоят из контейнеров внутри виртуалок, потому что никто низачто не отвечает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 25-Апр-23, 01:06 +/–

> в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений.
Это что за чёрная магия? Как это работает?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17

17. Сообщение от Аноним (2), 25-Апр-23, 01:43 +/–

>> в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений.
> Это что за чёрная магия? Как это работает?
За натом работает, видимо. У меня отваливались по таймауту. Если программа рассчитана на обновление соединения то всё будет работать при этом, а так вообще никто ничего не заметит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #27

18. Сообщение от Аноним (18), 25-Апр-23, 05:53 +/–

это ж как мне кажется напоминает ceph из proxmox`a

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

19. Сообщение от Аноним (19), 25-Апр-23, 06:34 +/–

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

Ответить | Правка | Наверх | Cообщить модератору

21. Сообщение от Аноним (21), 25-Апр-23, 07:12 –2 +/–

Правильная, ядерная (никаких изменений в системном и прикладном ПО не требуется) реализация SSI кластера балансировки нагрузки между узлами (прозрачная миграция процессов) и правильная, реализация сохранения и восстановления процессов для Linux (прозрачное восстановление абсолютно всех процессов,включая все графические процессы): https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
Исходники: https://sourceforge.net/projects/monitoring/files/hardened-o.../

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

22. Сообщение от Аноним (21), 25-Апр-23, 07:19 +2 +/–

> и вроде говорили что для иксов анриал
Лгут тебе. Выше ссылки на LiveCD и исходники ядра Linux, все оттестировано и работает.
Жаль, не смогли протолкнуть эти, ПРАВЕЛЬНЫЕ, технологии в официальное ядро. Победила красная шляпа с cgroups, namespaces, systemd+dbus+polkit.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #69

23. Сообщение от Аноним (21), 25-Апр-23, 07:24 +/–

> и вроде говорили что для иксов анриал, но для вейланда возможно
Насколько помню события 15-летней давности там разрабы поругались с технологиями cgroup, namespaces если их выкинуть с ядра, то уже есть реализация и для X11: https://sourceforge.net/projects/monitoring/files/hardened-o.../
А вейленд такое же нинужгое зло как и сыстемды с дбас.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #58

24. Сообщение от Аноним (24), 25-Апр-23, 08:24 +/–

> Тут гораздо большая проблема с окружением (которое по умолчанию может быть очень отличным от машины, на которой сняли снапшот).
Допустим у нас контейнер, содержимое которого рсинхаем перед расснапшочиванием.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

25. Сообщение от Аноним (24), 25-Апр-23, 08:24 +/–

Нет. Иначе повторят его судьбу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #33

26. Сообщение от Tron is Whistling (?), 25-Апр-23, 08:42 +/–

Главное чтобы файл за это время измениться не успел.
Иначе будет ПРИКОЛЬНО111!!!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #65

27. Сообщение от Tron is Whistling (?), 25-Апр-23, 08:44 +/–

Да а в чём магия-то? Дескриптор сокета и прочее переносится со всей сопутствующей инфой.
Если удалённая сторона стаймаутится не успеет - всё будет ок. У меня так SSH-сеансы после часовой отлучки в хибернейт поднимаются.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #46, #53

28. Сообщение от Tron is Whistling (?), 25-Апр-23, 08:47 +/–

Вообще сама идея мне честно говоря нравится. Можно перетащить большой долгоживущий процесс с машины на машину и машину обслужить.
Другое дело, что лично мне оно вообще почти не надо, потому что я строго соблюдаю принцип "одна машина - одна задача" + дублирование/кластеризацию, а контейнерщикам со всякими мокросервисами не надо вообще - их проще грохнуть и перезапустить. Но вот когда у тебя есть какая-то махровая проприетарь или щастье, которое ни задублировать, ни погасить на время обслуживания хост-системы, может быть интересно.
Надо с астериском попробовать - кто-нибудь пробовал?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56

31. Сообщение от 1 (??), 25-Апр-23, 09:18 +/–

Идея хороша, хотя бы для обновления ядра без остановки компа ...
Продумать, чтоб новое ядро перехватывало процессы и вуаля - правильные 24/7

Ответить | Правка | Наверх | Cообщить модератору

32. Сообщение от ZVVZ (?), 25-Апр-23, 09:35 +3 +/–

Что только не делают. лишь бы Plan9/Inferno не пилить

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

33. Сообщение от Sw00p aka Jerom (?), 25-Апр-23, 09:36 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

35. Сообщение от Аноним (35), 25-Апр-23, 09:38 +2 +/–

Ждем в proxmox для ha lxc контейнеров

Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от Аноним (37), 25-Апр-23, 10:16 –1 +/–

Почему нельзя просто скопировать machine1:/proc/$pid1 на machine2:/proc/$pid2
?

Ответить | Правка | Наверх | Cообщить модератору

40. Сообщение от Ivan (??), 25-Апр-23, 11:16 +1 +/–

Жду пока в Proxmox VE добавят живую миграцию LXC контейнеров. Ранее в Promox VE работала живая миграция
OpenVZ контейнеров. После того как разработчики в Proxmox VE добавили LXC вместо OpenVZ, то они сломали живую миграцию контейнеров.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #48

41. Сообщение от Ддд (?), 25-Апр-23, 12:04 +1 +/–

В демке они игры на лету между датацентрами по планете перекидывали и игра не осианавливалась

Ответить | Правка | Наверх | Cообщить модератору

42. Сообщение от Аноним (16), 25-Апр-23, 13:01 +1 +/–

А на них так можно разве?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

46. Сообщение от Бывалый смузихлёб (?), 25-Апр-23, 16:31 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #49, #50

48. Сообщение от ABATAPA (ok), 25-Апр-23, 16:40 +/–

Для QEMU-контейнеров работает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #54

49. Сообщение от Tron is Whistling (?), 25-Апр-23, 17:37 +/–

IP-адрес тоже придётся переносить
А так - да, могут даже смешаться до степени смешения, и будет весело

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

50. Сообщение от Tron is Whistling (?), 25-Апр-23, 17:38 +/–

Удалённому источнику там пофиг, что у кого установлено, он тупо пакетики получает с энным адресом

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

53. Сообщение от Аночик (?), 26-Апр-23, 15:08 –1 +/–

В переносе ip адреса как минимум магия.
Ну и так по мелочи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #61

54. Сообщение от PnD (??), 26-Апр-23, 16:23 +/–

LXC оборачивает то что умеет ядро с cgropus.
Там некому (пока?) контролировать состояние памяти (чтобы построить поверху миграцию). Максимум что можно — зафризить SIGSTOP и потом тащить всю память, до победного.
Второй проблемой будет перенос состояния CPU в новую точку запуска контейнера. И вот его в CRIU как-то сумели решить, как я понял из новости.
* "Тапки", fd etc. не упоминаю т.к. в целом тривиально.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

55. Сообщение от PnD (??), 26-Апр-23, 16:41 +/–

> через htop
Сотонист, не иначе.
# pkill -STOP -f XXX
# pkill -CONT -f XXX

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

56. Сообщение от PnD (??), 26-Апр-23, 16:55 +/–

Э, зачэм астериск? © анекдот про гусей.
Немного не понял смысл упражнения. Не, ну перетащить "прогретую" jvm с одного физ. хоста (без гипервизора-прослойки потому что HFT /а почему тогда java?/ или ещё какая фигня) наверное ок.
Но астер-то зачем вот так???

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #62

58. Сообщение от Илья (??), 26-Апр-23, 19:17 +/–

> А вейленд такое же нинужгое зло
А есть какой-то другой способ окна рисовать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #60, #63

60. Сообщение от AlexYeCu (ok), 26-Апр-23, 23:59 +/–

>А есть какой-то другой способ окна рисовать?
Ты не поверишь…

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

61. Сообщение от Tron is Whistling (?), 27-Апр-23, 08:22 +/–

А в чём магия-то?
Снял IP на одной системе, поднял на другой.
Или роутинг изменил, а IP на lo.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

62. Сообщение от Tron is Whistling (?), 27-Апр-23, 08:26 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #64

63. Сообщение от Аноним (63), 27-Апр-23, 08:45 –1 +/–

X11, он более универсален, поддерживает сеть, многоголовость (DMX). Хотя и DMX в иксах недавно похерели. Наверно производители железа приплатили.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #68

64. Сообщение от PnD (??), 27-Апр-23, 11:59 +1 +/–

> У нас есть больничные кол-центры, которые даже блин не раскидать по нодам
Да, "положить" дежурную больницу — отдельная песТня, перед заходом на "посадку".
Я такие штуки прокладывал xen (ну и qemu в DM, как без него). Потому что там легче доказать свою невиноватость. (И такой подход впоследствии отлично зашёл в PCI-DSS.)
Но, т.к. x86-железо (да хотя бы и ARM|Power|etc., протекающему PJSIP [20 байт на входящий по последним замерам] вообще пофиг) в нашей унылой реальности "складывается" примерно всегда. Проектировал так чтобы "сложившийся" узел оборвал текущие звонки. (В этом месте никого не привлекут если все регламенты проведены по журналам.) А новые сразу шли на резерв. Чего и вам желаю.
* Если в системе нет регламента для штатного (без сбоев в обслуживании) вывода из нагрузки, то я даже не знаю что сказать…

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

65. Сообщение от Олег (??), 28-Апр-23, 21:33 +/–

кеши сделабт много прикольного
уже умеют много прикольного без всяких нововведений

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

68. Сообщение от Илья (??), 01-Май-23, 17:34 +/–

> X11, он более универсален, поддерживает сеть, многоголовость (DMX). Хотя и DMX в
> иксах недавно похерели. Наверно производители железа приплатили.
Его же усиленно выпиливают и везде рекомендуют от него отказываться.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

69. Сообщение от xoy (??), 11-Май-23, 21:45 +/–

Дела давно минувших лет - преданье старины глубокой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 24-Апр-23, 23:03	–9 +/–
Каким образом это нововведение возможно применить в девопсе?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2, #7

2. Сообщение от Аноним (2), 24-Апр-23, 23:11	+3 +/–
Какое именно? И зачем именно в девопсе? Как мне видится невозможность сдампить GUI приложения несколько ограничивает применимость на десктопе, но всё же. Да и вроде говорили что для иксов анриал, но для вейланда возможно. Так уж получается, что какой-нибудь блендер иногда неплохо бы остановить по разным причинам.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #21, #22, #23

4. Сообщение от Аноним (4), 24-Апр-23, 23:38	+3 +/–
Я minecraft приостанавливал посылая SIGSTOP через htop, чтоб проц не грузил, когда на паузе
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #55

6. Сообщение от Аноним (7), 24-Апр-23, 23:41	+/–
А что происходит с файловыми дескрипторами? Например, программа пишет что-то в файл на нфс-шаре, мы её резко снэпшотим. Потом - восстанавливаем на другой машине с такой же нфс-шарой. Сможет ли она продолжить писать в тот же файл? Также сокеты иксов и пульсов. Допустим я хочу перенести граф-приложение с машины на машину. Persistent storage - тот же нфс.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #11, #26

7. Сообщение от Аноним (7), 24-Апр-23, 23:42	+4 +/–
Было бы неплохо смигрировать вживую контейнер с одной машины на другую, например.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #12, #40

8. Сообщение от Sw00p aka Jerom (?), 24-Апр-23, 23:47	+/–
Фантом ОС изобретают :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #25

11. Сообщение от Dzen Python (ok), 24-Апр-23, 23:56	+1 +/–
Отслеживание открытых файлов и маппинг на удаленной машине? Дамп небольших файлов целиком с переносом образа процесса на удаленную машину? Резолв соединений к БД на уровне внешних процессов-брокеров? > Потом - восстанавливаем на другой машине с такой же нфс-шарой. Сможет ли она продолжить писать в тот же файл? Если пути и окружение совпадает - то почему бы и нет? Главное - синхронизировать состояние целефого файла, гарантируя, что не было разрушающих формат дозаписей, т.к. снять мы можем в произвольный момент времени. > А что происходит с файловыми дескрипторами? Это как раз наименьшая проблема. Тут гораздо большая проблема с окружением (которое по умолчанию может быть очень отличным от машины, на которой сняли снапшот).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #18, #24

12. Сообщение от Dzen Python (ok), 24-Апр-23, 23:57	+/–
М? Прикладники научились писать софт, который не требует перезапусков раз в эн времени? Или 640 петабайт оперативы уж точно должно хватить всем?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #14

14. Сообщение от 48 (?), 25-Апр-23, 00:40	+/–
А что драйверов на расте писать не собираются? или системы не состоят из контейнеров внутри виртуалок, потому что никто низачто не отвечает?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 25-Апр-23, 01:06	+/–
> в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Это что за чёрная магия? Как это работает?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #17

17. Сообщение от Аноним (2), 25-Апр-23, 01:43	+/–
>> в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. > Это что за чёрная магия? Как это работает? За натом работает, видимо. У меня отваливались по таймауту. Если программа рассчитана на обновление соединения то всё будет работать при этом, а так вообще никто ничего не заметит.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #27

18. Сообщение от Аноним (18), 25-Апр-23, 05:53	+/–
это ж как мне кажется напоминает ceph из proxmox`a
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

19. Сообщение от Аноним (19), 25-Апр-23, 06:34	+/–
Идея хорошая, а вот с реализацией проблемы. После нескольких заморозок процесс начинает глючить. Лучшее решение - это использование виртуализации и снапшотов.
Ответить \| Правка \| Наверх \| Cообщить модератору

21. Сообщение от Аноним (21), 25-Апр-23, 07:12	–2 +/–
Правильная, ядерная (никаких изменений в системном и прикладном ПО не требуется) реализация SSI кластера балансировки нагрузки между узлами (прозрачная миграция процессов) и правильная, реализация сохранения и восстановления процессов для Linux (прозрачное восстановление абсолютно всех процессов,включая все графические процессы): https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../ Исходники: https://sourceforge.net/projects/monitoring/files/hardened-o.../
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

22. Сообщение от Аноним (21), 25-Апр-23, 07:19	+2 +/–
> и вроде говорили что для иксов анриал Лгут тебе. Выше ссылки на LiveCD и исходники ядра Linux, все оттестировано и работает. Жаль, не смогли протолкнуть эти, ПРАВЕЛЬНЫЕ, технологии в официальное ядро. Победила красная шляпа с cgroups, namespaces, systemd+dbus+polkit.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #69

23. Сообщение от Аноним (21), 25-Апр-23, 07:24	+/–
> и вроде говорили что для иксов анриал, но для вейланда возможно Насколько помню события 15-летней давности там разрабы поругались с технологиями cgroup, namespaces если их выкинуть с ядра, то уже есть реализация и для X11: https://sourceforge.net/projects/monitoring/files/hardened-o.../ А вейленд такое же нинужгое зло как и сыстемды с дбас.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #58

24. Сообщение от Аноним (24), 25-Апр-23, 08:24	+/–
> Тут гораздо большая проблема с окружением (которое по умолчанию может быть очень отличным от машины, на которой сняли снапшот). Допустим у нас контейнер, содержимое которого рсинхаем перед расснапшочиванием.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

25. Сообщение от Аноним (24), 25-Апр-23, 08:24	+/–
Нет. Иначе повторят его судьбу.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #33

26. Сообщение от Tron is Whistling (?), 25-Апр-23, 08:42	+/–
Главное чтобы файл за это время измениться не успел. Иначе будет ПРИКОЛЬНО111!!!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #65

27. Сообщение от Tron is Whistling (?), 25-Апр-23, 08:44	+/–
Да а в чём магия-то? Дескриптор сокета и прочее переносится со всей сопутствующей инфой. Если удалённая сторона стаймаутится не успеет - всё будет ок. У меня так SSH-сеансы после часовой отлучки в хибернейт поднимаются.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #46, #53

28. Сообщение от Tron is Whistling (?), 25-Апр-23, 08:47	+/–
Вообще сама идея мне честно говоря нравится. Можно перетащить большой долгоживущий процесс с машины на машину и машину обслужить. Другое дело, что лично мне оно вообще почти не надо, потому что я строго соблюдаю принцип "одна машина - одна задача" + дублирование/кластеризацию, а контейнерщикам со всякими мокросервисами не надо вообще - их проще грохнуть и перезапустить. Но вот когда у тебя есть какая-то махровая проприетарь или щастье, которое ни задублировать, ни погасить на время обслуживания хост-системы, может быть интересно. Надо с астериском попробовать - кто-нибудь пробовал?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #56

31. Сообщение от 1 (??), 25-Апр-23, 09:18	+/–
Идея хороша, хотя бы для обновления ядра без остановки компа ... Продумать, чтоб новое ядро перехватывало процессы и вуаля - правильные 24/7
Ответить \| Правка \| Наверх \| Cообщить модератору

32. Сообщение от ZVVZ (?), 25-Апр-23, 09:35	+3 +/–
Что только не делают. лишь бы Plan9/Inferno не пилить
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #42

33. Сообщение от Sw00p aka Jerom (?), 25-Апр-23, 09:36	+/–
Лол, Фантому надо было родиться на западе, чтобы эпфийцы заценили его :) как и все остальное давным-давно изобретенное, но не оцененное.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25

35. Сообщение от Аноним (35), 25-Апр-23, 09:38	+2 +/–
Ждем в proxmox для ha lxc контейнеров
Ответить \| Правка \| Наверх \| Cообщить модератору

37. Сообщение от Аноним (37), 25-Апр-23, 10:16	–1 +/–
Почему нельзя просто скопировать machine1:/proc/$pid1 на machine2:/proc/$pid2 ?
Ответить \| Правка \| Наверх \| Cообщить модератору

40. Сообщение от Ivan (??), 25-Апр-23, 11:16	+1 +/–
Жду пока в Proxmox VE добавят живую миграцию LXC контейнеров. Ранее в Promox VE работала живая миграция OpenVZ контейнеров. После того как разработчики в Proxmox VE добавили LXC вместо OpenVZ, то они сломали живую миграцию контейнеров.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #48

41. Сообщение от Ддд (?), 25-Апр-23, 12:04	+1 +/–
В демке они игры на лету между датацентрами по планете перекидывали и игра не осианавливалась
Ответить \| Правка \| Наверх \| Cообщить модератору

42. Сообщение от Аноним (16), 25-Апр-23, 13:01	+1 +/–
А на них так можно разве?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #32

46. Сообщение от Бывалый смузихлёб (?), 25-Апр-23, 16:31	+/–
т.е если подобную штуку запустить и на другом компе, то получится что к одному удалённому источнику установлено 2 одинаковых подключения с разных машин ? И как тогда они будут одинаковыми, если у новой машины даже адрес будет другой ?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #49, #50