Важно! Перед любыми операциями с массивами бэкап важных данных обязателен!
В теме обсуждаем вопросы и проблемы организации (выбор структуры), создания, эксплуатации, модернизации (перенос/расширение) и восстановления (ребилда), а также сопутствующие этим вопросам моменты.
Обсуждение выбора 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) - работает с ними.

либо ставить под 2000, либо искать в инете...

Попробую...
А как насчёт второй проблемы с сестрёнкой, можно так сделать?

g-force

все просто, ставишь один винд на первый hdd, настраиваешь разбиваешь и т.д. потом временно отключаешь его, ставишь винду на второй, тоже настраиваешь.. включаешь оба винта, после чего устанавливаешь загрузчик, например acronis os selector, загружаешь винду для сестры и в диспетчере логических дисков просто удаляешь буквы от разделов второго винта и все... она его и не увидит при работе

но это злостный оффтоп

Спасибо попробую.... но надо купить винт... Всем Спокойной ночи

вобщем такой вопрос: поставил для игр RAID, чтоб грузились быстрее и подгрузки менее заметны были,(что они щас и делают в два раза быстрей... ). получилось так: "один" винт с системой и прогами, два других в RAID с играми... куда девать своп? конечно лучше на RAID, но с другой стороны у меня там игры(для них собственно и ставил RAID)...
что скажете?
ЗЫ
второй RAID не предлагать...

maxmm
на RAID... игры обычно мало используют во время игры свои файлы - только в процессе подгрузки уровней. поэтому оптимум - перенсти своп на рейд.

maxmm И желательно разметить для свопа отдельный раздельчик ровно в размер файла подкачки.

спасибо.

Хелло, большая ветка, интересная но прочитал только до 30 стариницы =)
Стоит на серваке promise SX6000 4х250гб, IBM 2mb, raid 5. gigabyte boundry on, stripe block size 64кб, всё это под W2K.
Всё конечно в контроллере хорошо, кроме того что он промис и нереального вранья по поводу его 6-ти канальности, на практике полноценно работают только первые 4. Дело придумывалось для хранения всёкого свежескачанного файла, и его дальнейшего просмотра по 1Гбит лан. По лану средняя скорость 32 метра т.е. всё отлично, правда в течении года пришлось два раза пересобирать array, отваливались диски, если рушилось питание. Так вот прошёл год и запищал один из дисков, диск не смог проити полную диагностику в "онтрак изи рекавери", висла винда, была произведена замена диска, после 6-8 часоваого ребилда, кстати контроллер делал ребилд но перестал отобраджать прогресс на 82%, не отображал, но делал, я в этом уверен, т.к. статус изменился на функциональный только по прошествии нескольких часов. далее на момент поломки из 749 999 мб были свободны только 35 000 мб, после ребилда свободные мб остались такимиже, а занятые превратились грубо говоря из 714 в 476, считай 250 гб куда-то делись. Час чекдиска в итоге дал 135 гиг свободного и 614 занятого, т.е. вернули 150 гигабайт. И вот что теперь делать вроде бы и неплохо, что-то цело, но многово нет, а такого недолжно было произойти, наверное виновата винда?! и как доставть потеряные 100гиг. Есть ли у меня какие нибудь варианты лечения этой проблемы, возможно ли её предотвращёние в будёщем, как вариант можно рассмотреть переход на другую ОС.

Как же можно на сервере и без UPS?
Может быть у вас еще в настройках контроллера стоит политика кеширования записи как "Write Back"?
Если все именно так, то надежную работу массива после отключения питания вообще нельзя гарантировать! Если нужна надежность то ставьте UPS или батарею на контроллер (если контроллер имеет такую возможность). А пока можно поставить режим кеширования как "Write Through" - но упадет скорость работы при записи (иногда очень существенно).
Еще вопрос: А после отключения питания синхронизацию массива проводили?


Я так понял, что диск проверяли отдельно от массива? т.е подключили диск к другому компьютеру и проверяли там.

Ктонибудь может внятно разьяснить для чево и на что влияет рзная велечина block size при создание RAID масива.
Если можно то отнеситесь к каждому по отдельности.

block size 32кб - ..........
block size 64кб - ..........
и так далее.

Если для чего нужен Block Size в RAID массивах - то это из теории RAID'ов. В любой статье написано. Например:
http://www.ferra.ru/online/storage/26107/
http://www.ibase.ru/devinfo/raid.htm

А если о том, на что влияет это размер - то это зависит еще и от типа RAID массива.
Фактически BlockSize - это минимальный размер, которым контроллер будет вести обмен с диском, при запросах на чтение или запись. Т.е. При любом запросе на чтение, контроллер прочитает с диска минимум BlockSize байтов (даже если запрашивали одни байт).
Если запросы идут на последовательное чтение, то выгоднее иметь большой размер BlockSize. В этом случае меньше накладных расходов на обслуживание. А вот если запросы в основном имеют случайных характер (к разным участкам диска), то выгоднее имень маленький размер блока. Т.к. при каждом запросе будет читаться BlockSize байтов, и чем больше BlockSize, тем больше чтения впустую. А сказать конкретно по каждому размеру - все зависит от контроллера и от задачи.

