Zfs: Запрос функции - онлайн-сплит-клон

Похоже, что zfs promote уже может делать то, что вам нужно.

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

Я смотрел на продвижение zfs, но, похоже, это просто перевернуло отношения между родителями и детьми ...

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

некоторые варианты использования для этого могут быть
клонирование шаблонов виртуальных машин - наличие базового образа, который клонируется для создания других виртуальных машин, которые, в свою очередь, отделяются от шаблона, чтобы шаблон можно было обновить / уничтожить / воссоздать
клоны базы данных - клонирование prod db для разработчика, который претерпит множество изменений и который, в свою очередь, может стать базой для самого тестового клона, в случае, если было бы неплохо отделить dev от prod, поскольку базовый снимок может стать больше чем наличие независимой файловой системы для разработчиков

После клонирования исходного @ snapshot вы можете свободно изменять и набор данных, и клонировать, они не будут влиять друг на друга, за исключением того, что они совместно используют данные, все еще общие для обоих на диске.

Если вы хотите уничтожить / воссоздать шаблон (оригинал), вы можете просто уничтожить на нем все снимки (кроме тех, которые используются в качестве источников клонов), zfs переименует оригинал, а zfs создаст новый с тем же именем (свойство origin of clones не привязан к имени исходного набора данных, поэтому вы можете свободно переименовывать оба).

Единственным недостатком этого является то, что все _уникальные_ данные, хранящиеся в исходном @ snapshot (= базе клона), не могут быть выпущены, если вы не желаете уничтожить либо клон (ы), либо (после продвижения клона) оригинал.

@ greg-Hydrogen в конце концов вы определили, соответствует ли zfs promote вашим потребностям? Или здесь все еще возможный запрос функции.

Чтобы прокомментировать это, было бы неплохо, если бы существовала функциональность для преобразования отношений источник-клон в дедупликационный вид: удаление логических ссылок, которые предотвращают индивидуальное уничтожение наборов данных по желанию - при сохранении только одной копии все еще общего данные.

@behlendorf : это почти наверняка не отвечает потребностям.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
хорошо объясняет проблему.

Вот что я пытаюсь сделать концептуально:

пользователь @ резервное копирование :

1. создать снимок на основе даты
2. отправить его из резервной копии на тест в качестве зеркала

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

пользователь @ test :

1. создать место для дезинфекции зеркала
2. продезинфицировать это
3. сфотографируйте это
4. клонировать очищенную версию для использования
5. используй это

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

пользователь @ резервное копирование :

1. воспользовавшись продукцией дальше ...
2. создать обновленный снимок
3. отправить инкрементальные изменения от продукта к тесту
4. удалить предыдущий инкрементный маркер (который в моем случае освобождает 70 ГБ)

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

пользователь @ test :

• вот тут и возникают проблемы.
• с некоторой долей уговоров можно уничтожить дезинфицирующие объемы.
• Но у меня остался test/mirror@20170901 который является источником двух оставшихся вещей: test/mirror@20170908 и test/test .
• Я мог бы уничтожить обновленное зеркало ( test/mirror@20170908 ), если бы захотел, но это не принесет мне никакой пользы (поскольку моя цель - использовать эти данные).

Чтобы добиться прогресса, мне на самом деле нужно пройти дезинфекцию, остановить то, что использует тест, уничтожить тест (полностью), клонировать зеркало в качестве теста, перезапустить вещь с помощью теста, а затем я могу, наконец, попытаться уничтожить оригинал снимок. Или я могу решить, что я собираюсь пройти проверку, позже запустить новый моментальный снимок при резервном копировании и отправить его приращение, удалить моментальный снимок, который никогда не был зеркалирован для тестирования, и повторить попытку.

Fwiw, чтобы попробовать это ...:

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

(числа действительно неправильные, у меня действительно есть 1 том с 4 содержащимися томами, поэтому рекурсивные флаги ...)

Теперь я понимаю, что могу использовать zfs send | zfs recv для разрыва зависимостей, и для мелких вещей это нормально. Но эта часть моего пула примерно в два раза больше доступного пространства в пуле, а половина, вероятно, больше, что означает, что выполнение этой операции проблематично. Это также огромное количество байтов для повторной обработки. Я надеялся, что при использовании моментальных снимков смогу извлечь выгоду из COW, но вместо этого мне платят за COW, потому что точка ветвления, в которой в конечном итоге будут использоваться данные ни одной из сторон моего дерева ветвления, все равно должна быть оплачена.

@behlendorf Привет, есть ли в этом прогресс? Разделение клона из исходной файловой системы будет действительно отличным вариантом для шаблонов виртуальных машин и / или восстановления на уровне больших файлов. См. Ссылку @jsoref, вставленную выше, для практического примера.

