Яка рекомендована конфігурація RAID для бази даних Oracle?


16

RAID (надлишкові масиви недорогих дисків) поставляється з різною конфігурацією (RAID-0, RAID-1 ...). Яка рекомендована конфігурація RAID, яку я повинен налаштувати та використовувати під час встановлення бази даних Oracle. База даних в основному буде використовуватися як сховище даних.


RAID0 і RAID1 - це абсолютно різні речі. Ви використовуєте RAID0 лише для продуктивності, а RAID1 - лише для відмовок у випадку відмови диска.
Йонас

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

Відповіді:


13

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

Розгляньте дискусію на AskTom , OTN форумах , OTN форумах 2 та OTN форумах 3 .

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

Призначаючи результати запитів у всіх трьох середовищах, ви зможете виявити, яка методологія найкраще підходить для вас. Я розгорнув бази даних за допомогою віртуальних нальотів на базі ASN та Linux, і віртуальний рейд повівся трохи краще (кілька років тому.). Однак, я підозрюю, що це було частково способом налаштування накопичувачів.

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

--Edit--

Кожна " група дисків " може складатися з одного або декількох дисків, каталогів або файлів відповідної підсистеми. Oracle рекомендує "Для найкращої продуктивності та надійності виберіть пристрій RAID або логічний том на більш ніж одному фізичному пристрої та застосуйте методологію" смуга і дзеркало "(SAME)." при розміщенні файлів у файловій системі. Це означає, ніби Oracle рекомендує RAID 1 + 0.

Дискові групи, керовані ASM, однак: "Для нормальної групи дискових резервувань потрібно мінімум дві групи відмов (або два дискові пристрої), якщо ви використовуєте дзеркальне дзеркальне дзеркальне відображення. Ефективний дисковий простір у звичайній дисковій групі резервування становить половину суми дисковий простір у всіх його пристроях "мабуть, автоматично забезпечує дзеркальне відображення.

Самі ці пристрої можуть складатися з RAID-пристроїв тощо. На практичних тестах, коли я створював сховища даних RAIDed, простий віртуальний RAID 5 у файловій системі забезпечив прийнятну продуктивність, а додатковий ASM не додав переваг продуктивності. У такому завданні оптимізації спочатку визначте свої ресурси, а потім протестуйте всі можливі конфігурації, оскільки іноді результати можуть бути надзвичайно протизаконними.


1
Віртуальний рейд звучить досить смішно: /
jcolebrand

10

Якщо у вас є два фізичних накопичувача:

RAID0: Швидке, але зайве. Будь-яка помилка диска знищить весь масив. Деякі люди ставлять тимчасове сховище на RAID0 (тобто tempdb під MSSQL), але я все одно вважаю це небезпечним, оскільки поки ви не втратите жодних значущих даних, якщо масив, що потрапить на вас, матиме відключення сервера, поки ситуація не буде відновлена.

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

Якщо у вас є три фізичні приводи:

Ваші параметри - це RAID5, нестандартний 3-накопичувальний RAID10 (або RAID1E, як посилаються на нього контролери IBM), якщо вони підтримуються. Звичайно, ви можете використовувати RAID1 і зберігати додатковий диск як запас, коли хтось з інших не спрацьовує, але ви все одно повинні зберігати запасні частини в критичному середовищі місії, так що це само собою зрозуміло.

RAID5 пропонує більше місця, ніж RAID10 (два накопичувачі варто замість півтора), але має потенційну проблему з швидкістю запису, оскільки для кожного записаного блоку контролеру потрібно прочитати блок парності, оновити його та записати його назад. Ця проблема продуктивності запису може бути подвоєна для записів у базу даних, оскільки є щонайменше дві записи для кожного оновлення: одна до журналу транзакцій та одна до фактичних областей даних. Оскільки місця зараз мало, я б рекомендував 3-привідний RAID10, якщо він підтримується для кращої продуктивності запису. Програмне забезпечення Linux RAID пропонує це, як і багато контролери IBM (вони називають його RAID1E). Ви можете знайти його під іншими іменами, оскільки він не вважається стандартним розташуванням, тому не має стандартного імені.

Як R5, так і R10-над трьома дають однакову надмірність (будь-який один привід може вийти з ладу за один раз, і масив виживе) та аналогічні показники продуктивності читання (аналогічно дводисковому масиву RAID0).

Якщо у вас є чотири фізичні приводи:

Якщо створюється лише один масив, то є два варіанти (ігнорування "гарячих запасних" варіацій): RAID6 і "традиційний" RAID10 (RAID0 з RAID1).

