В настройках grub корневая система как указана?

да, такое наблюдается. При этом если штатно (--fail, затем --remove) вывести один диск из массива, то с оставшегося загрузка будет производится нормально. А если диск выпал аварийно, то хрен. Грузиться с rescue и выводить отпавший из массива.

Значит программный Raid для отказоустойчивости не совсем подходит видимо... Аппаратный лучше тогда использовать? Кто-то может посоветовать оптимальный по цене и по качеству контроллер, который полностью совместим под Linux, с системой мониторинга, чтоб в случае сбоев продолжал фунциклировать и грузиться и работать с одним диском при этом уведомлял что произошел сбой..

Ну у вас же диск не с бухты Барахты отвалится и не будет вообще определяться системой.

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

А если вы хотите на ходу сами заменить диск, то в начале руками уделяете его из массива, за если снимаете питание давая ядру соответветствующую команду, за если вынимаете его, вставляете новый, даёте и команду просканирвоать Ата каналы, что бы нашелся новый диск, затем создаете на нем такую же разметку. У вас же raid не просто на дисках, а на разделах рейд аутодетект? И вот потом добавляете его в массив.

А на ходу просто так диски никто не дергать, все делаетеся на рабочей системе.

А если вы по какой то причине выключили сервер, вынули диск, то значит можете руками и удалить диск или добавить новый.

Повторюсь, рейд должен быть собран не просто на дисках, /dev/sdX, а на разделах диска /dev/sdXN с типом рей автодетект.

Ну и вы что сервера перезагружаете каждый день?

Настраиваете себе в mdadm отправку писем на почту о выходе диска из строя, как только получили сообщение приходите, проводите операции по замену диска без остановки системы.

Я пытаюсь сделать отказоустойчивую систему, поэтому моделирую ситуацию по полному сбою диска, это вариант не исключается же..

Автодетек это значит выставленный тип в Fdisk - FD ? В Centos 7 это уже не работает, нету такого параметра в Fdisk. Тип показывает Linux RAID У меня кстати непонятно почему, только для двух развелов показывает такой тип

Команда (m для справки): p

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 3EF136E1-99EA-45E3-BF28-9DCA0F5A82DC


#         Start          End    Size  Type            Name
 1         2048       616447    300M  EFI System      EFI System Partition
 2       616448      2713599      1G  Microsoft basic
 3      2713600   2101329919  1000,7G  Linux RAID
 4   2101329920   3887540223  851,7G  Linux RAID
 5   3887540224   3907028991    9,3G  Linux swap

Для первого и второго тоже создан рэйд, но тип дисков почему-то остался как был до установки рэйда... может потому, что там metdata 0,90 для первых двух... Даже не знаю как проверить это, поскольку в 7-ом Centos нет возможности выставить тип разделу - RAID (для 4-ого и 5-ого разделов этот тип поставился сразу после команды создания массива mdadm --create...)

отказоустойчивости

У тебя странное понимание отказоустойчивости raid. Выключение - это уже «отказ» для raid. Если тебе нужно другое «понимание отказоустойчивости», то тебе не нужен raid.

Отказоустойчивость в моем понимании - это продолжении работы системы в случае подобного отказа одного из дисков...\ Для этого вроде и придумывали RAID изначально...

При отключении _отказали_ все диски. Просто некоторые реализации raid чисто случайно умеют автоматически собирать рабочий массив из отказавших дисков. В твоем случае нужен не raid, а спец загрузчик (который не на raid), который умеет собирать raid из отказавших (выключенных) дисков.

Странная реализация рэйда.... где же найти такой спецзагрузчик? не лучше ли уйти на аппаратный рэйд?

Что у тебя сейчас происходит? Boot и efi «как бы» в рейде. Во время загрузки рейд на них не рабтает, потому что линуксовый софт-рейд, а линукс не загружен, работать нечему. И система грузится с чисто случайного неотказоустойчивого раздела. А когда загружен, смысл нахождения boot и efi в рейде вообще не понятен - от какого отказа защищаешься? Если от «ненадежной» записи, то тебе в наркоманский тред про надежную запись на диск для переписи шаманов с бубнами камлащих над sync, direct и тп.
Чтобы сделать отказоустойчивый дублированный загрузчик, нужен неотказоустойчивый загрузчик такого загрузчика. Успехов.

А можно как-то повнятнее и конкретнее? Вижу что эмоций много в ответе, но суть я сильно понял ))

