Как сделать снимок файловой системы

Как создать
Содержание
  1. Backup и Snapshot: что это?
  2. Резервное копирование (backup)
  3. Виды резервного копирования
  4. Полное резервное копирование
  5. Дифференциальное копирование
  6. Инкрементное копирование
  7. Время резервного копирования
  8. Инструменты резервного копирования
  9. Встроенные инструменты резервного копирования
  10. Бесплатные и платные программы резервного копирования
  11. Облачное резервное копирование
  12. Shapshot – снимки системы
  13. Файловые службы
  14. Снэпшоты в виртуальных машинах
  15. Выводы
  16. Можно ли сделать снимок / (или другой) файловой системы, как в VirtualBox?
  17. 3 ответа
  18. rsync
  19. Гипервизор Xen
  20. rsnapshot
  21. Бэкап для Linux, или как создать снапшот
  22. Немного теории в начале
  23. How it works — в теории
  24. Снапшот под микроскопом
  25. CoW vs RoW
  26. How it works — на практике
  27. Согласованное состояние
  28. Где расположить снапстору?
  29. Переполнение снапшота
  30. Change Block Tracking (CBT)
  31. Проблема производительности
  32. Throttling
  33. Deadlock
  34. Round Robin Database
  35. Выбор размера блока
  36. Вместо заключения

Backup и Snapshot: что это?

До появления виртуальных машин все администраторы делились на две группы: тех, кто еще не делает бэкапы (bakup — резервное копирование), и тех, кто уже делает.

С появлением гипервизоров выделились еще две полярные группы: тех, кто еще не делает снэпшоты (snapshot — снимки файловой системы), и тех, кто уже делает.

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

Резервное копирование (backup)

Резервные копии нужны для восстановления утраченной или испорченной информации. Также резервное копирование применяется для архивирования (сохранения данных для использования их в будущем).

Копировать можно:

Виды резервного копирования

Существует несколько видов резервного копирования.

Полное резервное копирование

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

Дифференциальное копирование

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

Инкрементное копирование

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

Время резервного копирования

Для того чтобы правильно планировать резервное копирование, необходимо рассчитать два показателя: RPO и RTO.

RPO (recovery point objective) – это максимальный период времени, за который могут быть потеряны данные в результате аварии. Например, у нас есть информационная система, и если произойдет авария, и мы готовы ее восстановить за один час. Это значит, что за этот час новые данные не будут поступать в нашу информационную систему, и RPO равняется часу. Эти данные невозможно восстановить из резервной копии, потому что они не поступали в информационную систему. Показатель RPO говорит нам, как часто делать резервные копии нашей системы. На основании RPO мы можем выбрать нужную систему резервного копирования и какие технологии применять, чтобы вписаться в этот промежуток времени. Можно ли свести его к нулю? Можно, если использовать два хранилища, которые работают зеркально.

RTO (recovery time objective) — это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Например, в серверной произошла авария, и мы хотим, чтобы система была снова доступна через час. Это и есть значение RTO. Мы должны создать такой план аварийного восстановления, чтобы за этот час восстановить работоспособность информационной системы на резервном оборудовании или площадки.

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

Инструменты резервного копирования

Все инструменты резервного копирования можно поделить на следующие группы:

Встроенные инструменты резервного копирования

Современные операционные системы уже включают в себя инструменты резервного копирования. Например, для Windows, начиная с Microsoft Vista, доступна программа Windows Backup And Restore (Архивация и Восстановление). Эта программа позволяет создавать полный бэкап операционной системы с возможностью инкрементного копирования. Windows Backup And Restore позволяет создавать автоматический полный бекап на сменный носитель, оптические диски или в специальное место на удаленном сервере.

Для копирования небольшого количества файлов и каталогов часто используется команда xcopy. Эту команду можно использовать с планировщиком Windows.

Для UNIX-систем самой популярной программой резервного копирования файлов является утилита rsync. Оно обладает богатыми возможностями, включая инкрементное резервное копирование, обновление всего дерева каталогов и файловой системы, как локальных, так и удаленных резервных копий, сохранение прав доступа к файлам, ссылок и многое другое.

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

