Как сделать backup OpenVZ контейнера без downtime

> так все же - В ЧЕМ КРИВОСТЬ LVM? Не уходите от ответа

В том, что это не труЪ ынтырпрайс ЗетЭфЭс на труЪ ынтырпрайс венде^Wфрибзде, а какой-то ляликс :-) Просто их (бздунов и виндузятников) настолько долго лупили LVM, что у них начинается истерика каждый раз, когда они слышат эту аббревиатуру. А аргументов про то, что сделанный снапшот можно смонтировать и снять с него бэкап не только dd, но и например тем же самым dump, rsync и вообще чем угодно, они старательно будут "не услышивать".

> а если файл занимал 50 гигов а в нём изменились 50 байт?

Покажи методику резервного копирования средствами ZFS, по которой:
1. для файла в 50 гигабайт
2. в котором в процессе работы изменится < 1 килобайта
3. для бэкапа этого файла НА ДРУГОЙ НОСИТЕЛЬ ИЛИ НА ДРУГОЙ СЕРВЕР
4. не нужно прибегать к однократному копированию всего файла и затем копированию "дельт"
ZFS snapshot бэкапом не считается, ибо оно ложится на той же ФС и тех же устройствах что и сами данные.

> я уже около трех раз в лоб спросил: в чем кривость LVM?

На разделе 50-100 VPS - нужна ОДНА!

И нафига снапшот всех 100 штук? Конечно, можно и через жопу, но зачем?!!

> почему LVM не соединить с FS и не бекапить одной командой?

Потому, что это не нужно. НЕ НУЖНО. Задача снапшота - сделать замороженную копию данных на некоторый момент.

> а зачем столько движений?

Не путай задачи разведения фермы "примерно одинаковых" ФС/разделов и задачу резервного копирования, поскольку первая задача всегда локальна, вторая всегда распределенная.

>ZFS snapshot бэкапом не считается, ибо оно ложится на той же ФС и тех же устройствах что и сами данные.

зато ZFS send отсылает снапшот именно по количеству занятых данных а не по размеру скажем квоты, выделенной на данный раздел. сама бля. без ансамбля. без необходимости что-то маунтить, дрочить rsync'и, писать скрипты, ломать голову и плакать когда наступил "странный частный случай и бекап не прошел" именно в тот момент когда рейд по стечению обстоятельств йобнулся потому что очередной дибил из hardware ops опять уронил отвёртку.

> без необходимости что-то маунтить, дрочить rsync'и, писать скрипты, ломать голову

Понятно, специально для дебилов.

Но все же - как с помощъю ZFS забэкапить ОДНУ VPS на разделе?

> ломать голову и плакать когда наступил "странный частный случай и бекап не прошел"

Ыыыыы... Мы-то это переживем - у нас есть предыдущие бэкапы, а вы? http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00290.html

>В ЧЕМ КРИВОСТЬ LVM?

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

Когда снапшоты делаются на уровне файловой системы это выполняется автоматически. LVM нужны дополнительные манипуляции. Хотя сейчас вроде он заставляет файловые системы дописать буфера перед тем как делает снимок. По крайней мере ext3 и xfs.

>В ЧЕМ КРИВОСТЬ LVM?

Знаешь как работает COW в снапшоте? ФС хочет записать блок на диск. LVM проверяет есть скопирован ли он, если нет - то он:

1. Читает этот блок.

2. Пишет прочитанный блок в снапшот

3. Пишет блок от ФС.

Производительность записи падает как минимум в 3!! раза, в реальности из-за дрыганья головок диска ещё больше.

> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00290.html

current system is BETA1 r195422M, вопросы?

> Знаешь как работает COW в снапшоте?

Страшная тайна - а знаешь ли ты, что так работают _все_ снапшотилки ? :-)

> current system is BETA1 r195422M, вопросы?

Удаление слова BETA влияет на что-нибудь? Если глюк случится в ZFS - а он случится, такие монстроидальные нагромождения кода не бывают безошибочными в принципе (если уж Sun допускали баги в коде telnet и icmp, в ZFS баги есть 100%) - что тогда ты будешь делать? Будешь сидеть без бэкапов пока не закроют баг, в надежде что не потребуется восстановиться?

Чем проще каждый компонент, тем надежнее система компонентов. rsync, tar, dd и прочие просты как пробки - там тупо неоткуда взяться глюкам, приводящим к потере данных. А в ZFS любой вовремя незамеченный глюк способен привести весь сторадж в неконсистентное состояние.

