RAID0 замість RAID1 або 5, це божевільний?

Я розглядаю можливість установки RAID0 для одного з наших кластерів SQL Server. Я окреслю ситуацію і шукаю, чому це може бути поганою ідеєю. Крім того, якщо хтось, у кого ви користуєтеся справами, документами чи іншою документацією, ви можете вказати мені на цю тему, це було б чудово.

У нас є 3 сервери в 2 центрах обробки даних, які є частиною кластера SQL. Всі вони працюють із SQL Server у групі доступності. Первинний має репліку, що сидить поруч, а інша в іншому центрі обробки даних. Вони виконують синхронну реплікацію з автоматичним відмовою. Усі накопичувачі - це жорсткі диски корпоративного класу. Вони працюватимуть на SQL Server 2017 або 2019.

Я думаю, що для запуску їх на масивах RAID0 у порівнянні з іншими методами буде кілька переваг, які мають декілька реальних недоліків. Єдиний мінус, який я зараз бачу, - це відсутність надмірності на первинному сервері, тому його збій збільшується. Як плюси:

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

2. Це знижує ймовірність виходу з ладу в цілому на туберкульоз. Оскільки нам не потрібні диски парності чи дзеркала, ми зменшуємо кількість дисків на масив. При меншій кількості накопичувачів існує менший загальний шанс виходу з ладу.

3. Це дешевше. Потреба в меншій кількості накопичувачів для нашої необхідної ємності, очевидно, коштує менше.

Я знаю, що це не звичайне ділове мислення, але чи є щось, про що я не замислююся? Я хотів би будь-який внесок або про, або проти.

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

ОС знаходиться на окремому дзеркальному диску, тому сам сервер повинен залишатися в режимі спокою. Один з таких приводів можна замінити і знову віддзеркалити. Він невеликий, і на ньому немає ніяких файлів баз даних, крім системних БД. Я не уявляю, що це займе більше хвилин. Якщо один з масивів даних виходить з ладу, ми замінюємо диск, відновлюємо масив, відновлюємо та повторно синхронізуємо з AG. З мого особистого досвіду, відновлення пройшло набагато швидше, ніж відновлення диска RAID5. У мене ніколи не було помилок RAID1, тому я не знаю, чи відбудеться це відновлення швидше чи ні. Відновлення будуть надходити з резервної копії та прокручуватися вперед, щоб відповідати основній, тому збільшення навантаження на первинному сервері повинно бути дуже мінімальним, лише синхронізуючи останні кілька хвилин журналів із відновленою реплікою.

Є один дуже важливий аспект, який, на мою думку, вам не вистачає:

Як ви плануєте відновитись?

Коли raid5 втратить диск, він буде працювати в деградованому стані, поки він не відновиться автоматично. (Принаймні, якщо у вас є гаряча запасна частина.)

Коли raid0 втрачає диск, він ніколи не може відновитись взагалі. Це означає, що ви втратили надмірність, і щоб відновити його, вам потрібно відновити рейд0 та скопіювати всі дані (не лише дані на пошкодженому диску) назад із вторинного, який зараз знаходиться під виробничим навантаженням. Тобто замість одиночного деградованого масиву raid5 тепер ваша ціла виробнича установка отримує хіт продуктивності.

Якщо рейд5 (або raid6) погіршив показник продуктивності штату - це не те, з чим ви можете впоратися, напевно, вам слід зробити рейд 1 + 0 замість цього . Так, це коштує дорожче, але ціни на дисках, якими вони є, це будуть добре витрачені гроші.

Можливо, "активно контролюйте стан raid5 і переносьте навантаження з основного, коли накопичувач не працює" - це рішення, яке дає вам більшість переваг без будь-яких недоліків? (Окрім втрати коефіцієнта крутості роботи без локальних надмірностей, звичайно.) Якщо відновлення диска raid5 займає набагато більше часу, ніж повна синхронізація даних бази даних, або ваше програмне забезпечення рейду діє дивно, або у вас серйозно завищені диски, Я б подумав.

Тут слід врахувати несправність приводу.

Уявіть на секунду, що наші диски в будь-який конкретний день мають 1/1000 відмов. Тоді уявіть, що у нас є 20 накопичувачів у кожному з наших 3 масивів.