Бесплатные и платные программы резервного копирования

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

Главное – это перед использованием на реальных данных проверить на тестовой копии тех же самых данных. Кроме того, необходимо проверить можно или восстановить данные из архива.

Облачное резервное копирование

Существуют решения, которые позволяют копировать в облако не только данные, но и целые виртуальные машины. Так

Такие системы, как CommVault или Veeam позволяют делать резервные копии в облако для:

При резервном копировании в облако через сеть Интернет особенно важно учитывать значения RPO и RTO, так как каналы с Интернет обычно достаточно медленные.

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

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

Shapshot – снимки системы

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

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

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

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

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

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

Читайте также:  Как сделать свой энергетический напиток

Рассмотрим виды создания снэпшотов.

Файловые службы

В современных версиях Windows перезапись или удаление файла можно откатить благодаря наличию теневой копии.

В теневых копиях (VSS) содержатся записи об изменениях файлов. Копии делаются автоматически каждый час — по умолчанию Windows хранит 64 копии файла. Использовать копии можно без прав администратору.

Вот важные особенности теневых копий:

В UNIX-системах можно использовать файловую систему ZFS, которая предоставляет широкие возможности по созданию и управлению снимками файловой системы.

Снимки могут быть сделаны одноразовыми или запланированными как задание cron. В любой момент вся файловая система может быть отброшена до последнего моментального снимка. Старые снимки могут быть клонированы и доступны для восстановления данных из этой версии файловой системы.

Снэпшоты в виртуальных машинах

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

Такие гипервизоры, как Hyper-V или Wmware vSphere содержат встроенные средства создания снэпшотов. Использование СХД для размещения виртуальных машин и их снэпшотов позволяет снизить влияние снимков на производительность виртуальных машин, благодаря особенному устройству дисковых массивов.

Если вы используете виртуальные машины, размещенные в облаке провайдера, то для создания снимков необходимо в панели управления ввести имя снэпшота, и нажать на кнопку «Сделать снимок».

Выводы

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

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

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

Бэкап важных данных следует делать в соответствии с правилом 3-2-1:

1. Создавайте три копии важных данных.

2. Две копии должны быть сохранены на различных физических носителях.

3. Одна копия должна храниться отдельно от двух других, в другом здании.

Источник

Можно ли сделать снимок / (или другой) файловой системы, как в VirtualBox?

Создание снимка корневого раздела позволит откатиться до предыдущего состояния. Это очень полезно, когда что-то пошло не так и / или произошла потеря данных. Эту функцию можно увидеть на жестком диске VirtualBox и опцию персистентности на live CD. В отличие от резервного копирования, он использует инкрементное использование данных, поэтому размер данных меньше. Можно ли сделать снимок файловой системы?

3 ответа

Что вам действительно нужно, так это BTRFS

rsync

Создание снимка корневого раздела сделает возможным откат к предыдущему состоянию

Мы называем это процедурой резервного копирования, и для инкрементных резервных копий вы можете использовать rsync 😉

Удаленное резервное копирование

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

Grsync

Grsync является графическим интерфейсом:

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

Гипервизор Xen

Существуют и другие методы: Гипервизор Xen.

Вы можете запускать все свои операционные системы на гипервизорах (т. Е. На виртуальных машинах). Xen является примером такой установки. По сути, вы превращаете ВСЕ свои операционные системы в виртуальные машины и можете скопировать контейнер виртуальных машин под новым именем, и у вас будет точка резервного копирования или восстановления.

Начиная с Ubuntu 11.10 (Oneiric), ядро ​​по умолчанию, включенное в Ubuntu, может использоваться непосредственно с гипервизором Xen в качестве домена управления (или контроля) (Dom0 или Domain0 в терминологии Xen).

Остальная часть этого руководства дает базовый обзор того, как настроить базовую систему Xen и создать простых гостей. В нашем примере LVM используется для виртуальных дисков и сетевого моста для виртуальных сетевых карт. Предполагается также Xen 4.1 (версия доступна в 12.04) и набор инструментов xend. Он предполагает знакомство с общими проблемами виртуализации, а также со специальной терминологией Xen. Пожалуйста, смотрите вики Xen для получения дополнительной информации.

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

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