>а знаешь ли ты, что так работают _все_ снапшотилки ?

Отнюдь не все. В случае снапшотов ZFS или MVCC транзакций postgresql, новые данные пишутся в новое место. А старые не удаляются (считаются занятыми) до тех пор, пока они принадлежат снапшоту, или их не отпустит транзакция.

И в Btrfs сделано также, насколько я понимаю.

> новые данные пишутся в новое место

1. Это не COW

2. Фрагментация! В COW-based снапшоте тот же ораклячий даатфайл, который специально создавался заданного размера чтобы быть нефрагментированным, окажется фрагментированным после первого же мало-мальски серьезного апдейта по таблице, а это весьма и весьма плохая идея - не дать скорости "прогнуться" на время снапшота это конечно хорошо, но получить тотальное поражение от фрагментации на все оставшееся время существования файла - это гораздо хуже. Оракловцы в целях последующего performance делают именно чистый COW - пишут старые данные в специально отведенное место.

Ничего плохого. Не только снапшоты не снижают проиводительность, но и хорошая устойчивость к внезапным отключениям при такой организации COW. Это именно копирование при

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

И всё хорошо, и данные не фрагментированы и снапшоты не тормозят.

>> current system is BETA1 r195422M, вопросы?
>Удаление слова BETA влияет на что-нибудь?

сравнивать стабильный продукт с бетой находящейся в активной стадии допиливания - очень очень странно

> Фрагментация, да

Когда мы училисб на курсах по тюнингу производительности БД, там проводили один простой тест - скорость чтения данных последовательная, параллельная в несколько потоков и рандомная в несколько потоков маленькими кусками (примерно по 64 килобайта кусок). Скорость чтения с диска "в лоб" составляет порядка 40 мегабайт в секунду, в третьем случае (а это как раз эмуляция фрагментакии она составляла 4 мегабайта в секунду. В ZFS дефрагментатор уже сделали? :-)

> сравнивать стабильный продукт с бетой находящейся в активной стадии допиливания - очень очень странно

Сколько не пилите - "Тестирование способно доказать наличие ошибок, но не их отстутсвие". Аксиома разработки.

> В том, что это не труЪ ынтырпрайс ЗетЭфЭс на труЪ ынтырпрайс венде^Wфрибзде, а какой-то ляликс :-) Просто их (бздунов и виндузятников) настолько долго лупили LVM, что у них начинается истерика каждый раз, когда они слышат эту аббревиатуру. А аргументов про то, что сделанный снапшот можно смонтировать и снять с него бэкап не только dd, но и например тем же самым dump, rsync и вообще чем угодно, они старательно будут "не услышивать".

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

'zfs send' работает в ядре и контекст не переключает.

или и тут спорить будете?

Да, кстати, в ZFS есть выбор - монтировать снапшоты или нет. А с LVM'ом выбора нету - только монтировать.

Даже больше - явно монтировать снапшоты может быть вовсе не нужно, можно сделать их доступными через .zfs/snapshot/ в корне соответствующей файловой системы. Их, кстати, даже создавать так можно:

cd .zfs/snapshot mkdir now

И даже через NFS/CIFS.

Внимание вопрос. Как долго придется интегрировать LVM, ext[34]/XFS/что-там-еще, NFS в линуксе, прежде чем это заработает?

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

>> почему LVM не соединить с FS и не бекапить одной командой?

>Потому, что это не нужно. НЕ НУЖНО. Задача снапшота - сделать замороженную копию данных на некоторый момент.

Нужно или не нужно - это кому как больше нравится. Кому-то нравиться когда проще, кому-то - когда сложнее. В любом случае сделать сложно - легко, а вот сделать просто - гораздо труднее. В любом случае, 'zfs send' сам снимки не делает - нужно предварительно создать либо с помощью "zfs snapshot", либо как показано выше

>> Знаешь как работает COW в снапшоте?

> Страшная тайна - а знаешь ли ты, что так работают _все_ снапшотилки ? :-)

Утверждение слишком сильное, чтобы быть корректным.

>> новые данные пишутся в новое место

>1. Это не COW

Как впрочем и это.

> 2. Фрагментация! В COW-based снапшоте тот же ораклячий даатфайл, который специально создавался заданного размера чтобы быть нефрагментированным, окажется фрагментированным после первого же мало-мальски серьезного апдейта по таблице, а это весьма и весьма плохая идея - не дать скорости "прогнуться" на время снапшота это конечно хорошо, но получить тотальное поражение от фрагментации на все оставшееся время существования файла - это гораздо хуже. Оракловцы в целях последующего performance делают именно чистый COW - пишут старые данные в специально отведенное место.

