LINUX.ORG.RU
ФорумAdmin

LVM snapshot, backup for VM and OS


0

0

Добрый день, не знаю какую схему выбрать:

Задача: есть относительно мощный сервер с VT-d, есть proxmox, надо попробовать чего из этого выйдет. Так как пока сервер всего один, то надо решать вопрос о бекапах VM.

В скорости в этом сервере будет аппаратный Raid контроллер.

Но он будет только для VM. Для / есть только fake raid, на Intel ICH10R.

Необходимо добиться: отказоустойчивости, для этого хочется: / --- raid 1

VM --- raid 1, но для VM ещё выполнять online backup.

Как сие осуществить?

Дистрибутив proxmox, Авторы специально удалили всякую поддержку dmraid, mdadm, и ВЕЗДЕ пишут на форумах, что дескать ТОЛЬКО ИДИОТ может это использовать... Типо если хотите backup, либо берите аппаратный raid, либо мучайтесь с LVM. Или используйте Debian обычный с нашим пакетом proxmox, но это самое плохое, что можно сделать в данной ситуации, Авторы очень на этом акцентируют внимание.

В связи с этим я бросил попытки создания fake raid, mdadm raid.

После установки proxmox, оно создаёт вот такое дело:

proxmox-52:~# mount

/dev/pve/root on / type ext3 (rw,errors=remount-ro)

/dev/mapper/pve-data on /var/lib/vz type ext3 (rw)

/dev/sda1 on /boot type ext3 (rw)

Есть у меня совершенно аналогичный HDD, который я готов пожертвовать для системы.

Какие будут варианты? Две разные группы LVM + /boot вообще отдельно, всё это не айс, очень не айс.

Что делать?

У меня такие:

1: насильно настроить mdadm на proxmox. - Но фиг знает, у них там кастомное ядро... Да и очень не советуют они этого. Да и CPU это барахло будет грузить не мало...

2: поставить обычный дебиан и использовать fakeraid.

3: как то разрулить всё через lvm snapshot, и /boot бекап делать отдельно.

Но. Прочитал, я что если для lvm есть snapshot то скорость записи в эти разделы ОЧЕНЬ понижается, ну вообще довольно логично, так как приходится вносить каждую транзакцию в таблицу изменений.

С системой понятно. Как бы Вы поступили?

Вопрос-2:

Теперь надо понять чего же делать с VMs? Как их бекапить? Будет отдельный железный контроллер raid, его силами я сделаю raid 1. Но вот всё же как бекапить сами VM?

На ум приходит вот чего:

1: создавать lmv для каждой машины, и монтировать его в kvm как raw устройство, я так понимаю, что это возможно, и снимать с этого дела ночью snapshot отдельно для каждой машины. Но... Опять же, пока оно будет копироваться по 100 мб/сек в другую серверную, VM по сути будет тупить, так-как LVM будет иметь таблицу изменений эту дурацкую? Я понимаю, что у моего raid будет кеш в 512 мб и будет BBU, но есть ещё один сервер пока без контроллера, так, что надо подумать как делать backup VM. --- Можно как-нибудь делать инкрементальные backup? Так-как гонять каждую ночь по 400 гб - да и не реально это на 100 мб/сек, не хочется в другую серверную, да и машин планируется 10 штук, а то и более.

Запись данных на том, с которого сделан снимок, очень сильно замедлена по сравнению с обычной работой!

Элементарное сравнение производительности, наглядно демонстрирующее разницу между скоростью работы с томом, у которого нет снапшотов (смонтирован в /data/lv3/xxxx), и с томом, на котором есть снапшот (смонтирован в /data/lv4/qqqq).

Вот чего меня тревожит. Насколько это актуально сейчас?

http://www.xgu.ru/wiki/LVM#.D0.A0.D0.B5.D0.B7.D0.B5.D1.80.D0.B2.D0.BD.D0.BE.D...

2: машины для kvm делать в файле: qcow2, он как я понимаю поддерживает snapshot backup.

