Конфігурація RAID для великих NAS


13

Я думаю створити короб NAS 25 диска на 1 ТБ, але я не впевнений, яка найкраща конфігурація накопичувача. Я дивлюся на використання контролера ARCA-1280ML-2G areca і підвішую з нього всі 24 диски.

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

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

Яке найкраще рішення для цього типу конфігурації? З 24 дисками на 1 ТБ, швидше за все, одночасно вийде з ладу більше (або протягом часу, необхідного для відновлення гучності після першого відмови), тому у мене виникають проблеми з пошуком хорошого рішення.

Відповіді:


10

Вже є рівень RAID для того, що ви хочете; це називається RAID 10.

MTBF для приводів професійного та споживчого рівня в останні роки збільшився на порядок, коефіцієнт непоправної помилки залишився відносно постійним. Ця швидкість оцінюється в 10 ^ 14 біт, тому один біт на 12 терабайт зчитується для споживчих накопичувачів SATA, джерело .

Отже, при кожному скануванні ваших пропусків накопичувача 24 ТБ статистично ви зустрінете щонайменше 2 поодинокі помилки. Кожна з цих помилок призведе до відновлення RAID5, і що ще гірше, під час відновлення друга помилка спричинить подвійну помилку.


Відмінні бали щодо невиправленого рівня помилок, але в третьому абзаці слід додати, що "статистично ви зіткнетесь ...", оскільки всі ми знаємо, що помилки читання (або їх відсутність) не визначені
Метт Сіммонс

Не спробуєте прочитати ще раз перед перебудовою?
Антуан Бенкемун

Антуан: Звичайно, але якщо його справді неможливо прочитати, його доведеться перебудувати, щоб отримати дані з паритету, IIRC.
Метт Сіммонс

@Antonie, це непоправні помилки читання, тобто помилки, які не можна виправити за допомогою логіки ECC накопичувачів (що виправляє помилки зі швидкістю, значно вищою за 1: 10 ^ 14)
Дейв Чейні,

Отже, це помилки, які викликані помилками запису? що перешкоджає повторному читанню читання?
Антуан Бенкемун

11

Це саме моя щоденна робота ... створення серверів зберігання Linux.

  • Картка Areca в порядку. Ви можете використовувати його в RAID-6, це забезпечить розумну безпеку. Купуйте також додатковий резервний пристрій для акумулятора .
  • Використовуйте корпоративні диски , а не настільні диски. Ви витратите ще 400 доларів на свій сервер, але це того варто. Купіть два запасні диски. Не сваріться з цим, використовуйте диски тієї ж моделі.
  • Для файлової системи використовуйте XFS . Не жартуючи, ext3 та друзі просто не вирішать роботу для файлових систем 16TB +. Навіть у випадку серйозної аварії, xfs_repair буде досить швидким на об'ємі 20 ТБ (15 хвилин, не більше).
  • Переважно, використовуйте LVM2 , це полегшить управління зберіганням, навіть якщо ви не плануєте його сильно змінювати.
  • встановіть інструмент керування areca та напишіть завдання cron, щоб надсилати вам щоденне повідомлення електронної пошти з перевірки стану здоров’я.
  • Не забувайте резервного копіювання . RAID - це не резервне копіювання; якщо хтось просто видалить важливий файл, ви не зможете відновити його без відповідної резервної копії. Я особисто використовую rdiff-резервне копіювання для збереження всіх важливих даних на спеціальному сервері з одномісячною історією; ви також можете створити два томи RAID на своєму файловому сервері та створити резервну копію на іншому.

6

вау, RAID5 над RAID5? Хочете обговорити проблеми ефективності? У вас буде тонни . Хазяїн, на якого ви повісили, матиме кошенят, які обчислюють паритет, записуючи цей паритет на 3 диски, а потім обчислюючи паритет ТОЧНОГО паритету і записуючи його на 4-й диск цього набору. ОЦЕ ТАК!

Давайте поговоримо про RAID10. По суті це RAID 1, але ви розділите свої накопичувачі навпіл і віддзеркалюйте це. Це вірогідно в тому, що ви можете втратити 2 накопичувачі і все одно добре, плюс продуктивність видатна.

Якщо вам не потрібно божевільний простір, але у вас є масив 24 ТБ, який сидить навколо, нічого кращого робити, але це абсолютно позитивно повинно бути вгору, тоді ви можете розглянути RAID60. По суті це RAID6, використовуючи дзеркальні набори накопичувачів. Ви втратите близько половини своїх накопичувачів, а продуктивність буде поганою, але ви будете майже гарантовані, що дані будуть там.