rsnapshot

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

Снимки локальной файловой системы обрабатываются с помощью rsync. Защищенные удаленные соединения обрабатываются с помощью rsync через ssh, тогда как анонимные соединения rsync просто используют сервер rsync. Как удаленная, так и локальная передача зависят от rsync.

Источник

Бэкап для Linux, или как создать снапшот

Всем привет! Я работаю в Veeam над проектом Veeam Agent for Linux. С помощью этого продукта можно бэкапить машину с ОС Linux. «Agent» в названии означает, что программа позволяет бэкапить физические машины. Виртуалки тоже бэкапит, но располагается при этом на гостевой ОС.

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

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

Всех заинтересовавшихся прошу под кат!

Немного теории в начале

Исторически так сложилось, что есть два подхода к созданию бэкапов: File backup и Volume backup. В первом случае мы копируем каждый файл как отдельный объект, во втором – копируем всё содержимое тома в виде некоего образа.

У обоих способов есть масса своих плюсов и минусов, но мы рассмотрим их через призму восстановления после сбоя:

Как же нам взять и сохранить весь том целиком? Само собой, простым копированием мы ничего хорошего не добьёмся. Во время копирования на томе будет происходить какая-то активность с данными, в итоге в бэкапе окажутся несогласованные данные. Структура файловой системы будет нарушена, файлы баз данных повреждены, как и прочие файлы, с которыми во время копирования будут производиться операции.

Чтобы избежать всех этих проблем, прогрессивное человечество придумало технологию моментального снимка – снапшота. В теории всё просто: создаём неизменную копию – снапшот – и бэкапим данные с него. Когда бэкап окончен – снапшот уничтожаем. Звучит просто, но, как водится, есть нюансы.

Читайте также:  Как сделать сапожный крючок своими руками

Из-за них было рождено множество реализаций этой технологи. Например, решения на основе device mapper, такие, как LVM и Thin provisioning, обеспечивают полноценные снапшоты томов, но требуют специальной разметки дисков ещё на этапе установки системы, а значит, в общем случае не подходят.

BTRFS и ZFS дают возможность создавать моментальные снимки подструктур файловой системы, что очень здорово, но на данный момент их доля на серверах невелика, а мы пытаемся сделать универсальное решение.

Предположим, на нашем блочном девайсе есть банальная EXT. В этом случае мы можем использовать dm-snap (кстати, сейчас разрабатывается dm-bow), но тут — свой нюанс. Нужно иметь на готове свободное блочное устройство, чтобы было куда отбрасывать данные снапшота.
Обратив внимание на альтернативные решения для бэкапа, мы заметили что они, как правило, используют свой модуль ядра для создания снапшотов блочных устройств. Этим путём решили пойти и мы, написав свой модуль. Решено было распространять его по GPL лицензии, так что в открытом доступе он доступен на github.

How it works — в теории

Снапшот под микроскопом

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

По сути, veeamsnap (так мы назвали свой модуль ядра) – это фильтр драйвера блочного устройства.

Его работа заключена в перехвате запросов к драйверу блочного устройства.

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

А что такое сам снапшот? Это виртуальное блочное устройство, копия оригинального устройства на конкретный момент времени. При обращении к блокам данных на этом устройстве они могут быть считаны либо со снапсторы, либо с оригинального устройства.

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

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

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

CoW vs RoW

Давайте немного остановимся на выборе алгоритма работы снапшота. Выбор тут не особо обширен: Copy-on-Write или Redirect-on-Write.

Redirect-on-Write при перехвате запроса на запись перенаправит его в снапстору, после чего все запросы на чтение этого блока будут уходить туда же. Замечательный алгоритм для систем хранения, построенных на базе В+ деревьев, таких, как BTRFS, ZFS и Thin Provisioning. Технология стара как мир, но особенно хорошо она проявляет себя в гипервизорах, где можно создать новый файл и писать туда новые блоки на время жизни снапшота. Производительность – отличная, по сравнению с CoW. Но есть жирный минус – структура оригинального устройства меняется, а при удалении снапшота надо скопировать все блоки из снапсторы в оригинальное место.

