Top.Mail.Ru
ploop - Меркантильный гуру — LiveJournal
? ?
Меркантильный гуру

> Recent Entries
> Archive
> Friends
> Profile
> knutov.com

June 11th, 2013


Previous Entry Share Flag Next Entry
02:21 pm - ploop

В общем, ploop - это такой LVM для опенвз - http://openvz.livejournal.com/44508.html

Причем, не без сайд эффектов - чудесный монолог про сломавшуюся aufs. А у dmih с spiculator есть даже чудесная теория почему оно монолог :)

Что в итоге имеем - с ploop есть профит, если требуется частая миграция вдс и если в вдс очень очень много мелких файлов.

От всего остального сплошные минусы (в контексте около-хостинговых задач), как, собственно, и в случае с LVM.

Особенно я начал рыдать, когда по первой ссылке начали предлагать делать снапшоты в "scenario: you need to upgrade your web site backend inside your container".

Итог, если кратко - не используйте ploop для решения около-хостинговых задач.


Tags:

(23 comments | Leave a comment)

Comments:


[User Picture]
From:k001
Date:June 11th, 2013 06:15 pm (UTC)
(Link)
LVM limitations
• Not flexible enough – works only on top of block device (ploop works over nfs etc.)
• Hard to manage (e.g. how to migrate huge volume?)
• No dynamic allocation (--virtualsize 16T --size 16M)
• Management is not as convenient as for files
[User Picture]
From:knutov
Date:June 11th, 2013 06:17 pm (UTC)
(Link)
ну, лвм - это такая штука, которую вообще никогда не надо использовать.

ploop то, в целом, неплохая идея для решения некоторых задач. Правда совсем не для тех, которые описаны по ссылке.
[User Picture]
From:k001
Date:June 11th, 2013 06:17 pm (UTC)
(Link)
> Что в итоге имеем - с ploop есть профит, если требуется частая миграция вдс и если в вдс очень очень много мелких файлов.

Выводы неправильные.

> Особенно я начал рыдать, когда по первой ссылке начали предлагать делать снапшоты в "scenario: you need to upgrade your web site backend inside your container".

А что так? Эта часть у меня получилась особенно печальной, или что?

[User Picture]
From:k001
Date:June 11th, 2013 06:18 pm (UTC)
(Link)
> Выводы неправильные.

В Интернете кто-то не прав :)
[User Picture]
From:knutov
Date:June 11th, 2013 06:21 pm (UTC)
(Link)
Выводы правильные в контексте определенного круга задач.

Да, грустно мне от такого. Кто-нибудь ведь прочитает и реально начнет так делать. Например, в одной компании тут, которая аутсорсит часть администрирования нам, вот так вот и делают, только с lvm. Рыдают от этого потом все.
[User Picture]
From:knutov
Date:June 11th, 2013 06:28 pm (UTC)
(Link)
btw, вот я тут читал, смотрел и так и не понял.

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

Я правильно понимаю, что с ploop так сделать никак нельзя?
[User Picture]
From:k001
Date:June 12th, 2013 01:09 am (UTC)
(Link)
Конечно, пилупы для разных контейнеров разные, поэтому будет копирование с удалением, а не перенос.

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

> Я правильно понимаю, что с ploop так сделать никак нельзя?

В свете вышесказанного ответ отрицательный.
[User Picture]
From:knutov
Date:June 12th, 2013 04:20 am (UTC)
(Link)
Сценарий чуть другой - есть вдс, решающая околохостинговые задачи. Убунта старая, а то и вообще федора 3-4, администрируется непонятно как и кучей людей. Владелец нанимает нормальных админов, например нас, мы делаем новую пустую вдс, ставим туда свою сборку околохостингового софта с автогенерацией конфигов и прочего. Надо быстро перенести /home (часто - только часть /home) со старой вдс.

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

Нам регулярно приходится решать именно эту задачу. Несколько раз в месяц.

---

Вторая задача, которую я не вижу как хорошо решить с ploop: есть два сервера в ДЦ. Я могу перекидывать роутинг ип между ними снаружи. Мне нужно обеспечить возможность обновления серверов без даунтайма работащих на них проектов и/или наличие (почти) самого свежего бекапа на втором сервере.

Я это делаю через rsync и/или rsnapshot для /vz

При запланированных работах на одном сервере я, уже имея почти актуальные файлы на втором сервере могу быстро(!) пересинкать и рестартовать/vzmigrate live все вдс на втором сервере и ребутить первый.

С rsnapshot я могу делать инкрементальные бекапы с хардлинками и иметь много состояний вдс на удалённом сервере. Причем они будут занимать очень мало места - если файл не изменился - будет хардлинк на предыдущую версию.

