LINUX.ORG.RU

Разный уровень RAID для разных файлов на одном дисковом массиве

 , , ,


0

3

Итак, попробую объяснить, что я хочу и зачем мне это нужно. Давно планировал собрать себе RAID вместо (точнее, на основе и в дополнение к) сборной солянки из накопителей. Естественным образом выбор пал на RAID 5. Однако меня всё равно смущали определённые моменты:

  • Несложно представить ситуацию, когда либо нет возможности подключить все диски, либо из живых/доступных вообще только один. Не хотелось бы ограничивать себя необходимостью подключать как минимум (n-1) винтов, чтобы прочитать данные. В идеале важная информация должна дублироваться на всех ЖД, чтобы для получения доступа к ней было достаточно примонтировать один.

  • И наоборот: неплохо было бы не тратить лишнее пространство на избыточные копии неважных данных. Их можно и размазать по всем дискам для увеличения производительнотси.

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

Скорее всего, всё равно придётся использовать ZFS (в т. ч. ради контроля целостности), поэтому решил подумать, возможно ли там сделать сабж. Пришло в голову такое:

  1. На каждом диске создать по 2 (или 3, если решу к RAID{1, 5} добавить ещё RAID 0) логических тома с thin provisioning (sparse volumes).

  2. Первые тома на каждом диске объеденить в один тип массива, вторые — в другой и т. д.

  3. Получившиеся ФС монтировать отдельно (т. е. /mnt/raid1, /mnt/raidz, …) и опционально объединять через mergerfs.

Также нужна возможность пополнять хранилище подкроватного датацентра новыми винтами с сохранением существующих ФС.

Собственно, вопрос: насколько такая безумная затея осуществима в реальности? Подойдёт ли для этого ZFS? Получится ли при этом иметь нормальную производительность?

★★★★★

Последнее исправление: sudopacman (всего исправлений: 1)

Скорее всего, всё равно придётся использовать ZFS (в т. ч. ради контроля целостности), поэтому решил подумать, возможно ли там сделать сабж. Пришло в голову такое:

На каждом диске создать по 2 или 3 (в зависимости от того, решу ли я к RAID{1, 5} добавлять RAID 0) логических тома с thin provisioning.

ты хочешь к качестве vdev использовать LVM Thin?
Валяй, потом расскажешь как отреагирует ZFS на закончившееся место в LV.

Первые тома на каждом диске объеденить в один тип массива, вторые — в другой и т. д.
Получившиеся ФС монтировать отдельно (т. е. /mnt/raid0, /mnt/raidz, …)

это можно.

опционально объединять через mergerfs

хз может ли она работать поверх zfs.

Также нужна возможность пополнять хранилище подкроватного датацентра новыми винтами с сохранением существующих ФС.

тут все зависит от типа raid.
raid0, raid1 можно расширять.
raidz нельзя расширять добавлением еще одного диска, можно расширять только добавлением еще одного raidz, т.е. грубо говоря у тебя raid5 трансформируется в raid50.

Собственно, вопрос: насколько такая безумная затея осуществима в реальности?

тэг «вещества» вполне уместен 😏

кстати, по поводу производительности:
линейное чтение/запись в raid0 и raidz практически одинаковое.
стоит ли городить то, что ты задумал?

Minona ★★☆
()

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

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

нужна возможность пополнять хранилище

Не хотелось бы ограничивать себя подключать (n-1) винтов

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

Clockwork ★★★★★
()
Последнее исправление: Clockwork (всего исправлений: 2)
Ответ на: комментарий от Clockwork

ты не понял чего он хочет.
он хочет как в LSI MegaRAID: создавать разные типы RAID[0,1,5] на одном наборе дисков с возможностью этот набор расширять.

Minona ★★☆
()
Ответ на: комментарий от Minona

ты хочешь к качестве vdev использовать LVM Thin?

Нет, я хочу thin provisioning средствами ZFS, т. е. sparse volume.

