Comments 75
Можно сказать, что в домашних условиях избыточность хранилища обычно и не требуется, поэтому самой подходящей конфигурацией RAID для SSD действительно становится RAID 0

В домашних условиях время доступа вообще в принципе не критично. А вот сохранность данных — наоборот. Очень обидно потерять винт, на котором например хранятся семейные фото лет за 10. Поэтому для дома для семьи — RAID1. И лучше именно на HDD — с коих в случае смерти хоть часть информации да можно спасти.
Когда помимо SSD в системе стояли HDD, то заметил одну особенность — HDD засыпает, и при обращении к нему происходит «фриз» всей системы на какое то время, поэтому от HDD в системнике отказался полностью в пользу SATA SSD а в дальнейшем m.2 на 1Тб.
В качестве файлопомойки стоит NAS с RAID 1 на 8Тб, при этом фоточки и прочие невосстановимые вещи синхронизируются с облаком (1Тб халявы), поэтому за сохранность данных не переживаю.
Скорость чтения с SSD по бенчмаркам 3200Мб/с, куда еще больше?
С файлопомойки через PLEX телевизоры в квартире воспроизводят видео, ресивер может брать музыку (да, я злостный пират и скачиваю всё к себе).
Теперь вопрос: зачем RAID дома еще и на отдельном аппаратном контроллере?
И да, по поводу спасения информации — SSD обычно переходят перед смертью в режим ReadOnly, по крайней мере у меня было так, но повторюсь, вся важная информация была синхронизирована в облако и на файлопомойку.
Теперь вопрос: зачем RAID дома еще и на отдельном аппаратном контроллере?

Ну во первых аппаратный — согласен не зачем. Хотя вопрос тупо в цене — если не дорого, почему нет. Нужен хоть какой. Хоть ручной (это когда руками на один пишешь, а потом на другой :) ).
А во вторых — не улыбается мне лить в облако личную жизнь. Не хочется делать ее достоянием общественности.
Ангела Меркель когда свои сиськи фотографировала — не знала поди что станет канцлером.
Как будто кто-то запрещает вам лить в облако шифрованные архивы
> HDD засыпает
У некоторых HDD это отключается, а для тех, у которых нет — просто ставится утилита, которая каждую, скажем, минуту, что-то пишет на диск.
Это старая обманка. Если речь идет 2х дисках, то вероятность отказа любого из пары составляет (допустим) 2% в год. Или 4% для всего массива. Оба показателя сравнимы друг с другом, нет причины как-то особенно беспокоиться. Особенно если учесть, что даже если объединить их в зеркало, то, хотя вероятность отказа всего массива составит уже всего 0,04% в год, при отвале первого второй скорее всего уже рядом с ним, и вероятность двойного отказа вырастет на порядки. Плюс прибавляются риски отказа самого контроллера или даже всей машины (а аналогичную пойди поищи). То есть сохранность особо не повышается, зато проблем прибавляется. Бэкапы никто не отменял. Райд это не средство повышения отказоустойчивости, а средство снижения времени простоя. По факту в домашних сценариях что с райдом, что без него ситуация с потерей данных по причине отвала оборудования примерно одинаковая. Вот если RAID1 сделать на 4 диска, да на популярном надежном аппаратном контроллере, то тогда да, можно получить параноидальную надежность и не париться о надежности дисков вообще, только менять их иногда по очереди. Но беда в том, что популярные потребительские контроллеры не позволят объединить 4 диска в зеркало. Максимум, позволят сделать зеркало из двух страйпов. Поэтому простой бэкап на съемный диск, который хранится на полочке, с точки зрения сохранности данных намного лучше, чем зеркало (а два таких диска в разных местах и подавно). При том что стоят дешевле и мороки меньше. Не стоит использовать зеркальный райд для дома, если нет объективных причин (например, заведомо ненадежные диски, хотя их такое желание само по себе очень странно).
Это старая обманка. Если речь идет 2х дисках, то вероятность отказа любого из пары составляет (допустим) 2% в год. Или 4% для всего массива


В бытность мою сисадмином то ли 2 то ли 3 раза сталкивался:

После помирания первого диска в RAID второй помирает за считанные дни. Пока подпишешь у директора, пока закажешь, пока приедет диск и вот уже всё, вон она — встреча ягодичных мышц, в просторечии "… опа".

То ли это нагрузка на оставшиеся диски возрастает.
То ли это закон Мэрфи.

Но после второго такого случая я уже не верю ни в случайность ни в эти ваши оптимистичные цифры статистики.

