Чому RAID 1 + 6 не є більш поширеною схемою?


17

Чому вкладені рівні RAID 1 + 5 або 1 + 6 майже не чуті? Стаття Вікіпедії про вкладені рівні RAID наразі не містить своїх розділів. Я не розумію, чому вони не частіше, ніж RAID 1 + 0, особливо в порівнянні з RAID 1 + 0 потрійним дзеркальним відображенням.

Очевидно, що час відновлення стає все більш проблематичним, оскільки потужність приводу збільшується швидше, ніж їх продуктивність чи надійність. Мені кажуть, що RAID 1 відновлює швидше і що масив RAID 0 пар RAID 1 уникає проблеми, але, безумовно, так би RAID 5 або 6 масив пар RAID 1. Я, принаймні, сподіваюся, що вони будуть поширеною альтернативою RAID 1 + 0.

Для 16 накопичувачів 1 Тб ось мої розрахунки наївної ймовірності вдатися до резервного копіювання, тобто з спрощенням припущення, що накопичувачі незалежні з рівномірною ймовірністю:

RAID | storage | cumulative probabilities of resorting to backup /m
 1+0 |     8TB | 0, 67, 200, 385, 590, 776, 910, 980, 1000, 1000, 1000
 1+5 |     7TB | 0,  0,   0,  15,  77, 217, 441, 702,  910, 1000, 1000
 1+6 |     6TB | 0,  0,   0,   0,   0,   7,  49, 179,  441,  776, 1000
(m = 0.001, i.e. milli.)

Якщо це правильно, то цілком зрозуміло, що RAID 1 + 6 є виключно надійнішим, ніж RAID 1 + 0, лише на 25% зменшення ємності для зберігання. Як і взагалі, теоретична пропускна здатність запису (не рахуючи часу пошуку) - це ємність зберігання / розмір масиву × кількість дисків × пропускна здатність запису найповільнішого накопичувача в масиві (рівні RAID із надмірністю мають більшу посилення запису для записів, що не заповнюйте смугу, але це залежить від розміру шматка), а теоретична пропускна здатність - це кількість пропусканих частот зчитування накопичувачів у масиві (за винятком того, що RAID 0, RAID 5 та RAID 6 ще теоретично можуть бути обмежені рівнем найповільніший, 2-й повільний і 3-й найповільніший привід швидкості зчитування відповідно). Тобто, якщо вважати однакові приводи, це було б відповідно 8 × 7 ×,

Крім того, розглянемо RAID 0 вчетверо трійки RAID 1, тобто RAID 1 + 0 потрійне дзеркальне відображення з 12 дисків, і RAID 6 секції пар RAID 1, тобто RAID 1 + 6 з 12 дисків. Знову ж таки, це однакові накопичувачі 1 Тб. Обидва макети мають однакову кількість приводів (12), однакову кількість ємності зберігання (4 ТБ), однакову частку надмірності (2/3), однакову максимальну пропускну здатність запису (4 ×) і однакову максимальну пропускну здатність ( 12 ×). Ось мої розрахунки (поки що):

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | 0, 0, 18,  ?,   ?,   ?,   ?,   ?, 1000
1+6 (6×2) | 0, 0,  0,  0,   0,  22, 152, 515, 1000

Так, це може виглядати як надмірна кількість, але там, де використовується потрійне дзеркальне відображення для розщеплення клону для резервного копіювання, RAID 1 + 6 може бути також використаний, просто заморозивши і видаливши 1 з кожного диска всіх, крім 2 RAID 1 пара, і, роблячи це, він все ще має набагато кращу надійність при деградації, ніж деградований масив RAID 1 + 0. Ось мої розрахунки для 12 дисків, деградованих на 4 таким чином:

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | (0, 0, 0, 0), 0, 143, 429, 771, 1000
1+6 (6×2) | (0, 0, 0, 0), 0,   0,  71, 414, 1000

