Как мне настроить эти диски на SQL Server для конфигурации BI?

8

Предполагая постоянную память (32 ГБ) и ЦП (4), 2 х дисковых массивов, у меня есть следующие диски

  • 2 х 150 (10 КБ)
  • 6 х 150 (15 КБ)

Все они локальные диски.

Мои требования

  • Моя база данных 350 ГБ и установлен по умолчанию 10% роста
  • Моя ОС и SQL Server - это Сервер 2k8R2 (C: диск ОС + страница + приложения = 55 Гб)
  • Требования к журналу составляют около 70 ГБ и установлены по умолчанию 10% роста и обычно усечены
  • Мой TempDb составляет около 12 ГБ в настоящее время и установлен по умолчанию 10% роста

Моя проблема в том, что я пытаюсь понять, куда лучше всего поместить TempDB, OS и Log. Мой опыт ограничен в оптимальной конфигурации этих двух

Это не онлайн транзакционная система. Он выполняет интенсивную запись данных (новые данные + перестройка / переоценка индексов), а затем интенсивное чтение данных (по моим оценкам, около 50/50), обработка которых занимает около 13 часов, а затем просто тишина.

Насколько я понимаю, TEMPDB интенсивно используется во время обычной обработки по сравнению с журналом.

Моя идея заключается в следующем

  • 2 x 150g (15k) Raid 1 = 150g для OS + TempDB
  • 2 x 150g (10k) Raid 1 = 150g для LOG (обратите внимание на более медленные диски здесь)
  • 4 х 150 г (15 КБ) Raid 5 = 150 г для данных

Это звучит как хорошая идея? Затем я мог бы поменять местами Log + TempDB, если это необходимо.

Я нарушаю кардинальные правила, такие как никогда не помещать TempDB на диск ОС из-за проблем с подкачкой , или, возможно, никогда не помещаю журнал на более медленный диск, чем данные ?

Редактировать:

У нас также есть SSAS в системе, и конечные пользователи имеют доступ только к кубу. Чтение 50% выше основано на времени, необходимом для обработки базы данных SSAS.

sql-server-2008-r2 business-intelligence disk-structures Прит Сангха
источник

Ответы:

7

2 * 10k RAID1 для ОС, 6 * 15k RAID10 для всего остального. Честно говоря, с таким количеством дисков 1 массив является самой безопасной и обычно самой быстрой ставкой.

Если у вас есть время на тестирование и у вас есть реальная, воспроизводимая, измеримая рабочая нагрузка, то непременно сделайте тестовый запуск с вашей базой данных tempdb на диске ОС (caveat: ограничьте рост файла tempdb, чтобы убедиться, что вы не разбрызгиваете ОС) , С другой стороны, вы можете увидеть умеренное улучшение загрузки и обслуживания данных, если вместо этого вести журнал, поэтому стоит провести один или два теста, если позволит время.

Марк Стори-Смит
источник
Есть ли что-нибудь, что можно иметь с дополнительными массивами? Разве TempDB не должен быть в отдельном наборе массив / шпиндель? Я оцениваю 50/50, так как он основан на 50% обработки DW и 50% обработки SSAS (6 часов чтения).
Прит Сангха
Я не вижу упоминания о кубе служб анализа в вашем исходном вопросе. Обращаются ли к реляционной базе данных и кубу конечные пользователи или только куб?
Марк Стори-Смит
1
+1 Мне нравится твоя рекомендация. Стоит отметить, что если он поместит tempdb на диск с ОС, то он определенно ограничит максимальный размер файлов базы данных. Мы все можем согласиться с тем, что мы не хотим, чтобы фальшивые файлы базы данных заполняли этот конкретный диск.
Томас Стрингер
1
@PreetSangha Belief - отличная основа для планирования развертывания сервера или хранилища. Вам нужно потратить некоторое время на изучение и понимание того, почему это уместно в некоторых сценариях, а не в других. У отделения вашего куба от реляционной базы данных здесь могут быть ноги, но кто может сказать, не проверяя его. Там нет жесткого и быстрого, один размер подходит всем, я боюсь, JFDI подход к этому.
Марк Стори-Смит
2
Если вы можете протестировать и измерить различные сценарии с вашей рабочей нагрузкой, это может оказаться правильным. Когда / если вы не можете, один большой пул максимально быстрого хранилища будет впитывать комки и удары лучше, чем выстрел в темноте. Не стесняйтесь заходить в чат, если вы хотите поделиться идеями. Есть несколько постоянных с большим опытом работы с SSAS, чем у меня, у которых могут быть предложения по определению, как / если вы должны отделить куб от базы данных.
Марк Стори-Смит
3

Я согласен с Марком в том, что идеальный подход состоит в том, чтобы поместить два более медленных диска в RAID 1 только для O / S, а остальные диски в RAID 10 для всего остального. Это было бы идеально.

Однако, учитывая размеры, которые вы указали, это в значительной степени позволяет вам начать с минимальным запасом ошибок и отсутствием возможностей для роста. И, кстати, если кто-то скажет вам, что диски имеют 150 ГБ, они могут на самом деле быть меньше (146 ГБ?) В неотформатированном виде, что, вероятно, означает, что не все подходит сразу.

К сожалению, рабочая нагрузка включает в себя тяжелые записи, и для этого RAID 5 ... не ваш друг.

Если вам удастся немного сэкономить, есть пара подходов:

  • Еще два 15k дисков такого же размера. В зависимости от того, что означает «2 x дисковых массива»,> 8 дисков может означать, что необходим новый контроллер RAID. (И / или шасси большего размера, возможно.)

  • Два твердотельных накопителя ~ 120 ГБ (PCI-Express или SATA) в программном RAID 1 для данных / журнала TempDB и файла журнала базы данных. На самом деле это может быть самое быстрое решение, и может стоить значительно меньше, чем 2 15-килобайтных диска корпоративного класса (не говоря уже о сопоставимом RAID-контроллере). Это предполагает наличие доступных слотов / портов на материнской плате, которые, вероятно, есть.

Если управление не пойдет на бюджет (эта ситуация пахнет тем, что старое оборудование перераспределяется для нового проекта ... что означает, что бюджет равен нулю), вам придется использовать RAID 5 из-за нехватки места, потому что нет способ избежать этого без большего количества доступных дисков. В этот момент, вероятно, лучше всего разместить 2 более медленных диска в RAID 1 только для O / S, а остальные - в RAID 5 для максимизации пространства. Если вы вынуждены использовать RAID 5 для какой-либо части этого, руководство должно подписать (письменно), чтобы понять, что это означает с точки зрения производительности.

Джон Сайгель
источник
Спасибо. Это сервер клиента, поэтому он примет окончательное решение, но мы признаем, что большие быстрые избыточные полосы - лучшее, к чему мы должны стремиться. Наши собственные серверы используют большие полосы SSD.
Прит Сангха