Copy-on-Write при перехвате запроса копирует в снапстору данные, которые должны подвергнуться изменению, после чего позволяет их перезаписать в оригинальном месте. Используется для создания снапшотов для LVM томов и теневых копий VSS. Очевидно, для создания снапшотов блочных устройств он подходит больше, т.к. не меняет структуру оригинального устройства, и при удалении (или аварии) снапшот можно просто отбросить, не рискуя данными. Минус такого подхода – снижение производительности, так как на каждую операцию записи добавляется пара операций чтение/запись.

Поскольку обеспечение сохранности данных для нас основной приоритет, мы остановились именно на CoW.

Пока всё выглядит просто, поэтому давайте пройдёмся по проблемам из реальной жизни.

How it works — на практике

Согласованное состояние

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

Но мы же в 21-м веке живём! Есть же механизмы журналирования, предохраняющие от подобных проблем! Замечание верное, правда, есть важное “но”: эта защита не от сбоя, а от его последствий. При восстановлении в согласованное состояние по журналу незавершённые операции будут отброшены, а значит — потеряны. Поэтому важно сместить приоритет на защиту от причины, а не лечить последствия.

Систему можно предупредить о том, что сейчас будет создан снапшот. Для этого в ядре есть функции freeze_bdev и thaw_bdev. Они дёргают функции файловой системы freeze_fs и unfreeze_fs. При вызове первой система должна сбросить кэш, приостановить создание новых запросов к блочному устройству и дождаться завершения всех ранее сформированных запросов. А при вызове unfreeze_fs файловая система восстанавливает своё нормальное функционирование.

Получается, что файловую систему мы можем предупредить. А что с приложениями? Тут, к сожалению, всё плохо. В то время, как в Windows существует механизм VSS, который с помощью Writer-ов обеспечивает взаимодействие с другими продуктами, в Linux каждый идёт своим путём. На данный момент это привело к ситуации, что задача администратора системы самостоятельно написать (скопировать, украсть, купить, etc) pre-freeze и post-thaw скрипты, которые будут подготавливать их приложение к снапшоту. Со своей стороны, в ближайшем релизе мы внедрим поддержку Oracle Application Processing, как наиболее часто запрашиваемую нашими клиентами функцию. Потом, возможно, будут поддержаны и другие приложения, но в целом ситуация довольно печальна.

Где расположить снапстору?

Это вторая встающая на нашем пути проблема. С первого взгляда проблема не очевидна, но, немного разобравшись, увидим, что это та ещё заноза.

Конечно же, самое простое решение — расположить снапстору в RAM. Для разработчика вариант просто отличный! Всё быстро, очень удобно делать отладку, но есть косяк: оперативка — ресурс ценный, и расположить там большую снапстору нам никто не даст.

ОК, давайте сделаем снапстору обычным файлом. Но возникает другая проблема – нельзя бэкапить том, на котором расположена снапстора. Причина проста: мы перехватываем запросы на запись, а значит, будем и перехватывать свои собственные запросы на запись в снапстору. Кони бегали по кругу, по-научному — deadlock. Следом возникает острое желание использовать для этого отдельный диск, но никто ради нас в сервера диски добавлять не будет. Работать надо уметь на том что есть.

Расположить снапстору удалённо — идея отличная, но реализуема в очень уж узких кругах сетей с большой пропускной способностью и микроскопических латенси. Иначе во время удержания снапшота на машине будет пошаговая стратегия.

Значит, надо как-то хитро расположить снапстору на локальном диске. Но, как правило, всё место на локальных дисках уже распределено между файловыми системами, и заодно надо крепко подумать, как обойти проблему deadlock’a.

Направление для раздумий, в принципе, одно: надо как-то аллоцировать у файловой системы пространство, но с блочным устройством работать напрямую. Решение этой проблемы было реализовано в user-space коде, в сервисе.

