Комментарии 19
Немного не в тему, но я тут недавно задавался вопросом о восстановлении TCP соединения, чтобы при переключении с одной тачки на другую keep-alive соединение не разрывалось. Интересно было бы использовать только механизм восстановления TCP сессий.
Ядерная часть вошла в 3.5 kernelnewbies.org/Linux_3.5#head-9ef0326b4fa2e159cdc12f5ab329a06d8658e1e4
Пример userspace кода вы можете найти тут: git.criu.org/?p=crtools.git;a=blob_plain;f=sk-tcp.c;hb=HEAD
Пример userspace кода вы можете найти тут: git.criu.org/?p=crtools.git;a=blob_plain;f=sk-tcp.c;hb=HEAD
conntrackd?
conntrackd для гейтвеев/файрволлов. Мне же требуется на двух разных бэкендах с разными IP поддерживать на уровне приложения и ядра уже установленные коннекты. Т.е. на web1 создается ESTABLISHED соединение, а на web2 создается клон, на тот случай, если к нему буду приходить коннекты.
Я уже задавался этим вопросом на lor, но низкоуровневого решения не нашлось, пришлось использовать nginx в качестве прослойки и по сигналу RST перенаправлять трафик на нужный backend.
Я уже задавался этим вопросом на lor, но низкоуровневого решения не нашлось, пришлось использовать nginx в качестве прослойки и по сигналу RST перенаправлять трафик на нужный backend.
Я немножко не понял, что оно делает со средой обитания программы при восстановлении. Понял, что переоткроет все дескрипторы (файлы, сокеты, мьютексы...), но не понятно, что будет делать если файл был удалён, сокет закрыт, а мьютекс переключен. Насколько я понимаю, segmentation fault либо что-то похожее можно гарантировать… Разъясните пожалуйста этот момент.
Программа будет работать как раньше, никаких лишних segfault-ов быть не должно. Если файл будет удален, то его содержимое будет сохранено и на ресторе файл будет восстановлен, открыт и снова удален. С закрытым сокетом проблем еще меньше, достаточно на восстановлении создать сокет и закрыть его. С мьютексом проблемы совсем нет, его состояние хранится в памяти, а она восстанавливается.
Предупрежу дальнейшие вопросы. Мы не просто приоткрываемым сокеты, пайпы и т д, но и восстанавливаем их состояния. Для каждого объекта свой подход. Сначала мы стараемся использовать существующие механизмы, если не получается добавляем новые интерфейсы в ядро.
Предупрежу дальнейшие вопросы. Мы не просто приоткрываемым сокеты, пайпы и т д, но и восстанавливаем их состояния. Для каждого объекта свой подход. Сначала мы стараемся использовать существующие механизмы, если не получается добавляем новые интерфейсы в ядро.
Программа будет работать как раньше, никаких лишних segfault-ов быть не должно. Если файл будет удален, то его содержимое будет сохранено и на ресторе файл будет восстановлен, открыт и снова удален. С закрытым сокетом проблем еще меньше, достаточно на восстановлении создать сокет и закрыть его. С мьютексом проблемы совсем нет, его состояние хранится в памяти, а она восстанавливается.
Предупрежу дальнейшие вопросы. Мы не просто приоткрываемым сокеты, пайпы и т д, но и восстанавливаем их состояния. Для каждого объекта свой подход. Сначала мы стараемся использовать существующие механизмы, если не получается добавляем новые интерфейсы в ядро.
Предупрежу дальнейшие вопросы. Мы не просто приоткрываемым сокеты, пайпы и т д, но и восстанавливаем их состояния. Для каждого объекта свой подход. Сначала мы стараемся использовать существующие механизмы, если не получается добавляем новые интерфейсы в ядро.
Интересно, а какие-то наработки такого рода для Windows существуют?
Для восстановления приложения с контрольной точки необходимо сначала создать дерево его процессов. Для этого в ядре Linux был разработан отдельный механизм для создания процессов с заданными идентификаторами.
Что будет, если такой PID в системе уже присутствует? :)
Тоже интересовал этот вопрос. И как решается если на дургой системе немного другое дерево. Или тут должна быть ос 1 в 1. ЧТо конечно логично но хотелось бы коментарий.
Что значит немного другое дерево? В каждой системе дерево свое.
Есть проблема с изоляцией приложений. Мы сохраняем и восстанавливаем только те процессы, которые попросил пользователь. Проблема в том, что процессы могут быть связаны между собой и иметь некий двусторонний внутренний стейт, который зависит от логики приложения. В этом случае, если мы сохраним только одну сторону и потом ее восстановим, то формальная связь (unix сокет, fifo) будет восстановлена, но мы ничего не знаем о внутреннем состоянии.
Сохранение и восстановление контейнера целиком, гарантирует что мы собрали все зависимости и с большой вероятностью сможем его восстановить на другой системе.
Есть проблема с изоляцией приложений. Мы сохраняем и восстанавливаем только те процессы, которые попросил пользователь. Проблема в том, что процессы могут быть связаны между собой и иметь некий двусторонний внутренний стейт, который зависит от логики приложения. В этом случае, если мы сохраним только одну сторону и потом ее восстановим, то формальная связь (unix сокет, fifo) будет восстановлена, но мы ничего не знаем о внутреннем состоянии.
Сохранение и восстановление контейнера целиком, гарантирует что мы собрали все зависимости и с большой вероятностью сможем его восстановить на другой системе.
В этом случае восстановление не возможно. Это не проблема, если мы дампим контейнер (lxc или OpenVZ), потому что они используют pid namespace.
Ну наконец-то, давно думал почему этим еще никто не занялся, это же будет очень удобно.
Напомнило долгостроящуюся ru.wikipedia.org/wiki/Фантом_%28ОС%29 — в ней что-то такое обещают с самого начала, а это лет шесть назад.
Q: Каково же уникальное свойство ОС Фантом?
A: Говоря попросту — бессмертие. В отличие от всех существующих систем Фантом умеет обеспечить работающим в нём программам вечную жизнь. Для программ не существует необходимости завершаться. Это довольно сильно меняет ситуацию. Во-первых, это удобно — пользователь не должен перед выключением машины закрывать все программы и снова открывать их перед началом работы. Во-вторых, это позволяет программам быть сильно проще — например, программа больше не вынуждена вообще уметь записывать своё состояние в файл! Одно лишь это упрощение снижает затраты денег и времен на те самые 30%. А есть и другие.
Да, чем-то напоминает, но в нашем случае нет возможности обновить приложение и потом его восстановить.
К слову 6 лет назад у нас уже была эта функциональность в OpenVZ. CRIU позволит избавиться от своего кода в OpenVZ ядре, который нам сейчас приходится поддерживать. В свою очередь это даст нам возможность сделать что-то новое.
К слову 6 лет назад у нас уже была эта функциональность в OpenVZ. CRIU позволит избавиться от своего кода в OpenVZ ядре, который нам сейчас приходится поддерживать. В свою очередь это даст нам возможность сделать что-то новое.
Я упомянул «Фантом» не для установления исторического первенства, а скорее, чтоб вы могли черпать идеи из ещё более амбициозного проекта, и учиться на опыте и на ошибках его разработчиков.
Например, у них снимки памяти делаются инкрементально, что позволяет существенно сократить задержку. Может, сумеете и из юзермода так же?
Например, у них снимки памяти делаются инкрементально, что позволяет существенно сократить задержку. Может, сумеете и из юзермода так же?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CRIU — новый амбициозный проект для сохранения и восстановления состояния процессов