хз может ли она работать поверх zfs.

Может, куда она денется?

линейное чтение/запись в raid0 и raidz практически одинаковое.
стоит ли городить то, что ты задумал?

Поэтому, скорее всего, будет без RAID 0. Только RAID{1, 5}.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от cobold

Не хотелось бы ограничивать себя необходимостью подключать как минимум (n-1) винтов, чтобы прочитать данные. В идеале важная информация должна дублироваться на всех ЖД, чтобы для получения доступа к ней было достаточно примонтировать один.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от sudopacman

Занятно. Что-то похожее видел в cephfs, там для файла через xattrs можно задавать pool, на котором он будет хранится, а в описании пула уже задается в том числе и избыточность. Но для этой задачи она явно не годится

cobold ★★★★★
()

Технически работоспособно, но практически, подозреваю, бессмысленно. Может, стоит рассмотреть более простые решения вроде SnapRAID? Очень популярно у любителей коллекций разноразмерных дисков.

anonymous
()
Ответ на: комментарий от Minona

raidz нельзя расширять добавлением еще одного диска, можно расширять только добавлением еще одного raidz, т.е. грубо говоря у тебя raid5 трансформируется в raid50.

Я думал, что уже можно, но это я перепутал dRAID с RAIDZ expansion. Не ожидал, что в mdadm можно, а в ZFS нельзя. А так вроде пишут, что скоро завезут.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от Minona

Пока ещё не доконца разобрался во всей терминологии. Но нужно, чтобы было так (со звёздочкой — виртуальный размер):

sda     [N TB]
├─ vol0 [N TB*]
└─ vol1 [N TB*]

sdb     [N TB]
├─ vol0 [N TB*]
└─ vol1 [N TB*]

...

sdM     [N TB] 
├─ vol0 [N TB*]
└─ vol1 [N TB*]
raid1 [N TB*]
├─ sda/vol0
├─ sdb/vol0
...
└─ sdM/vol0
raid5 [N×(M-1) TB*]
├─ sda/vol1
├─ sdb/vol1
...
└─ sdM/vol1

Виртуальный размер нужен, чтобы и RAID 1, и RAID 5 могли в теории использовать всё дотупное место без необходимости руками менять размер ФС, потому что заранее неизвестно, сколько данных будет храниться на каком типе массива.

sudopacman ★★★★★
() автор топика
Последнее исправление: sudopacman (всего исправлений: 1)

разные рэйды на одних дисках - никогда не понимал этой наркомании

zfs ditto blocks нужно тебе

anonymous
()
Ответ на: комментарий от anonymous

Слышал про SnapRAID, но не особо придавал значения. Сейчас почитал, и вроде бы там неплохо реализовано (полу)автоматическое раскидывание данных, да ещё и контрольные суммы. Достойно рассмотрения в качестве альтернативы моей задумке. Осталось найти, как там для разных данных разную степерь избыточности настроить.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от sudopacman

🤦‍♂️ так и думал.
ты задумал какой-то лютый бутерброд.
проще сделать один raidz[1|2] пул из всех твоих sdX.

Minona ★★☆
()
Ответ на: комментарий от anonymous

Это которое copies=n? А там можно а) сделать, чтобы эти копии хранились на разных дисках, всегда по одной на каждый винт (т. е. чтобы при замене или добавлении ЖД автоматически копировалось); б) получить доступ к отзеркалированным данным, примонтировав всего один диск из массива?

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от Minona

А мы не ищем лёгких путей (: Нужно же, чтобы можно было примонтировать только один винт и прочитать данные. Ты скажешь: «бэкапы», но а) n копий лучше, чем 2; б) у меня столько винтов нет.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от sudopacman

Нужно же, чтобы можно было примонтировать только один винт и прочитать данные

если этот винт был частью raid1, то прочитать сможешь.
если этот винт был частью raid[0|5] — нет.
т.е. при таком условии задачи, никакой другой тип raid, кроме raid1, ты использовать не можешь и городить такой бутер нет смысла.

