Правильно ли я настроил RAID?

[KALIBR-10]

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

Код: [Выделить]

wipefs --all --force /dev/sd{c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z}

На каждом диске создал таблицу разделов и раздел типа RAID:

Код: [Выделить]

(parted) mklabel gpt                                                     
(parted) mkpart raid ext4 1Mib 100%                                       
(parted) set 1 raid on

Создал 2 рейда:

Код: [Выделить]

# mdadm --create --verbose /dev/md126 -l 6 -n 12 /dev/sd{c,d,e,f,g,h,i,j,k,l,m,n}1
# mdadm --create --verbose /dev/md127 -l 6 -n 10 /dev/sd{o,p,q,r,s,t,u,v,w,x}1


Код: [Выделить]

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md127 : active raid6 sdx1[9] sdw1[8] sdv1[7] sdu1[6] sdt1[5] sds1[4] sdr1[3] sdq1[2] sdp1[1] sdo1[0]
      62511144960 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
      [>....................]  resync =  0.0% (1336156/7813893120) finish=1266.8min speed=102781K/sec
      bitmap: 59/59 pages [236KB], 65536KB chunk

md126 : active raid6 sdn1[11] sdm1[10] sdl1[9] sdk1[8] sdj1[7] sdi1[6] sdh1[5] sdg1[4] sdf1[3] sde1[2] sdd1[1] sdc1[0]
      78138931200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
      [>....................]  resync =  0.0% (4159056/7813893120) finish=1001.4min speed=129970K/sec
      bitmap: 59/59 pages [236KB], 65536KB chunk

md125 : active raid1 sda1[0] sdb1[1]
      586057664 blocks [2/2] [UU]
     
unused devices: <none>

Создал файл /etc/mdadm.conf:

Код: [Выделить]

#
#  /etc/mdadm.conf  --  mdadm configuration file
#
#  Customized for ALTLinux
#  See complete sample on manual page and in documentation directory
#
#  This is a minimalistic skeleton but it should work out-of:a+box!
#

MAILADDR root
PROGRAM /sbin/mdadm-syslog-events
DEVICE partitions
ARRAY /dev/md/125 metadata=0.90 UUID=15075b5a:cc7aaf6b:1d83e7eb:114865ed
ARRAY /dev/md126 metadata=1.2 name=mlxbackups2.localdomain:126 UUID=1e6fe826:44cdadbf:33572379:c3a85f78
ARRAY /dev/md127 metadata=1.2 name=mlxbackups2.localdomain:127 UUID=775fc238:4c5885b9:247bc053:798b60ca
## EOF ##

На этот раз дождусь пока рейды синхронизируются и перезагружу сервер, рейды при этом должны быть активны?

[klark973]

Интересно, куда исчезло предыдущее сообщение про ваш рейд? Какой смысл отвечать, если сообщения потом пропадают...

после перезагрузки сервера получил inactive, и поскольку не смог активировать всё переделал с нуля

Вообще-то одной командой это лечится. Но все детали здесь вырезаны.

На каждом диске создал таблицу разделов и раздел типа RAID:

Интересно, зачем? Ведь gpt прекрасно ляжет на mdp (с ядра 3.14+, если не изменяет память), необязательно объединять разделы, можно поступить наоборот.

На этот раз дождусь пока рейды синхронизируются и перезагружу сервер, рейды при этом должны быть активны?

Обычно никто не ждёт. И это ненормально, что рейды после ребута автоматом не активируются. Мы это уже ни раз чинили в make-initrd, но проверить будет нелишним.

Правильно ли я настроил RAID?

А кто же его знает? Во-первых, цели этого конфигурирования тут не определены. Во-вторых, в первом сообщении была дополнительная информация, сейчас её уже нет. Там что-то говорилось о дисках HGST, а они очень разные бывают. Например, есть с прошивками, ориентированными на максимально быстрый отказ. Тогда их надо ставить в RAID-0, надёжность и скорость обеспечивается за счёт дублирования в сети быстро вылетающих кластерных нод. В-третьих, хотя программный рейд всё же предпочтительней, RAID-6 реальный мегатормоз при дегрейде и периодическом перестроении.

[KALIBR-10]

Интересно, куда исчезло предыдущее сообщение про ваш рейд? Какой смысл отвечать, если сообщения потом пропадают...

Предыдущую тему я просто удалил, там я не мог создать рейд по собственной не внимательности, в итоге получилось, и чтобы не отвлекать людей решил тему грохнуть, но после создал эту

