From: Michael Shigorin <mike@osdn.org.ua> To: "Культурный офтопик" <smoke-room@lists.altlinux.org> Subject: Re: [room] Разработка механизма резервирования виртуальных машин Date: Mon, 9 Jan 2012 14:11:59 +0200 Message-ID: <20120109121159.GE16304@osdn.org.ua> (raw) In-Reply-To: <CAP7eui6b03K9SXdmSnUHWW7c+AKu7Onz5LW5EsoKEv70DKRP=Q@mail.gmail.com> On Tue, Jan 03, 2012 at 05:50:44PM +0400, Илья Кучмин wrote: > > Есть такое. > Под словом "перекрестный" предполагаю хранение резервных копий > непосредственно на HW. Я понял как "взаимное предоставление хостами с расположенными на них контейнерами друг другу стораджа для бэкапа". > >> Особенно если учесть, что винчестеры нынче дешевые, да и > >> raid обычно нулевой используется. > > Тот, кто с дешёвыми винчестерами использует raid0 для данных, > > испытывает судьбу даже и с бэкапами. Да и с дорогими тоже... > В данном случае от raid1 большоей пользы не будет. VPS в > основном используются для целей тестирования и разработки, > смысл backup только в том, чтобы в короткие сроки развернуть > машину на стороннем HW. А-аа, ну так это существенное уточнение. Возможно, Вам лучше посмотреть в сторону существующих систем для организации provisioning -- насколько понимаю, сейчас в моде Puppet. (мы работали с systemimager.org) > В идеале, если требуется стабильность, имеет смысл собирать > raid начиная с 5, но в нашем случае это слишком большие > затраты, не сравнимые с однодневными потерями. Пятёрка плоха по записи и ресурсу дисков, если что. > >> [...] соответственно должны использоваться утилиты > >> предоставленные авторами механизма виртуализации [...] > > Вы про снапшоты? > Я имел ввиду, что системе должно быть возможно указать какую > утилиту использовать для выполнения резервирования. К примеру > для выполнения резервирования машин на платформе OpenVZ хорошо > бы было испольлзовать vzdump и т.д. Если по постановке задачи делается не столько бэкап, сколько шаблон -- может быть проще останавливать VE/VM и делать просто копию. VE при практически нулевой активности можно бэкапить и на ходу, хотя риск неконсистентности при этом всё же есть. Ещё может быть интересно эти шаблоны попросту выпекать под задачу -- на альтовской (прямщас) пакетной базе пилю mkimage-profiles: http://www.altlinux.org/Mkimage/Profiles/m-p -- но это требует возможности в существенной степени формализовать задачу VE. > > Не проще ли слать их более-менее гарантированным транспортом? > Когда я говорил о не гарантированных обновлениях я предполагал > вариант, когда клиент выпал из сети. В таком случае сервер > пишет в лог что уведомление не доставленно и в дальнейшем не > пытается его доставить повторно.(По аналогии с notify в DNS Возможно, стоит описать собсно задачу, а не фрагмент видимой реализации. > >> Прошу читателей покритиковать предложенную схему backup. > > Вы знакомы с bacula? Там достаточно гибкая и шаблонируемая > > схема организации распределённого бэкапа, хотя возни при > > реализации (и времени на освоение базовых вещей) прилично. > Про bacula читал, но не использовал. Если не сложно поясните > как ее можно применить в моем случае. Как минимум там уже реализованы работающие бэкапные и стораджевые агенты, плюс управляющая логика. Возможно, под Вашу задачу не подойдёт, но посмотреть стоит -- хотя бы ради того, чтоб не решать уже решённое на концептуальном уровне. > Мне кажется основная проблема в том, что в bacula процесс > резервирования инициируется единым сервером, через клиентов на > HW. В тоже время я хочу обратной ситуации, чтобы более > скурпулезно управлять процессом резервирования в зависимости от > нагрузки HW и активности использования VPS. Да, bacula нацелена на снятие головной боли ручного управления. > Возможно я зря этого хочу, если вы считаете также то прошу > указать на это. Попробуйте сделать небольшой прототип и поиграться с ним, чтобы понять, насколько будет необходимо человеческое внимание. Осторожно только с тем, чтоб не влопатить туда нечаянно слишком много рабочего кода: можно попасть на "о, так у нас уже есть решение" и прототип пойдёт в дело, к которому не готов в принципе. У меня обычно ощущения складываются за две-четыре недели таких экспериментов... > >> Также если вы знаете об инструментах которые полностью или > >> частично реализуют необходимый функционал, прошу указать их. > > Возможно, http://wiki.openvz.org/Partners#Openwall; > Не до конца понял в какой форме они осуществляют процесс > резервирования. Если использовали прошу поделиться опытом. Нет, не использовал -- ссылку дал с тем, чтобы если покажется интересным -- связались сами. Люди в проекте OpenWall, с которыми довелось общаться -- крайне вменяемые, как минимум Solar Designer ещё и русскоязычный. > Про bacula почитаю подробнее, насколько я понял это самый > распространненный инструмент. Не знаю насчёт самого распространённого, но не исключено, что самый развитый; спроектирован и реализован тоже неплохо. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
next prev parent reply other threads:[~2012-01-09 12:11 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 2012-01-03 13:50 ` Илья Кучмин 2012-01-09 12:11 ` Michael Shigorin [this message] 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=20120109121159.GE16304@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