2012/1/3 Michael Shigorin <[email protected]>: > On Sun, Jan 01, 2012 at 04:59:29PM +0400, Илья Кучмин wrote: >> Задумался об автоматизации процесса резервирования виртуальных >> машин на платформах openvz, kvm. Так как backup HN не требуется >> то возникает, вполне законное желание, осуществлять >> перекрестный backup. > > Есть такое. > Под словом "перекрестный" предполагаю хранение резервных копий непосредственно на HW. >> Особенно если учесть, что винчестеры нынче дешевые, да и raid >> обычно нулевой используется. > > Тот, кто с дешёвыми винчестерами использует raid0 для данных, > испытывает судьбу даже и с бэкапами. Да и с дорогими тоже... В данном случае от raid1 большоей пользы не будет. VPS в основном используются для целей тестирования и разработки, смысл backup только в том, чтобы в короткие сроки развернуть машину на стороннем HW. В идеале, если требуется стабильность, имеет смысл собирать raid начиная с 5, но в нашем случае это слишком большие затраты, не сравнимые с однодневными потерями. > >> Процесс резервирования видится следующим: Имеется два компонента >> Сервер и Клиент. Сервер выполняет процесс резервирования для >> виртуальных машин которые на нем хостятся. > > Целиком?
Если речь идет именно о VPS, то да - целиком. Сохраняются диск и метаданные о VPS. > >> В зависимости от типа виртуализации процесс резервирования >> может отличаться, соответственно должны использоваться утилиты >> предоставленные авторами механизма виртуализации, либо >> инструмент который пожелает использовать администратор. > > Вы про снапшоты? Лучше по возможности конкретизировать то, > что крутится в голове, поскольку фразу можно понимать сразу > на нескольких уровнях :) Я имел ввиду, что системе должно быть возможно указать какую утилиту использовать для выполнения резервирования. К примеру для выполнения резервирования машин на платформе OpenVZ хорошо бы было испольлзовать vzdump и т.д. > >> После того как процесс снятия резервных копий окончен, >> сервер рассылает(клиентам) уведомления, после чего клиенты >> осуществляют процедуру выгрузки копий зарезервированных на сервере >> виртуальных машин. Также клиенты должны с определенной >> периодичностью проверять наличие последних обновлений доступных >> на сервере. Таким образом решается проблема потерявшихся в пути >> уведомлений. > > Не проще ли слать их более-менее гарантированным транспортом? Когда я говорил о не гарантированных обновлениях я предполагал вариант, когда клиент выпал из сети. В таком случае сервер пишет в лог что уведомление не доставленно и в дальнейшем не пытается его доставить повторно.(По аналогии с notify в DNS > Таймстампы -- относительно небольшой трафик даже относительно > метаданных. Мультикаст относительно интересен при выливе данных, > но есть подозрение, что _закладываться_ на него -- значит как > минимум существенно усложнить себе поддержку шифрования трафика > (например, http://cseweb.ucsd.edu/~spanjwan/multicast.html). > IMHO это хорошая идея при разливе образов, но не для бэкапа... > >> Понятие Клиент и Сервер существуют в рамках одной сессии >> передачи данных, так как для одних VPS, HW является >> клиентам(выгружая их с другой машины) для других >> сервером(предоставляя свои ресурсы гостям). > > Резонно запихать бэкап тоже в контейнеры или виртуалки. Об этом я думал. В принципе идея правильная. > >> Примечания: >> Уведомления должны передаваться не только в рамках одной >> широковещательной сети. Гарантии что промежуточные >> маршрутизаторы поддерживают multicast также нет. > > Мало того, для уведомлений мультикаст не очень интересен. > >> Прошу читателей покритиковать предложенную схему backup. > > Вы знакомы с bacula? Там достаточно гибкая и шаблонируемая > схема организации распределённого бэкапа, хотя возни при > реализации (и времени на освоение базовых вещей) прилично. > Про bacula читал, но не использовал. Если не сложно поясните как ее можно применить в моем случае. Мне кажется основная проблема в том, что в bacula процесс резервирования инициируется единым сервером, через клиентов на HW. В тоже время я хочу обратной ситуации, чтобы более скурпулезно управлять процессом резервирования в зависимости от нагрузки HW и активности использования VPS. Возможно я зря этого хочу, если вы считаете также то прошу указать на это. >> Также если вы знаете об инструментах которые полностью или >> частично реализуют необходимый функционал, прошу указать их. > > Возможно, http://wiki.openvz.org/Partners#Openwall; Не до конца понял в какой форме они осуществляют процесс резервирования. Если использовали прошу поделиться опытом. > ещё какие-то соображения можно попробовать почерпнуть около > http://www.virtualmin.com/documentation/cloudmin/vm/backup Они предлагают обычный backup с возможностью передачи в удаленное хранилище. Собственно немного не то, что мне надо, но все равно спасибо за ссылку. > > (а бакулу есть мысля подружить с инструментарием управления > виртуальными окружениями и машинами, разработанным в рамках > Clustrx -- но это вряд ли дело ближайшего полугода) Про bacula почитаю подробнее, насколько я понял это самый распространненный инструмент. Благодарен за любые мысли. > > -- > ---- WBR, Michael Shigorin <[email protected]> > ------ Linux.Kiev http://www.linux.kiev.ua/ > _______________________________________________ > smoke-room mailing list > [email protected] > https://lists.altlinux.org/mailman/listinfo/smoke-room _______________________________________________ smoke-room mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/smoke-room
