Оптимальная конфигурация дисков для SQL Server 2008R2

19

У меня довольно занятый сервер баз данных под управлением SQL Server 2008 R2, который имеет следующую настройку:

SATA RAID 1 (2 накопителя) - ОС / Программы
SAS RAID 10 (4 диска) - Sql Database Files (данные и журналы)
SAS RAID 1 (2 накопителя) - TempDB (данные и журналы)

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

Обновить:

Для тех, кто запросил дополнительную информацию об оборудовании:

Диски SATA (используемые для раздела ОС / программы): WD 7200 RPM 3 Гбит / с, 3,5 дюйма SATA
В других массивах используются диски SAS: Seagate 15K RPM 6 Гбит / с, 3,5 дюйма SAS
Используемый контроллер RAID: порт LSI 9260-8i SAS / SATA 6 Гбит 8

Обновление 2:

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

Оставьте все как есть - я, вероятно, не сделаю намного лучше
Переместите мои 2 диска SAS RAID 1 в существующий массив RAID 10, чтобы он состоял из 6 дисков.
Переместить мои файлы журналов на SAS RAID 1 и / или переместить TempDB (данные или журналы) обратно на RAID 10

sql-server hardware

— DanP
источник

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

— Марк Стори-Смит

С появлением на рынке высокопроизводительных NVMe и других SSD-дисков RAID больше не имеет особого значения с точки зрения рекомендаций по конфигурации дисков SQL-сервера . Дисковые пулы (дисковые пространства) - это путь вперед. Однако вам потребуется логически разделить тома, чтобы лучше устранять проблемы с производительностью диска.

— Faces of IT

14

Варианты этого вопроса появляются регулярно:

Есть также случайные ссоры из-за разделения данных / журналов "наилучшей практики".

Без более подробного анализа того, что делает этот сервер, применяется тот же совет, что и ранее.

RAID 1 для ОС
RAID 10 (6 дисков) для данных / журналов / tempdb

В сплите редко бывает какая-либо точка с таким небольшим количеством шпинделей. Один массив с большей емкостью операций ввода-вывода обычно впитывает комки и неровности вашей рабочей нагрузки лучше, чем 2 меньших массива.

Один из вариантов, который стоит протестировать, - это поместить tempdb на диск с ОС. Делайте это только в том случае, если у вас есть репрезентативная рабочая нагрузка, которую вы можете повторно воспроизводить, чтобы обеспечить правильное сравнение конфигурации. Если вы будете использовать эту схему в производстве, убедитесь, что рост базы данных tempdb ограничен, чтобы вы случайно не использовали все свободное место на диске ОС.

Принимая во внимание, что ваши диски ОС имеют скорость 7200 об / мин, я был бы удивлен, если бы база данных tempdb в конфигурации дисков ОС принесла какую-то пользу.

— Марк Стори-Смит
источник

7

Все зависит от вашей рабочей нагрузки, но только с 6 накопителями это ограничивает ваши возможности. Если ваша рабочая нагрузка не сильно зависит от базы данных tempdb для таких вещей, как сортировки, хеш-таблицы и изоляция моментальных снимков, то вам лучше использовать вместе 6 дисков SAS в RAID 10. Однако, если вы знаете или располагаете показателями, чтобы доказать, что Tempdb интенсивно используется, тогда вы должны держать его отдельно, как и у вас.

— Патрик Кейслер
источник

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

— Данп

2

Помните, что SQL Server должен физически записывать все транзакции в журнал как часть фиксации, поэтому вы хотите максимально возможную производительность записи в вашей конфигурации. RAID 10 обеспечивает лучшую производительность записи, чем RAID 1, поэтому я бы оставил журналы на более быстром томе.

— Патрик Кейслер

2

Это очень сильно зависит от того, что вы подразумеваете под «очень занятым»: различные шаблоны рабочей нагрузки (интенсивная запись или нет, массовые операции, общие или нет, уровень одновременного доступа, если назвать только три из множества переменных) могут оказать сильное влияние на выполнение любого данного расположения шпинделя.

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

Без дальнейшей ссылки на вашу рабочую нагрузку (и спецификации этих дисков и любого контроллера, который находится между ними и машиной) я был бы склонен пойти на три тома: один для программ OS + и tempdb (данные), один для основной БД данные и третий для журналов (как базы данных tempdb, так и основных баз данных).

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

— Дэвид Спиллетт
источник

Я бы определенно охарактеризовал нашу среду как «тяжелую запись» - я обновлю свой вопрос более подробными спецификациями оборудования в понедельник.

— Данп

Есть идеи о количестве дисков, которые есть у OP? Я думаю больше о Рейде 1, который он имеет для файлов журнала. Это не похоже на отличный вариант для целей записи, и файлы журнала AFAIK не ограничены для чтения, но пишут ..

— Marian

Я добавил дополнительные характеристики об оборудовании машины.

— ДанП

1