Тому ймовірність виходу одного з накопичувачів у масив становить 20/1000 = 1/50. Шанс виходу з ладу двох накопичувачів в одному масиві є близьким до 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Таким чином, перейшовши з RAID 0 на RAID 5, ми вже значно рідше знищимо один з наших масивів.

Тож ми можемо взяти це далі - якщо шанс виходу з ладу масиву в день становить 1/50, то ймовірність виходу з ладу двох масивів в день становить 1 / (50 * 50) = 1/2500. Шанс виходу з ладу двох однакових масивів RAID 0 вдвічі більше, ніж один збій масиву RAID 5, якщо вважати той самий набір дисків. Це експоненціальне збільшення шансів на невдачу має стосуватися вас, оскільки це значно збільшує ймовірність того, що відразу один масив вийде з ладу.

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

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

Відмова від відповідальності: наведені вище розрахунки спрощено - вони все ще відносно точні.

Я думаю, що для запуску їх на масивах RAID0 у порівнянні з іншими методами буде кілька переваг, які мають декілька реальних недоліків.

Це досить поширена конфігурація при запуску АГ із внутрішніми / прямими приєднаними накопичувачами. Особливо з NVMe або іншими пристроями для зберігання даних на базі PCI.

Це просто означає лікування несправності накопичувача, як помилка сервера. З невеликою кількістю твердотільних накопичувачів у вас насправді немає значно менших MTBF для накопичувачів, ніж у інших твердотільних компонентів сервера, і тому ви просто трактуєте кожен диск як точку збою для сервера та замінити / відновити сервер у разі відмови диска.

Мене заінтригує те, чого ви намагаєтесь досягти? Ви згадуєте про себе, що не намагаєтеся вийти з підвищення цієї продуктивності, і який виграш ви намагаєтеся отримати?

Зверніть увагу на питання про продуктивність: якщо ви використовуєте жорсткі диски Enterprise Class, чи справді ваш розрахунок RAID є стільки вузьким місцем, яке вам потрібно для його покращення?

Беручи свої 3 плюси, я не думаю, що ти достатньо продумав це:

1. Чи відмовить SQL відразу? Що призведе до автоматичного запуску аварійної помилки? Чи перенесе сервер диск в автономному режимі, як тільки хтось його вдарить? Що робити, якщо це просто поганий сектор на одному диску? Якщо SQL не потрапить у поганий сектор, чи не вдасться вийти з ладу? Я не впевнений у цьому на 100%.

2. Чи зменшує це вірогідність виходу з ладу в цілому на туберкульоз. Ви думаєте, що менше дисків означає менше очок, але я не думаю, що це правильно. Шанси виходу з ладу 1 диска залишаються однаковими, якщо у вас є 1 диск або 10 дисків (або 100 дисків), але при RAID 0 це також означає, що це катастрофічний збій.

3. Невже один додатковий SSD буде коштувати занадто дорожче, щоб отримати RAID5? Я розумію, як RAID1 АБО 1 + 0 може підірвати бюджет, але 1 додатковий диск?

Без надмірності, якщо диск виходить з ладу і RAID переходить в режим офлайн, цей вузол буде в автономному режимі, поки ви не відновите RAID і не відновите всі ваші бази даних з нуля. Який процес ви збираєтесь здійснити, щоб це сталося? Ви не можете видалити базу даних із групи доступності, оскільки це зупинить реплікацію на DR, але якщо не вжити певних дій, інші два сервери не зможуть усікати свої файли журналів. Це нормально? Що станеться, якщо це не вдасться в ніч на п'ятницю довгих вихідних? Це все-таки добре? Чи можуть ваші вторинники впоратися з таким обсягом даних?

Мої останні запитання стосуються часу відновлення, про який ви згадуєте, буде швидшим. Ви на 100% впевнені, що це буде швидше? На скільки швидше?

Налаштування сервера Brent Ozar досі є моїм керівництвом щодо налаштування нових екземплярів SQL. Першим моментом у посібнику є перевірка того, що ви не використовуєте RAID0 для жодних накопичувачів.

==== ОНОВЛЕННЯ ====

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

1. Перебудова дуже великого індексу - реплікація може відставати на одному або обох вторинних
2. Помилка диска на RAID0 під час виправлення вторинного. Сервер, який ви виправляєте, може не мати можливості повернутися до мережі через те, що основний не працює в режимі офлайн.

Вони є крайніми випадками, але можуть бути катестрофними залежно від того, що втрачено за ті часи.