У вас есть реальные данные о степени пагубности влияния фрагментации датафайлов на производительность? Поделитесь пожалуйста, а? А то все про это говорят-говорят, а стоит цыферки попросить - ныряют под корягу.

Может у вас просто кэш слишком маленький и приходится слишко часто на диск ходить? Или больше памяти в супер-пупер систему на Интеле запихнуть нельзя? Дык есть и более другие решения даже для таких ограниченных архитектур, как Интеловая ;-)

> Если глюк случится в ZFS - а он случится, такие монстроидальные нагромождения кода не бывают безошибочными в принципе

Боюсь, что слухи о монстроидальности ZFS сильно преувеличены. Вот специально взял прикинул количестви строк в исходниках кернельной части ZFS (линукс же это ядро, так что строки кода в командах считать не будем) и в LVM/Ext4/jbd2, включая специфические хедеры.

Получилось ~87500 в случае ZFS и ~87000 в случае LVM/Ext4/JBD2. LVM/Ext3/JBD немногим меньше.

Есть вопросы у матросов?

А насчет багов - так они везде есть. И в LVM и всем зоопарке ФС в линукс.

> Будешь сидеть без бэкапов пока не закроют баг, в надежде что не потребуется восстановиться?

а в линуксе что будешь делать? а если это rhel3/4 и обновиться ну никак? Или в линуксе багов нет по определению - любой глюк это такая фича?

> Чем проще каждый компонент, тем надежнее система компонентов. rsync, tar, dd и прочие просты как пробки - там тупо неоткуда взяться глюкам, приводящим к потере данных.

Глюкам тупо ест ьоткуда взяться в той обвязке, которая вокруг всего этого можно построить. И потом, что у ZFS posix-интерфейс уже отменили? или все перечисленные вами вещи на ней не работают?

> А в ZFS любой вовремя незамеченный глюк способен привести весь сторадж в неконсистентное состояние.

Ню-ню. Сказка про белого бычка. Кажется тут где-то приводили примеры, как ZFS обнаруживала глюки, а связка LVM/Ext3 нет. Или это не считается?

Кстати, BTRFS тоже должна это уметь делать.

Ах, как я мог забыть, у вас же принципы :-)

> У вас есть реальные данные о степени пагубности влияния фрагментации датафайлов на производительность?

# ./demoio /dev/sda1 1
Test with blocksize 1048576 ... roundcount 100, 4 seconds
Test with blocksize 262144 ... roundcount 400, 9 seconds
Test with blocksize 65536 ... roundcount 1600, 16 seconds
Test with blocksize 16384 ... roundcount 6400, 56 seconds
Test with blocksize 4096 ... roundcount 25600, 222 seconds

demoio - это маленькая учебная программка, которая читает из первых 40 гигабайт указанного в качестве параметра устройств 100 мегабайт данных в случайном порядке, делая seek после каждого прочтенного блока, чтобы симулировать фрагментацию. Размер блока и количество seek'ов указаны в выводе. Комментарии, думаю, излишни (да, 1 после имени файла это количество копий).

> Или больше памяти в супер-пупер систему на Интеле запихнуть нельзя?

Ну, на домашнем компе и на рабочей станции у меня "всего-то" 1.6 и 1.2 терабайта соответственно. На сервере столько же, но уже RAID0+1. Могу я попросить тебя дать ссылочку на сервер, который это удержит в памяти, хотя-бы даже и не-Intel?

> demoio - это маленькая учебная программка, которая читает из первых 40 гигабайт указанного в качестве параметра устройств 100 мегабайт данных в случайном порядке, делая seek после каждого прочтенного блока, чтобы симулировать фрагментацию. Размер блока и количество seek'ов указаны в выводе. Комментарии, думаю, излишни (да, 1 после имени файла это количество копий).

В том то и дело, что это маленькая демо программка. У меня у самого таких программок вагон и маленькая тележка.

За данные о работе реальной системы, к сожалению, не канает.

> Ну, на домашнем компе и на рабочей станции у меня "всего-то" 1.6 и 1.2 терабайта соответственно. На сервере столько же, но уже RAID0+1. Могу я попросить тебя дать ссылочку на сервер, который это удержит в памяти, хотя-бы даже и не-Intel?

Речь шла не упихивании всей базы в память, а о увеличении размеров ее кэша, при котором, ясен перец, рано или поздно упрешься в архитектурные ограничения платформы. Так что мимо кассы.

