Debian RAID1 Soft: Question

Support Debian
Tags: #<Tag:0x00007fb417cf4900>
#1

Salut à tous,

J’ai une question concernant un serveur dédié chez OVH:
J’ai un de mes disques /dev/sdb qui est tombé en panne.
Il me l’ont remplacé et j’ai recréé mes partitions et reconstruit mon RAID 1 sans problème:
Pour ceux que ca intéresse:
sgdisk -R=/dev/sdb /dev/sda
sgdisk -G /dev/sdb

mdadm --manage /dev/md3 --add /dev/sdb3
mdadm --manage /dev/md2 --add /dev/sdb2

Mais mon interrogation est la suivante:
Si /dev/sda tombe en panne, mon serveur va-t-il redémarrer ?
Ma partition root / étant /dev/md2
et j’ai une partition EFI system sur chacun des disques.
Device Start End Sectors Size Type
/dev/sda1 2048 1048575 1046528 511M EFI System
/dev/sda2 1048576 42006527 40957952 19,5G Linux RAID
/dev/sda3 42006528 3905970175 3863963648 1,8T Linux RAID
/dev/sda4 3905970176 3907016703 1046528 511M Linux swap

Device          Start        End    Sectors  Size Type
/dev/sdb1        2048    1048575    1046528  511M EFI System
/dev/sdb2     1048576   42006527   40957952 19,5G Linux RAID
/dev/sdb3    42006528 3905970175 3863963648  1,8T Linux RAID
/dev/sdb4  3905970176 3907016703    1046528  511M Linux swap

Est -ce qu’il faut faire un installation de grub2 sur /dev/Sdb ? et à quoi sert la partition EFI ?

Merci pour vos réponses

#2

La partition EFI sert à l’amorçage en mode (U)EFI. C’est en quelque sorte une version très améliorée du secteur d’amorce (MBR). Elle est normalement montée sur /boot/efi pour que GRUB l’utilise. Elle est utilisée en conjonction avec les variables de boot EFI qui sont stockées dans la mémoire non volatile de la carte mère et peuvent être affichées ou modifiées avec la commande efibootmgr.

Ça dépend de beaucoup de choses, notamment

  • du contenu de /etc/fstab
  • du contenu de la partition EFI du nouveau disque
  • des variables de boot EFI

Notes :

  • Le nommage des disques n’est pas stable et peut changer à chaque démarrage, ne pas se fier à sda et sdb
  • Le swap dans sdb4 est activé donc si sdb est le nouveau disque, ça implique que tu n’as pas seulement recréé la table de partition et resynchronisé les ensembles RAID mais aussi formaté la partition de swap et fait en sorte qu’elle soit activée.
  • Ne pas mettre le swap en RAID est risqué, car il est à la merci d’un panne de disque qui peut faire planter des applications voire tout le système.
  • J’aurais créé un seul ensemble RAID utilisé par LVM et des volumes logiques pour tout sauf les partitions EFI (racine, données, swap), c’est plus simple à gérer.
#3

En fait tu peux créer un raid 1 pour la partie LVM et un autre pour la partie /boot (incluant EFI).
Il y a une astuce pour la partie /boot il me semble pour qu’elle puisse être prise en charge quelque soit le disque en panne.
Mais tu ne peux pas le faire à l’installation, mais après.
C’est comme ca que j’ai un de mes serveurs.

il faudrait que je retrouve ce que j’ai fait à l’époque.

#4

Pas besoin de RAID séparé pour /boot. Par contre les partitions EFI doivent être à part et ne peuvent être combinées avec /boot. Et oui, il y a une astuce pour les mettre en RAID 1 (metadata=1.0) et ainsi éviter de les synchroniser à la main mais c’est du bricolage, la mise à jour des variables de boot EFI lors de l’installation de GRUB ne fonctionne pas dans cette configuration.

A noter que le GRUB d’Ubuntu semble supporter nativement plusieurs partitions EFI indépendantes, j’aimerais bien avoir ça dans Debian.

#5

Bonjour,

Cette question est à rapprocher d’un sujet que j’ai ouvert de mon côté.

Moi, c’est sur trois disques avec un RAID5, mais l’idée est la même, je voulais que la partiton EFI soit la même sur les trois disques.

#6

6 messages ont été fusionnés à un sujet existant : Grappe redondante non formelle pour partition EFI sur plusieurs disques

#7

Hello,

Pour ma part j’ai testé un raid1 soft sur 2 disques mais n’ai pas pu raider la /boot et la /efi. J’ai quand même créé les partitions sur mon 2e disque, j’ai copié manuellement /efi du disque 1 vers le 2 et ai fait une restauration de grub sur le disque 2 aussi.

