Як я можу налаштувати RAID масив накопичувачів SSD на моєму SQL сервері?

Я будую SQL Server з 48 ГБ оперативної пам’яті, 1 процесором та 8 SATA III (6 ГБ / с) SSD накопичувачами (128 Гбайт вирішального значення 4) та контролером LSI MegaRAID (SAS 9265-8i). Я очікую, що типове робоче навантаження в основному зчитується. Будуть певні періоди посилення активності запису (погодинна синхронізація даних із сторонніми постачальниками даних - нічні резервні копії), але я підозрюю, що типове співвідношення читання / запису становить приблизно 90% читання / 10% записів.

Варіант 1:
Логічний диск C: - RAID 1 (2 фізичні диски) - OS
Логічний диск D: - RAID 10 (6 фізичних накопичувачів) - файли DB / журнали / tempdb / резервні копії?

АБО

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

АБО

Варіант 3:
Інші пропозиції?

Я думаю, що варіант 1 дасть мені кращу ефективність, оскільки вся діяльність БД буде прокладена через 3 диски (і відображена через інші 3 в масиві), хоча варіант 2, схоже, імітує загальноприйняту мудрість (яка, здається, більше стосується механічної накопичувачі, ніж SSD). Схоже, переповнення стека пішло з варіантом 1 .

Я здогадуюсь із SSD, що це нормально, щоб ставити всі речі на один логічний диск, оскільки ваш сервер, ймовірно, більше обмежений процесором замість обмеженого вводу / виводу на той момент?

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

Звичайна мудрість щодо RAID не належить до SSD. Їм не дуже потрібні роздягання (RAID0). Вони схильні до відмов по-дизайну, але RAID-1, як правило , не є правильним відповідь на SSD з двох причин: а) марнотратно, половинки ємності масиву SSD (і вони є дорогими) і 2) SSD - накопичувачів характеристики відмов дроти по відношенню до обох приводів у дзеркалі, щоб вийти з ладу через дуже близькі проміжки часу (тобто корельовані відмови) і, таким чином, зробити весь масив марним. Див. Диференціальний RAID: Переосмислення RAID для надійності SSD для більш тривалої дискусії. Деякі рекомендують використовувати Raid-6 для SSD.

Крім того, звичайна мудрість розміщення файлів SQL Server не застосовується до SSD. Я б рекомендував вам переглянути SQL на SSD: Hot and Crazy Love та перейти за посиланнями орієнтирів у цій відповіді .

Стандартний підхід відокремлення випадкових шаблонів вводу-виводу даних для послідовних журналів просто не застосовується на SSD-дисках, тому я обрав би ваш варіант 1 із застереженнями:

• Резервні копії ОБОВ'ЯЗКОВО повинні бути в окремій машині. Немає сенсу створювати резервні копії, до яких ви не можете отримати доступ, якщо сервер задимлений.
• Існує деяке значення в розділенні накопичувачів даних і журналів, таким чином, що помилка масиву даних дозволить вам взяти хвіст резервного копіювання журналу.
• Пам’ятайте, що у вас немає гарячої запаси.
• Пам’ятайте, що у вас є накопичувачі на рівні споживачів. Не припускайте, що вони будуть настільки ж надійними, як еквіваленти підприємства з кратною вартістю.
• Подивіться на розважальний та дуже інформативний SQL на SSD: Hot and Crazy Love від Brent Ozar.

Питання відокремлення журналів від даних, де використовуються SSD, - це питання 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

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

Залиште tempdb також відокремленим від ваших резервних копій, тому що багато матеріалів відбувається і там. Не змішуйте резервні копії та файл даних. незважаючи на те, що резервне копіювання не робиться щодня, тоді, коли вони трапляються, вони наносять величезний удар вашому IO. на основі вашого бізнесу та використання вашої бази даних, деякі люди або багато людей можуть скаржитися під час резервного копіювання.

Сподіваюсь, це допомагає