@kpande : цель состоит в том, чтобы платить (в пространстве и передаче данных) за то, что изменилось (COW), а не за весь набор данных (каждый раз, когда происходит эта операция).

Если бы у меня был движущийся набор данных 10 ТБ и вариант набора данных, который я хочу создать, конечно, я мог бы скопировать 10 ТБ, применить вариант и заплатить за 20 ТБ (если у меня есть 20 ТБ). Но если мой вариант действительно всего на 10 МБ отличается от исходных 10 ТБ, почему я не могу заплатить за 10 ТБ + 10 МБ? - снимки + клоны дают мне то. Пока 10 ТБ не переместится достаточно, чтобы я теперь плачу за 10 ТБ (в реальном времени + снимок 10 ТБ + расходящиеся 10 ТБ), а мой вариант 10 МБ перемещается так, чтобы теперь он был собственным 10 ТБ (отличным от реального и снимка). Тем временем, чтобы «исправить» мою проблему с 30 ТБ, я должен потратить еще 10 ТБ (= 40 ТБ - через ваш zfs send + zfs recv). Это не идеально. Конечно, он будет «работать», но он не «быстрый» и не эффективен удаленно.

Отредактированный send / recv звучит интересно (поскольку он более или менее соответствует моему варианту использования), но, хотя я могу найти его упомянутым во множестве мест, я не могу найти никакого полезного объяснения того, что он на самом деле редактирует.

Fwiw, для нашей системы я переключился так, чтобы дезинфекция происходила на отправляющей стороне (что также лучше с точки зрения конфиденциальности), что в основном вытащило нас из леса.

Это случаи, когда изменение данных не «редактируется» и когда система имеет ресурсы для zfs snapshot + zfs send, но на самом деле не хочет выделять ресурсы для размещения второй базы данных для «мутации» - и не хочет платить за отправку всего тома между первичным и вторичным (т.е. он скорее отправит инкрементный снимок в систему, в которой уже есть предыдущий моментальный снимок).

Да, я знаю, что могу использовать дедупликацию. Мы платим за наш cpus / ram, поэтому выделение постоянного cpu + ram для быстрого выполнения редкой задачи (обновление мутировавшего клона) казалось плохим компромиссом (я бы предпочел заплатить за немного больше места на диске).

@kpande эта ссылка довольно четко показывает проблему с текущими клонами. В конце концов, если клон так сильно отличается от базового снимка, постоянное отношение «родитель-> потомок» между ними является источником путаницы. Разделение клона будет явным признаком того, что они настолько разошлись, что их больше нельзя считать связанными.

Но позвольте мне привести более практический пример.

Пусть kvm/vmimages будет контейнером хранилища данных для нескольких образов виртуальных дисков, моментальные снимки которых будут делаться ежедневно. Я знаю, что ответ по умолчанию будет «использовать набор данных для каждого диска», но пулы libvirt плохо справляются с этим. Итак, у нас есть что-то вроде:

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

В какой-то момент с виртуальным диском происходит что-то плохое (например, серьезное повреждение гостевой файловой системы), но тем временем другие пользователи активно хранят новые важные данные на других дисках. По сути, у вас есть несколько противоположных требований: а) вернуться к старым, не поврежденным данным вчерашнего дня, б) сохранить все новые загруженные данные, которые не найдены ни в каких моментальных снимках и в) вызвать минимальное прерывание обслуживания.

В качестве возможного решения приходят клоны: вы можете клонировать kvm/vmimages@snap3 как kvm/restored чтобы немедленно восстановить службу для затронутой виртуальной машины. Итак, теперь у вас есть:

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

Затронутая виртуальная машина работает с kvm/restored , а все остальные остаются с kvm/vmimages . На этом этапе вы удаляете все лишние диски из kvm/restored и исходный поврежденный диск из kvm/vmimages . Все кажется хорошо, пока вы не поймете, что старый поврежденный образ диска все еще использует реальное дисковое пространство, а любая перезапись в kvm/restored потребляет дополнительное пространство из-за старого, не удаляемого kvm/vmimages@snap3 . Вы не можете удалить этот старый снимок, не удалив также и свой клон, и вы не можете просто продвигать kvm/restored и удалять kvm/vmimages потому что это не единственный истинный "авторитетный" источник данных (т.е. хранится внутри обоих наборов данных).

Отделение клона от источника полностью решит указанную выше проблему. Мне неясно, как отредактированный send / recv поможет в этом случае.

Сначала @kpande , спасибо за то, что поделились своим мнением и своим решением (что интересно!). Я полностью согласен с тем, что тщательная и очень конкретная гостевая конфигурация (и дерево набора данных хоста) может помочь избежать проблемы, описанной выше.