Правильно ли я думаю, что с ploop это сделать не получится, если я буду делать бекапы на уровне /vz ноды, а не поштучно на уровне самих вдс?

---

3) Для LVM и ZFS характерно значительное снижение скорости при увеличении числа снапшотов. В тестах скорость падает уже при наличии хотя бы одного снапшота (если я правильно помню - для LVM примерно на 18%). Делались ли тестирования на эту тему для ploop?

[User Picture]
From:k001
Date:June 12th, 2013 06:38 am (UTC)
(Link)
> Сценарий чуть другой

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

Как вариант -- можно посинкать на ноду и превратить в байнд маунт, а после того, как всё утрясётся, обратно посинкать в контейнер (или так оставить).

> Вторая задача

В общем-то, rsync вполне справляется и с пилупными файлами, единственно, что нельзя использовать опцию --sparse. То есть можно иметь "почти актуальные" файлы и быстрый синк (который, кстати, с пилупом должен быть заметно быстрее для случая vzmigrate --live).

Описанное про rsnapshot очень похоже на ploop snapshots, включая "делать инкрементальные бекапы" и " иметь много состояний вдс на удалённом сервере, причём они будут занимать очень мало места".

> снижение скорости при увеличении числа снапшотов

Не меряли (или я ничего про это не знаю). Знаю, что при разработке пилупа высокая производительность была одной из важных целей, думаю (это голословно, ничем подтвердить не могу), что на 18% оно ну никак не может упасть.
[User Picture]
From:knutov
Date:June 12th, 2013 07:25 am (UTC)
(Link)
1 - да, это очевидное решение, но вариант без ploop-а удобен тем, что делается сразу и быстро, а рсинк на каталоге с миллионами файлов (увы, но встречается чуть ли не каждый второй раз) - это надолго.

---
Нигде не могу найти - а какой размер блока у плупных образов? Он как-то коррелирует с фактическим на диске? Его можно задавать вручную (нужно, если все лежит где-то на iscsi)? Делаются ли там какие-то выравнивания на размер блока (если надо, не уверен)? И если это обычный блочный девайс, то можно ли внутри одного плуп контейнера иметь несколько разделов с разными фс? И если можно, то что с выравниванием, включая выравнивание начала разделов в этом случае?

При операциях ресайза и подобного - как-то можно управлять нагрузкой на диск/приоритетами? Чтобы в продакшене ресайз одного контейнера не сделал плохо остальным.
[User Picture]
From:knutov
Date:June 12th, 2013 07:37 am (UTC)
(Link)
> Не меряли (или я ничего про это не знаю).

А вообще хоть какие-то тесты делались? Хотя бы пустой сервер, одна запущенная вдс, обычная simfs vs ploop.
[User Picture]
From:knutov
Date:June 11th, 2013 06:30 pm (UTC)
(Link)
> Выводы неправильные.

А какие должны быть выводы?

Вообще весь этот ploop выглядит как маркетинговый bullshit, я не задумываясь вспоминаю кучу кейсов, когда профита от него было бы ноль, а вред очевиден; и с некоторым трудом могу придумать технические случаи, когда с ploop лучше.
[User Picture]
From:shpagin
Date:June 11th, 2013 08:25 pm (UTC)
(Link)
Маркетинговый bullshit у тебя в голове. Иди учи мат часть. Как ты надоел со своими выводами. На затравку вот тебе первый профит, на ploop начинают хорошо работать io приоритеты и sync. Когда много контейнеров на одной файловой системе, то общий журнал мешает это делать.
[User Picture]
From:knutov
Date:June 12th, 2013 03:53 am (UTC)
(Link)
А почему вот это не написано в понятном виде в вики? Ведь это же реально хороший момент.

Почему нету таблички вида "тут - плохо, там - хорошо"? Если нельзя написать непозитивное слово "плохо" - можно заменить его на "not so good".
[User Picture]
From:k001
Date:June 12th, 2013 06:05 am (UTC)
(Link)
Почему не написано? Ажно в трёх местах написано, навскидку:
* https://openvz.org/Ploop/Why
* http://openvz.org/images/f/f3/Ct_in_a_file.pdf (слайды 6 и 7)
* http://openvz.livejournal.com/40830.html

[User Picture]
From:k001
Date:June 12th, 2013 01:17 am (UTC)
(Link)
> А какие должны быть выводы?

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

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

Третья -- изменение номеров айнодов при миграции через rsync.

Четвёртая -- контейнер на NFS

Ну и ещё что-то там.

