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

Я создаю 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-сервера, и я предполагаю, что запись резервных копий в том же месте, что и в журналах, является хорошей практикой, поскольку в обоих случаях поведение чтения / записи является последовательной записью.

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

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

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

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

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

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

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

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