Пропускна здатність, однак, може бути знижена до 6 × за цей час для RAID 1 + 6, тоді як RAID 1 + 0 знижується лише до 8 ×. Тим не менш, якщо диск не вдається, поки масив знаходиться в цьому деградованому стані, масив RAID 1 + 6 мав би 50–50 шансів залишитися приблизно на 6 × або обмежитися далі 5 ×, тоді як масив RAID 1 + 0 буде обмежуватися до 4 × вузького місця. Пропускна здатність запису повинна бути дуже незадіяною (вона може навіть збільшитися, якщо диски, взяті для резервного копіювання, були самими повільними дисками).

Насправді, обидва можна розглядати як "потрійне дзеркальне відображення", оскільки деградований масив RAID 1 + 6 здатний розщеплювати додаткову групу RAID 6 з 4 дисків. Іншими словами, цей 12-накопичувальний макет RAID 1 + 6 можна розділити на 3 деградовані (але функціональні) масиви RAID 6!

Так це просто, що більшість людей детально не вивчали математику? Чи будемо ми бачити більше RAID 1 + 6 у майбутньому?


2
Здається, ваш calput calc не враховував посилення запису для створення паритету.
JamesRyan

1
@JamesRyan: Так, я дійсно вважав, що паритет потребує написання. Ось для чого «ємність накопичувача / розмір масиву» - зворотний цьому коефіцієнт посилення запису, не враховуючи подальшого посилення запису, пов’язаного з твердотільними накопичувачами. Зауважте, що це включає також посилення запису надмірності RAID 1. В основному коефіцієнт посилення запису дорівнює зворотному 1 мінус частці надмірності. Так 50% надмірності дає коефіцієнт посилення запису 2; 62,5% (10/16) надмірності дає коефіцієнт посилення запису ~ 2,67 (16/6).
Джеймс Хей

1
ні, це неправильно. Кожен запис RAID6 приймає 6 IO, а кожен запис RAID1 приймає 2 IO, вони є мультиплікаційними. Отже, в RAID 1 + 6 кожне записування візьме 12 IO, для RAID 10 - це 2 IO. Пропускна здатність запису на 12 дисках буде 1x для RAID1 + 6 і 6x для RAID10!
JamesRyan

@JamesRyan: О, я бачу, куди ви зараз це робите - для записів, які менші, ніж повна смуга, коефіцієнт посилення запису може подвоїтися для RAID 1 + 6, таким чином, вдвічі зменшити максимальну пропускну здатність запису. Для повної смуги, так, є 12 записів у прикладі 6 × 2, але ви забуваєте, що це на 4 шматки, варті даних. Для 4, 3, 2, 1 відрізків значення коефіцієнтів посилення запису відповідно (6 × 2) / 4 = 3, (5 × 2) / 3 = ~ 3,33, (4 × 2) / 2 = 4, ( 3 × 2) / 1 = 6, що дає максимальну пропускну здатність 4 × 3,6 × 3 × 2 ×. Для RAID 1 + 0 4 × 3 це (4 × 3) / 4, (3 × 3) / 3, (2 × 3) / 2, (1 × 3) / 1, що дає константу 4 ×. …
Джеймс Хей

2
Виходячи з своїх розрахунків, ви заявили, що RAID1 + 6 має таку ж пропускну здатність запису, що і RAID10 з трьома. Насправді RAID1 + 6 навіть не має віддаленої пропускної здатності RAID10, тому ваші розрахунки чи припущення, на яких вони ґрунтуються , помилкові . Я намагався допомогти вам зрозуміти, чому, якщо ви відмовитесь слухати, то, можливо, ми витрачаєте час, але це ви витрачаєте на це.
JamesRyan

Відповіді:


17

Як правило, я б сказав, що RAID 1 + 0, як правило, буде широко використовуватися, ніж 1 + 5 або 1 + 6, оскільки RAID 1 + 0 досить надійний і забезпечує кращі показники продуктивності та більш зручне зберігання.

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

Якщо вам потрібна краща надійність, ніж RAID 1 + 0, тоді займіться цим! .. але більшості людей, мабуть, це не потрібно.


