forum.lissyara.su

Доброго дня. Вопрос больше теоретический и возможно глупый.
Дано: 3 винта с архивной информацией, которые стоят на разных системах. Емкость 500гб. (условно для простоты). Заполнены не полностью.
Задача - собрать инфу в одном месте.
Выделили следующее:
Есть мать с 4 сата. И один свободный винт на 500.
Как я это бы хотел сделать: поднять 13 фрю на zfs. Залить на нее данные с первого винта и таким образом освободить его, затем подключить к фре, увеличив емкость, залить данные с остальных винтов и увеличить емкость общую емкость.
В идеале если взять все 4 диска одновременно - это raidz. 3+1 для четности.
Но я не уверен что если я поставлю фрю просто на zfs то смогу его расширить сначала до raid stripe а потом до raidz
Если кто знает как это делается - прошу ткните носом в мануал, ну или в 2 словах направьте как это сделать а маны я постараюсь сам раскурить

Но я не уверен что если я поставлю фрю просто на zfs то смогу его расширить сначала до raid stripe а потом до raidz
Если кто знает как это делается - прошу ткните носом в мануал, ну или в 2 словах направьте как это сделать а маны я постараюсь сам раскурить

никак. ZFS на один диск - это уже stripe без резервирования, как итог, последующая
трансформация в zraid1/2/3 невозможна по определению, по архитектуре.

Ну и при отсутствии практики, я бы не стал делать bootable zraid1...

ps. Ну и следует помнить что заполнение zfs > 70% грозит деградацией
производительности. Про RAM и вовсе молчу.

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

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

ничего. я таких технологий не знаю.

"защита от выхода из строя одного из дисков" - предполагает:
избыточность.

Другой вариант: независимость FS на каждом отдельном диске
и их объединение в единое пространство на уровне какой-нибудь: unionfs или nullfs
Выход одного диска - потеря лишь данных одного диска.

Тогда я предполагаю что мой вариант - промежуточное хранилище. Благо оно есть - не хотел данные два раза гонять.
Освобождение дисков. И сборка сразу на raid-z.
В этом случае я получу 1.5 тб полезной емкости из 4 винтов по 0.5тб. И один пойдет в избыток. Правда, насколько я понимаю расширить в этом случае не получится? Слышал что грядут изменения в zfs - как раз что то на счет расширения хранилища. Не в курсе как это будет работатб?

Освобождение дисков. И сборка сразу на raid-z.
В этом случае я получу 1.5 тб полезной емкости из 4 винтов по 0.5тб.

в raidz оптимально 3 диска в одном vdev'е

Raidz: 3, 5, 9, и тд (2+1, 4+1, ...)
Raidz2: 4, 6, 10, и тд (2+2, ...)
Raidz3: 5, 7, 11, и тд (2+3, ...).

выше таблица оптимального кол-ва дисков в одном vdev'е для raidz1/2/3
если учесть что начиная с 9'ти hdd в одном vdev'е, работа zfs деградирует по производительности,
таблица будет:

Raidz: 3,5
Raidz2: 4,6
Raidz: 5,7

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

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

ps. Я не оставляю диски на горячий резерв. Меняю при необходимости.

Phanthom писал(а): ↑

2021-10-24 16:47:53

Тогда я предполагаю что мой вариант - промежуточное хранилище. Благо оно есть - не хотел данные два раза гонять.
Освобождение дисков. И сборка сразу на raid-z.
В этом случае я получу 1.5 тб полезной емкости из 4 винтов по 0.5тб. И один пойдет в избыток. Правда, насколько я понимаю расширить в этом случае не получится? Слышал что грядут изменения в zfs - как раз что то на счет расширения хранилища. Не в курсе как это будет работатб?

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

guest писал(а): ↑

2021-10-24 22:05:37

Raidz: 3, 5, 9, и тд (2+1, 4+1, ...)
Raidz2: 4, 6, 10, и тд (2+2, ...)
Raidz3: 5, 7, 11, и тд (2+3, ...).

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

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

дело не только в кратности степени 2, было дано оптимальное кол-во дисков в одном vdev.
Алгоритмы не изменились.
Если берем FreeBSD, то recordsize=128K, ZFS размазывает данные по дискам и формулу для
оптимального выравнивания данных, никто не отменил и не изменил:

128KiB / (nr_of_drives – parity_drives) = maximum (default) variable stripe size
(все это подтверждено и теорией и практикой), получаем таблицу:

3-disk RAID-Z = 128KiB / 2 = 64KiB = удачное выравнивание
4-disk RAID-Z = 128KiB / 3 = ~43KiB = ПЛОХОЕ
5-disk RAID-Z = 128KiB / 4 = 32KiB = удачное выравнивание
9-disk RAID-Z = 128KiB / 8 = 16KiB = удачное выравнивание
--
4-disk RAID-Z2 = 128KiB / 2 = 64KiB = удачное выравнивание
5-disk RAID-Z2 = 128KiB / 3 = ~43KiB = ПЛОХОЕ
6-disk RAID-Z2 = 128KiB / 4 = 32KiB = удачное выравнивание
10-disk RAID-Z2 = 128KiB / 8 = 16KiB = удачное выравнивание

Про кол-во дисков в vdev, как разработчики говорили что лучше
не использовать >9xHDD в одном VDEV'е, так все и осталось,
заложенные алгоритмы коренным образом не изменились.

