Один великий RAID 10 проти кількох менших масивів?

Моє запитання: коли доцільно просто створити один великий масив із швидкою швидкістю читання та запису, наприклад RAID 10, замість створення менших масивів для конкретних програм?

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

Якщо я присвячую шпинделі пари для певної задачі, наприклад журналів транзакцій, і вони навіть не порушують потужність із завантаженням роботи ... чому б просто не поставити це навантаження на більший RAID 10? Ці шпинделі могли б тоді сприяти іншим навантаженням, а не сидіти, чухаючи себе 60% часу.

PS, в моєму конкретному випадку витрати на RAID 10 не є фактором, тому що я дивлюся на створення декількох масивів RAID 1 і одного невеликого RAID 5. Перехід RAID 10 на потрібний мені простір буде порівнянним.

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

Там дійсно хороший маленький IO калькулятор тут що я часто використовую при плануванні зі сховища. Каталог пам'яті wmarow також приємний для отримання досить сучасних номерів продуктивності диска.

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

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

Виміряйте або обчисліть максимально можливий випадковий IOPS для передбачуваного обсягу призначення, візьміть базову лінію поточного робочого навантаження на цей обсяг, а потім вирішіть, чи є у вас достатньо проміжного місця, щоб помістити ці протоколи IOPS журналу транзакцій у решту випадкових IO в томі призначення. Крім того, не забудьте сплатити бюджет, необхідний для навантаження (очевидно). Якщо ви так схильні, побудуйте у відсотках додатковий «простір» у своєму розподілі робочого навантаження / простору.

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

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

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

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

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

Наскільки передбачувані ви хочете затримати ваші програми?

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

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

Звісно, ​​чому б ні. річ у тому, що пам’ятайте, що правильно скласти великий масив з кількома дисками, помиліться, і ви перебуваєте на тривалий час відновлення.

RAID 10 поставляється у 2-х ароматах:

• RAID 1 + 0, де ви збираєте 2 масиви RAID 1, а потім роздягайте їх.
• RAID 0 + 1, де ви створюєте 2 масиви RAID 0, потім віддзеркалюйте їх.

Як тільки диск вмирає, в одному вам просто доведеться відновити один масив raid1. З іншим вам доведеться відновити весь масив raid0.