CentOS Linux 7.2 и программный RAID с помощью mdadm
Итак, в дисковую полку 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.
- Yuriy Kanakov's blog
- 26174 reads
Who's online
Copyright © Home Co. Ltd. LLC, 2008-2022 - Kurgan-Telecom.Ru - VDS/VPS Хостинг в Кургане - All Rights Reserved