Маркетинговый булшит бывает тогда, когда надо что-то продавать, а продавать нечего. И тогда начинается выдавливание чего-то из ничего.

Вы серьёзно считаете, что вот так вот, ради какого-то маркетинга, люди сядут и будут писать довольно сложную подсистему ядра?
[User Picture]
From:knutov
Date:June 12th, 2013 04:26 am (UTC)
(Link)
> А проблема-то по сути надуманная, если есть отдельные фс

Кстати, а оно там вообще отдельный блочный девайс внутри? Можно форматировать в любую ФС или как?

> Маркетинговый булшит

Это то, как воспринимается текст на сайте, когда его читает не kernel hacker (читающий, видимо, параллельно исходники). Вот все эти комменты в этом посте - спасибо за них, эти темы никак нигде не освещены, я чуть позже напишу по их мотивам отдельный понятный пост. Но, мне кажется, хорошо бы обо всем этом более подробно рассказать в вики про ploop.

Люди нередко без всякого смысла пишут сложные вещи, которые дорого стоят. Я уже давно перестал подобному удивляться, такое просто бывает.
[User Picture]
From:k001
Date:June 12th, 2013 06:12 am (UTC)
(Link)
> Кстати, а оно там вообще отдельный блочный девайс внутри? Можно форматировать в любую ФС или как?

Да (https://openvz.org/Ploop/readme#Mount). Но для всяких продвинутых операций, типа онлайн ресайза, мы поддерживаем только ext4 (ну и ext3, но она не нужна при наличии ext4).

> Но, мне кажется, хорошо бы обо всем этом более подробно рассказать в вики про ploop.

Я вроде как пытаюсь. Не знаю, что я делаю не так :) Тут вот, в частности, люди всерьёз писали, что OpenVZ умирает -- я показал им http://openvz.org/News/updates, объяснил, вроде поняли. Но я не один раз таких людей встречал.

> Люди нередко без всякого смысла пишут сложные вещи, которые дорого стоят.

Ну у нас, к счастью или к сожалению, нет для этого "лишних" инженеров -- все кернельщики ну почти что на вес золота. Да и ploop довольно сложная штука, её силами, скажем, двух толковых студентов никак не напишешь.
[User Picture]
From:k001
Date:June 11th, 2013 06:17 pm (UTC)
(Link)
AUFS сломалась из-за улучшений не для ploop, а для FUSE (насколько я понимаю). Патчи для FUSE мы успешно вливаем в апстрим.
[User Picture]
From:knutov
Date:June 11th, 2013 06:26 pm (UTC)
(Link)
мне тут показались примечательными два момента:

1) AUFS сломалась

2) это таки был монолог

1 было бы нормальным, если бы не 2. Но таки и 1 и 2 и монологами вообще форум полон.
[User Picture]
From:k001
Date:June 12th, 2013 01:04 am (UTC)
(Link)
Я не знаю, какими ещё буквами написать, что баги надо в багзиллу постить.
[User Picture]
From:knutov
Date:June 12th, 2013 03:59 am (UTC)
(Link)
Я, наверное, чего-то не понимаю.

Захожу на http://forum.openvz.org. Вижу два раздела, для которых написано баги туда не писать. Вижу два зеркала рассылки. Вижу три форума на местных языках, где про неписание багов ничего не указано.

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

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

А учитывая, что у вас багзилла, которая юзерфрендли чуть менее, чем совсем никак - пошаговая инструкция вида "file bug in 3 steps" сделала бы всем хорошо. Лучше с картинками )
[User Picture]
From:k001
Date:June 12th, 2013 06:23 am (UTC)
(Link)
Там прямо на главной странице написано, местами даже жирными и красными буквами:

> If you think you hit a bug in OpenVZ, the best place to file it is Bugzilla, not this forum.
> Do not file bugs here - use Bugzilla.
> Please always report your kernel and tools version.

Да, написано в разделе саппорт, потому что большинство людей идёт туда, но видно на главной и относится ко всему форуму. Ну нигде никто не файлит баги в форум, форум просто для этого не подходит, там нет трекинга и т.п.

> А учитывая, что у вас багзилла, которая юзерфрендли

Это обычная стоковая багзилла. Я ничего не хочу плохого ни про кого сказать, но если человек не сможет разобраться с багзиллой, то возможно, это и хорошо, что мы не получим от него баг, потому что если мы получим, это будет не баг-репорт, а чёрт-те что. Если файлишь баг -- надо не только через багзиллу пройти, но и уметь как-то там дебажить, быть готовым запускать strace, накладывать патчи на ядро и тому подобное.

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

> Go to Top
LiveJournal.com