Да в общем все нормально только 2 но.
1. Что-то дороговато, посмотрите еще поставщиков.
2. Диски SATA вон из сервера БД. В серверах баз данных их не применяют. А кешем их Вы все-равно не воспользуетесь так как выключать его надобно... замените на 4xSAS 15k 146Gb - за глаза хватит. По мне так и трех бы хватило (а значит и корпуса 815, и контроллера типа 3405 от адаптека).
3. На сколько прожорлива оболочка?
4. Какой именно софт планируете ставить (версии выпусков)?

ALEX_SE:
Отвечу как смогу...
Поставщик баз данных предлагает поставить и железо. Естественно, для него чем дороже, тем лучше. Поэтому вынужден консультироваться.
Дополнительно к основному ПО (указано в вопросе) будет установлено ПО от КроСистем http://www.crosys.ru/products.html CrossChecker и CrossRequest. По "прожорливости" ничего сказать не могу, просто не знаю как ее оценить.
Могу сказать, что некоторые сторонние специалисты посоветовали заменить дорогие и быстрые диски Raptor на дешевые обычные (7200). Сказали, что здесь хорошая RAID-карта, которую нужно оставить и удаленное управление IPMI, которое может упростить работу сисадмина.
К сожалению все

Удаленное управление тут действительно имеется, при чем в отдельном сетевом интерфейсе на матери. И весьма неплохо работает.
А специалистов таких надо слушать с опаской. Я Вам уже сказал - никаких SATA в сервере БД. Тем более что он будет еще и совмещен с прикладными программами...
Райд-контроллер тут и правда не плох, но связи между ним и типом дисков я не вижу.
Цена сервера завышена. Про софт (версию операционной системы и СУБД) Вы не ответили.
В бщем я Вам свое мнение сказалДиски меняем на SAS, корпус можно использовать 1U, если нет (и не будет) необходимости в стойке - можно посмотреть на пьедестальные корпуса, типа 733, они дешевле.

ALEX_SE:
ОС Windows 2003, SQL Server 2005 64-битные.

ALEX_SE:
Уважаемый ALEX_SE!
Прошу посмотреть рекомендации компании (по Вашим замечаниям):
"1) Когда-то что-то обязательно сломается, потребуется установить параллельно другую копию БД - например, оригинальную в дополнение к обновлённой - и минимум по дискам должен быть 1.5 TB. Делать такое хранилище на SAS очень дорого.

2) Поскольку база обновляемая, её желательно хранить на RAID1+0, а не RAID0, иначе при проблемах с любым диском в массиве придётся восстанавливаться с резервной копии. Резервная копия терабайтной базы - штука небыстрая, в самом оптимистичном случае (25 Мбайт в секунду - реальная цифра для SATA или USB с резервной копией) в час будет восстанавливаться 0.025 * 3600 = 90 GB, то есть рабочий день потерян. Самые свежие данные в копии будут на прошлый день, потому что даже инкрементальные копии такой БД придётся делать ночью. В случае RAID1+0 замену можно сделать без перерыва в обслуживании.
То есть RAID1 может оказаться единственным спасением.

3) Кеш-память на чтение используется всегда и везде, а кеш на запись контроллер включает, если в него вставить BBU (battery backup unit), безотносительно технологий SAS и SATA. С помощью этой батарейки контроллер будет хранить не успевшие записаться данные, если отключится питание. Обычно выключенный кеш на запись это совершенно душераздирающее зрелище, со скоростями типа 5 Мбайт в секунду, и приходится включать кеш, даже если батарейки нет, попадая на соответствующие последствия.

4) Я трижды пробовал применить разные контроллеры Adaptec, получив в одном случае систематическую порчу данных, а в двух других в каждый момент времени случайную скорость чтения в диапазоне от 512 Кбайт/с до 50 Мбайт/с. Когда история повторилась в третий раз, я понял, что компании Adaptec не вполне удаётся её основная деятельность, и нужно использовать 3ware или LSI. Сейчас 3ware объединилась с LSI. Может, есть ещё хорошие компании, но я их не знаю.

5) Касательно корпуса - я бы не стал отказываться от дублирования электропитания, потому что электричество в здании плохое, с большими перепадами напряжения, и выход из строя UPS или самих блоков питания случается. Одно питание можно подключить к UPS, другое напрямую в сеть, и это периодически будет спасать".

