From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Date: Tue, 3 Jan 2012 09:55:55 +0200 From: Michael Shigorin To: =?koi8-r?B?69XM2NTV0s7ZyiDPxtTP0MnL?= Message-ID: <20120103075555.GD16304@osdn.org.ua> Mail-Followup-To: =?koi8-r?B?69XM2NTV0s7ZyiDPxtTP0MnL?= References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [room] =?koi8-r?b?8sHa0sHCz9TLwSDNxcjBzsnazcEg0sXaxdLXydLP18HO?= =?koi8-r?b?ydEg18nS1NXBzNjO2cggzcHbyc4=?= X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shigorin@gmail.com, =?koi8-r?b?69XM2NTV0s7ZyiDPxtTP0MnL?= List-Id: =?koi8-r?b?69XM2NTV0s7ZyiDPxtTP0MnL?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 07:56:02 -0000 Archived-At: List-Archive: 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 ------ Linux.Kiev http://www.linux.kiev.ua/