CentOS Linux 7.2 и программный RAID с помощью mdadm

imageВ рамках подготовки небольшой инфраструктуры под виртуализацию на базе 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.

 

Дополнительные источники информации:

Всего комментариев: 2 Комментировать

  1. AlektroNik /

    Спасибо. Без сомнения очень полезная статейка.
    Но меня больше заинтересовала первая часть первого предложения "В рамках подготовки небольшой инфраструктуры под виртуализацию на базе Linux ...".
    Будет статейка о непосредственно инфраструктуре виртуализации? Ее реализации, какая именно, какие трудности, какие хранилища, как мониторится, как управляется ну и т. д.?

    1. Алексей Максимов / Автор записи

      Да. Планируется ряд заметок про развёртывание и базовую настройку oVirt 4.0

Добавить комментарий