1
Проблема, з якою у мене є RAID 1 + 0, полягає в тому, що він має погане співвідношення надійності та зберігання. Якщо RAID 6 довільно було розширюватися до будь-якої кількості паритетів (нижче n - 1), то для одних і тих же накопичувачів можна було б досягти як збільшення сховища, так і кращої надійності, ніж RAID 1 + 0. Для прикладу вище, якби можна було мати RAID 6 з 4 паритетами, у вас було б на 50% більше пам’яті та максимальна пропускна здатність, ніж RAID 1 + 0, але ви мали б винятково більшу надійність. RAID 6 з 3 або 4 паритетами матиме гарну компромісну надійність та зберігання.
Джеймс Хей

4
@JamesHaigh RAID 6 проти RAID 1 + 0 - це набагато інша дискусія, ніж RAID 1 + 6 проти RAID 1 + 0, ви якось змінили тему. ZFS raidz3 здається, що це буде на вашу алею? У будь-якому разі, на ваш погляд, є деякі переваги продуктивності, які RAID 1 + 0 підтримує над RAID 6, наприклад, невеликі одноблокові записи, які потребують дотику до значно меншої кількості накопичувачів (і назад до raidz3, ZFS обробляє це інтелектуально, записуючи кілька повні копії замість того, щоб писати на всі диски для невеликих записів)
Шейн Мадден

Вибачте, так, я думаю, що це справді те, що я переслідую. З цього останнього коментаря я писав нове запитання спеціально про RAID з 3 і більше паритетами . Це було б краще, ніж RAID 1 + 6, я думаю. Було б також більш гнучким і простим отримати бажаний компроміс. Ви можете продовжити це з цього питання.
Джеймс Хей

3
RAID 6 не може бути лінійно розширений, оскільки він не працює таким чином. Обчислення синдрому для другого паритету не буде тривіально масштабним для третьої сторони. Але ви можете досить легко робити менші групи RAID 6 - немає реальної причини, що вам потрібно робити 14 + 2, а замість цього можна зробити 2 + 2 або 4 + 2 і отримати велику надійність.
Sobrique

1
@JamesHaigh Чого ти, схоже, хочеш, - це 12-ти рейдовий рейд8. Виходячи з логіки, яка йде на розрахунки паритету, це буде чітко приєднати процесори навіть з тривіальними даними. Поодинокий паритет по суті є XOR (легко). Подвійний паритет - це щось спільне з квадратами (не важко, але не просто). Потрійний паритет на основі куба або подібний (твердий). Паритет 4, 5, 6, 7 або 8 вимагає ще більших (за експоненціальною шкалою) обчислень (які, можливо, знадобляться квантовим комп'ютерам). Пам’ятайте лише, що в міру зростання форми зростає показник IOPS на ZERO. Хто для медіа кого цікавить? Для ВМ це вбиває.
вбивця

16

Практична відповідь лежить десь на перетині технічних характеристик апаратних RAID-контролерів, середніх розмірів дисків, форм-факторів накопичувача та дизайну сервера.

Більшість апаратних RAID-контролерів обмежені рівнями RAID, які вони підтримують. Ось варіанти RAID для контролера Smart Array HP ProLiant:

[raid=0|1|1adm|1+0|1+0adm|5|50|6|60]

зауважте: "adm" - це просто потрійне дзеркальне відображення

Контролери LSI RAID підтримують: 0, 1, 5, 6, 10, 50, and 60

Таким чином, ці контролери здатні використовувати лише RAID 50 і 60 як вкладені рівні. LSI (від Dell PERC ) та HP складають більшу частину ринку адаптерів для зберігання корпоративних серверів. Це головна причина, що ви не бачите в полі щось подібне до RAID 1 + 6 або RAID 61.

Крім цього, для вкладених рівнів RAID понад RAID 10 потрібна відносно велика кількість дисків. Враховуючи зростаючі потужності накопичувача, доступні сьогодні (з 3,5-дюймовими приводами SAS і SATA) у поєднанні з тим, що багато шасі сервера розроблені приблизно в 8-ти 2,5-дюймових клітках накопичувача, можливостей для фізичного налаштування RAID 1+ немає більше 6 або RAID 61.

Області, де ви можете побачити щось на зразок RAID 1 + 6, - це великі програмні рішення для шасі RAID. На це безумовно здатні Linux MD RAID або ZFS. Але до цього часу несправність приводу може бути усунена гарячими або холодними дисками. Надійність RAID не є великою проблемою в наші дні, якщо ви уникаєте токсичних рівнів RAID та комбінацій обладнання (наприклад, диски RAID 5 і 6 ТБ). Крім того, продуктивність читання та запису буде обмежена шарами шару шару та кешування. Середні навантаження на зберігання зазвичай виграють одне чи інше.

Отже, врешті-решт, здається, що потреби / попиту просто немає.


1
Існує попит у вигляді реплікації масиву. Я знаю декілька сайтів, які роблять мультисайт DR, який практично говорить RAID 10 або 5 або 6, реплікується на віддалений (RAID 10 або 5 або 6) віддалений сайт. У незначній частині - за винятком певного рівня надійності диска, ваші процесори, контролери, мережі, джерело живлення, aircon, datacentre-catch-fire є більші загрози вашій надійності.
Sobrique

1
Я не думаю, що ОП навіть не розглядала реплікацію чи використання на різних сайтах.
ewwhite

1
Ні, напевно, ні. Як ви кажете - попиту просто немає, оскільки це надмірно. Це єдиний випадок, який я можу придумати, де це не зайве, хоча :)
Sobrique

