Comments 100
ИМХО вентилятор там нужен на 120мм спереди.
Лучше создать на дисках разделы, а потом добавлять их в массив. Некоторые ОС (windows) при подключении диска могут испортить главную запись mdadm, создав на диске таблицу разделов.
Железный Raid контроллер =ускоряет систему +упрощает Rebuild Харда 🙃
И добавляет риск отлета контроллера. А его заменить с течением времени все сложнее.
+100500
Дважды попадал на такое. Один раз отлетел контроллер, а замену уже просто не найти. Пришлось осваивать программные средства восстановления данных на RAID массивах из образов дисков. Я, тогда, возблагодарил всех богов, что держал встроенный в контроллер кэш в режиме write-through. Успешно.
Второй раз отлетели процессор и материнская плата на сервере. Контроллер вроде бы вот он, даже рабочий, но, PCI, и втыкать на новом железе его уже некуда. И, вроде, есть переходники с PCI-E, но, нет драйвера под новую ОС. А в старой нет драйвера на новый процессор :-)
Благо, навыки восстановления данных уже имелись :-)
С тех пор, программные массивы, - наше все.
С тех пор, программные массивы, - наше все.
Пользуемся и тем и тем - проблема программных в том что улетающий диск с лёгкостью может повешать систему или вообще не давать матери загрузиться и статистически у нас это на порядок чаще чем отказ контроллера. Ну и производительность повеселее у нормальных аппаратных.
Это проблема не только программных, но и fake-RAID на чипсете, вроде IRST.
При уходе массива (не обязательно системного) в "degrated" вся система начинает тормозить до полного зависания, пока больной зуб не извлечешь. Причем, определить его бывает непросто - IRST крайне примитивен и не дает толком никакой информации.
fake-RAID, это вообще зло. Они сочетают в себе недостатки обоих (аппаратных и программных) RAID, притом не имеют никаких достоинств в сравнении с любым из них, кроме цены, которая сейчас равна почти нулю.
Но, и, к сожалению, многие "аппаратные" сейчас де-факто являются "перекачанными программными". То есть, вся RAID логика де-факто делается на CPU посредством программной прослойки, которая загружается через BIOS контроллера или драйвер.
Ну, у каждой технологии своя область применения.
Тот же IRST хорошо работает в производственных АРМах. Причина - он дешев и прост в настройках (которых, по сути, нет), а АРМы, обычно, дублируются и троируются. Да еще бэкапируются. И контроллер выйдет из строя только вместе с мамкой, тому как отдельного аппаратного контроллера нет.
Можно не заморачиваться мониторингом, высокими уровнями RAID и пр. По факту выхода из строя, заменить диск - дело 15-20 минут. Плюс время доехать до объекта и уехать с него.
Такое, теоретически, возможно, если носитель поврежден и оставлен в системе в момент перезагрузки. В редких случаях может сбоить BIOS POST или попытки чтения загрузочной области. Но, я ни разу не перезагружался с неисправным диском в системе. Просто, из корзины его достаю перед этим, или сразу меняю, потому, ни разу не сталкивался.
Вообще, отказ диска, - это ситуация штатная, перезагрузки для замены не требующая. Если, конечно, у вас не аппаратный контролер, которому надо в BIOS залезть, чтобы массив пересобрать, потому что в ОС нет под него софта.
Ну, а, тормоза, - это ожидаемо. Некоторые уровни RAID тормозят при деградации by design (5-6), зеркало тоже уменьшит скорость из-за потери диска, а, чередование, вообще протухнет. И, аппаратный raid тут ничем не поможет.
А, чтобы, умирающий, но еще пока не совсем мертвый диск не тормозил систему, надо просто настроить SCT ERC. Ну, или переплачивать за "диски для RAID" где по-умолчанию ERC включен, хотя, настроить/включить его можно и на большинстве обычных дисков.
Еще, замечу, что, к сожалению, производительность у аппаратных рэйдов в последние годы, сначала, сравнялась с программными, а потом, начала, отставать. Особенно заметно на NVM-E SSD. Там у аппаратных RAID задержки, а, следовательно, однопоточный IOPS сильно проседает. Просто из за дополнительной обработки данных контроллером, которая требует время. Ну и железо процессорное сильно выросло в производительности. Больше нет узких мест в RAM/CPU/PCI-E. Ну, если их, конечно, своими руками не создать, забыв сконфигурировать размер кэша программного массива, или повесив десяток дисков на контроллер воткнутый в 1xPCI-E слот.
В редких случаях может сбоить BIOS POST или попытки чтения загрузочной области.
У меня несколько раз уезжал контроллер самого диска и post зависал. Было что post проходил, но не видел ни одного диска.
Но, я ни разу не перезагружался с неисправным диском в системе.
В моем случае система висла наглухо или падала в kernel и перезагружалась собакой. Впрочем никогда не проверял диски на исправность перед перезагрузкой.
Некоторые уровни RAID тормозят при деградации by design (5-6), зеркало тоже уменьшит скорость из-за потери диска,
С чего бы вдруг by design? Если отбросить кэш - запись это запись на все диски, исключение самого медленного (сдыхающего) ускорит ситуацию. Чтение в degraded это чтение со всех - будет медленнее на диск, заметнее всего на зеркале - упадёт вдвое максимум, для условного raid6 из 8 дисков - потеря одного никак толком не будет замечена.
Особенно заметно на NVM-E SSD
Ой, массивы на ssd вообще отдельная тема.
Ну и железо процессорное сильно выросло в производительности
А на raid контроллерах железо не выросло? У нас в основном линейное чтение/запись, может я не замечаю что все ужасно.
Впрочем никогда не проверял диски на исправность перед перезагрузкой.
Я тоже не проверял. Они вытаскиваются из корзины по факту вываливания из массива. В момент перезагрузки их в системе нет, т.к. замена диска перезагрузки не требует.
С чего бы вдруг by design?
Если диски присутствуют не все, то, операция чтения с отсутствующего диска требует прочитать данные со всех остальных и вычислить четность. Производительность чтения падает со значений сравнимых с raid0 (в IOPS) до скорости самого медленного диска. Запись у raid 5/6 всегда на все диски идет и всегда меньше или равна скорости самого медленно диска (в IOPS). Это вправило верно почти всегда, за исключением случая чисто линейной записи когда все блоки обновляются синхронно на всех дисках, и, узким местом становится не IOPS (что верно почти всегда в реальных сценариях), а скорость интерфейса/чтения с пластины.
исключение самого медленного (сдыхающего) ускорит ситуацию
При настроенном ERC "сдыхающий" должен сам из массива отвалиться и быть заменен. Так что, такие диски, - синоним неисправных.
А на raid контроллерах железо не выросло? У нас в основном линейное чтение/запись, может я не замечаю что все ужасно.
Выросло. Но, раньше, узкоспециализированное железо могло это делать лучше, чем железо общего назначения. А, сейчас, почти все RAID контроллеры представляют собой какой-нибудь слегка кастомизированный ARM/PowerPC/x86 SoC, который внутри имеет свою операционную систему, вплоть до специализированной сборки Linux, которая внутри собирает программные массивы :-D. Да они стали быстрее, но, чтобы разогнать SoC до 5ти гигагерц на него надо ставить огромный радиатор, как на процессоре/видеокарте, и подводить Ватт этак 100 по питанию.
Сейчас TDP является узким местом всей электроники. А, радиатор у вас на ЦП всяко больше размером чем на RAID карточке.
И да. Чисто линейное чтение/запись очень узкоспециализированный сценарий со своими особенностями.
Если диски присутствуют не все, то, операция чтения с отсутствующего диска требует прочитать данные со всех остальных и вычислить четность.
Да, не подумал, вы правы. При условии случайного чтения попадание в вылетевший stripe обеспечит тормоза, с одной стороны скорость чтения каждого такого блока упадёт до чтения самым медленным диском, с другой стороны - проблему частично сгладит невысокая вероятность попадания на большом количестве дисков. При линейном чтении скорость не особо поменяется.
При настроенном ERC "сдыхающий" должен сам из массива отвалиться
Практика показывает что он никому ничего не должен.
с другой стороны - проблему частично сгладит невысокая вероятность попадания на большом количестве дисков.
Если дисков должно быть 10 штук, то, каждый 10ый случайный запрос будет попадать в отсутствующий диск, и превращаться 9 запросов на оставшиеся вместо одного. Так что, при увеличении IOPS верхний предел IOPS при случайном чтении все равно будет стремиться к скорости одного диска.
Практика показывает что он никому ничего не должен.
Да. Такое тоже бывает. Но реже.
По любому. Наверное он дороговат для такой системы?
Ускоряет… пока батарейка жива и прошивка не решила сыграть в лотерею
Давно уже ничего он не ускоряет особо и никаких дополнительных функций относительно софтверных рейдов не предлагает. Особенно для дома. А головной боли очень даже добавляет.
Так что железный рейд сегодня - это энтерпрайз, да и то...
Если с батарейкой или суперконденсатором (и лучше с SSD-кэшем) - то штука реально полезная, т.к. сильно ускоряет операции записи без риска потери данных (просто за счёт того, что запись всегда в кэш, даже если запрошено подтверждение записи на диск).
А вот без оного - преимуществ не даёт, и может даже тормозить по сравнению с чисто софтверными рейдами.
Хуже железного без батареи/суперконденсатора - только полуаппаратный рейд (он же полусофтверный, он же хострейд) :)
По-моему, для ускорения записи чаще используют ssd-cache, всё же батарейковый кэш по размерам сильно уступает.
Кэш на контроллере стоит независимо от батарейки... А вот дальше начинаются варианты.
В старых контроллерах - батарейка питает кэш. В более новых - кэш сбрасывается на SSD за счёт питания от суперконденсатора. Что позволяет держать контроллер выключенным очень долго, чем при питании его от батарейки.
Без того и другого - контроллер по идее предпочитает не использовать свой кэш на запись вообще во избежании потерь данных по питанию, из-за чего в raid-режиме на запись тормозит по сравнению с HBA-режимом.
А если делать SSD-прослойку в самом массиве - то уже и raid-контроллер-то не особо нужен, кроме как в режиме HBA...
Софтверный массив сегодня вообще заметно более гибкий, чем аппаратный.
Но сохранить данные в RAM при пропадании питания не смогут. А потому ускорение в режиме "подтвердить запись данных на диск несмотря на то, что они всё еще в кэше" - чревато. А это очень сильно ускоряет дисковые операции...
В остальном да, и не только сегодня, а всегда были более гибкими.
С пропаданием питания должен ИБП бороться.
Даже если оно пропало по причинам:
проблема в БП
проблема с ИБП
проблема с OS и её ребут
?
Суперконденсатор с SSD кэшем отработают автономно, плюс это надёжнее чем даже online ИБП со свинцовыми батареями, а уж про цену ИБП с литиевыми лучше помолчать...
Когда у меня проблемы с БП и ИБП, новая информация меня уже не особо волнует. Сохранилась бы старая.
А сохранность информации в кышах - это уже задачи энтерпрайза. Но там все эти "проблема с БП-ИБП и ребут" тоже должны решаться не за счёт батарейки, а за счёт кластера с HA, СХД и т.п.
ну вот сброс кэша не в /dev/null, а на ssd - как раз и предотвращает нарушение консистентности данных и метаданных уровня массива (не fs даже), даже если машина по какой-то причине дёрнулась по питанию несмотря на все ИБП, резервированные БП и т.д.
Случаи - они разные бывают...
А вот уже над этим всем собирается какая-нибудь СХД с резервированным контроллером...
Правда, "контроллер" у СХД внутренностями куда больше похож на комп, чем на плату для сервера, но это уже следующий уровень надстройки. И с SATA дисками просто так резервирование контроллера работать не будет, только с SAS/NL-SAS (SATA-диски, если они СХД поддерживаются, подключаются через dualport-адаптер).
Но если СХД работает в максимально производительном режиме - то есть с фейковыми подтверждениями для команд записи данных на накопители - то без возможности аварийного сохранения кэша вероятность повреждения данных и даже метаданных массива "в случае чего" очень сильно возрастает.
В 2008 - да.
В 2020+ - только HBA, поверх можно намазать что душе угодно
Железный контроллер, который действительно ускорит и упростит, будет стоить как весь системный блок, использованный под хранилище. Дешевые аппаратные рейды будут сливать по производительности mdadm с любым более-менее современным процессором.
Красивый гайд. Спасибо!
На ZFS примерно так же выглядит замена диска.
RAID-5 - зло. Проверено опытом.
Обычно есть смысл выбирать между RAID-1 и RAID-6.
raid5 - вполне пристойное дешевое решение увеличить надёжность, не сильно теряя в ёмкости массива.
В своё время я прикинул (чисто с потолка) преимущества и недостатки разных уровней RAID:
RAID-0 на 2-х HDD;
RAID-1 - 2 массива на 2-х HDD каждый;
RAID-10 на 4-х HDD;
RAID-5 на 3-х HDD;
RAID-6 на 4-х HDD.
Т.е. объем был во всех случаях одинаковым.
Сравнение шло по следующим критериям:
Надежность (вероятность полной потери информации; вероятность частичной потери информации):
Скорость (на чтение; на запись);
Стоимость.
Выставил по каждому критерию баллы, раскрасил красиво в разные цвета от зеленого до красного и как-то всё сложилось само собой:
RAID-0: Устройство временного хранения некритичной к потере информации быстрого доступа (временные файлы, хеши);
RAID-1: Ненагруженные базы данных малого объема;
RAID-10: Нагруженные базы данных значительного объема;
RAID-5: Устройство длительного хранения некритичной к потере информации (архивы, ненагруженные инфосистемы);
RAID-6: Устройство длительного хранения критичной к потере информации (копии рабочих материалов).
Правда, с тех пор много изменилось (например, использование SSD вместо HDD частично восполняет потерю скорости), но основное осталось прежним, в частности:
Надежность RAID-5 даже на трёх дисках кратно ниже надежности двух независимых RAID-1. При увеличении числа дисков надежность RAID-5 падает сильнее, чем у нескольких RAID-1 даже без учета консолидированного отказа. Кроме того, при выходе из строя RAID-5 мы потеряем всю информацию, а при выходе из строя одного RAID-1 из нескольких - только часть, что ускорит её восстановление из бэкапов.
Надежность RAID-6 на порядок выше, чем у RAID-5. Потеря ёмкости при этом не такая существенная.
За надёжность хранения информации отвечает бэкап.
RAID отвечает за непрерывность доступа.
Надежность RAID-5 даже на трёх дисках кратно ниже надежности двух независимых RAID-1.
Вы не можете собрать два raid1 на трёх дисках. Задача raid5 - не "максимальная надёжность", а способность перенести потерю одного диска и продолжить работу. Не более того.
А где я писал про RAID-1 на трех дисках?
RAID-1 - 2 массива на 2-х HDD каждый;
...
RAID-5 на 3-х HDD;
Т.е. при одинаковом объеме хранения RAID-5 на трёх дисках менее надежен, чем 2 RAID-1 на четырех дисках.
И наличия бэкапа не умаляет значение RAID для повышения надежности.
Если имеем дела не с сервером СУБД с полной моделью восстановления и журналированием на отдельных массивах, а с обычными рабочими материалами и проектами или отчетами, то бекап не совершается в реальном времени, а, в лучшем случае, пару раз в сутки. А то и раз в неделю. Поэтому отсутствие RAID чревато потерей документов за несколько дней.
А где я писал про RAID-1 на трех дисках?
RAID5 на трёх дисках сравниваете с двумя RAID1 на четырёх дисках. Само собой, система с двумя дисками для избыточности будет надёжней системы с одним диском.
И наличия бэкапа не умаляет значение RAID для повышения надежности.
Ещё раз скажу - RAID к надёжности хранения данных прямого отношения не имеет. Он про непрерывность доступа.
бекап не совершается в реальном времени, а, в лучшем случае, пару раз в сутки. А то и раз в неделю.
Если вы делаете бэкап раз в неделю - значит данные, созданные между бэкапами для вас недостаточно критичны.
Поэтому отсутствие RAID чревато потерей документов за несколько дней.
Наличие RAID вас тоже не защитит от потерь информации. RAID спасёт только от одной угрозы - выход диска из строя. Причём эта угроза даже не самая часто встречаемая, информация гораздо чаще теряется по куче других причин. RAID вас не спасёт от шифровальщиков, от удаления файлов, от перезаписи файла поверх и т.п.
Потому бэкап всегда должен быть первичен.
Выход из строя диска - причина более частая и по последствиям более разрушительная, чем всё перечисленное вместе взятое.
Для прочего есть другие организационно-технические решения:
От шифровальщиков групповыми политиками назначили запрет на выполнение определенных действий. Это для обычных пользовательских компов. Для производственных и лабораторных АРМов всё еще проще - работают в изолированном сегменте сети или вообще к сети не подключены, CD/DVD-дисководов нет. USB-порты закрыты металлическими заглушками.
Удаление файлов в СХД сделано через корзину с автоматической очисткой по истечению срока давности. Если пользователь удалил файл мимо корзины - R.Saver или R-Studio в помощь. У нас одна обиженная перед увольнением удалила папку с документами с рабочего стола компа коллеги и корзину очистила. За 5 часов всё восстановили.
Если пользователь решил изменить содержимое файла и перезаписать его, то это его собственное решение, а не моя зона ответственности.
(например, использование SSD вместо HDD частично восполняет потерю скорости
+
длительного хранения
А по сравнению с HDD - даже превосходит по скорости.
Всё зависит от потребности в IOPS и объёма данных в конкретном случае.
Иными словами, качественная оценка типа "нагруженные/ненагруженные базы данных" должна быть выражена в количественной оценке в виде IOPS.
Иначе можно тёплое с мягким перепутать...
Кому-то под его базы данных и raid5/6 на SSD хватит, а кому-то и 10 из SSD придётся собирать.
Для хранения больших объёмов не слишком интенсивно используемых данных - нет смысла ставить SSD, т.к. "не слишком интенсивно" означает, что подходящие IOPS можно получить количеством HDD, а по цене за гигабайт большие HDD будут дешевле. 10 из HDD нынче тянет на экзотику, но 5/6 и 50/60 - вполне можно.
Вот выбор между 5 и 6 - уже зависит от многих факторов, включая число дисков... С большим числом дисков цена лишнего диска уже не столь критична по сравнению с риском развала массива из-за еще одного сбоя во время включения спера...
И вот что-то тут никто по-моему про hot spare не упомянул, а зря - если уж переживать за доступность массива при отказах дисков, то пусть он автоматом заменяет отказавший диск.
Ну, про Hot-Spare не упоминают, наверное, потому что это и так само собой разумеющееся.
Но не всегда. Например, для SQL+1C сервера систему, базы и журналы транзакций лучше располагать на массивах с HS. А TempDB, кэши и горячие бэкапы и без HS обойдутся.
Кстати, лет 15 назад RAID-10 реально спас одну ИС. Пока искали диск на замену (а там SCSI Ultra320 были), пока его покупали, пока привезли, пока менять собрались - вышел из строя еще один. Хорошо, что из другого зеркала.
Кстати, чем больше дисков в RAID-5, тем выше вероятность консолидированного сбоя. Читал рекомендацию не делать его больше, чем из 4-6 дисков. Всё что больше - RAID-6 или хотя бы RAID-50.
Ну, про Hot-Spare не упоминают, наверное, потому что это и так само собой разумеющееся.
Вот не уверен, к сожалению...
Кстати, чем больше дисков в RAID-5, тем выше вероятность консолидированного сбоя. Читал рекомендацию не делать его больше, чем из 4-6 дисков. Всё что больше - RAID-6 или хотя бы RAID-50.
Да, сталкивался с рекомендациями, и резоны есть - в т.ч. потому, возможен отказ еще одного диска в процессе перестроение массива. Так что периодический scrubbing данных тоже полезен.
Судя по буферу, диск с черепичной записью. Не рекомендовал бы.
Могу только прокомментировать, что, с такими ценами на HDD за 1TB проще уже на SDD 2TB накопители переходить. Цены почти сравнялись в пересчете на терабайт. Правда, это, конечно, не для всех сценариев подойдет. Если надо много писать, то нужно учитывать TBW ресурс.
Только, еще замечу, что за пределами РФ диски аналогично сильно подорожали. Так что, это, скорее, AI гонка все же виновата)
Цены на ssd прямо сейчас вас неприятно удивят. Снова.
Человек покупал 2тб за 15. На следующий день диск стоил уже 30
Как то тоже думал в сторону замены на ssd, но как то стрёмно становится от того, что они умеют в самый неподходящий момент умирать без предварительных симптомов.
Hdd в этом плане более предсказуемы.
Я держу пару достаточно крупных массивов на SSD (как NVM-E, так и SATA). Из моего опыта: они действительно отъезжают внезапно, но, обычно, при этом, сваливаются в readonly и просто вываливаются из массива. И, восстановление банальным dd на новый носитель + re-add прокатывало во всех случаях. Полных смертей не было пока. Но, они, конечно, возможны, как и у дисков.
Единственно, я начал, на всякий случай, использовать raid6 и raid1 с тремя зеркалами для совсем уж критичных данных. Но, как показала практика, все оказалось даже проще, чем с дисками.
По личному опыту (несколько сотен ссд, а так вообще тысячи прошли) - в ридонли переход встречается заметно реже, чем внезапная смерть.
Интересно, есть ли какая открытая статистика по-типу BackBlaze, но про SSD?
Не встречал. Моя статистика на недорогих бытовых ссд основана, большей частью adata (примерно 50%), wd (25%), а потом уже остальной зоопарк kingston, msi, intel, samsung и всякая китайщина.
О проценте брака на этом наборе делать выводы не стоит, конечно.
Но симптомы вылетов, думаю, достаточно репрезентативны должны быть.
Я вообще не понимаю, на кого сегодня рассчитаны терабайтники.
Да, 1ТБ стоит 10 тысяч. 2ТБ стоит 10500. А 6ТБ стоит 15 тысяч.
На кой тут брать терабайтник?
Дыыы RAID работает идеально годами, а потом внезапно напоминает о себе в воскресенье утром
Подскажите пожалуйста, как вы реализовали отправку оповещения о том, что диск в массиве надо заменить?
У автора две статьи, одна из них про настройку мониторинга дисков).
штатная возможность mdraid. Главное, чтобы был сервер, через который можно отправить ;)
Да, есть статья на хабре. Это на своём компе делал, там в коментах есть скрипт на питоне ещё: https://habr.com/ru/articles/962290/. На домашнем сервере делал по другому, писал здесь: https://vk.com/wall88559934_2622
RPM - 5400 об/мин
Немного странно видеть для Raid диски с 5 400 об/мин, а не классические 7 200 об/мин.
поздравляю с покупкой
собакен - гуд
что-то на очереди еще под замену? Проверил бы.
PS покупать так или иначе придется всем
Пошёл смотреть что я могу приобрести и очумел. HDD на 1 Тб стоят 10000 рублей!!!
Стоят. Настолько невыгодно купить диск - надо было постараться.
2ТБ стоит 13.
3ТБ стоит 13.
4ТБ стоит 14.
6ТБ стоит 18.
А SATA SSD 1TB стоит тоже 10 тысяч. Цены из ДНС.
Если у него там еще три терабайтника HDD - то ни брать терабайтник SSD, ни брать диск большего объема - не имеет смысла.
Точнее, имеет смысл брать диск большего объёма - но в рамках плана постепенной замены трёх остальных в течение года, и обкатав технологию расширения массива при таких заменах.
При таких ценах на диски, как минимум, надо было пересмотреть структуру массива.
У него три диска по 1ТБ - то есть результирующий размер массива 2ТБ.
На мой взгляд, ради такого объёма массивом вообще заморачиваться смысла нет.
Оптимально, на мой взгляд, было бы так
1) покупаем новый винт на 3-4ТБ.
2) Копируем на него инфу с массива.
3) Разваливаем массив, живые диск используем под бэкапы. Да, не в риалтайме, но гоняй раз в полчаса rsync важных папок - и будет не сильно хуже пятого рейда.
4) Как появятся деньги, покупай второй 3-4ТБ и делай зеркало. Старые диски на пенсию.
В плюсах - увеличение размера массива в полтора-два раза и свободный слот под диск.
В минусах - пришлось какое-то время пожить без рейда. Но при наличии бэкапов это не такая уж и беда. Всё равно на пятом рейде редко идёт такая активная работа, чтобы информация потерялась при лаге в полчаса-час между бэкапами...
В минусах - потеря в и IOPS, и так небольших. Потому что для дискового массива при том же конечном объёме - чем больше дисков, тем лучше.
По-моему, пятый рейд и так самый медленный, особенно на запись.
Зеркало уж точно не медленней будет.
На чтение - таки ускоряет по IOPS. При записи да, надо учитывать пенальти, но число дисков и тут имеет значение, и чем их больше - тем и на запись больше IOPS.
А проблема зеркала - это минут 50% дисков из итогового объёма. В то время как RAID5 - минус только один.
Если нужна скорость - надо брать ssd.
Массив на HDD - это сегодня хранение и считать на нём иопсы уже нет смысла.
А вот это "зависит от" - может ему в его задачах хватает 200-300 IOPS, но не хватает 100?
Опять же, он собирал систему когда цены на диски были другими. Сейчас менять сразу все три диска на 2+TB - накладно...
Нужны от винтов иопсы - ставь raid0.
А на что менять - я там ниже написал примерный план действий, как бы я вопрос решал.
Нужны от винтов иопсы - ставь raid0.
И с отказом одного диска теряется все данные, что не попали в бэкап.
В то время как IOPS на чтение - у RAID5 тоже суммируется, так что при том же объёме raid5 из 3 дисков как минимум не ухудшит Read IOPS по сравнению с raid0 на два диска.
Write IOPS да, ухудшатся, хотя не факт, что он на практике это сильно почувствует :)
А на что менять
Если у него есть план в течение года поменять все диски на больший объём - то смысл брать для замены диск на 2+ТБ есть. Потом купит остальные, соберёт degraded массив, перенесёт данные и переведёт заменённый диск в новый массив (устранив тем замым degraded; после чего можно убить старый массив или заюзать диски подо что-то другое).
Если таких планов нет, и ему надо просто заменить один диск и дальше пару лет так жить - ну смысла нет и огород городить, заменил диском такого же размера и дальше всё живёт.
Микшировать в массиве SSD и HDD - смысла тоже нет, кроме как если делать tiering. Брать два SSD на 2ТБ каждый - ну даже если взять дешманские и сомнительной надежности, то всё равно дороже замены одного HDD будет, несмотря на конский ценник за терабайт у мелких HDD.
И с отказом одного диска теряется все данные, что не попали в бэкап.
Зато иопсы есть.
Если таких планов нет, и ему надо просто заменить один диск и дальше пару лет так жить
Только теперь он потратил 10 тысяч и лишил себя возможности следовать вашему варианту.
Кстати, у современных дисков и на одного вполне может быть побольше "иопсов", чем у массива из нескольких старых.
Зато иопсы есть.
Он поставил три диска, и получил всё сразу - и IOPSы, и подстраховку на случай отказа одного диска. Которая в статье и сработала.
Только теперь он потратил 10 тысяч и лишил себя возможности следовать вашему варианту.
Ну если ему на ближайший год этого объёма хватит - то через год по новым ценам может вернуться к вопросу покупки N новых дисков. Ничего не потерял.
Кстати, у современных дисков и на одного вполне может быть побольше "иопсов", чем у массива из нескольких старых.
Надо замерять, конечно, но линейных операциях - явно да, а на рандоме - не факт, что в разы прирост на той же версии SATA и тех же оборотах.
Многие контроллеры и программные RAIDы не позволяют (или крайне не рекомендуют) использование в одном массиве SSD и HDD.
Вот по этому нужен взгляд со стороны. Отсутствие времени и не хватка опыта не позволили мне даже смотреть в сторону вашего решения. Я усвою опыт и в следующий раз буду мудрее ))
Ну, я и сам тоже временами выбираю путь, который на момент выбора кажется логичным и пру по нему, выбирая такие решения, которые со стороны кажутся кривыми. Aka "tunnel vision".
Потому стараюсь временами отходить в сторону и смотреть на проблему под более широким углом. Ну или выношу на обсуждение, люди со стороны нередко подсказывают более логичные варианты.
Этот HDD Seagate под видеонаблюдение. Не подходит сюда.
Скажу по секрету - под домашнюю файлопомойку подходят любые диски, лишь бы контроллер или софтверный RAID на них не ругался.
Я на работе из списанного барахла сделал себе личную ФП. Поднял на ней ХРЕНолоджи. На ней сделал массив SHR-2 (это проприетарный RAID-6 от Synology) на 6-ти списанных, но с хорошим S.M.A.R.T.ом Seagate Barracuda ST500DM002.
Теперь у меня там видеокурсы по настройкам, ремонту, Флибуста, рок и метал.
Добрый день!
Не боитесь использовать RAID-5? При выходе из строя одного диска (а меньше одного из строя не выходит), система остается без защиты.
RAID-6 требует еще одного диска, но в разы повышает надежность системы.
С ценами на диски сейчас, конечно, просто слов нет.
Не боитесь использовать RAID-5? При выходе из строя одного диска (а меньше одного из строя не выходит), система остается без защиты.
А если не использовать raid5, то при выходе из строя одного диска, вы полностью теряете данные. raid5 менее надёжен, чем более высокие уровни рейда, но более надёжен, чем отсутствие рейда.
Впрочем, наличие рейда не должно отменять регулярных бэкапов.
Для RAID-6 нужно обновлять железо. Суть проекта бюджетный сервак для дома. Я сделал его за 3000 рублей. Если очень боятся, то тогда лучше S3 подключить как диск и складывать всё туда.
бюджетный сервак для дома. Я сделал его за 3000 рублей.
а можете расписать построчно стоимость компонентов вашего сервера?
Видимо, это было очень давно)
Учитывая, что стоимость одного диска сейчас приближается к 10К.
Возможно, сервер собирался из условно "бесплатного" или б/у железа. Хотелось бы конкретики, с указанием года сборки сервера. Я вот сейчас собрал для дома NAS из комплектующих в небольшом корпусе - у меня только корпус с начинкой вышел в 50к руб. Про диски промолчу.
Как писал выше банк прикрыли и я купил у них системник за три копейки. Плюс рассказал зачем он мне и мне дали ещё оперативки и пару хардов.
Мать: https://www.asrock.com/mb/intel/H61M-DGS/index.ru.asp
Проц: https://fb.ru/article/256241/protsessor-intel-core-i-harakteristiki-temperatura
Оперативки 8 гигов
Купил на распродаже ))
Мой сервер прислал мне письмо: пора менять диск в RAID