Важно! Перед любыми операциями с массивами бэкап важных данных обязателен!
В теме обсуждаем вопросы и проблемы организации (выбор структуры), создания, эксплуатации, модернизации (перенос/расширение) и восстановления (ребилда), а также сопутствующие этим вопросам моменты.
Обсуждение выбора RAID-контроллеров ведётся здесь.
Подобрать накопители для массива поможет эта ветка.
Обоснованный выбор оптимального размера страйпа для производительных RAID 0 посредством тестирования в HAB.
Померяться производительностью стоит тут.

В случае описания вопроса выбора, скорости и связанных с этим проблем, просьба ссылаться на посты в соответствующих ветках.

Основы теории массивов: http://wikipedia.org/wiki/RAID
Общая информация по массивам доступна в виде мини-бета-FAQ.
Познавательная статья по контроллерам от програмного массива к аппаратному - Игры с RAID
Полезная статья по восстановлению RAID.
Полезные сведения по работе с RAID-контроллером 3ware 9550SX-8LP, в качестве примера.

Задавая вопрос, постарайтесь как можно полнее описать конфигурацию массива и компьютера в профиле, то что, проделали и текущий результат. Не забываем пользоваться поиском в данной теме и по всему Internet'у!

Intel® Rapid Storage Technology не поддерживает 3TB диски в RAID-режиме, а Rapid Storage Technology enterprise(X79, C600) - работает с ними.

nanoflooder Суть проблемы непонятна. "Убедите меня, что я все правильно делаю", или что?
1. Я бы систему держал на чипсете. Во-первых, поднять легче, ибо контроллер как правило держит натив либо дрова в наличии в ОС вшитые, во-вторых, скорость ССД вырастает от САТА3 только на линейке, а для ОС вообще не принципиально.
2. JBOD - кака, под большой объем с избыточностью либо рэйд-1, если место не жмет, либо два сингла под бэкапы, если критично (тут опять же есть свобода в бэкапе особо нужной инфы на оба носителя, а шнягу хранить уже на каждом по-отдельности).
З. Ы. С удаленкой есть девайсы перехвата даже консоли на уровне BIOS, но тут вопрос денег....

Подскажите пжалста! На материнке собран рэйд 1 если рядом воткнуть ssd рэйду от этого ж никоем образом не поплохеет? или не желательно, когда рэйд контроллер в матери, рядом держать диски не в составе рэйда?

163tiger163 Нет разницы: режим RAID у встроенного контроллера - это тот же режим AHCI+включенная консоль управления. Вот когда сами ССД в рэйде, возможна проблема с пробросом команд от ОС к ССД через контроллер, но раз у вас ССД одиночный - нет разницы.

тоесть я правильно понимаю? Если решусь собрать raid на ssd заменив обычные диски и затем решусь добавить еще ssd дополнительно рядом с raid возникнут проблемы, или raid на ssd впринципе нежелателен? Просто подобные мысли были, но пока решил попробовать вариант установить ssd рядом с raid и положить туда базу 1С, а бэкапы пущай на raid делаются.

Почему? Просто нужны ССД со встроенным GC, чтобы мусором таблица страниц не зарастала - TRIM при включенном режиме RAID не работает, или работает только с определенными типами массивов и версий iRST. Описано, например, тут. А так SSD сам по себе уже RAID-0 из 4/8/16 и т. д. флешек, так что ничего страшного тут нет. Другое дело, что при райд-0 из ССД выигрыш будет только в линейке, который большинству пользователей бесполезен, а вот отказоустойчивый массив - вполне себе, тем более, проблема с TRIM решается не очень сложно либо вообще не актуальна (если оставить свободное место и в ССД свой GC есть).

На чипсетах от NVIDIA "такое" бывает, на интелёвых - не бывает... Всячески одобрям!

Добавлено спустя 3 минуты 51 секунду:
По правильному, для работы отказоустойчивого RAID-массива, нужны SSD с Deterministic Read After Trim (DRAT); иначе у RAID-контроллера может "сорвать крышу"...

Для отказоустойчивых массивов много чего противопоказано. SF с его сжатием, например...

Если прошивка обеспечивает DRAT... не вижу причин не использовать.

Хочется поинтересоваться ради спортивного интереса. Можно ли с аппаратного нулевого рейда забекапить один диск и потом вкинуть его к другому диску. Просто не всегда есть под рукой 2 свободных диска (недавно уже сталкивался с этой проблемой, переливание инфы и перетыкание дисков геморное дело) хотелось бы всё это упростить. Рейд массив интересует только в нуле, знаю что когда включаешь рейд, диск начинает определяться как часть массива отсюда возникает вопрос, можно ли одиночном диске управлять райд контроллером?(я в этом конечно не очень соображаю, только азы) По этому поводу в инете ничего не нашёл по этому спрашиваю тут. Если я тут наговорил ереси сильно не бить.