C’est à peu près ça de mémoire car ça date de 2019 le truc, j’ai simulé un fail du disque 1 et j’ai pu booter sur le 2. J’ai ensuite remis le 1 fonctionnel. Depuis les disques sont toujours vivants, je peux pas prédire ce qu’il se passera quand l’un des 2 mourra.

#8

Il n’y a aucun souci à mettre /boot en RAID logiciel puisque GRUB sait le lire. La partition EFI en revanche, c’est plus délicat car le firmware UEFI doit être capable de la lire.

#9

Tu as certainement raison mais sous Buster j’y suis pas arrivé en installation standard.
Pour la EFI ben j’ai booté en live sous SystemRescue et j’ai juste recopié manuellement les données de la EFI du disque 1 vers le 2. Ensuite dans l’uefi j’ai dû faire un clone manuel de l’entrée sur le disque 1, avec l’uuid du disque 2 de mémoire, le reste j’ai recopié à l’identique et ça a fonctionné.

1 J'aime
#10

Je confirme mon serveur ELk fonctionne de la même façon.
j’ai simplement créé un premier node RAID sur un disque sans lui donner le second noeud.
Quand j’ai créé le second et que je l’ai rattaché à la grappe RAID,le second disque a récupéré toute l’installation.
ne restait plus que le GRUB a mettre à jour.

#11

Donc, c’est bien ce que je pensais, il faut de manière préventive après le changement de /dev/sdb faire une copie de /dev/sda1 vers /dev/sdb1 pour le démarrage EFI.
Mais comment cloner cette partition ?
Pour ce qui est du LVM, j’ai récupérer le serveur tel quel, faire le changement maintenant est impossible.

#12

En fait une fois monté les RAID. Les recopies se font automatiquement des que le noeud est activé.
C’est à dire que ta partition /boot/efi est elle même sur un RAID dédié

par exemple sur mon serveur:

# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.0
     Creation Time : Sun Sep 26 12:49:01 2021
        Raid Level : raid1
        Array Size : 291776 (284.94 MiB 298.78 MB)
     Used Dev Size : 291776 (284.94 MiB 298.78 MB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

           Update Time : Mon Oct  3 01:06:39 2022
                 State : clean
        Active Devices : 2
       Working Devices : 2
        Failed Devices : 0
         Spare Devices : 0

    Consistency Policy : resync

                  Name : dsrvbull01:0  (local to host dsrvbull01)
                  UUID : 6929b19e:ecf5a4d3:ee47f87d:2e646024
                Events : 132

        Number   Major   Minor   RaidDevice State
           0       8        1        0      active sync   /dev/sda1
           1     259        1        1      active sync   /dev/nvme0n1p1

    # mdadm --detail /dev/md1
    /dev/md1:
               Version : 1.2
         Creation Time : Fri Sep 24 14:39:15 2021
            Raid Level : raid1
            Array Size : 976336896 (931.11 GiB 999.77 GB)
         Used Dev Size : 976336896 (931.11 GiB 999.77 GB)
          Raid Devices : 2
         Total Devices : 2
           Persistence : Superblock is persistent

         Intent Bitmap : Internal

           Update Time : Sat Oct  8 14:45:10 2022
                 State : clean
        Active Devices : 2
       Working Devices : 2
        Failed Devices : 0
         Spare Devices : 0

    Consistency Policy : bitmap

                  Name : dsrvbull01:1  (local to host dsrvbull01)
                  UUID : 2236484b:4675a0a8:8dae070f:b4025705
                Events : 19063

        Number   Major   Minor   RaidDevice State
           2       8        2        0      active sync   /dev/sda2
           1     259        2        1      active sync   /dev/nvme0n1p2

Pour créer les RAID, j’ai utilisé le fait de pouvoir créer un RAID avec un membre manquant:
Pour le /boot/efi

mdadm --create /dev/md0 --level=1 --raid-devices=2  /dev/sda1 missing --metadata=1.0

Et pour le reste:

mdadm --create /dev/md1 --level=1 --raid-devices=2  /dev/nvmen1p2 missing

le deuxième disque n’est aps activé.
L’installation se fait entièrement sur le noeud 0, de façon normale.
Une fois l’installation terminée, l’activation du deuxième membre de chaque raid provoquera la synchronisation des disques.

il n’y a que la partie démarrage où je ne sais plus ce que j’ai fait mais il me semble que la réinstallation du grub fonctionne directement.

#13

Je ne pense pas puisque:

        md3 : active raid1 sdb3[1] sda3[0]
              1931981760 blocks [2/2] [UU]
              bitmap: 12/15 pages [48KB], 65536KB chunk
        md2 : active raid1 sdb2[1] sda2[0]
              20478912 blocks [2/2] [UU]

et

 Device          Start        End    Sectors  Size Type
/dev/sda1        2048    1048575    1046528  511M EFI System
 Device          Start        End    Sectors  Size Type
/dev/sdb1        2048    1048575    1046528  511M EFI System

On voit bien que ni sda1 ni sdb1 sont sur une partition RAID

#14

Un début de solution trouvé dans un rapport de beug un peu ancien :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925591

Il y a bien l’astuce de définir metadata à 1.0, il y avait un souci avec la commande grub-install à l’époque où je m’y suis penché et le second problème est lorsque UEFI lui même modifie une des partitions je ne suis pas sûr que le raid au démarrage va pouvoir gérer le coup.

D’après moi il vaut mieux faire les modifications à la main ou via un script mais éviter pour l’instant encore le montage en raid de la partition EFI .

Autre manière de faire qui doit toujours fonctionner : https://paulgorman.org/technical/linux-software-raid-with-uefi-boot.txt

#15

Actuellement, j’en suis à 5 ou 6 modification du kernel avec un système avec un RAID 1 sur /boot/efi et un RAID 1 sur le reste entre un disque nvme et un disque SSD de même capacité.
le système etait une Buster 10.x au départ et a été upgradé jusqu’à bullseye 11.5 actuelle.

#16

Pas seulement après le changement d’un disque mais plus globalement lors de toute modification du contenu de la partition EFI.
Comment synchroniser les partitions EFI pour la redondance de l’amorçage, c’est la question à 1000 balles…
Il y a plusieurs méthodes possibles, avec leurs avantages et inconvénients.

@Zargos a utilisé des partitions en RAID1 (miroir) logiciel avec superbloc RAID à la fin des partitions (metadata=1.0).
Avantage : réplication instantanée du contenu des partitions EFI ; resynchronisation après remplacement triviale ; on n’a pas de question à se poser sur quelle partition à monter sur /boot/efi, on monte l’ensemble RAID.
Inconvénient : la mise à jour des variables de boot EFI grub-install ne supporte pas le RAID logiciel, il faut donc le faire à la main avec efibootmgr ou installer GRUB dans le « chemin de support amovible » qui n’en a pas besoin ; il a aussi été évoqué que le firmware UEFI était susceptible d’écrire dans une partition EFI, ce qui rendrait le miroir incohérent, mais je ne l’ai jamais observé.
On peut voir dans le rapport de bug pointé par @Clochette une demande pour que GRUB supporte cette configuration mais malgré sa simplicité et son élégance à mon avis cette méthode ne sera jamais supportée officiellement car elle n’est pas propre.

D’après une discussion vue dans un autre forum, Ubuntu semble être capable d’installer GRUB dans plusieurs partition EFI. Pour cela son paquet grub-efi- a un paramètre debconf qui contient les partitions de boot, à l’instar du paquet grub-pc mais donc la version de Debian est dépourvue. Je n 'ai pas plus de détails, n’utilisant pas Ubuntu, mais à mon avis ce serait la meilleure approche.

A défaut, on peut utiliser des partitions EFI indépendantes et les synchroniser manuellement. Pour les synchroniser, plusieurs méthodes possibles.
Le clonage bit à bit avec dd a un effet de bord intéressant : il attribue le même UUID de système de fichiers, donc n’importe laquelle des partitions EFI existante sera montée au démarrage. Mais avoir des UUID dupliqués n’est pas très propre. Et le clonage d’un système de fichiers ne devrait se faire que lorsqu’il est démonté.
On peut aussi copier ou synchroniser le contenu du système de fichiers avec rsync ou autre. Mais si les deux partitions ont des UUID différents, alors que faut-il mettre dans /etc/fstab concernant /boot/efi ? Si on met l’UUID de l’une et que son disque tombe en panne, le démarrage finira en erreur à cause de l’échec du montage à moins de mettre l’option « nofail ».
Dans les deux cas, si les partitions ont des UUID de partition (PARTUUID) différents, alors une entrée de boot EFI créée pour une ne fonctionnera pas avec l’autre. Ce n’est pas un problème si GRUB est dans le chemin de support amovible.

#17

Est ce qu’utiliser le même label pour le montage fonctionne ?

#18

C’est comme avec l’UUID. Si un LABEL spécifié dans /etc/fstab est affecté à plusieurs systèmes de fichiers, alors n’importe lequel de ceux-ci pourra être monté. Mais c’est aussi sale que les UUID dupliqués.

1 J'aime