> За данные о работе реальной системы, к сожалению, не канает.

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

> Речь шла не упихивании всей базы в память, а о увеличении размеров ее кэша

HP DL500-е - 128/256 гигабайт, спарки T5XYZ - 128/256 гигабайт, T5440 - 512GB. Не вижу кардинального прорыва.

>> За данные о работе реальной системы, к сожалению, не канает.

> Что, начались отмазки про "реальные системы"? Я уже привел реальные цифры, ты не смог привести ни одного арумента, кроме "а вот я думаю...". Пока ты не сможешь показать реальные цифры для одного и того же устройства с известной степенью фрагментации читаемых данных (размер непрерывного блока, количество seek потребных для чтения и т.п.), продолжать обсуждение смысла нет.

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

>> Речь шла не упихивании всей базы в память, а о увеличении размеров ее кэша

> HP DL500-е - 128/256 гигабайт, спарки T5XYZ - 128/256 гигабайт, T5440 - 512GB. Не вижу кардинального прорыва.

Да, отстал от жизни. Но на Sun Fire T5440 SPARCи не заканчиваются, хотя дальше уже монстры и там другие системы сравнивать надо.

Ладно, значит уперлись примерно в 256 ГБ там и там. Но вот с ZFS можно легко и просто использовать SSD с медленной записью но быстрым чтением в качестве дополнительной иерархии кэша (ReadZilla), причем что на SPARC'е, что на X64. А что нам может предложить связка LVM+линуксовая ФС?

> Я задал конкретный вопрос, а вы вместо конкретного ответа, что у вас таких данных нет

Датафайлы. Самые обычноые, оракловские датафайлы.

> или вместо данных вашего исследования о катастрофическом влиянии фрагментации датафайлов на работу базы данных вы подсовываете результаты работы программки

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

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

Прямо влияет. На sort-on-disk, на seqential read, на sequential writes.

> Но на Sun Fire T5440 SPARCи не заканчиваются, хотя дальше уже монстры и там другие системы сравнивать надо.

Ссылку в студию. Или название модели. Нет ссылки - нет модели.

> А ведь это вы у нас тут кроме баз данных других приложений не мыслите

А для чего еще нужны огромные дисковые объемы с высокой производительностью? Меряться членами на ЛОРе?

> Но вот с ZFS можно легко и просто использовать SSD с медленной записью но быстрым чтением в качестве дополнительной иерархии кэша (ReadZilla)

Флуд. Цифры в студию.

Сударь, вроде бы мы договорились не продолжать, а вам неймется. Давайте еще раз.

>> Я задал конкретный вопрос, а вы вместо конкретного ответа, что у вас таких данных нет

>Датафайлы. Самые обычноые, оракловские датафайлы.

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

>> или вместо данных вашего исследования о катастрофическом влиянии фрагментации датафайлов на работу базы данных вы подсовываете результаты работы программки

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

Треп - это, извините, у вас. Я нигде не утверждал, что никакого влияния не будет. Если утверждал - покажите где. И лпровергать я никого не собираюсь. Я просто усмонился в обоснованности вашего заявления насчет "тотальности поражения". Что ж, вы наглядно показали, что оно не обосновано.

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

> Прямо влияет. На sort-on-disk, на seqential read, на sequential writes.

Это-то понятно. Как оно количественно влияет? Речь - об этом, а не о том, что не влияет вообще.

>> Но на Sun Fire T5440 SPARCи не заканчиваются, хотя дальше уже монстры и там другие системы сравнивать надо.

>Ссылку в студию. Или название модели. Нет ссылки - нет модели.

Странный вы ей-богу. M9000-64 - что, не SPARC чтоли? Но и сравнивать его с DL580 тоже неправильно. Надо сравнивать с более другими системами :-)

>> А ведь это вы у нас тут кроме баз данных других приложений не мыслите

> А для чего еще нужны огромные дисковые объемы с высокой производительностью? Меряться членами на ЛОРе?

Да много для чего. Научные расчеты всякие, геофизика, расшифровка генома и так далее.

>> Но вот с ZFS можно легко и просто использовать SSD с медленной записью но быстрым чтением в качестве дополнительной иерархии кэша (ReadZilla)

> Флуд. Цифры в студию.

Вроде речь была не о цифрах, а о технической возможности. Ну если вы так уж хотите цифр - то вот тут есть:

http://blogs.sun.com/brendan/entry/l2arc_screenshots