Админы приходили и спрашивали, почему у тебя ZFS быстро работает
и scrub быстро проходит?
Предлагал без всяких тюнингов изменить конструкцию RAIDZ1:
с
# zpool create poolname raidz disk1 disk2 disk3 disk4 disk5 disk6 disk7 disk8 disk9
на
# zpool create poolname raidz disk1 disk2 disk3 raidz disk4 disk5 disk6 raidz disk7 disk8 disk9

те (то есть) грубо говоря с RAID5 на RAID50, аналогично и для raidz2.
Ситуация в корне менялась.

guest, так я про это выравнивание и говорю, кратно степени 2
в каком-то блоге прочитал что сейчас это не актуально, спорить впрочем не буду, у меня 1 raidz2 из 8 дисков на OmniOS, для бэкапов и дистров.
т.е. io нагрузки почти никакой. ☺

Hi Neus,

guest, так я про это выравнивание и говорю, кратно степени 2
в каком-то блоге прочитал что сейчас это не актуально, спорить впрочем не буду, у меня 1 raidz2 из 8 дисков на OmniOS, для бэкапов и дистров.
т.е. io нагрузки почти никакой. ☺

Возможно... давно не читал про новшества...

Я отказался от Omni и OpenIdiana и перешел на Linux после того как в Proxmox допилили работу
с LIO Target iSCSI (Comstar работал классно).
Увы, устарели системы на базе illumos.

Перешел на Debian/Ubuntu, тьфу-тьфу-тьфу, уже несколько лет ZFS пашет по полной.
Жалко что ps и top не показывают использование ARC как в Solaris.

Все, что не span mirror, от лукавого

lazhu писал(а): ↑

2021-12-30 10:48:20

Все, что не span mirror, от лукавого

чо эта?

если только не храните там бэкапов и вам пофиг на производительность, любой parity check это жопа во всех смыслах

lazhu » 2021-12-30 13:30:46
если только не храните там бэкапов и вам пофиг на производительность, любой parity check это жопа во всех смыслах

чего-чего? где такую дурь дают?

span в zfs/raid технологиях подразумевает растягивать или охватывать.
span - это пул или недорейд из нескольких дисков (охваченных-растянутых в один пул или том...) без parity.
нормальным языком - это raid-0 конкатенированный (span) или jbod.

Для создания подобной шняги, zfs нафик не нужен:
- иная цель
- серьезное потребление ресурсов для такой лажи как span
- отсутствие надежности

gconcat или graid и получаем span без накладных расходов zfs.

ps. zfs span mirror - нужно сохранить сей шедевр.

lazhu писал(а): ↑

2021-12-30 13:30:46

если только не храните там бэкапов и вам пофиг на производительность, любой parity check это жопа во всех смыслах

https://www.delphix.com/blog/delphix-en ... love-raidz

guest писал(а): ↑

2021-12-30 14:23:06

span mirror

хз чего он имел ввиду, но видимо не в контексте zfs.
я по запросу span mirror нагуглил только port mirroring в cisco

guest писал(а): ↑

2021-12-30 14:23:06

span - это пул или недорейд из нескольких дисков (охваченных-растянутых в один пул или том...) без parity.
нормальным языком - это raid-0 конкатенированный (span) или jbod.

о!
а может под span mirror он имел ввиду raid-10?

guest писал(а): ↑

2021-12-30 14:23:06

много букофф

слышит звон, да не знает где он

Neus писал(а): ↑

2021-12-30 14:52:33

а может под span mirror он имел ввиду raid-10?

Да какой хотите, хоть 10, хоть n-way. Только не надо заливать мне про волшебный raidz. Возьмите терабайтную оракловую базу и посмторите, как она на вашем raidz крутиться будет

lazhu писал(а): ↑

2021-12-30 15:32:02

Возьмите терабайтную оракловую базу и посмторите, как она на вашем raidz крутиться будет

а raidz под DB никто и не ставит.

lazhu писал(а): ↑

2021-12-30 15:32:02

Возьмите терабайтную оракловую базу и посмторите, как она на вашем raidz крутиться будет

если пул на SSD или хотя бы l2arc на SSD сделать то и на raidz нормально будет.

Хотел спросить. Под Freebsd13 с openzfs работает авто горячая замена hdd. Эксперименты в виртуалке у меня не увенчались успехом

Непрочитанное сообщение lazhu » 2021-12-30 15:32:02

Neus писал(а): ↑
2021-12-30 14:52:33
а может под span mirror он имел ввиду raid-10?

Да какой хотите, хоть 10, хоть n-way. Только не надо заливать мне про волшебный raidz. Возьмите терабайтную оракловую базу и посмторите, как она на вашем raidz крутиться будет

Юноша столкнулся с проблемой, не имея опыта и сделал личный вывод что raidz г...о.

А мужики то из Oracle и Sun Microsystems об это и не знали...
Но почему-то делали raid10 для Oracle DB на базе raidz в далекие времена еще на шпиндельных
дисках из 4xHDD, 8xHDD и так далее и наслаждались скоростью чтения в Oracle.

guest писал(а): ↑

2022-01-20 12:45:23

raid10 для Oracle DB на базе raidz

Объясни плиз, что это за бутерброд получается: "raid10 on raidz"?