В общем как бы Вы реализовали инкрементальный backup VMs, и raid лдя этого дела, имея лишь один сервер, и удалённый сервер для backup?

★★★★★

у меня на файловой помойке = 4 терайбайтных винта в софтрейде 5 уровня. поверх лвм. снапшоты делаются влет.

MikeDM ★★★★★ ()

(Какой-то урод стёр мои сообщения.)

Учти, LVM не поддерживает инкрементные снимки, так что придётся держать дополнительные носители под каждый из сохраняемых снапшотов.

iZEN ★★★★★ ()

DALDON> 1: создавать lmv для каждой машины, и монтировать его в kvm как raw устройство, я так понимаю, что это возможно, и снимать с этого дела ночью snapshot отдельно для каждой машины.

Я примерно так делаю. Для каждой VM создаётся LV, который подсовывается как raw. Внтури VM на этом «диске» тоже всё ставится на LVM. Профит такой: можно в любой момент добавить места, можно сделать снапшот всего диска «снаружи», если надо, и при этом можно делать снапшоты «внутри» и собственно бекапить файло. Тупить, конечно, будет, но насколько сильно, и будет ли это критично, зависит от конкретной задачи и нагрузки. В целом оверхед от LVM на LVM небольшой.

rusty_angel ()
Ответ на: комментарий от rusty_angel

В смысле я для бекапа делаю снапшот, монтирую его, делаю бекап, удаляю снапшот. Просто образы диска так тоже можно делать, думаю. То есть тупит не постоянно, а только когда бекап делается. Думаю, тут оверхед от снапшота не сильно заметен на фоне самого копироания данных.

rusty_angel ()
Ответ на: комментарий от MikeDM

> поверх лвм. снапшоты делаются влет.

А когда LVM имеет снэпшот, скорость записи как?

DALDON ★★★★★ ()
Ответ на: комментарий от rusty_angel

>В целом оверхед от LVM на LVM небольшой.

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

DALDON ★★★★★ ()
Ответ на: комментарий от anonymous

> Тупить будет, адназначна: http://events.linuxfoundation.org/slides/lfcs09_mason.pdf (слайды 18 и 19)

Вот, вот, и я про это же, спасибо, посмотрел слайды, почитаю и ведь документ.

Brtfs ещё сырая, не думаю, что есть смысл. Да и там слайд 18 тоже видно падение.

