SVN для контроля версий виртуальных машин (vmware server 1)
 

Всем привет!
Хочу спросить у знающих людей насколько идея достойна реализации.

Итак, существует сервер на котором установлена VMware Server 1. На хостовой системе находится не одна виртуальная машина, эти машины необходимо периодически обновлять (софт в гостевой системе) и восстанавливать в случае краха гостевой системы или не поняток каких-либо.

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

Поискал в рунете и обратил внимание на SVN. Бесплатная и вроде как есть спец. режим (модель) Блокирование-Изменение-Разблокирование не допускающая сливание файлов (как раз у меня-то бинарные файлы *.vmdk например) и собственно удобная система управления версиями.

Дак, вот подскажите пожалуйста действительно ли можно использовать SVN для данных целей и если да, то насколько это будет эффективно? Действительно ли размер изменений посылаемых сервером будет не большой, может он будет такой же как размер реальных файлов?

Может меня кто-то поправит, но svn вроде работает с текстовыми файлами.

Дак в том то и дело. Кто-то говорит, что должно работать и с бинарниками и с текстовыми файлами..
Но тут нужно уточнить. Мне нужно собственно не текстовое сравнение (просматривать бинарники я не буду), а чтобы изменения бинарников были не большими! Т.е. вот есть файл 6 ГБ, у него несколько ревизий. Мне нужно откатится до самой ранней ревизии. Вот и хочу узнать при откате будет ли сервер посылать на клиента не большое изменение или все-таки 6Гб с небольшим???

Кстати а откуда такая информация, можете ссылку дать?
>но svn вроде работает с текстовыми файлами.

Нашел такой вот текст:

Для Subversion безразлично, если вместо исходного кода вы загрузите свой домашний каталог; его дело – хранить изменения. Однако имеется несколько загвоздок. Прежде всего, проблемы вызываются большими двоичными файлами. Не то чтобы Subversion их не поддерживал, но они реально замедляют систему, так как Subversion вынужден их сравнивать, отслеживая разницу. Возможно, стоит держать большие файлы вне репозитария.

по адресу http://wiki.linuxformat.ru/index.php/LXF82:Subversion

Т.е. выходит все будет работать но очень медленно?

rfcr, да. Можно посмотреть в сторону cvs или git.

Кто-нибудь еще может подтвердить утверждение о том, что будет все работать только медленно?

Я-бы не рискнул пользоваться, пока сам не проверил.

rfcr, может я задам глупый вопрос... а в сторону снапшотов (snapshot) виртуальных машин не смотрели?

Смотрел :)
В vmware server можно делать только один снапшот. Его не достаточно, да и в использовании снапшотов не мало заморочек.
Например снапшоты место занимают там где находятся виртуальные машины, а вот если бы SVN сгодился то всё для "отката назад" лежало бы в одном месте - на сервере. Ну это так, к слову.

rfcr, мм, как так один?
А по поводу SVN, я поспрашивала - не рекомендуют, причем в категоричной форме.

А что именно говорят? Почему не рекомендуют и кто такие? :)
Вот например мне тут подбросили конкретную ссылку:

http://subversion.tigris.org/faq.html#binary-files

Получается, что все должно работать...

И вообще, у меня пока нет возможности поставить svn и проверить, может кто-нибудь уже на установленной системе может попробовать?
Гоняют же по svn программисты exe и dll и ниче все нормально... А тут просто файл *vmdk размером 2ГБ. Нужно просто проверить.

На счет снапшотов, да один снапшот. А что вы не верите?

Как минимум, для того чтобы сделать резервную копию и восстановится из копии виртуальную машину придется останавливать, да и diff по файликам размером по 2 гигабайта - это не кошерно.
Последняя ссылка говорит лишь о том, что svn поддерживает бинарные файлы, но не говорит, о том что поддерживает их хорошо (в Вашем случае "хорошо" означает - быстро сравнивает большие файлы).

Теоретически, в Вашей ситуации можно использовать вместо vmware server - vmware esxi с NFS хранилищем..

А Вам не кажется, что с svn их будет все-таки больше?

Да их возможно будет больше, но и средства управления в svn мощнее чем просто менеджер снапшотов в vmware.

Согласен, как альтернативный вариант кандидат vmware esxi с NFS хранилищем может рассматриваться, но пока нет возможности его поставить на машину, а решение нужно как говориться уже "вчера"...

В чем Вы видите преимущество средств управления SVN перед средствами управления VMware, в применении к конкретно этой задаче (создание дерева снапшотов с названиями и комментами)?

Вообщем я забанил svn ... Проверил на виртуалке ниче хорошего не получается.
Точно еще не понял но delta-компрессия похоже не работает хорошо для файлов vmdk, а при изменении ревизии в любую сторону файла сразу не обновляются, а с начала занимают место в системе. Вообщем по принципу распаковки архива - файлы сбрасываются во временную папку... Т.е. получается как бы 2 проекта один рабочий другой новое обновление которое еще находится во временной папке.. Потом конечно лишние файлы удаляются но это потом...

>В чем Вы видите преимущество средств управления SVN перед средствами управления VMware
Видимо ошибался..

rfcr, Теперь куда копать будете?
У меня кроме как Vmware esxi с NFS хранилищем идей нет.

Ну куда еще копать...

У меня кроме vmware server 1 ничего нет и пока не предвидится.
Поэтому тут либо обычный инкрементальный бэкап (спец программами бэкапа), либо скриптами через tar например.

Сейчас пытаюсь реализовать простейшие скрипты бэкапа и восстановления. Надо сказать заморочек куча, особенно с правами пользователей. Но это вроде как удалось реализовать (через sudo и ssh), а сейчас работаю над логикой скрипта, проверки всякие и пр. Пишу на обычном bash.

Нашел скрипт vmbackup одного заграничного автора, написанный на питоне вот здесь. Скрипт работает, архивирует папку с ВМ и может отправлять на удаленный сервер. Особенно понравилось, что достаточно ввести лишь имя ВМ, а не путь к ее месторасположению (охото такое реализовать на bash но не знаю как). НО после испытаний в реале вышло так, что комнада scp копирует не сжатый каталог в 2 раза (!) быстрей чем эта софтина, поэтому вынужден был отказаться.