А мы не ищем лёгких путей

сколько дисков одновременно ты хочешь подключить к своему серверу?

Minona ★★☆
()
Ответ на: комментарий от sudopacman

Виртуальный размер нужен, чтобы и RAID 1, и RAID 5 могли в теории использовать всё дотупное место без необходимости руками менять размер ФС, потому что заранее неизвестно, сколько данных будет храниться на каком типе массива.

Создай raid1/5 средствами LVM, тогда сможешь увеличивать нужный LV(raid1) или LV(raid5) по-мере надобности.

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от Minona

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

Так мне же нужно зеркалировать не все данные, а только часть. Для остального достаточно избыточности RAIDZ.

сколько дисков одновременно ты хочешь подключить к своему серверу?

В массиве будет 3–6.

sudopacman ★★★★★
() автор топика

Мне кажется на практике, даже если ты всё это реализуешь, оно окажется ненужным.

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

firkax ★★★★★
()
Ответ на: комментарий от sudopacman

я под твои хотелки сделал бы так:
zpool mirror на 2 диска
zpool raidz на 4 диска

но если ты хочешь бутер, тебе zfs не нужен.
делай LVM Thin на каждом диске
и два LV, для md-raid1 и md-raid5.

Minona ★★☆
()
Ответ на: комментарий от sudopacman

а) да, б) надо смотреть исходники или тестить, как он блоки раскидывает, я уже и не помню подробностей.

anonymous
()
Ответ на: комментарий от Minona

но если ты хочешь бутер, тебе zfs не нужен. делай LVM Thin на каждом диске
и два LV, для md-raid1 и md-raid5.

Получается, средствами ZFS нельзя такое? Не ожидал.

Матрёшка на dm-mapper какой-то слишком топорной кажется. Не уверен, что оно не будет люто тормозить. Там же и RAID пересобирается дольше, и dm-integrity в 2 раза режет скорость записи, а про VDO вообще лучше забыть. Но придётся и этот вариант тоже рассмотреть.

sudopacman ★★★★★
() автор топика

Как вариант:

  1. разбиваешь диски на 5-20 равных партиций каждый;
  2. первые партиции соединяешь в mirror пул zfs;
  3. последние партиции соединяешь в raidz пул zfs;
  4. по мере необходимости добавляешь в пулы партиции, двигаясь к центру дисков где-то ближе к середине пулы встретятся.
  5. некоторые партиции можно временно использовать под что-то другое, пока они не под zfs пулами.
anonymous
()
Ответ на: комментарий от anonymous

интересный вариант... но:
по мере добавления в пул новых партиций производительность IO начнет превращаться в говно.

Minona ★★☆
()
Ответ на: комментарий от sudopacman

Получается, средствами ZFS нельзя такое?

можно

смотри:
рейд делается 2 способами - md-raid & zfs-raid;
sparse volume тоже 2 - lv-thin & zvol;

т.о. у тебя есть 4 варианта:
md-raid over lv-thin;
md-raid over zvol;
zfs-raid over lv-thin;
zfs-raid over zvol.

развлекайся 😏

Minona ★★☆
()
Ответ на: комментарий от Minona

т.о. у тебя есть 4 варианта:

Не, ну смешивать device-mapper и ZFS я уж точно не буду. Остаётся (1) и (4). С (1) вроде всё понятно. Но с (4) уже возникают вопросы. Насколько я понял, иерархия такая: физические разделы → vdev → zpool → dataset/zvol. Получается, мне нужно ZFS поверх ZFS создавать?

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от sudopacman

Хотя я тут подумал: может, правда стоит ZFS использовать для создания блочных устройств вместо dm-матрёшки? Там ведь сразу и thin provisioning, и проверка целостности, и сжатие в комплекте. Создать на каждом диске по vdev/zpool, в нём по два sparse zvol. И уже эти zvol’ы объединить в mdraid и отформатировать в XFS.

@Minona

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от cobold

