company_banner

ZFS: архитектура, особенности и отличия от других файловых систем

    Frozen cells by arbebuk

    Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions. Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. Из выпуска и родилась эта статья, а вот тут можно послушать аудиоверсию.

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

    ZFS и ее отличия от других решений на примере Linux

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

    Любая файловая система — это абстракция для удобного хранения данных. Каждая файловая система разрабатывалась под определенные требования: сколько у нее будет дисков, какая система хранения под капотом и так далее. Например, семейство EXT — очень простая система, вдохновлённая UFS, XFS — система с упором на параллельный доступ, а ZFS стремится быть системой, включающей в себя всё нужное для создания больших локальных хранилищ, в частности это отражается и на удобстве эксплуатации.

    В Linux как де-факто стандарт используется менеджер логических томов (Logical Volume Manager, LVM), который также предлагает некоторые абстракции над нижележащим блочным устройством — можно создавать абстракции в виде Physical Volume, Logical Volume и так далее. По сути, можно делать то же самое, что с ZFS, но другими методами, добавив ещё кучу слоёв к LVM.

    Плюсы ZFS в том, что он знает, что и где лежит, группирует это и дает некоторые другие фишки, в частности безопасное хранение данных — эта файловая система сделана с упором на целостность. Сейчас это (на мой скромный взгляд) лучшее из опенсорсных кроссплатформенных предложений на рынке. Конечно, можно собрать хранилище и без ZFS, но это будет хуже по производительности, т. к. для достижения хотя бы отдалённого паритета по функциональности придётся использовать много слоёв (LVM, mdadm, dm-integrity, что-то для дедупликации и компрессии). К сожалению, каждый слой даёт немалое пенальти.

    Основы ZFS

    ZFS — это copy-on-write файловая система, она никогда не перезаписывает данные. Мы всегда оперируем новым блоком, для обеспечения консистентности данных не нужен журнал, как в большинстве других файловых систем.

    У баз данных типа MySQL и PostgreSQL есть так называемый WAL-лог. По умолчанию все данные пишутся в виде лога, потом записываются в блок данных на диске, получается двойная запись. При этом надо ждать, когда файловая система подтвердит, что данные на диске.

    Copy-on-write дает следующее преимущество: старые данные не меняются, можно не вести журнал и восстановить данные, записанные ранее. Мы не боимся повреждения данных, так как их нельзя повредить, новый вариант блока запишется в новое место, не затирая старый.

    Сам copy-on-write процесс не гарантирует консистентность данных, но если рассматривать ZFS, то в основе его работы лежит дерево Меркла, или Хэш-дерево. У ZFS всегда консистентное состояние за счет того, что он использует атомарные транзакции. Есть дерево блоков, для каждого из них с самого нижнего блока подсчитывается хеш-сумма и так доходит до самого верхнего блока. Хеш-сумма верхнего блока (uberblock) позволяет валидировать состояние всей файловой системы на момент транзакции.

    Визуализация дерева блоков. Источник: https://ritlug.com/talks/slides/2019-spring-w08-zfs.pdf
    Визуализация дерева блоков. Источник: https://ritlug.com/talks/slides/2019-spring-w08-zfs.pdf

    Однако из-за того, что copy-on-write система никогда не пишет в одно и то же место появляется проблема фрагментации данных. Также надо решать вопрос чтения и его эффективности. С SSD эта проблема по большей части решается, но она ощутима при работе на жестких дисках.

    ZFS, как и любой copy-on-write системе, нужно иметь на дисках запас свободного места, чтобы было куда записывать данные, которые всегда пишутся в новое место. К этому добавляется проблема порядка записи, следующие блоки одного файла будут записаны в другое место на диске, то есть в наличии непростая задача по эффективному аллоцированию данных. Однако и в классических файловых системах фрагментации можно избежать, только переалоцировав последовательно отрезок и работая только с ним. По факту мы так возвращаемся к прибиванию сущностей программы к конкретному диску, а это менее удобно (а любая ФС, как мы говорили раньше, стремится облегчить жизнь разработчику).

    Преимущества ZFS

    Давайте же поговорим о плюсах, зачем вообще стоит выбирать ZFS:

    Целостность и консистентность — ZFS сделан для максимальной надежности. По умолчанию на все данные подсчитываются контрольные суммы, а для метаданных записывается минимум по две копии в разных местах диска. Есть такой миф, что для ZFS нужна ЕСС-память, на самом деле — она нужна для любой файловой системы для исключения записи некорректных данных, просто в ZFS об этом честно говорят.

    Сжатие на лету. К примеру, используя алгоритм сжатия LZ4 система без проблем выдает 800 Мбайт в секунду на одно ядро на запись и до 4.5 Гбайт в секунду — на чтение. Соответственно, если мы говорим про многопоточную нагрузку, то при наличии свободного процессорного времени его можно эффективно утилизировать. В таком случае можно сэкономить не только место на диске, но и IOPS жесткого диска взамен ресурсов процессора за счет меньшего количества операций к диску. Есть интересные кейсы, к примеру использование MySQL, когда при этом под нами не очень дорогой SSD или простой HDD — тогда, включив LZ4, можно хорошо выиграть по многопоточной производительности, немного увеличив latency каждого потока.

    Атомарность. В ZFS все атомарно за счет того, что в основе лежит дерево Меркла. Если наша файловая система всегда атомарна, то можно отказаться от WAL-лога в приложениях, потому что целостность блоков гарантируется транзакционностью файловой системы. Тут есть нюансы: нужно уметь говорить с файловой системой на ее языке, манипулировать транзакциями. Отдельный вопрос, что эти логи некоторые базы данных используют для репликации. Но в целом — можно так экономить на ресурсах.

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

    «Бесплатные» снапшоты. Создание снапшота в ZFS по времени константно и не накладывает дополнительных расходов на работу с этими данными. Снапшоты удобно передавать, в том числе инкрементально, Те, кто пользуется бэкапами через Rsync или другие инструменты, сталкиваются с такой проблемой — нужно проверять, какая часть данных изменилась. А здесь можно отправить снапшот инкрементально, целостность будет проверена и подтверждена на другой стороне.

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

    Архитектура ZFS

    Посмотрим, как устроена ZFS изнутри. Есть набор дисков, над ним появляется абстракция в виде виртуального устройства (device). В терминологии ZFS — это Vdev, сокращение от virtual device. Есть разные реализации Vdev: Mirror (зеркало), который дублирует как есть информацию на два диска, RAID-Z, похожий по логике работы на классические RAID 5, 6 или 7. Также на подходе новый dRAID, о котором поговорим позже.

    Составные части пула. Источник: https://forums.lawrencesystems.com/t/freenas-zfs-pools-raidz-raidz2-raidz3-capacity-integrity-and-performance/3569
    Составные части пула. Источник: https://forums.lawrencesystems.com/t/freenas-zfs-pools-raidz-raidz2-raidz3-capacity-integrity-and-performance/3569

    Как конкретно мы храним и резервируем данные — с упором на производительность или на объём полезного пространства — это ответственность Vdev. Из набора Vdev’ов мы составляем общий пул. Если перевернуть на классическое понимание того же mdadm, чтобы собрать RAID 10, то есть набор мирроров, нужно сделать несколько Vdev Mirror и объединить их в один пул. Каждый Vdev — это, по сути, stripe, то есть отдельная виртуальная единица хранения. В рамках пула каждый уникальный блок данных будет храниться только на одном Vdev.

    Логически элементы ZFS делятся на 3 подсистемы:

    1. SPA (Storage Pool Allocator) — отвечает непосредственно за нарезку на диски, хранение данных на диске. Этот элемент отвечает за то, куда кладется конкретный блок данных, но с абстракцией от диска. Когда мы к нему обращаемся, то видим единое пространство, вне зависимости от набора конкретных Vdev’ов.

    2. DMU (Data Management Unit) — на этом уровне ZFS представляется обычным объектным хранилищем. Есть реализации, когда ее так и используют с некоторыми модификациями. К примеру, распределённая файловая система Lustre реализует свой слой поверх DMU ZFS.

    3. Следующий уровень DSL (Data and Snapshot Layer) пользуется этим объектным хранилищем. Этот компонент занимается непосредственно файловыми системами, снапшотами, то есть логикой, которая реализует POSIX-совместимую файловую систему (в него входит слой ZPL — ZFS POSIX layer).

    Сравнение интерфейсов классических ФС и ZFS. Источник: https://slideplayer.com/slide/11350106/
    Сравнение интерфейсов классических ФС и ZFS. Источник: https://slideplayer.com/slide/11350106/

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

    ARC (Adaptive Replacement Cache). Его разработали, чтобы решить проблему с чтением. ARC примечателен тем, что делает упор не только на трекинг тех объектов, что были использованы последними (LRU-cache), но и на трекинг частоиспользуемых объектов, которые он и кэширует (MFU-cache).

    У классического page cache Linux’а есть проблема вымывания: если прочесть файл, размер которого превышает объем оперативной памяти, то старые данные из кэша вымоются, так как по умолчанию файл будет загружен в page cache.

    ARC — это умная замена page cache. Когда создавался ZFS, часто использовали жесткие диски, а у них маленькие IOPS. Чтение copy-on-write данных — по умолчанию случайная операция, чтобы её ускорить, используют разные ухищрения, например, аккумулируют данные, записывают большим блоком и так далее, но эти оптимизации не всегда срабатывают. На этот случай нужно умное кеширование. Нормально, если при штатной работе 99% запросов чтения попадает в кэш, если меньше, значит, что-то не так, стоит добавить оперативной памяти.

    Если ARC не всегда полностью помещается в память, есть варианты вынести кэш на более быстрый отдельный SSD — это называется L2ARC (Layer 2 ARC).

    ZIL (ZFS intent log). Мы пишем данные в ZFS транзакциями, это набор дорогостоящих операций: подсчет хэш-сумм, построение дерева, запись метаданных, которые пишутся для безопасности несколько раз в разные места дисков. Поэтому мы стараемся набить каждую транзакцию максимальным количеством данных. Тут (сюрприз) появляется определенного вида журнал, без которого не обойтись, если нужна быстрая синхронная запись и критична задержка. Только здесь он вынесен как сущность, что позволяет использовать разные решения для персистентного хранения кусочка синхронной записи. Этот журнал обычно очень маленький, его записью и занимается ZIL (ZFS intent log).

    ARC и ZIL — хотя это и необязательные с технической стороны компоненты, но они нужны для обеспечения высокой производительности хранилища, без них система будет работать медленнее. ZFS в продакшене чаще применяют для крупных инсталляций хранилища данных. Архитектура подразумевает эффективную утилизацию большого количества HDD, SSD, RAM, CPU.

    Паттерны использования ZFS и типовые конфигурации

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

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

    2. Другой классический вариант — NFS-хранилище, там больше дисков, начинаем задумываться о синхронной записи, кэше и тут можно подставить дополнительные блоки в виде SSD.

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

    Блоки типа ARC, ZIL и так далее — это не диски, которые мы можем использовать, это понятия виртуальные, они всегда есть в ZFS. У нас есть возможность вынести их на более быстрые отдельные носители.

    ZIL можно вынести на так называемый Slog, которому не нужно быть большим, так как синхронная запись обычно идет мелким блоком и быстро сбрасывается на основное хранилище. То есть важно как можно быстрее записать конкретный блок данных и отрапортовать клиенту об успешной записи, а не записать как можно больше данных (привет, СУБД!). Slog нужен на чтение только при сбое питания.

    ARC можно дополнить одним или более SSD и выгружать на него определенный вид данных, например, кэшировать только метаданные или данные, которые последовательно или случайно прочитались с основного хранилища.

    Есть много вариаций настройки ZFS. Можно оптимизировать любой профиль нагрузки, начиная от размера блока, которым мы оперируем. Например, когда мы хотим оптимизировать copy-on-write, то можем писать бо́льшим блоком, чем в классических файловых системах, для ZFS по умолчанию принят объем в 128 КБайт на блок.

    Плюсы и минусы ZFS по сравнению с аппаратными решениями

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

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

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

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

    Датасет — отдельная файловая система в терминологии ZFS со своими настройками. К примеру, для СУБД можно создать отдельное пространство под основные данные с размером блока 8 Кбайт и отдельный датасет, оптимизированный под WAL-лог с размером блока 16 Кбайт. При этом все будет эффективно работать. Хочется сжимать одни данные — отлично, zfs set compression=on. Другие данные читаются очень редко и могут без надобности вымывать ARC — без проблем, zfs set primarycache=metadata.

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

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

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

    Особенности работы ZFS

    Фрагментация данных

    В copy-on-write системе постоянно появляются новые блоки, а старые не всегда пригодны к удалению. Часто возникают ситуации, когда старый блок не полностью записан, какие-то блоки не нужны, появились «дырки» (пустые пространства небольшого размера) и так далее.

    В ZFS пространство разрезано на так называемые metaslabs, которые ведут трекинг того, какие сектора свободны, а какие заняты. Это происходит на уровне SPA — слоя, который работает с дисками.

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

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

    По умолчанию на каждый Vdev создается ~200 meta-slabs. Если что-то изменилось, то надо метаданные по этим 200 meta-slabs записывать каждый раз для каждого Vdev. Сейчас это пишется постоянно на каждый Vdev, но уже перед релизом патч, который записывает информацию об изменениях в meta-slabs в виде лога на один из Vdev, а потом регулярно применяет этот лог. Это чем-то похоже на WAL-лог базы данных. Соответственно, уменьшается нагрузка на запись на диск информации о metaslabs.

    Конечно, при заполнении всего места возникает проблема, но на эту ситуацию любая copy-on-write файловая система (да и традиционная тоже) закладывает какой-то процент зарезервированного места для работы, без этого с динамической аллокацией никак.

    Запись данных

    По умолчанию чтение данных в ZFS практически всегда является случайным, но так как мы пишем каждый раз в новое место, то можем превращать случайную запись в практически последовательную. Если нужна система хранения под запись и редкое чтение, то любая copy-on-write система, в том числе ZFS, будет отличным решением. Данные пишутся группами транзакций (txg, сокращённое от transaction groups), можно агрегировать информацию в рамках этой группы.

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

    Если синхронная запись и ее целостность не важна, например, у вас не большая и дорогостоящая PostgreSQL, а сервер на одного пользователя, то синхронную запись можно отключить одной настройкой, она станет равняться асинхронной (zfs set sync=disabled).

    Таким образом, собрав пул из HDD, можно ими пользоваться как дешёвыми SSD с точки зрения IOPS. Сколько IOPS даст оперативная память, столько и будет. При этом целостность ZFS обеспечивает в любом случае — при потере питания произойдет откат на последнюю целую транзакцию и все будет хорошо. В худшем случае мы теряем последние несколько секунд записи, сколько у нас настроено в параметре txg_timeout, по умолчанию — это до 5 секунд, (до — т.к. ещё есть задаваемый лимит на размер буфера, при превышении данные запишутся раньше).

    Зависимость скорости работы ZFS от количества дисков

    Один блок данных всегда приходит на один Vdev. Если мы делим файл на небольшие блоки по 128 KB каждый, то такой блок будет на одном Vdev. Далее мы резервируем данные с помощью Mirror или как-то еще. Набив пул сотней Vdev, мы в один поток будем писать только на один из них.

    Если дать многопоточную нагрузку, например в 1 000 клиентов, то они могут использовать сразу много Vdev параллельно, нагрузка распределится. При добавлении дисков мы, конечно, не получим полностью линейного роста, но параллельная нагрузка эффективно размажется по Vdev’ам.

    Обработка запросов на запись

    Когда много Vdev и идут запросы на запись, то они распределяются, есть диспетчеризация и приоритезация запросов. Можно посмотреть, на какой Vdev идет нагрузка, каким блоком данных, с какой задержкой. Есть команда zpool iostat, у неё куча ключей для просмотра различной статистики.

    ZFS учитывает, какой Vdev был перегружен, где нагрузка меньше, где какая была задержка доступа к носителям. Если какой-то диск начинает умирать, у него высокая задержка, то система в итоге отреагирует на это, например выводом его из использования. Если мы используем Mirror, то ZFS пытается распределять нагрузку и параллельно считывать с обоих Vdev разные блоки.

    Как появились OpenZFS и ZFS on Linux и проблемы с версионированием

    ZFS изначально создана в Sun Microsystems для проприетарной операционной системы Solaris. Она появилась в качестве замены UFS, которая должна была покрыть любые надобности от файловой системы на долгое время (характерно само название ZFS — Zettabyte File System, намёк на недостижимые объёмы). После продукт стал распространяться с открытым кодом под лицензией CDDL и названием OpenSolaris. Затем Oracle купили Sun Microsystems, и проект перевели обратно в разряд проприетарных. До этого FreeBSD успел притянуть к себе код, были наработки у Apple, они даже встроили реализацию в штатную поставку, но отказались от нее, в конечном итоге внедрив свой аналог AFS. Тогда же появился форк, который превратился в OpenZFS. Сначала желающие работали на OpenSolaris, а потом создали OpenZFS, под которым собрали все усилия в рамках Illumos (форк OpenSolaris).

    Кстати, сейчас ZFS — одна из наиболее кроссплатформенных файловых систем, доступная почти на любой операционной системе (даже ведётся портирование под Windows).

    У ZFS on Linux другая история. В Ливерморской национальной лаборатории США в качестве распределённой файловой системы для суперкомпьютеров использовали Lustre FS. Ее особенность в том, что на каждой ноде под ней используется еще одна локальная файловая система Ldiskfs — это патченный Ext3, наработки которой послужили основой для Ext4. У Ldiskfs был ряд недостатков, и ZFS должен был заменить эту файловую систему, так и появился проект ZFS on Linux.

    В OpenZFS возникла проблема версионирования. Есть ZFS от Oracle и есть OpenZFS, последний не может повторять проприетарную версию, как и банально получать её исходный код. Изначально и у пула и у датасета в ZFS была версия, при обновлении Solaris можно было просто поднимать соответствующую версию. После обновления пул может не импортироваться в старом коде вообще или импортироваться в режиме только для чтения.

    На тот момент в проекте OpenZFS уже было много реализаций: FreeBSD, Linux, Solaris, Macos, нужно было связать все наработки. Для этого придумали feature flags, т. н. функциональные флаги. Например, взводишь флажок, что пул поддерживает LZ4 сжатие и в дальнейшем смотришь на него из кода — поддерживается/не поддерживается фича (т. е. можно ли импортировать пул).

    У каждого флага есть подпись — можно ли импортировать пул с ним в режиме только на чтение, так как многие вещи важны только при изменениях данных на носителях. Каждая реализация стала обрастать своими feature flags, и платформы переносили их между друг другом через backports.

    ZFS не включен в ядро Linux, а другие файловые системы в Linux идут из коробки, т.е. есть в ядре. Вопрос включения в ядро — проблема лицензии, это вопрос сложный. Однако есть отдельный модуль ядра, его можно без проблем обновлять вне зависимости от версии ядра.

    В Linux для этого есть два механизма:

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

    2. KMOD — модуль ядра приезжает из репозитория в бинарном виде, конкретная сборка совместима с определённой версией ABI ядра. Отсутствует риск проблем при сборке модуля, характерные для DKMS, но сопровождающие пакета с модулем должны оперативно предоставлять новые версии при появлении свежих ядер.

    Разница в том, что приедет из пакета: исходный код как в DKMS или сразу бинарный файл как в KMOD.

    Что нового в последних релизах

    В версии 0.8 появилось нативное шифрование. Есть американская компания Datto, которая занимается бэкапами данных и базируется на ZFS. Они предложили реализацию нативного шифрования.

    Ее плюс в том, что шифруются только данные и то, что связано с ними, а информация о датасетах и большая часть метаданных не шифруются. То есть информация на уровне DSL, о директориях и так далее, шифруется, а то, что ниже — DMU и SPA, нет. Что это дает? Можно зашифровать данные на стороне клиента и, не отдавая ключ, отправить их сначала полностью, потом регулярно обновлять инкрементально, принять на стороне сервера также инкрементально без расшифровки и проверить целостность.

    Если шифрование идет на низком уровне (к примеру, LUKS) и у нас большие объемы данных, то теряется информация о том, что там есть, нужно передавать все целиком, так как изменение одного байта меняет весь блок. Чтобы проверить целостность данных в этом случае, нужно их расшифровать — это дорого и долго.

    Еще одно обновление — это Special Allocation Class. Предположим, что есть большое количество медленных жестких дисков плюс используется реализация Vdev RAIDZ, особенность которого в том, что он не заточен на большие IOPS. Так обеспечивается целостность, он всегда атомарен (не страшна проблема потери массива при т. н. raid write hole), но у этого есть минусы в части производительности. Читать метаданные и мелкие блоки с RAIDZ дорого.

    Special Allocation Class — это специальный Vdev, куда пишутся метаданные или блоки данных меньше 4 килобайт (запись данных конфигурируется). Получается, что под большие блоки данных можно использовать медленное, но дешевое HDD-хранилище, а рядом поставить SSD-диски, хранящие его по блоки метаданных и блоки данных небольших размеров.

    Планы по развитию ZFS

    ZFS — файловая система, которая может работать с большинством операционных систем. Скоро появится полнофункциональная версия даже под MS Windows.

    В настоящий момент в планах на развитие идет упор на производительность, к примеру на оптимизацию для NVMe. Они дорогие, хочется выжать из них максимум. ARC в данном случае не даёт сильного выигрыша, так как это дополнительные операции по копированию данных в ОЗУ. Сейчас, если поставить 5 — 10 NVMe, мы быстро упремся в производительность ОЗУ и ЦПУ. Специально для этого случая ведутся работы по поддержке direct io с целью исключения лишних операций в ARC.

    Другие направления — больше удобства для конечных пользователей-частных лиц. При использовании ZFS дома есть проблема в том, что объем наращивается либо установкой нового Vdev, либо заменой всех дисков в Vdev на бо́льшие (ZFS видит, что диски увеличились и может использовать дополнительное пространство). То есть собрав один RAIDZ, мы не можем добавить к нему на ходу еще один диск. Уже в альфе патч, который позволяет это делать.

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

    Проблема в том, что жесткие диски, наращивая объем в 20 ТБ и более, не сильно наращивают производительность с точки зрения пропускной способности. У любого диска есть количество ошибок на каждый терабайт чтения, официально заявленное производителем (URE — unrecoverable read error rate). И любой RAID 5 и более с дисками больше 3 ТБ практически гарантированно развалится при пересборке, когда один диск вылетел и мы читаем с оставшихся. Риск ошибки чтения хотя бы одного не того байта с этих 3 ТБ каждого диска просто огромен (для «потребительских» HDD стандартом является одна ошибка чтения на каждые 1014 бит, т.е. на каждые ~11 ТиБ). Когда мы пересобираем RAIDZ, а это тот же RAID 5, 6 и так далее, есть та же проблема.

    Конечно, можно увеличить количество дисков, которое мы можем потерять: поставить RAIDZ 2, RAIDZ 3 — сколько копий будет хранится, но мы не решаем вопрос производительности восстановления. Новый диск, который мы меняем, по-прежнему является узким горлышком. Эти 15 — 20 ТБ будут восстанавливаться в лучшем случае со скоростью 200 МБ/сек (а в реалистичном — около 100 МБ/сек, а то и меньше). Несколько суток на восстановление одного диска — это очень долго.

    Пример расположения блоков на дисках, RAIDZ. Источник: https://itnext.io/backup-storage-for-thousands-of-virtual-machines-using-free-tools-b3909004bef2
    Пример расположения блоков на дисках, RAIDZ. Источник: https://itnext.io/backup-storage-for-thousands-of-virtual-machines-using-free-tools-b3909004bef2

    dRAID решает проблему одновременного восстановления данных на большом количестве дисков. Вместо того чтобы работать в рамках «один диск — одна единица», мы как бы нарезаем каждый диск на мелкие сущности по количеству дисков. Так, если в dRAID 50 дисков, то каждый из них будет разделен на ~50 областей. Некоторые из этих областей будут зарезервированы как свободные (spare) области, на которые можно восстановиться.

    Пример расположения блоков на дисках, dRAID. Источник: https://itnext.io/backup-storage-for-thousands-of-virtual-machines-using-free-tools-b3909004bef2
    Пример расположения блоков на дисках, dRAID. Источник: https://itnext.io/backup-storage-for-thousands-of-virtual-machines-using-free-tools-b3909004bef2

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

    Например, мы собрали dRAID, аналогичный RAIDZ2 с одним spare диском, который позволяет вылететь двум дискам, один вылетел, осталось девять. Пока мы не вставили новый диск, размазываем данные на пустое зарезервированное пространство других дисков в группе. И так восстанавливаем ситуацию: дисков по-прежнему девять, но вылететь может уже два, а не один, ведь блоки с вылетевшего диска уже разъехались по уцелевшим оставшимся. Таким образом снимается проблема узкого горлышка в виде производительности spare диска, технически он теперь размазан на другие диски массива.

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

    Послесловие

    В связи с тем, что ZFS пережил существование в разных компаниях и ОС, идёт активная централизация кода и документаций в проекте OpenZFS. Приглашаю желающих к созданию единой документации по проекту, буду рад вашим PR!

    Полезные ссылки:

    Также, как я уже говорил, в основном блочном и объектном хранилище Mail.ru Cloud Solutions, которое разрабатывают коллеги в моей команде, хранение устроено по-другому, об объектном хранилище недавно подробно рассказал наш архитектор Монс Андерсон: Архитектура S3. 3 года эволюции Mail.ru Cloud Storage.

    Коллеги пишут про хранение данных:

    1. Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions.

    2. Больше чем Ceph: блочное хранилище облака MCS.

    3. Наш Телеграм-канал с новостями об обновлениях S3-хранилища и других продуктов.

    P.S. Наш проект ищет разработчиков на Go в команду Identity Access Management. Из интересного — разработка на open source, highload, Kubernetes, распределенные системы. А полный список наших вакансий — здесь.

    Mail.ru Group
    Строим Интернет

    Комментарии 65

      0
      Подскажите, Георгий. Учитывая текущее состояние разработки ZFS, для каких сценариев использования Вы бы рекомендовали ZFS. Или же пока лучше использовать в режиме Бета-теста?

      Для исключения нарушения целостности ZFS достаточно ли синхронной записи или же обязательно наличие ИБП?
        +1

        Я не Георгий, но отвечу. Целостность ZFS обеспечивает за счёт СoW + атомарные транзакции. Поэтому на диске данные всегда находятся в консистентном состоянии. ИБП и синхронные записи лишь спасают от потери данных в ОЗУ, которых можеть быть очень много.

          +1
          Подскажите, Георгий. Учитывая текущее состояние разработки ZFS, для каких сценариев использования Вы бы рекомендовали ZFS. Или же пока лучше использовать в режиме Бета-теста?

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

          Классические сценарии использования:
          — локальная ФС (к примеру, я использую её как корневую ФС на всех своих инсталляциях)
          — локальное файловое/блочное хранилище для масштабов, где сетевые ФС, такие как ceph, излишни (хороший пример — proxmox)
          — Posix-совместимое локальное файловое хранилище, отлично подходит для классических хранилок на большое количество дисков

          Для исключения нарушения целостности ZFS достаточно ли синхронной записи или же обязательно наличие ИБП?

          ZFS на уровне файловой системы всегда обеспечивает целостность за счёт использования merkle tree и атомарности, т.е. даже отключив синхронную запись на датасете через sync=disabled, ФС после сбоя по питанию останется целой. Но это приведёт к откату на последнюю корректно записанную транзакцию.
          0
          Размениваться на скорость параллельной записи, против latency — такое себе. Не говоря уже про заявления о том что на ZFS не нужен WAL.
            0
            Размениваться на скорость параллельной записи, против latency — такое себе.

            Для требовательных к write latency нагрузок нужно использовать Slog.

            Не говоря уже про заявления о том что на ZFS не нужен WAL.

            С точки зрения целостности он и правда не нужен, если правильно настроить размер блока записи и делать сброс данных на диск в нужный момент. Другой вопрос, что WAL в БД может использоваться, к примеру, и для репликации на другие инстансы. Этот момент я тоже в статье попытался рассказать.
              0
              А так же бэкап, point in time recovery…
                0
                Ну, во-первых, это доп. функционал, который обеспечивает WAL, тут я ещё раз соглашусь.

                А в рамках контекста статьи именно бэкап, point in time recovery в zfs иногда можно обеспечить за счёт снапшотов.

                Т.е. я не хотел сказать, что WAL теперь вообще не нужен :) А что задачу целостности данных с него ZFS может забрать (как и некоторые другие).
                  0
                  point in time recovery невозможно обеспечить через снапшоты, так как нельзя заранее знать, на какой момент придется откатывать.
                  Сама целостность данных, в отрыве от ACID (в базах данных), мало интересна. Файловая система оперирует несколько другим набором данных, чем база данных.
            0

            Но есть интересные альтернативы.
            Например, bcachefs и btrfs.
            Или они обладают каким-то недостатком?

              0
              Я бы сказал, что у каждого решения своя специфика и нюансы.

              Про тот же btrfs, хотя его автор и признавал, что вдохновлялся и ZFS (хоть и не сразу), но по архитектуре они весьма отличаются, плюс отличается также и логика управления массивом.

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

              А вообще это тема для отдельного цикла статей :)
                0

                В статье сравнивают "яблоки и лимоны". Ведь и то и то фрукты…
                А мне хотелось бы сравнение с современными аналогами.
                Ну и если кто-то утверждает, что какая-то fs ненадежна:


                1. Нужно описание, как повторить этот fail
                2. Понимание, почему это (ещё) не исправлено или не будет исправлено (никогда)
                  Просто для ошибок есть везде. Далеко ходить не надо, даже ecc не всесилен
                0
                В отличии от bcachefs и btrfs у zfs очень давняя, и что не менее важно, очень положительная история, начиная еще с SUN
                bcachefs — сам видел мертвяка систему из-за мертвого ssd кэша
                btrfs — были статьи на habr с детальным разбором и приходом к выводу что она не для продакшена, очень много экспериментов без финальной точки в ней
                  0
                  bcachefs — сам видел мертвяка систему из-за мертвого ssd кэша

                  вы, наверное, про bcache, а не про bcachefs.


                  ну и потеря данных из-за смерти накопителя выглядит как проблема не fs, а настраивавшего её админа, «ежу же понятно», что при wb кэше и выходе кэширующего накопителя из строя данные будут потеряны, поэтому нужно использовать избыточность (например, зеркало из двух ssd).

                0

                С мелкими файлами все очень плохо в zfs.
                Особенно при копировании каталога с огромным количеством мелких файлов. Zfs выдаёт список файлов в копирующую программу в каком то странном порядке, который вообще никогда не бывает оптимальным для чтения.
                И чем шире рейд, тем хуже скорость чтения. Иначе говоря скорость чтения мелких файлов в массиве дисков zfs бывает даже хуже одиночного диска на каком нибудь extfs. И в ZoL она хуже чем в фришной zfs.

                  +1
                  Если у вас есть порядок воспроизведения данных проблем при большом количестве файлов с ZFS — будем рады данной информации, по возможности пришлите в issue tracker github.com/openzfs/zfs/issues, спасибо! На явные деградации в производительности сейчас уделяется большое внимание.

                    0

                    сейчас проверил на raidz2 из 8+2 hdd, tar -c xxx | pv > /dev/null 50к файлов общим размером 3.5ГБ выполнялось 7 минут. это медленно или нет?

                      +1

                      8.5 мегов в секунду на 10 дисках. Куда уж медленнее. Сравните с одиночным диском на ext4 или xfs

                        0

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

                          0

                          Ну кто вам мешает протестировать по другому. И сравнить с другими фс.
                          Попробуйте добиться столь низкой скорости на ext4, ntfs, btrfs.

                            0

                            нашёл старый сервер, где когда-то работал squid, запустил tar -c xxx | pv > /dev/null, 6.7МБ/с, примерно 135 файлов в секунду. цифры одного порядка.
                            xfs, hdd 7200 rpm.

                              0
                              Чисто по приколу. 1.47GiB 0:04:04 [6.15MiB/s], в WSL на NTFS при числе файлов в 184 тысячи.
                            0

                            Ну я тестил не таром, а своей прогой, в том числе и вмногопоточном режиме.
                            Да и тару 8 дисков данных должны бы помочь, если файлы у вас более 8*2^ashift байт

                      0
                      Георгий, а эта таблица все еще актуальна? Все еще имеет смысл выбирать sector size и record size?

                      docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-Dc4ZcwUdt6fkCjpnXxAEFlyA/edit#gid=1418963574
                        +2
                        Про конкретно эту таблицу не скажу, а для расчёта эффективной утилизации пространства в RAIDZ актуальна аналогичная таблица из статьи www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz, если вы спрашиваете в этом контексте. Надо будет мне добавить эту табличку в документацию.
                          0
                          Точно, хотел на нее сослаться, а загуглил-то другую. Эта таблица еще более медитативная.

                          Нет ли серебряной пули? Вроде если ashift=12, а block size = 128kb (32 по этой таблице?) или 1Mb (256 по этой таблице?), то все у вас будет хорошо.
                            0
                            Т.н. rule of thumb тут выглядит по другому — использовать raidz только для блоков размером не менее, к примеру, 32К. Для сглаживания этой проблемы реализовали special allocation class, на миррор из ссд можно вынести все мелкие блоки, (и метадату, и, при желании, все блоки с recordsize меньше определённого размера).

                            Т.е. можно собрать пул на raidz со special vdev, оставить дефолтный recordsize=128k, выставить special_small_blocks=32K, и все маленькие файлы или файлы с мелким блоком (recordsize до 32К) будут эффективно записываться на ssd mirror, а большие файлы — на raidz hdd.

                            В целом можно сказать, что raidz стоит использовать в основном для эффективного хранения данных с большим размером блока. В остальных случаях нужно считать оверхед по iops/используемому пространству.
                              0

                              А вот как бы решить задачу наоборот — все хранить на ssd/nvme и только файлы больше мегабайта писать на медленные диски?

                                0
                                Нужно выставить special_small_blocks=1M
                                  0

                                  Я долго читал документацию и у меня не возникло понимания — с точки зрения внутренностей основными дисками при этом будут большие медленные диски? Т.е. если умрут они то вообще все потеряно, а если умрут special vdev то только они, или как?


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


                                  И с точки зрения свободного места непонятно — если закончилось место на одном из девайсов — будет писаться на второй? Это работает в обе стороны?

                                    0
                                    Special vdev в первую очередь является самым обычным vdev, только с определёнными приоритетами на запись. Все vdevs в пуле равны по критичности потери. Однако, если special vdev использовался с самого начала, то при его потере даже используя механизмы, позволяющие импортировать пул без одного vdev ( openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-max-missing-tvds ) смысла в этом будет мало, т.к. все метаданные будут потеряны (хотя тут стоит протестировать объём доступного к восстановлению, у меня не доходили руки).

                                    Если вы хотите разделять данные по степени отказоустойчивости, то сейчас штатно это делается только через создание разных пулов.
                                      +1

                                      Было бы полезно все-таки скидывать содержимое special на обычные vdev в простое, все-таки special не для расширения пула создают, а для производительности и обеспечивать на тем тот же уровень избыточности не всегда хочется. И оценивать надёжность ссд по сравнению с хдд тоже.
                                      Например у меня были случае, когда ссд от special выкидывало на автотриме. Т. Е даже при одинаковом уровне избыточности special из ссд может стать точкой отказа и убить весь пул.

                                        0
                                        Было бы полезно все-таки скидывать содержимое special на обычные vdev в простое, все-таки special не для расширения пула создают, а для производительности

                                        Хранение мелких блоков эффективнее на mirror, чем на raidz, special vdev создавался в первую очередь для эффективного и производительного хранения мелких блоков в пулах с raidz/draid. Плюс не стоит забывать, что в настоящий момент в ZFS нет механизма автоматической модификации данных без явной перезаписи (т.н. block pointer rewrite), т.е. схемы «сделать что-то потом с данными» в ZFS сейчас в принципе нет.

                                        Да и у схем с «скидывать в простое» тоже есть свои минусы, это доп. нагрузка, тоже не универсальная штука. Ну и резервировать такие диски тоже нужно, смысл от пула, часть данных которого потеряна на «промежуточном» этапе.

                                        Например у меня были случае, когда ссд от special выкидывало на автотриме. Т. Е даже при одинаковом уровне избыточности special из ссд может стать точкой отказа и убить весь пул.

                                        Если был отказ дисков, то тут мало что поможет. Схема с «скидывать в простое» привела бы к такому же итогу, вы не можете уменьшать избыточность, не увеличивая риск отказа (касаемо каких-либо буферов на запись). Схема с slog работает только по причине того, что эти же данные сразу приедут на vdevs в виде асинхронной записи. И то, если данные важны, то slog тоже нужно резервировать.

                                        Данные в какой-то момент всё равно должны быть записаны с резервированием, если вы не хотите гарантировать отказоустойчивость special vdev, то ваша идея отличается от классического использования slog только моментом сброса на hdd vdevs данных.

                                        А для кеша на чтение уже сделали персистентный l2arc.
                                          0
                                          Хранение мелких блоков эффективнее на mirror, чем на raidz

                                          разве? ЕМНИП raidz1 даёт в худшем удвоение занимаемого места, ну так зеркало делает это всегда.
                                          или вы про raidz2? ну так его с triple mirroring надо сравнивать.

                                    0
                                    Нужно выставить special_small_blocks=1M

                                    а оно разве не после сжатия считается? (я предполагаю, что с этой настройкой все более-менее сжимаемые файлы «уедут» на special vdev)

                          0
                          Планирую собрать подкроватный сервер для бэкапов, по большей части с помощью Proxmox Backup Server. Купил два HDD по 4Гб для зеркалирования. Стоит ли их форматировать в ZFS?
                            0
                            Моё субъективное мнение — да, ZFS прекрасно подходит для нужд холодного хранения данных. В частности, продукты ProxMox отлично интегрированы с ним и имеют хорошую документацию на этот счёт pbs.proxmox.com/docs/sysadmin.html
                              0
                              Советую еще посмотреть TrueNas core (бывший Freenas), эта ОС тоже отлично подойдет для хранения ZFS реплик и может полностью забрать на себя вопросы создания снимков на удаленных хостах и их репликацию по расписанию.

                              Тулинг для реплик в последней версии обновили. Там можно настроить все мыслимые опции,
                              * можно задать реплику дерева датасетов, но исключить конкретные узлы.
                              * можно использовать реплицировать ТОЛЬКО уже имеющиеся на проде снимки, либо делать снимки по расписанию и сразу их реплицировать.
                              * можно автоматизировать удаление старых (сделанных утилитой) снимков на проде, а на сервере бэкапов их оставить.
                              * можно делать бэкап с удаленного сервера на удаленный сервер, с удаленного сервера на на локальный, или с локального на удаленный. Главное чтобы был доступ по SSH и ZFS. Бэкап с Proxmox на локальный пул Freenas работает.
                              * можно добавить создание закладок ZFS на проде для снимков, которые используются для реплик, чтобы если вдруг на боевом сервере почистят снимки и удалят последний релицированный снимок, все равно можно было бы продолжить репликацию. Иначе пришлось бы создавать новую резервную копию
                              * можно настроить уведомления на почту, в случае проблем с заданиями репликации
                                –1
                                А я недаdно поимел ноут с зфс на ссд и Ubuntu18. Уж не знаю, что там делал юзер, но кроме партишна зфс на диске больше ничего не осталось. Прочитать структуру не удалось ничем.
                                Нашел несколько прог под винду для восстановления и поиска данных. Есть очень неплохие, но за деньги и немалые. Смог слить некоторое кол-во фоток и то часть повреждены. Так что пришел к выводу — лучше ext4+mdadm+LVm и не жужу!
                                  0
                                  TrueNAS | XigmaNAS | OpenMediaVault + флешка для системы

                                  1-ые две — freebsd, последняя — linux.
                                  Все три умеют жить на флешке.
                                  Зы. TrueNAS — крут, но монстр по потреблению ресурсов.
                                  +1

                                  Ну и сегодня вышел релиз 2.0. На мой взгляд, замечательное событие, во многом потому, что наконец-то удалось объединить разработчиков разных ОС для работы над единым проектом.
                                  Ждём полноценной поддержки в Win и Mac OS X))

                                    0
                                    Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions.

                                    Хотя в продакшене нашего подразделения мы и не используем ZFS


                                    И сразу противоречие! И оно как то незримо фоном идет во всех статьях про эту ФС. Прокомментируйте, почему так сложилось хотя бы у Вас.

                                    зы вообще столкнулся с тем, что нет стабильной ФС со сжатием под линь. А надо: очень экономит место на небольших VDS.
                                    ззы вечные беты btrfs, reiser4(5), zfs не предлагать!
                                      +1
                                      И сразу противоречие! И оно как то незримо фоном идет во всех статьях про эту ФС. Прокомментируйте, почему так сложилось хотя бы у Вас.

                                      Под каждую задачу свой инструмент, идеального решения нет. В статье я указал только ситуацию в конкретном подразделении конкретной компании, и то в рамках дозволенного к оглашению :). Если говорить только обо мне, то за рамками остались остальные личные/рабочие инсталляции с ZFS, которые здравствуют и бесшовно обновляются уже который год, переживая сбои и некорректную работу дисков, ОЗУ, ЦПУ, блоков питания и т.д.
                                      Это я ещё не перечислил продукты других компаний с ZFS, существующие не первый год.

                                      зы вообще столкнулся с тем, что нет стабильной ФС со сжатием под линь. А надо: очень экономит место на небольших VDS.
                                      ззы вечные беты btrfs, reiser4(5), zfs не предлагать!

                                      Критерий стабильности каждый определяет для себя сам, как и выбор инструмента для конкретных задач.
                                        0
                                        файловой может и нет, а вот Red Hat в 8 версии для сжатия предлагает использовать Stratis с XFS. Именно в его пользу они отказались от btrfs.
                                          +1
                                          не пойму — почему RH не любит ext4. Все его на xfs тянет…
                                            0
                                            у него есть свои плюсы, как минимум inod-ы динамические и амплификация записи меньше чем у extN.
                                            0

                                            Это конечно сугубо моё личное ощущение, но этот Stratis — очередная попытка RedHat запилить вендорлок. Я просто не могу воспринять это творение в сравнении с ZFS или BTRFS. Сама архитектура вызывает отвращение https://www.opennet.ru/opennews/art.shtml?num=51828


                                            btrfs вполне можно развивать, и она будет не хуже ZFS.

                                              0
                                              Надо понимать, что RedHat продает поддержку на это. И в случае проблем, понятно куда обращаться. А вот что делать с zfs, btrfs — не понятно… разве что читать код и править.
                                                0

                                                Тут, да. С поддержкой не всё так просто.
                                                BTRFS, ну вроде как есть поддержка от Oracle Linux, SLES.
                                                ZFS, та что проприетарная старая — Oracle + Solaris.
                                                OpenZFS, тут только от вендоров конкретных продуктов.


                                                В случае RedHat. Это просто технически сложно добиться тех же результатов с помощью EXT4|XFS + lvm. Пока невозможно сделать столь же эффективные снапшоты на блочном уровне. Так же как и сжатие, шифрование датасетов и т. д.

                                                  0
                                                  У меня пока по восьмерке rhel каша в голове, там с файловыми накрутили что-то слишком сложное — Stratis для снапшотов и тонких томов, VDO для сжатия и дедуплакации… И это при живом LVM, да еще и поверх него… Через пару лет авось определятся в технологиями.
                                                  PS: путаюсь между VDO и Stratis, исправил.
                                              0
                                              извиняюсь, VDO а не Stratis…
                                              0

                                              Ну например у нас ZFS уже много лет в проде.


                                              И оно как то незримо фоном идет во всех статьях про эту ФС

                                              Это потому, что ZFS кардинально отличается от классических ФС, типа ext4, XFS. Чтобы её эксплуатировать нормально, нужны хотя бы минимальные знания о том как она работает. Это не говоря, о просто администрировании — там талмуд на сотни страниц. Можете поглядеть документацию от Oracle. Поэтому сложно её рекомендовать как ФС по-дефолту. В Linux дополнительно накладываются проблемы с лицензией, поэтому различные дистрибутивы не предлагают её по-умолчанию.


                                              C VDS многие хостеры вообще ненавидят ZFS, т.к. она может сходу выжрать/разметить весь диск.

                                                0
                                                Чтобы её эксплуатировать нормально, нужны хотя бы минимальные знания о том как она работает.

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

                                                  Для домашних систем мне сложно что-то посоветовать, т.к. я буду предвзят. Я как разработчик имею дело с ZFS на работе. Естественно, что у меня она стоит и на домашней системе. Но я и по полной эксплуатирую её фишки: снапшоты, boot environment, сжатие для отдельных датасетов с исходниками, backup с помощью send/receive. Плюс у меня два диска в зеркале, что тоже проще чем подпрыгивание с mdadm и т. д.


                                                  В целом для домашних систем по-дефолту я бы её не советовал, хотя бы из-за жора памяти. EXT4 и классические ФС вполне справляются с 90% задач обычных пользователей. Но если вам действительно нужны фишки ZFS, то да, стоит её ставить. и не мучать себя альтернативами типа ext4 + lvm, mdadm и т. д.

                                                  0
                                                  Чтобы её эксплуатировать нормально, нужны хотя бы минимальные знания о том как она работает.

                                                  В общем случае, ничего не нужно. Опыт FreeBSD где ZFS уже второй десяток лет в эксплуатации, в том числе и много лет как файловая система по умолчанию тому подтверждением.

                                                    0
                                                    В общем случае, ничего не нужно.

                                                    Таки нужно, и тут как минимум два момента (как раз по некоторому опыту эксплуатации под FreeBSD):


                                                    1. Никогда не заполнять файловую систему более чем на 98%! Лучше — останавливать раньше. По границе 98-99% её может тупо парализовывать внутренней вознёй по сборке/очистке.


                                                    2. Выделять оперативную память и настраивать размеры под неё без всякой экономии.



                                                    Первый пункт особенно неудобен тем, что выжирание может наступить непредсказуемо. Я не знаю, ввели ли сейчас какой-то защитный резерв (как у классической UFS доля рута), но без него управление начинает требовать плохих мер.
                                                    Reservation property — это оно? Если да, это надо было бы вводить в каждой инструкции, но в большинстве howto это игнорируют.

                                                      0

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

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

                                                  да, массив будет гораздо меньшее время в degraded state, но ИМХО в случае raidz2 (и тем более z3) это не так уж важно, зато общее время ребилда («всё тормозит») увеличится.


                                                  Особенности работы ZFS

                                                  ох, если смотреть на raidz, то тут много всего.


                                                  1. в raidz нельзя добавить диск.
                                                    есть у вас, например, vdev из 8+2 дисков, нужно расширить ещё на пару дисков, единственный вариант — создать рядом ещё один vdev на 2+2 накопителя и включить его в тот же пул (разумеется, никто не будет так делать, придётся собирать рядом «на вырост» ещё один vdev на 8+2).
                                                    да, draid, как я понял, тоже будет обладать этой «особенностью»: возможность расширения планируется, но если мы составили массив со схемой 8+2, то добавить в него можно будет только 10 накопителей сразу.
                                                    в сравнении с ceph, например, который позволяет не только вводить-выводить накопители хоть по одному, но и делать массив из накопителей разного размера, это выглядит ужасным анахронизмом (я понимаю, что ceph про другое, но пример показывает, что задача «создать расширяемый пул из кучи накопителей» решаема);
                                                  2. raidz генерирует жуткую мультипликацию операций ввода-вывода.
                                                    поясню: в случае классических raid вы можете установить большой размер блока (например, несколько мегабайт), и операция последовательного чтения мегабайта с большой вероятностью затронет один диск.
                                                    в случае raidz же максимальный рекомендуемый размер записи — 1 мегабайт, чтение одного мегабайта затронет все диски в vdev (ну разве что диски с избыточностью не будут читаться). и то, что zfs знает о файлах, играет тут против наc: даже если файл меньше мегабайта, но занимает несколько секторов, то он будет-таки «размазан» по всем дискам.
                                                    в отношении больших файлов проблему бы решили гигантские recordsize (десятки мегабайт), они заодно существенно улучшили бы степень сжатия для zstd, но максимальный рекомендуемый размер, повторюсь, — 1Мб;
                                                  3. фича «special vdev» очень крута, конечно, но есть впечатление, что дизайнили второпях.
                                                    нельзя реализовать многоуровневое хранилище, например, метаданные мы храним на зеркале ssd, мелкие блоки на тройном зеркале hdd, а крупные — в raidz2 на hdd. это бы во многом решило проблемы предыдущего пункта с мелкими файлами (хранить их все на ssd всё-таки накладно).
                                                    да, кстати, интеграцию special vdev с l2arc тоже так и не сделали, печаль (нельзя объяснить zfs, что метаданные у нас уже на ssd, и поэтому создавать их копию на кэширующем ssd бессмысленно).

                                                  но при всём этом я считаю, что лучше zfs для долговременного хранения данных пока ничего не придумано. вот только вот вывел из массива два годовалых 16Тб диска, на обоих zfs пачками показывала ошибки контрольных сумм, притом как минимум на одном из них это произошло до того, как посыпались дисковые ошибки. с любыми другими файловыми системами я бы практически гарантированно получил silent data corruption (ну или не silent, если есть чексуммы на уровне fs, но всё равно данные были бы утеряны), тут же zfs известила ошибках и исправила их.

                                                    +1
                                                    да, массив будет гораздо меньшее время в degraded state, но ИМХО в случае raidz2 (и тем более z3) это не так уж важно, зато общее время ребилда («всё тормозит») увеличится.

                                                    Когда в пуле больше 100 дисков, то сокращение времени в degraded state всё же критично.

                                                    в raidz нельзя добавить диск.

                                                    Сейчас — да, но в скором времени будет можно github.com/openzfs/zfs/pull/8853

                                                    в случае raidz же максимальный рекомендуемый размер записи — 1 мегабайт

                                                    Можно задавать размер блока до 16М, увеличив параметр модуля zfs_max_recordsize. Оно прекрасно работает (проверено не раз лично), но только для соответствующего профиля, т.к. операции с таким размером блока сильно уменьшают iops (относится и к обычному raid).

                                                    фича «special vdev» очень крута, конечно, но есть впечатление, что дизайнили второпях.
                                                    нельзя реализовать многоуровневое хранилище,

                                                    В момент разработки данного функционала у vdevs не было своих свойств (properties). Как они будут реализованы — на их основе можно будет сделать такую приоритизацию.
                                                      0
                                                      Когда в пуле больше 100 дисков, то сокращение времени в degraded state всё же критично.

                                                      массив из 100 дисков будет не на одном vdev же (если мы говорим про обычный raidz), так что ИМХО число дисков тут роли не играет.


                                                      Можно задавать размер блока до 16М, увеличив параметр модуля zfs_max_recordsize. Оно прекрасно работает (проверено не раз лично), но только для соответствующего профиля, т.к. операции с таким размером блока сильно уменьшают iops (относится и к обычному raid).

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


                                                      В момент разработки данного функционала у vdevs не было своих свойств (properties).

                                                      вот оно что, слона-то я и не приметил.

                                                    0
                                                    Спасибо за хороший материал
                                                    Подскажите — 2 вопроса по github.com/openzfs/zfs/releases/tag/zfs-2.0.0
                                                    1) Added fallocate(mode-0/2) compatibility to preallocate space. #10408
                                                    Что это? Как я понимаю, preallocation в принципе в CoW не возможен — не прав? И на примере — пусть Transmission пишет файл, кусками в случайном порядке. На не CoW ФС preallocation как раз эту проблему и решает. А как у нас теперь?

                                                    2) Redacted zfs send/receive
                                                    Что значит subsets? Выбранные папки с подпапками? Выбранные типы данных? Иное?
                                                    Лучше всего, конечно, взглянуть на синтаксис того, как это подмножество задавать

                                                      +1
                                                      Что это? Как я понимаю, preallocation в принципе в CoW не возможен — не прав? И на примере — пусть Transmission пишет файл, кусками в случайном порядке. На не CoW ФС preallocation как раз эту проблему и решает. А как у нас теперь?

                                                      Подробности описаны в PR github.com/openzfs/zfs/pull/10408, поддержка preallocation на ZFS не пишет блоки на диск, но проверяет, что места на пуле для записи файла данного размера хватит.
                                                      Основная причина реализации таких вещей — приложения при отсутствии возможности воспользоваться preallocation могут попытаться выполнить бессмысленную на CoW FS работу, например писать превентивно нули, что бессмысленно.

                                                      2) Redacted zfs send/receive

                                                      Тут стоит посмотреть на примеры и описание из man openzfs.github.io/openzfs-docs/man/8/zfs-redact.8.html
                                                      Кратко по памяти — создаётся клон от нужного снапшота, в нём чистится sensitive информация, и итоговый send поток заменяет соответствующие блоки на пометку REDACT. На принимающей стороне из такого неполноценного снапшота можно создать рабочий клон.
                                                      0
                                                      Спасибо. Помог разобраться man по zfs redact
                                                        0
                                                        Большое спасибо за статью.
                                                        Активно пользуем zfs в проде — proxmox ve, proxmox backup server, xigmanas (ex. nas4free).

                                                        Зы. Proxmox VE + zfs — всеяден (дебиан же). Работает на старых HP g5,g6,g7 etc, к-ые бюджетно модернизировали, добавив nvm-диски через переходники в pci-e x16. Переходник Orient C299E есть в продаже или на али.

                                                        Зы2. Enable IT mode on HP Smart Array P410i RAID card on HP DL380 Gen7 servers medium.com/@terryjx/enable-it-mode-on-hp-smart-array-p410i-raid-card-on-hp-dl380-gen7-servers-4e827eeb78ca Только trim после перепрошивки уметь не будет, но это некритично для обычных hdd.

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

                                                        Самое читаемое