А кто же его знает? Во-первых, цели этого конфигурирования тут не определены. Во-вторых, в первом сообщении была дополнительная информация, сейчас её уже нет. Там что-то говорилось о дисках HGST, а они очень разные бывают. Например, есть с прошивками, ориентированными на максимально быстрый отказ. Тогда их надо ставить в RAID-0, надёжность и скорость обеспечивается за счёт дублирования в сети быстро вылетающих кластерных нод. В-третьих, хотя программный рейд всё же предпочтительней, RAID-6 реальный мегатормоз при дегрейде и периодическом перестроении.

С нуждами-то определился, не в этом проблема, в последовательности действий при его создании.
Но видимо что-то сделал не правильно. Перезагрузил я сервер и вот что получил в итоге:

Код: [Выделить]

# cat /proc/mdstat
Personalities : [raid1]
md125 : inactive sdc1[0] sdl1[9] sdg1[4] sdn1[11] sdf1[3] sdj1[7] sdd1[1] sdi1[6] sdm1[10] sdh1[5] sde1[2] sdk1[8]
      93766717440 blocks super 1.2
       
md126 : inactive sdv1[7] sdp1[1] sdw1[8] sdr1[3] sdx1[9] sds1[4] sdu1[6] sdq1[2] sdo1[0] sdt1[5]
      78138931200 blocks super 1.2
       
md127 : active raid1 sda1[0] sdb1[1]
      586057664 blocks [2/2] [UU]


[klark973]

Предыдущую тему я просто удалил, там я не мог создать рейд по собственной не внимательности, в итоге получилось, и чтобы не отвлекать людей решил тему грохнуть, но после создал эту

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

С нуждами-то определился, не в этом проблема, в последовательности действий при его создании.

Ну, я бы делал не md, а mdp, т.е. не кучу рейдов поверх разделов, а наоборот -- объединил целые диски в рейды, а уже полученные рейды делил бы на разделы (если нужно), т.к. речь тут не о системных дисках. Впрочем, дело вкуса.

Но видимо что-то сделал не правильно. Перезагрузил я сервер и вот что получил в итоге:

Нет, тут давняя ошибка в make-initrd. Гоняюсь за ней, как за неуловимы Джо. Вполне возможно, опять потеряли этот коммит из p8. Теперь попробуйте mdadm -IRs

[KALIBR-10]

Теперь так:

Код: [Выделить]

