А давай вспомним еще simfs (фича OpenVZ, чем-то похожа на sub-volume в btrfs). Там ваша задача места просто отсутствует, т е там нет накладных расходов по месту бай дизаин.
* будет быстрее, просто потому что nbd не очень быстро работает.
* qcow2 очень похож на формат ploop-а. Какая функциональность вам интересует. ploop формат поддерживает снапшоты, балунинг, умеет сжиматься, расширяться. Мог что-то забыть.
ploop — это loop девайс «нового поколения». Через некоторое время он (или почти он) появится в мейнстримном ядре. У него нет двойного кеширования, он поддерживает разные форматы дисков, есть возможность делать снапшоты.
А вот формат дисков — это уже другое. По понятным причинам OpenVZ использует формат, который используется для виртуальных машин в PCS. Этот формат по фичам и структуре аналогичен форматам используемым в KVM, т е ваше рассуждение о проблемах связанных с форматами в корне не верное. Проблемы в этом месте у всех одинаковые.
В OpenVZ живая миграция уже больше 4 лет. Разработчики давно хотели запушать ее в мейнстрим, но никак не могли найти правильного решения. Около двух лет назад это решение было найдено и родился проект CRIU. Буквально недавно вышла версия 1.0. Я писал несколько статей об этом проекте.
«любой Linux процесс» — группу процессов с сопутствующими объектами. Любые процессы не может, т к процесс может иметь внешние связи, которые просто так не восстановишь Прелесть контейнеров в том, что это фактические изолированная группа процессов.
LXC — это уже имя собственное. На сколько мне известно Google использует свою реализацию контейнеров.
«видоизмененный аналог chroot» — это mount namespace для LXC и по историческим причинам своя реализация для OpenVZ. Для изоляции сети, IPC, UTS так же используются соответствующие пространства имен.
Из свободных реализаций так же можно упомянуть unshare, nsenter из util-linux, systemd-nspawn.
Ну, и не плохо было бы описать недостатки контейнеров.
Так известны все потомки и родители. Проблема в другом. Мы не знаем историю, как это дерево было создано.
Дерево жило своей жизнью, процессы там рождались, умирали, кто-то в какой-то момент времени становился лидером сессии, кто-то child-reaper-ом. Потом пришли мы и сбросили текущее состояние на диск. На ресторе надо восстановить его. Для этого нужно понять кто кого должен породить. В некоторых случаях придется вставлять вспомогательные процессы. К примеру если есть процессы принадлежащие к определенной сессиии, а лидера этот сессии нет.
Посмотрите на предложенный пример. К нему есть картинка, входные данные и выходные данные.
Любой процесс задампить нельзя, потому что процесс может иметь внешние связи и некоторые из них нельзя разорвать и потом восстановить. Так же процессы ресторятся с теми же пидами, которые у них были до дампа. Если часть пидов в новой системе занята, то рестор отвалится с ошибкой. Эта проблема обходится использованием pid name-space-ов.
Если вы хотите гарантировано задампить и поресторить дерево процессов, используйте Linux Containers.
Миграция между нодами, для балансировки нагрузки или для проведения сервисных работ. Подобное решение есть в OpenVZ ядре для миграции Linux контейнеров. Оно широко используется хостинг компаниями.
Обычному юзеру, может быть интересен сценарий с обновлением ядра, без перезагрузки юзерспейса habrahabr.ru/post/160201/.
В чем хитрость? CRIU — это opensource, если вы предложите хорошее решение, то мы обязательно напишем, что это придумано вами.
Сразу скажу, у нас варианта, который бы нас устраивал, нет. Вы можете посмотреть то что есть на git.criu.org/?p=crtools.git;a=blob;f=pstree.c;hb=HEAD, но оно не покрывает все возможных случаев. Есть решение, которое покрывает все варианты, но оно нас не устраивает по сложности алгоритмов и по количеству вспомогательных процессов, которые создаются во время работы.
Если тут никто не предложит хорошего решения, то я опишу своё отдельной статьей.
Сейчас многие живут в виртуальных машинах, если мы говорим о серверных продуктах (облака и все такое). В случае проблем с производительностью, часто бывает полезна любая информация. Чем ее больше, тем больше вероятность, что с вашей проблемой разберутся в короткие сроки. Не все проблемы воспроизводятся локально.
Мне лично это интересно, потому что я работаю на Linux. Почти вся моя разработка ведется не локально, а на удаленных машинах, часто в виртуалках. Можно все установить на реальной машине, но это время, которого обычно нет.
Читая статью в голове крутится вопрос. A действительно ли это важно для десктопных продуктов? И как дела обстоят с серверными вариантами (XEN, KVM, ESX, HyperV, PCS)?
* qcow2 очень похож на формат ploop-а. Какая функциональность вам интересует. ploop формат поддерживает снапшоты, балунинг, умеет сжиматься, расширяться. Мог что-то забыть.
CRIU 0.2 и Linux Containers — новые возможности
В преддверии очередного релиза CRIU
Официальный сайт проекта
Анонс 1.0
CRIU 0.2 и Linux Containers — новые возможности
В преддверии очередного релиза CRIU
Официальный сайт проекта
Анонс 1.0
А вот формат дисков — это уже другое. По понятным причинам OpenVZ использует формат, который используется для виртуальных машин в PCS. Этот формат по фичам и структуре аналогичен форматам используемым в KVM, т е ваше рассуждение о проблемах связанных с форматами в корне не верное. Проблемы в этом месте у всех одинаковые.
«любой Linux процесс» — группу процессов с сопутствующими объектами. Любые процессы не может, т к процесс может иметь внешние связи, которые просто так не восстановишь Прелесть контейнеров в том, что это фактические изолированная группа процессов.
«видоизмененный аналог chroot» — это mount namespace для LXC и по историческим причинам своя реализация для OpenVZ. Для изоляции сети, IPC, UTS так же используются соответствующие пространства имен.
Из свободных реализаций так же можно упомянуть unshare, nsenter из util-linux, systemd-nspawn.
Ну, и не плохо было бы описать недостатки контейнеров.
Дерево жило своей жизнью, процессы там рождались, умирали, кто-то в какой-то момент времени становился лидером сессии, кто-то child-reaper-ом. Потом пришли мы и сбросили текущее состояние на диск. На ресторе надо восстановить его. Для этого нужно понять кто кого должен породить. В некоторых случаях придется вставлять вспомогательные процессы. К примеру если есть процессы принадлежащие к определенной сессиии, а лидера этот сессии нет.
Посмотрите на предложенный пример. К нему есть картинка, входные данные и выходные данные.
habrahabr.ru/post/148413/
habrahabr.ru/post/152903/
habrahabr.ru/post/177499/
Любой процесс задампить нельзя, потому что процесс может иметь внешние связи и некоторые из них нельзя разорвать и потом восстановить. Так же процессы ресторятся с теми же пидами, которые у них были до дампа. Если часть пидов в новой системе занята, то рестор отвалится с ошибкой. Эта проблема обходится использованием pid name-space-ов.
Если вы хотите гарантировано задампить и поресторить дерево процессов, используйте Linux Containers.
Обычному юзеру, может быть интересен сценарий с обновлением ядра, без перезагрузки юзерспейса habrahabr.ru/post/160201/.
На сайте есть еще десяток сценариев, как можно использовать CRIU criu.org/Usage_scenarios
Сразу скажу, у нас варианта, который бы нас устраивал, нет. Вы можете посмотреть то что есть на git.criu.org/?p=crtools.git;a=blob;f=pstree.c;hb=HEAD, но оно не покрывает все возможных случаев. Есть решение, которое покрывает все варианты, но оно нас не устраивает по сложности алгоритмов и по количеству вспомогательных процессов, которые создаются во время работы.
Если тут никто не предложит хорошего решения, то я опишу своё отдельной статьей.
Мне лично это интересно, потому что я работаю на Linux. Почти вся моя разработка ведется не локально, а на удаленных машинах, часто в виртуалках. Можно все установить на реальной машине, но это время, которого обычно нет.