Только, извиняйте, не про ваши любимые базы данных.

> Ну если вы так уж хотите цифр - то вот тут есть

Друг вы наш настойчивый, на 8 дисках в raid 0+1 (не на 140, на 8 дисках!) тесты выдают порядка 3000 операций в секунду при 40 паралельно оперирующих нитях. Вы уж извините, но если апроксимировать это на 140 дисков, как в примере по сслыке, то 17000 ops/second смотрятся как-то не особо впечатляюще.

Увы - 140 дисков в наличии нет чтобы проверить, а на своих жалких 16 шпинделях я смог отжать всего лишь 5000 операций в секунду :-( Хотя есть некоторая надежда, что на 100 шпинделях получится снять 20000 операций в секунду. К счастью, ребята из VMWare были так добры, что выложили результаты своих тестов - http://blogs.vmware.com/performance/2008/05/100000-io-opera.html

Да, у VMWare на 480 шпинделей (в три раза больше чем у Sun), но получилось 100k ops/second против 17k у Sun (в пять раз больше), при этом R/W соотносилось у VMWare 50/50 (в Sun только чтение), с латентностью 8ms - у Sun она 10ms. Ой как грустно... При чем тут линукс? А при том, что VMWare ESX это гипервизор и Dom0-линукс :-) Так что извиняйте - пока что видно, что как только дело доходит до сравнений в более-менее равных конфигурациях, Sun начинает стекать в осадок. L2ARC не помогает.

> Друг вы наш настойчивый, на 8 дисках в raid 0+1 (не на 140, на 8 дисках!) тесты выдают порядка 3000 операций в секунду при 40 паралельно оперирующих нитях. Вы уж извините, но если апроксимировать это на 140 дисков, как в примере по сслыке, то 17000 ops/second смотрятся как-то не особо впечатляюще.

В вас определенно пропадает бенчмаркетер! Это так типично - мимоходом перескакивать с одного на другое, сравнивать горячее с тихим, опускать существенные детали.

Например, о каких дисках ведете речь вы? В примере по ссылке - 7200 RPM SATA. Что-то я сомневаюсь, что вы получите 3000 IOPS с размером блока 8К с 8 дисков SATA 7200RPM. Ведь в ваших тестах (где результаты, кстати) размер блока тоже 8К, не так ли?

Затем, в примере по ссылке речь идет о тестировании с 10 клиентов по два потока с каждого, монтирующих файловые системы с 7410 по NFS. У вас ведь тоже NFS, правда, и аналогичные условия? Или таки локальные диски?

> Увы - 140 дисков в наличии нет чтобы проверить, а на своих жалких 16 шпинделях я смог отжать всего лишь 5000 операций в секунду :-( Хотя есть некоторая надежда, что на 100 шпинделях получится снять 20000 операций в секунду. К счастью, ребята из VMWare были так добры, что выложили результаты своих тестов - http://blogs.vmware.com/performance/2008/05/100000-io-opera.html

Ребята из VmWare имели перед собой другую цель - опровергнуть миф о том, что IO в ESX плохо масштабируется. Поэтому на все остальное они чхать хотели, в том числе и на цену вопроса. Хотя не, неправ, отслюнявить бабла за 3 штуки CX3-80 они не захотели, попросили на время у EMC ;-)

> Да, у VMWare на 480 шпинделей (в три раза больше чем у Sun),

Но это в три раза более быстрые диски

> но получилось 100k ops/second против 17k у Sun (в пять раз больше), при этом R/W соотносилось у VMWare 50/50 (в Sun только чтение),

Вот именно что только чтение. То есть нужно говорить о 50к Read IOPS. И это получено с в три раза большего количества как минимум в три раза более быстрых и в несколько раз более дорогих дисков. То есть количество IOPS оказалось лучше не в девять раз, а всего в три (с учетом записи в 6, но в случае 7410 записи не было)

Вобщем, продолжайте сравнивать горячее с тихим :-)

> с латентностью 8ms - у Sun она 10ms. Ой как грустно...

Как мило :-) Вы только забыли упомянуть, что латентность 10 мс - это без ReadZill'ы. А с ReadZill'ой эта латентность в большинстве случаев менее 1 ms. Подумаешь, всего лишь в 8 раз лучше...

> При чем тут линукс? А при том, что VMWare ESX это гипервизор и Dom0-линукс :-) Так что извиняйте - пока что видно, что как только дело доходит до сравнений в более-менее равных конфигурациях, Sun начинает стекать в осадок. L2ARC не помогает.

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