[root@mlxbackups2 ~]# mdadm -IRs
mdadm: started array /dev/md/mlxbackups2.localdomain:127
mdadm: started array /dev/md/mlxbackups2.localdomain:126
[root@mlxbackups2 ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md125 : active (auto-read-only) raid6 sdc1[0] sdl1[9] sdg1[4] sdn1[11] sdf1[3] sdj1[7] sdd1[1] sdi1[6] sdm1[10] sdh1[5] sde1[2] sdk1[8]
      78138931200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
      resync=PENDING
      bitmap: 41/59 pages [164KB], 65536KB chunk

md126 : active (auto-read-only) raid6 sdv1[7] sdp1[1] sdw1[8] sdr1[3] sdx1[9] sds1[4] sdu1[6] sdq1[2] sdo1[0] sdt1[5]
      62511144960 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
      resync=PENDING
      bitmap: 12/59 pages [48KB], 65536KB chunk

md127 : active raid1 sda1[0] sdb1[1]
      586057664 blocks [2/2] [UU]
     
unused devices: <none>


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

Вот тут тема осталась, там реально мой косяк по невнимательности.
https://sysadmins.ru/topic535034.html?sid=46569a55c7c8b13468ad59e01df72b8c

[KALIBR-10]

Вывел массивы из состояния ридонли:

Код: [Выделить]

[root@mlxbackups2 ~]# mdadm -w /dev/md125
[root@mlxbackups2 ~]# mdadm -w /dev/md126
[root@mlxbackups2 ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md125 : active raid6 sdc1[0] sdl1[9] sdg1[4] sdn1[11] sdf1[3] sdj1[7] sdd1[1] sdi1[6] sdm1[10] sdh1[5] sde1[2] sdk1[8]
      78138931200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
      [======>..............]  resync = 31.0% (2425397816/7813893120) finish=703.5min speed=127642K/sec
      bitmap: 41/59 pages [164KB], 65536KB chunk

md126 : active raid6 sdv1[7] sdp1[1] sdw1[8] sdr1[3] sdx1[9] sds1[4] sdu1[6] sdq1[2] sdo1[0] sdt1[5]
      62511144960 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
      [================>....]  resync = 82.4% (6441008128/7813893120) finish=467.9min speed=48896K/sec
      bitmap: 12/59 pages [48KB], 65536KB chunk

md127 : active raid1 sda1[0] sdb1[1]
      586057664 blocks [2/2] [UU]

Но ведь это не нормально если после каждой перезагрузки их так заводить

[klark973]

Теперь так:

Осталось mdadm -w /dev/md126 && mdadm -w /dev/md127 (о, смотрю уже!), чтобы окончательно вылечить ситуацию и вот с этим всем нужно писать в багзилу на компонент startup или systemd, если последняя стабильная система и она корректно обновлена. Иначе придётся лечить руками/скриптом после каждой перезагрузки. Дело в том, что "лекарство" в make-initrd не успевает отрабатывать для этих больших массивов, т.к. задача initrd найти корень и загрузиться с него. Очевидно в юзерспейсе нашей второй стадии аналогичного лекарства нет, нужно посоветоваться с shaba@, куда это лучше приткнуть.

Вот тут тема осталась

Там была такая необычная ошибка:
mdadm: failed to open /dev/sdg after earlier success - aborting
Она лечится предварительной чисткой сигнатур (wipefs -a или mdadm --zero-superblock).

[rits]

https://youtu.be/h5xVXdvoXUQ
Не поленись - посмотри!

[KALIBR-10]

Написал в багзиллу https://bugzilla.altlinux.org/show_bug.cgi?id=39695

[klark973]

Написал в багзиллу https://bugzilla.altlinux.org/show_bug.cgi?id=39695

Интересная ошибка! Немного разобрался. Понятно, куда копать...

Всё нештатное, что раньше делали, делать не надо. Попробуйте "вылечить" после загрузки, и не монтируя ничего с него корректно вручную остановить массивы (mdadm --stop ...), затем перезагрузиться. Правила udev сейчас таковы, что если /sys/block/mdX/array_state содержит "clear*" или "inactive", массив этими правилами не соберётся. Если после перезапуска будет снова "inactive", значит проблему создаёт make-initrd в процессе сборки первого рейда -- он выполняет pivot_root не дожидаясь двух других рейдов. Если же проблема устранится, значит имеем проблему в systemd в части выключения/отмонтирования (mdadm.shutdown).

[klark973]

Если после перезапуска будет снова "inactive", значит проблему создаёт make-initrd в процессе сборки первого рейда -- он выполняет pivot_root не дожидаясь двух других рейдов.

Для решения этой проблемы (если подтвердится) нашёл простой воркэраунд: временно скопировать куда-то /etc/mdadm.conf, внести в него одно изменение:

Код: [Выделить]

-DEVICE partitions
+DEVICE /dev/sd[ab]1
после чего запустить make-initrd и вернуть обратно сохранённый конфиг. По идее, никто в initramfs после такого финта пытаться собирать массивы из оставшихся дисков не должен, а следовательно, при корректном отключении состояния inactive не возникнет и правила udev должны отработать штатно. Однако сразу предупрежу, что вместо /dev/sda и /dev/sdb здесь лучше использовать /dev/disk/by-* -- взять что-то подходящее отсюда и искать диски по чему угодно, да хоть по серийнику, а не по нодам.

[KALIBR-10]

Для решения этой проблемы (если подтвердится) нашёл простой воркэраунд: временно скопировать куда-то /etc/mdadm.conf, внести в него одно изменение:

Код: [Выделить]

-DEVICE partitions
+DEVICE /dev/sd[ab]1
после чего запустить make-initrd и вернуть обратно сохранённый конфиг. По идее, никто в initramfs после такого финта пытаться собирать массивы из оставшихся дисков не должен, а следовательно, при корректном отключении состояния inactive не возникнет и правила udev должны отработать штатно. Однако сразу предупрежу, что вместо /dev/sda и /dev/sdb здесь лучше использовать /dev/disk/by-* -- взять что-то подходящее отсюда и искать диски по чему угодно, да хоть по серийнику, а не по нодам.

Может быстрее будет предоставить удаленный доступ для решения проблемы?

[klark973]

Да нет, не быстрее, т.к. до 2 марта буду совсем недоступен. К тому же загадка разгадана, осталось лишь получить подтверждение. Вот уже и legion@ согласился, что идём верным путём.))

[KALIBR-10]

Да нет, не быстрее, т.к. до 2 марта буду совсем недоступен. К тому же загадка разгадана, осталось лишь получить подтверждение. Вот уже и legion@ согласился, что идём верным путём.))

Ок, завтра проверю отпишусь

[asy]

Вот уже и legion@ согласился, что идём верным путём.))

Интересная рассылка. И тема интересная. И фраза интересная:

>> Главное, чтобы эти рейды с данными не начинал собирать
>> интеллект в initramfs (ограничить DEVICES=...), тогда в
>> обычной системе правила udev сами его соберут.

Я завтра проверю: https://bugzilla.altlinux.org/29831#c29. Система с /boot с nofail у меня загрузилась, но я не помню, чтобы у меня /boot смонтирован оказался.