From: Sergey Matveev
Date: 2026-07-07 12:53:04Z
*** "Алексей" [2026-07-07 13:28]:
>А почему вообще кто-то до сих пор использует аппаратные RAID-контроллеры,
>когда уже давно есть софтверные?
20+ лет назад я задавал точно такой же вопрос. И думал, что аппаратные
RAID-ы нужны были только потому что CPU не мог прожевать все эти объёмы
данных на лету. Уже к концу 2000-х это было не так: CPU достаточно
мощные, чтобы на них можно было несколько десятков дисков в RAID6
многоуровневых массивах держать. И не понимал зачем нужны аппаратные
(стоимость CPU меньше чем аппаратных умеющих RAID6, который дорогой).
Позже я узнал про "write hole" и понял зачем нужны *хорошие* дорогие
RAID аппаратные: в них есть или аккумулятор, или суперконденсатор. Если
у нас зеркало и мы пишем stripe (а это много секторов диска для записи),
то контроллеры делают это параллельно на оба диска (иначе бы скорость
записи упала в два раза относительно одного диска). Очевидно, что
одновременно запись там закончится не может. Что будет когда произойдёт
сбой? Пропажа питания, потеря контакта, hard-reset, whatever? Мы получим
stripe, в котором данные на двух дисках отличаются. Как понять какой из
них актуальный (точно записанный), целостный? Или в RAID5, где у нас два
независимых друг от друга блока, да ещё и третий с XOR от них? Никак
этого не понять. Мы получаем битые данные, "потерянный" stripe. В теории
хорошие RAID-ы хранят состояние записи и помнят что должно было быть
куда записано и в случае потери питания могут дозаписать потом. Либо
держат stripe+state в RAM, питаемой от аккумулятора, либо сбрасывают из
неё в flash память (для чего хватит заряда конденсатора).
И вот статья говорит о том, что их RAID-ы забывают конфигурацию после
потерь питания. Что, как бы, весь их теоретический смысл сводит на нет.
Зачем их использовать тогда? У меня нет ответа. Пару лет назад спрашивал
одних админов на этот счёт: им просто так привычнее. Ну а то, что
целостность может быть нарушена -- они просто закрывают на это глаза,
признают что это так.
Где-то я видел, что только в конце 2010-х в Linux mdadm появилась
возможность сохранять аналогичный state последней записи на отдельном
блочном устройстве. Если бы это был SSD, то тогда и просадки по скорости
бы не было, что годное решение. Это появилось в Linux лишь относительно
недавно. Прежде mdadm (как и аналоги в *BSD) не смогли бы сравняться с
RAID-ами с аккумуляторами/RAM/SSD *в теории* (на практике -- мы просто
верим на слово vendor-ам).
Смысл всего этого при наличии ZFS -- вообще нулевой.
>По поводу NVMe в RAID - они сослались на две свои статьи 2021 года, где
>рассказывали, что при сборке NVMe дисков в RAID их скорость становится как
>у SSD. Не знаю, поменялось ли что-нибудь с тех пор: [...]
Ну когда там речь про Windows, то я бы дальше вообще не продолжал читать
эти статьи. Там бутылочным горлышком может быть всё что угодно (в софте).
Если бутылочное горлышко в контроллере -- ну или "слабый" контроллер
(+PCIe), или, действительно, очень быстрые NVMe, забивающие PCIe lane-ы
вусмерть. Но если NVMe деградирует до уровня "обычной" SSD, то это
чересчур огромная разница и значит контроллеры просто не приспособлены
для NVMe нагрузок.
Как только мы начали распределять виртуалки по NUMA-нодам, внезапно
всё заработало с нужной скоростью.
Я вот не сисадмин, с железом давно не "работал", но даже я понимаю (с
2000-х годов, когда с этим имел дело), что первым делом нужно
обязательно уметь "рассредотачивать" софт по NUMA нодам, как и PCIe
железо. Это же касается и сетевых карт и даже просто userspace задач
тяжёлых вычислительных. Я легко поверю, что большинство сисадминов не
понимают этого (низкая квалификация) и это, в том числе, объясняет и
продолжающуюся у них любовь к привычным для них аппаратным RAID. Звучу
наверняка высокомерно тут, но с чистой совестью всё это говорю, ибо я
слишком часто встречался что люди не учитывают подобные важнейшие нюансы.
Аж бесит :-). Поверю что аппаратных RAID-ов не сделали на тот момент для
NVMe -- намёк на то, что делать это надо на software уровне.
>> при небольшом количестве дисков RAID 6 оказывается надежнее
>> при увеличении количества дисков RAID 10 выигрывает в надежности
>
>Мне пришлось спросить Википедию, чтобы вспомнить отличие RAID 10 от 01, и
>она говорит, что RAID 10 - это RAID0 (striping) поверх пар дисков, где
>каждая пара - свой RAID1 массив (mirror). Соответственно, идея автора
>статьи в том, что в RAID 10 массиве из 8 дисков могут погибнуть три, если
>они будут в разных парах. Но сколько дисков на самом деле можно вставить в
>один сервер и объединить в один массив - не знаю.
RAID10 из 8 дисков это значит четыре RAID1 массива (по два диска),
объединённые в stripe. Это значит, в принципе может вылететь четыре
диска: по одному из каждого RAID1 (под)массива. Потеря в месте: 2x.
Но если вылетит два из одного RAID1 -- всему конец.
Если сделать RAID60, то это будет два RAID6 массива из 4-х дисков,
объединённые в stripe. Может тоже вылететь до четырёх дисков суммарно.
Потеря в месте: 2x. Но какова вероятность того, что 2+ диска вылетят в
одно RAID6 подмассиве? Ниже, чем вылет полного RAID1 из четырёх в RAID10.
Все эти "конфигурации" RAID-ов это сплошные компромиссы и обмены
потерянного места, производительности и вероятности отказа доступности.
Если взять один RAID6 на 8 дисков, то да, в нём только два диска могут
вылететь, тогда как в RAID10 -- четыре. Но при этом и потерь места в
таком RAID6 будет меньше (1/4 места, против 1/2). Сравнивать RAID6 и
RAID10 с большим количеством дисков: нечестно, так как надо сравнивать
RAID60 с RAID10, тогда уж, который будет надёжнее.
>Плюс для них ещё и скорость важна: [...]
Тут да, RAID6 будет медленней. Они разменивают надёжность на
производительность.
Я не хочу сказать, что они (он, автор) делают полнейшую глупость. Но
мне не нравится то, что если так часто упоминают заботу о надёжности,
потери данных, и всё такое прочее, то это идёт в диссонанс в принимаемым
решением, где оказывается, что всё же они готовы пожертвовать
надёжностью/доступностью (поверю, что её всё равно может быть
достаточно), чтобы получить выше производительность. Даже software NVMe
RAID1 на основе mdadm (без батареек и прочего) был бы лучше, чем его
отсутствие. Но они решили вообще не делать отказоустойчивый NVMe в
принципе. Я даже для себя, для домашнего использования, не позволяю себе
такого. Но по мне, так у них параллельный мир и непонятное мировоззрение,
раз там вовсю используется Windows, судя по статьям.
Очень часто многие предпочитали (или до сих пор?) RAID10 RAID6-му,
только потому, что аппаратные RAID-ы не справлялись с ним, тупо медленно
работали, так как RAID1/10/5 не требует никаких вычислений (XOR можем не
считать), тогда как RAID6 это тяжёлый Рид-Соломон или подобное. Люди
просто упирались в ограничение контроллеров, которые были бы заметно
дороже с нормальной поддержкой RAID6. И тут встаёт выбор: существенно
большая цена или же прикидывание вероятности вылета дисков RAID10 так,
что он полностью ляжет. Многие готовы смириться с не столь хорошей
вероятностной надёжностью RAID10 по сравнению с RAID6, зато существенно
более дешёвой.
Но с ZFS-ом вообще все эти разговоры просто уходят в небытие :-)
From: "Алексей"
Date: 2026-07-08 11:31:34Z
Большое спасибо за пояснение про аппаратный RAID!
Согласен с тем, что надо сравнивать RAID'ы с одинаковым количеством дисков
(и рабочих, и "избыточных"). Это я был не прав. В таком случае, конечно,
RAID6 лучше, чем 10.
Пишут, что ZFS поддерживает уровни до RAID-Z3, выдерживающий потерю трех
дисков. Но если рассматривать потерю 4 дисков в 8-дисковом массиве (что
означает потерю всего RAID-Z3 массива), то вероятность того, что RAID 10
массив выживет (все потерянные диски окажутся в разных парах) составляет
всего 23%. При этом потеря трёх случайных дисков (что не смертельно для
RAID-Z3) означает потерю всего RAID 10 массива в 57% случаев!
Не знаю, конечно, как RAID-Z3 скажется на производительности, не имею
достаточно ресурсов, чтобы это проверить.
Вообще было бы интересно, если бы провайдеры предоставляли возможность
выбирать уровень надежности для создаваемых ВМ (и, соответственно, цену за
Гб). Правда, указывать разный профиль RAID для разных образов ВМ - это
скорее фича btrfs, чем ZFS - а там RAID5/6 официально не рекомендуется.
From: Sergey Matveev
Date: 2026-07-08 12:46:24Z
*** "Алексей" [2026-07-08 13:16]:
>Пишут, что ZFS поддерживает уровни до RAID-Z3, выдерживающий потерю трех
>дисков.
Всё так. RAID-Z3, -Z2 в первую очередь предполагаются для использования
с большим количеством дисков, с созданием большого количества подмассивов.
Сотню дисков поделить например на 10 подмассивов -Z2 или -Z3, как то так.
Один массив на -Z3 -- вряд ли имеет смысл, ибо уж слишком низкая
производительность будет. За счёт strip-а из большого количества таких
массивов, мы получаем годную производительность.
>Не знаю, конечно, как RAID-Z3 скажется на производительности, не имею
>достаточно ресурсов, чтобы это проверить.
IOPS-ы в RAIDZ будут как у одного диска (большое отличие от не ZFS
RAID-ов). Последовательная запись/чтение: соотносится с кол-вом не
"parity" дисков. http://www.stargrave.org/Articles/ZFSProscons.html --
табличка в конце. RAIDZ это не равно сильно RAID5 или 6, а всё же более
медленно, как правило. Плюс всё сильно зависит от конкретных режимов
работы: если там размещать образы виртуальных машин с размером блока в
8KiB, то потери места будут огромными. С ZFS всё не так просто, нет
однозначного ответа что будет, без знания что именно и как там будет
выполняться. Если кому то важна производительность, то нужно делать
много -Z2/-Z3 и объединять в большой stripe, чтобы линейно увеличивать
IOPS и скорости чтения/записи. Это всё для жирных setup-ов :-)
>Вообще было бы интересно, если бы провайдеры предоставляли возможность
>выбирать уровень надежности для создаваемых ВМ (и, соответственно, цену за Гб).
Было бы не плохо наверное. Мне не приходилось пользоваться подобными
услугами, поэтому вообще не знаю как и что они там предоставляют :-)
>Правда, указывать разный профиль RAID для разных образов ВМ - это
>скорее фича btrfs, чем ZFS - а там RAID5/6 официально не рекомендуется.
Думаю, вы перепутали. В ZFS то как-раз проблем с RAIDZ нет никаких. А в
btrfs даже (аналог) RAID5 официально не рекомендуется, ибо плохо
работает. В нём по сути есть либо зеркало, либо stripe (ну и
соответственно возможность делать stripe из зеркал). Я поэтому считаю
btrfs ФС для домашнего использования в лучшем случае. ZFS то ещё с
2000-х вовсю трудится в hardcore enterprise где сотни сотни дисков даже
в одном pool.