Вот я и хочу сказать, что все говорят, мол, вот снепшоты, круто, туда, сюда... А вот про это как то и не видно особо было. :(

DALDON ★★★★★ ()
Ответ на: комментарий от rusty_angel

Есть пока одна машина, в будущем будет ещё одна, но более слабая. Между ними будет интерфейс гигабитный, нет проблем. В общем да, перекрёстный backup никто не отменял, я подумаю над этим, ну и ещё всё же хочется забирать бекапы в удалённую комнату серверную, сами понимаете... Жизнь она такая... Уже два раза за год заливало сервреную.. Хорошо что обошлось всё.

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

На время backup всё же придётся создавать снепшот LVM. Вот это немного парит. Т.к. скорость записи упадёт резко. Вопрос насколько быстро... Всё же по гигабитному линку долго будет копироваться. Ну представте себе: NFS, 1гб/сек линк, больше 25-30 мегабайтов в сек. как показывает практика мне не выжать, получаем: одна машина в среднем по 40 гб. + одна будет 200 гб. И того: 400 гб. Теперь считаем время: в среднем такой объём будет копироваться не менее 5-ти часов. Что к примеру: с 1 до 6-ти часов утра. Всё это время все VM находящияся в одном VG, или на одном PV даже по сути будут тупить на запись данных. Чтобы уменьшить это время надо на высоконагруженные VM мутить разные диски, и делать различное время старта backup.

Получается только так?

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

Поправка: не на одном VG или PV, а на одном физическом диске.

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

Если так парит скорость, то я бы думал, как бекапить файлы, а не образы целых разделов. Чтобы инкрементально. И всё-таки не перекрёстные бекапы , а отдельная машина для бекапов, и ротировать винты в ней.

NFS, 1гб/сек линк, больше 25-30 мегабайтов в сек. как показывает практика мне не выжать

Почему? Сам не пробовал, но узкое место тут не сеть, мне кажется, а диски на обеих машинах.

rusty_angel ()
Ответ на: комментарий от rusty_angel

>Почему? Сам не пробовал, но узкое место тут не сеть, мне кажется, а диски на обеих машинах.

Я пробовал, и не однократно, да и тут уже писал. Чистый тест делал на свежеустаноленных ОС, винтах новых, не даёт оно больше.

DALDON ★★★★★ ()
Ответ на: комментарий от rusty_angel

>Если так парит скорость, то я бы думал, как бекапить файлы, а не образы целых разделов. Чтобы инкрементально.

Как бы это реализовать? В этом и есть суть вопроса.

DALDON ★★★★★ ()

В случае использования Proxmox VE, я делал так:

Ставил Debian Lenny, разбивал диски как мне надо, делал программный рейд (mdadm) прямо через инсталлятор, поверх рейда LVM.
Подключал репозитарии proxmox`а, ставил их окружение, ядро. И все работает прекрасно.

Для бекапа самих виртуальных машин, в Proxmox имеется штатная бекапилка, которая настраивается через WEB интерфейс и умеет по расписанию бекапить нужные (или все) виртуалки на NFS хранилище.
Во время бекапа, она сама создает LVM snapshot, выполняет бекап, удаляет спаншот.

Steel901 ()
Ответ на: комментарий от rusty_angel

>Или я вопроса не понимаю?

Каждую ночь по 400 гб... Много копировать. Хочется инкременентности.

Для бекапа самих виртуальных машин, в Proxmox имеется штатная бекапилка, которая настраивается через WEB интерфейс и умеет по расписанию бекапить нужные (или все) виртуалки на NFS хранилище.

Во время бекапа, она сама создает LVM snapshot, выполняет бекап, удаляет спаншот.

Ну да. Так я и делаю в общем то.

DALDON ★★★★★ ()
Ответ на: комментарий от Steel901

> Ставил Debian Lenny, разбивал диски как мне надо, делал программный рейд (mdadm) прямо через инсталлятор, поверх рейда LVM. Подключал репозитарии proxmox`а, ставил их окружение, ядро. И все работает прекрасно.

А fakeraid на Intel ICH10R всё совсем плохо? Почему не стоит его попробовать? Поставить Debian там его завести, и вперёд... Если делают драйвера в Linux, если выпускает чипсеты сама Intel, не уж то это всё столь ужасно? Оно ведь не вчера вышло то...

DALDON ★★★★★ ()
Ответ на: комментарий от Steel901

> Подключал репозитарии proxmox`а, ставил их окружение, ядро. И туда модулями грузите mdadm? Ведь как я понял оных средств в ихнем ядре нету принципиально, или из исходников пересобирали?

DALDON ★★★★★ ()

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

все остальное - ненадежные костыли.

можно как вариант, опускать машину для бакапа по крону, копировать имиджи дисков, и поднимать через API платформы.

в RHEV таким образом можно бекапить и экспортировать целые домейны ВМов, а не только по одной.

dyasny ★★★★★ ()
Ответ на: комментарий от DALDON

>Хочется инкременентности.

Так в чём проблема? Просто бекапить уже не с хоста, а с гостей. Ну и раз в неделю/месяц, как больше нравится, делать полные бекапы гостевых систем с хоста. Система получается сложнее, зато большой выигрыш в скорости и эффективности.

rusty_angel ()
Ответ на: комментарий от DALDON

И туда модулями грузите mdadm? Ведь как я понял оных средств в ихнем ядре нету принципиально, или из исходников пересобирали?


Там есть поддержка mdadm.
mercury:~# uname -a
Linux mercury 2.6.24-11-pve #1 SMP PREEMPT Fri May 14 09:28:08 CEST 2010 x86_64 GNU/Linux

mercury:~# lsmod | grep raid
raid1 35840 3
md_mod 99740 4 raid1

Steel901 ()
Ответ на: комментарий от rusty_angel

>Так в чём проблема? Просто бекапить уже не с хоста, а с гостей.

Вы имеете ввиду бекапить просто отдельными приложениями критичными, по cron внутри самой гостевой ОС? Ну тут да. Вопросов не возникает никаких.

DALDON ★★★★★ ()
Ответ на: комментарий от Steel901

># apt-get install mdadm

...

update-initramfs: Generating /boot/initrd.img-2.6.32-2-pve

Ага. Оно видимо собирает модуль само.

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

Да можно бекапить систему целиком, просто на уровне файловых систем, а не блочных устройств. Бекапить отдельные сервисы мне не нравится. Это оправдано, когда машин немного; в сетях покрупнее проще будет держать по серверу на сервис и целиком бекапить серверы. Но вместо чего-то по cron я бы всё-таки смотрел на bacula. Разобраться с ней (и даже успеть набить шишек и набраться опыта) будет быстрее, чем написать много костылей. Кроме неё я ещё на amanda смотрел, и совсем не понравилось. Но глянуть на неё в любом случае стоит.

rusty_angel ()
Ответ на: комментарий от rusty_angel

>Бекапить отдельные сервисы мне не нравится. Это оправдано, когда машин немного; в сетях покрупнее проще будет держать по серверу на сервис и целиком бекапить серверы.

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

Win я слышал что то ntfs снепшоты, а вот Linux и прочие дела, это Вы как раз через LVM бекапите?

Ну опять же можно каждой машине по LVM.

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

Win я слышал что то ntfs снепшоты, а вот Linux и прочие дела, это Вы как раз через LVM бекапите?

Некорректный вопрос, но ответить, видимо, следует: «Да» :) Но LVM — это аналог виндового VSS (если не путаю, как оно там в винде называется). Если нам нужны снапшоты и гибкое управление томами - мы пользуемся LVM, а поверх неё любую файловую систему, которая нам подходит. Btrfs и zfs умею снапшоты уже на уровне файловой системы, но одно ещё не допилено, а другое в линуксах только через fuse.

Кстати, раз в сети есть и винда, как я понял, то наверно уже используется какая-то система резервного копирования. Возможно, у неё есть и под линукс агенты.

rusty_angel ()
Ответ на: комментарий от rusty_angel

>Кстати, раз в сети есть и винда, как я понял, то наверно уже используется какая-то система резервного копирования. Возможно, у неё есть и под линукс агенты.

Когда то это была bacula, надо возрождать, сейчас же это FreeNAS + NFS + samba, вот там и планирую bacula.

Если нам нужны снапшоты и гибкое управление томами - мы пользуемся LVM, а поверх неё любую файловую систему

А то, что на заснепшотенной файловой системе падает сильно скорость записи... Вот чего парит... Надо как можно резче наснепшатить, и потом удалить этот снепшот.

В общем и целом понятно всё.

Спасибо всем!

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

А то, что на заснепшотенной файловой системе падает сильно скорость записи...

Кстати, проблема-то, по-моему, не собственно в скорости записи, а в iops. Если приложения не слишком много пишут на диск, то падение скорости не будет очень заметно.

rusty_angel ()
Ответ на: комментарий от rusty_angel

>Кстати, проблема-то, по-моему, не собственно в скорости записи, а в iops. Если приложения не слишком много пишут на диск, то падение скорости не будет очень заметно.

Mysql... + Корпоротивный workflow. Ну и по мелочи с десяток машин, таких как антивирусная корпоративная, оно тоже иопсы любит...

DALDON ★★★★★ ()
Ответ на: комментарий от anonizmus

> Получается при таком раскладе можно юзать heartbeat + DRBD.

Уже пробовал. Работает. Надо только ещё уговорить начальство на один контроллер с BBU, и всё будет ок. А пока...

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

>Mysql

Если памяти хватает, оно не очень активно винтом шевелит.

таких как антивирусная корпоративная, оно тоже иопсы любит...


А это вроде должно в основном не процессор.

rusty_angel ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.