В рамках подготовки небольшой инфраструктуры под виртуализацию на базе Linux потребовалось организовать сервер под NFS-шары, которые в последствии планируется использовать под задачу резервного копирования виртуальных машин и прочие полезные цели. Для того, чтобы организовать дисковую ёмкость для NFS-сервера на базе CentOS Linux 7.2, было решено сдуть пыль с пары дисковых полок HP MSA 20, которые давно уже "вялились" на складе, и организовать их прямое подключение к SCSI U320 RAID-контроллеру HP Smart Array 6400. У этого устаревшего контроллера имеется одно не очень приятное ограничение – он не умеет создавать RAID-массивы размером больше 2TB. Чтобы данное ограничение не мешало нам в организации нужного нам объёма дискового пространства, было решено воспользоваться функционалом mdadm (multiple disks admin) для организации программного RAID. В этой заметке мы и рассмотрим пример создания программного дискового массива уровня RAID6 с помощью mdadm в CentOS Linux 7.2.
Итак, в дисковую полку MSA 20 было установлено 5 дисков по 1TB. Контроллер HP Smart Array 6400 устроен таким образом, что не транслирует напрямую в хостовую систему подключенные диски в виде физических дисковых устройств, а транслирует только созданные на нём RAID-массивы. Поэтому я создал на контроллере 5 массивов уровня RAID0, после чего в системе появились соответствующие устройства /dev/cciss/c1d[0-4]:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
cciss!c0d0 104:0 0 68.3G 0 disk
├─cciss!c0d0p1 104:1 0 512M 0 part /boot
├─cciss!c0d0p2 104:2 0 50G 0 part /
├─cciss!c0d0p3 104:3 0 15.9G 0 part /home
├─cciss!c0d0p4 104:4 0 1K 0 part
└─cciss!c0d0p5 104:5 0 2G 0 part
cciss!c1d0 105:0 0 931.5G 0 disk
cciss!c1d1 105:16 0 931.5G 0 disk
cciss!c1d2 105:32 0 931.5G 0 disk
cciss!c1d3 105:48 0 931.5G 0 disk
cciss!c1d4 105:64 0 931.5G 0 disk
Предварительная проверка дисков
Перед тем, как собирать диски в программный RAID-массив, совсем не лишним будет убедиться в том, что с ними всё в порядке. Например можно проверить состояние дисков с помощью технологии S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). В общем случае в CentOS Linux проверить состояние здоровья диска через S.M.A.R.T. можно с помощью утилиты smartctl из состава smartmontools:
# yum install smartmontools
# smartctl --all --health /dev/sdb
Однако в моём случае, как было замечено ранее, устройства /dev/cciss/c[x]d[x] являются не физическими дисками, а логическими устройствами транслированными в ОС контроллером Smart Array. Поэтому вместо утилиты smartctl, для быстрой проверки статуса дисков, можно воспользоваться ранее установленной утилитой hpacucli:
# hpacucli
HP Array Configuration Utility CLI 9.40.12.0
Detecting Controllers...Done.
Type "help" for a list of supported commands.
Type "exit" to close the console.
=>
Пример команд, которые выведут информацию о текущей конфигурации всех массивов и дисков для всех контроллеров Smart Array и подключённых к ним дисковых полок (вывод команд показывать не буду, так как он очень объёмный):
=> ctrl all show config
=> ctrl all show config detail
=> ctrl all show status
Пример команды получения только информации о текущем состоянии физических дисков установленных в отдельно взятой дисковой полке (с отбором по её серийному номеру):
=> ctrl chassisserialnumber=E04KE04K physicaldrive all show status
physicaldrive 1:1 (box 1:bay 1, 1 TB): OK
physicaldrive 1:2 (box 1:bay 2, 1 TB): OK
physicaldrive 1:3 (box 1:bay 3, 1 TB): OK
physicaldrive 1:4 (box 1:bay 4, 1 TB): OK
physicaldrive 1:5 (box 1:bay 5, 1 TB): OK
Итак, предполагаем, что с нашими дисками всё в порядке, и теперь можно перейти к процедуре создания программного RAID-массива.
Создание RAID-массива
Устанавливаем пакет mdadm:
# yum update
# yum install mdadm -y
Утилита mdadm имеет большой ряд параметров запуска и встроенную справку по применению этих параметров. Например, чтобы получить справку по созданию массивов, выполним:
# mdadm --create --help
Следующей командой мы создаём программный массив RAID6 в устройстве /dev/md0 из 5 устройств /dev/cciss/c1d[0-4] с произвольным описанием:
# mdadm --create /dev/md0 --level=6 --raid-devices=5 /dev/cciss/c1d[0-4] --name='MSA20 Chassis E04KE04K'
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
Проверяем состояние массива командой:
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Fri Aug 26 15:12:10 2016
Raid Level : raid6
Array Size : 2929795584 (2794.07 GiB 3000.11 GB)
Used Dev Size : 976598528 (931.36 GiB 1000.04 GB)
Raid Devices : 5
Total Devices : 5
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Fri Aug 26 15:16:25 2016
State : clean, resyncing
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Resync Status : 0% complete
Name : MSA20 Chassis E04KE04K
UUID : ac36eb88:6d3e07be:a56429ae:509d62cb
Events : 50
Number Major Minor RaidDevice State
0 105 0 0 active sync /dev/cciss/c1d0
1 105 16 1 active sync /dev/cciss/c1d1
2 105 32 2 active sync /dev/cciss/c1d2
3 105 48 3 active sync /dev/cciss/c1d3
4 105 64 4 active sync /dev/cciss/c1d4
Как видим, в данный момент наш массив находится в состоянии инициализации (см. State и Resync Status).
Получить список всех массивов в системе можно командой:
# mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name="MSA20 Chassis E04KE04K" UUID=ac36eb88:6d3e07be:a56429ae:509d62cb
Конфигурационный файл mdadm
Для того, чтобы наши массивы автоматически запускались после перезагрузки системы генерируем конфигурационный из текущей запущенной конфигурации mdadm:
# mdadm --verbose --detail --scan > /etc/mdadm.conf
Проверим содержимое получившегося файла mdadm.conf:
# cat /etc/mdadm.conf
ARRAY /dev/md0 level=raid6 num-devices=5 metadata=1.2 name="MSA20 Chassis E04KE04K" UUID=ac36eb88:6d3e07be:a56429ae:509d62cb
devices=/dev/cciss/c1d0,/dev/cciss/c1d1,/dev/cciss/c1d2,/dev/cciss/c1d3,/dev/cciss/c1d4
Немного подправим файл, добавив параметр DEVICE, в котором перечислим все дисковые устройства, которые могут участвовать в каких-либо массивах, плюс соберём все параметры массива в одну строку. В итоге файл примет следующий вид:
DEVICE /dev/cciss/c1d[0-4]
ARRAY /dev/md0 level=raid6 num-devices=5 name="MSA20 Chassis E04KE04K" UUID=ac36eb88:6d3e07be:a56429ae:509d62cb devices=/dev/cciss/c1d0,/dev/cciss/c1d1,/dev/cciss/c1d2,/dev/cciss/c1d3,/dev/cciss/c1d4
Дополнительную информацию о формате конфигурационного файла mdadm можно получить через man mdadm.conf.
В некоторых ситуациях, как это описано, например, здесь, после перезагрузки системы, можно наблюдать такое явление, когда массивы изначально сконфигурированные как, например, /dev/md0, /dev/md1 и т.д., запускаются в системе, как /dev/md126, /dev/md127 и т.д. Чтобы избежать этого, после правки /etc/mdadm.conf нужно обновлять загрузочный образ initramfs. Для этого сначала сделаем резервную копию текущего используемого образа, затем вызовем команду его сборки (модифицированный нами файл /etc/mdadm.conf будет добавлен в загрузочный образ при пересборке):
# cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
# /sbin/dracut --mdadmconf --add="mdraid" --force -v
Перезагрузим наш сервер и убедимся в том, что в процессе загрузки системы, по данным из ранее настроенного конфигурационного файла /etc/mdadm.conf, наш массив успешно запустился и в данный момент всё ещё находится в фазе инициализации.
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 cciss/c1d3[3] cciss/c1d0[0] cciss/c1d2[2] cciss/c1d1[1] cciss/c1d4[4]
2929795584 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] resync = 1.3% (13558472/976598528) finish=399.4min speed=40178K/sec
bitmap: 8/8 pages [32KB], 65536KB chunk
unused devices: none
Если после загрузки по какой-то причине массив не запустился, например в конфигурационном файле мы допустили ошибку, то после правки можно заставить mdadm считать новую конфигурацию и запустить все массивы, которые там записаны командой:
# mdadm --assemble --scan --verbose
Файловая система для RAID-массива
Создаём файловую систему на массиве (в нашем случае это будет ext4), затем создаём каталог, в который будем монтировать созданный раздел и, наконец, монтируем этот раздел:
# mkfs.ext4 /dev/md0
# mkdir /mnt/mdadm-vv1
# mount /dev/md0 /mnt/mdadm-vv1
# df -H /dev/md0
Filesystem Size Used Avail Use% Mounted on
/dev/md0 3.0T 93M 2.9T 1% /mnt/mdadm-vv1
Теперь пропишем в файл /etc/fstab информацию для автоматического монтирования раздела в точку монтирования /mnt/mdadm-vv1 в процессе загрузки системы. Для этого сначала узнаем UUID раздела:
# blkid /dev/md0
/dev/md0: UUID="ace6cab1-015a-475c-aa09-11e12c046db1" TYPE="ext4"
Потом добавим информацию о монтировании в конец файла /etc/fstab
...
#
# Mount software RAID-disk /dev/md0 on /mnt/mdadm-vv1
#
UUID=ace6cab1-015a-475c-aa09-11e12c046db1 /mnt/mdadm-vv1 ext4 discard,defaults 0 2
После этого перезагружаем сервер и убеждаемся в том, что конечный результат достигнут и раздел автоматически монтируется в точку монтирования /mnt/mdadm-vv1. Пробуем создать новый пустой файл в смонтированном в каталог разделе, проверяя тем самым возможность записи в этот каталог:
# touch /mnt/mdadm-vv1/write-test.txt
# rm /mnt/mdadm-vv1/write-test.txt
Мониторинг состояния RAID-массива
Добавляем в конец файла /etc/mdadm.conf параметры определяющие адрес, на который будут отсылаться письма в случае проблем в RAID-массивами (MAILADDR) и адрес отправителя, если нужно (MAILFROM):
...
MAILADDR DST-KOM-FS03-Admins@holding.com
MAILFROM KOM-FS03@holding.com
Перезапускаем службу mdmonitor и проверяем её состояние:
# service mdmonitor restart
# service mdmonitor status
Redirecting to /bin/systemctl status mdmonitor.service
● mdmonitor.service - Software RAID monitoring and management
Loaded: loaded (/usr/lib/systemd/system/mdmonitor.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2016-08-26 20:13:09 MSK; 5s ago
Process: 16057 ExecStart=/sbin/mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid (code=exited, status=0/SUCCESS)
Main PID: 16058 (mdadm)
CGroup: /system.slice/mdmonitor.service
└─16058 /sbin/mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
Aug 26 20:13:09 KOM-FS03.holding.com systemd[1]: Starting Software RAID monitoring and management...
Aug 26 20:13:09 KOM-FS03.holding.com systemd[1]: Started Software RAID monitoring and management.
Чтобы быть уверенным в том, что наш сервер сможет успешно отправлять почту из службы mdmonitor, нам потребуется настроить и проверить сам механизм отправки почты с сервера. О том, как настроить и проверить отправку почты с помощью предустановленной в CentOS Linux 7 службы postfix, написано в Вики-статье Как настроить отсылку уведомлений на внешний почтовый сервер с помощью postfix в CentOS.
Проверка работы RAID-массива
После того, как служба мониторинга запущена, переходим к тестированию нашего массива и заодно проверим то, как отработает механизм оповещений у службы mdmonitor.
Дожидаемся момента, когда массив будет полностью проинициализирован (не должно отображаться состояние resyncing):
# mdadm --detail /dev/md0 | grep State
State : clean
...
Попробуем сымитировать сбой диска в массиве. Помечаем один из дисков массива, как неисправный (в нашем случае в качестве "жертвы" выбран диск /dev/cciss/c1d2):
# mdadm /dev/md0 --fail /dev/cciss/c1d2
mdadm: set /dev/cciss/c1d2 faulty in /dev/md0
Посмотрим, как изменился статус нашего массива:
# mdadm --detail /dev/md0
...
Update Time : Sat Aug 27 17:16:07 2016
State : clean, degraded
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
...
Number Major Minor RaidDevice State
0 105 0 0 active sync /dev/cciss/c1d0
1 105 16 1 active sync /dev/cciss/c1d1
4 0 0 4 removed
3 105 48 3 active sync /dev/cciss/c1d3
4 105 64 4 active sync /dev/cciss/c1d4
2 105 32 - faulty /dev/cciss/c1d2
Параллельно мы должны получить от службы mdmonitor письмо с оповещением о проблеме примерно следующего вида:
This is an automatically generated mail message from 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. The /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: <none>
Как видим, в письме достаточно информации, чтобы идентифицировать проблему.
Удаляем "сбойный" диск из массива:
# mdadm /dev/md0 --remove /dev/cciss/c1d2
mdadm: hot removed /dev/cciss/c1d2 from /dev/md0
На этом этапе, в случае реального выхода из строя диска, подразумевается физическая замена неисправного диска на исправный.
Возвращаем диск в массив:
# mdadm /dev/md0 --add /dev/cciss/c1d2
mdadm: re-added /dev/cciss/c1d2
После добавления диска, автоматически начнётся перестройка массива:
# mdadm --detail /dev/md0
...
Update Time : Sat Aug 27 17:34:21 2016
State : active, degraded, recovering
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
...
Rebuild Status : 92% complete
...
Number Major Minor RaidDevice State
0 105 0 0 active sync /dev/cciss/c1d0
1 105 16 1 active sync /dev/cciss/c1d1
2 105 32 2 spare rebuilding /dev/cciss/c1d2
3 105 48 3 active sync /dev/cciss/c1d3
4 105 64 4 active sync /dev/cciss/c1d4
Дожидаемся успешного окончания перестройки массива, после чего проверку можно считать оконченной.
Форсированное разрушение массива
Пока я экспериментировал с mdadm, столкнулся с одной проблемой – после создания сразу двух массивов (инициализация массивов ещё не была завершена) и неправильной настройки файла mdadm.conf, я получил систему, которая падала в kernel panic в процессе загрузки ОС, то есть фактически, я получил неработоспособную систему. Исправить ситуацию удалось через режим восстановления (загружаемся в установочного диска CentOS и в процессе загрузки жмём ESC, затем вводим "rescue linux dd", чтобы перейти в режим восстановления с возможностью предварительной загрузки драйвера контроллера дисков) и форсированное разрушение массива по методу, подсказанному здесь:
# mdadm --stop /dev/md[x]
# mdadm --zero-superblock /dev/sd[x] (do this for all your raid disks)
В моём случае этого оказалось достаточно для того, чтобы уничтожить метаданные о проблемном массиве с дисков, которые в него входили (вторую команду нужно выполнять для каждого диска), и вернуть систему к работоспособному состоянию. Если же вы столкнётесь с данной ситуацией, и даже после выполнения указанных выше команд, команда blkid продолжит отображать диски в списке блочных устройств, то можно будет попробовать почистить метаданные на дисках, которые участвовали в проблемном RAID-массиве, ещё одним кардинальным способом:
# dd if=/dev/zero of=/dev/sd[x] bs=512 count=1
После удаления данных о массиве не забываем вычистить о нём информацию в /etc/fstab и /etc/mdadm.conf.
Дополнительные источники информации:
RSS - Записи
Спасибо. Без сомнения очень полезная статейка.
Но меня больше заинтересовала первая часть первого предложения "В рамках подготовки небольшой инфраструктуры под виртуализацию на базе Linux ...".
Будет статейка о непосредственно инфраструктуре виртуализации? Ее реализации, какая именно, какие трудности, какие хранилища, как мониторится, как управляется ну и т. д.?
Да. Планируется ряд заметок про развёртывание и базовую настройку oVirt 4.0
Здравствуйте Алексей.
Почему рассмотрен другой вариант создания RAID.?
P.S.
Или вы не рекомендуете проводить установку средствами Centos7 на программный RAID. При установке Centos7 предлагается выбрать например два идентичных диска и создать программный RAID.
Здравствуйте, Андрей. Не понял Вашего вопроса.
У меня таки не работал рейд из коробки centos7. Он конечно ставился, и статистика работала, но стоило отключить 1 диск у зеркала - centos при следующей загрузки уходил в emergency в котором mdadm не мог собраться: писал что неправильный UID у диска. Подключаешь диск - все опять отлично. Так и не смог побороть эту проблему. Вручную собрал рейд постфактум установки - все работает.
Обратная ссылка: работа с RAID Centos 7. mdadm. — Opensips blog /