Налаштування Software RAID (mdadm) для серверів

Чому налаштування Software RAID (mdadm) на серверах іде не за планом

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

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

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

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

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

Гірше, коли перевірка запускається вперше саме в момент аварії: масив перебудовується за пошкодженим членом і тиражує помилку на всі копії.

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

Що дає зібраний масив: час простою та класи відмов

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

Для замовника це різниця між «нічний дзвінок і відновлення з копії» та «ранкова заміна диска за регламентом». Простій сервісу в момент відмови вимірюється секундами перемикання, а не годинами.

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

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

Вона йде за розкладом, тому невідповідності спливають до того, як стануть відмовою, а не в момент пікового навантаження.

Чого масив не закриває — відмову контролера, кабелю, живлення та помилкові дії адміністратора. Резервні копії залишаються обов’язковими: масив відповідає за безперервність, а не за відновлення даних. Цю межу ми проговорюємо відразу, щоб не створювати хибного відчуття захищеності.

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

Варіанти організації дискового масиву: порівняння підходів

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

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

Жоден варіант не скасовує другого: масив захищає від відмови накопичувача, але не від відмови самої машини.

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

Як проходить впровадження: аудит, схема, складання, перевірка

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

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

1. Аудит конфігурації сервера та інвентаризація накопичувачів. Дивимося моделі й ресурс дисків, розбиття, файлові системи, що вже зібрано в масиви, які розділи беруть участь у завантаженні, яке навантаження на введення-виведення і чи є вільні відсіки під заміну без зупинки.
2. Проєктування схеми масиву. Обираємо рівень надлишковості та розмір смуги під реальний профіль читання-запису, кількість робочих дисків і резервних, розмічаємо службові та завантажувальні розділи так, щоб система піднімалася навіть із накопичувачем, що випав.
3. Складання mdadm. Створюємо масив, розмічаємо й монтуємо за ідентифікаторами, а не за іменами пристроїв, прописуємо залежності в завантажувач і образ початкового завантаження, щоб порядок дисків, які визначилися, нічого не ламав.
4. Перевірка відновлення. Навмисно виводимо накопичувач, дивимося, як проходить перезбирання і скільки воно триває, чи поводиться сервіс передбачувано в цей час і чи повертається резерв у стрій автоматично.
5. Моніторинг і обслуговування. Налаштовуємо оповіщення про деградацію масиву, ведемо журнал подій, ставимо в розклад планову перевірку парності — тоді розходження блоків ловиться до відмови, а не на відновленні.
6. Передача регламентів. Віддаємо документацію щодо схеми, процедуру заміни накопичувача крок за кроком, матрицю «що робити при деградації» та порядок перевірки після будь-яких змін.

Конфігурації, схеми масиву та регламенти обслуговування

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

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

• Файл конфігурації масиву: склад дисків, рівень надлишковості, розмір блоку та прив’язка до ідентифікаторів накопичувачів, а не до імен пристроїв. Після перезавантаження масив збирається сам, незалежно від порядку визначення дисків.
• Карта підключення накопичувачів: контролер, слот, серійний номер і роль кожного диска, окремо позначено слоти під гарячу заміну. Інженер виймає потрібний накопичувач, не зачепивши сусідній масив.
• Регламент заміни диска: що перевірити до виймання, як увести новий накопичувач у масив, на які стани дивитися під час перезбирання і коли операція вважається закритою.
• Політики доступу: кому дозволено операції з масивом, як обмежено права, куди пишеться журнал команд. Випадкове виключення диска перестає бути незворотним.
• Порядок планових перевірок: опитування стану накопичувачів і масиву за розкладом, звіряння контрольних сум, пороги, за яких інженер втручається до відмови.
• Інструкція з відновлення: сценарії деградації та повної втрати масиву, порядок складання на новому сервері, точки, де дані втрачаються безповоротно.
• Документація щодо сервера: зв’язок масиву з розділами, точками монтування та завантаженням, що змінюється під час розширення.

Комплект живе разом із сервером у репозиторії конфігурацій: наступна заміна диска йде за документом, а не за пам’яттю.

Практика: складання масиву та відновлення після деградації

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

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

Що змінили

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

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

Результат у цифрах

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

mdadm чи апаратний контролер: що вибрати для сервера

Коротка відповідь: вибір визначається не швидкістю, а тим, наскільки ви готові залежати від конкретної моделі плати. Програмний масив mdadm збирається ядром поверх звичайних накопичувачів, апаратний — живе всередині контролера зі своїм кешем і логікою.

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

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

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

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

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

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

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

Розбір частих сумнівів: деградація, заміна диска, моніторинг

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

Чи можна замінити диск без перевстановлення й зупинки сервісів?

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

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

Як переконатися, що масив справді цілий, а не «просто відповідає»?

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

Чи потрібен окремий моніторинг, якщо масив відновлюється сам?

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

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

Обговоримо задачу: повернемося з оцінкою та планом робіт

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

Що потрібно від вас для старту:

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

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

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