Помогите с пониманием дела создать ZFS

сначала создай из двух

Задача - создать ZFS из 58 дисков.

Собирай пул raidz3, он переживет гибель трёх дисков.

Я правильно понимаю, что создавая пул так:

zpool create pool0 raidz2 /dev/sdx … raidz2 /dev/sdx

получается пул из двух raidz2, где в рамках одного raidz2 может выйти из строя 2 диска, а на весь пул может выйти 4 диска?

Одиночные vdev по своей сути опасны.

Одиночные Ext4, Btrfs, XFS, ReiserFS, UFS, NTFS, FAT32 по своей сути опасны!

Как правильно создавать эти пулы? 1 пул на все 58 дисков, или же разбить их? Как это влияет на отказоустойчивость и на время ребилда?

Каждое добавление диска в пул требует ребилда. Чем больше данных/метаданных, тем дольше будет ребилд. Потому создание пула сразу из пачки дисков будет быстрее создания из нескольких с последующим вводом остальных.

а на весь пул может выйти 4 диска?

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

Но суть я уловил правильно, спасибо.

1. читаем про draid

2. читаем про ashift

3. PROFIT

dRAID на 58 дисков - ОК, он для этого и был придуман. Просто raidz3 - боже упаси.

«Одиночные vdev по своей сути опасны. Такое виртуальное устройство не переживёт ни одного сбоя — и если используется в качестве хранилища или специального vdev, то его сбой приведёт к уничтожению всего пула. Будьте здесь очень, очень осторожны».

Статья от Капитана Очевидность: если Вы сделаете массив из одного диска и диск умрёт, то умрёт весь со всеми данными на нём. Ну да, логично.

P.S. а ещё у меня пара SSD. Отдать их под кэш?

Зависит от рабочей нагрузки на массив. Какая она у Вас? Если не ошибаюсь, возможности сейчас такие (коллеги, поправьте/дополните, если ошибаюсь):

• l2arc (кэширование чтения на ssd),
• zil (кэш записи для ускорения некоторой записи),
• special device (вынос мелких файлов на ssd). Для надёжности, для zil и special device рекомендуют использовать mirror из ssd.

По оптимизации под конкретные задачи - см. тут

dRAID разве уже получил путевку в Энтерпрайз?

zil не кэш записи.

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

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

А о какой именно опции речь, Вы не помните?

Речь не про special device, случайно?

zpool status показывал проблему?

Написали багрепорт?

dRAID разве уже получил путевку в Энтерпрайз?

А какой критерий Энтерпрайза?

dRAID вошёл в релиз ZoL 2.1.0. В Proxmox’e, например, уже 2.1.2.

zil не кэш записи.

Да, Вы правы. Я написал «для ускорения некоторой записи», надеясь, что никто не придерётся. Надежда не оправдалась :)

Потеря BTRFS (комментарий)

Ну я багрепорт не отправлял, а разгневанный на моё замечание о печальных пропажах Psychosis [тут](Потеря BTRFS (комментарий)) и [тут](Потеря BTRFS (комментарий)) что такого бага в багтрекере нет.

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

Ну для конкретики я скажу что я пользовался zfs-fuse, а что в других реализациях не знаю.

Там же в этой теме можно посмотреть как именно я на этот баг наскакивал.

А о какой именно опции речь, Вы не помните?

Не помню, но она там одна такая.

Написали багрепорт?

Не писал, но на ЛОРе рассказывал давно, и меня довольно хорошо за это облили помоями.

Речь не про special device, случайно?

Не знаю что это такое, я через zfs-fuse собрал zfs в режиме raid5 из восьми 250 ГБ WD Raid Edition, чексуммы и принудительная компрессия zip6 включена.
(Более эффективные компресcии перегревали процессор и он превращал данные в труху)

Гм.

5-7 лет zfs явно хуже работала (в linux), чем сейчас. Ну и может быть, реализация в виде zfs-fuse кривая (ни разу ей не пользовался).

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

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

Вы что, всё чейнджлоги читали?

В общем, я предлагаю не смущать ТС этой проблемой :)

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

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

На худой конец можно оставить папку с файлами меньше 1 килобайта и ждать сообщения о ощибках в логах(раньше чем через полгода не появятся)

А какой критерий Энтерпрайза?

Статус «Production Ready» это путевка туда.

dRAID вошёл в релиз ZoL 2.1.0. В Proxmox’e, например, уже 2.1.2.

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

Я бы задал себе вопросы:

0. Действительно ли мне нужна ZFS? 
1. Для каких целей будет использоваться хранилище?
2. Какие преимущества будет иметь ZFS по сравнению с нативными решениями (к примеру, RAID10+ext4/XFS)?
3. Планы по обслуживанию.

Быстрый поиск показывает, что в статусе «Developer preview», dRAID был 3 года назад.

