Основная проблема в том, что это — полная виртуализация на гипервизоре, а не контейнер в том смысле слова, что тут обсуждается. Интересна тема прямого разделения ресурсов хоста, нежели эмуляция виртуального железа.
Дада, слышал, я читаю новости :)
Это, как я понял всего лишь контейнеризация джава-приложения на основе kvm/xen. Немного не то.
Меня пока устраивает мой комбайн на основе Proxmox где приложения бегут в OpenVZ контейнерах. Контейнеры лежат на NFS который экспортирует ZFS тома.
Всё что выше мною написано — своеобразный плачь Ярославны.
systemd — это больше чем лаунчер. Да, он ломает каноны, но там настолько опытные люди заняты в проекте, что я хочу думать, что он движется в нужную сторону.
Я тоже слежу за его развитием с тех пор как Леннарт оставил в покое пульс-аудио.
Есть мнение, и не только моё, что вместо своего велосипеда было бы неплохо взять за основу открытый launchd как это уже делают некоторые люди из мира BSD. Но идеология линукса не даёт использовать лучшее из открытых разработок, принуждая к вилосипедостроению — убогий btrfs, недоделанный systemd (хотя надо отдать должное — наплевали на вой евангелистов и пытаются сделать как должно быть, а не как по писанию пророчат, поглядим во что вырастет), крайне убогий lvm, убогий gcc (по сравнению с clang+llvm), наколенный SystemTap, список длинный. Всё затраченное время на свои велосипеды можно было использовать куда более эффективно, но — увы.
zfs похоже действительно крута, но на линукс ее никто толком портировать не может.
Отчего же. Контрибьютят в нём не самые последние люди. Недавно вышел production ready релиз. Я поставил на бэкап-сервер 12.04 убунту из ppa — работает. zfs send/recv выполняется, версии zfs и zpool свежайшие, блоки по 4к и сжатие lz4 работает. Rootfs я пока ext4 оставил — нет желания возиться с грубом, но методички существуют, при желании можно перевести. Оно понятно, что zfs в линуксе не на столько глубоко интегрирована в систему, не проведены оптимизации до состояния zfs on solaris, где любой тюнинг zfs почти всегда приводит к падению производительности. Но процесс идёт, в удачном результате заинтересованы не последние силы, есть, короче говоря, надежда.
Я так понимаю, многие фичи присутствую в btrfs
Понимаете, фичи zfs есть в btrfs, вопрос в том — как они реализованы. В таком виде как btrfs готова сейчас — да ну их нафиг, действительно лучше прикрутить сбоку неродной open-zfs, чем пользоваться ванильным ортодоксальным btrfs.
А пока можете посмотреть в сторону контейнеров на ploop, там снапошоты больше похожи на то, что вы ожидаете увидеть, нежели то, что вы тут обсуждали в LVM. Ну и у ploop есть ряд интересных фич. Автор данного поста, намерен и о нем написать заметку.
Я подожду заметку, спасибо.
Про netns прочтите, будут вопросы спрашивайте. Думаю это сравнимые вещи с CrossBow.
Читаю тут про thin-provisioning, похоже они как-то хотят решить эту проблему, но я ещё не понял как.
Пишут, что на thin-provisioned volum'е при наличии нескольких снапшотов происходит всего одна CoW при изменении блока.
Хотелось добавить, что LVM снапшоты требуют место на диске под данные снапшота и метаданные изменённых блоков, что тоже отличается в сторону сильно «дороже» в отличии от ZFS.
Ну, серию снапшотов в таком случае мне вполне заменяет www.rsnapshot.org/, (который на файловом уровне осуществляет дедупликацию хардлинками, кстати говоря).
Вот это туманная область для меня. По идее не должно, потому что
Вы не могли бы привести какую-нибудь более-менее актуальную ссылку на подобные замеры?
Попробую ещё раз объяснить. Смысл LVM снапшота — на базе тома origin создать разреженное пустое блочное устройство snap1. На данные момент цена создания снэпшота крайне мала. Что происходит далее — в origin начинают изменяться блоки. LVM запоминает какие блоки изменились (метаданные), читает из origin эти ещё не изменённые блоки, записывает эти блоки в snap1, записывает новые блоки в origin, помечает в метаданных проделанную работу, после чего считается, что в origin данные записаны.
Т.е. грубо говоря вместо одной операции записи блока происходит чтение и две записи. Это serious impact to performance.
Читаю тут про thin-provisioning, похоже они как-то хотят решить эту проблему, но я ещё не понял как.
Если Вы просто укажете, зачем такое используется, буду благодарен за расширение горизонта.
Я немного параноик — мне спокойнее, когда у меня на удалённом бэкап-сервере лежат не только актуальные данные, но и так же снапшоты важных томов, в зависимости от важности на каждый час/день/неделю/месяц. Пока не пригодилось :) Хватало снапшотов на боевом сервере. Но в случае, когда на основном сервере старые снапшоты уйдут в утиль из-за периодической чистки для поддержания нужного объёма свободного места, эти снапшоты останутся на бэкап-сервере значительно дольше. Могут пригодится.
Насколько я знаю, падение производительности действительно есть, на существенно затрагивает оно именно последовательное чтение с самого снапшота, поскольку оно перестаёт быть таким уж последовательным.
Насколько я понимаю проблема падения производительности как раз при записи в оригинальное блочное устройство, ибо идея снапшотов лвм такова, что при изменении блока в оригинальном устройстве сначала этот блок читается, потом переносится в созданные снапшоты и после записывается в оригинальное устройство.
По поводу вашей ссылки — я понял так, что человек бэкапит базу на том который несколько раз заснапшотен и при этом пытается измерить скорость чтения с тома. Оригинальная методика, но не понятно почему надо чесать ухо пяткой.
Я даже не могу представить где можно использовать такой алгоритм, чтобы не навредить перформансу. Получается, что часто и много делать снапшотов попросту нельзя — из-за высокого I/O умрёт любая дисковая система при уже некотором количестве снапшотов. Наличие снапшотов по итогу дорого обходится в отличии от zfs.
Ну а вообще, похоже, дискуссия наша с Вами имеет некоторый ЛОРовский оттенок, и потому не имеет смысла.
Я постараюсь держать себя в руках.
Мы ударяемся в обсуждение неких конкреных фич и деталей реализации, забывая о задачах, ради которых и стоит все эти снапшоты городить.
Понимаете, именно добираясь до принципов реализации каких-то фич, можно апроксимировать поведение системы в целом, очень неплохо учитывать особенности реализации для понимания того как и почему именно так работает система.
Да, я уверен что можно составить перечень фич, которые есть в zfs, но нет в LVM (ровно как и наоборот, стопудово).
Мы лишь пока про снапшоты говорим.
Далее у Вас есть полное право голословно для каждого пункта заявить, что вот без этой-то фичи lvm вообще не может считаться софтверным продуктам, и такое не надо не только Вам, но и вообще никому, что всё это несеръёзно и гибрид поделки с подделкой.
На что вам нужны объяснения? Я готов пообщаться.
Если Вы всеръёз собираетесь что-то узнать/понять, давайте очертим условия и цели, и будем сравнивать конкретные способы их достижения при помощи zfs и LVM?
Мы пытаемся обсуждать снапшоты там и там.
Мой вопрос такой — решена ли проблема с падением производительности на блочном устройстве с которого снят один или особенно несколько снапшотов?
Моё мнение такое — выбранная схема снапшотинга в лвм ужасна более чем полностью. Но я подозреваю, что остальные способы ещё хуже. Могу сообщить, что снэпшоты зфс не имеют проблем существующих у лвм.
Как я понял CoW имеется в виду именно процесс создания снапшота, т.е., например, при изменении оригинала изменяемые блоки сначала уезжают в созданное блочное устройство, которое и является снапшотом, после чего обновляются в оригинале?
Как я понял CoW имеется в виду именно процесс создания снапшота, т.е., например, при изменении оригинала изменённые блоки уезжают в созданное блочное устройство, которое и является снапшотом?
Если всё так и есть, то уже можно прекратить обсуждать LVM и снапшоты ибо это не просто костыль, это сильно мягко выражаясь — обманка.
Боюсь, не настолько владею zfs, чтобы понимать в чём отличие send от rsync. Казалось бы, есть два блочных устройства на соединённых через сеть машинах. Мы хотим их каким-то образом синхронизировать…
ну, например, инкрементальный send/recv с воссозданием абсолютно идентичной иерархии тома с его снапшотами
я не представляю сколько сил надо чтобы на rsync+block device такое запилить, в zfs — из коробки
Полное копирование необзательно, с некоторых пор есть опция --merge для объединения снапшотов/снапшота и рабочей копии.
я быстренько пробежался в гугле про принцип lvm snapshot'ов и коротко уже высказал своё мнение, простите, но это — ужас-ужас
Хм, блочной дедупликациив LVM нет, насколько я помню, видимо копировать полностью. Вопрос об этом был?
ага, именно так, но дедупликация не при чём, вопрос в том как устроена система, в zfs создание, восстановление или клон снапшота это атомарная мгновенная операция, которую можно представить в виде перенаправления указателя актуальных данных на нужную ветку дерева
Её скорее всего можно подружить с юзерскими полномочиями, но как это сделать я сходу не скажу, извините.
ничего готового для использования нет, я лишь про это
Оно выглядит как утка, крякает как утка, ходит как утка, но если начать разбираться :)
Изнчально LVM это костыли впихиные в парадигму Linux.
Я не силён в LVM и особенно в их снапшотах, через это могу лишь задавать вопросы:
— насколько дорого сделать снапшот в LVM?
— является ли снапшот LVM новым файлом/директорией в плоскости фс или это некий новый объект?
— есть ли send/recevie снапшотов между томами/по сети? (rsync немного не то — лишь малая часть zfs send/recv)
— дорого ли восстанавливать том из снапшота?
— можно ли и как дорого создать новый том из снапшота?
— в zfs существует фича ".zfs" — некая виртуальная директория, где перечислены все созданные снапшоты, я делаю её видимой для пользователей и у меня нет проблем с вопросами типа — «восстанови мне вчерашний файл», есть ли такое в LVM?
, из той же серии стоит отметить базирующийся на контейнера из Linux Upstream дистрибутив CoreOs: coreos.com/ .
Вот это хочется пощупать, да.
Но наша задача шире — необходимо создание подобных подсистем во всех ведущих дистрибутивах, чем в свою очередь, например, очень активно занимается systemd, который буквально обязал все дистрибутивы перешедшие на него начать использовать контейнеры.
Всех ведущих, за спинами которых торчат не уши гиков, но денежные мешки, можно пересчитать по пальцам одной руки на которой может не хватать пары пальцев.
Будем посмотреть куда это всё пойдёт.
Это, как я понял всего лишь контейнеризация джава-приложения на основе kvm/xen. Немного не то.
Меня пока устраивает мой комбайн на основе Proxmox где приложения бегут в OpenVZ контейнерах. Контейнеры лежат на NFS который экспортирует ZFS тома.
Всё что выше мною написано — своеобразный плачь Ярославны.
Я тоже слежу за его развитием с тех пор как Леннарт оставил в покое пульс-аудио.
Есть мнение, и не только моё, что вместо своего велосипеда было бы неплохо взять за основу открытый launchd как это уже делают некоторые люди из мира BSD. Но идеология линукса не даёт использовать лучшее из открытых разработок, принуждая к вилосипедостроению — убогий btrfs, недоделанный systemd (хотя надо отдать должное — наплевали на вой евангелистов и пытаются сделать как должно быть, а не как по писанию пророчат, поглядим во что вырастет), крайне убогий lvm, убогий gcc (по сравнению с clang+llvm), наколенный SystemTap, список длинный. Всё затраченное время на свои велосипеды можно было использовать куда более эффективно, но — увы.
Отчего же. Контрибьютят в нём не самые последние люди. Недавно вышел production ready релиз. Я поставил на бэкап-сервер 12.04 убунту из ppa — работает. zfs send/recv выполняется, версии zfs и zpool свежайшие, блоки по 4к и сжатие lz4 работает. Rootfs я пока ext4 оставил — нет желания возиться с грубом, но методички существуют, при желании можно перевести. Оно понятно, что zfs в линуксе не на столько глубоко интегрирована в систему, не проведены оптимизации до состояния zfs on solaris, где любой тюнинг zfs почти всегда приводит к падению производительности. Но процесс идёт, в удачном результате заинтересованы не последние силы, есть, короче говоря, надежда.
Понимаете, фичи zfs есть в btrfs, вопрос в том — как они реализованы. В таком виде как btrfs готова сейчас — да ну их нафиг, действительно лучше прикрутить сбоку неродной open-zfs, чем пользоваться ванильным ортодоксальным btrfs.
Я подожду заметку, спасибо.
Угу.
Пишут, что на thin-provisioned volum'е при наличии нескольких снапшотов происходит всего одна CoW при изменении блока.
Хотелось добавить, что LVM снапшоты требуют место на диске под данные снапшота и метаданные изменённых блоков, что тоже отличается в сторону сильно «дороже» в отличии от ZFS.
Ммм, слабо понимаю какую проблему это решает.
Судя по этим фразам:
Он занимается именно этим :)
Попробую ещё раз объяснить. Смысл LVM снапшота — на базе тома origin создать разреженное пустое блочное устройство snap1. На данные момент цена создания снэпшота крайне мала. Что происходит далее — в origin начинают изменяться блоки. LVM запоминает какие блоки изменились (метаданные), читает из origin эти ещё не изменённые блоки, записывает эти блоки в snap1, записывает новые блоки в origin, помечает в метаданных проделанную работу, после чего считается, что в origin данные записаны.
Т.е. грубо говоря вместо одной операции записи блока происходит чтение и две записи. Это serious impact to performance.
Читаю тут про thin-provisioning, похоже они как-то хотят решить эту проблему, но я ещё не понял как.
Я немного параноик — мне спокойнее, когда у меня на удалённом бэкап-сервере лежат не только актуальные данные, но и так же снапшоты важных томов, в зависимости от важности на каждый час/день/неделю/месяц. Пока не пригодилось :) Хватало снапшотов на боевом сервере. Но в случае, когда на основном сервере старые снапшоты уйдут в утиль из-за периодической чистки для поддержания нужного объёма свободного места, эти снапшоты останутся на бэкап-сервере значительно дольше. Могут пригодится.
Насколько я понимаю проблема падения производительности как раз при записи в оригинальное блочное устройство, ибо идея снапшотов лвм такова, что при изменении блока в оригинальном устройстве сначала этот блок читается, потом переносится в созданные снапшоты и после записывается в оригинальное устройство.
По поводу вашей ссылки — я понял так, что человек бэкапит базу на том который несколько раз заснапшотен и при этом пытается измерить скорость чтения с тома. Оригинальная методика, но не понятно почему надо чесать ухо пяткой.
Я даже не могу представить где можно использовать такой алгоритм, чтобы не навредить перформансу. Получается, что часто и много делать снапшотов попросту нельзя — из-за высокого I/O умрёт любая дисковая система при уже некотором количестве снапшотов. Наличие снапшотов по итогу дорого обходится в отличии от zfs.
Ознакомился, понял что такое persistent и non-persistent.
Я постараюсь держать себя в руках.
Понимаете, именно добираясь до принципов реализации каких-то фич, можно апроксимировать поведение системы в целом, очень неплохо учитывать особенности реализации для понимания того как и почему именно так работает система.
Мы лишь пока про снапшоты говорим.
На что вам нужны объяснения? Я готов пообщаться.
Мы пытаемся обсуждать снапшоты там и там.
Мой вопрос такой — решена ли проблема с падением производительности на блочном устройстве с которого снят один или особенно несколько снапшотов?
Моё мнение такое — выбранная схема снапшотинга в лвм ужасна более чем полностью. Но я подозреваю, что остальные способы ещё хуже. Могу сообщить, что снэпшоты зфс не имеют проблем существующих у лвм.
Взято отсюда.
Как я понял CoW имеется в виду именно процесс создания снапшота, т.е., например, при изменении оригинала изменённые блоки уезжают в созданное блочное устройство, которое и является снапшотом?
Если всё так и есть, то уже можно прекратить обсуждать LVM и снапшоты ибо это не просто костыль, это сильно мягко выражаясь — обманка.
ну, например, инкрементальный send/recv с воссозданием абсолютно идентичной иерархии тома с его снапшотами
я не представляю сколько сил надо чтобы на rsync+block device такое запилить, в zfs — из коробки
я быстренько пробежался в гугле про принцип lvm snapshot'ов и коротко уже высказал своё мнение, простите, но это — ужас-ужас
ага, именно так, но дедупликация не при чём, вопрос в том как устроена система, в zfs создание, восстановление или клон снапшота это атомарная мгновенная операция, которую можно представить в виде перенаправления указателя актуальных данных на нужную ветку дерева
ничего готового для использования нет, я лишь про это
спасибо
Изнчально LVM это костыли впихиные в парадигму Linux.
Я не силён в LVM и особенно в их снапшотах, через это могу лишь задавать вопросы:
— насколько дорого сделать снапшот в LVM?
— является ли снапшот LVM новым файлом/директорией в плоскости фс или это некий новый объект?
— есть ли send/recevie снапшотов между томами/по сети? (rsync немного не то — лишь малая часть zfs send/recv)
— дорого ли восстанавливать том из снапшота?
— можно ли и как дорого создать новый том из снапшота?
— в zfs существует фича ".zfs" — некая виртуальная директория, где перечислены все созданные снапшоты, я делаю её видимой для пользователей и у меня нет проблем с вопросами типа — «восстанови мне вчерашний файл», есть ли такое в LVM?
Навскидку.
Вот это хочется пощупать, да.
Всех ведущих, за спинами которых торчат не уши гиков, но денежные мешки, можно пересчитать по пальцам одной руки на которой может не хватать пары пальцев.
Будем посмотреть куда это всё пойдёт.