Обидва дають однаковий простір (два диски з ваших чотирьох). RAID6 забезпечує кращу надмірність, оскільки будь-які два накопичувачі можуть вийти з ладу в той час, коли RAID10 може вижити лише чотири з шести можливих ситуацій, що відсутній на двох дисках. Обидва дають продуктивність зчитування simialr, але RAID6 має проблеми з швидкістю запису, аналогічні RAID5 (те саме на хорошому контролері, хоча це може бути повільніше, ніж RAID5 на поганому контролері або з програмним RAID, залежно від ОС, можливостей управління введення-виводу. RAID10 - це зазвичай бажані для баз даних з міркувань продуктивності - якщо вам потрібна додаткова надмірність, ви можете використовувати шість накопичувачів і мати RAID0 або 2 RAID1 з 3-х накопичувачами.

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

Якщо у вас більше чотирьох накопичувачів:

Ваші параметри тут широко відкриті, і це дійсно залежить від того, якими є ваші дані та якими очікуються оновлення / читання завантажень / моделей. Наприклад, колись наші послуги працюють на накопичувачах 12 ~ 70 Гбіт:

  • 4x як RAID10 для системних областей (ОС, SQL Server (MSSQL в нашому випадку), swap, tempdb).
  • 4x як RAID10 для файлів даних
  • 4x як RAID10 для журналів транзакцій

Tempdb зберігається в системному масиві. Ми можемо перемістити його до двох інших масивів і просто запустити системний масив як 2 диски в RAID1, оскільки додаткова швидкість не дуже потрібна для системних фрагментів (як це дуже важливо лише під час завантаження або під час заміни, і ми гарантуємо, що є достатньо оперативної пам’яті для того, щоб ніколи не потрібно міняти місцями), але з тим, як ми платимо хостинг-провайдеру за цей набір машин, нам не обійшлося б менше скинути два накопичувачі. Резервні копії також переходять до системного масиву, перш ніж їх буде скопійовано у позасерверні, позаміські та офлайнові резервні копії.

Звичайно, це є серйозною надмірністю для деяких баз даних (не було б сенсу запускати невеликий сервер блогу таким чином!), Але наш головний додаток дуже добре справляється з цим домовленістю.

Якщо у вас є шість дисків, ви можете розглянути три масиви RAID1 або два масиви RAID10 з трьома дисками.

Взагалі

На жаль, немає справжньої простої "найкращої практики", оскільки це дуже залежить від розміру вашої системи та використання моделей. Єдині загальні правила, про які я можу подумати чи такі:

  • уникайте RAID5 і 6, якщо ви не знаєте, що проблема з записом не вплине на вас суттєво
  • з чотирма або більше накопичувачами на основі обертового диска розглядають можливість розбиття речей на декілька масивів, щоб зменшити рухи голови (вся користь декількох масивів не застосовуватиметься до хороших SSD, оскільки фізичних рухів голови не враховувати, хоча ви можете побачити певну різницю залежно від залежності стратегія поєднання запису SSD-дисків тощо)
  • тест, тест та ще раз тестування: завжди добре спробувати знайти час, щоб переконатися, що обрана вами схема дійсно оптимальна

Апаратне чи програмне забезпечення RAID?

Раніше продуктивність програмного забезпечення RAID була нижчою за продуктивність апаратного RAID для RAID 5 за рахунок розрахунків паритету та всіх домовленостей через повільні інтерфейси між накопичувачами та процесором. З сучасними процесорами проблема калькуляції парності насправді не є проблемою, але якщо у вас дуже швидкі накопичувачі, апаратний RAID все одно може виграти, якщо загальна швидкість накопичувачів може прийти де завгоднопоблизу (в порядку порядку, на здогадку), як швидко машина може поговорити з дисковим контролером. Якщо у вас є чотири накопичувальні масиви RAID1 (тобто чотири копії одних і тих же даних для безлічі надмірностей) з програмним RAID, кожна операція запису призведе до того, що ОС відправить чотири лоти даних на контролер вводу / виводу, можливо послідовно - з обладнанням контролер ОС просто надсилає один запит запису, а контролер надсилає це на чотири диски, ймовірно, паралельно.

Хороший апаратний RAID також може запропонувати і інші переваги: ​​деякі контролери високої специфікації мають кеш-запис із резервним запасом акумулятора, щоб очікувані записи не втрачалися в режимі відключення живлення, навіть якщо, наприклад, ваш UPS вийшов з ладу.

Програмний RAID, очевидно, дешевший і портативніший, тому ви не прив’язані до конкретного контролера, якщо вам доведеться переміщувати масиви через несправність контролера / машини.

Дешевий апаратний RAID зазвичай поєднує негативні вимоги програмного та апаратного RAID з кількома (або жодними) перевагами будь-якого, тому найкраще уникати.

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


5

" Посібник з настройки продуктивності бази даних Oracle " містить розділ, присвячений конфігурації вводу-виводу . Коротко:

  • Використовуйте зачистку (апаратний RAID, програмний RAID, ASM)
  • Не використовуйте RAID5 для архівування та повторення журналів
  • Вирівняйте розмір блоку файлової системи та розмір блоку БД

4

У деяких випадках JBOD - правильна відповідь (тобто не RAID).

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

Ви можете використовувати смугастий (RAID0), щоб збалансувати записи, але якщо це все одна велика група, ви не можете відокремити індекси від записів.

Дзеркальне дзеркальне відображення (RAID1) є стійким до помилок, і воно швидше для читання (як ви можете прочитати з того, що шпиндель не зайнятий), але це може бути повільніше для запису, оскільки вам доведеться чекати, коли будуть написані обидві копії.

Я б ніколи не переходив на базу даних RAID5 або RAID6. Якщо дані важливі, придбайте більше дисків і перейдіть з RAID1; RAID5 / 6 повільний (особливо в програмному забезпеченні), і для сучасних розмірів жорсткого диска може знадобитися кілька днів для відновлення після заміни несправних дисків для великої групи дисків ... не кажучи вже про те, що більшість систем RAID5 / 6 мають справу з помилками паритету просто перерахувати паритет ... але шанси є, помилка в даних, а не паритет, але ви не маєте уявлення, де була помилка. (на жаль, я не думаю, що для баз даних є щось на кшталт LOCKSS)

...

Найцікавіший макет, який я бачив у базі даних, насправді мав два розділи на шпинделі - внутрішня частина диска була використана для виготовлення бази даних, а надбудовані диски використовувались для резервного копіювання. (і вони переконалися, що в розділі не було створено резервну копію одного і того ж шпинделя; я думаю, було кілька баз даних, тому кожна резервна копія на диски з іншої). Це дало їм перевагу поширювати речі на більше шпинделів протягом робочого дня, а потім вночі вони виконували резервні копії.

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

...

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

Бази даних, з якими я маю справу, - це те, що мій начальник називає «ВИРОБНИЦТВО»: Пишіть один раз, ніколи не читайте; він жартує, але "сховище даних" може означати будь-який рівень активності ... Я бачив деякі, які завантажувались із стрічки щоночі / щотижня (і були лише копіями екземпляра OLTP, і допомогли нам переконатися, що стрічки хороші) та на них проводилися масивні аналітичні завдання та інші, де є постійний потік введення та випадкові читання, але немає реальної конкуренції за ресурси.


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

@jcolebrand: насправді після того, як я опублікував це, я прочитав "ASM", про який згадував Брайан Баллсун-Стентон, і це виглядає так, що це Oracle управління дзеркальним відображенням + смугастим, а не на рівні OS / FS / апаратного рівня, тому ми зробили подібні моменти, але він дав краще рішення для останніх встановлень Oracle.
Джо

Для чого потрібен JBOD так, як ви рекомендували, так?
jcolebrand

@jcolebrand: досить багато. (було б доцільно, але я не думаю, що потрібно )
Джо

3

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


Але зміна жорстких дисків - це не домен DBA? Моніторинг дисків протягом усього життя та рівня відмов призначений для автоматизованих інструментів натовпу SF. Давайте не дублювати роботу та знищувати причини спеціалізації. Ми в АБД в кінці кінців;)
jcolebrand