при больших размерах дисков что r1 что r5 - плохая идея (как ни странно)

и связано это с скоростью восстановления (resync/rebuild speed)

если нет жёстких требований к производительности (особенно на запись) и нужно много места (диски больше 2тб и их больше 4) - то r6 - наше всё!

mumpster ★★★★★
()
Ответ на: комментарий от anonymous

я использовал и использую дома ибо диски разные.

mumpster ★★★★★
()
Ответ на: комментарий от Minona

ой! только не надо про это амно тут вспоминать!

mumpster ★★★★★
()
Ответ на: комментарий от sudopacman

просто в zfs это делается по-другому ну плюс планирование никто не отменял. да и в mdadm ты просто так диски не добавишь в r5/r6, надо ждать rebuild.

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

у тя опыт большой работы с ZFS?

0

тебе вообще это для себя надо? или по работе?

Вряд ли бы я стал такой наркоманией заниматься не на личной машине.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от sudopacman

0

ну про «Нюансы» её знаешь вообще? или как раз, для прокачки опыта?

не на личной машине

на самом деле я уже всякого навидался ))))

то что ты хочешь - простым способом не сделаешь

и ZFS/mdadm под это совершенно не заточены (пропадающие диски - это та ещё попаболь! mdadm -C … missing делал когда-нибудь? ;) )

либо я не понял

лично я частично пользуюсь дома с твоей схемой по п.2 (/ раздел и прочие важные - в зеркале тройном SSD+ HDD с флагом W, остальные - по-разному, сейчас частично унифицировал и объединил в один большой R6 под файлохранилку).

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

ну про «Нюансы» её знаешь вообще?

Смотря что «нюансами» считать. По основным моментам RTFM сделал.

для прокачки опыта

И это тоже.

то что ты хочешь - простым способом не сделаешь

