Как лучше хранить большой массив информации? mdadm / lvm / zfs / btrfs

У нее, как и всего семейства FAT, с отказоустойчивостью полная беда из-за отсутствия журналирования. Да, переупрощение имеет те же последствия, что и переусложнение :)

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

Нет, это не так.

Нет, это не так.

Аргументируй.

и ты сильно ошибаешься

Удачи.

Не ошибаюсь. Могу привести пример: вот есть такая «замечательная» штука, как Kafka. Её брокеры в одном из кейсов живут на сервера с RAID10 в качестве стораджа данных из 24 дисков. Так вот, в случае начала деградации поверхности одного из 24 дисков, т.е. постепенного роста бб и ремапа их в резервные сектора, производительность этого брокера уходит ниже плинтуса, и в кластере появляются under replicated partitions, что в свою очередь аффектит консумеров и продюсеров. Поэтому такой брокер незамедлительно из кластера вынимается и сидит в сторонке, пока ему диск не поменяют.

Этот же пример, кстати, хорош и для понимания того, почему RAID10 лучше, чем RAID5/6 - время ребилда массива на 10 - десятки минут, время ребилда на 5/6 - до 10 часов, за которые может улететь другой диск и данным наступит кирдык. В описанном кейсе на это плевать, потому что на брокере уже нет данных (его ж отбалансили), но сам факт имеет место быть.

Насколько я знаю, mdadm можно расширять (и даже менять с RAID 5 на RAID 6). В ZFS можно будет расширять RAIDZ (т. е. vdev) новыми дисками, но пока нельзя. В BTRFS RAID 5/6 не рекомендуют к использованию.

В ZFS и BTRFS есть контрольные суммы для данных, в mdadm и/или стандартных ФС нет. Вроде как можно прикрутить dm-integrity, но скорость записи падает вдвое. Этого можно избежать, но ценой надёжности.

ext4 расходует место не самым оптимальным образом.

Да.

Насколько я знаю, mdadm можно расширять
В ZFS можно будет расширять RAIDZ
В BTRFS RAID 5/6 не рекомендуют к использованию.
ext4 расходует место не самым оптимальным образом.

В результате получается mdadm RAID 6 + XFS? Кстати, нужны ли всякие опции для указания размера stripe'а?

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

время ребилда массива на 10 - десятки минут, время ребилда на 5/6 - до 10 часов

чушь.
я проводил такой эксперимент на контроллере Adaptec и массиве из 8 дисков по 1 ТБ.
оба типа рейда ребилдились около 2 часов, т.е. со скоростью линейной записи на 1 диск.

Про XFS нужно держать в уме то, что она не любит отключения питания

емнип, это починили еще лет 10 назад.

Поэтому если нет контроллера с батарейкой

то любая не CoW FS идет лесом.

В результате получается mdadm RAID 6 + XFS?

Ну, если проверка целостности не нужна, то да. В ZFS ещё можно для разных dataset’ов разные параметры устанавливать, например recordsize или настройки сжатия.

Кстати, нужны ли всякие опции для указания размера stripe’а?

Не знаю.

Т.е. это 5 перестроений массива.

Не путайте перестроение массива, где сдох диск, с перестроением массива, где один диск заменяется на другой.

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

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

Свободное место станет частью того же раздела?

Свободное место в zfs общее для разделов на пуле by disign, если квоты не установлены.

Если нужно в будущем докидывать диски по одному

Если в будущем, то можно и подождать, пока расширение RAIDZ завезут.

подождать, пока расширение RAIDZ завезут

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

Что аргументировать? Что совокупность фич и гарантий, предоставляемых современными ФС, качественно превосходит то, что в принципе можно достигнуть с помощью «консервативных» ФС? Это очевидный факт, его не нужно аргументировать.

А вот особенно смешно, когда «новомодным» «хипстерским» «переусложнённым» вертикально интегрированным системам противопоставляются ни разу не переусложнённые слоёные пироги из десятка «консервативных» инструментов, каждый со своими проблемами, особенностями и failure mode. Вот это надёжность, вот это да.

