LINUX.ORG.RU
ФорумAdmin

[vm] синхронизация клонов виртуальных машин.


0

0

Есть на двух машинах две виртуальные машины. В обеих одинаковый пока дебиан. Возникнет ситуация, когда одна из систем будет изменена, и довольно сильно, возможно. Например, будут поставлены пакеты, ядра и т.д. Вопрос: как синхронизировать изменения систем, которые могут охватывать весь /, например? Есть вариант rsync, но как будет выглядеть скрипт, обшаривающий весь диск, и сколько времени это займет? Также можно rsync по файлу-виртуальному диску, но здесь смущает объем. Рсинк при обнаружении разницы будет ее переписывать, или весь файл?

Re: [vm] синхронизация клонов виртуальных машин.

> Рсинк при обнаружении разницы будет ее переписывать, или весь файл?

Это как попросишь, но прелесть рсинка как раз в том, чтобы пересылать и переписывать только различающиеся блоки.

const86 ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

Только для этого он должен посчитать контрольную сумму для файла(вернее, контрольную сумму для каждого чанка) как на принимающей стороне так и на отправляющей. Поэтому, например, если есть база данных на 30гиг в одном файле(скажем, innodb) то синкать каждую минуту её не получится т.к. за такое время 30гиг не обсчитаешь.

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

true_admin ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

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

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

const86 ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

> либо в ОС надо предусматривать мехинизм уведомления о записи в файл.

само по себе это не поможет. Вот inotify скажет что такой-то 20гиговый файл изменился, разве rsync станет легче? К тому же rsync сам не дурак, если mtime/ctime у файлов одинаковые то он синкать их не будет.

true_admin ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

> само по себе это не поможет. Вот inotify скажет что такой-то 20гиговый файл изменился, разве rsync станет легче?

Так я ж не про inotify сказал. В том-то и дело, что на сегодня я не знаю, чтобы эта задача как-то красиво решалась. Можно, например, свой таргет для device-mapper сочинить...

const86 ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

drbd

OMEN ()

Re: [vm] синхронизация клонов виртуальных машин.

почитай на сайте drbd, там всё достаточно подробно написано. Я в продакшене пока не пускал т.к. само по себе это задачу не решает. Есть идея делать т.н. savepoints, т.е. останавливать запись на диск, сборасывать кэши, делать снапшот и уже этот снапшот реплицировать. Но я пока над этим не думал.

Просто реплицировать не очень хорошая идея т.к. не обеспечивается консистентность данных. Главным образом от этого может пострадать база.

true_admin ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

> На правах бреда

так nbd может и без raid1 реплицировать. Зачем рейд? Ускорить операции чтения? :). По-моему, он треснет по сети такое гонять.

Кстати, ещё идея: купить nas и всех присоединять к нему. Некоторые так делают, получается очень простая и крутая архитектура, но всё завязано на том что nas не может сломаться. А если он сдохнет то тогда всё нафиг полетит :)

true_admin ★★★★★ ()

Re: [vm] синхронизация клонов виртуальных машин.

Я делал на двух физических машинах drbd - вполне работоспособная весчь, правда я не использовал primary-primary режим и синхронизовал раздел с данными, а не всю ОС. Есть предположение, что можно на какой-нибудь кластерной ФС+drbd создать решение с полной поблочной репликацией, но не 100% уверен, и это будет в большой степени LFS :)

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