Это недоразумение может лежать в основе многих рангов разделения данных / журналов, поэтому извиняюсь, но я собираюсь это высказать. «... поскольку каждая запись включает обновление как журнала, так и файлов данных» - нет, это не так. Запись на страницы данных происходит на контрольной точке, а не на каждой модификации.

— Марк Стори-Смит

1

@DavidSpillett Правда, всегда будут случаи, когда разделение выгодно. Ключевым моментом является то, что вы протестировали и подтвердили, что конфигурация была полезной для этой конкретной рабочей нагрузки.

— Марк Стори-Смит

2

Фактический ответ зависит от ваших потребностей, но обычно «помещать данные и журналы в разные массивы» важнее, чем «помещать tempdb в свой собственный массив».

Учитывая количество доступных вам дисков, моя отправная точка будет:

Два диска, RAID 1 - операционная система, исполняемые файлы, файл подкачки.
Четыре диска, RAID 5 - все файлы данных (альтернативно, RAID 1 + 0)
Два диска, RAID 1 - все файлы журналов

Что нужно сделать, это использовать SQLIO для проверки производительности различных конфигураций дисков.

— Гринстоун Уолкер
источник

Это определенно представляет «другую сторону» совета, который я прочитал. Хотелось бы, чтобы был определенный метод определения того, какой из вариантов был бы лучше, не прибегая к «опробованию» в производственной среде.

— ДанП

2

@DanP Ну, лично я пошел бы на совет Марка и выбрал бы RAID10 с остальными дисками (кроме ОС). Насколько мне известно, файлы журналов требуют интенсивной записи и требуют большей производительности, чем то, что предлагает RAID 1. Но я не эксперт по аппаратному обеспечению. Просто мои 2 цента.

— Мариан

2

Я должен отметить, что мое мнение исходит только из опыта прошлой (вроде) неудачной миграции на лучший сервер, но с более низкой производительностью. Мы никогда не проверяли реальную нагрузку на этом новом сервере, у нас никогда не было шансов, сервер не был готов вовремя. Оказывается, тестирование сервера ДО перехода на производственный процесс должно быть ОБЯЗАТЕЛЬНЫМ. Извините за акцент. Итак, моя мантра для всех миграций / обновлений такова: ТЕСТ, ТЕСТ, ТЕСТ, ... как можно больше офигенных тестов.

— Marian

1

Не уверен, стоит ли начинать с RAID 5 или SQLIOSIM ... давайте перейдем к последнему, поскольку первое говорит само за себя. SQLIOSIM - это инструмент для проверки правильности и стресс-тестирования , а не инструмент для тестирования производительности или нагрузки. Ему абсолютно не место в сравнении производительности config-X и config-Y для workload-Z. Все, что вам скажет, это то, насколько хорошо config-X работает против config-Y при запуске SQLIOSIM. Если вы хотите сравнить производительность для workload-Z, протестируйте workload-Z.

— Марк Стори-Смит

1

@ GreenstoneWalker «RAID1 быстрее для записи, чем RAID1 + 0» - это нонсенс. Откуда появилась эта идея?

— Марк Стори-Смит

-1

В зависимости от того, для чего вы используете БД (OLTP или хранилище), ваша конфигурация выглядит как хорошая общая конфигурация. Если бы у вас было больше дисков, у вас было бы больше вариантов.

Вы можете получить лучшую производительность, если переключите диск для вашей TempDB на RAID 0 (чередование). Это увеличивает риск неудачи, но, поскольку TempDB только буферизует данные, вы не можете их потерять. Поэтому большинство людей считают это разумным компромиссом. Просто держите запасной (или горячий запасной).

Одна вещь, которую вы не упомянули, но можете попробовать (если вы еще этого не сделали): Microsoft рекомендует разбить вашу TempDB на несколько файлов (по одному на процессор). Конечно, лучше всего, если они находятся на разных дисках, но просто наличие отдельных файлов помогает. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx

— TimG
источник

4

Tempdb используется для многих целей, но не рассматривайте его как одноразовую базу данных и размещайте ее на RAID 0. Имейте в виду, что в случае сбоя тома RAID 0 SQL Server не сможет запуститься.

— Патрик Кейслер

Я действительно создал одну временную базу данных на ядро, как и предлагалось, но спасибо за то, что поднял эту точку :)

— DanP

1

Ну, эти предложения не очень хороши и не подходят для любой среды. Первый упоминается @PatrickKeisler ранее. Второй миф, который Пол Рэндал развенчал некоторое время назад. Эта статья такова: миф администратора баз данных SQL Server в день: (12/30) база данных tempdb всегда должна иметь один файл данных на ядро процессора . Так что документация MS может быть неправильной, не принимайте это наизусть.

— Мариан

2

«так как TempDB только буферизует данные, вы не можете потерять их» ... и я уверен, что пользователи системы оценят, что в течение X часов простоя они страдают, пока a) оперативники копаются в подвале для замена диска или б) администратор БД пытается объяснить службе поддержки, как переместить базу данных tempdb со своего мобильного телефона.

— Марк Стори-Смит