|
|
|
June 11th, 2013
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 для решения около-хостинговых задач.
|
![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | 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]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 11th, 2013 06:17 pm (UTC) |
|---|
| | | (Link) |
|
ну, лвм - это такая штука, которую вообще никогда не надо использовать.
ploop то, в целом, неплохая идея для решения некоторых задач. Правда совсем не для тех, которые описаны по ссылке. ![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | 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]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 11th, 2013 06:18 pm (UTC) |
|---|
| | | (Link) |
|
> Выводы неправильные.
В Интернете кто-то не прав :)
![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 11th, 2013 06:21 pm (UTC) |
|---|
| | | (Link) |
|
Выводы правильные в контексте определенного круга задач.
Да, грустно мне от такого. Кто-нибудь ведь прочитает и реально начнет так делать. Например, в одной компании тут, которая аутсорсит часть администрирования нам, вот так вот и делают, только с lvm. Рыдают от этого потом все. ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 11th, 2013 06:28 pm (UTC) |
|---|
| | | (Link) |
|
btw, вот я тут читал, смотрел и так и не понял.
Мне в контексте шаред хостинга бывает нужно взять две вдс, остановить обе, переместить файлы из одной в другую, запустить другую, поправить там права на файлы, жить дальше. Ключевой момент - перенести, потому что так быстро, а копировать любым способом - их миллионы и медленно.
Я правильно понимаю, что с ploop так сделать никак нельзя? ![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 12th, 2013 01:09 am (UTC) |
|---|
| | | (Link) |
|
Конечно, пилупы для разных контейнеров разные, поэтому будет копирование с удалением, а не перенос.
Однако, если есть такой сценарий, когда есть файлы, которые быстро нужны (пусть в разное время) на разных контейнерах, имеет смысл держать их отдельно и подмонтировать в контейнер по необходимости (можно в том числе и на отдельном пилупе держать). Тогда и переносить ничего не надо будет вообще.
> Я правильно понимаю, что с ploop так сделать никак нельзя?
В свете вышесказанного ответ отрицательный.
![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | 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]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 12th, 2013 06:38 am (UTC) |
|---|
| | | (Link) |
|
> Сценарий чуть другой
Ну тогда бы я, например, запустил rsync для копирования, причём в два этапа -- первый раз пока оно ещё работает, а второй после стопа. По времени второй rsync должен занять немного, а время первого вроде как не должно быть особенно критично.
Как вариант -- можно посинкать на ноду и превратить в байнд маунт, а после того, как всё утрясётся, обратно посинкать в контейнер (или так оставить).
> Вторая задача
В общем-то, rsync вполне справляется и с пилупными файлами, единственно, что нельзя использовать опцию --sparse. То есть можно иметь "почти актуальные" файлы и быстрый синк (который, кстати, с пилупом должен быть заметно быстрее для случая vzmigrate --live).
Описанное про rsnapshot очень похоже на ploop snapshots, включая "делать инкрементальные бекапы" и " иметь много состояний вдс на удалённом сервере, причём они будут занимать очень мало места".
> снижение скорости при увеличении числа снапшотов
Не меряли (или я ничего про это не знаю). Знаю, что при разработке пилупа высокая производительность была одной из важных целей, думаю (это голословно, ничем подтвердить не могу), что на 18% оно ну никак не может упасть.
![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 12th, 2013 07:25 am (UTC) |
|---|
| | | (Link) |
|
1 - да, это очевидное решение, но вариант без ploop-а удобен тем, что делается сразу и быстро, а рсинк на каталоге с миллионами файлов (увы, но встречается чуть ли не каждый второй раз) - это надолго.
--- Нигде не могу найти - а какой размер блока у плупных образов? Он как-то коррелирует с фактическим на диске? Его можно задавать вручную (нужно, если все лежит где-то на iscsi)? Делаются ли там какие-то выравнивания на размер блока (если надо, не уверен)? И если это обычный блочный девайс, то можно ли внутри одного плуп контейнера иметь несколько разделов с разными фс? И если можно, то что с выравниванием, включая выравнивание начала разделов в этом случае?
При операциях ресайза и подобного - как-то можно управлять нагрузкой на диск/приоритетами? Чтобы в продакшене ресайз одного контейнера не сделал плохо остальным. ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 12th, 2013 07:37 am (UTC) |
|---|
| | | (Link) |
|
> Не меряли (или я ничего про это не знаю).
А вообще хоть какие-то тесты делались? Хотя бы пустой сервер, одна запущенная вдс, обычная simfs vs ploop. ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 11th, 2013 06:30 pm (UTC) |
|---|
| | | (Link) |
|
> Выводы неправильные.
А какие должны быть выводы?
Вообще весь этот ploop выглядит как маркетинговый bullshit, я не задумываясь вспоминаю кучу кейсов, когда профита от него было бы ноль, а вред очевиден; и с некоторым трудом могу придумать технические случаи, когда с ploop лучше. ![[User Picture]](https://l-userpic.livejournal.com/52636597/4800177) | | From: | shpagin |
| Date: | June 11th, 2013 08:25 pm (UTC) |
|---|
| | | (Link) |
|
Маркетинговый bullshit у тебя в голове. Иди учи мат часть. Как ты надоел со своими выводами. На затравку вот тебе первый профит, на ploop начинают хорошо работать io приоритеты и sync. Когда много контейнеров на одной файловой системе, то общий журнал мешает это делать. ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 12th, 2013 03:53 am (UTC) |
|---|
| | | (Link) |
|
А почему вот это не написано в понятном виде в вики? Ведь это же реально хороший момент.
Почему нету таблички вида "тут - плохо, там - хорошо"? Если нельзя написать непозитивное слово "плохо" - можно заменить его на "not so good". ![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 12th, 2013 06:05 am (UTC) |
|---|
| | | (Link) |
|
![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 12th, 2013 01:17 am (UTC) |
|---|
| | | (Link) |
|
> А какие должны быть выводы?
Самая большая проблема с общей файловой системой -- это общий журнал. Мало того, что в него может упереться вся дисковая активность всех контейнеров, так это ещё можно и спровоцировать, написав программку, которая будет генерировать много апдейтов метаданных. В ядре журнальный тред один, решить эту проблему без отдельной файловой системы крайне сложно.
Вторая проблема -- это отсутствие дисковых квот на каталог. Мы её решили штукой под названием vzquota (это подсистема ядра). А проблема-то по сути надуманная, если есть отдельные фс, то и квотировать ничего не надо.
Третья -- изменение номеров айнодов при миграции через rsync.
Четвёртая -- контейнер на NFS
Ну и ещё что-то там.
Маркетинговый булшит бывает тогда, когда надо что-то продавать, а продавать нечего. И тогда начинается выдавливание чего-то из ничего.
Вы серьёзно считаете, что вот так вот, ради какого-то маркетинга, люди сядут и будут писать довольно сложную подсистему ядра? ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 12th, 2013 04:26 am (UTC) |
|---|
| | | (Link) |
|
> А проблема-то по сути надуманная, если есть отдельные фс
Кстати, а оно там вообще отдельный блочный девайс внутри? Можно форматировать в любую ФС или как?
> Маркетинговый булшит
Это то, как воспринимается текст на сайте, когда его читает не kernel hacker (читающий, видимо, параллельно исходники). Вот все эти комменты в этом посте - спасибо за них, эти темы никак нигде не освещены, я чуть позже напишу по их мотивам отдельный понятный пост. Но, мне кажется, хорошо бы обо всем этом более подробно рассказать в вики про ploop.
Люди нередко без всякого смысла пишут сложные вещи, которые дорого стоят. Я уже давно перестал подобному удивляться, такое просто бывает. ![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | 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]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 11th, 2013 06:17 pm (UTC) |
|---|
| | | (Link) |
|
AUFS сломалась из-за улучшений не для ploop, а для FUSE (насколько я понимаю). Патчи для FUSE мы успешно вливаем в апстрим. ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 11th, 2013 06:26 pm (UTC) |
|---|
| | | (Link) |
|
мне тут показались примечательными два момента:
1) AUFS сломалась
2) это таки был монолог
1 было бы нормальным, если бы не 2. Но таки и 1 и 2 и монологами вообще форум полон. ![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | From: | k001 |
| Date: | June 12th, 2013 01:04 am (UTC) |
|---|
| | | (Link) |
|
Я не знаю, какими ещё буквами написать, что баги надо в багзиллу постить. ![[User Picture]](https://l-userpic.livejournal.com/31903506/3699140) | | From: | knutov |
| Date: | June 12th, 2013 03:59 am (UTC) |
|---|
| | | (Link) |
|
Я, наверное, чего-то не понимаю. Захожу на http://forum.openvz.org. Вижу два раздела, для которых написано баги туда не писать. Вижу два зеркала рассылки. Вижу три форума на местных языках, где про неписание багов ничего не указано. Исходя из чего у людей должно сложится понимание, что в русский форум не надо писать про баги? Ну и, я бы внутри форума прямо в шапке большими бы буквами красным текстом написал о. И у людей сразу появится понимание. А учитывая, что у вас багзилла, которая юзерфрендли чуть менее, чем совсем никак - пошаговая инструкция вида "file bug in 3 steps" сделала бы всем хорошо. Лучше с картинками ) ![[User Picture]](https://l-userpic.livejournal.com/50213010/990679) | | 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, накладывать патчи на ядро и тому подобное.
Для всех тех, кто не может, не хочет, не готов и так далее -- есть коммерческий продукт, с документацией, обучением, специально обученным саппортом, гарантиями на ответ и так далее. Это вовсе не значит, что если ты не платишь денег, то всё должно быть сложным, глючным, тупым, недокументированным. Это значит, что если ты не платишь денег -- будь готов вместо этого вложить своё время, умственные усилия и так далее. За ручку никто водить не будет, это не богадельня. |
|