Назад | Перейти на главную страницу

Физическая система Centos 7.6 RAID5 не загружается после сбоя одного диска

Привет,

Недавно я построил сервер Centos 7.6 с 4 идентичными дисками по 500 ГБ, используя установщик Anaconda с локального DVD Centos 7.6. Настройки BIOS дают мне EFI, а не загрузку BIOS.

Используя "ручное разбиение" в подменю диска, я создал небольшое четырехстороннее зеркало RAID1, содержащее точки монтирования "/ boot" и "/ boot / efi". Насколько я могу судить, это зеркало использует программный RAID через «md» и не использует «lvm». Я создал «/», «/ var», «/ home» и «swap» как точки монтирования LVM в массиве RAID5 максимального размера. По завершении установки я вижу следующую схему дисковода:


$ lsblk
NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                          8:0    0 465.8G  0 disk  
├─sda1                       8:1    0     1G  0 part  
│ └─md127                    9:127  0  1023M  0 raid1 /boot
├─sda2                       8:2    0     1G  0 part  
│ └─md125                    9:125  0     1G  0 raid1 /boot/efi
└─sda3                       8:3    0 463.8G  0 part  
  └─md126                    9:126  0   1.4T  0 raid5 
    ├─centos_reports2-root 253:0    0   100G  0 lvm   /
    ├─centos_reports2-swap 253:1    0  19.9G  0 lvm   [SWAP]
    ├─centos_reports2-var  253:2    0 299.9G  0 lvm   /var
    └─centos_reports2-home 253:3    0  49.9G  0 lvm   /home
sdb                          8:16   0 465.8G  0 disk  
├─sdb1                       8:17   0     1G  0 part  
│ └─md127                    9:127  0  1023M  0 raid1 /boot
├─sdb2                       8:18   0     1G  0 part  
│ └─md125                    9:125  0     1G  0 raid1 /boot/efi
└─sdb3                       8:19   0 463.8G  0 part  
  └─md126                    9:126  0   1.4T  0 raid5 
    ├─centos_reports2-root 253:0    0   100G  0 lvm   /
    ├─centos_reports2-swap 253:1    0  19.9G  0 lvm   [SWAP]
    ├─centos_reports2-var  253:2    0 299.9G  0 lvm   /var
    └─centos_reports2-home 253:3    0  49.9G  0 lvm   /home
sdc                          8:32   0 465.8G  0 disk  
├─sdc1                       8:33   0     1G  0 part  
│ └─md127                    9:127  0  1023M  0 raid1 /boot
├─sdc2                       8:34   0     1G  0 part  
│ └─md125                    9:125  0     1G  0 raid1 /boot/efi
└─sdc3                       8:35   0 463.8G  0 part  
  └─md126                    9:126  0   1.4T  0 raid5 
    ├─centos_reports2-root 253:0    0   100G  0 lvm   /
    ├─centos_reports2-swap 253:1    0  19.9G  0 lvm   [SWAP]
    ├─centos_reports2-var  253:2    0 299.9G  0 lvm   /var
    └─centos_reports2-home 253:3    0  49.9G  0 lvm   /home
sdd                          8:48   0 465.8G  0 disk  
├─sdd1                       8:49   0     1G  0 part  
│ └─md127                    9:127  0  1023M  0 raid1 /boot
├─sdd2                       8:50   0     1G  0 part  
│ └─md125                    9:125  0     1G  0 raid1 /boot/efi
└─sdd3                       8:51   0 463.8G  0 part  
  └─md126                    9:126  0   1.4T  0 raid5 
    ├─centos_reports2-root 253:0    0   100G  0 lvm   /
    ├─centos_reports2-swap 253:1    0  19.9G  0 lvm   [SWAP]
    ├─centos_reports2-var  253:2    0 299.9G  0 lvm   /var
    └─centos_reports2-home 253:3    0  49.9G  0 lvm   /home