Расширение RAIDZ имеет одну «небольшую» проблему: оно не изменяет длину страйпов и не уменьшает per-stripe overhead. То есть если у тебя есть RAIDZ из 3 дисков и ты добавляешь 4-й, то данные продолжают храниться с избыточностью 1/3, а не 1/4.

Смена типа RAID на лету (например, с mirror на raidz и потом на raidz2) в ZFS точно также невозможна.

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

Для этого всего припасено 5 дисков TOSHIBA HDWG160, 6 ТБ (5.4 ТиБ).
Я планировал из них собрать что-то вроде программного RAID 6, т.е. полезный объём будет равен объёму только трёх дисков, 18 ТБ.

Купи ещё один диск и сделай два RAID5 массива.

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

Лучше ext4, думаю. zfs от такого начинает лагать, её подражатель btrfs думаю тоже.

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

В отдельный физический массив? Пока дисков только 5. И что это даст, кстати?

Купи ещё один диск и сделай два RAID5 массива.

Тогда уж проще 10, не?

Расширение RAIDZ имеет одну «небольшую» проблему: оно не изменяет длину страйпов и не уменьшает per-stripe overhead.

Ну тогда это не интересно.

и сделай два RAID5 массива

Просто отличный совет! Только один маленький вопрос, а чего не нулевой? Что бы так сказать сразу, не мучаясь.

То есть если у тебя есть RAIDZ из 3 дисков и ты добавляешь 4-й, то данные продолжают храниться с избыточностью 1/3, а не 1/4.

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

В отдельный физический массив? Пока дисков только 5. И что это даст, кстати?

Перезаписи и плохая нагрузка от второго массива не будет вредить первому.

Тогда уж проще 10, не?

Ну я думал у тебя бюджет ограничен, не надо зря лишнее покупать. Можешь и 10 купить. Но как минимум один докупить крайне желательно. Ну, можно сделать RAID5 (2+1) и миррор под те данные что 5гб, но объёмы данных имеют обыкновение расти, у тебя закончится место, а конвертировать его в RAID5 на лету не совсем просто.

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

Ну а RAID0 это вредительство в чистом виде.

Ты так пишешь, как будто RAID5 из трёх дисков это что-то плохое.

Как будто, это что-то хорошее.

Ну а RAID0 это вредительство в чистом виде.

Однако это не мешает вам его советовать.

Не нашёл информации по этому поводу, но по идее должно работать для существующих.

Да, я знаю. Но тут как с устройствами все-в-одном - отдельные устройства свои задачи все равно выполняют лучше. LVM дает намного больше гибкости в последующих изменениях стораджа вот и все. А так, конечно, можно «ехать» с одним лишь mdadm или наоборот - с одним лишь lvm.

После расширения данные можно самостоятельно перезаписать, чтобы освободить место.

RAID0 я не советовал. А RAID5 из трёх дисков это вполне себе хорошо, или у тебя есть аргументы против?

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

Нет, кмк, это курам на смех.

Да. Когда вылетит диск, ваша карета превратиться в тыкву raid0.

Когда вылетит диск, его надо заменить.

И если оценивать такие риски - надо оценивать вероятность не эмоционально ужасных событий типа «у меня получился raid0», а вероятность поломки массива (это тогда вылетят одновременно, до замены и восстановления, 2 диска в RAID5 или 3 диска в RAID6).

Ну, теоретическая вероятность поломки указанного RAID6 может быть меньше чем вероятность того, что сломается один из двух половинных RAID5 (хотя - не факт, диски в RAID6 будут быстрее изнашиваться сами по себе). Но вероятность и там и там исчезающе мала и она «потом» (см. ниже*), а вот просадка производительности в RAID6 будет заметная и она «сейчас».

Если пугают такие перспективы - надо делать два RAID6 массива (докупив ещё 2-3 диска), они и ещё надёжнее будут, и быстрее. А если бюджета не хватило - смириться с тем, что возможости оплатить ещё большую надёжность сейчас нет. (*)Кстати со временем (когда деньги найдутся) можно страшные RAID5 несложно сконвертировать в RAID6, докупив им по диску. А если денег не будет, то и raid6 со временем сдохнет, если ему диски не менять.

