Как мне настроить RAID-массив SSD-дисков на моем SQL Server?

14

Я создаю SQL Server с 48 ГБ ОЗУ, 1 ЦП и 8 жесткими дисками SATA III (6 ГБ / с) (128 ГБ Crucial m4) и контроллером LSI MegaRAID (SAS 9265-8i). Я ожидаю, что типичная рабочая нагрузка будет в основном читать. Будут некоторые периоды более интенсивной записи (ежечасные синхронизации данных с сторонними поставщиками данных - еженедельное резервное копирование), но я подозреваю, что типичное соотношение чтения / записи составляет около 90% операций чтения / 10% операций записи.

Вариант 1:
логический диск C: - RAID 1 (2 физических диска) - ОС
Logical Drive D: - RAID 10 (6 физических дисков) - файлы DB / logs / tempdb / backups?

ИЛИ

Вариант 2:
логический диск C: - RAID 1 (2 физических диска) - ОС
Logical Drive D: - RAID 1 (2 физических диска) - Db Files
Logical Drive E: - RAID 1 (2 физических диска) - файлы журнала / резервные копии?
Логический диск F: - RAID 1 (2 физических диска) - tempdb

ИЛИ

Вариант 3:
другие предложения?

Я думаю, что вариант 1 даст мне лучшую производительность, так как вся активность БД будет распределена по 3 дискам (и зеркально отражена по другим 3 в массиве), хотя вариант 2, кажется, имитирует традиционную мудрость (которая, кажется, больше применима к механическим диски, чем твердотельные накопители). Похоже, переполнение стека прошло с опцией 1 .

Я предполагаю, что с SSD все в порядке, чтобы поместить все на один логический диск, так как ваш сервер, вероятно, более ограничен ЦП, чем ограничен ввод / вывод в этот момент?

Другой вопрос, который у меня есть, где я должен размещать ночные резервные копии? Мы не хотим, чтобы резервные копии замедляли работу остальной части SQL-сервера, и я предполагаю, что запись резервных копий в том же месте, что и в журналах, является хорошей практикой, поскольку в обоих случаях поведение чтения / записи является последовательной записью.

sql-server configuration Робби
источник
Когда-то я верил, что логическое распределение приносит пользу, но после довольно обширных исследований (у Майкла, возможно, еще есть некоторые из них), мы пришли к выводу, что логическое распределение при целевом уровне не улучшает производительность. Так что, если мы говорим о физическом (вращающемся) диске, и вы хотите использовать 8 файлов данных, чтобы воспользоваться преимуществами сродства ядра, не имеет значения, было ли это 8 файлов на одном логическом томе (на одном физическом диске) или если Вы вырезали 8 логических разделов для этих 8 файлов (на одном физическом диске). Я думаю, вы обнаружите, что это похоже на логическое сокращение вашего SSD
Eric Higgins

Ответы:

9

Традиционные знания о RAID не подходят для SSD. Они действительно не нуждаются в чередовании (RAID0). Они склонны к отказам по-дизайну, но RAID-1, как правило , не является правильным ответ на SSD по двум причинам: а) расточительно, половинки емкости массива SSD (и они являются дорогими) и 2) SSD - накопителей характеристики отказов провода по отношению к обоим дискам в зеркале сбой через очень короткие промежутки времени (т.е. коррелированные сбои) и, таким образом, делает весь массив бесполезным Посмотрите Дифференциальный RAID: Переосмысление RAID для Надежности SSD для более длинного обсуждения. Некоторые рекомендуют использовать Raid-6 для SSD.

Кроме того, общепринятая схема размещения файлов в SQL Server не распространяется на твердотельные накопители. Я бы порекомендовал вам посмотреть SQL на твердотельных накопителях: Hot and Crazy Love и просмотреть ссылки на тесты в этом ответе .

Ремус Русану
источник
Хороший вопрос, с RAID 10 я, вероятно, более уязвим к коррелирующим сбоям. Спасибо за дифференциальное соединение RAID.
Робби
8

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

  • Резервные копии ДОЛЖНЫ быть на отдельной машине. Бессмысленно иметь резервные копии, к которым вы не можете получить доступ в случае, если сервер работает в дыму.
  • Существует некоторая ценность в разделении дисков данных и журналов, так что сбой массива данных позволит вам выполнить резервное копирование журнала.
  • Помните, что у вас нет горячего резерва.
  • Помните, что у вас есть диски потребительского уровня. Не думайте, что они будут такими же надежными, как и эквиваленты предприятия, при кратной стоимости.
  • Посмотрите интересный и очень информативный SQL на SSD: Hot and Crazy Love от Brent Ozar.

Вопрос отделения журналов от данных, где используются твердотельные накопители, является скорее RPO (целью точки восстановления) для системы, а не производительностью. Если RPO определен в минутах, используйте один общий массив и делайте резервные копии журнала каждые [RPO] минуты. Если RPO определен в секундах, используйте отдельные массивы.

Честно говоря, если бы RPO был жестким, я бы оставил SSD для массива данных и использовал бы зеркальную пару дорогих (корпоративных) надежных блесен для журнала.

Марк Стори-Смит
источник
Резервные копии также копируются на отдельную машину. Они созданы на локальном компьютере, поэтому я могу использовать SQL Compare / Data Compare и отменить изменения в случае регрессии / ошибки пользователя.
Робби
Кроме того, RPO определяется в минутах (я думаю, что даже в течение 10 секунд было бы приемлемо, чтобы мой сценарий был полностью честным). Пост Hot & Crazy Love заставляет меня задуматься о взаимосвязанных неудачах. Из моего ограниченного опыта у меня было больше сбоев материнской платы и полных сбоев системы (блок питания / скачок напряжения жарит все), чем сбои дисков, поэтому я все еще пытаюсь определить, какой будет наиболее экономически эффективный уровень паранойи / предотвращения.
Робби
1

Вы должны выбрать вариант 2 следующим образом:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

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

Оставьте tempdb отдельно от ваших резервных копий, потому что там тоже много чего происходит. Не перепутайте свои резервные копии и файл данных. даже если резервные копии не создаются ежедневно, когда они происходят, они сильно влияют на ваш ввод-вывод. в зависимости от вашего бизнеса и использования вашей базы данных, некоторые люди или МНОЖЕСТВО людей могут жаловаться во время резервного копирования.

Надеюсь это поможет

Николя де Фонтене
источник
6
Бред какой то. Это SSD, а не спиннеры.
Марк Стори-Смит
не чушь, даже с sdd, есть ряд достижений, хотя и не так много.
Николас де Фонтене
2
Даже при использовании спиннеров отделение данных от индексов не имеет значения, пока вы не играете на территории SQLCAT. Случай разделения tempdb также никогда не бывает четким и очень редко применяется при таком небольшом количестве дисков.
Марк Стори-Смит