Это я с самого начала понял (:

В идеале хотелось бы, чтобы просто можно было на уровне ФС сделать, чтобы копия нужного файла/директории хранилась на каждом диске и чтобы можно было смонтировать отдельный диск в ro и получить доступ к таким файлам/директориям. Но такого нигде нет.

Пока что вот это — лучшее, до чего мне удалось додуматься. От ZFS я получаю:

  • сжатие;

  • контроль целостности;

  • снапшоты;

  • thin provisioning.

А от mdadm я получаю возможность расширять массив по мере приобретения новых дисков и даже возможность из RAID 5 сделать RAID 6. (Ну и возможность прочитать данные, хранившиеся на RAID 1, имея только один диск.)

Т. е. в теории в такой конфигурации есть сразу все нужные мне фичи. Но это в теории. А как оно будет работать на практике — пока неизвестно. Пойду хотя бы на «виртуальных» дисках протестирую.

sudopacman ★★★★★
() автор топика
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от sudopacman

не умножай сущности и надстройки сверх необходимости!

не, я понимаю, по приколу можно всякое, я раз так на лабах по Veritas vxvm raid5 поверх raid5 построил по приколу, он это позволяет. но смысл? и накладные и в случае проблем сложность играет против тебя же?

и плюс домашнняя тачка=>заведомо уязвима по сравнению с нормальным ЦОДом (гуcары, об OVH молчать!)

и главное - какой в этом практический смысл? thin pools придумали чтобы обойти проблему с жёстко задаваемыми границами RG под разные задачи, ну там redo логи на одной RG в зеркале, DB tablespace - на другой с R5. переделать - очень сложно. и не всегда можно предсказать чего и как.

но с трудом себе представляю зачем это дома? тем более если не венда и легко можно что угодно и куда угодно примонтировать? (на самом деле даже в венде много что можно)

можете тебе надо подумать и просто какой-нибудь rsync делать?

я твою проблему кажется понял и у меня есть что-то похожее - по историческим причинам у меня были ( и частично есть) дубли на разных разделах и я думал на тему автосистемы их удаления и разбрасывания. толкьо на уровен kernel fs это очень сложно, лучше с fuse начать.

mumpster ★★★★★
()
Ответ на: комментарий от sudopacman

для твоего подкроватного сервака пойдет любой из 4-х способов.
md over lvm самый быстрый по IO.

Насколько я понял, иерархия такая: физические разделы → vdev → zpool → dataset/zvol.

не совсем так.
vdev в zfs это либо "(block-device|file)" либо "(mirror|raidz[1-3]) of (block-device|file)".
т.е. так: vdev → zpool → dataset/zvol

Получается, мне нужно ZFS поверх ZFS создавать?

ага, и получится такой бутер 😏:
vdev → zpool → dataset/zvol → zpool → dataset

Minona ★★☆
()
Ответ на: комментарий от sudopacman

Там ведь сразу и thin provisioning, и проверка целостности, и сжатие в комплекте.

если у тебя пул не mirror|raidz, то проверка целостности тебе ничего не даст, чтобы от нее был толк тебе придется сделать copies=2.

сжатие:
смотри, размер блока в zvol делают равным размеру кластера ФС.
у XFS он 4к, а если у тебя диски с размером сектора 4к, то никакого сжатия у тебя не будет.

Minona ★★☆
()
Ответ на: комментарий от mumpster

а потому что предлагается сделать вот что:
разбиваем диски на партиции sda[1-N] sdb[1-N]
делаем mirror sda1 sdb1
затем по мере надобности добавляем mirror sda2 sdb2 ... mirror sdaN sdbN.
в результате получим распараллеливание IO по партициям sda[1-N] и sdb[1-N].

Minona ★★☆
()
Ответ на: комментарий от sudopacman

снапшоты

в твоей схеме: md over zvol, у тебя каждый zvol на отдельном пуле, как ты собрался делать согласованный снапшот на всех пулах?

Minona ★★☆
()
Ответ на: комментарий от sudopacman

нуу
если ты сделаешь 4-й вариант (zfs over zvol), то получишь все из этого списка:
сжатие;
контроль целостности;
снапшоты;
thin provisioning.

насчет производительности ничего не скажу 😏

Minona ★★☆
()
Ответ на: комментарий от Minona

если у тебя пул не mirror|raidz, то проверка целостности тебе ничего не даст, чтобы от нее был толк тебе придется сделать copies=2.

Так я же RAIDZ и планирую (решил всё-таки разупороться и сделать просто RAID 5/Z без бутербродов). Или даже на RAIDz нужно copies=2?

а если у тебя диски с размером сектора 4к, то никакого сжатия не будет

А если 512? 🤔

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от sudopacman

решил всё-таки разупороться и сделать просто RAID 5/Z без бутербродов

во! с просветлением тебя 😏
только если ты планируешь 6 дисков большого объема, то делай raidz2.

Или даже на RAIDz нужно copies=2?

нет конечно, я же написал: «если у тебя пул не mirror|raidz», т.е. пул из одного диска.

А если 512?

будет.
сжатие работает если recordsize>sector_size.
зависит от данных, фотки и видео почти не жмутся.

Minona ★★☆
()
Ответ на: комментарий от Minona

а! я сослепу пропустил важный момент, что ежа с ужом хотят скрестить! гыгы

а то по такой схеме - нарезка множества относительно мелких кусочков и размазывание LUN по таких кусочкам на множестве шпинделей. пусть даже и повторно, работали многие Hi-End СХД типа EMC Symmetrix. но так-то у меня примерно так нарезаны /, /var и хомяк - полёт норм! просто я странные идеи ТСа так и не понял. готовые fs и тем более нижняя прослойка типа dm/mdadm это решить не сможет.

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

mumpster ★★★★★
()

Сам в создании RAID почти полный 0, лет 10 назад mdadm по работе RAID1 сделал и больше не пользовался-решал-проблемы.
Но как вам идея использовать не ZFS, а btrfs?
А дубляж нужных папок доверить rsync по cron

s-warus ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.