Поэтому диски для массива надо брать из разных партий, а еще лучше от разных производителей. Когда берешь у одного продавца несколько дисков одинаковой модели, есть большая вероятность что они будут из одной партии. Диски из одной партии с большой вероятностью умрут одинаково, т.к. производились, транспортировались, хранились и эксплуатировались в одинаковых условиях.
Так себе идея. Лучше просто купить запасных и менять их до истечении гарантии (уж ее-то они обязаны отработать).

В RAID-5/6 после выпадения диска нагрузка сильно растёт. Захотели прочитать страйп с данными -> его больше нет -> читаем все страйпы этой строки и восстанавливаем отсутствующий кусок через контрольную сумму. В том числе по этой причине уже давно считается дурным тоном 1) строить RAID-5 из больших по объёму дисков (строгой границы нет, но в большинстве случаев это >1 ТБ, куда попадают все 7200 об/мин диски) 2) строить длинные дисковые группы, больше 10-12 HDD из сплошного RAID-5/6. Надо длиннее — разбиваем на кусочки и делаем RAID-60.

вероятность двойного отказа вырастет на порядки.
[citation needed]

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

Поэтому простой бэкап на съемный диск, который хранится на полочке, с точки зрения сохранности данных намного лучше, чем зеркало
Он хуже тем, что съемный диск надо руками регулярно перетыкать. Пользователь забивает >> метод не работает.

например, заведомо ненадежные диски
Ну так, заведомо надежных не выпускает никто :)

например, заведомо ненадежные диски


Ну так, заведомо надежных не выпускает никто :)


Вполне себе выпускают
QLC называются.

На сегодня если хотите диск понадежнее — имеет смысл брать предыдущего поколения, на TLC (на SLC конечно уже не найти, да и в поколении SLC контролеры еще так себе, но вот у TLC контролеры уже отлажены). Там объемчик поменьше, да и диск не дешевый — но заведомо надежнее.
Нагрузка околонулевая, но после обнаружения развала массива вы, скорее всего, заходите его перестроить со 100% загрузкой диска на много часов.
В традиционных RAID-ах «старая» математика.
Она распределяет нагрузку равномерно, следовательно и диски «ложаться» практически одновременно. Перестроение рэйда, при современных объемах, это боль.
В идеале, новая математика должна осуществлять неравномерный износ дисков, что бы их можно было менять по одному, и иметь «на борту» один-два SSD, что-бы на момент перестроения не деградировала производительность. Ну что-то среднее между ZFS и нютаниксом. Ждем-с.

Выравниванием износа, помимо прочих задач, занимается контроллер самого SSD.

Я делаю так: прежде чем объединить накопители в зеркало, беру один из них и запускаю на ночь-две цикл «запись-удаление-запись». При этом, судя по показаниям фирменной утилиты, удаётся понизить ресурс накопителя на несколько процентов. По-идее, это должно решить проблему синхронного выхода со строя обоих накопителей.

По моим наблюдениям (статистика обращений по гарантии и техподдержке почти за 10 лет, серверы и СХД) все эти опасения насчёт одновременного выхода из строя являются чем-то вроде старой городской страшилки. Это было с HDD и доходило до рекомендаций ставить в большие массивы диски непременно 3–4 разных моделей и от разных вендоров (!). Определённые основания такой фобии есть, они связаны с массовым отказом определённой моделей. Но, во-первых, последний очень громкий и действительно массовый случай был с Барракудами 7200.11 и это было 10 лет назад, во-вторых — не надо под серьёзный production собирать массивы из бытовых дисков, и в-третьих — не надо забывать про аксиому «RAID ≠ бэкап».
Видимо с годами эта фобия перекочевала на SSD, но тут на практике вообще ничего не подтверждается. Да, SSD мрут, в том числе и серверные, и любых вендоров/моделей (есть обширная статистика Intel, Micron, Samsung, HGST, Toshiba), но за 10 лет я ни разу не наблюдал этого мифического случая «одновременного износа».

Ссд от износа не умирают, вот вообще никак. Просто контроллер в какой-то момент такой хлоп и всё диск исчез. От износа мрут забитые под завязку флешки, т.к. там контроллеры не болтают данные для равномерного износа а затираются до дыр свободные ячейки.

у Synology для этих целей используется некий raid F1
сам не пользовался только как ключевые слова для посика

