Комментарии 13
Круто, спасибо!
0
странно дело — у меня сервера у них на LVM и при этом у меня не было подобных танцев с бубном.
сервер на Debian minimal образе ставил
сервер на Debian minimal образе ставил
0
Берем бесплатный KVM на два часа… и делаем все что нам нужно =).
0
Я бы посоветовал с большой осторожностью относиться к LVM.
Во-первых write amplification. При записи на диск со снапшотами запись повторяется несколько раз, причём в разные места диска, то есть из линейного (sequential с точки зрения БД) превращается в чистый random.
Во-вторых первая запись принуждает к чтению, то есть LVM перед записью должен прочитать аж 2Мб блок, внести изменения и записать.
В третьих есть бродячая бага с дедлоком при удалении снапшотов. Гарантированно воспроизвести, увы, не получается, но ловили неоднократно. Настолько, что (в нашей задаче — при обновлении миррора дистрибутивов) переключились с LVM'а на банальный mv для каталогов.
Во-первых write amplification. При записи на диск со снапшотами запись повторяется несколько раз, причём в разные места диска, то есть из линейного (sequential с точки зрения БД) превращается в чистый random.
Во-вторых первая запись принуждает к чтению, то есть LVM перед записью должен прочитать аж 2Мб блок, внести изменения и записать.
В третьих есть бродячая бага с дедлоком при удалении снапшотов. Гарантированно воспроизвести, увы, не получается, но ловили неоднократно. Настолько, что (в нашей задаче — при обновлении миррора дистрибутивов) переключились с LVM'а на банальный mv для каталогов.
+2
Бага — это неприятно. Я не сталкивался, правда (может быть, исправили в новых версиях?) — как выглядит ее проявление? Что касается просадки производительности, то, по-моему, она не очень-то заметна на фоне процесса-бэкапа (снапшот-то только на время бэкапа создается, потом удаляется). Бэкап же поедает кучу ресурсов сам по себе.
Просто ну очень хочется бэкапить на бесплатный, вместительный и очень быстрый (реальные 100 МБит у Хецнера) FTP инкрементно, для этого подходит duplicity, но duplicity запускать на «незамороженной» файловой системе — это самоубийство (если еще rdiff-backup — куда ни шло, то duplicity — смерть). А для снапшота же он работает, как часы. Плюс duplicity, кажется, лучше по производительности бэкапа, чем rdiff-backup (хотя бы из-за того, что rdiff-backup сильно грузит не только ту машину, которую бэкапит, но еще и ту, НА КОТОРУЮ бэкапит). (И да, репликация — это не замена бэкапа.)
Просто ну очень хочется бэкапить на бесплатный, вместительный и очень быстрый (реальные 100 МБит у Хецнера) FTP инкрементно, для этого подходит duplicity, но duplicity запускать на «незамороженной» файловой системе — это самоубийство (если еще rdiff-backup — куда ни шло, то duplicity — смерть). А для снапшота же он работает, как часы. Плюс duplicity, кажется, лучше по производительности бэкапа, чем rdiff-backup (хотя бы из-за того, что rdiff-backup сильно грузит не только ту машину, которую бэкапит, но еще и ту, НА КОТОРУЮ бэкапит). (И да, репликация — это не замена бэкапа.)
+1
Баг выглядит как прекращение IO на устройство. Обычный дедлок. Для mdadm его поправили, а для LVM никто поймать не может обстоятельств. Возникает редко, но при ежесуточной ротации снапшотов миррор затыкался раз в месяц-полтора. Баг был в трёх версиях (ядра) точно, возможно, в большем количестве.
0
у меня было похоже с ядрами 3.0.* — 3.0.17
делаешь снапшот из дом0, начинаешь делать копи каталогов обычным tar zcf… и всё, привет дедлок, система висла напрочь.
после перехода на 3.0.35 такое явление прекратилось.
делаешь снапшот из дом0, начинаешь делать копи каталогов обычным tar zcf… и всё, привет дедлок, система висла напрочь.
после перехода на 3.0.35 такое явление прекратилось.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Настраиваем RAID1+LVM (для снапшотов файловой системы) в Hetzner и ServerLoft