1. Это что же такого должно быть в базе что бы 10 человек набили терабайт? Под базы таких размеров оборудование идет на несколько порядков другое... Даже на 100 человек на сайте кросиса указана хранилка в 500Гб. И это надо полагать с учетом места под резервную базу и растущие логи. У Вас их 10!
2. Кто и где говорил про RAID-0? Вообще-то если заметили статус у меня тут такой же как и у Вас :)))
2.1 При бакапе полуторатерабайтной БД и необходимости быстрого восстановления про SATA или тем более USB с резервной копией вообще говорить не стоит. Это другие решения которые стоят других денег.
3. Отправьте в школу того кто это написал. Кеш ДИСКОВ отключает не контроллер (вернее контроллер если ему дать соответствующую команду, а такую команду ему дает админ при формировании массива если используется Write Back).
4. Ничего не буду говорить про это вообще...
5. Есть и с резервированием башня. Но от резервного источника отказываться пожалуй нелогично - диски, блоки питания, вентиляторы это то, что отказывает чаще всего. Кстати именно потому я не люблю вентиляторного охлаждения процессоров, гораздо надежнее если кулер пассивный (то есть воздух гоняется через воздухопровод несколькими задними и внутренними вентиляторами, при выходе из строя одного из них все работает). Что до UPS- ставьте линейно-интерактивный ИБП и работайте...

Вам рекомендации дает непосредственно разработчик софта?

Уважаемый, Burbon. Я присоединяюсь к совету ALEX_SE про применение SAS. От себя хочу добавить, что, если вы хотите обезопасить себя от сбоев связанных с дисками, можно создать RAID5 из 3-4 дисков SAS + еще подумать о hot spare. Из минусов RAID5 низкая скорость записи, зато высокая скорость чтения, imho для БД это хорошо.

Не такая уж и высокая особенно в режиме degradedТем более что база может порушиться далеко не только из-за сбоя диска. Могу сказать что у меня только в 1 случае из 30 рестор связан с аварией оборудования.

ALEX_SE:
Уважаемый ALEX_SE!
1. Информационный массив около 500 Gb. ("Дофин-4", что-то похожее: http://description.sec.ru/index.cfm?pid=20). Информацию в базы не набивают, ею пользуются, она уже есть.
2. У меня статус в другой области знаний.
Да, рекомендации дает разработчик софта, поэтому и приходится обращаться к Вам.
Спасибо за помощь.

Богданов Сергей:
Уважаемый Богданов Сергей, спасибо Вам за совет.

1. Да слышал я про этот продуктОткуда она есть, информация, Вы не задумывались? Это же практически CRM немного переделанный... ЧТО можно напихать в терабайт? И почему разработчик на своем сайте дает другие (в 3 раза низкие) рекомендации для числа юзеров в 10 раз большего?
2. Ну в общем я еще не сошел с ума что бы страйпы гольные на сервера советовать :)
3. А кто занимается внедрением?
Хотя, с другой стороны, нагрузка почти отсутствует. Можно и SATA если интегратор подпишется что тормозов не будет, а если будут то исправятся за его счет...
Но стоимость-таки завышена :)
А там думайте сами.

вариант - берете пару тысячников саташных и на набортный контроллер. Бакап разумеется делается на отдельное внешнее устройство - сервер или стример. А дальше по результатам добиваете дисковую до нужного уровня. Свободные диски - в десктопы или бакап-сервер.

ALEX_SE, ну при использовании массива всегда в коморке должен лежать запасной диск, чтобы degraded-режим был предельно непродолжительныйТем более, что нагрузку на диски 10 человек не создадут, как Вы сами сказали.
Burbon, судя по вашей беседе, делает упор на безопасность со стороны железа. Думаю, RAID-5+hotspare хороший вариант. Чтобы вышло из строя в короткое сразу 3 диска - вероятность 1/1000 за день. :)

Богданов Сергей:
Что бы деградед-режим был непродолжителен надо HotSpareНу вообще у меня не раз вылетали нескольки дисков из массива правда в 99% случаев это было по вине контроллера/шлейфов. Что касаемо безопасности избыточный массив её не поднимает, для этого нужен бакап. Да и тормозная штука этот R5 :)