----

А, я почему-то решил что там будет большая нагрузка. Хотя автор впрямую это не заявлял. Если нагрузки особой нет (ну, допустим, суммарный объём всех операций меньше чем 100мбайт/сек) один raid6 на всё проблем не вызовет. Если же есть - то см. выше.

Но ведь у ТСа всего два dataset’а, а снапшоты он вообще использовать не собирается.

Я вот тоже не вижу смысл тонны снапшотов заводить, особенно для объёмных данных, которые очень нужно было бы переписывать для освобождения места.

Но вероятность и там и там исчезающе мала

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

а вот просадка производительности в RAID6 будет заметная и она «сейчас».

Просадка по производительности будет заметна если есть с чем сравнивать.

Что хочу добавить лично от себя. Во-первых, никаких рейдов в BIOS, конечно. Во-вторых, учитывая необходимость, как минимум, зеркалировать информацию на не забитом под 100% носителе и куда-то еще и бекапиться, дисков слишком мало. В-третьих, надежное хранение у меня подразумевает исключительно CoW и контрольную сумму данных. То есть это только ZFS и BTRFS.

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

Мне однозначно очень нравится ZFS, даже на Linux. Однако, если это какой-то десктоп и ты просто похвалился наличием памяти, которая на самом деле будет занята всякими браузерами, то никаких особых преимуществ получить не удастся. И заполнение больше 80% ZFS очень не любит, будет тормозить. И дефрагментатора для нее нет. И модуль собирать, если у тебя часто ядро обновляется, замаешься… На Gentoo или Fedora ZoL достаточно болезненная штука, говорю по собственному опыту.

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

В общем, если это выделенная машинка со статичным дистрибутивом, я бы использовал ZFS на 8Тб (зеркало из двух дисков) и ZFS на 5Тб (тоже зеркало), не забыв разрешить раздуваться кешу ZFS (он отдельный) до 25Гб (sysctl тоже не забудь). Если десктоп - плакать и играть в пятнашки на BTRFS, тоже зеркалами.

Во-первых, никаких рейдов в BIOS, конечно

Естественно! Кто тут такое посоветовал, пусть у себя использует.

пул для бекапа и хранения тех 8Тб

Они всё же тоже немного изменяемые, как я написал, там не 100% read only.

Однако, если это какой-то десктоп и ты просто похвалился наличием памяти

Я написал, т.к. часто говорят о повышенной потребности у ZFS, не 32 GiB это не много, чтобы хвалиться.

которая на самом деле будет занята всякими браузерами

Она будет занята процессами, что будут эти данные «жевать», собственно из почти read only группы данные будут частями перетекать во вторую группу.

И заполнение больше 80% ZFS очень не любит, будет тормозить.

Речь про 80% RAID или памяти? Есть RAID, то это очень даже вероятно, т.к. пока дисков вот столько, сколько есть.

И модуль собирать, если у тебя часто ядро обновляется, замаешься… На Gentoo или Fedora ZoL

Сейчас там стоит последняя Ubuntu, вроде как в ней ZFS поддерживается вполне официально и для корня в том числе. Хотя, в моём случае, пока корень и не требуется на ней. На Ubuntu и хотелось бы остаться. Или всё равно надо будет пересобирать?

BTRFS не настолько страшная штука, как ее описывают.

Не знаю, не использовал, как и ZFS. Однако, как показывает гугление, она пока более сырая, чем ZFS и чаще встречаются темы «Как восстановить данные?» именно про BTRFS.

Если десктоп, то можно взять и ее.

Что значит десктоп? Память серверная, с ECC, но остальное вполне обычное. Этот компьютер не сервер в привычном понимании. Вообще, если уж вдаваться в детали, зачем всё это, то это «кормушка» для нейронных сетей. Данные из большого хранилища обрабатываются, к ним создаются всякие меатаданные, что-то тестируется, пакуется, опять тестируется... и т.п. Потом отправляется на обучение НС, само обучение не на этой машине.

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

Облачное. Но там интернет не вот чтобы быстрый, не хочется туда-обратно все эти терабайты гонять.

