Умеет ли OpenZFS добавлять в пул dRAID новые диски для расширения пула?

не рекомендуется пихать в один vdev много дисков макси-оптимальный 😏 вариант для raidzХ: 8+Х

С твоей точки зрения почему?

у dRAID ... на мой взгляд этот тип рейда еще сырой для продакшена, надо подождать когда код отшлифуют.

Как думаешь, в каком году это произойдет? 22/23/24?

а чо не по контроллеру на диск? 😏

Лучше бы конечно по контроллеру на каждый диск в пределах любого vdev одного пула, это было бы как в зеркальном vdev, но в raidz обычно дисков больше, поэтому по одному контроллеру на диск вероятно слишком затратно, это надо 9 контроллеров куда-то подключить для raidz3 из 9-и дисков, да еще хотя бы один на spare :)

Стало интересно, есть ли десктопные матплаты с 10 слотами под контроллеры и поддержкой ECC? Серверные недорогие матплаты бывают с 10 слотами под контроллеры? Хотя один у них еще обычно встроенный.

raidz практикуют.

Для работы с нагруженными СУБД? Кэшируют большую часть горячей инфы?

PS: тогда вероятно оптимальным конфигом raidz3 является vdev из 8-ми (5+3) дисков и 4-х контроллеров (по два диска на каждый контроллер). Причем один контроллер может обслуживать любое количество vdev любого количества пулов, но в пределах одного vdev не более двух дисков. Золотая середина конфига ? :)

А spare диски в ZFS пуле общие для всего пула, а не только для какого-то одного vdev?

А spare диски тогда нужно цеплять по одному к каждому из четырех контроллеров? Что тогда произойдет в случае отвала какого-либо контроллера? Диски отвалившегося контроллера будут заменяться на spare других контроллеров?

А что происходит в случае большого количества сбоев одного диска (возможно из-за помех, но диск то нормальный при этом)? Он тоже меняется на spare?

Может быть, spare лучше вообще не использовать для архивного сервера бэкапов (для которого отсутствие uptime в пределах суток вообще некритичен) тем более на raidz3 (где допустима полная потеря трех дисков, но ведь диски, бывает, вылетают из пула всего лишь временно до следующего импорта или даже команды online), просто мониторить его и принимать решение о замене той или иной железки вручную, чтобы избежать лишних замен и синхронизаций spare?

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

по поводу наших корзин:
это часть большой кластерной системы, работает это всё хозяйство на OpenVMS, так что там нет ZFS, и какая там ФС я ваще ниипу.
у меня есть фалопомойка для софта и бэкапов, вот там обычный raidz2 из 8 WD DC SATA дисков.

С твоей точки зрения почему?

ну.. могу пересказать своими словами то, что читал когда-то в блогах сотрудников Sun Microsystems.
раньше оптимальное количество дисков с данными для raidzN должно было быть кратно степени 2, т.е. 2,4,8,16...
посчитали что 16 это дофига, т.к. чем больше деталей в устройстве, тем выше шансы выхода его из строя.
ну вот из этих соображений и получилось что для raidz(1,2,3) максиоптимально делать vdev на 9,10,11 дисков соответственно.

Для работы с нагруженными СУБД? Кэшируют большую часть горячей инфы?

а почему нет, даже обычный DC SATA SSD это 70000 IOPS.
либо делают пулл целиком из SSD либо большой L2ARC.

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

Неужели контроллеры для архивного сервера так дороги в 2022 году? IMHO контроллер не дороже одного диска?

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

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

ну.. могу пересказать своими словами то, что читал когда-то в блогах сотрудников Sun Microsystems. раньше оптимальное количество дисков с данными для raidzN должно было быть кратно степени 2, т.е. 2,4,8,16...

Интересно, насколько это актуально для 2022 года и особенно для dRAID?

Если актуально, тогда raidz3 наверно стоит делать из 4+3=7 или 8+3=11 дисков в зависимости от возможностей?

По моей теории один контроллер в raidz3 должен обслуживать не более трех дисков, чтобы сохранить пул в состоянии raidz0 после сбоя одного из контроллеров и не более двух дисков, чтобы сохранить пул в состоянии (образно) raidz1. Тогда для варианта с запасом при деградации пула raidz3 из-за контроллера (образно) до raidz1:

Для случая 4+3=7 дисков достаточно 4 контроллера (IMHO вполне реально). Причем на одном контроллере можно ведь держать любое количество vdev, но не более 1-2 диска из каждого vdev пулов типа raidz3.

Для случая 8+3=11 дисков достаточно 6 контроллеров.

