Сервер 1С + SQL 2008 настройка дисков #511605

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

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

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

к

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

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

+100500

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

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

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

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

+ по скорости чтения RAID1 дает прирост, хотя это, возможно, зависит от контроллера (

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

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

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

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

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

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

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. Такой у вас будет запись в файл данных, но этот процесс не особо критичен - он выполняется в фоновом режиме. Хотя, конечно, может стать проблемой при нехватке оперативной памяти. Софтверный рэйд - это скорее всего в любом случае уменьшение производительности если хотите еще увеличить производительность - перенесите бэкапы на другой сервер, а для логов сделайте рэйд 0 из двух дисков. Или оставьте один, а освободившийся диск засуньте в рэйд 0 для файлов данных. ИМХО, производительность - это круто, но про отказоустойчивость забывать не стоит.

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

тоже читал про это, наверно ее разметим с файлом данных, воспользовавшись советом по избежанию фрагментации Еще вопрос рассчитанный на ваш опыт На чем база крутится на SQL 2000 или 2008? как SQL 2000 дружит с 64 битами Читал обсуждение что 2000 быстрее 2008 человек проводил тесты, но аудитория ему так и не поверила. Что вы скажете на этот счет?  (

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

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