ZFS на 8Тб (зеркало из двух дисков)

На данный момент диски по 6 ТБ (примерно 5.4 ТиБ) и их всего 5 штук.

Если десктоп - плакать и играть в пятнашки на BTRFS

Пока не понял, по какому критерию проходит разделение.

харды уже не торт, летят любые только в путь

И всё же, одновременный (и неожиданный!) вылет двух из трёх - крайне маловероятное событие.

Просадка по производительности будет заметна если есть с чем сравнивать.

Ну конечно, надо страдать с 100% i/o загрузкой, из которой 90% - езда головками ради рандомного чтения файлов по 50кбайт. Главное не знать, что может быть иначе.

BTRFS не настолько страшная штука, как ее описывают.

Не знаю, не использовал, как и ZFS. Однако, как показывает гугление, она пока более сырая, чем ZFS и чаще встречаются темы «Как восстановить данные?» именно про BTRFS.

Считаю должно быть гвоздями прибито где-нибудь на главной: Шишкин о BTRFS.

Держитесь подальше. А вообще солидарен с господином pekmop1024: HW RAID10, поверх него ext4 или xfs «по вкусу». Не надо переусложнять там где не надо. Все эти SW RAID / LVM от лукавого. Приспичит объем нарастить - новый RAID соберёте и на него переедете, дефрагментируетесь в процессе заодно.

ПыСы. Определенный «боевой» опыт имеется: пара десятков машинок в проде под жёсткой нагрузкой со storage примерно такого размера.

И всё же, одновременный (и неожиданный!) вылет двух из трёх - крайне маловероятное событие.

Чуть менее вероятное, чем то что при выходе из подъезда вы увидите кошку. А если однопартийцы, то вероятность повышается.

Главное не знать, что может быть иначе.

Я не могу вас понять, вы за «хренак хренак и в продакшен» или «ехать» топите?

срочная замена с горящей жопой

RAID 6/Z2 защищает жопу от возгорания. Вылетел диск - массив все равно защищен.

время ребилда массива на 10 - десятки минут, время ребилда на 5/6 - до 10 часов

Вот тут поясни. Ребилд все равно же лимитирован скоростью записи на новый диск и он будет одинаковым. Вот даже пруф есть: Как лучше хранить большой массив информации? mdadm / lvm / zfs / btrfs (комментарий)

Ну, daxoric128 , конечно, много пурги нанёс. Но резон в отдельном питании в принципе есть. Например, дорогие контроллеры стартуют диски по-одному. А дешёвые платы все диски сразу, получаем резкое потребление по току. Тут уж скорее процессор зависнет и диски не проинициализируются при недостатке питания. В этом случае могут быть полезны БП Chieftec серии A-135, у них 2 линии 12V, вроде бы незывисимые, однако каждая имеет только половинную мощность.

ZFS.

Чуть менее вероятное, чем то что при выходе из подъезда вы увидите кошку. А если однопартийцы, то вероятность повышается.

Ну, видимо у тебя были плохие диски. WD Red 4TB 10 штук все из одной партии, за 7 лет аптайма с нагрузкой ниче не сдохло. WD Green менее надёжными были. А сигейты вот часто дохнут вне зависимости от модели. «Дохнут» это разумеется не когда диск отвечать перестанет, а когда в смарте realloc появятся или ещё какие проблемы.

Я не могу вас понять, вы за «хренак хренак и в продакшен» или «ехать» топите?

За «ехать», если я правильно понял о чём речь.

Дискам мало что будет оставаться от чистого тока. У процессора мосфеты есть, а у дисков нету. Они доедают импульсы за ним.

Какая-то шиза.

как лучше организовать надёжное хранение большого объёма данных

надёжное

Конечно же ZFS.

Добавь еще один диск и собери 3xRAID1 в linear LVM. Вероятность того, что у вас накроются оба диска в паре так, что с них ничего не вычитать, ничтожно мала.

WD Red 4TB 10 штук

Простите за вопрос, но не могу не задать: «Это весь ваш опыт?»

reflink (внезапно)