Имеется сервер c 6 винтами по 120 гб
на сервере доступны RAID 0 1 5 1+0
Посоветуйте как лучше настроить диски, с упором на производительность?
пока мысли такие
1 диск для ОС + 1с + SQL (Размер кластера фс 64 кб)
3 диска объединенные в RAID 0 для файла данных SQL (размер кластера фс 64 кб)
1 диск для файла транзакционных логов SQL (размер кластера 32 кб)
1 диск для резервных копий (размер кластера 1 мб)

В настройке серверов опыта нет, подскажите как лучше поступить?

Бекапы на другой сервер вынеси...

угу, и выход любого из дисков (кроме диска с бэкапами) приводит к ополной остановке работы..

(2) к (0)

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

(0) может быть имеет смысл делать три рэйда 1 - для ОС, mdf и ldf. Бэкапы делать куда-нибудь на диски с ОС и сразу переносить на другой сервер (или как говорит ДенисЧ сразу делать по сети на другой сервер).
Если база > 120 гигабайт, или может в ближайшее время сильно вырасти - я бы поставил ОС на отдельный рэйд 1, а логи и файлы данных свалил на рэйд 10 (если оперировать можно только имеющимися дисками и покупка новых не предусмотрена)

(5)+100500

у меня сейчас 4 диска SAS в райд-0. Все на нем: скуль, БД, система. Лог транзакций отсутствует (модель восстановления simple). Работает вполне шустро.

Небольшой нюанс: это не сервер :)

(4) а что будете делать если у вас внезапно откажут 2 диска? Например с бэкапами и файлами данных? Если все в порядке - ваша конфигурация вполне приемлима.
>>Ну и попутно задам вопрос какой ресурс сервера наиболее важен для повышения производительности?
Какая деталь в машине наиболее важна для скорости?

(5) рейд 1 не дает увеличения в скорости для файловых операций
сервер панель, у него только 6 слотов для дисков.
Ставить данные и логи на 1 диск боюсь из-за фрагментации, может и зря но все же.
>Какая деталь в машине наиболее важна для скорости?
движок...

(9) >>движок
угу, особенно если колеса проколоты. Я это к тому, что узкое место сервера определяется по месту. Обычно внимание уделяют дискам, процессору, оперативной памяти и сети.

>>Ставить данные и логи на 1 диск боюсь из-за фрагментации
ну, как вариант, вы можете просчитать примерный прирост за год (2-3-10 лет, до следующей модернизации оборудования) и преждевременно увеличить место занимаемое этими файлами (сделать их нужного размера) - файловой фрагментации не будет..

+(10) по скорости чтения RAID1 дает прирост, хотя это, возможно, зависит от контроллера (http://www.pcguide.com/ref/hdd/perf/raid/levels/singleLevel1-c.html)

(10) Спасибо за совет, про такое решение проблемы фрагментации даже не подумал

(9)Делай 3 рейда первых и не мучай себя... Либо покупай ещё 4 диска и делай под логи и данные отдельные 1+0....

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

(14)При конфигурации в (0) при первом же сбое любого диска (кроме бекапного) приоритеты у тебя поменяются мгновенно.....

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

(15) базу восстановить  - делов на 15 минут. другой вопрос, что 15 минут может быть критично, тогда да.

(14)
Random Read Performance: Good. Better than a single drive but worse than many other RAID levels
Таким у вас будет чтение из файла данных.

Sequential Write Performance: Good; again, better than many other RAID levels.
такой у вас будет запись в журнал транзакций - очень даже критичная операция

Random Write Performance: Good. Worse than a single drive, but better than many other RAID levels.
Такой у вас будет запись в файл данных, но этот процесс не особо критичен - он выполняется в фоновом режиме. Хотя, конечно, может стать проблемой при нехватке оперативной памяти.

Софтверный рэйд - это скорее всего в любом случае уменьшение производительности

(16) если хотите еще увеличить производительность - перенесите бэкапы на другой сервер, а для логов сделайте рэйд 0 из двух дисков. Или оставьте один, а освободившийся диск засуньте в рэйд 0 для файлов данных.

ИМХО, производительность - это круто, но про отказоустойчивость забывать не стоит.

Советую еще базу TempDB выносить с диска, где будет стоять система. 1С очень любит под все временные таблицы создавать

(19) тоже читал про это, наверно ее разметим с файлом данных, воспользовавшись советом по избежанию фрагментации
Еще вопрос рассчитанный на ваш опыт
На чем база крутится на SQL 2000 или 2008? как SQL 2000 дружит с 64 битами
Читал обсуждение что 2000 быстрее 2008 человек проводил тесты, но аудитория ему так и не поверила. Что вы скажете на этот счет?  (http://sql.ru/forum/actualthread.aspx?bid=1&tid=743022&pg=1)

(20) tempdb советуют выносить на отдельные "шпиндели". В вашей конфигурации она и так лежит отдельно.
SQl Server 2000, ЕМНИП, не дружит с 64-мя битами, только с IA-64.

Очень рекомендую SQL 2008. Прогресс знаете ли. Тесты в пользу SQL 2000 скорее говорят об однобокости тестов, чем о продвинутости древней версии СУБД