Там всё просто на самом деле. Это тот же RAID-5, но со слегка нарушенной очередностью записи страйпов и контрольных сумм. Выбирается один из накопителей и на него добавляется +1 запись контрольной суммы вне очереди. Из-за такой побочной штуки, как write-penalty (пишем что-то в RAID-5 с размером меньше полного страйпа — получаем необходимость пересчитать и записать новую контрольную сумму), на этот накопитель приходится большая нагрузка на запись. По достижении определённого износа выбирается следующий SSD и так далее.
Я ни разу не наблюдал на практике подтверждения этой фобии равномерного износа (см. выше), а вот минусы этого подхода есть — этот RAID-F1 является проприетарной надстройкой Synology над mdadm, т.е. в случае чего абы где массив не поднять.

Программные RAID-контроллеры уступают интегрированным и аппаратным по производительности и отказоустойчивости

Похоже статью писали без участия технических специалистов

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

Как раз, чтоб при установке того же centos использовать рэйд — это всего одна галочка.
А железный рэйд даже просто включить — много чего понимать нужно.


Железный мощнее однозначно, но проще — вряд ли.

Ну этот холивар длится уже не первый год. Есть и там, и там, плюсы и минусы.
Этот холивар закончился пора было закончить с появлением ZFS. В 2019 г. нет ни одной веской причины связываться с аппаратными контроллерами, писанными левой ногой темными индийскими ночами проприетарными прошивками и прочими сопутствующими «радостями». Какое же счастье, что весь этот ад остался в прошлом.
Ну там вроде еще батарея делает свое дело на случай внезапного отвала питания. Хотя использовать машину, чувствительную к потере данных, без хорошего бесперебойника, это откровенное раздолбайство.

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

UPS никак не отменяет необходимость защиты любой отложенной записи в RAM-кэшах или отключения кэширования записи, так как кроме проблем с внешним питанием можно получить выход из строя блока питания. Дублирование блоков питания не всегда спасает, ведь есть ещё платы распределения питания, которые тоже мрут.
Так что защищаем write-back кэш контроллера батареей (на современных контроллерах вместо неё ионисторы+запись на флеш); применяем правильные SSD с защитой собственного RAM-кэша конденсаторами; отключаем кэширование записи на HDD.
P.S. И, кстати, если зашла речь о связке «аппаратный RAID + SSD», то стоит учитывать тот факт, что для all-flash томов на контроллерах от Broadcom и Adaptec максимум производительности обеспечивается без write-back, т.е. и защищать кэш контроллера в такой конфигурации не нужно.

Сам обратил внимание )
Производительней то понятно, а вот по отказоустойчивости ситуация, скорее, обратная.


Глюков mdadm не припомню.
Зато с разными рэйдовыми картами проблем было достаточно.

Не являюсь специалистом по RAID, но неплохо осведомлен о цикле проектирования ASIC. И смею предположить что проблемы с хардверными решениями таки на самом деле обусловлены проблемами драйверов и прошивок. То есть опять таки — софта.
Просто прежде чем запустить в тейп-аут ASIC — его верифицировать могут пару лет. Там ошибки очень дорого стоят.
А касательно производительности — ничто программное не может быть производительнее аппаратного (если мы не говорим о крайних случаях когда Вы на Xeon считаете то, что до этого делал ASIC 10-летней давности).

Я без понятия про ASIC.
Но когда в рэйд-карте дохнет конденсатор, то врядли тут дело в софте.
И просто на слух случаев саморазбора железных рейдов в разы больше, чем от mdadm.


У каждого, конечно, своя статистика...

Но когда в рэйд-карте дохнет конденсатор,

У Вас с тем же успехом может сдохнуть конденсатор на материнской плате или в блоке питания. Вероятность примерно такая же.
«Проблемы» — это когда у Вас в чипе в железной логике ошибка, к которой патчик не выпустишь.
Ну и понятно наверное что для серьезных применений нужно брать поделки от Tier1 производителей, а не с Али.
Ну и если говорить конкретно от конденсаторах — какой? Как сдох? Электролиты и керамика обычно дохнут из-за производственного брака — электролитам гнут ноги при монтаже и они закипают, керамика трескается, танталовые мрут — от ошибок в дизайне, так как чувствительны к малейшему превышению напряжения. Я к тому что это просто в принципе проблемы железа как такового а не RAID карт как класса устройств.

Собственно, я всего и сказал, что софтовое решение лишено недостатков железного, а не наоборот, как в статье.


Всё остальное вы сами себе додумали, мне это вообще не интересно.