Да к сожалению человеческий фактор никто не исключает, формула упс + 2 х акумулятор + "что-то очень умное что делает 220, но не упс" хватает на час, обычно этого достаточно, но естественно невсегда, да и кстати последний "падёж" был в декабре прошлого года.
Извинете за наглость http://www.promise.ru/production/ata_ra ... raksx6000/ но помоему здесь всё проще. По поводу синхронизациии, кстати промис несоветует делать синхронизацию массива после его пересобирания т.е. проблемы возникшей по необьянимым причинам, синхронизацию, да делал с помощью PAM (promise aray manager) но прорамма "не ИМХО" ущербная, во первых сильно влияет на работу массива, влияние исключительно негативное, выражается в частом подвисании операционной системы, и существенном падени скоростей записи/чтения, проявлятся в момент копиравания как на так и с массива, неоднократно отмечалось падение скорости до 400 кб/с, проблема разрешалась деинсталляцией программы с последующей перезагрузкой системы, ещё контроллер очень любит конфликтовать с ОС перенесёнными с любой матринской платы, такие же проблемы со скоростью, т.е. исключительно новая или идентичная по мат плате винда.

Да статус массива приобрёл критический статус, замены в виде, любого другого идентичного или большего по обьёму жёсткого диска, на контроллере небыло. Соответственно, контроллер попытался восстановить сбойный диск, но диск "стучал", процесс стоял на месте. В мануале по восстановлению массива разрешается отключить сбойный диск и установить на его место идентичный или больший по размеру другой. Диск проверил на другой машине, заменил и пошёл процесс перестройки.
Меня на данный момент интересует существование возможность грубо говоря автоматизции перехода драйвера контроллера в режим "только чтение" на собойном массиве, мне не кажется но у промиса написано что в режиме критикал массив доступен, но тереяет устойчивость, поэтому доступ к массиву происходит в режиме только чтение. А практика такая что этого не происходит, винда пишет на массив, и видимо не только пытается дописать, но и дописывает что хочет, особенно меня добил во время "экспериментов" на уже другом, искуствеено убитом массиве, процесс автоматического чекдиска этого сбойного массива, естественно чекдиск во время загрузки винды происходит с параметром f. Уж сорри за отсутствие смайлов ибо неохота бесится или ликовать, наверное уже просто лень, но может кто нибудь посоветутекакую-нибудь интересную инфу по этому вопросу, а то ме честно нехочется пользоваться советами ala промис-помойка-свалка-друзья на век.

А это "что-то очень умное" может по COM, USB или сети сообщить, что батарейное питание подходит к концу, чтобы в таких случаях сервер корректный shutdown успевал сделать? Это был бы идеальный вариант защиты от электричества.

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


А после поломки накопителя, но до ребилда, когда масив находился в критическом состоянии логическая стркуктура диска была в порядке? Если так, то это уже грабли у Promise, на это указывает еще и:

В свете проблем, могу предположить, что ребилд контроллер так и не довел до нормального завершения.
Но в этом случае боюсь предположить, что творится с массивом сейчас.

Нет сейчас всё нормально, боятся я зе него давно перестал, у контроллера очень долгий процесс наверное "инициализации" т.е. пока он напишет свой статус пройдёт минуты три, промис пишет, что "проверка целостности структуры массива может занять много времени, и это так же время прверки зависит от объёма массива".
Кстати в вопросе выполнения ребилда этой железяке можно кричать ура-ура, может продолжить хоть в винде, хоть после перезгрузки, я вижу проблему только в винде. Иес! целёхонька правда недоконца, ладно перейдём на "попальцам" я удалял четыре ЖПГ по 15 метров каждый в одной папке, потом решил что папка мне вообще-то уже ненужна, удалил её полность, шифт-делит, контроллер запищал, честно через пуск перезагрузил комп, стаус был фанкшнл, мне предложили чекать диск я де откзался, удалённая папка вернулась на своё место, но была неоткрывабальна. Дальше был чекдиск который без f, диск постучал своими внутренностями, контроллер перешёл в статус критикал, проблема обозначилсь.

Это понятно, иначе и быть не может. Контроллер - этоже специализированный компьютер.Т.е. звуковая сигнализация показывает, что на массиве авария,а после перезагрузки все якобы в порядке?
Windows почуяла незакрытый диск. Но при этом завершение работы было корректным.С этого момента массив в состоянии Критикал, но работает. Что со структурой диска? Все в порядке (кроме этой папки с ЖПГ) или данных уже 476GB вместо 714?

Всё пока было ок, но сбоила уже не только папка с ЖПГ, пропала первая по времени запись, папка с образом местного системного диска, после чекера она кстати вернулась, но была уже в папке FOUND.
Чекдиск удалял "неверный аттрибут записи о файле из файла *****"

Ничего не помагает (
Bios последний

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

И с включением контроллера отказываеться работать инет по ВПН


нашел на сайте производителя драйверы и образы биос для контроллера.Можно ли обновить биос для контроллера встроенного в мат плату?

To all:
У меня была раньше проблема: комп зависал иногда (раз в 3 дня), при перезагрузке не видел массив. Выключал комп на 20 минут, включал - всё работало. Думал, контроллер глючный - а оказалось, проблема решилась заменой шлейфов. Хотя те шлейфы на вид были абсолютно нормальные, сам из коробки доставал (из под материнки MSI).
Это всё написал просто так... Может у кого-нить такие же глюки будут странные.