На мой взгляд, для 58 дисков лучше использовать относительно новую фичу, чем поиметь «Death Spiral».

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

Вроде ZFS’ники в этом плане более надёжные ребята, чем RH.

0. Действительно ли мне нужна ZFS?

Действительно ли нужны чексуммы, снепшоты, background scrubbing, send-receive (для бэкапов/миграции/синхронизации с другим массивом), dRAID, компрессия, отсуствие смешных лимитов для большого массива? Ну да, нужны, конечно.

2. Какие преимущества будет иметь ZFS по сравнению с нативными решениями (к примеру, RAID10+ext4/XFS)?

см. выше.

• raid10 — 50% доступного места.
• Ext4 — смешные лимиты (типа inode)
• XFS — уже лучше

3. Планы по обслуживанию.

Присоединяюсь к вопросу!

по сравнению с нативными решениями

Лучшую поддержку из коробки, отсутствие заморочек с памятью (не надо l2arc ограничивать, что бы ZFS не брала 50% ОЗУ по кэш).

Быстрый поиск показывает, что в статусе «Developer preview», dRAID был 3 года назад.

а медленный?😏
в официальном мануале об этом ни слова.

На мой взгляд, для 58 дисков лучше использовать относительно новую фичу, чем поиметь «Death Spiral».

нет, вводить в прод новую фичу - ССЗБ.
лучше проверенный временем сетап: stripe of raidz1|raidz2 (зависит от размера дисков) + spare.

Вроде ZFS’ники в этом плане более надёжные ребята, чем RH.

с чего бы?
у RH, ЕМНИП, новые фичи в релизах выходят в статусе «Technology Preview».

NOPA, а какие диски предполагается использовать?

нет, вводить в прод новую фичу - ССЗБ.

Вы всё правильно говорите. Вводить новую фичу в прод - ССЗБ. Подписываюсь.

Можно внедрить «stripe of raidz», подождать год, а потом переводить массив на «stripe of draid».

Можно внедрить «stripe of raidz», подождать год, а потом переводить массив на «stripe of draid».

и как давно zfs умеет «на лету» менять тип vdev?
или куда предлагаете сделать бэкап пула из 58 дисков?

Death Spiral

*интересуется*

background scrubbing

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

сам ты пони!

проблема решена планировщиком IO (5 уровней), у него для scrub самый низкий приоритет.

^_^

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

и как давно zfs умеет «на лету» менять тип vdev?

или куда предлагаете сделать бэкап пула из 58 дисков?

Minona, я был неправ, предполагая возможность такой миграции. Я себе неправильно представлял ограничения raidz vdev. Я предполагал возможность сократить один пул в размере (например, на 1/4), сделать второй (1/4), перенести в него часть данных, снова сократить первый пул и расширить второй пул и т.д.

Оказывается, такое можно сделать только с mirror vdev.

Оказывается, такое можно сделать только с mirror vdev.

Что сделать, уменьшить размер пула?
Или ты опять что-то путаешь, или я что-то проспал.

вопрос «почему?» это к разработчикам MD.
там где-то должны настраиваться ограничения на процедуры проверки/ребилда.

выходит, пользоваться вообще нельзя?

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

Ну не может же быть настолько большой разницы между конкурирующими технологиями

почему не может?
ZFS проектировали грамотные инженеры Sun с ориентацией на «кровавый энтерпрайз».
а MD - хз кто, в свободное от основной работы время.
MD не конкурент ZFS.
у ZFS из опенсорс проектов нет конкурентов.

кстати, про ТС то мы забыли совсем 😏
как у тебя эти 58 дисков подключаются?

Что сделать, уменьшить размер пула?

Да.

Ограничения указаны в man zpool-remove:

This command supports removing hot spare, cache, log, and both mirrored and non-redundant primary top-level vdevs, including dedup and special vdevs.

Top-level vdevs can only be removed if the primary pool storage does not contain a top-level raidz vdev, all top-level vdevs have the same sector size, and the keys for all encrypted datasets are loaded.

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

Так и должно быть, в моём понимании. Хотя да, возможность руками переместить данные с одного физического диска на другой (в рамках одного пула), как в lvm pvmove сделано - была бы полезна.

zpool remove vdev - относительно недавняя разработка. Может быть, в будущем добавят возможность и zraid/draid сокращать.

zpool remove vdev - относительно недавняя разработка

До чего дошел прогресс! Я помню еще категорическое «хотите уменьшить ZFS-пул? Ответ - никак». Вариант с миграцией всего через send/receive в новый пул - это, естественно не решение, а вынужденная мера.

А поди ж ты, есть подвижки в эту сторону, пусть пока и с тонной ограничений...

с тонной ограничений...

да какая тонна...
вроде одно — нельзя уменьшить raidz.

До чего дошел прогресс!

до расширения raidz. уже совсем скоро в продакшене. 😏