From: Michael Shigorin <mike@osdn.org.ua> To: "Культурный офтопик" <smoke-room@lists.altlinux.org> Subject: Re: [room] Разработка механизма резервирования виртуальных машин Date: Tue, 3 Jan 2012 09:55:55 +0200 Message-ID: <20120103075555.GD16304@osdn.org.ua> (raw) In-Reply-To: <CAP7eui4M_J2gYj-GjcWsTpacyw3yfd33xyVypAU=jbqXpx7YFA@mail.gmail.com> On Sun, Jan 01, 2012 at 04:59:29PM +0400, Илья Кучмин wrote: > Задумался об автоматизации процесса резервирования виртуальных > машин на платформах openvz, kvm. Так как backup HN не требуется > то возникает, вполне законное желание, осуществлять > перекрестный backup. Есть такое. > Особенно если учесть, что винчестеры нынче дешевые, да и raid > обычно нулевой используется. Тот, кто с дешёвыми винчестерами использует raid0 для данных, испытывает судьбу даже и с бэкапами. Да и с дорогими тоже... > Процесс резервирования видится следующим: Имеется два компонента > Сервер и Клиент. Сервер выполняет процесс резервирования для > виртуальных машин которые на нем хостятся. Целиком? > В зависимости от типа виртуализации процесс резервирования > может отличаться, соответственно должны использоваться утилиты > предоставленные авторами механизма виртуализации, либо > инструмент который пожелает использовать администратор. Вы про снапшоты? Лучше по возможности конкретизировать то, что крутится в голове, поскольку фразу можно понимать сразу на нескольких уровнях :) > После того как процесс снятия резервных копий окончен, > сервер рассылает(клиентам) уведомления, после чего клиенты > осуществляют процедуру выгрузки копий зарезервированных на сервере > виртуальных машин. Также клиенты должны с определенной > периодичностью проверять наличие последних обновлений доступных > на сервере. Таким образом решается проблема потерявшихся в пути > уведомлений. Не проще ли слать их более-менее гарантированным транспортом? Таймстампы -- относительно небольшой трафик даже относительно метаданных. Мультикаст относительно интересен при выливе данных, но есть подозрение, что _закладываться_ на него -- значит как минимум существенно усложнить себе поддержку шифрования трафика (например, http://cseweb.ucsd.edu/~spanjwan/multicast.html). IMHO это хорошая идея при разливе образов, но не для бэкапа... > Понятие Клиент и Сервер существуют в рамках одной сессии > передачи данных, так как для одних VPS, HW является > клиентам(выгружая их с другой машины) для других > сервером(предоставляя свои ресурсы гостям). Резонно запихать бэкап тоже в контейнеры или виртуалки. > Примечания: > Уведомления должны передаваться не только в рамках одной > широковещательной сети. Гарантии что промежуточные > маршрутизаторы поддерживают multicast также нет. Мало того, для уведомлений мультикаст не очень интересен. > Прошу читателей покритиковать предложенную схему backup. Вы знакомы с bacula? Там достаточно гибкая и шаблонируемая схема организации распределённого бэкапа, хотя возни при реализации (и времени на освоение базовых вещей) прилично. > Также если вы знаете об инструментах которые полностью или > частично реализуют необходимый функционал, прошу указать их. Возможно, http://wiki.openvz.org/Partners#Openwall; ещё какие-то соображения можно попробовать почерпнуть около http://www.virtualmin.com/documentation/cloudmin/vm/backup (а бакулу есть мысля подружить с инструментарием управления виртуальными окружениями и машинами, разработанным в рамках Clustrx -- но это вряд ли дело ближайшего полугода) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
next prev parent reply other threads:[~2012-01-03 7:55 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-01 12:59 Илья Кучмин 2012-01-03 7:55 ` Michael Shigorin [this message] 2012-01-03 13:50 ` Илья Кучмин 2012-01-09 12:11 ` Michael Shigorin 2012-01-10 6:09 ` Илья Кучмин 2012-01-10 9:02 ` Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20120103075555.GD16304@osdn.org.ua \ --to=mike@osdn.org.ua \ --cc=shigorin@gmail.com \ --cc=smoke-room@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Культурный офтопик This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/smoke-room/0 smoke-room/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 smoke-room smoke-room/ http://lore.altlinux.org/smoke-room \ smoke-room@lists.altlinux.org smoke-room@lists.altlinux.ru smoke-room@lists.altlinux.com smoke-room@altlinux.ru smoke-room@altlinux.org smoke-room@altlinux.com public-inbox-index smoke-room Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.smoke-room AGPL code for this site: git clone https://public-inbox.org/public-inbox.git