Я тебе уже все сказал. Рейд задуман, чтобы работать. Выключение - отказ, нужно заново собирать. Если веришь «автоматике», то не требуй от автоматики больше чем она может, а автоматика мало чего может. Поэтому (пере)загрузка - ручная, под личную ответственность. Нахождение в рейд boot, efi и даже root (но не бд) - это очень сомнительная идея. Рейд не защищает от глюков самого рейда (в root у нас линукс с реализацией рейда, вот почему сомнительно). Это утверждение также можно применить к аппаратным рейдам: глюк в аппаратной части рейда - прощай рейд. И вообще все сказанно относится и к аппартным рейдам. Чувствуешь ограничения рейда?

Значит случайное выключение может привести к падению системы, а это не хорошо, ибо может так случиться, что некому будет собирать руками его для запуска хотя бы на одном диске... Изначально я пробовал сделать только для одного раздела с базами рэйд, продублировал загрузочные разделы с /dev/sda[1-2] на /dev/sdb[1-2] , но возникла проблема с fstab, в нем прописываются UUID, а они разные получаются при загрузке с разных дисков ...

случайное выключение может привести к падению системы

Ты не понимаешь самое главное: выключение системы - это уже падение системы. Чтобы вылезти из этого порочного круга нужна другая система над этой системой. Можно поднять две системы и рулить ими третьей системой, можно поднять одноранговую систему из «любящих выключаться» систем.

...вопросов больше чем ответов... как поднятая система будет рулить другой если физически она упадет... нужна система, которая в случае перезагрузки ( пусть это и называется отказ) могла легко заново подняться автоматом без участия рук, не крайняя же ситуация - вылет одного hdd...

Копай глубже, может премию (как там нобелевка у математиков называется) получишь. А то ишь чего захотел - положу-ка рейд в рейд и все само.

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

Неверно. Например появление появление реаллок это ошибка? Да ошибка, но помечать как сбойный и выносить автоматом система не будет. Вообще обычно система не выносит диски автоматом (во всяком случае я с таким не сталкивался), она может перестать его использовать, но не выносить из рэйда.

А если вы по какой то причине выключили сервер, вынули диск, то значит можете руками и удалить диск или добавить новый.

Неправильный вывод. Например хард может умереть при старте, да-да так бывает. Рубанули питание, потом вернули, хард на старте умер, но это не означает что вы находитесь рядом с этой машинкой, и до нее может быть «три дня на оленях».

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

Что за юзкейс? и при чем тут Дебиан, у меня Centos 7, мне нужно с ней подружиться..

Два диска в софтовом рейде, на каждом загрузчик, при вынимание диска система продолжает загружать на деградировавшем рейде. Разве у вас не такая ситуация?

Подтверждаю, смоделировал ситуацию на виртуалке, установлена система на raid1, отдельно /boot и /, на обоих RAID metadata 1.2.

Выключил виртуалку, отключил один диск, система загрузилась без вопросов на одном диске в деградированном RAID.

Так что нужно сравнивать сценарии активации RAID в Initramfs дистрибутивов CentOS и Debian.

Ну либо автор может всё же поставить Debian.

В initramfs Debian есть скрипт /scripts/local-block/mdadm, в котором есть вот такой код:

#!/bin/sh

PREREQ="multipath"