$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md125 : active raid1 sdb2[0] sdd2[2] sdc2[1] sda2[3]
      1049536 blocks super 1.0 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md126 : active raid5 sdb3[1] sdc3[2] sdd3[4] sda3[0]
      1458462720 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 2/4 pages [8KB], 65536KB chunk

md127 : active raid1 sdd1[2] sdb1[0] sdc1[1] sda1[3]
      1047552 blocks super 1.2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices:
$

Все четыре диска имеют одинаковые разделы, а именно:


# fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 500.1 GB, 500107862016 bytes, 976773168 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: dos
Disk identifier: 0x000f06c8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *        2048     2101247     1049600   fd  Linux raid autodetect
/dev/sdd2         2101248     4200447     1049600   fd  Linux raid autodetect
/dev/sdd3         4200448   976773119   486286336   fd  Linux raid autodetect

Command (m for help): q

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

Я действительно вижу меню grub, и я вижу попытку загрузки в Centos 7. Я наблюдаю, как разноцветные линии ползут по нижней части консоли. Но затем процесс падает до приглашения аварийной загрузки с ошибками, говорящими о том, что / dev / centos_reports2-root и / dev / centos_reports2-swap не существуют, и предлагает мне сохранить "/run/initramfs/rdsosreport.txt" на USB-накопитель. и отправьте отчет об ошибке. Выход из оболочки приводит к идентичной ошибке. Если я остановлю систему, отключу питание, снова вставлю диск и снова включу питание, то она загрузится нормально.

Я надеюсь, что есть способ заставить это работать так, как должно. Centos 7 должен иметь возможность построить RAID5 и работать с ним в деградированном состоянии, и мне придется заменить вышедший из строя диск.

Теперь, возможно, если бы я вытащил диск sda, я, возможно, даже не зашел так далеко. Я не записывал вручную загрузчик для каждого диска; возможно, если бы я вытащил sda, я бы даже не дошел до попытки загрузки Centos. Мне кажется, что установщик Anaconda должен помещать загрузчик на каждый диск, который является частью метаустройства, содержащего «/» и / или «/ boot / efi», но я не знаю, делает ли он это. (Я почти уверен, что в более ранних версиях этого не было.) В любом случае, это отдельная проблема.

Должен ли я использовать RAID-что-нибудь там, где я использовал RAID5? Я встречал несколько источников, которые рекомендуют RAID10 вместо RAID5. Загрузилась бы моя система, если бы я это сделал? Или я еще что-то делаю не так?

Когда я запускаю "journalctl" в аварийной оболочке, строка, которая терпит неудачу, оказывается почти в конце. Насколько я могу судить, все было нормально до:


. . . . . . . .
sd :1:0:0:0 [sda] Attached SCSI disk
random: fast init done
mgag200 0000 04:03:0: fb0: mgadrmfb frame buffer device
[drm] initialized mgag200 1:0:0 20110418 for 0000:04:03:0: on minor 0
Job dev-mapper-centos_myhost\x2droot.device/start timed out
[TIME] timed out waiting for device dev-mapper-centos_myhost\x2droot.device
Dependency failed ...
Dependency failed ...
. . . . . . . .

Это происходит даже после того, как я внес некоторые изменения и попытался переустановить. Я изменил параметры загрузки прошивки BIOS с «UEFI and Legacy» на «UEFI Only» и переустановил Centos с двумя накопителями, настроенными в зеркале. Разделы / boot и / boot / efi такие же, как и раньше (за исключением двухстороннего, а не четырехстороннего зеркала), а другие разделы снова являются lvm на массиве RAID максимального размера, на этот раз RAID1 из двух диски, а не RAID5 с четырьмя дисками. Эффект от этих изменений был заметен. Anaconda написала GPT, а не ярлыки DOS на двух дисках, и установка по умолчанию включала пакет «efibootmgr». "efibootmgr -v" теперь работает, а не выдает сообщение о том, что переменные EFI не поддерживаются.