Тем не менее, libvirt (и ее реализация пулов хранения) не очень хорошо работает с этим подходом, особенно при управлении смешанными средами с виртуальными машинами Windows. Более того, это был единичный пример. Разделяемые клоны были бы очень полезны, например, при использовании для создания «золотого главного / базового образа», который может быть инстансирован по желанию для создания «настоящих» виртуальных машин.

При текущем состоянии дел это потребует больших затрат на выделенное пространство, поскольку вы не сможете когда-либо удалить исходный, потенциально устаревший снимок. Что меня удивляет, так это то, что, будучи файловой системой ZFS CoW, это должна быть относительно простая операция: при удалении исходного снимка «просто» пометить как свободный любой блок, на который нет ссылки, и удалить отношение родитель / потомок. Другими словами, пусть будет клоном настоящая файловая система, не связанная с любым исходным моментальным снимком.

Обратите внимание, что я использовал мир «просто» внутри кавычек: хотя это действительно простая логическая операция, я не уверен, соответствует ли / насколько хорошо она сопоставляется с базовой файловой системой zfs.

@kpande хорошо, честно - если существует реальная техническая проблема, я должен с ней согласиться. Но это отличается от утверждения, что конкретный вариант использования недействителен.

Если эта точка зрения (то есть невозможность отделить клон от исходного родительского снимка без использования «мифического» BPR) разделяется разработчиками zfs, я думаю, что этот FR можно закрыть.

Благодарю.

+1 о необходимости этой функции. Да, можно использовать send / recv, но это потребует простоя того, что использует этот набор данных, чтобы переключиться со старого (клонирования) на новый набор данных.

Я сталкивался с ситуациями с LXD, когда контейнер копируется (клонируется), но это вызывает проблемы с моим отдельно управляемым моментальным снимком.

@kpande : опять же, в моем

Из того, что я видел, не похоже, что overlayfs хорошо играет с zfs в качестве файловой системы (в соответствии с вашими примечаниями, похоже, он счастлив с zvols и ext4 / xfs). Кажется, что этот подход подходит для большинства случаев, и в этом случае будет приветствоваться документация, объясняющая, как настроить overlayfs с ext4 / xfs.

Тем не менее, некоторые из нас используют zfs не только для управления томами, но и для поведения / просмотра acl / allow / snapshot, и хотели бы иметь возможность использовать overlayfs w / zfs вместо ext4 / xfs, так что если это не невозможно, есть ли для этого ошибка? Если есть, было бы хорошо, если бы это было выделено (отсюда), если нет, если вы одобряете подход overlayfs, возможно, вы могли бы его подать (если вы настаиваете, я, вероятно, мог бы написать это, но я не Я ничего не знаю о overlayfs, и это кажется ключевой технологией в описании).

Из того, что я видел, не похоже, что overlayfs хорошо играет с zfs в качестве файловой системы (в соответствии с вашими примечаниями, похоже, он счастлив с zvols и ext4 / xfs). Кажется, что этот подход подходит для большинства случаев, и в этом случае будет приветствоваться документация, объясняющая, как настроить overlayfs с ext4 / xfs.

Подход overlayfs не работает для чрезвычайно важного и распространенного варианта использования: клонирования виртуального образа, начиная с другого (или шаблона «золотой мастер»). В таком случае разделение клона было бы ключом к тому, чтобы избежать потери места из-за расхождения исходных / клонированных изображений.

@ ptx0 это работает только в том случае, если гостевая ОС поддерживает overlayfs (т.е. нет поддержки виртуальных машин Windows) и если конечный пользователь (то есть: наши клиенты) желает значительно изменить подготовку / установку образов своих виртуальных машин. В качестве побочного примечания, хотя я полностью понимаю - и принимаю - этот PR закрыт по техническим причинам (например: если он включает BPR), довольно неприятно иметь отметку о законном случае пользователя как «недействительный». Если это не ваш вариант использования, хорошо. Но, пожалуйста, не думайте, что ни у кого нет подходящего варианта использования этой функции.

Windows не нуждается в overlayfs, она имеет встроенные профили перенаправления папок и перемещаемые файлы.

Перенаправление папок, хотя и существует с NT, не всегда работает надежно, поскольку существует программное обеспечение, которое (по неясным причинам) не обрабатывает перенаправленные папки правильно и просто дает сбой при столкновении с перенаправленным рабочим столом или документами. Кроме того, клоны установок Windows расходятся сами по себе, массово и довольно быстро от источника, благодаря Центру обновления Windows - вход и выход разных пользователей только ускоряют это.