Обзор популярных файловых систем в системах виртуализации. Часть 2: BTRFS
В прошлом материале мы рассказали о типах файловых систем и подробно остановились на системе ZFS. В второй части подробно разберем BTRFS — файловую систему для Unix-подобных ОС.
Файловая система BTRFS хорошо известна производительностью в средах Linux. Она ориентирована на защиту от повреждений, простоту восстановления и администрирования данных.
В основе BTRFS (B-Tree Filesystem) лежит метод управления ресурсами в компьютерном программировании Copy-on-write (CoW). Его применяют при проведении дублирования или копирования изменяемых ресурсов. Система упрощает масштабирование файловой системы, обеспечивает надежность, гибкость настроек и простоту администрирования при высокой скорости работы.
История BTRFS
BTRFS — молодая файловая система, опубликованная корпорацией Oracle в 2007 году как альтернатива ZFS. Ее разработчики стремились избавиться от недостатков, присущих ранним файловым системам для Linux и упростить интерфейс управления.
Особенности файловой системы
BTRFS решает широкий спектр задач, однако, у нее есть свои недостатки:
активное развитие приводит к изменению ключевых моментов, на которые могут опираться сторонние утилиты при работе с системой;
высокая подверженность фрагментации, которая устраняется при помощи функции онлайн-дефрагментации;
скудная и местами устаревшая документация;
проблемы на разных версиях ядер;
ограниченная поддержка другими операционными системами: Btrfs разработана для использования в Linux и имеет ограниченную или отсутствующую поддержку в других операционных системах;
отсутствие поддержки RAID5 и RAID6: Btrfs не полностью поддерживает RAID5 и RAID6, что может быть недостатком для пользователей, которым нужна дополнительная защита данных и возможность восстановления данных после сбоя диска;
большой размер метаданных: Btrfs требует большого объема метаданных для управления файловыми системами, что может занять значительное количество дискового пространства.
Основные возможности BTRFS:
максимальный размер файла 2^64 байт;
динамическая таблица inode;
сжатие и дедупликация данных;
эффективное хранение файлов разных размеров;
создание сабвольюмов и снапшотов;
квоты на размеры сабвольюмов;
контрольные суммы для данных и метаданных;
создание RAID конфигурации на уровне файловой системы.
Архитектура BTRFS
BTRFS состоит из нескольких уровней.
На базовом уровне — блочные устройства, которые представляют собой одно или несколько раздельных физических пространств, объединенных в единое виртуальное адресное пространство.
На логическом уровне расположены структуры метаданных и блоки с данными пользователей. Данные, которые на логическом уровне расположены последовательно, могут физически находиться на разных блочных устройствах.
Структуры метаданных также можно условно разбить на множество уровней. При этом одни структуры будут более высокоуровневыми, и на самом верху окажется структура, представляющая собой сабвольюм.
Сабвольюмы — это корневые элементы файловой системы, образующие отдельный слой представления данных, который инкапсулирует работу низших слоев. Благодаря этому данные пользователей представляются в привычном виде директорий и файлов.
Верхний слой — файлы и директории, располагающиеся в сабвольюмах. Здесь содержатся данные в том виде, как они представлены для пользователя.
Сабвольюмы
Сабвольюмы (subvolumes) в файловой системе Btrfs — механизм, который позволяет создавать и управлять независимыми подразделами внутри одной файловой системы. Каждый сабвольюм ведет себя как отдельная файловая система с собственным деревом каталогов, метаданными и настройками доступа.
Вот несколько ключевых особенностей и преимуществ использования сабвольюмов в Btrfs:
1. Изоляция данных. Сабвольюмы позволяют изолировать и организовывать данные внутри одной файловой системы. Каждый сабвольюм может содержать свой собственный набор файлов и каталогов, что упрощает организацию и администрирование данных.
2. Гибкость. Сабвольюмы могут быть созданы и удалены без необходимости изменения размера или разбивки существующего раздела. Это позволяет удобно управлять разделением данных и их миграцией без необходимости изменения физической структуры диска.
3. Мгновенные снимки. Каждый сабвольюм может быть сохранен в виде мгновенного снимка (snapshot), предоставляя возможность создавать точки восстановления для отдельных частей данных и быстро возвращаться к предыдущим состояниям.
4. Квоты и настройки доступа. Сабвольюмы позволяют устанавливать индивидуальные квоты на дисковое пространство и настройки доступа для каждого подраздела внутри файловой системы. Это дает большую гибкость в управлении использованием ресурсов и защите данных.
5. Наследование свойств. Сабвольюмы могут наследовать свойства и настройки от верхнеуровневых сабвольюмов. Это позволяет определять общие правила доступа, сжатие или шифрование данных для всех подразделов, упрощая администрирование.
6. Масштабируемость. Btrfs поддерживает создание большого числа сабвольюмов внутри одной файловой системы, обеспечивая гибкость и возможность масштабирования данных.
7. Резервные копии. Сабвольюмы могут быть использованы для создания резервных копий, позволяя сохранить состояние данных на момент определенного мгновенного снимка. Это дает возможность быстрого и безопасного восстановления данных в случае ошибок или сбоев.
Снапшоты
Снапшот — это сабвольюм с расширенными свойствами. Вследствие этого его возможности отличаются от привычных.
Снапшот наследует все файлы и директории своего родителя, но вместо сабвольюма внутри снапшота будет пустая директория, без вложенных данных. Если будет нужен рекурсивный снапшот, решать эту задачу в BTRFS потребуется дополнительными средствами. Например, можно убрать отметку «только для чтения» при создании снапшота.
Если же снапшот был снят с флагом «только для чтения», то приведенный вариант не сработает. В этом случае нужно размещать снапшоты рядом с сабвольюмом и монтировать snapA внутрь снапшота snap0.
В любом случае рекурсивные снапшоты будут сняты в рамках разных операций в разное время.
Copy-on-write
Представим сабвольюм в файловой системе, в котором расположен файл. Далее с сабвольюма снимается снапшот. На файловой системе появится новый сабвольюм с содержимым, аналогичным исходному сабвольюму. Создание снапшота происходит почти мгновенно, данные самого файла не копируются. Вместо этого создаются дополнительные метаданные, и снапшот наравне с родительским сабвольюмом становится владельцем файла. Один файл на диске принадлежит одновременно сабвольюму и снапшоту. Изменение файла в сабвольюме не повлияет на файл в снапшоте.
В результате на диске будет храниться исходный файл плюс некоторая дельта, отличающая исходный файл от измененного. Если удалить один из сабвольюмов (оригинальный или снапшот), лишние данные будут вычищены с диска, а на диске останется только актуальная версия файла.
В BTRFS сабвольюмы применяются для высокоуровневого управления наборами данных:
для атомарного снятия снапшота со всех данных сабвольюма;
для поиска источника наследования;
для возвращения набора данных к более ранней версии.
Дерево файловой системы
Есть три типа организации структуры сабвольюмов: плоский, вложенный и смешанный.
Плоская структура предусматривает плоский список сабвольюмов в корневом сабвольюме. Например, отдельными сабвольюмами можно выделить корень файловой системы, пользовательскую директорию, директорию с сайтом и базу данных. Некоторые сабвольюмы для удобства можно размещать в директориях.
Все сабвольюмы необходимо замонтировать. Сабвольюм root должен иметь точку монтирования /, а внутри себя содержать директории home и var. После монтирования root в /home должен монтироваться сабвольюм home, а в /var/www и /var/database — сабвольюмы var/www и database соответственно. Таким образом, можно отобразить дерево btrfs-сабвольюмов в виртуальной файловой системе ОС.
Плюсы такого подхода в том, что пользователи видят только замонтированные сабвольюмы, а сами сабвольюмы легко заменяются и удаляются. При этом можно запутаться какой сабвольюм в какое место монтируется. Также к недостаткам относится то, что для каждого сабвольюма нужна запись в fstab, которую нужно обновлять при «откате» к снапшотам.
Вложенная структура предполагает простое использование сабвольюмов вместо некоторых директорий.
В этом случае кроме корневого сабвольюма монтировать больше ничего не требуется. Второе преимущество этого типа организации в том, что сабвольюмы видны, а их структура проста для восприятия. Минус в том, что при таком подходе не получится скрыть отдельные сабвольюмы от пользователей, а удаление или замена сабвольюма потребует дополнительных усилий из-за наличия вложений.
Смешанный подход представляет из себя комбинацию первых двух с использованием преимуществ обоих типов организации. Однако он может привести к созданию сложной запутанной структуры с огромным количеством записей в fstab.
Добавление/удаление диска, баланс
В BTRFS можно добавлять блочные устройства непосредственно в процессе работы файловой системы. Команда balance перераспределяет данные на дисках, уменьшая фрагментированность на уровне блоков данных, но не влияя на фрагментированность файлов. Например, при RAID1 баланс приведет к клонированию данных с первоначального устройства, при RAID0 — к более равномерному распределению данных по двум дискам. Благодаря этому данные более плотно записываются на диске и получается дефрагментация, правда, без учета логического содержимого. Команда balance просто перемещает блоки данных из одного места в другое. Также эта команда позволяет сменить профиль записи.
Фрагментация
Из-за сложной многоуровневой архитектуры и из-за того, что данные записываются всегда в новое расположение на диске, BTRFS подвержена фрагментации. Даже при простом чтении или частичном обновлении данных при записи они попадут в новую область на диске. Поэтому частые изменения приведут к сильной фрагментации файлов и увеличат распределение фрагментов по нескольким дискам. Нагрузка на CPU им расход памяти возрастет. Сильнее всего фрагментированности подвержены базы данных и образы виртуальных машин.
При некоторых операциях BTRFS самостоятельно перечитывает системные данные на блочных устройствах, чтобы найти все части файловой системы. Если в процессе поиска будет обнаружено два блочных устройства с одинаковыми UUID, система воспримет их как части одного и того же инстанса. Если эти два устройства окажутся оригиналом и клоном, это может привести к повреждению данных.
Эта статья поддерживается командой vStack
vStack — гиперконвергентная платформа для построения виртуальной инфраструктуры корпоративного уровня. Продукт входит в реестр российского ПО.
• Наш сайт
• Наш блог про Enterprise IT во всех его проявлениях