Но система по-прежнему не может загрузиться, когда я забираю один из дисков, и снова драйвер md должен иметь возможность запускать зеркальную конфигурацию в ухудшенном состоянии. Возможно, мне нужно добавить параметры конфигурации для программного обеспечения MD? Я постараюсь отправить это как отчет об ошибке, хотя, опять же, приветствуются любые советы.

Это не столько реальное решение моей проблемы, сколько осознание того, что мои ожидания от программного RAID «md + lvm» были, возможно, более чем реалистичными. Возможно, я слишком многого требовал, чтобы ожидать, что "md + lvm" загрузится с жесткого диска внезапно и таинственным образом исчезнет. Когда диск (или раздел диска) в конфигурации RAID действительно становится неисправным во время использования, он со временем генерирует различные ошибки в файлах журнала и т. Д., И программное обеспечение RAID 'md' будет испытывать сбои при попытке использовать этот диск. и / или перегородка.

В конечном итоге программное обеспечение md откажет этот компонент или пометит его как неисправный. Вы можете увидеть это через "cat / proc / mdstat", в этом случае показывая, что компонент / dev / sdb1 зеркала md125 RAID1 неисправен:


[root@host ~]# cat /proc/mdstat
Personalities : [raid1] 
md125 : active raid1 sda1[0] sdb1[1](F)
      1049536 blocks super 1.0 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk
.  .  .  .  .
[root@host ~]#

Используя административную утилиту "mdadm", вы можете смоделировать такой сбой с помощью:

mdadm --manage /dev/md125 --fail /dev/sdb1

(Вот как я произвел вышеприведенный вывод.) Команда:

mdadm --manage /dev/md125 --remove /dev/sdb1
then removes the failed component from the metadevice configuration, and the metadevice runs on the remaining components. When a partition or drive really does fail, then before you can pull the drive it is necessary to 'fail' and 'remove' every partition of that drive from the metadevices of which they are components. After I simulated a drive failure and response by doing all this, I was able to successfully shut down, pull the drive, reboot the unit and it came back up into Centos successfully. All the metadevices (RAID1 mirrors) ran on single sub-mirrors:


[root@reports2 ~]# cat /proc/mdstat
Personalities : [raid1] 
md125 : active raid1 sda1[0]
      1049536 blocks super 1.0 [2/1] [U_]
      bitmap: 1/1 pages [4KB], 65536KB chunk

md126 : active raid1 sda2[0]
      1047552 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md127 : active raid1 sda3[0]
      974529536 blocks super 1.2 [2/1] [U_]
      bitmap: 3/8 pages [12KB], 65536KB chunk

unused devices: 
[root@reports2 ~]#

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


mdadm --manage /dev/md125 --add /dev/sdb1

После этого со всеми зеркалами они повторно синхронизируются. Чем больше зеркало, тем больше времени потребуется:


[root@reports2 ~]# !cat
cat /proc/mdstat
Personalities : [raid1] 
md125 : active raid1 sdb1[1] sda1[0]
      1049536 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md126 : active raid1 sdb2[2] sda2[0]
      1047552 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md127 : active raid1 sdb3[2] sda3[0]
      974529536 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.0% (883968/974529536) finish=91.7min speed=176793K/sec
      bitmap: 3/8 pages [12KB], 65536KB chunk

unused devices: 
[root@reports2 ~]#

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

https://www.howtoforge.com/tutorial/linux-raid-replace-failed-harddisk/

И использовал утилиту "gdisk" для удобного копирования таблицы разделов / dev / sda GPT на / dev / sdb через:


sgdisk -R /dev/sdb /dev/sda
sgdisk -G /dev/sdb

Вышеупомянутая ссылка рекомендует "gdisk" как надежный для меток дисков / таблиц разделов GPT. Первая команда выполняет фактическое копирование (из «/ dev / sda» в «/ dev / sdb», что, возможно, немного противоречит интуиции), а вторая генерирует уникальные UUID для / dev / sdb и его разделов.