Комментарии 75
Можно сказать, что в домашних условиях избыточность хранилища обычно и не требуется, поэтому самой подходящей конфигурацией RAID для SSD действительно становится RAID 0
В домашних условиях время доступа вообще в принципе не критично. А вот сохранность данных — наоборот. Очень обидно потерять винт, на котором например хранятся семейные фото лет за 10. Поэтому для дома для семьи — RAID1. И лучше именно на HDD — с коих в случае смерти хоть часть информации да можно спасти.
В качестве файлопомойки стоит NAS с RAID 1 на 8Тб, при этом фоточки и прочие невосстановимые вещи синхронизируются с облаком (1Тб халявы), поэтому за сохранность данных не переживаю.
Скорость чтения с SSD по бенчмаркам 3200Мб/с, куда еще больше?
С файлопомойки через PLEX телевизоры в квартире воспроизводят видео, ресивер может брать музыку (да, я злостный пират и скачиваю всё к себе).
Теперь вопрос: зачем RAID дома еще и на отдельном аппаратном контроллере?
И да, по поводу спасения информации — SSD обычно переходят перед смертью в режим ReadOnly, по крайней мере у меня было так, но повторюсь, вся важная информация была синхронизирована в облако и на файлопомойку.
Теперь вопрос: зачем RAID дома еще и на отдельном аппаратном контроллере?
Ну во первых аппаратный — согласен не зачем. Хотя вопрос тупо в цене — если не дорого, почему нет. Нужен хоть какой. Хоть ручной (это когда руками на один пишешь, а потом на другой :) ).
А во вторых — не улыбается мне лить в облако личную жизнь. Не хочется делать ее достоянием общественности.
Ангела Меркель когда свои сиськи фотографировала — не знала поди что станет канцлером.
У некоторых HDD это отключается, а для тех, у которых нет — просто ставится утилита, которая каждую, скажем, минуту, что-то пишет на диск.
Это старая обманка. Если речь идет 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 контролеры уже отлажены). Там объемчик поменьше, да и диск не дешевый — но заведомо надежнее.
Она распределяет нагрузку равномерно, следовательно и диски «ложаться» практически одновременно. Перестроение рэйда, при современных объемах, это боль.
В идеале, новая математика должна осуществлять неравномерный износ дисков, что бы их можно было менять по одному, и иметь «на борту» один-два SSD, что-бы на момент перестроения не деградировала производительность. Ну что-то среднее между ZFS и нютаниксом. Ждем-с.
Выравниванием износа, помимо прочих задач, занимается контроллер самого SSD.
По моим наблюдениям (статистика обращений по гарантии и техподдержке почти за 10 лет, серверы и СХД) все эти опасения насчёт одновременного выхода из строя являются чем-то вроде старой городской страшилки. Это было с HDD и доходило до рекомендаций ставить в большие массивы диски непременно 3–4 разных моделей и от разных вендоров (!). Определённые основания такой фобии есть, они связаны с массовым отказом определённой моделей. Но, во-первых, последний очень громкий и действительно массовый случай был с Барракудами 7200.11 и это было 10 лет назад, во-вторых — не надо под серьёзный production собирать массивы из бытовых дисков, и в-третьих — не надо забывать про аксиому «RAID ≠ бэкап».
Видимо с годами эта фобия перекочевала на SSD, но тут на практике вообще ничего не подтверждается. Да, SSD мрут, в том числе и серверные, и любых вендоров/моделей (есть обширная статистика Intel, Micron, Samsung, HGST, Toshiba), но за 10 лет я ни разу не наблюдал этого мифического случая «одновременного износа».
сам не пользовался только как ключевые слова для посика
Там всё просто на самом деле. Это тот же RAID-5, но со слегка нарушенной очередностью записи страйпов и контрольных сумм. Выбирается один из накопителей и на него добавляется +1 запись контрольной суммы вне очереди. Из-за такой побочной штуки, как write-penalty (пишем что-то в RAID-5 с размером меньше полного страйпа — получаем необходимость пересчитать и записать новую контрольную сумму), на этот накопитель приходится большая нагрузка на запись. По достижении определённого износа выбирается следующий SSD и так далее.
Я ни разу не наблюдал на практике подтверждения этой фобии равномерного износа (см. выше), а вот минусы этого подхода есть — этот RAID-F1 является проприетарной надстройкой Synology над mdadm, т.е. в случае чего абы где массив не поднять.
Программные RAID-контроллеры уступают интегрированным и аппаратным по производительности и отказоустойчивости
Похоже статью писали без участия технических специалистов
Ну этот холивар длится уже не первый год. Есть и там, и там, плюсы и минусы. Аппаратный RAID легко настроить, есть отличные графические интерфейсы, понятные даже школьнику. Софтовый все ж таки требует определённых знаний (если это конечно не зеркало в винде)
Как раз, чтоб при установке того же centos использовать рэйд — это всего одна галочка.
А железный рэйд даже просто включить — много чего понимать нужно.
Железный мощнее однозначно, но проще — вряд ли.
Ну этот холивар длится уже не первый год. Есть и там, и там, плюсы и минусы.Этот холивар
Так что защищаем write-back кэш контроллера батареей (на современных контроллерах вместо неё ионисторы+запись на флеш); применяем правильные SSD с защитой собственного RAM-кэша конденсаторами; отключаем кэширование записи на HDD.
P.S. И, кстати, если зашла речь о связке «аппаратный RAID + SSD», то стоит учитывать тот факт, что для all-flash томов на контроллерах от Broadcom и Adaptec максимум производительности обеспечивается без write-back, т.е. и защищать кэш контроллера в такой конфигурации не нужно.
Сам обратил внимание )
Производительней то понятно, а вот по отказоустойчивости ситуация, скорее, обратная.
Глюков mdadm не припомню.
Зато с разными рэйдовыми картами проблем было достаточно.
Просто прежде чем запустить в тейп-аут ASIC — его верифицировать могут пару лет. Там ошибки очень дорого стоят.
А касательно производительности — ничто программное не может быть производительнее аппаратного (если мы не говорим о крайних случаях когда Вы на Xeon считаете то, что до этого делал ASIC 10-летней давности).
Я без понятия про ASIC.
Но когда в рэйд-карте дохнет конденсатор, то врядли тут дело в софте.
И просто на слух случаев саморазбора железных рейдов в разы больше, чем от mdadm.
У каждого, конечно, своя статистика...
Но когда в рэйд-карте дохнет конденсатор,
У Вас с тем же успехом может сдохнуть конденсатор на материнской плате или в блоке питания. Вероятность примерно такая же.
«Проблемы» — это когда у Вас в чипе в железной логике ошибка, к которой патчик не выпустишь.
Ну и понятно наверное что для серьезных применений нужно брать поделки от Tier1 производителей, а не с Али.
Ну и если говорить конкретно от конденсаторах — какой? Как сдох? Электролиты и керамика обычно дохнут из-за производственного брака — электролитам гнут ноги при монтаже и они закипают, керамика трескается, танталовые мрут — от ошибок в дизайне, так как чувствительны к малейшему превышению напряжения. Я к тому что это просто в принципе проблемы железа как такового а не RAID карт как класса устройств.
Собственно, я всего и сказал, что софтовое решение лишено недостатков железного, а не наоборот, как в статье.
Всё остальное вы сами себе додумали, мне это вообще не интересно.
Не более того. Ваш афигенный Soft-Raid вполне себе успешно рухнет, из-за того что китаец плохо проверил Вашу конкретную серверную плату на производстве.
У железных решений всего два недостатка:
1. Их нельзя улучшать.
2. В них нельзя исправлять ошибки.
Ну как бы не совсем так. Главное, чтобы заменяемый контроллер не был предыдущего поколения. На таком же или более новом импорт конфигурации проходит безболезненно. Хотя safe config да и вообще snapdump никто не отменял, для рачительного админа — это как зубы чистить два раза в день, must have. Хотя бы периодически.
Может быть, может нет, мне всё равно.
Я вообще об этом не говорил, вы опять сам с собой спорите.
Полностью подписываюсь. Блоки конденсаторов, защищающие кэш, умирают крайне редко. Имею статистику в силу специфики работы. Батарейки BBU — да, но на то они и батарейки. У них рекомендованный срок службы 1 год. У конденсаторов гарантия — 3 года.
Ну кто и за что пишет софт, вам возможно виднее. Так-то у нас полстраны за еду работает. А индусы, кстати, вполне себе толковые ребята. А если по делу — допиливание софта, bugfix — абсолютно нормальный процесс. Главное своевременно реагировать на косяки в случае их возникновения. Если посмотреть на историю выхода релизов прошивок, драйверов и управляющего софта — сразу увидите, насколько регулярно все это выходит. А особо внимательные ещё и release note читают, чтоб понять, что именно пофиксили
Батарея — расходный материал. Вы же не выбрасываете принтер, когда тонер заканчивается. Кстати, срок жизни батареек можно регулировать — у них есть 5 режимов в зависимости от температуры окружения и retention time. В самом щадящем режиме BBU может прослужить до 5 лет. У меня в парке некоторым контроллерам по 7-8 лет, пашут как часы. Да, они лохматого поколения 6G, но свою заявленную производительность показывают.
С софтовыми RAIDами как-то не приходилось работать. По аппаратным есть рабочие тесты для RAID разного уровня с разными видами накопителей — от SAS/SATA хардов и SSD до NVMe. Но это немаленький массив таблиц. Если автор заинтересуется в продолжении рассказа, буду готов поделиться.
>Нужно ли создавать RAID-массив из SSD
— Кстати, а вы вообще знаете что такое RAID?
— Кстати, а вы знаете чем SSD отличается от HDD?
— Возвращаясь к вопросу… мы поговорим о нём в следующей статье!
Кингстон, какого чёрта?!
TRIM выполняют только HBA в IT режиме, на MegaRAID трима нет, там другая фича недавно появилась — Unmap
Что значит «другая фича», когда unmap используется в SCSI для тех же целей, что и trim в ATA?
Ситуация с передачей trim в контроллерах Broadcom сейчас такова: https://www.broadcom.com/support/knowledgebase/1211161496937/trim-and-sgunmap-support-for-lsi-hbas-and-raid-controllers
Никакие =) Поэтому и нет этого в статье.
Поэтому, если ставить SSD в железный рейд, то нужны интерпрайз-версии, которые сильно дороже и обычно ограничены объемом — именно потому, что реально там еще процентов 50 выделено для работы внутренних алгоритмов очистки, которые еще тоже неизвестно как работают.
Есть огромный соблазн воткнуть консьюмерские SSD — и оно будут работать так же. Но недолго, и потом внезапно обнаруживаете, как ваш быстрый сторадж стал улиткой с потолком на запись в районе 30мб/с при любых нагрузках.
Хотя должен сказать, что по нашему опыту консьюмерские samsung 850 evo pro очень хорошо себя показывают даже в железном рейде. Не знаю с чем это связано, но факт — например, тошибы "летели" десятками, а гнусы работают в разы дольше под теми же нагрузками.
Но железные контролллеры принципиально не способны решить эту проблему с ssd.
Поэтому никакого смысла сегодня ставить железные я не вижу. Ну только если у вас сервер на винде или на чем-то подобном экзотичном, где нет ZFS. =)
У нас 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 тоже просел — и это всего после некольких записанных терабайт.
Бред-то какой!
Вам быстро в космос — делайте на 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`ы.
Классная рекламная статейка без единого замера. 10 ссд быстрее лошади, а 10 лошадей быстрее вилки. Битовый поток рейдмассива из 100 нвме ссд превысит третью классическую и сервер улетит на луну.
П.с. а чтобы ещё больше ускориться надо поставить рейд в рейд. Начнем с того что любой ссд с количеством флешчипов больше одного рейд сам по себе.
А так всё что TLC, QLC — это там где не нужны скорость и надёжность. SLC можно найти без очереди, но если MLC стоит на пол порядка дороже, то SLC на все два.
Нужно ли создавать RAID-массив из SSD и какие контроллеры для этого нужны