Софтовое решение крутится на железе а не в воздухе. Поэтому аргументация — сдох конденсатор на карточке — и является слабой.
Не более того. Ваш афигенный Soft-Raid вполне себе успешно рухнет, из-за того что китаец плохо проверил Вашу конкретную серверную плату на производстве.
У железных решений всего два недостатка:
1. Их нельзя улучшать.
2. В них нельзя исправлять ошибки.

Есть третий. Программный рэйд можно восстановить на другой машине с другим железом. А аппаратный только на том же железе, и может быть даже только с одной и той же ревизий железа.

Ну как бы не совсем так. Главное, чтобы заменяемый контроллер не был предыдущего поколения. На таком же или более новом импорт конфигурации проходит безболезненно. Хотя safe config да и вообще snapdump никто не отменял, для рачительного админа — это как зубы чистить два раза в день, must have. Хотя бы периодически.

Вот по-этому на полке должен лежать запасной RAID-контроллер такой же модели.

Может быть, может нет, мне всё равно.
Я вообще об этом не говорил, вы опять сам с собой спорите.

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

Полностью подписываюсь. Блоки конденсаторов, защищающие кэш, умирают крайне редко. Имею статистику в силу специфики работы. Батарейки BBU — да, но на то они и батарейки. У них рекомендованный срок службы 1 год. У конденсаторов гарантия — 3 года.

В большинстве железных рейдов до 1k$ софт написан индусами за еду, с соотвествующим качеством

Ну кто и за что пишет софт, вам возможно виднее. Так-то у нас полстраны за еду работает. А индусы, кстати, вполне себе толковые ребята. А если по делу — допиливание софта, bugfix — абсолютно нормальный процесс. Главное своевременно реагировать на косяки в случае их возникновения. Если посмотреть на историю выхода релизов прошивок, драйверов и управляющего софта — сразу увидите, насколько регулярно все это выходит. А особо внимательные ещё и release note читают, чтоб понять, что именно пофиксили

mdadm на ssd дисках уже более 5 лет в разных проектах использую. Проблем никаких. А вот аппаратные контроллеры живут в среднем 5-7 лет (по крайней мере в моем парке), чаще всего вздувается батарея, потом идёт отказ контроллера, ну и другие проблемы есть.

Батарея — расходный материал. Вы же не выбрасываете принтер, когда тонер заканчивается. Кстати, срок жизни батареек можно регулировать — у них есть 5 режимов в зависимости от температуры окружения и retention time. В самом щадящем режиме BBU может прослужить до 5 лет. У меня в парке некоторым контроллерам по 7-8 лет, пашут как часы. Да, они лохматого поколения 6G, но свою заявленную производительность показывают.

Согласен! Всегда считал, что контроллеры бывают аппаратные и программно-аппаратные(fake). А тут эвона как…
Очень не хватает тестов. Сделайте тесты, в первую очередь интересует сравнение программного RAID (md) с аппаратным RAID различного класса и стоимости (для HDD, SATA-SSD и NVME). Мне было бы очень интересно посмотреть.

С софтовыми RAIDами как-то не приходилось работать. По аппаратным есть рабочие тесты для RAID разного уровня с разными видами накопителей — от SAS/SATA хардов и SSD до NVMe. Но это немаленький массив таблиц. Если автор заинтересуется в продолжении рассказа, буду готов поделиться.

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

Делал в свое время такие тесты. Результатов уже не сохранилось правда. Итог был, аппаратный рейд нужен только для 50 или 60 если у тебя куча дисков.


Для 0 и 1 нафиг не нужен.

TL;DR
>Нужно ли создавать RAID-массив из SSD
— Кстати, а вы вообще знаете что такое RAID?
— Кстати, а вы знаете чем SSD отличается от HDD?
— Возвращаясь к вопросу… мы поговорим о нём в следующей статье!

Кингстон, какого чёрта?!
Нет самого главного: описания того, как работает TRIM на SSD в raid-массивах, какие SSD и контроллеры нормально это отработают.

TRIM выполняют только HBA в IT режиме, на MegaRAID трима нет, там другая фича недавно появилась — Unmap

По-этому, создавая RAID-том на SSD, я оставляю 10% не используемого пространства (на уровне RAID-контроллера). В таком случае алгоритмы равномерного износа должны работать нормально.

Никакие =) Поэтому и нет этого в статье.
Поэтому, если ставить SSD в железный рейд, то нужны интерпрайз-версии, которые сильно дороже и обычно ограничены объемом — именно потому, что реально там еще процентов 50 выделено для работы внутренних алгоритмов очистки, которые еще тоже неизвестно как работают.