а почему нет, даже обычный DC SATA SSD это 70000 IOPS.

Слишком уж ZFS (из-за COW) подвержен фрагментации. Как вы справляетесь с ней? Регулярно дефрагментируете через send | receive (можно в фоне в периоды низкой нагрузки) на вторую железку?

либо делают пулл целиком из SSD либо большой L2ARC.

Такое я делал, действительно сильно ускоряет, но только после прогрева, хотя вроде появился persistent L2ARC, интересно, насколько он надежный? Для нагруженных СУБД используют persistent L2ARC?

ППКС.

Неужели контроллеры для архивного сервера так дороги

Ты наверное видел статистику по отказам HDD, которою публикует Backblaze?
А статистика по отказам контроллеров попадалась? Мне нет.
Так зачем покупать лишний контроллер если можно купить то что намного чаще ломается?

Можно узнать преимущества ленточек

Хз, не интересовался.

Интересно, насколько это актуально для 2022 года и особенно для dRAID?

Это давно пофиксили, но рекомендации до сих пор встречаются.
Про dRAID не в курсе, там совершенно другой аллокатор. У него могут быть детские болячки о которых ещё не известно.

Слишком уж ZFS (из-за COW) подвержен фрагментации.

Там речь про SSD шла. Насколько фрагментация ему мешает?

Там речь про SSD шла. Насколько фрагментация ему мешает?

https://superuser.com/questions/1325962/sequential-vs-random-i-o-on-ssds

Пишут, что и для SSD имеет значение.

Могу подтвердить из собственного опыта, что фрагментированный за полгода ZFS пул на Samsung EVO после дефрагментации читает данные при send | receive в несколько раз быстрее (примерно в 2-3 раза).

Т.е. повторный send | receive проходит в разы быстрее первого на том же оборудовании и соответственно показатели фрагментации пула (свободного места?) в zpool list сильно падают.

И это для нагрузки далеко не такой, как у СУБД. У меня обычные файлики документов, сорцов, копий веб страничек и т.п.

Думаю, ежедневно нагруженная СУДБ может фрагментировать пул значительно сильнее.

Твой опыт не про тот профиль нагрузки что создаёт база данных.

send читает данные последовательно, и натыкаясь на фрагментированные файлы скорость снижается даже на ssd(в 2-3 раза у тебя), но не так сильно как на hdd(в 100+ раз).

База данных читает данные рендомом почти всегда.
К тому же, современные субд - версионники, то есть почти как CoW работают.
И даже на классической ФС файл БД начнёт фрагментироваться.

но не так сильно как на hdd(в 100+ раз).

Пробовал базу данных IBM Db2 на ZFS поверх HDD, без L2ARC скорость последовательного чтения send | receive с фрагментированного базой пула очень низкая - около 1-5 мбайт в секунду. После подключения к пулу L2ARC на SSD размером примерно с базу данных, СУБД работает в десятки раз веселее, но прогрев кэша занимает пару часов после рестарта ZFS хоста. У СУБД еще есть и свой буферный кэш в оперативке, его тоже нужно прогреть. Вероятно сейчас с persistent L2ARC прогревать по крайне мере L2ARC кэш уже ненужно, если допустимо его использовать для баз данных?

К тому же, современные субд - версионники, то есть почти как CoW работают. И даже на классической ФС файл БД начнёт фрагментироваться.

IBM Db2 - современный блокировочник? Ему выгоднее использовать FS без COW? Тем более, что эта СУБД сама умеет проверять чексуммы хранимых данных.

IBM Db2 - современный блокировочник? Ему выгоднее использовать FS без COW?

хз, я с DB2 не работал.
Для современных СУБД навороченная ФС вообще не нужна 😏, т.к. они сами ведут журнал изменений.
Oracle и Firebird умеют БД размещать на raw-device, т.е. вообще без ФС.
Про PostgreSQL и MSSQL не в курсе, как и про DB2.

Для современных СУБД навороченная ФС вообще не нужна 😏, т.к. они сами ведут журнал изменений.

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

Накат бэкапа с WAL для такого возврата достаточно длительное удовольствие, а zfs rollback мгновенный, перезапуск базы со снэпшота еще минут 10-15.

Oracle и Firebird умеют БД размещать на raw-device, т.е. вообще без ФС.

Db2 раньше тоже умела, но в современных версиях IBM вроде бы собирается отказаться от database managed table space по крайне мере для пользовательских таблиц:

https://www.ibm.com/docs/en/db2/11.5?topic=management-database-managed-space

https://www.ibm.com/docs/en/db2/11.5?topic=data-table-spaces-without-file-sys...