prereqs()
{
        echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac

. /scripts/functions

# Poor man's mdadm-last-resort@.timer
# That kicks in 2/3rds into the ROOTDELAY

if [ ! -f /run/count.mdadm.initrd ]
then
    COUNT=0

    # Unfortunately raid personalities can be registered _after_ block
    # devices have already been added, and their rules processed, try
    # triggering again.  See #830770
    udevadm trigger --action=add -s block || true
    wait_for_udev 10
else
    COUNT=$(cat /run/count.mdadm.initrd)
fi
COUNT=$((COUNT + 1))

echo $COUNT > /run/count.mdadm.initrd

# Run pure assemble command, even though we default to incremental
# assembly it is supported for users to export variables via
# param.conf such as IMSM_NO_PLATFORM.  See #830300
mdadm -q --assemble --scan --no-degraded || true

MAX=30
if [ ${ROOTDELAY:-0} -gt $MAX ]; then
    MAX=$ROOTDELAY
fi
MAX=$((MAX*2/3))

if [ "$COUNT" = "$MAX" ]
then
    # Poor man's mdadm-last-resort@.service for incremental devices
    mdadm -q --run /dev/md?*

    # And last try for all others
    mdadm -q --assemble --scan --run

    rm -f /run/count.mdadm.initrd
fi

exit 0

Строчка:

mdadm -q --assemble --scan --run

Ну и вторая особенность, в Initramfs Debian в качестве init сценария работает sh скрипт, а в CentOS - systemd.

Так что здесь вопрос к разработчикам.

Если в CentOS после того как загрузка вываливается в initramfs shell при деградированном RAID набрать команду:

mdadm --stop /dev/md126 
mdadm --stop /dev/md127
mdadm --assemble --scan --run

exit

/dev/md126 и /dev/md127 могут быть с другими номерами, но если два RAID, то скорее всего будет так.

С другой стороны остановка запуска на деградированном RAID не факт, что и плохо.

А если у вас там RAID совсем развалился?

В общем, пишите разработчикам CentOS, пускай исправляют проблему, либо разбирайтесь сами как поправить Initramfs в CentOS.

Ну либо ставьте Debian, там нужное вам поведение работает из коробки.

Спасибо большое за моделирование и подсказку.. Полегчало, что не у меня одного проявилось этот баг... Уходить на Debian пока не хочется, но как вариант приму к сведению. То что проблема кроется в initramfs я догадывался, но он создается автоматом dracut.. попробую все же как-то решить проблему на Centos и спасибо за подсказку по сборке массивов деградированного RAID.

Рискуешь очередным обновлением похерить свои костыли в initramfs

РЕШЕНИЕ

Обратился за помощью на centos.org Получил подтверждение этой проблемы, вот она https://bugzilla.redhat.com/show_bug.cgi?id=1451660 Проблема не решенная, и посоветовали откатиться на старую версию dracut, а именно:

Скачать пакеты с нужной версией, в которой все работает:

dracut-033-535.el7.x86_64.rpm 
dracut-config-rescue-033-535.el7.x86_64.rpm 
dracut-network-033-535.el7.x86_64.rpm 
kexec-tools-2.0.15-13.el7.x86_64.rpm

...вот отсюда: http://vault.centos.org/7.5.1804/updates/x86_64/Packages/

Downgrade packages, затем выполнить «dracut -f» (rebuild the initrd)

Для всех, у кого эта проблема нарисовалась, вот по шагам лечение:

Используем rpm...

получаем список установленных пакетов 

# rpm -qa | grep «dracut» 
dracut-033-554.el7.x86_64 
dracut-network-033-554.el7.x86_64 
dracut-config-rescue-033-554.el7.x86_64

Удаляем эти пакеты без зависимостей!!!

# rpm -e --nodeps «dracut-config-rescue-033-554.el7.x86_64» 
# rpm -e --nodeps «dracut-network-033-554.el7.x86_64» 
# rpm -e --nodeps «dracut-033-554.el7.x86_64»

Далее скачиваем в нужную директорию пакеты с нужной нам версией 
и из этой директории выполняем установку
 
# rpm -ivh dracut-033-535.el7_5.1.x86_64.rpm 
Preparation... ################################# [100%] 
Update / install... 1:dracut-033-535.el7_5.1 ################################# [100%] 
# rpm -ivh dracut-config-rescue-033-535.el7_5.1.x86_64.rpm 
Preparation... ################################# [100%] 
Update / install... 1:dracut-config-rescue-033-535.el7_################################# [100%] 
# rpm -ivh dracut-network-033-535.el7_5.1.x86_64.rpm 
Preparation... ################################# [100%] 
Update / install... 1:dracut-network-033-535.el7_5.1 ################################# [100%]

Проверяем установленные пакеты, а именно версии

# rpm -qa | grep «dracut» 
dracut-033-535.el7_5.1.x86_64 
dracut-network-033-535.el7_5.1.x86_64 
dracut-config-rescue-033-535.el7_5.1.x86_64

После этого пересоздаем initramfs

#dracut -f

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

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

# mdadm /dev/md124 --add /dev/sda1 
mdadm: hot added /dev/sda1 
# mdadm /dev/md125 --add /dev/sda2 
mdadm: hot added /dev/sda2 
# mdadm /dev/md126 --add /dev/sda3 
mdadm: re-added /dev/sda3 
# mdadm /dev/md127 --add /dev/sda4 
mdadm: re-added /dev/sda4

И ждем завершение синхронизации 

# cat /proc/mdstat

И в дополнение чтобы не схватить обновление этих пакетов

echo "exclude=dracut dracut-config-rescue dracut-network kexec-tools" >>/etc/yum.conf