Итак, чтобы не плодить тем, напишу в этой, есть сервак, внешний контроллер sas с bbu, так же имеем 7 винтов sas 10k (кол-во винтов можно уменьшить, увеличить никак). Задача: какие рэйд массивы организовать для mssql+1C УПП (20 пользователей). База 1С будет вближайшее время активно заполняться, поэтому запись будет достаточно интенсивной, насколько я понимаю, 5 рэйд массив тут будет проигрывать по этому параметру 10 рэйд массиву, так же надо будет вынести на отдельный диск лог файл для увеличения быстродействия. Пока у меня в голове такой вариант. Из 4 дисков создать 10 рэйд, там разместить систему и базу, из двух оставшихся сделать зеркало и туда лог вести, оставшийся 7-й сделать хот спаре на оба массива,если где вылетит из двух массивов, туда и подцепится. Критикуйте, есть еще другие интересные варианты?

defecator,

Требуется компромисс быстродействия и надежности в данных условиях.
авторна мой взгляд, систему и СУБД вынести на отдельный диск - от них быстродействия не требуется особого.
На одиночном диске? Не айс, имхо, так как отказоустойчивость будет не на высоте, пусть уж торчат на 10 массиве, в крайнем случае на 2 LUN порезать 10 массив, но так как bbu есть и других ролей типа КД на сервере не будет, то смысла большого не вижу резать.
авторлог-файл - на рейд 0. Благо в MSSQL восстановить лог файл можно без проблем, если что
В случае чего, 0 массив тупо выйдет из работы, разве MS_SQL будет работать без лога? К тому же, я ни разу его не восстанавливал, можно предварительно поробовать, но в любом случае - это время, время простоя различных отделов (т.к. все же УПП), что крайне не желательно. Сервер должен работать без перебоя в рабочее время (сорри за тафтологию), понятно, что лучше кластер и т.п., но пока надо свести к определенному балансу при данной конфиге.

авторК тому же они все равно все через один контроллер подключены, запись пойдет через один и тот же кэш буфер контроллера
На борту будет кэш в 512Мб мало? У нас же не будет 100 пользователей в системе одновременно колбаситься)
авторбыло бы 2 контроллера и винтов поболе, можно было бы попробовать разделить, а так я лично особого смысла не вижу.
А то, что лог будет писать на отдельное зеркало, и им не надо будет дополнительное время, чтобы синхронизироваться с основным массивом, работают сами по себе. А так, если это будет один массив 10 уровня, то это 3 пары, которые между собой синхронизируются, и если лог будет писаться на этот же массив (ну пусть другой лун), но все равно головки винтов будут скакать и синхронизироваться друг с другом, а это потери будут существеннее, другое дело, что или 10 массив из 4 винтов или из 6, тут по надежнее выглядит.
авторЗато сколько незабываемых часов и впечатлений !
Острые ощущения хорошо, но только если они тебя касаются, если других затрагивают - не айс.
авторВозьмите 8 SAS и соорудите на контроллере нормальный RAID10.
8 без хот спаре? Тупо все один массив и резать на луны под систему, данные и лог? А что есть не нормальный рэйд 10, есть критерии? Да, понятно, что при увеличении количества жестких дисков увеличивается надежность в некоторых случаях быстродействие, но здесь уже больше не выбить.
авторНенужно пытаться изобрести велосипед с квадратными колесами - невзлетит.
Должно стабильно работать с приемлимым быстродействием. В чем квадратность колес?
P.S Скачаю потом обработку от гилева, загоню тест на производительность в условных попугаях при разных рэйдах, самому интересно)

авторесли включен райтбэк
Включен будет, т.к. BBU будет присутствовать.
авторНу я ж незнаю что у тебя за железка.
сервер на базе Fujitsu PRIMERGY RX300 S6, рэйд контроллер там со своим кастомайзингом, но на базе LSISAS2108
авторСистему можно на обычный SATA или даже IDE ставить.
А скорость доступа к контроллеру по интерфейсу? Обмена с переферией? Оптимизированность работы в массиве? Уменьшенное время доступа к инфе? Время наработки на отказ?
авторДля этого квалифицированный и подготовленный человек должен находиться в момент сбоя на площадке со всем необходимым ЗИПом наперевес и тем не менее гарантирован даунтайм даже по твоим же крайне оптимистичным оценкам напрочь оторванным от реальности как минимум полчаса.

В топку такой экстрим.
Согласен, что-то 20 минутами там может и не пахнуть, минут 5-10 только вкурить в ситуацию надо будет (что, откуда и из за чего) и потом накатывать софт, разворачивать базы..Очень сомнительная затея.
авторЕсли у тебя строго постоянно в лог пишется вдвое меньше информации чем в базу, то разделение на 2+4 может сравняться по скорости с 6, а если пойдет перекос и от соотношения 1к2, то единый массив будет выгоднее 4+2, причем не зависимо в какую сторону перекос.
Спс, надо покумекать на досуге, но думаю, что без конкретных данных о работе в системе сложно будет что-то сказать сейчас.

Да, не написал, 2 проца Xeon E5640 4C/8T 2.66 GHz 12 MB кэш и 8 Гб ддр-3 есс