Резервное копирование — виртуальные клоны против неконсистентных кентавров

    Клоны Геракла и кентавр Нессоили простой способ создания консистентныx резервныx копий без остановки сервера с помощью клонирования виртуальных машин

    Идеальный бэкап в вакууме


    Системный администратор, настраивая резервирование данных на сервере, рисует в своем воображении прекрасные образы. Скрипт резервного копирования добросовестно складывает данные в архив, где они лежат в сохранности, внушают спокойствие. Случается катаклизм, в результате которого информация на дисках превращаются в тоскливую последовательность нулей без единой единицы. Нарастает паника, директор запирается в своем кабинете с пистолетом. И тут появляется герой, хладнокровно восстанавливает данные из последней резервной копии и через пол-часа сервер работает как ни в чем не бывало. Под торжественную музыку герой уходит в закат.

    Грубая реальность вносит коррективы: если при настройке копирования не предусмотреть множество мелочей, то при восстановлении может случиться так, что часть данных в бэкапе окажется повреждена непонятным образом. Легкое восстановление превратится в мучительные поиски кусочков в разных архивах и собирание из них одного целого. Уход в закат откладывается из-за нарушенной консистентности копии.

    Неконсистентность копии


    Понятие неконсистентности копии означает то, что вместо единого массива данных, отражающих состояние оригинала в один момент времени, копия состоит из нескольких частей, отражающих состояние соответствующих частей оригинала в разные моменты времени.

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

    Как появляются кентавры


    Самый простой и популярный способ резервного копирования — пофайловое копирование файловой системы. В архиве может сохраняться полная копия, создаваемая tar или cpio, или инкрементная с помощью dump, rsync, bacula. Все файлы файловой системы поочередно обходятся, возможно, проверяются на удовлетворение неким правилам и копируются в архив.

    Первая очевидная причина нарушения консистентности — изменение файлов, происходящее во время копирования. Сервер продолжает выполнять свои обычные задачи, файлы создаются, обновляются, удаляются. Чем дольше длится копирование, чем больше объем всех данных, чем больше скорость изменения данных в оригинале — тем большая получается неконсистентность копии. В одних случаях это будет малокритично — например, если ночью копируется корпоративный веб-сайт, на котором в это время изменяются только логи. А вот если в это время записывались изменения в репозиторий SVN, то не смотря на то, что SVN использует транзакции, после восстановления из такого бэкапа можно столкнуться с потерей или перемешиванием версий у произвольных компонентов.

    Как создаются клоны


    Клонирование дискаДля решения этой проблемы существует универсальная схема — клонирование диска или файловой системы, мгновенные снимки (snapshot). Реализации ее могут быть разными — например, с средствами самой файловой системы в UFS и ZFS, или уровнем ниже, на блочном устройстве в LVM/DeviceMapper или VHD. Со стороны пользователя это выглядит так, как будто в требуемый момент операционная система создает вторую копию файловой системы или блочного устройства. На создание снимка времени требуется очень мало (от нескольких миллисекунд до секунд), поэтому без ущерба для работы приложений блокируются все операции записи. В период создания снэпшота никаких изменений не происходит и копия получается консистентная.

    Годятся ли снэпшоты в качестве резервных копий? Для краткосрочный нужд — да. Например, перед какими-нибудь рискованными обновлениями будет полезно сделать снэпшот и, если что-то пойдет не так, откатить состояние по этому снэпшоту, а если все закончится хорошо, то снэпшот можно удалить. Использование снэпшотов имеет свою цену — замедление дисковых операций, увеличение расхода места на диске. Поэтому долговременное использование снэпшотов должно приносить пользы больше, чем будет теряться производительности. Для резервного копирования снэпшоты не годятся еще потому, что находятся там же, где и оригинал. Если пострадает оригинал, то с высокой вероятностью пострадает и копия.

    В резервировании снэпшоты используются в качестве неизменной файловой системы, которую можно копировать в удаленное хранилище сколь угодно долго и консистентность копии в конце копирования нарушена не будет. Копирование может выполняться теми же самыми dump/tar/rsync/bacula. После того, как снэпшот использован, его удаляют, чтобы не тратить впустую ресурсы.

    Консистентность данных сервера


    Решает ли это задачу чистого восстановления? Только частично. Мы получаем консистентную копию файловой системы, но не получаем консистентную копию всей информации сервера. Ведь есть еще приложения, которые оперируют данными в оперативной памяти и сохраняют их на диске. В памяти данные приложения консистентны, но записанные на диск — не обязательно. Информация записывается в файл в том порядке, в котором это удобно для приложения и операционной системы. Точка зрения системы резервирования об этом порядке приложение не интересует. Состояние копии соответствует состоянию диска сервера после внезапного отключения, например, обесточивания.

    Для веб-проектов потенциальная жертва неконсистентности — базы данных MySQL. Допустим, у нас активный проект с большим числом обновлений данных, в таблицы постоянно записываются данные. Сервер БД держит данные таблиц в оперативной памяти, периодически сбрасывая изменения на диск. К этому присоединяется еще операционная система, которая может задерживать данные в буферах записи, исходя из собственных соображений о том, что нужно для повышения производительности. Если мы сделаем в этот момент консистентную копию файловой системы, то в разных таблицах могут оказаться данные, актуальные на разные моменты времени, а в некоторых таблицах может быть нарушена целостность данных, если они в этот момент переносились в другое место.

    Это приводит нас к необходимости учитывать особенности работы каждого приложения, изменяющего данные на сервере. И адаптировать процесс создания резервных копий, заставляющие каждое приложение, изменяющее данные, сохранять их на диск перед созданием копии и воздержаться от их изменения во время копирования. Для сервера MySQL это заключается в блокировании таблиц на запись и сбросе изменений на диск одной командой FLUSH TABLES WITH READ LOCK, из разблокировании таблиц после создания копии командой UNLOCK TABLES. А если это Java-приложение со сторонними компонентами, об особенностях работы которых ничего не известно, ситуация осложняется и остается только полная остановка приложения. Для Windows-приложений предлагается специальный механизм Quiesce, с помощью которого операционная система дает знать приложениям, что она начинает бэкап и им нужно сбросить свои данные на диск или каким-то другим образом привести их на диске в консистентное состояние.

    На практике, именно эта часть либо часто упускается из виду при настройке резервного копирования, либо сисадмин (или разработчик) сознательно отказывается от дополнительных настроек, если считает, что риск в его ситуации незначительный и он не стоит дополнительных затрат на усложнение сценария копирования.

    Виртуальные клоны виртуальных машин


    Виртуальные машины за последние годы стали привычны и на десктопе, и на сервере. Прогресс делает жизнь людей более комфортной. Более комфортной он делает и жизнь системных администраторов. Серверные виртуальные машины удобно использовать для абстракции оборудования, для эффективного и плотного использования аппаратных ресурсов, для удобного администрирования большого числа функционально различных серверов, объединенных на небольшом количестве физических серверов. А еще виртуализация позволяет делать идеальный бекап, без мифических существ и фантастических мутантов.

    Клонирование работающей виртуальной машиныМногие среды виртуализации позволяют сохранить снимок работающей виртуальной машины (в отличие от диска, для этого чаще используется термин checkpoint, а не snapshot — чтобы не путать снимок памяти со снимком диска). В основном, они предназначены для разработки и тестирования, например, для сохранения состояние работающего сервера перед обновлением, чтобы при неудачном исходе откатиться назад. А с точки зрения резервного копирования, снимок памяти и диска является консистентной копией всех данных сервера. Таким образом, инструмент для получения идеального бэкапа у нас есть, и его нужно правильно применить.

    В Citrix XenServer (включая XenServer Free) и XCP для создания снимка виртуальной машины с памятью и диском используется команда xe vm-checkpoint. На время создания снимка работа виртуальной машины приостанавливается и после завершения продолжается. Снимок готов и находится в хранилище, но в таком виде его ценность как резервной копии невелика — как и в случае с снэпшотами диска, то, что хранится вместе с оригиналом, может пострадать вместе с оригиналом. Для получения копии, которую можно будет хранить где угодно, нужно воспользоваться командой xe vm-export, которая на выходе сохраняет память и диск виртуальной машины в xva-файл.

    Xen Hypervisor 4 в виде xend+xm, при размещении дисков машин на LVM, позволяет делать примерно то же самое. Стандартная команда xm save -c (сохранение с checkpoint) позволяет сохранить снимок памяти и продолжить затем работу виртуальной машины. Снимок диска при этом не создается, предполагая что этим займется кто-то другой. Первое приходящее в голову решение — поставить домен на паузу, сделать снэпшот диска, и только после этого делать снэпшот виртуальной машины. Но оно не пройдет, для того, чтобы домен мог сохраняться, Xen требует, чтобы он был в рабочем состоянии. Есть несколько способов решить эту задачу, для нас в итоге самым удобным оказался вариант с небольшой модификацией xend (можно взять наш сокращенный патч для Debian 6 с Xen 4.0 и при необходимости доработать под свои нужды: www.truevds.ru/misc.xen-checkpoint-clone-patch). Для этого достаточно указать в коде функции, ответственной за создания checkpoint, что в конфигурации сохраняемой виртуальной машины используются снэпшоты дисков, а не их оригиналы, и перед возобновлением работы виртуальной машины сделать эти снэпшоты стандартным способом LVM. После этого у нас будет файл со снимком памяти виртуальной машины и раздел LVM со снимком диска.

    Кроме основанных на Xen систем виртуализации, аналогичные возможности предоставляет VMWare и Hyper-V. В их терминологии checkpoint называется snaphost.

    Хороший клон — выключенный клон


    Выключенные клоны РоденаХранить в архиве полные копии памяти и дисков виртуальной машины не очень накладно, если это какой-то маленький сервер с маленькими данными. Если пытаться использовать эту схему для чего-то серьезного, скажем, production-сервера для посещаемого сайта с оперативной памятью 8 Гб и объемом данных на диске около 100 Гб, передача по сети и хранение 108 Гб на каждую копию быстро сделают цену резервирования непомерно высокой.

    Самый удобный способ хранения большого числа архивных копий — инкрементные бэкапы. Во время очередного копирования в архиве записывается не полная копия файловой системы, а только изменения, произошедшие после предыдущего копирования. Для этого нам требуется консистентная файловая система в которой находятся консистентные данные сервера.

    Есть единственное состояние сервера, в котором данные на диске сохранены приложениями максимально корректно и в оперативной памяти не меняются. Это состояние — корректно остановленный сервер. Все приложения, хоть как-то заботящиеся о сохранности своих данных, ценят и с готовностью подчиняются, когда операционная система просит их завершить свою работу — через stop-скрипты или через отправку сигнала SIGTERM. Файловая система остановленного таким образом сервера и является максимально возможным консистентным состоянием всех данных сервера.

    Клонирование дискаНам нужна файловая система в таком состоянии. У нас есть клон — снэпшот виртуальной машины и снэпшот диска. Нам нужно запустить виртуальную машину клона и дать его операционной системе команду остановки (shutdown). В XenServer/XCP для этого нужно будет конвертировать снэпшот в темплейт командой xe snapshot-copy и затем стартовать новую машину на этом темплейте. Xen Hypervisor достаточно запустить машину через xm restore.

    Клон не должен иметь возможность навредить оригиналу. В качестве диска клон использует собственный снимок (в xend/xm по умолчанию это не так, но исправляется упомянутым ранее патчем, сохраняющим снимок виртуальной машины) — диск оригинала клону не доступен. Но если оригинал работал с сетью, то и у клона будет сетевой интерфейс с такими же настройками. При включении возникнет конфликт между клоном и оригиналом за право общения с внешним миром. Поэтому сетевой интерфейс клона нужно деактивировать или изолировать внутри отдельной виртуальной сети, не выходящей в реальную. Метод остановки сервера зависит от того, как он сконфигурирован и чаще всего для PV-машины будет достаточно команды xm shutdow, а для HVM отправки ACPI power off.

    После отключения виртуальную машину клона можно удалить, и у нас остается снэпшот диска с чисто выполненной остановкой. Это будет файловая система с чистейшей консистентностью. Ее можно со спокойной душой отправлять в архив тем же методом, которым копируются обычные снэпшоты диска.

    Цена победы


    Есть мелкие трудности, связанные с тем, что для запуска клонов нужна оперативная память, которой вдруг может быть недостаточно; работа машины приостанавливается на время сохранения памяти. Их решение во много зависит от конкретных обстоятельств. Например, если мы, как порядочные люди, делаем резервирование ночью, то мы можем безболезненно отнять перед снимком у оригинала половину памяти и стартовать клона на освободившейся половине. Небольшая модификация xend позволяет делать снимок памяти даже без приостановки виртуальной машины (в XCP это тоже технически возможно, скорее всего у разработчиков просто пока не дошли до него руки).

    Переносить серверы в виртуальные машины для высоконагруженного интернет-проекта может быть лишним. Имея десятки или сотни однотипных серверов, будет практичнее отладить до мелочей и унифицировать процедуру резервного копирования средствами приложений, воплотив потом ее одну множество раз, чем тратить небольшой процент ресурсов на накладные расходы виртуализации.

    Медный всадник на закатеДля интернет-проектов меньшего масштаба или для разношерстного набора корпоративных серверов, затраты на организацию чистого резервирования с помощью виртуализации окажутся наименьшими в большинстве случаев. В итоге мы получаем возможность делать нормальные консистентные бэкапы сервера не занимаясь подгонкой сценариев резервирования под все многообразие приложений. При этом уменьшается риск, что какой-то из компонентов будет забыт или не сработает. Герой, восстановив сервер за десять минут, поскачет в закат на коне, без риска превратиться в кентавра.
    TrueVDS
    Виртуальные серверы с гарантированными ресурсами
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 28

      +3
      Если неправильно делать резервные копии, можно стать взадником без головы.
        0
        И без вазелина.
        0
        «Акатуальная» статья.
          0
          Странно что нет упоминания про дедупликацию данных (http://en.wikipedia.org/wiki/Data_deduplication), всё таки это хоть и дороже, но гораздо удобнее использования инкрементальных резервных копий.
            0
            Дедупликацию удобно организовать непосредственно на хранилище сервера, но тогда теряется смысл в использовании его как резервной копии.

            Если дедупликация выполняется средствами хранилища архива, а программа резервного копирования о дедупликации не заботится, то это означает, что в архив необходимо каждый раз передавать полную копию — не оправданный расход ресурсов.

            Если дедупликацией занимается программа резервного копирования, в том числе чтобы не передавать лишние данные по сети, то самая простая реализация дедупликации — инкрементное копирование.
              0
              Объясните пожалуйста, почему же смысл теряется?

              И почему же передавать нужно именно полную копию, имелась ввиду именно дедупликация посредством программы, и лично я не вижу в этом существенных проблем, т.к. инкрементальная резервная копия в описанном вашем примере в посте по размерам значительно уступает полной резервной копии. И даже если индексация этой копии будет занимать несколько часов, то для пользователя это уже никак не будет афектить.

              Создание инкрементальной резервной копии никак не является реализацией дедупликации, не путайте пожалуйста, это разные понятия.
              Если говорить проще: то инкрементальная копия отслеживает изменения по сравнению с последней созданной резервной копией. В случае использования дедупликации: происходит именно поиск уникальных данных создаваемых в различных резервных копиях.
              Например (ПРК — полная резервная копия; ИРК — инкрементальная резервная копия):
              В случае создания инкрементальных копий: ПРК+ИРК+ИРК+ИРК и так до бесконечности (при этом каждая ИРК будет содержать все изменения), если конечно вы не будете настраивать политики консолидации и очистки старых копий. Т.е. получится 100Гб + 8 Гб + 8 Гб + 8 Гб и т.д.
              В случае с дедупликацией: ПРК+ИРК+ИРК+ИРК… Но при этом размер будет значительно меньше, например 100Гб + 8 Гб + 1 Гб + 1 Гб и т.д.
                +1
                Хранить хоть снэпшоты, хоть дедуплицированные копии на том же хранилище, что и оригинал, бессмысленно по причине — если пострадает оригинал, то с высокой вероятностью пострадает и копия. Копии должны находиться максимально далеко и быть независимыми от оригинала.

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

                Мы почти везде используем rsync и для передачи копий, и для организации нескольких версий. Лет 10 назад кроме него ничего лучшего не было, и сейчас это для большинства наших задач отлично подходит, поэтому нет причин менять. Задачу по сокращению объема передаваемых и сохраняемых данных он решает хорошо. Таких же гибких, простых в эксплуатации и проверенных долгой практикой аналогов, которые были бы для нас лучше, скажем, в аспекте дедупликации, пока не нашел. Наверняка они есть, но предполагаемая дополнительная выгода от их использользования слишком мала, чтобы оправдать переход.

                Из современных способов дедупликации мне больше всего нравится дедупликация на блочном уровне, так как у нас становится все больше задач, в которых мы оперируем образами дисков и доступа в файловую систему не имеем и не должны иметь. Но пока «закидываем шапками» — когда необходимо, держим отдельные копии на дешевых дисках.

                По поводу конфликтности терминов дедупликация и инкрементность не соглашусь. Путаница — да, есть. Скажем, rsync, сделав хардлинки на одинаковые файлы добился того, что их данные не дублируются. Но rsync называется это incremental backup, а bacula — deduplication.
            –1
            Какая-то сильно «водная» статья. Вроде бы любому понятные очевидные вещи превратились в «многобукв».
              +1
              Статья большая, интересная, с картинками и большим количеством данных. Но есть еще один важный момент, наверняка присутствующий в сложных системах, о котором нет ни слова в статье, и который, увы, не позволяет — по-крайней мере, на мой текущий взгляд; надеюсь, вы меня переубедите — использовать метод резервирования виртуальнх снапшотов.

              К примеру, этот метод не подходит для резервирования контроллеров домена в случае, если их больше одного. При попытке восстановить контроллер со снимка мы получим проблему отката USN (USN Rollback). Лично с ней сталкивался с год назад, уповая как раз на механизмы, описанные в статье. Слава богу, была «обычная» резервная копия, но так как проблема обнаружилась только через несколько дней после восстановления, изрядно помучился, внедряя в старую копию изменения за прошедшее время. Наверняка точно такая же ситуация будет и в других системах, использующих репликацию «мастер-мастер», а уж в случае с «master-slave» — почти 100% при восстановлении master-ноды.
                0
                На уровне резервного копирования файловой системы решить вопрос конфликта версий узлов с взаимной репликацией невозможно. Думаю, описываемую ситуацию можно свести к такой:

                1) Есть серверы, синхронизирующие между собой данные, и имеющие в один и тот же момент одинаковую версию данных.
                2) Периодически выполняется резервное копирование снэпшотов файловой системы серверов. Версии данных при этом зависят от времени создания снэпшота и в общем случае у резервных копий, сделанных в одно и то же время, версия данных может не совпадать.
                3) Произошел отказ одного сервера. Его восстанавливают из бэкапа за прошлый день, с устаревшей версией данных. Остальные узлы, работавшие без аварии работают с актуальной версией данных.

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

                Мне трудно допустить, что у контроллера домена такая реакция на перерыв работе может быть нормой. В статье по ссылке описывалось условие, в котором возникла проблема — это был просто снэпшот, и восстановление из этого снэпшота привело к нарушению в работе. Судя по ней, контроллер доменов не поддерживает Quiesce, поэтому не сбрасывает корректно данные на диск перед снэпшотом. Могу предположить, что ни в вашем случае, ни в случае из KB MS, шатдаун клона на снэпшоте не выполнялся.

                В принципе, выполнив синхронно снэпшоты всех узлов, занимающихся репликацией, затем запустив их клоны в отдельной виртуальной сети, не пересекающейся с рабочей, и отправив их всех в шатдаун, мы получим консистентное состояние всей системы этих узлов. Но не вижу особой ценности в таком результате, ведь репликация master-master или master-slave нужна для того, чтобы не терять изменения, и при потере какого-то из узлов данные должны востанавливаться не по бэкапу, а из оставшихся узлов. И если мы вместо ресинхронизации узлов просто восстановим из бэкапа все узлы на прошлы день, мы потеряем произошедшие изменения.
                  +1
                  Боюсь, что я не очень корректно описал проблему, или она непонятно изложена в MS KB. Дело в том, что сохранив данные даже выключенной системы на уровне файлов (например, вытащив диск из сервера, вставив его в другой компьютер и скопировав данные), потом запустив сервер снова и через какое-то время (максимум — через 15 минут, потому что это минимальное промежуток между репликациями) восстановив файлы на старое место, полностью затерев предыдущие, вы получите ту же самую проблему.

                  Ситуация в следующем: при репликации AD используется USN (update sequence number) совместно с идентификатором вызова (invocation ID) для отслеживания изменений, переданных с источника обновления. Эти номера фиксируются. Если вы сняли снимок виртуальной машины, а затем продолжили работу, все участники репликации продолжают обмениваться данными. Если же затем вы восстановите систему из снимка, то номера не совпадут. А так как AD не транзакционная система и логов там не ведется, то восстановленный сервер просто не сможет договориться с остальными участниками репликации — он будет пытаться отдать данные с устаревшим USN и ID, а остальные откажутся их принимать (и, соответственно, отправлять свои), потому что для них этот номер уже в прошлом.

                  Поэтому MS прямо говорит (все в той же статье по ссылке выше), что нельзя для резервного копирования контроллеров домена использовать средства типа Norton Ghost или снимков виртуальных машин, потому что не заведется потом, если данные реплицируются. При использовании штатных (или разработанных специально сторонних) средств в вышеуказанном случае происходит корректное обнуление (reset) USN и ID, и конфликта не возникает.

                  Кроме того, мне неясна, честно говоря, мысль «для получения инкрементных бэкапов нам нужно иметь снимок выключенной машины» либо она не до конца у вас в статье развернута. Безусловно, чтобы иметь возможность делать консистентный инкрементный бэкап, нужно иметь снимок файловой системы, но как вы планируете в дальнейшем добраться до файлов, расположенных на снимке диска виртуальной машины? (может, я просто невнимательно прочитал статью и не увидел решения?) Если же отправлять всё целиком, то неясен смысл выключения клона, отправить прямо с памятью и в случае чего получить рабочую копию в уже работающем состоянии.

                  Отсюда же неясна ссылка на приведенный мной случай — сохранялся снимок всей машины и восстанавливался так же весь. Т.е. о неконсистентности данных в рамках виртуальной машины говорить просто не приходится.

                  В общем, я к чему разговор завел — предложенный метод именно в данном виде подходит для отдельных серверов либо небольших проектов, не завязанных друг на друга системами репликации. Во всех остальных случаях бессмысленно полагаться только на снимки системы на уровне виртуальной машины, потому что необходимо работать с резервированием\восстановлением данных на уровне приложения, а в таких условиях при использовании соответствующих файловых систем (т.е. позволяющих иметь снимки) нет нужды в чем-то сверху. Если мы заставили приложение сбросить на диск всю информацию из буферов в памяти, а затем создали снимок файловой системы, то мы можем всё, что нам нужно, сделать из самой виртуальной машины.

                  Конечно, если у нас куча виртуальных машин, то удобнее организовать это снаружи, но без вмешательства в работу виртуальной машины (т.е. без агента, работающего в ней, причем такого, который поддерживал бы все приложения, выполняющиеся там) полноценно сделать это нельзя.
                    0
                    А что мешает использовать СРК, которые поддерживают корректное восстановление ВМ с ролью Контроллера Домена, например Symantec Backup Exec или Veeam Backup & Replication или что-то серьезнее?
                      0
                      Если эти средства позволяют восстанавливать VM из снимка (snapshot) виртуальной машины — то ничего не мешает. Только они ведь не позволяют. Они делают собственный backup, возможно, будучи установленными на host-систему (я, к сожалению, не работал с ни с одной из этих систем, поэтому не знаю), но скорее всего требуют либо отдельную физическую машину, либо стоят в отдельной виртуальной машине, а на остальные VM ставят свои backup-агенты.
                        0
                        Для бекапа они временно создают snapshot'ы ВМ, если вы об этом.
                      0
                      Теперь понятно, USN для каждого сервера собственный, я сначала предположил, что он общий для всех. С учетом изложенного вами поведения узлов при встрече с устаревшими USN, получается, что протоколом их взаимного резервирования состояние консистентности распространяется на всю группу.

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

                      В принипе, можно представить в качестве аналогии приложение, использующее базу данных. Если они находятся на одном сервере и останавливаются одновременно и у них есть стандартная последовательность остановки: приложение сможет закрыть свои внутренние данные, сбросить их в базу, а база сбросить на диск. При шатдауне клона все будет выполнено правильно. Если находятся на разных серверах, то для сохранения консистентности их нужно клонировать и останавливать синхронно, чтобы они выполнили полностью штатные процедуры остановки не теряя связи друг с другом.
                        0
                        как вы планируете в дальнейшем добраться до файлов, расположенных на снимке диска виртуальной машины?

                        Некоторые утилиты делают бэкап прямо с блочного устройства (dump) без монтирования. А в общем случае, для пофайлового копирования файловую систему можно монтировать в хост-системе, в отдельной виртуальной машине для копирования, экспортировать по iscsi на внешний сервер копирования бэкапов. У нас сейчас используется rsync в хост-системе, но есть планы изолировать копирование в отдельную виртмашину.
                    0
                    Извиняюсь за офтоп. Для ESXi, вроде как, есть платные приблуды для репликации виртуалок в реальном времени. Кто-нибудь, интересно, пользовался?
                      0
                      м, так а встроенная клонирование это не одно и то же?
                        0
                        Так клонирование — это вроде просто снапшот. А нужна репликация мастер-слэйв.
                          +1
                          Есть в XenServer (так и называется HA) и в патчах XEN Remus (уже включены в основную ветку). Реализуется через постоянную Live миграцию виртуалки с мастер хоста на бэкап хост. К данному топику имеет слабое отношение.
                            0
                            Про репликацию в Veeam уже упоминали ниже, хотя там действительно не совсем синхронная реплика.
                            В составе платных редакций начиная с Enterprise есть механизм создания на другом ESXi теневой копии защищаемой вм — Fault Tolerance.
                          0
                          а насчёт тулов да, вроде как Acronis и Veeam есть. Там есть подобный функционал.
                            0
                            Можно настроить синхронную репликацию на уровне СХД, умеют многие СХД middle и high-end уровня, обычно при покупке соответствующих опций.

                            Все известные мне программные решения реплицируют на уровне ВМ и обеспечивают только асинхронную репликацию. Хотя Veeam Backup & Replication умеет то, что называется near online replication (т.е. запускает задание репликации сразу после завершения предыдущего, т.е. каждые 3-7 минут, зависит от дисковой активности реплицируемой ВМ). Site Recovery Manager 5 может реплицировать не чаще, чем раз в 15 минут, у других примерно также.
                              0
                              Тоже за синхронную репликацию СХД. Но нужно всегда учитывать, что и репликация СХД, и репликации ВМ могут оказаться неконсистентными при старте резерва и часть данных окажется неживой. С этой точки зрения репликация ВМ, если выполняется с quiesce и приложения их поддерживают, может оказаться более надежным решением.
                            0
                            Я сколько работал с ксеном, /etc/init.d/xendomains stop не всегда корректно отрабатывал, а вы это на поток ставите.
                            И как праверить, что бэкап целостный
                            А если у тебя побитый бэкап, это еще хуже чем его нет вовсе

                            А активная работа с LVM снапшотами может привести к самым неожиданным последствиям, это очень узкое звено.
                              0
                              Скорее всего, это ваш личный негативный опыт. Мы работаем с ксеном 4 года и все решаемо. Баги, конечно, встречаются. Но их можно либо самостоятельно устранять, либо репортить и ждать, когда устранят разработчики.

                              Про побитый бэкап не понятно кому адресован вопрос. Верифицируйте бэкап тем способом, к которому привыкли.

                              В чем претензия к снэпшотам LVM? Они приводят к закономерной деградации производительности, в этом нет ничего неожиданного и в статье про это написано. Собственно, как статья и показывает, как минимизировать деградацию.
                                0
                                Мы тоже работаем с ксеном 4 года. Не в таких промышленных масштабах как Вы, но около 30-40 хост-систем с ~25 виртуальных машин на каждой имеется.
                                Баги встречаются и «самостоятельно устранять» — это самое интересное. Вы преподнесли статью как готовую HowTo, преподнеся как готовое стабильное решение, а самое интересное не написали. Какие баги возникли при остановке доменов XEN и как пофиксили?

                                Верификация бэкапа — это важнейший момент. Вы его упускаете.

                                При активной работе с LVM снапшотами наблюдается не деградация проивзодительности, а полный отказ системы. (Был эксперимент по запуску корневого раздела машин на снапшотах)
                                  0
                                  В основном, проблемы случаются не с самим ксеном, а с конкретными версиями паравиртуальных ядер. Самые простые решения — менять ядра, или использовать HVM. Другие проблемы при частном или корпоративном использовании вряд-ли будут пересекаться с нашими, т.к. связаны с тем, что стандартное окружение ксен подготовлено для отдельных серверов, а у нас условия сильно от этого отличаются.

                                  Я написал ровно о том, о чем заявлено — про метод создания консистентных бэкапов. Верификация бэкапа — один из аспектов, ничем не важнее остальных, таких как- среда и место хранения, метод ротации и удаления. У вас были бы основания сказать, что я все это упустил, если бы я заявил, что это учебник о бэкапах от и до.

                                  С LVM скорее всего вам не повезло с конкретным багом и конкретными условиями. Не могу больше ничего сказать про ваш случай. На моих личных десктопах при загрузке автоматически создается снэпшот корня и система потом стартует на этом снэпшоте. Ни разу связанных с этим проблем за пару лет не было.

                            Only users with full accounts can post comments. Log in, please.