Существует системный вызов fallocate, который позволяет создать пустой файл нужного размера. При этом фактически на файловой системе создаются только метаданные, описывающие расположение файла на томе. А ioctl FIEMAP позволяет нам получить карту расположения блоков файла.

И вуаля: мы создаём файл под снапстору с помощью fallocate, FIEMAP отдаёт нам карту расположения блоков этого файла, которую мы можем передать для работы в наш модуль veeamsnap. Далее при обращении к снапсторе модуль делает запросы напрямую к блочному устройству в известные нам блоки, и никаких deadlock’ов.

Но тут есть нюанс. Системный вызов fallocate поддерживается только XFS, EXT4 и BTRFS. Для остальных файловых систем вроде EXT3 для аллокации файла его приходится полностью записывать. На функционале это сказывается увеличением времени на подготовку снапсторы, но выбирать не приходится. Опять таки, работать надо уметь на том что есть.

А что, если ioctl FIEMAP тоже не поддерживается? Это реальность NTFS и FAT32, где нет даже поддержки древнего FIBMAP. Пришлось реализовать некий generic алгоритм, работа которого не зависит от особенностей файловой системы. В двух словах алгоритм такой:

Читайте также:  Как сделать voip сервер

Переполнение снапшота

Вернее, заканчивается место, которые мы выделили под снапстору. Суть проблемы в том, что новые данные некуда отбрасывать, а значит, снапшот становится непригоден для использования.
Что делать?

Очевидно, надо увеличивать размер снапсторы. А насколько? Самый простой способ задания размера снапсторы – это определить процент от свободного места на томе (как сделано для VSS). Для тома в 20 TB 10% будет 2TB – что очень много для ненагруженного сервера. Для тома в 200 GB 10% составит 20GB, что может оказаться слишком мало для сервера, интенсивно обновляющего свои данные. А есть ещё тонкие тома…

В общем, заранее прикинуть оптимальный размер требуемой снапсторы может только системный администратор сервера, то есть придётся заставить человака подумать и выдать своё экспертное мнение. Это не соотвествует принципу «It just work».

Для решения этой проблемы мы разработали алгоритм stretch snapshot. Идея состоит в разбиении снапсторы на порции. При этом, новые порции создаются уже после создания снапшота по мере необходимости.

Опять же коротенько алгоритм:

Что делать в других случаях? Пытаемся угадать необходимый размер и создаём всю снапстору целиком. Но по нашей статистике, подавляющее большинство Linux серверов сейчас используют EXT4 и XFS. EXT3 встречается на старых машинах. Зато в SLES/openSUSE можно наткнуться на BTRFS.

Change Block Tracking (CBT)

Инкрементальный или дифференциальный бэкап (кстати, слаще хрен редьки или нет, предлагаю читать тут) – без него нельзя представить ни один взрослый продукт для бэкапа. А чтобы это работало, нужен CBT. Если кто-то пропустил: CBT позволяет отслеживать изменения и записывать в бэкап только изменённые с последнего бэкапа данные.

Свои наработки в этой области есть у многих. Например, в VMware vSphere эта функция доступна с 4-ой версии в 2009 году. В Hyper-V поддержка внедрена с Windows Server 2016, а для поддержки более ранних релизов был разработотан собственный драйвер VeeamFCT ещё в 2012-м. Поэтому, для нашего модуля мы не стали оригинальничать и использовали уже работающие алгоритмы.
Коротенько о том, как это работает.

Весь отслеживаемый том разбит на блоки. Модуль просто отслеживает все запросы на запись, помечая изменившиеся блоки в таблице. Фактически, таблица CBT – это массив байт, где каждый байт соответствует блоку и содержит номер снапшота, в котором он был изменён.
Во время бэкапа номер снапшота записывается в метаданные бэкапа. Таким образом, зная номера текущего снапшота и того, с которого был сделан предыдущий успешный бэкап, можно вычислить карту расположения изменившихся блоков.

Тут есть два нюанса.