Я (коротко) сконфігурував щось на кшталт raid 6 + 1- a локальний синхрогір Netapp створить ідентичну копію себе і мультиплексне зчитування в обох програмах, при цьому дзеркальне записування. Він здебільшого використовується для міграції Netapp V-Series до нових задніх LUN, однак, якби я хотів подвоїти свою надійність, я міг би зробити це з цим.
Василь

12
  • У вас зменшується віддача від надійності. RAID 6 навряд чи може призвести до несправності навіть на неприємних дисках SATA зі швидкістю 1 в 10 ^ 14 UBER. На накопичувачах FC / SAS ваш UBER становить 1 на 10 ^ 16, і ви також отримуєте значно більшу продуктивність.

  • Надійність групи RAID не захищає вас від випадкового видалення. (так що вам потрібні резервні копії)

  • окрім певних рівнів RAIDing, шанси на збій з’єднань на дисках стають нижчими, ніж збій у підтримці інфраструктури (електроживлення, мережа, витік повітряного зв'язку тощо).

  • Напишіть штраф. Кожне надходить на ваш RAID 61 запустить 12 операцій вводу-виводу (наївно). RAID 6 вже болісний у сценаріях "низького рівня" з точки зору ВГД на випадкове записування ТБ. (а у вищому рівні ваш показник відмов у 100 разів кращий)

  • це не "25% зниження", це ще 25% зниження. Ваш 16TB перетворюється на 6TB. Таким чином, ви отримуєте 37,5% зручного сховища. Вам потрібно в 3 рази більше дисків на ємність і в 3 рази більше місця в центрі даних. Ви, напевно, отримаєте більшу надійність, просто зробивши менші набори RAID6. Я не зробив скорочення чисел, але спробуйте - наприклад, суми RAID 6 у наборах 3x 3 + 2 (15 дисків, менше накладних витрат, ніж ваш RAID10). Або замість цього 3-х дзеркала.

Сказавши це - це частіше, ніж ви думаєте, робити це для ДР з кількома сайтами. Я запускаю реплікувані масиви зберігання, де я отримав RAID5 / 6 / DP групи RAID асинхронно або синхронно на DR-сайт. (Не синхронізуйте, якщо вам це можливо уникнути - це виглядає добре, насправді жахливо).

З моїм NetApps це метрокластер з деякими дзеркальними агрегатами. За допомогою моїх VMAXів у нас є інструмент віддалених даних Symmetrix (SRDF). І мої 3PAR роблять віддалену копію.

Це дорого, але забезпечує рівень «центру обробки даних», що займається вогнем »рівня DR.

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

Я намагаюся зробити те, що в моєму прямому досвіді роботи адміністратора пам’яті - в ~ 40 000 об'єктах шпинделя (так, ми заміняємо десятки дисків щодня) - нам довелося перейти до резервного копіювання для різних Причини за останні 5 років, але жодна з них не була відмовою групи RAID. Ми обговорюємо відносні достоїнства та прийнятний час відновлення, точку відновлення та вікна відключення. І це лежить в основі ЗАВЖДИ вартості додаткової стійкості.

У нашому масиві всі медіа-скраби та прогнозування несправностей, а також агресивно запасні та тестові диски.

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

Тож я думаю, тому я запропону відповідь на ваше запитання:

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


«Надійність групи RAID не захищає вас від випадкового видалення. (так що вам потрібні резервні копії) "- Я не мав на увазі, що це робить резервні копії непотрібними (я добре знаю, що RAID - це не резервне копіювання ). Насправді я маю на увазі зворотне слово, кажучи "накопичувальні ймовірності вдатися до резервного копіювання" - я вважаю, що резервування - це стандартна практика. Я погоджуюся з цим пунктом, однак він подається як протидію моїм міркуванням про RAID 1 + 6, що не має сенсу.
Джеймс Хей

"RAID 61" - RAID 6 + 1 буде масивом RAID 1 з масивів RAID 6. Це зворотне гніздування, і я думаю, воно мало б набагато меншу надійність. Тобто, що станеться, якщо 3 диска виходять з ладу в одному вкладеному масиві RAID 6? Чи не потрібно весь цей вкладений масив RAID 6 відновити? Ті ж накопичувачі, які вкладені як RAID 1 + 6, могли б потерпіти ті самі 3 відмови диска, не діючи в режимі офлайн жодні робочі диски.
Джеймс Хей

"Поза певними рівнями RAIDing, ваші шанси на збій з'єднання на дисках стають нижчими, ніж з'єднання збою підтримуючої інфраструктури (живлення, мережа, витік повітря і т.д.)"; "Це ще більше 25% зменшення" - Правда і правда, це макет для вкладення надмірного рівня. Але чому тоді на одній Землі хтось використовуватиме масив RAID 0 з трійки RAID 1? Дякуємо, що нагадали про потрійне дзеркальне відображення RAID 1 + 0! "Я не зробив скорочення числа"; "Або робите замість цього 3-х дзеркальних дзеркал". - Ви дійсно повинні виконати деякі обчислення, перш ніж подавати допоміжний кейс як контрприклад. Ці розрахунки слід вивчити…
Джеймс Хей,

1
Мій прямий досвід такий: у мене в маєтку 40 000 шпинделів, у різних конфігураціях. За останні 5 років у нас не було збоїв групи рейдів. Я використовував потрійні дзеркала, але не для стійкості - вони роблять клонові копії з резервних причин. Я використовував мультисайтні репліки з причин DR - які я використав - але жодна з них не потрібна була і для відмов RG.
Sobrique

1
Ви нерозумієте, що таке пеня за написання. Справа в тому, що для одного перезапису потрібно прочитати з двох пристроїв паритетності, обчислити паритет, записати на вас пристрої подвійного паритету та цільовий блок. Таким чином, 6 МО на "запис". Це не обмеження програмного забезпечення або впровадження. Ви частково пом'якшуєте гарне кешування запису, але лише частково.
Sobrique

3

Сучасні та вдосконалені системи не реалізують подібні форми, оскільки вони надмірно складні, абсолютно непотрібні та суперечать будь-якій подобі ефективності.

Як зазначали інші, відношення сировинного простору до корисного простору по суті становить 3: 1. Це по суті три примірники (дві зайві копії). Через розрахункову вартість "raid6" (удвічі більше, якщо дзеркальне відображення) та втрату IOPS, що виникає, це дуже неефективно. У системі ZFS, яка дуже добре розроблена і налаштована, рівноцінним рішенням, можливо, було б створити смугу з 3-х сторонніх дзеркал.

Наприклад, замість дзеркала з 6-ти сторонніми формами raid6 / raidz2 (всього 12 дисків), що було б дуже неефективно (також не те, що у ZFS є якийсь механізм реалізації), ви мали б чотири 3-х сторонні дзеркала (також 12 приводи). І замість IOPS, який вартує одного диска, у вас є 4 диски, які варті IOPS. Особливо це стосується віртуальних машин - це величезна різниця. Загальна смуга пропускання для двох форм може бути дуже схожою при послідовних читаннях / записах, але смуга 3-х дзеркальних дзеркал, безумовно, буде більш чутлива до випадкового читання / запису.

Підводячи підсумок: raid1 + 6 є загалом непрактичним, неефективним, і не дивно, що все, що серйозно стосується сховища, може розробити.

Для уточнення невідповідності IOPS: З дзеркалом форм raid6 / raidz2, при кожному записі, всі 12 дисків повинні діяти як один. Немає можливості загальної форми розділити активність на кілька дій, які кілька фігур можуть виконувати самостійно. Із смужкою 3-х дзеркальних дзеркал кожне записування може бути чимось, з чим повинен мати справу лише одне із 4-х дзеркал, тож інше записування, яке входить, не повинно чекати, коли буде вирішена вся форма омнібуса, перш ніж шукати подальші дії .


2

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

Послідовне написання нормально, і якщо кешування, об'єднання записів і т. Д. Здатне прикрити це, це виглядає нормально. Під великим навантаженням речі виглядають погано, і це головна причина, що налаштування 1 + 5/6 майже ніколи не використовується.


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

1

Шукайте разів

Проблема полягає в тому, що посилення пошуку запиту поводиться дуже інакше, як посилення пропускної здатності запису . Мінімальне посилення пропускної здатності запису з паритетом виникає, коли вся смужка пишеться одразу (назвемо це прикметник «повною смугою»), але мінімальне посилення запиту запису відбувається, навпаки, коли все записування після запиту у віртуальному пристрої вписується єдиний шматок. Перш ніж розібратися в деталях, відносини набагато простіше передати в табличному вигляді:

RAID | write throughput amplification factor | write seek amplification factor
     | full-stripe (e.g.) | single-chunk     | full-stripe  | single-chunk
   0 | 1           ;  1   | 1           ;  1 | n       ; 12 | 1           ;  1
   1 | n           ; 12   | n           ; 12 | n       ; 12 | n           ; 12
   5 | n/(n - 1)   ; ~1.1 | min [3, n]  ;  3 | n       ; 12 | min [3, n]  ;  3
   6 | n/(n - 2)   ;  1.2 | min [5, n]  ;  5 | n       ; 12 | min [5, n]  ;  5
*1+0 | n₁          ;  3   | n₁          ;  3 | n       ; 12 | n₁          ;  3*
 1+5 | n/(n₅ - 1)  ;  2.4 | expr₁       ;  5 | n       ; 12 | expr₁       ;  5
*1+6 | n/(n₆ - 2)  ;  3   | expr₂       ;  8 | n       ; 12 | expr₂       ;  8*
expr₁ = 2n₁ + min [1, n₅ - 2]
expr₂ = 3n₁ + min [2, n₆ - 3]

де n - загальна кількість дисків, n₁ - кількість дисків у групах RAID 1, а n₅ і n₆ - кількість груп у масивах RAID 5 або RAID 6 відповідно. Приклади стосуються 12-ти приводного запису у питанні (відповідні рядки ' *bolded*'); Прикладами рівнів RAID 1 + 0, 1 + 5, 1 + 6 є 4 × 3, 6 × 2, 6 × 2 відповідно.

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

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

RAID | large contiguous write throughput    | concurrent tiny writes throughput
     | full-stripe    | single-chunk        | full-stripe | single-chunk
   0 | n×       ; 12× | n×          ; 12×   | 1×     ; 1× | n×          ; 12×
   1 | 1×       ;  1× | 1×          ;  1×   | 1×     ; 1× | 1×          ;  1×
   5 | (n - 1)× ; 11× | max[n/3, 1]×;  4×   | 1×     ; 1× | max[n/3, 1]×;  4×
   6 | (n - 2)× ; 10× | max[n/5, 1]×;  2.4× | 1×     ; 1× | max[n/5, 1]×;  2.4×
*1+0 | n₀×      ;  4× | n₀×         ;  4×   | 1×     ; 1× | n₀×         ;  4×  *
 1+5 | (n₅ - 1)×;  5× | expr₃×      ;  2.4× | 1×     ; 1× | expr₃×      ;  2.4×
*1+6 | (n₆ - 2)×;  4× | expr₄×      ;  1.5× | 1×     ; 1× | expr₄×      ;  1.5×*
expr₃ = n/(2n₁ + min [1, n₅ - 2]) = max [n/(2n₁ + 1), n/(2n₁ + n₅ - 2)]
expr₄ = n/(3n₁ + min [2, n₆ - 3]) = max [n/(3n₁ + 2), n/(3n₁ + n₆ - 3)]

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

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

RAID | read throughput amplification factor | read seek amplification factor
     | full-stripe      | single-chunk      | full-stripe (e.g.) | single-chunk
   0 | 1                | 1                 | n      to n;    12 | 1
   1 | 1                | 1                 | 1      to n;  1–12 | 1
   5 | 1                | 1                 | n - 1  to n; 11–12 | 1
   6 | 1                | 1                 | n - 2  to n; 10–12 | 1
*1+0 | 1                | 1                 | n₀     to n;  4–12 | 1           *
 1+5 | 1                | 1                 | n₅ - 1 to n;  5–12 | 1
*1+6 | 1                | 1                 | n₆ - 2 to n;  4–12 | 1           *

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

RAID | large contiguous read throughput | concurrent tiny reads throughput
     | full-stripe (e.g.)| single-chunk | full-stripe         | single-chunk
   0 | n×          ; 12× | n×     ; 12× | 1×          ;  1×   | n×     ; 12×
   1 | n×          ; 12× | n×     ; 12× | n×          ; 12×   | n×     ; 12×
   5 | n×          ; 12× | n×     ; 12× | n/(n - 1)×  ; ~1.1× | n×     ; 12×
   6 | n×          ; 12× | n×     ; 12× | n/(n - 2)×  ;  1.2× | n×     ; 12×
*1+0 | n×          ; 12× | n×     ; 12× | n₁×         ;  3×   | n×     ; 12×*
 1+5 | n×          ; 12× | n×     ; 12× | n/(n₅ - 1)× ;  2.4× | n×     ; 12×
*1+6 | n×          ; 12× | n×     ; 12× | n/(n₆ - 2)× ;  3×   | n×     ; 12×*

Примітка. Знову ж таки, середні 2 пропускні стовпчики можна ігнорувати з огляду на розмір розумного розміру. 3-й пропускний стовпчик знову тісно пов'язаний із пропорцією надмірності.

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

Тож насправді "коефіцієнт посилення" набагато складніше, ніж формула у питанні, де було розглянуто лише повне посилення пропускної здатності. Зокрема, продуктивність запису 6 × 2 RAID 1 + 6 для одночасних записів, які є достатньо малими, щоб бути пов'язаними з пошуком, буде гіршою, ніж у 4 × 3 RAID 1 + 0. А для крихітних записів, до яких усі прагнуть, продуктивність може бути приблизно третьою, ніж 4 × 3 RAID 1 + 0 в абсолютному кращому випадку (тобто, з ідеальною реалізацією).

Виявивши цю проблему, порівняння з 12 приводами не має прямого переможця:

                                  | 4×3 RAID 1+0 | 6×2 RAID 1+6
   number of identical 1TB drives | 12           | 12
                 storage capacity | 4TB          | 4TB
            redundancy proportion | 2/3          | 2/3
large contiguous write throughput | 4×           | 4×
 large contiguous read throughput | 12×          | 12×
concurrent tiny writes throughput |*4×           | 1.5×
 concurrent tiny reads throughput | 12×          | 12×
safe number of random drive loses | 2            |*5
    12 - 1 large write throughput | 4×           | 4×
     12 - 1 large read throughput | 8×           |*11×
    12 - 1 tiny writes throughput |*4×           | ~1.42×
     12 - 1 tiny reads throughput | 8×           |*~9.33×
  can split-off a copy for backup | yes[1]       | yes[1]
                  2-site failover | yes          | yes
    2-copy large write throughput | 4×           | 4×
     2-copy large read throughput |*8×           | 6×
    2-copy tiny writes throughput |*4×           | ~1.28×
     2-copy tiny reads throughput |*8×           | 6×
   2-copy safe random drive loses | 1            |*2
2-copy - 1 large write throughput | 4×           | 4×
 2-copy - 1 large read throughput | 4×           |*5× or 6×[2]
2-copy - 1 tiny writes throughput |*4×           | ~1.46× or 1.2×[2]
 2-copy - 1 tiny reads throughput | 4×           |*3.6x or 6×[2]
can be divided into 3 full copies | yes          | yes
                  3-site failover | yes          | yes
    1-copy large write throughput | 4×           | 4×
     1-copy large read throughput | 4×           | 4×
    1-copy tiny writes throughput |*4×           | ~0.85×
     1-copy tiny reads throughput |*4×           | 2×
   1-copy safe random drive loses | 0            | 0
                       complexity |*simple       | more complex

Примітка 1: Повна копія збережених даних - це відповідно четвірка RAID 0 або масив RAID 6, деградований 4/6. Примітка 2: Є рівномірний шанс того, чи невдача диска обмежує одну з 4 деградованих пар RAID 1 або погіршує одну з 2 нормальних пар.

Тим не менш, це було б подвоїти ефективність зчитування масиву RAID 6 з 6 дисків, і крихітна пропускна здатність запису повинна бути на 25% кращою (1,5 / 1,2) через необхідне зчитування розділене між парами RAID 1, а RAID 6 очевидно мати відповідні програми, тому в додатках із високою доступністю, які мають більшу кількість записів або більше стурбовані ефективністю читання, ніж продуктивністю запису, можливо, є ніша для RAID 1 + 6 після завершення. Але це ще не все ...

Складність

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

Наприклад, не відразу очевидно, що 6 × 2 RAID 1 + 6 можна абстрагувати як такі, що мають 3 незалежні віртуальні зчитувальні головки, здатні одночасно зчитувати 3 суміжні великі зчитування з пропускною здатністю 4 × кожна, як і 4 × 3 RAID 1 + 0. Просто вкладати 6 пар RAID 1 в масив RAID 6 за допомогою програмного RAID може бути не таким елегантним; реалізація може бути дурною і зграйною (я ще не перевіряв цю гіпотезу).

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


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

@JamesRyan: Це не секонд-хенд інформація. Теоретичні результати отримані з основ роботи стандартних рівнів RAID. Все, що потрібно для теорії, - це розуміння того, як працює RAID, і розуміння логіки та математичного виведення. Якби ці розрахунки робив хтось інший, я, звичайно, зазначу це і надаю посилання, якщо це можливо. Зауважте, що існує багато способів, за допомогою яких практична реалізація RAID 1 + 6 може бути неоптимальною, але різні реалізації будуть різними. Що я хотів би знати, чому ваш практичний тест не збігається.
Джеймс Хей

@JamesRyan: Скажіть, будь ласка, докладніше про те, якою реалізацією ви користувалися, якими накопичувачами ви користувалися, в яких конфігураціях та якими методами бенчмаркінгу? Ви пробували як масив RAID 6 з 6 пар RAID 1, так і масив RAID 0 з 4 трійки RAID 1 з тими ж 12 дисками та розміром фрагмента? Це був програмний RAID?
Джеймс Хей

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