«Introducing container in a file aka ploop»
Оригинал и мой черновой перевод (версия #2).
Совсем недавно в OpenVZ была реализована поддержка технологии «контейнер-в-файле» - как на уровне ядра, так и вспомогательных утилит, известная как ploop. Это - попытка обрисовать⁰ почему потребовался ploop, и почему он на голову выше того, что было ранее.
До ploop: simfs и vzquota
Прежде всего, несколько фактов касательно предшествующих ploop технологий, и их ограничений. Как вы наверное знаете, файловая система контейнера была попросту каталогом для chroot()'а. Хотя это выглядит вполне натурально и здорово, всё же есть и проблемы. Поскольку контейнеры существуют на одной и той же файловой системе, они все используют одни и те же её параметры (её тип, размер блока, и другие опции). Это значит, что мы не можем конфигурировать эти параметры для контейнеров индивидуально¹. Среди этих общих атрибутов файловой системы особо следует отметить её журнал. При всех достоинствах журнала как средства обеспечения целостности файловой системы и сокращения длительности загрузки (с ним можно обойтись без fsck во многих случаях), он является узким местом для контейнеров. Если один конт. заполняет память журнала (кучей небольших операций, которые требуют обновления метаданных, к примеру - обрезание файлов), операции ввода-вывода других конт. будут блокированы до тех пор, пока журнал не будет записан. Нам приходилось видеть 15-и секундные блокировки.
Поскольку многие конт. находятся на одной и той же FS, чтобы ограничить занимаемое конт. место, нам пришлось реализовать дисковые квоты для каталогов (vzquota). По той же самой причине, и исходя из того, что кол-во i-node ограничено [для большинства FS]², vzquota должна обеспечивать лимиты на их кол-во для каждого контейнера (читай - «для каталога»).
Для того, чтобы реализовать это на базе стандартных механизмов пользовательских и групповых дисковых квот, пришлось ввести уровень абстракции под названием simfs. Основная роль simfs - предоставить superblock, который нужен механизму дисковых квот для его работы (см. также).
При выполнение миграции-на-лету без использования разделяемого дискового хранилища (навроде NAS или SAN), мы используем rsync, который в точности копирует все файлы, за исключением того, что их номера i-node будут другими. Если есть какие-то программы, которые рассчитывают на то, что они остаются неизменными (TODO), то их работа будет нарушена в рез-те миграции.
В заключение - выполнить резервное копирование, или сделать снимок контейнера сложнее, поскольку требуется скопировать множество мелких файлов³.
Представляем ploop
Чтобы решить вышеуказанные проблемы и, в конечном итоге, сделать мир лучше⁴, мы решили реализовать хранение данных конт. в файле, TODO
Основная идея ploop в том, чтобы был файл-образ, который используется как блочное ус-во со своей FS. Некоторые читатели узнают в этом линуксовое ус-во loop! Так и есть, но loop крайне неоптимален⁵ (подвержен, например, проблеме двойного кэширования данных в ОЗУ), и его функционал не богат.
Реализация ploop в ядре использует модульный и послойный подход.
Верхним уровнем является главный модуль ploop, который представляет виртуальное блочное ус-во для размещения FS конт.
Средний уровень это модуль формата образа, который транслирует номера блоков блочного ус-ва в номера блоков образа. Простейший модуль формата, который называется "raw" выполняет тривиальное преобразование «один к одному» - такое же, как и у существующего ус-ва loop. Более сложные модули формата обладают собственной таблицей преобразования, и поддерживают рост/сокращение файла образа на лету. Это значит, если вы создали конт. с 2 GiB дискового прос-ва, файл образа будет не 2 GiB, а меньше - по размеру тех данных, которые действительно записаны⁶ в конт.. Есть возможность поддерживать и другие форматы образов, если написать соответствущий модуль формата, такой как, например QCOW2 (используемый QEMU и KVM).
Нижний уровень это модуль ввода-вывода. В настоящее время реализованы модули для EXT4 и NFS. Есть планы создать общий VFS модуль, в рез-те чего будет обеспечена поддержка произвольных файловых систем, но это потребует эффективной реализации прямого ввода-вывода на уровне VFS, работа над которой ещё ведётся⁷.
Преимущества ploop
Кратко:
⁰ - а это - попытка перевести попытку обрисовать.
(… и другие примечания ещё несомненно последуют) А вот собственно, и они:
¹ - Что мешает использовать LVM и для таких конт., которым нужны особенные параметры, давать их?
² - Reiser3 рулит - там нет явного лимита, который задаётся при создании FS. ЕМНИП, всё неплохо в этом отношении также и у JFS, XFS. А вот семейство EXT{2,4} до сих пор страдает.
³ - Не совсем ясна природа названной сложности. Используя LVM, можно легко получить snapshot к примеру, после чего скопировать консистентное состояние.
⁴ - Благостно-благостноПафосно-пафосно…
⁵ - Ну двойное кэширование эт понятно. Какие ещё неоптимальности за ним замечены?
⁶ - Если туда записать 1,5 GiB данных, а потом «снести их», оставив только 0,5 GiB такого приятного эффекта уже не будет(?)
⁷ - Несколько удивляет тот факт, что в 2012 у Linux до сих пор нет завершённого O_DIRECT, и над ним всё ещё ведутся какие-то работы.
⁸ - Теперь узким местом будет disk I/O scheduler aka elevator?
⁹ - Сложно назвать это однозначным преимуществом
¹⁰ - LVM/btrfs snapshots, а ещё лучше ZFS
¹¹ - см. 10
¹² - ???
Совсем недавно в OpenVZ была реализована поддержка технологии «контейнер-в-файле» - как на уровне ядра, так и вспомогательных утилит, известная как ploop. Это - попытка обрисовать⁰ почему потребовался ploop, и почему он на голову выше того, что было ранее.
До ploop: simfs и vzquota
Прежде всего, несколько фактов касательно предшествующих ploop технологий, и их ограничений. Как вы наверное знаете, файловая система контейнера была попросту каталогом для chroot()'а. Хотя это выглядит вполне натурально и здорово, всё же есть и проблемы. Поскольку контейнеры существуют на одной и той же файловой системе, они все используют одни и те же её параметры (её тип, размер блока, и другие опции). Это значит, что мы не можем конфигурировать эти параметры для контейнеров индивидуально¹. Среди этих общих атрибутов файловой системы особо следует отметить её журнал. При всех достоинствах журнала как средства обеспечения целостности файловой системы и сокращения длительности загрузки (с ним можно обойтись без fsck во многих случаях), он является узким местом для контейнеров. Если один конт. заполняет память журнала (кучей небольших операций, которые требуют обновления метаданных, к примеру - обрезание файлов), операции ввода-вывода других конт. будут блокированы до тех пор, пока журнал не будет записан. Нам приходилось видеть 15-и секундные блокировки.
Поскольку многие конт. находятся на одной и той же FS, чтобы ограничить занимаемое конт. место, нам пришлось реализовать дисковые квоты для каталогов (vzquota). По той же самой причине, и исходя из того, что кол-во i-node ограничено [для большинства FS]², vzquota должна обеспечивать лимиты на их кол-во для каждого контейнера (читай - «для каталога»).
Для того, чтобы реализовать это на базе стандартных механизмов пользовательских и групповых дисковых квот, пришлось ввести уровень абстракции под названием simfs. Основная роль simfs - предоставить superblock, который нужен механизму дисковых квот для его работы (см. также).
При выполнение миграции-на-лету без использования разделяемого дискового хранилища (навроде NAS или SAN), мы используем rsync, который в точности копирует все файлы, за исключением того, что их номера i-node будут другими. Если есть какие-то программы, которые рассчитывают на то, что они остаются неизменными (TODO), то их работа будет нарушена в рез-те миграции.
В заключение - выполнить резервное копирование, или сделать снимок контейнера сложнее, поскольку требуется скопировать множество мелких файлов³.
Представляем ploop
Чтобы решить вышеуказанные проблемы и, в конечном итоге, сделать мир лучше⁴, мы решили реализовать хранение данных конт. в файле, TODO
Основная идея ploop в том, чтобы был файл-образ, который используется как блочное ус-во со своей FS. Некоторые читатели узнают в этом линуксовое ус-во loop! Так и есть, но loop крайне неоптимален⁵ (подвержен, например, проблеме двойного кэширования данных в ОЗУ), и его функционал не богат.
Реализация ploop в ядре использует модульный и послойный подход.
Верхним уровнем является главный модуль ploop, который представляет виртуальное блочное ус-во для размещения FS конт.
Средний уровень это модуль формата образа, который транслирует номера блоков блочного ус-ва в номера блоков образа. Простейший модуль формата, который называется "raw" выполняет тривиальное преобразование «один к одному» - такое же, как и у существующего ус-ва loop. Более сложные модули формата обладают собственной таблицей преобразования, и поддерживают рост/сокращение файла образа на лету. Это значит, если вы создали конт. с 2 GiB дискового прос-ва, файл образа будет не 2 GiB, а меньше - по размеру тех данных, которые действительно записаны⁶ в конт.. Есть возможность поддерживать и другие форматы образов, если написать соответствущий модуль формата, такой как, например QCOW2 (используемый QEMU и KVM).
Нижний уровень это модуль ввода-вывода. В настоящее время реализованы модули для EXT4 и NFS. Есть планы создать общий VFS модуль, в рез-те чего будет обеспечена поддержка произвольных файловых систем, но это потребует эффективной реализации прямого ввода-вывода на уровне VFS, работа над которой ещё ведётся⁷.
Преимущества ploop
Кратко:
- Журнал FS больше не узкое место⁸
- Чтение-запись одного большого файла вместо кучи мелких, при административных процедурах⁹
- Дисковые квоты могут быть реализованы на основе виртуального блочного ус-ва; нет нужды заморачиваться с квотами каталогов
- Можно не ограничивать кол-во inode, поскольку этот ресурс более не разделяемый (у каждого конт. своя FS)
- Резервное копирвание на лету простое и консистентое¹⁰
- Миграция на лету выполняется надёжно и эффективно¹¹
- Разные конт. могут использовать FS разных типов и характеристик¹
- Эффективное создание конт.¹²
- [Возможная] поддержка QCOW2 и других форматов
- Поддержка разных типов дискового хранилища
⁰ - а это - попытка перевести попытку обрисовать.
(… и другие примечания ещё несомненно последуют) А вот собственно, и они:
¹ - Что мешает использовать LVM и для таких конт., которым нужны особенные параметры, давать их?
² - Reiser3 рулит - там нет явного лимита, который задаётся при создании FS. ЕМНИП, всё неплохо в этом отношении также и у JFS, XFS. А вот семейство EXT{2,4} до сих пор страдает.
³ - Не совсем ясна природа названной сложности. Используя LVM, можно легко получить snapshot к примеру, после чего скопировать консистентное состояние.
⁴ - Благостно-благостноПафосно-пафосно…
⁵ - Ну двойное кэширование эт понятно. Какие ещё неоптимальности за ним замечены?
⁶ - Если туда записать 1,5 GiB данных, а потом «снести их», оставив только 0,5 GiB такого приятного эффекта уже не будет(?)
⁷ - Несколько удивляет тот факт, что в 2012 у Linux до сих пор нет завершённого O_DIRECT, и над ним всё ещё ведутся какие-то работы.
⁸ - Теперь узким местом будет disk I/O scheduler aka elevator?
⁹ - Сложно назвать это однозначным преимуществом
¹⁰ - LVM/btrfs snapshots, а ещё лучше ZFS
¹¹ - см. 10
¹² - ???