Как я сказал, под номер снапшота в таблице CBT выделен один байт, значит, максимальная длина инкрементальной цепочки не может быть больше 255. При достижении этого порога таблица сбрасывается и происходит полный бэкап. Может показаться неудобным, но на самом деле цепочка в 255 инкрементов – далеко не самое лучшее решение при создании бэкап-плана.
Вторая особенность – это хранение CBT таблицы только в оперативной памяти. А значит, при перезагрузке целевой машины или выгрузке модуля она будет сброшена, и опять-таки, понадобится создавать полный бэкап. Такое решение позволяет не решать проблему старта модуля при старте системы. Кроме того, отпадает необходимость сохранять CBT таблицы при выключении системы.

Проблема производительности

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

Представим, что сервер просто линейно пишет какие-то данные. Скорость записи в таком случае максимальна, все задержки минимизированы, производительность стремится к максимуму. Теперь добавим сюда процесс бэкапа, которому при каждой записи надо ещё успеть выполнить алгоритм Copy-on-Write, а это дополнительная операция чтения с последующей записью. И не забывайте, что для бэкапа надо ещё читать данные с этого же тома. Словом, ваш красивый linear access превращается в беспощадный random access со всеми вытекающими.

С этим явно надо что-то делать, и мы реализовали конвейер, чтобы обрабатывать запросы не по одному, а целыми пачками. Работает это так.

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

Throttling

Уже на стадии отладки всплыл ещё нюанс. Во время бэкапа система становилась неотзывчивой, т.е. системные запросы ввода-вывода начинали выполняться с большими задержками. Зато, запросы на чтение данных со снапшота выполнялись на скорости, близкой к максимальной.
Пришлось немного придушить процесс бэкапа, реализовав механизм тротлинга. Для этого читающий из образа снапшота процесс переводится в состояние ожидания, если очередь перехваченных запросов не пуста. Ожидаемо, система ожила.

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

Deadlock

Я думаю, надо немного подробней объяснить, что это такое.

Уже на этапе тестирования мы стали сталкиваться с ситуациями полного повисания системы с диагнозом: семь бед – один ресет.

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

В данной ситуации при перехвате запроса на запись, модуль, копируя данные в снапстору, отправит запрос на запись LVM-тому. Device mapper перенаправит этот запрос на блочное устройство. Запрос от device mapper-а снова будет перехвачен модулем. Но новый запрос не может быть обработан, пока не обработан предыдущий. В итоге, обработка запросов заблокирована, вас приветствует deadlock.

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

Round Robin Database

Это уже проблема, подкинутая пользователями после релиза первой версии.
Оказалось, есть такие сервисы, которые только и занимаются тем, что постоянно перезаписывают одни и те же блоки. Яркий пример – сервисы мониторинга, которые постоянно генерируют данные о состоянии системы и перезаписывают их по кругу. Для таких задач используют специализированные циклические базы данных (RRD).
Выяснилось, что при бэкапе таких баз снапшот гарантированно переполнится. При детальном изучении проблемы мы обнаружили недочёт в реализации CoW алгоритма. Если перезаписывался один и тот же блок, то в снапстору каждый раз копировались данные. Результат: дублирование данных в снапсторе.

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

Выбор размера блока

Теперь, когда снапстора разбита на блоки встает вопрос: а какого, собственно, размера делать блоки для разбиения снапсторы?

Проблема двоякая. Если блок сделать большим, им легче оперировать, но при изменении хотя-бы одного сектора, придётся отправить весь блок в снапостору и, как следствие, повышаются шансы на переполнение снапсторы.

Очевидно, что чем меньше размер блока, тем больший процент полезных данных отправляется в снапстору, но как это ударит по производительности?

Правду искали эмпирическим путём и пришли в результату в 16KiB. Также отмечу, что в Windows VSS тоже используются блоки в 16 KiB.

Вместо заключения

На этом пока всё. За бортом оставлю множество других, не менее интересных проблем, таких, как зависимость от версий ядра, выбор вариантов распространения модуля, kABI совместимость, работа в условиях бекпортов и т.д. Статья и так получилась объёмной, поэтому я решил остановиться на самых интересных проблемах.

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

Источник

Оцените статью
Полезные советы и лайфхаки для жизни