Ага... Нули они тебе возвратят. Скорости-то представляешь какие будут? Одно дело удалить по команде, и другое дело проверить сперва, а не участвуют ли эти данные в Data differencing, не нужны ли они для сжатия/разжатия - кэша-то как такового нет. Плюсом еще у SF изначально всё место используется под данные, просто часть этого места - сами данные (сжатые по возможности), а часть - резервная область для сжатия. И там с уменьшением свободного места всё еще хуже, чем у классического ССД без GC даже при отсутствии Trim. Да и вряд ли поддерживают они, там же страничная запись, страницы постоянно тусуются, смысл напрямую сектор от ОС через контроллер АТА у контроллера ССД спрашивать?
grigorovdmitriy Можно, только смысл? При изменении данных на втором диске при подтыкании бэкапного с неизмененными рэйд скорее всего или совсем развалится или будет потеря данных на уровне ФС. А если на втором не менять - смысл бэкапить первый? Если уж бэкапить - то весь массив, ну или важную его часть, либо весь но по частям. А смысл вам грубо говоря только половину данных сохранять?

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

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

вы суть проблемы не поняли. Бекап для долгого ящика мне не нужен. Имея в наличии рейд в 0 и вдруг один диск начинает сыпаться, надо больной диск заменить на новый только вот проблема в том как с больного диска перелить инфу на живой и потом как его включить в рейд.

grigorovdmitriy А по-моему, это вы суть проблемы не поняли. Нельзя просто так взять и заменить участника в RAID-0. Точнее - заменить-то можно. Только массив прересобрать придется. То есть всё-равно либо бэкапить весь массив, либо только важную часть, либо вообще забить на данные.

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

163tiger163

1) Возьмите пару S3510 достаточного вам объёма
2) Сделайте raid1
3) Всё

В RAID0 не может быть 1(один) диск (за исключением специфических аппаратных RAID-контроллеров, которые не могли работать с одиночными накопителями, не входящими в массив - тогда приходилось делать "страйп из одного накопителя").
Контроллером-то можно всегда управлять; но, похоже, ты о чём-то совсем ином спрашиваешь?..
Напомню тебе старинный анекдот про "это уже второй вопрос!"
Что касается технической стороны реализации... Коль скоро транслятор SSD по любому точно знает - какие данные ещё пока актуальны, а какие - уже попали "под снос" (ибо по этому адресу LBA уже прошла команда TRIM) - нет проблем не пытаться тупо читать по этому LBA-адресу неактуальные данные, а сразу ответить нулями...
Напомню тебе логику работы любых драйверов дисковой подсистемы: драйвер всегда напрямую запрашивает у накопителя конкретный адрес сектора/блока; чему и как этот адрес сектора/блока соответствует в реальном накопителе - знает только сам контроллер накопителя (такие данные накопитель иногда может сообщать сервисному софту - но уж никак не стандартному драйверу любой ОС).
Ответ простой: никак.
Кроме того: а как ты вообще думаешь заранее определить, который из накопителей страйпа у тебя начнёт сыпаться? Тогда по твоей "методе" надо бэкапить сразу оба (или сколько там ты накопителей соберёшь в страйп) - а это уже предусмотрено в RAID10...

Так и я про то же: ну запросила ОС о каком-то секторе, ну транслировал контроллер АТА этот запрос контроллеру ССД. А вот дальше-то что? Либо этот блок, в котором искомый сектор, не нужен и на тебе нули, либо он нужен и низзя, либо он как бы не нужен но мы вот щас вот тут сожмем, тут почистим, тут подвинем, и можно начинать сносить всю страницу потихоньку... Вот у SF последний случай и будет с его сжатием "адаптивным", как я понимаю логику его работы. Ну или он тупо не даст такие данные херить, пока GC их не отпустит.

"сожмём, почистим, подвинем" - это всё относится к физическим блокам; а на логическом уровне нет (и не может быть ) никакого "сожмём..." etc.
Так что всё вполне решаемо на уровне прошивки для контроллера (пусть даже этот контроллер - так явно презираемый тобой SandForce).

Почему тогда диски показывают кучу свободного места, а скорость падает? Вот как раз потому, что логически там ничего нет, а физически там данные. Посмотри, как усиление записи работает.