KORSAможете сказать какой вариант будет оптималныи и почему ?Лучьше второй вариант, а на съэкономленные деньги купить несколько десятков дисков :-) И ещё памяти.

Если тупо выбор по производительности процессоров, то конечно первый быстрее раза в два минимум. Но производительность сервера определяется не только производительностью процессоров.
KORSAнужно ли 40 ядер не слишком ли многоЯдер много не бывает :-) Тем более DWH, да с паралельной OLAP-нагрузкой...

Ivan_Pisarevskyозвучьте дисковую подсистемуС таким количеством дисков и такими объемами хранилища - однозначно дуал процессоры. Т.е. 12 ядер с запасом и 64 ГБ ОЗУЯ бы не был столь категоричен, и 64 гб памяти под прирост 50 гиг базы в год сроком на 3 года... прямо скажем не много, и уж точно не "с запасом". 64 гига можно на старте воткнуть, но платформа должна держать как минимум гиг 200, чтоб не ставить раком диски в случае возрастания нагрузки.Запас для платформы конечно не помешает, но в принципе база в несколько сотен игов - копеечная, ничего особенного не надо.

Ivan_Pisarevsky4 САТА под логи и дисковая полка под базу. В OLTP именно логи определяют скорость работы БД. Не надо их по остаточному принципу :-)

Ну и админы СУБД знают, что маниакальное стремление админов не-СУБД разместить ОС на отдельных дисках ничем не оправдано - это просто выбросить диски. Нагрузки от ОС на диски вообще нет.

Ivan_PisarevskyalexeyvgОС на отдельных дисках ничем не оправдано - это просто выбросить диски. Нагрузки от ОС на диски вообще нет. Как по мне, так при наличии внешней дисковой полки разместить ОСь на внутренних дисках идея вполне здравая, вот если бы данные на внутреннем рэйде, то да, отдельные диски для ОСи бред. Да, если внешняя, то правильно, пропустил...
Di_LIneIvan_Pisarevskyвот если бы данные на внутреннем рэйде, то да, отдельные диски для ОСи бред.
Всё яйца в одной корзине - бред. Пусть даже она дисковая. :) Это слишком обобщённо.
Фактически, при выходе из строя любой части дисковой подсистемы придётся эту часть восстанавливать. Количество восстановлений за период времени прямо пропорционально количеству этих частей. Это если не всё сразу вылетает.

Так что для админа "всё в одном" удобнее и менее трудомко.

Di_LIneНЕ знают, что как приходится трахатцо, в случае системы накрывшейся медным тазом. Или при переносе на другое железо.Да, не знаем мы это...
Я вот не понимаю разницы - создают рейд, а потом восстанавливают системный бакап, всё это удалённо (серверы в другой стране, в датацентре).
На прошлой работе так работало много серверов, у админов и мысли не возникало, что это как-то очень сложно.
Спрашивали нас только со стороны производительности - отобрать пару дисков от баз для системы или не отбирать.

Dimitry SibiryakovalexeyvgНагрузки от ОС на диски вообще нет.

В случае какого-нибудь Линукса - может быть. Но попробуй посмотреть на дисковую активность
процесса System у Windows. Мы говорим конкретно о железе для MSSQL (например, версии 2008 R2, но для других версий то же самое). Как вы понимаете, не под линуксом :-)

Вот в этом случае активности нет. Конечно я долго смотрел, много лет и не на одном сервере.

Dimitry SibiryakovОн непрерывно что-то пишет в WBEM логСколько типично будет Мб/сек, IOPs записи в этот WBEM лог? Думаю, не наполовину диск загрузит?
Di_LIneНакти бекап с ними на мать, в которой их нету.
(Где тут смайлик с попкорном...) Чего-чего там нету???

Бакап нужно иметь рабочий, тренировочки устраивать с восстановлением.
Di_LInealexeyvgТак что для админа "всё в одном" удобнее и менее трудомко.
Простота - хуже воровства. (Ц) Что то у вас не сходится :-) То вы считаете, что это неподъёмно сложная для админа задача, то слишком просто (видимо, подразумевается, что просто в ущерб чему-то???).

Это не только проще, но и на халяву получаете 2 диска - производительность возрастает.