Комментарии 65
Для исключения нарушения целостности ZFS достаточно ли синхронной записи или же обязательно наличие ИБП?
Я не Георгий, но отвечу. Целостность ZFS обеспечивает за счёт СoW + атомарные транзакции. Поэтому на диске данные всегда находятся в консистентном состоянии. ИБП и синхронные записи лишь спасают от потери данных в ОЗУ, которых можеть быть очень много.
Подскажите, Георгий. Учитывая текущее состояние разработки ZFS, для каких сценариев использования Вы бы рекомендовали ZFS. Или же пока лучше использовать в режиме Бета-теста?
OpenZFS является стабильным продуктом, особенно с учётом его упора на отказоустойчивость. В режиме бета-теста стоит использовать только альфа-релизы, стабильные версии можно смело использовать везде. Конечно же, это не отменяет надобности делать бекапы, как и на любой ФС.
Классические сценарии использования:
— локальная ФС (к примеру, я использую её как корневую ФС на всех своих инсталляциях)
— локальное файловое/блочное хранилище для масштабов, где сетевые ФС, такие как ceph, излишни (хороший пример — proxmox)
— Posix-совместимое локальное файловое хранилище, отлично подходит для классических хранилок на большое количество дисков
Для исключения нарушения целостности ZFS достаточно ли синхронной записи или же обязательно наличие ИБП?
ZFS на уровне файловой системы всегда обеспечивает целостность за счёт использования merkle tree и атомарности, т.е. даже отключив синхронную запись на датасете через
sync=disabled, ФС после сбоя по питанию останется целой. Но это приведёт к откату на последнюю корректно записанную транзакцию.
Размениваться на скорость параллельной записи, против latency — такое себе.
Для требовательных к write latency нагрузок нужно использовать Slog.
Не говоря уже про заявления о том что на ZFS не нужен WAL.
С точки зрения целостности он и правда не нужен, если правильно настроить размер блока записи и делать сброс данных на диск в нужный момент. Другой вопрос, что WAL в БД может использоваться, к примеру, и для репликации на другие инстансы. Этот момент я тоже в статье попытался рассказать.
А в рамках контекста статьи именно
бэкап, point in time recovery в zfs иногда можно обеспечить за счёт снапшотов.Т.е. я не хотел сказать, что WAL теперь вообще не нужен :) А что задачу целостности данных с него ZFS может забрать (как и некоторые другие).
Но есть интересные альтернативы.
Например, bcachefs и btrfs.
Или они обладают каким-то недостатком?
Про тот же btrfs, хотя его автор и признавал, что вдохновлялся и ZFS (хоть и не сразу), но по архитектуре они весьма отличаются, плюс отличается также и логика управления массивом.
Универсального решения нет, у всех свои плюсы-минусы, но весомый аргумент в сторону ZFS тут обычно — это опыт промышленного использования, скоро будет 20 лет как он существует.
А вообще это тема для отдельного цикла статей :)
В статье сравнивают "яблоки и лимоны". Ведь и то и то фрукты…
А мне хотелось бы сравнение с современными аналогами.
Ну и если кто-то утверждает, что какая-то fs ненадежна:
- Нужно описание, как повторить этот fail
- Понимание, почему это (ещё) не исправлено или не будет исправлено (никогда)
Просто для ошибок есть везде. Далеко ходить не надо, даже ecc не всесилен
bcachefs — сам видел мертвяка систему из-за мертвого ssd кэша
btrfs — были статьи на habr с детальным разбором и приходом к выводу что она не для продакшена, очень много экспериментов без финальной точки в ней
bcachefs — сам видел мертвяка систему из-за мертвого ssd кэша
вы, наверное, про bcache, а не про bcachefs.
ну и потеря данных из-за смерти накопителя выглядит как проблема не fs, а настраивавшего её админа, «ежу же понятно», что при wb кэше и выходе кэширующего накопителя из строя данные будут потеряны, поэтому нужно использовать избыточность (например, зеркало из двух ssd).
С мелкими файлами все очень плохо в zfs.
Особенно при копировании каталога с огромным количеством мелких файлов. Zfs выдаёт список файлов в копирующую программу в каком то странном порядке, который вообще никогда не бывает оптимальным для чтения.
И чем шире рейд, тем хуже скорость чтения. Иначе говоря скорость чтения мелких файлов в массиве дисков zfs бывает даже хуже одиночного диска на каком нибудь extfs. И в ZoL она хуже чем в фришной zfs.
сейчас проверил на raidz2 из 8+2 hdd, tar -c xxx | pv > /dev/null 50к файлов общим размером 3.5ГБ выполнялось 7 минут. это медленно или нет?
8.5 мегов в секунду на 10 дисках. Куда уж медленнее. Сравните с одиночным диском на ext4 или xfs
так подождите, куча мелких файлов, записывавшихся в разное время — тут по определению будет случайное чтение. и 10 дисков никак не помогут, tar работает в один поток.
docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-Dc4ZcwUdt6fkCjpnXxAEFlyA/edit#gid=1418963574
Нет ли серебряной пули? Вроде если ashift=12, а block size = 128kb (32 по этой таблице?) или 1Mb (256 по этой таблице?), то все у вас будет хорошо.
Т.е. можно собрать пул на raidz со special vdev, оставить дефолтный recordsize=128k, выставить special_small_blocks=32K, и все маленькие файлы или файлы с мелким блоком (recordsize до 32К) будут эффективно записываться на ssd mirror, а большие файлы — на raidz hdd.
В целом можно сказать, что raidz стоит использовать в основном для эффективного хранения данных с большим размером блока. В остальных случаях нужно считать оверхед по iops/используемому пространству.
А вот как бы решить задачу наоборот — все хранить на ssd/nvme и только файлы больше мегабайта писать на медленные диски?
special_small_blocks=1MЯ долго читал документацию и у меня не возникло понимания — с точки зрения внутренностей основными дисками при этом будут большие медленные диски? Т.е. если умрут они то вообще все потеряно, а если умрут special vdev то только они, или как?
В моей задаче нужно сохранить мелкие файлы и они должны быть на надежных быстрых ссд, а вот большие файлы не критичны, должны лежать на обычных дисках и очень хочется чтобы ничего принципиально не сломалось, если эти диски умрут. Возможно ли это?
И с точки зрения свободного места непонятно — если закончилось место на одном из девайсов — будет писаться на второй? Это работает в обе стороны?
Если вы хотите разделять данные по степени отказоустойчивости, то сейчас штатно это делается только через создание разных пулов.
Было бы полезно все-таки скидывать содержимое special на обычные vdev в простое, все-таки special не для расширения пула создают, а для производительности и обеспечивать на тем тот же уровень избыточности не всегда хочется. И оценивать надёжность ссд по сравнению с хдд тоже.
Например у меня были случае, когда ссд от special выкидывало на автотриме. Т. Е даже при одинаковом уровне избыточности special из ссд может стать точкой отказа и убить весь пул.
Было бы полезно все-таки скидывать содержимое 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.
Нужно выставить special_small_blocks=1Mа оно разве не после сжатия считается? (я предполагаю, что с этой настройкой все более-менее сжимаемые файлы «уедут» на special vdev)
Тулинг для реплик в последней версии обновили. Там можно настроить все мыслимые опции,
* можно задать реплику дерева датасетов, но исключить конкретные узлы.
* можно использовать реплицировать ТОЛЬКО уже имеющиеся на проде снимки, либо делать снимки по расписанию и сразу их реплицировать.
* можно автоматизировать удаление старых (сделанных утилитой) снимков на проде, а на сервере бэкапов их оставить.
* можно делать бэкап с удаленного сервера на удаленный сервер, с удаленного сервера на на локальный, или с локального на удаленный. Главное чтобы был доступ по SSH и ZFS. Бэкап с Proxmox на локальный пул Freenas работает.
* можно добавить создание закладок ZFS на проде для снимков, которые используются для реплик, чтобы если вдруг на боевом сервере почистят снимки и удалят последний релицированный снимок, все равно можно было бы продолжить репликацию. Иначе пришлось бы создавать новую резервную копию
* можно настроить уведомления на почту, в случае проблем с заданиями репликации
Нашел несколько прог под винду для восстановления и поиска данных. Есть очень неплохие, но за деньги и немалые. Смог слить некоторое кол-во фоток и то часть повреждены. Так что пришел к выводу — лучше ext4+mdadm+LVm и не жужу!
1-ые две — freebsd, последняя — linux.
Все три умеют жить на флешке.
Зы. TrueNAS — крут, но монстр по потреблению ресурсов.
Ну и сегодня вышел релиз 2.0. На мой взгляд, замечательное событие, во многом потому, что наконец-то удалось объединить разработчиков разных ОС для работы над единым проектом.
Ждём полноценной поддержки в Win и Mac OS X))
Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions.
Хотя в продакшене нашего подразделения мы и не используем ZFS
И сразу противоречие! И оно как то незримо фоном идет во всех статьях про эту ФС. Прокомментируйте, почему так сложилось хотя бы у Вас.
зы вообще столкнулся с тем, что нет стабильной ФС со сжатием под линь. А надо: очень экономит место на небольших VDS.
ззы вечные беты btrfs, reiser4(5), zfs не предлагать!
И сразу противоречие! И оно как то незримо фоном идет во всех статьях про эту ФС. Прокомментируйте, почему так сложилось хотя бы у Вас.
Под каждую задачу свой инструмент, идеального решения нет. В статье я указал только ситуацию в конкретном подразделении конкретной компании, и то в рамках дозволенного к оглашению :). Если говорить только обо мне, то за рамками остались остальные личные/рабочие инсталляции с ZFS, которые здравствуют и бесшовно обновляются уже который год, переживая сбои и некорректную работу дисков, ОЗУ, ЦПУ, блоков питания и т.д.
Это я ещё не перечислил продукты других компаний с ZFS, существующие не первый год.
зы вообще столкнулся с тем, что нет стабильной ФС со сжатием под линь. А надо: очень экономит место на небольших VDS.
ззы вечные беты btrfs, reiser4(5), zfs не предлагать!
Критерий стабильности каждый определяет для себя сам, как и выбор инструмента для конкретных задач.
Это конечно сугубо моё личное ощущение, но этот Stratis — очередная попытка RedHat запилить вендорлок. Я просто не могу воспринять это творение в сравнении с ZFS или BTRFS. Сама архитектура вызывает отвращение https://www.opennet.ru/opennews/art.shtml?num=51828
btrfs вполне можно развивать, и она будет не хуже ZFS.
Тут, да. С поддержкой не всё так просто.
BTRFS, ну вроде как есть поддержка от Oracle Linux, SLES.
ZFS, та что проприетарная старая — Oracle + Solaris.
OpenZFS, тут только от вендоров конкретных продуктов.
В случае RedHat. Это просто технически сложно добиться тех же результатов с помощью EXT4|XFS + lvm. Пока невозможно сделать столь же эффективные снапшоты на блочном уровне. Так же как и сжатие, шифрование датасетов и т. д.
Ну например у нас ZFS уже много лет в проде.
И оно как то незримо фоном идет во всех статьях про эту ФС
Это потому, что ZFS кардинально отличается от классических ФС, типа ext4, XFS. Чтобы её эксплуатировать нормально, нужны хотя бы минимальные знания о том как она работает. Это не говоря, о просто администрировании — там талмуд на сотни страниц. Можете поглядеть документацию от Oracle. Поэтому сложно её рекомендовать как ФС по-дефолту. В Linux дополнительно накладываются проблемы с лицензией, поэтому различные дистрибутивы не предлагают её по-умолчанию.
C VDS многие хостеры вообще ненавидят ZFS, т.к. она может сходу выжрать/разметить весь диск.
Чтобы её эксплуатировать нормально, нужны хотя бы минимальные знания о том как она работает.
Если смотреть на десктопный сегмент — то в убунте 20.04 она идет из коробки как экспериментальная, а с 20.10 — полноценная. Пользовать ее, по крайней мере, на этих системах можно вообще не понимая о чем речь :) Вопрос: есть ли смысл ее ставить на домашние системы с одним/двумя дисками?
Для домашних систем мне сложно что-то посоветовать, т.к. я буду предвзят. Я как разработчик имею дело с ZFS на работе. Естественно, что у меня она стоит и на домашней системе. Но я и по полной эксплуатирую её фишки: снапшоты, boot environment, сжатие для отдельных датасетов с исходниками, backup с помощью send/receive. Плюс у меня два диска в зеркале, что тоже проще чем подпрыгивание с mdadm и т. д.
В целом для домашних систем по-дефолту я бы её не советовал, хотя бы из-за жора памяти. EXT4 и классические ФС вполне справляются с 90% задач обычных пользователей. Но если вам действительно нужны фишки ZFS, то да, стоит её ставить. и не мучать себя альтернативами типа ext4 + lvm, mdadm и т. д.
Чтобы её эксплуатировать нормально, нужны хотя бы минимальные знания о том как она работает.
В общем случае, ничего не нужно. Опыт FreeBSD где ZFS уже второй десяток лет в эксплуатации, в том числе и много лет как файловая система по умолчанию тому подтверждением.
В общем случае, ничего не нужно.
Таки нужно, и тут как минимум два момента (как раз по некоторому опыту эксплуатации под FreeBSD):
Никогда не заполнять файловую систему более чем на 98%! Лучше — останавливать раньше. По границе 98-99% её может тупо парализовывать внутренней вознёй по сборке/очистке.
Выделять оперативную память и настраивать размеры под неё без всякой экономии.
Первый пункт особенно неудобен тем, что выжирание может наступить непредсказуемо. Я не знаю, ввели ли сейчас какой-то защитный резерв (как у классической UFS доля рута), но без него управление начинает требовать плохих мер.
Reservation property — это оно? Если да, это надо было бы вводить в каждой инструкции, но в большинстве howto это игнорируют.
Ну первый пункт это форс-мажор.
По второму я на практике ни разу такой потребности при использовании системы для домашнего и офисного применения не испытывал за эти годы. ZFS с удовольствием забирает память под свои нужды по мере в этом потребности. При этом, справедливости ради, раньше ZFS отличалась тем, что крайне неохотно отдавала оперативную память другим процессам. Однако, как я вижу в последние годы, сейчас последнее поправили, так что даже в случае крайне ограниченного размера RAM специального вмешательства не требуется что, конечно, не исключает возможности это подкорректировать.
На мой взгляд, параметры по умолчанию во FreeBSD подобраны хорошо.
dRAID решает проблему одновременного восстановления данных на большом количестве дисков
да, массив будет гораздо меньшее время в degraded state, но ИМХО в случае raidz2 (и тем более z3) это не так уж важно, зато общее время ребилда («всё тормозит») увеличится.
Особенности работы ZFS
ох, если смотреть на raidz, то тут много всего.
- в raidz нельзя добавить диск.
есть у вас, например, vdev из 8+2 дисков, нужно расширить ещё на пару дисков, единственный вариант — создать рядом ещё один vdev на 2+2 накопителя и включить его в тот же пул (разумеется, никто не будет так делать, придётся собирать рядом «на вырост» ещё один vdev на 8+2).
да, draid, как я понял, тоже будет обладать этой «особенностью»: возможность расширения планируется, но если мы составили массив со схемой 8+2, то добавить в него можно будет только 10 накопителей сразу.
в сравнении с ceph, например, который позволяет не только вводить-выводить накопители хоть по одному, но и делать массив из накопителей разного размера, это выглядит ужасным анахронизмом (я понимаю, что ceph про другое, но пример показывает, что задача «создать расширяемый пул из кучи накопителей» решаема); - raidz генерирует жуткую мультипликацию операций ввода-вывода.
поясню: в случае классических raid вы можете установить большой размер блока (например, несколько мегабайт), и операция последовательного чтения мегабайта с большой вероятностью затронет один диск.
в случае raidz же максимальный рекомендуемый размер записи — 1 мегабайт, чтение одного мегабайта затронет все диски в vdev (ну разве что диски с избыточностью не будут читаться). и то, что zfs знает о файлах, играет тут против наc: даже если файл меньше мегабайта, но занимает несколько секторов, то он будет-таки «размазан» по всем дискам.
в отношении больших файлов проблему бы решили гигантские recordsize (десятки мегабайт), они заодно существенно улучшили бы степень сжатия для zstd, но максимальный рекомендуемый размер, повторюсь, — 1Мб; - фича «special vdev» очень крута, конечно, но есть впечатление, что дизайнили второпях.
нельзя реализовать многоуровневое хранилище, например, метаданные мы храним на зеркале ssd, мелкие блоки на тройном зеркале hdd, а крупные — в raidz2 на hdd. это бы во многом решило проблемы предыдущего пункта с мелкими файлами (хранить их все на ssd всё-таки накладно).
да, кстати, интеграцию special vdev с l2arc тоже так и не сделали, печаль (нельзя объяснить zfs, что метаданные у нас уже на ssd, и поэтому создавать их копию на кэширующем ssd бессмысленно).
но при всём этом я считаю, что лучше zfs для долговременного хранения данных пока ничего не придумано. вот только вот вывел из массива два годовалых 16Тб диска, на обоих zfs пачками показывала ошибки контрольных сумм, притом как минимум на одном из них это произошло до того, как посыпались дисковые ошибки. с любыми другими файловыми системами я бы практически гарантированно получил silent data corruption (ну или не silent, если есть чексуммы на уровне fs, но всё равно данные были бы утеряны), тут же zfs известила ошибках и исправила их.
да, массив будет гораздо меньшее время в 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). Как они будут реализованы — на их основе можно будет сделать такую приоритизацию.
Когда в пуле больше 100 дисков, то сокращение времени в degraded state всё же критично.
массив из 100 дисков будет не на одном vdev же (если мы говорим про обычный raidz), так что ИМХО число дисков тут роли не играет.
Можно задавать размер блока до 16М, увеличив параметр модуля zfs_max_recordsize. Оно прекрасно работает (проверено не раз лично), но только для соответствующего профиля, т.к. операции с таким размером блока сильно уменьшают iops (относится и к обычному raid).я из документации/обсуждений понял, что тут могут быть ещё не обнаруженные другими грабли.
раз вы считаете, что пользоваться можно, то, наверное, попробую скоро.
В момент разработки данного функционала у vdevs не было своих свойств (properties).
вот оно что, слона-то я и не приметил.
Подскажите — 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? Выбранные папки с подпапками? Выбранные типы данных? Иное?
Лучше всего, конечно, взглянуть на синтаксис того, как это подмножество задавать
Что это? Как я понимаю, 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. На принимающей стороне из такого неполноценного снапшота можно создать рабочий клон.
Активно пользуем 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.
ZFS: архитектура, особенности и отличия от других файловых систем