Есть огромный соблазн воткнуть консьюмерские SSD — и оно будут работать так же. Но недолго, и потом внезапно обнаруживаете, как ваш быстрый сторадж стал улиткой с потолком на запись в районе 30мб/с при любых нагрузках.


Хотя должен сказать, что по нашему опыту консьюмерские samsung 850 evo pro очень хорошо себя показывают даже в железном рейде. Не знаю с чем это связано, но факт — например, тошибы "летели" десятками, а гнусы работают в разы дольше под теми же нагрузками.


Но железные контролллеры принципиально не способны решить эту проблему с ssd.
Поэтому никакого смысла сегодня ставить железные я не вижу. Ну только если у вас сервер на винде или на чем-то подобном экзотичном, где нет ZFS. =)

Перед тем, как ставить бытовые SSD в железный RAID, можно посмотреть обзоры по моделям и узнать, что довольное большое количество SSD умеет в TRIM само, в свободное время, без внешних команд.
У нас 850 и 860 собраны в HP MSA P2000 в RAID 50. И очень, очень жалко, что следующие поколения MSA перестали поддерживать SATA :(
большое количество SSD умеет в TRIM само

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

Но сборка мусора без TRIM — это медленно и малоэффективно, после того как диск хотя бы пару раз был перезаписан полностью, он ощутимо (и навсегда, по крайней мере до TRIM) замедляется, особенно если постоянно нагружен. В домашних и прочих похожих условиях это может быть и незаметно, а вот на на серверах — ещё как, в одном известном мне случае (SATA RAID1, какой-то MegaRAID) скорость упала с изначальных 450M/s до примерно 200 MB/s, iops тоже просел — и это всего после некольких записанных терабайт.

У нас аж с 2013 года стоят intel s3700 (8шт) в raid-10. Контроллер — «железный». Тьфу-тьфу, до сих пор всё работает. Дохли, по-моему, только более новые s3710.

Зашёл почитать нужно ли создавать raid ссд. Прочёл кучу воды, а ответа не получил.

Бред-то какой!
Вам быстро в космос — делайте на ssd. Подешевле и побольше — на традиционных hdd.
Цена за гигабайт против скорости доступа.


Рейд однозначно нужен: элементарное зеркало на intel (читай софтовый) или на mdadm спасало, спасает и будет спасать.


А статья… Понятно, что аудитория на Хабре малость… Жиже стала, но все же не на столько же жиже?.. или на столько?

Вам быстро в космос — делайте на ssd.

А вот фиг. Где-то были тесты (влом искать) что на программных и встроенных (читай тоже программных) райдах скорость обсчета райда центральным процессором сравнима со скоростью приличного SSD. Поэтому значительны прирост скорости можно получить только на неприличных SSD. Ну а самые быстрые к PCIe коннектятся, читай к ЦП напрямую, там райд городить тем более странно.
А вот фиг… на программных и встроенных (читай тоже программных) райдах скорость обсчета райда центральным процессором сравнима со скоростью приличного SSD.… Ну а самые быстрые к PCIe коннектятся, читай к ЦП напрямую, там райд городить тем более странно.


Эм. Дело не в том, с какой скоростью у вас считает контроллер. Вернее не совсем в этом.
Начнем с начала (мы говорим только о домашнем применении):
1. Диски могут подключаться или по шине типа SATA\SAS или по PCI-e.
2. Диски могут быть мехиническими (скорость шпинделя и количество пластин) и твердотельными (линейная скорость доступа зависящая от %% заполнения)

Внимание вопрос: как у вас на плате разведены те самые SATA\SAS и PCI-e? Нет ли там узких мест, где, скажем, несколько линий SATA через чип-посредник подключаются к основному системному мосту? Может быть у вас PCI-e линий меньше чем устройств их потребляющих и идет борьба за время доступа к ЦП?

Т.е. дело даже не в том, что ваш центральный процессор через кучу прослоек и драйверов рутил Input и Output запросами для файловой системы и физических устройств.

Когда у вас аппаратный рейд, скажем на 4 устройства записи, то вопрос как он подлючен ко всей системе. Я знаю карты, у кторых эффективно отдается 6 Гб\с, а на устройство идет всего 3 Гб\с. Я так же знаю карты, у кторых 6 Гб\с на карту и по 6 Гб\с на устройство. Это я пишу все к тому, что «в лоб» не получится сказать что «будет быстрее или медленнее». Однозначно можно сказать, что твердотельники, даже самые плохие почти во всех вариантах RAID будут опережать классичиские диски по количеству обработанных I\O в единицу времени.

Но я писал про другое: я говорил, что массив нужен так как позволяет защититься от потери носителя информации, или, по крайней мере — дать время на его замену. Я не говорил, что, скажем, программный RAID5 на SSD будет быстрее RAID5 на HDD в Х раз. Хотя, поросто поверьте — он будет.

Я говорил что если вы работаете с информацией, которую хотите защитить и вам критично время доступа к ней, то тогда SSD. А если вам нужно надежно храниить много информации скорость доступа к которой не очень важна, то выгоднее брать HDD.

З.Ы. Я построил не один и не 2 массива как на «подножном» железе, так и в прохладных залах ВЦ. Удивительно, если бы все было так просто, почему же появились «диски» построеннные на RAM чипах? И за эти бабки их еще кто-то покупает и даже делает из них volum`ы.
Кстати, друзья без mdadm: вот у нас есть кеш в 2 Гб на контроллере рейд. Правильно ли отключить io scheduler (выставить none) в системе, дабы контроллер сам упорядочивал данные как надо? В случае с mdadm у меня вопросов нет: тут гений ентерпрайз-хранения не вмешивается в мой поток данных, и io scheduler я настрою согласно потребностям конкретной машины…
Мде. Думал тут тесты будут — вот вам синтетика, вот вам реальные приложения. Вот вам выводы (берите SSD, желательно NVMe; RAID не для сервера не нужен). А тут вода, вода, одна вода. Спасибо что рассказали нам про типы RAID контроллеров и уровни RAID массивов. В статьях 20 летней давности про RAID примерно то же самое можно прочитать.

Классная рекламная статейка без единого замера. 10 ссд быстрее лошади, а 10 лошадей быстрее вилки. Битовый поток рейдмассива из 100 нвме ссд превысит третью классическую и сервер улетит на луну.
П.с. а чтобы ещё больше ускориться надо поставить рейд в рейд. Начнем с того что любой ссд с количеством флешчипов больше одного рейд сам по себе.

у нас на продакшене PRO-версия nvme-шек от самса вылетела через полгода использования. Зеркало спасло данные.
А так всё что TLC, QLC — это там где не нужны скорость и надёжность. SLC можно найти без очереди, но если MLC стоит на пол порядка дороже, то SLC на все два.
В начале автор упоминает ПК-боярина (которому, всё это на самом деле очень интересно), но в конце не уточняет, что расчёты для Raid 0 он приводит для «идеальной», т.е. серверной загрузки (многопоточной и длинные очереди) контроллера данными. Чем ещё более отдаляет от данной темы бедного ПК юзера. И ещё, автор наверняка помнит, что запросы-то на те самые iopsы исходят от ЦПУ. В боярских же (домашних) нагрузках это чаще всего именно однопоточная ЦПУ-задача. И не далеко не всем известно, что именно из-за неё, например, рамдиск на ЦП от Интел очень скоро упирается в некий потолок /какие дисковые задачи ни крути/ — уже на уровне 13 ГБ/с (интересно, причина этого в КП? Раз этот предел у меня практически не изменился после смены платформы с 2011 с DDR3 на 2066 с DDR4 и ЦПУ с i7-3930k на i9-7920x). Так что, мечты выжать практический максимум из raid 0 на nvme дисках начинают стремительно таять уже после 4+ дисков класса 970EVO/PRO.

Рамдиск это по сути копирование, а как мы знаем, эффективная пп ддр3 и ддр4 мало отличается изза задержек, которые при копировании складываются и сильно режут. Ведь реалтаймовый л1 кеш всегда линейно повышает скорость вместе с частотой.

Статья начиналась за здравие, а кончилась никак. Где графики сравнения производительности, надежности, стоимости описанных решений? Что за вода в блоге компании-производителя?
+10500, где тесты? Что в реальности дает этот контроллер с четырьмя NVME накопителями уровня КС2000? Народ в сети пишет, процессора ложаться, 20 ядер загружено на 100%…

P.S. Про TRIM в RAID. Проще считать что его нет, и разметить тома не используя 20% емкости SSD.
Данная тема действительно заинтересовала аудиторию, тесты в планах. При использовании RAID контроллера, основная нагрузка ложится на плечи самого контроллера, процессор не нагружается сильно. Без контроллера, действительно могут наблюдаться подобные ситуации.
Only those users with full accounts are able to leave comments. Log in, please.