Montage RAID 1 sur serveur dédié Rocky 8 - Perte au boot

Bare Metal and VPS
1

Montage RAID 1 sur serveur dédié Rocky 8 - Perte au boot

Utilisant l'outil mdadm comme il se doit pour réaliser sur un serveur dédié (Advance STOR-1 Gen 2) des configs RAID 1 à l'aide de disques de 1TB, je n'arrive pas à persister la config, au boot tout redevient comme avant (même en ayant eu fait un "dracut -f"), je perd patience à force…

La doc technique OVH est trop légère et trop généraliste, aucun sujet ne traite de comment persister une config RAID au boot.

Existe t'il une belle procédure simple et claire qui synthétise les commandes à suivre sur Rocky 8 ?

- Voici un récap (mes notes) de toutes les commandes déjà essayées :
```
sudo mdadm --create /dev/md4 --level=1 --raid-devices=2 /dev/sda /dev/sdb
cat /proc/mdstat

## Infos sur le volume
sudo mdadm --detail /dev/md4
or
sudo mdadm -D /dev/md4

sudo blkid

sudo mkfs.ext4 /dev/md4 (once)

sudo mkdir /storage0
sudo mount /dev/md4 /storage0

sudo vim /etc/mdadm.conf
ARRAY /dev/md/md4 metadata=1.2 UUID=c314e00c:8957151a:8b7fb2ad:e4ec798b name=md4

sudo dracut --regenerate-all --force
sudo dracut -f /boot/initramfs-currentimage # For Rocky, same as 'sudo update-initramfs -u' for RedHat

#sudo mdadm --assemble --scan

------------------
See: https://www.linuxpedia.fr/doku.php/expert/mdadm
https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/5/html/installation_guide/s1-s390info-raid

sudo mdadm --create /dev/md4 --level=1 --raid-devices=2 /dev/sda /dev/sdb
sudo mdadm --query /dev/md4
sudo mdadm --detail /dev/md4

sudo mdadm --examine /dev/sda # Superblock infos on a physical disk (a good way to check if the disk is RAID config or not)
sudo mdadm --zero-superblock /dev/sda # Erase the superblock of a physical disk

sudo mdadm --assemble --scan
sudo mdadm --assemble --force --scan
sudo mdadm --assemble /dev/md4 /dev/sda /dev/sdb
sudo mount /dev/md4 /storage0

sudo umount /storage0
sudo mdadm --stop /dev/md4

sudo dracut -f /boot/initramfs-4.18.0-372.9.1.el8.x86_64.img $(uname -r)

sudo lsinitrd # Contents of current initramfs
```

2

Bonjour @AdminDataServer,

Avez-vous réussi à résoudre votre dysfonctionnement? Si c'est le cas, n'hésitez pas à le partager avec la communauté.

Dans le cas contraire, auriez-vous davantage d'informations à communiquer à la communauté?

^FabL

3

Bonjour,

Non toujours pas, mais par contre nous avons trouvé la cause qui provient bien des templates OVH, j'explique :

Comme on le sait la commande 'mdadm --create' créé des superblocks RAID sur les disques que l'on veut monter ensuite en RAID, et ces superblocks persistent naturellement sur les disques au-délà d'un reboot.

Or, les superblocks sont systématiquement effacés à chaque reboot par les templates OVH que nous avons testé (Rocky 8, Centos 8 et Ubuntu 20.04 LTS), d'où la raison pour laquelle le service mdadm n'arrive plus après un boot à faire un seul –assemble puiqu'il n'existe plus aucun superblock sur les disques RAID…

Sachant que les templates OVH ne sont pas prêt d'évoluer dans l'immédiat, nous allons réaliser de notre côté un service maison qui se chargera après chaque reboot de reconstruire intégralement les montages RAID (en forçant la commande 'mdadm --create')…

Exemple d'un create forcé :
```
sudo mdadm --create /dev/md4 --level=1 --raid-devices=2 /dev/sda /dev/sdb <<< 'y'
```