Дійсно, я б пішов з RAID10. Це добре і добре працює. Я другий, на думку Евана, що ви, мабуть, не повинні робити гігантські набори RAID з багатьох дисків, тому що, як він каже, такі речі, як fsck і chkdsk, візьмуться назавжди, але що ще важливіше, на мій погляд, оскільки статистична ймовірність помилки читання збільшується в залежності від розміру індивідуального диска. Я рекомендую 7-10 дисків на набір. Ви можете створити 3 томи RAID пристойного розміру з такою кількістю шпинделів.

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


@Matt: Я не кажу про розмір наборів RAID - я кажу про розмір файлової системи. Використання однієї великої файлової системи, незалежно від типу файлової системи, вимагає величезного простою, коли вам потрібно запустити перевірку файлової системи, оскільки хост ОС «пошкодив» файлову систему тощо
Еван Андерсон,

@Evan - Вибач, моя погана. Але це ще один аргумент проти цього.
Метт Сіммонс,

@Matt: Аргумент проти чого? Розташування контейнерів RAID та кількість файлових систем на цих контейнерах RAID є ортогональними питаннями. Не потрібно мати єдину файлову систему в одному контейнері RAID, і файлова система може охоплювати кілька контейнерів RAID у більшості операційних систем.
Еван Андерсон

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


1

Я знаю, що ви сказали "R&D", але ви також сказали "дуже доступно". Я б поставив під сумнів "економію" рішення "Зробіть сам" порівняно з придбанням позарядних передач SAN для цього. Коли з вашим рішенням "Зроби сам" все піде не так, ви опинитесь у незавидному становищі, коли немає до кого звернутися за допомогою. Що коштує простой у годину? Ви можете швидко з'їсти вартість деяких середньорівневих передач SAN в умовах простою, ігноруючи витрати, пов'язані з неправильною втратою даних.

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

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

Як приклад: у світі Windows запуск CHKDSK на томі 20TB NTFS, наповнений файлами, буде мало . У такому середовищі я б створив кілька менших томів NTFS і логічно об'єднав би їх в єдиний простір імен з DFS.


1

wazoox, відповіді хороші. У мене немає представника, щоб дати йому більше плюс балів, але я б додав наступне.

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

Якщо ви їдете по маршруту Linux, я б або скористався апаратною рейдовою карткою (з резервним запасом батареї) або мав рейдовий контролер у корпусі диска. Я погоджуюся, що xfs - це обрана файлова система в Linux, однак пам’ятайте, що файлові системи близько 50 Тб на xfs займають більше 16 ГБ оперативної пам’яті, якщо вам потрібно запустити xfs_check.

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

Виконання nfs / samba для успішної роботи - це трохи темне мистецтво. Чи будете ви використовувати ефір 10 Гб або просто агрегацію 1 Гб / сек? (Не отримуйте картки Broadcomm, особливо 10 ГБ).

LVM2 не є мозком, але не використовуйте оснащення, оскільки це не швидко.

Пам'ятайте, що резервне копіювання цього потребуватиме певного часу.

Перевірте те, як система може вийти з ладу, перш ніж вона вийде у виробництво, і запишіть її там, де ви та ваші колеги зможете знайти документи, коли все піде не так.


1

Це залежить від співвідношення читання / запису. Ми використовуємо багато зовнішніх корпусів SAS накопичувачів SAS HP MSA70 і завжди створюємо їх як єдиний масив RAID6, оскільки наш коефіцієнт читання та запису становить 99%: 1%, тому нам не байдуже, що R6 проходить самим повільним при написанні ( все ще досить швидко, просто не так добре в порівнянні з іншими). Таким чином, у нас є 23 диски, варті доступних нам даних, мають дуже хороші результати, як у ДУЖЕ хорошому, випадковому зчитуванні та загальній перевазі пропускної здатності читання і можуть пережити два збої диска.

Як орієнтовний посібник, масив RAID5 не повинен мати більше 14 дисків в одному масиві, тоді як RAID6 має бути добре з 54 дисками або близько того - очевидно, чим більший масив, тим більша прогалина між продуктивністю читання і запису та повільніші відновлення знадобляться, але це МОЖЕ бути хорошим компромісом.


0

Я б до початку додав два резервні диски.

RAID 5 або 6 добре для випадкових читання або великих послідовних зчитувань і записів. Якщо ви збираєтеся отримати багато невеликих записів, перейдіть з RAID 10, оскільки RAID 5+ отримує 4-кратне звернення до малих записів.

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

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