CentOS Linux 7
Зібрання нотаток про інформаційні технології
У рамках підготовки невеликої інфраструктури під віртуалізацію на базі Linux потрібно було організувати сервер під NFS-кулі, які планується використовувати під завдання резервного копіювання віртуальних машин та інші корисні цілі. Для того, щоб організувати дискову ємність для NFS-сервера на базіCentOS Linux 7.2, було вирішено здути пил з пари дискових полицьHP MSA 20, які давно вже «велися» на складі, та організувати їх пряме підключення до SCSI U320RAID -контролераHP Smart Array 6400. Цей застарілий контролер має одне не дуже приємне обмеження – він не вміє створювати RAID-масиви розміром більше2TB. Щоб це обмеження не заважало нам в організації потрібного нам об'єму дискового простору, було вирішено скористатися функціоналомmdadm (multipledisksadmin ) для організації програмного RAID. У цій замітці ми і розглянемо приклад створення програмного дискового масиву рівняRAID6 за допомогоюmdadm уCentOS Linux 7.2.
Отже, дискову полицю MSA 20 було встановлено 5 дисків по 1TB. Контролер HP Smart Array 6400 влаштований таким чином, що не транслює безпосередньо до хостової системи підключені диски у вигляді фізичних дискових пристроїв, а транслює тільки створені на ньому RAID-масиви. Тому я створив на контролері 5 масивів рівня RAID0, після чого у системі з'явилися відповідні пристрої /dev/cciss/c1d[0-4]:
Попередня перевірка дисків
Перед тим, як збирати диски в програмний RAID-масив, зовсім не зайвим буде переконатися, що з ними все гаразд. Наприклад, можна перевірити стандисків за допомогою технологіїS.M.A.R.T. (S elf-M onitoring,A nalysis andR eportingT echnology). У випадку CentOS Linux перевірити стан здоров'я диска через S.M.A.R.T. можна за допомогою утилітиsmartctl зі складуsmartmontools :
Однак у моєму випадку, як було зазначено раніше, пристрої /dev/cciss/c[x]d[x] є не фізичними дисками, а логічними пристроями трансльованими в ОС контролером Smart Array. Тому замість утилітиsmartctl, для швидкої перевірки статусу дисків, можна скористатися раніше встановленою утилітоюhpacucli :
Приклад команд, які виведуть інформацію про поточну конфігурацію всіх масивів і дисків для всіх контролерів Smart Array і підключених до них дискових полиць (виведення команд показувати не буду, оскільки він дуже об'ємний):
Приклад команди отримання лише інформації про поточний стан фізичних дисків встановлених в окремо взятій дисковій полиці (з відбором за серійним номером):
Отже, припускаємо, що з нашими дисками все гаразд і тепер можна перейти до процедури створення програмного RAID-масиву.
Створення RAID-масиву
Встановлюємо пакетmdadm :
Утиліта mdadm має велику низку параметрів запуску та вбудовану довідку щодо застосування цих параметрів. Наприклад, щоб отримати довідку щодо створення масивів, виконаємо:
Наступною командою ми створюємо програмний масивRAID6 у пристрої /dev/md0 з 5 пристроїв /dev/cciss/c1d[0-4] з довільним описом:
Перевіряємо стан масиву командою:
Як бачимо, зараз наш масив знаходиться в стані ініціалізації (див.State іResync Status ).
Отримати список усіх масивів у системі можна командою:
Конфігураційний файл mdadm
Для того, щоб наші масиви автоматично запускалися після перезавантаження системи, генеруємо конфігураційний з поточної запущеної конфігурації mdadm:
Перевіримо вміст файлу mdadm.conf :
Трохи підправимо файл, додавши параметрDEVICE, в якому перерахуємо всі дискові пристрої, які можуть брати участь у будь-яких масивах плюс зберемо всі параметри масиву в один рядок. У результаті файл набуде наступного вигляду:
Додаткову інформацію про формат конфігураційного файлу mdadm можна отримати черезman mdadm.conf.
У деяких ситуаціях, як це описано, наприклад, тут , після перезавантаження системи, можна спостерігати таке явище, коли масиви спочатку налаштовані як, наприклад, /dev/md0 , /dev/md1 і т.д., запускаються в системі, як / dev/md126, /dev/md127 і т.д. Щоб уникнути цього, після редагування /etc/mdadm.conf потрібно оновлювати завантажувальний образinitramfs. Для цього спочатку зробимо резервну копію поточного образа, що використовується, потім викличемо команду його складання (модифікований нами файл /etc/mdadm.conf буде доданий в завантажувальний образ при пересборці):
Перезавантажимо наш сервер і переконаємося в тому, що в процесі завантаження системи, за даними з налаштованого конфігураційного файлу /etc/mdadm.conf , наш масив успішно запустився і в даний момент все ще знаходиться в фазі ініціалізації.
Якщо після завантаження з якоїсь причини масив не запустився, наприклад в конфігураційному файлі ми припустилися помилки, то після виправлення можна змусити mdadm рахувати нову конфігурацію і запустити всі масиви, які там записані командою:
Файлова система для RAID-масиву
Створюємо файлову систему на масиві (у нашому випадку це будеext4 ), потім створюємо каталог, в який монтуватимемо створений розділ і, нарешті, монтуємо цей розділ:
Тепер пропишемо у файл /etc/fstab інформацію для автоматичного монтування розділу в точку монтування /mnt/mdadm-vv1 під час завантаження системи. Для цього спочатку дізнаємосяUUID розділу:
Потім додамо інформацію про монтування на кінець файлу /etc/fstab
Після цього перезавантажуємо сервер і переконуємося в тому, що кінцевого результату досягнуто і розділ автоматично монтується в точку монтування /mnt/mdadm-vv1. Пробуємо створити новий порожній файл у змонтованому в каталог розділі, перевіряючи цим можливість запису в цей каталог:
Моніторинг стану RAID-масиву
Перезапускаємо службуmdmonitor та перевіряємо її стан:
Щоб бути впевненим у тому, що наш сервер зможе успішно надсилати пошту зі службиmdmonitor, нам потрібно буде налаштувати та перевірити сам механізм надсилання пошти із сервера. Про те, як налаштувати та перевірити відправку пошти за допомогою встановленої в CentOS Linux 7 службиpostfix, написано у Вікі-статті Як налаштувати відсилання повідомлень на зовнішній поштовий сервер за допомогою postfix у CentOS .
Перевірка роботи RAID-масиву
Після того, як служба моніторингу запущена, переходимо до тестування нашого масиву і заразом перевіримо те, як відпрацює механізм оповіщень у службиmdmonitor.
Очікуємо моменту, коли масив буде повністю проініціалізований (не повинен відображатися станresyncing ):
Спробуємо зімітувати збій диска в масиві. Позначаємо один із дисків масиву, як несправний (у нашому випадку як «жертву» вибрано диск /dev/cciss/c1d2 ):
Подивимося, як змінився статус нашого масиву:
Паралельно ми повинні отримати від службиmdmonitor лист із оповіщенням про проблему приблизно наступного виду:
Це автоматично створений електронний лист з mdadm running on KOM-FS03.holding.com
A Fail event had been detected on md device /dev/md0 . It could be related to component device /dev/cciss/c1d2 .
Faithfully yours, etc.
P.S. /proc/mdstat file currently contains the following:
Personalities : [raid6] [raid5] [raid4] md0 : active raid6 cciss/c1d3[3] cciss/c1d1[1] cciss/c1d4[4] cciss/c1d0[0] cciss/c1d2[2] (F ) 2929795584 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/4] [UU_UU] bitmap: 2/8 pages [8KB], 65536KB chunk unused devices:
Як бачимо, у листі достатньо інформації, щоб ідентифікувати проблему.
Видаляємо «збійний» диск із масиву:
На цьому етапі, у разі реального виходу з ладу диска, мається на увазі фізична заміна несправного диска на справний.
Повертаємо диск у масив:
Після додавання диска автоматично почнеться перебудова масиву:
Чекаємо на успішне закінчення перебудови масиву, після чого перевірку можна вважати закінченою.
Форсована руйнація масиву
Поки я експериментував зmdadm, зіткнувся з однією проблемою – після створення одразу двох масивів (ініціалізація масивів ще не була завершена) та неправильного налаштування файлу mdadm.conf , я отримав систему, яка падала уkernel panic у процесі завантаження ОС, тобто фактично, я отримав непрацездатну систему. Виправити ситуацію вдалося через режим відновлення (завантажуємося в інсталяційному диску CentOS і в процесі завантаження тиснемоESC, потім вводимо "rescue linux dd ", щоб перейти в режим відновлення зможливістю попереднього завантаження драйвера контролера дисків) та форсована руйнація масиву за методом, підказаним тут:
У моєму випадку цього виявилося достатньо для того, щоб знищити метадані про проблемний масив з дисків, які до нього входили (другу команду потрібно виконувати для кожного диска), і повернути систему до працездатного стану. Якщо ж ви зіткнетеся з цією ситуацією, і навіть після виконання вказаних вище команд, командаblkid продовжить відображати диски у списку блокових пристроїв, то можна буде спробувати почистити метадані на дисках, які брали участь у проблемному RAID-масиві, ще одним кардинальним способом:
Після видалення даних про масив не забуваємо вичистити про нього інформацію в /etc/fstab і /etc/mdadm.conf.
Додаткові джерела інформації :