Куди реалізовано рейд 5? Обладнання? Програмне забезпечення? Oracle? На скільки дисків? Що з рекомендованим накопичувальним масивом Oracle? Чи не для цього потрібні повторні журнали архівів?
Брайан Балсун-Стентон

2
RAID5 може мати суттєві проблеми із швидкістю запису. RAID10 частіше зустрічається для серверів БД.
Девід Спіллетт

@jcolebrand, Багато компаній, з якими я працював, стосуються мережевих адміністраторів == сервер адмінів == адміністратори бази даних. У деяких є лише декілька людей, які мають доступ до виробничого центру обробки даних, тому цим людям доводиться носити відразу 2 капелюхи. У багатьох, над якими я працював, адміністратори сервера не знають, що відбувається, тому я залучаюсь, тому я також повинен знати свою роботу.
Тангурена

Ну це класно, і це смокче одночасно. Радий мати голос досвіду;) [PS: мій був +1]
jcolebrand

2

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

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

Основи виглядають так:

RAID0

Добре підходить для відеоігор. Погано майже ні для кого іншого. Непогано було б використовувати це для кешування-сервера, якому не потрібно зберігати дані протягом будь-якого тривалого часу. Після виходу з ладу диска система вимикається. Гра завершена.

RAID1

Відмінно підходить для надійності. Не велика розширюваність. Дуже добре на швидкості.

RAID5

Бажана суміш між RAID0 та RAID1 (свого роду).

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


2
Хоча ServerFault, безумовно, не був би неправильним місцем для цього питання, тут, мабуть, правильно. Питання продуктивності вводу / виводу - це те, про що слід ознайомитись з BBA.
Девід Спіллетт

@David Я твердо погоджуюся, але є різниця в тому, що слід знати і робити це самостійно. З мого досвіду, ніколи не було завдання однієї людини, коли сайт збирався бути великим і зайнятим. Дві голови краще, ніж одна, і все це
jcolebrand
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.