Le RAID 1 peut utiliser un nombre quelconque de membres, pas seulement deux.
Le RAID 5 mentionné ne concerne pas les partitions EFI mais seulement le reste du système.
(J’ai complété ma réponse précédente)
Désolé, vu l’heure tardive et les bieres, je ne suis pas complètement d’accord avec tes modifs.
il faut que je retrouve les infos que j’avais utilisé.
mais javais bien deux RAID 1:
- la partition de boot
- le reste
- le grub
faut que je retrouve.
sinon coté faire du RAID avec plus de deux stockages (disk / partition), c’est rédhibitoire pour les performances et en plus, le RAID c’est Deux. au delà c’est sinon inutile, assurément une usine à gaz;
d’autant que le RAID c’est du mirroring, donc à moins d’aller dans les mathématiques des dimensions, le mirroring par définition c’est deux.
sinon tu n’est plus en raid 1 mais en raid 10
(raid 1+0, le raide 01 ou 0+1 est à évité la perte d’un noeud raid 0 compromet le reste) . et donc toujours pair. mais coté rentabilité c’est pas terrible, en gros il faut 4 fois la capacité nécessaire. Pour 1 disque utile, 3 ne sont pas utilisés.
le mieux c’est le RAID 6 (pour des données, car coté système le RAID 1 suffit largement. car un système est simple à refaire, ce qui n’est pas le cas des données.
Le RAID 5 permet 1 disque en panne, le RAID 6 permet 2disques en panne.
En fait le RAID 6 est pratique pour ceux qui ne s’embarrasse pas d’une supervision efficace, et qui dispose d’un disque de spare, ce qui leur permet de remplacer le disque defaillant avant qu’un autre ne le soit.
Bien évidement, le RAID n’est pas là pour se passer de sauvegardes
le RAID 5 sert poru les données le RAID 1 pour le système. C’est mieux en terme de ratio performances/tolerance de pannes
Pas du tout, j’ai juste trois partitions qui doivent être identiques, mais qui ne le sont pas automatiquement. Je voulais automatiser leur réplication à l’instar de ce fait le RAID1, mais sans faire un RAID1 car je ne maîtrise pas le boot EFI et que je ne peux pas tout casser.
┌ (almtesh@Worm + 0) (07/05/22 - 7:46:03) (0.18 - 0%) (~)
└% efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003,0004,0001,0002
Boot0000* debian HD(1,GPT,c11d79b1-4558-47ba-9bef-265321fb250c,0x800,0x20000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001 UEFI: PXE IP4 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(7085c2d121dd,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002 UEFI: PXE IP6 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(7085c2d121dd,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0003* debian HD(1,GPT,c11d79b1-4558-47ba-9bef-265321fb250c,0x800,0x20000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot0004* debian HD(1,GPT,51885f61-c747-5045-8b7c-7f7c68889801,0x800,0x20000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
┌ (almtesh@Worm + 0) (07/05/22 - 7:46:31) (0.11 - 0%) (~)
└%
Ouais, c’est pas faux !
Effectivement, c’est une très bonne idée, malheureusement, la carte mère ne gère pas le démarrage BIOS. D’ailleurs, je ne le savais pas quand je l’ai achetée, du coup, j’ai dû réinstaller le système de la machine qui était avant à ce poste et qui avait un démarrage en BIOS.
Actuellement, je lance de temps en temps la commande suivante :
sudo umount /boot/efi ; for i in b c;do sudo dd if=/dev/sda1 of=/dev/sd$i1 bs=16M; done; sudo mount /boot/efi
Éventuellement, ce que je peux faire, c’est de programmer ça dans cron cette partition est montée avec la ligne suivante dans /etc/fstab :
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/sda1 /boot/efi vfat umask=0077 0 1
Mais bon, avant de faire ça, j’aimerais quand même savoir s’il n’existe pas un moyen de faire ça à la façon du RAID1.
Comme les partitions sont répliquées avec dd, j’ai innocemment pensé qu’elle avait le même PARTUUID, mais pas du tout :
/dev/sda1: UUID="7CFA-377F" TYPE="vfat" PARTUUID="c11d79b1-4558-47ba-9bef-265321fb250c"
/dev/sdc1: UUID="7CFA-377F" TYPE="vfat" PARTUUID="51885f61-c747-5045-8b7c-7f7c68889801"
/dev/sdb1: UUID="7CFD-0229" TYPE="vfat" PARTUUID="c8f9ceb4-32d4-485b-839b-398271f04982"
D’après la sortie de efibootmgr ton firmware UEFI fait partie de ceux qui supportent plusleurs variables de boot EFI avec le même nom. Cela peut simplifier la configuration si on tient à utiliser les variables de boot EFI. Mais je maintiens que l’utilisation du chemin de support amovible sans variable de boot EFI est plus simple et plus fiable.
Cette commande est défectueuse car sd$i1 est substitué en « sd », $i1 étant interprété comme une variable (non existante donc vide) et non la variable $i suivie de 1. La commande va donc créer un fichier /dev/sd contenant l’image de la partition /dev/sda1. Il faut mettre quelque chose comme ${i}1, $i'1' ou "$i"1 pour isoler la variable. On peut voir dans la sortie de blkid que /dev/sdb1 n’a pas le même UUID que /dev/sda1.
J’allais aussi argumenter que l’utilisation de noms de périphériques /dev/sd* n’est pas fiable car ces noms ne sont pas persistants et peuvent changer d’un démarrage à l’autre selon l’ordre de détection des disques, c’est pourquoi on utilise plutôt des UUID dans /etc/fstab. Mais tu as aussi utilisé /dev/sda1 dans /etc/fstab, donc ta commande est sûre de copier la partition montée sur /boot/efi sur les deux autres. Par contre ce n’est fiable que s’il n’y pas d’autre disque que ces trois.
A ce propos dans ma première réponse j’ai oublié d’évoquer le montage de la partition EFI au démarrage avec un disque défaillant. Si le montage échoue parce que la partition spécifiée n’existe plus, le démarrage s’interrompt et passe en mode dépannage. Avec des partitions EFI en RAID1 , l’ensemble RAID /dev/mdX pourra être assemblé et monté du moment que n’importe lequel des trois disques est opérationnel. En revanche avec des partitions EFI indépendantes, c’est un peu plus délicat. Pour pouvoir monter n’importe laquelle des partitions EFI, on peut utiliser le nom de périphérique /dev/sda1 comme tu l’as fait car sda existe toujours, à condition qu’il soit opérationnel. Sinon si on utilise un UUID ou LABEL, il faut que toutes les partitions EFI aient le même.
Le PARTUUID est contenu dans la table de partition et modifiable avec les outils de partitionnement comme fdisk ou gdisk, pas dans la partition elle-même contrairement à l’UUID.
Pour en revenir à la synchronisation des partitions EFI indépendantes, il n’est pas nécessaire de le faire périodiquement mais seulement après l’exécution de grub-install. Cette exécution se produit après la mise à jour des paquets grub* et shim*. Il doit y avoir moyen d’automatiser ça avec dpkg.
Ah oui, effectivement, je viens de relancer la commande en suivant ton conseil, les UUID sont identiques, mais pas les PARTUUID.
Effectivement, j’ai prévu de mettre un quatrième disque qui serait un disque de spare, mais pour le RAID5, il aurait aussi sa petite copie de la partition EFI comme les autres.
C’est bien ce qu’il me semblait.
Oui, en effet, je pense que je vais l’ajouter à mon processus de mises à jour des logiciels.
J’ai un système de gestion en masse, avec toutes les machines et les conteneurs que j’ai, ça me fait gagner du temps.
J’utilise en général des LABEL, on peut générer de l’homonymie, mais si ça déconne, je ne pourrai m’en prendre qu’à moi-même.
C’est surtout parce que mes partitions ont un contenu qui a une fonction précise, du coup, il arrive assez souvent que je remplace un contenu par un autre sur une fonction en modifiant les LABEL.
C’est moins acrobatique que ça en a l’air.
Ce n’est pas un souci s’il contient aussi une copie de la partition EFI.
Mais si tu veux mon avis, ma solution préférée est de mettre les partitions EFI dans un ensemble RAID1 au format 1.0 monté sur /boot/efi et de reconfigurer le paquet grub-efi-amd64 pour installer GRUB dans le chemin de support amovible et ne pas mettre à jour la NVRAM UEFI. Ce n’est pas très orhodoxe mais c’est simple et fiable puisqu’on ne s’embête plus avec la synchronisation des partitions EFI ni la gestion des variables de boot EFI qui est le point faible de l’amorçage UEFI.
Pardon, je n’ai pas percuté la première fois, mais c’est la deuxième fois que tu parles de mettre GRUB sur un support amovible, mais je ne veux pas mettre GRUB sur un support amovible, moi, je le veux en trois exemplaires identiques sur les trois disques bien durs.
Soit j’ai bien compris et je passe à la copie, soit je n’ai pas compris et je pense que quelques explications seront plus que nécessaires.
Non, je parle de mettre GRUB dans le « chemin de support amovible » /EFI/BOOT/BOOTX64.EFI de la partition EFI, qui ne nécessite pas de variable de boot EFI. Cf. les options --removable et --force-extra-removable de grub-install.
Ah, je dois t’avouer que je m’attendais à quelque chose de clair dans le manuel.
Je pense que, pour le moment, je vais rester sur mon petit bout de code qui réplique manuellement la partition à la mise à jour de GRUB, si j’ai le temps et le courage de me former sur le sujet, je m’en occuperai.
Pour l’instant, la machine démarre en EFI, et le boot est répliqué, ça fera l’affaire pour le moment.
Merci aux personnes qui ont apporté une réponse.
Juste une question, quel est l’objectif d’avoir la partition en triple?
En raid 1 'avais fait ça, qui marche très bien, la machine tourne en RAID 1 avec un NVME et un SSD, avec EFI:
Les pages de manuel de GRUB sont succintes et ne décrivent que la syntaxe des commandes et options. Pour la signification de « removable media path », il faut se référer aux spécifications de l’UEFI.
Ok. Deux remarques concernant les trois variables de boot « debian » :
- Deux pointent vers grubx64.efi donc ne fonctionnent pas si le secure boot est activé. Pour le secure boot il faut pointer vers shimx64.efi.
- Deux pointent vers la même partition EFI, donc une des trois partition EFI n’est référencée par aucune variable de boot.
Fort heureusement, le secure boot n’est pas activé sur cette carte mère. Quand même, j’ai dû me cogner l’EFI, j’allais pas avoir le secure boot en sus.
Par contre, ta remarque est pertinante concernant les trois entrées de démarrage qu’on voit ici :
la ligne « Boot0004 » est toujours différente de « Boot0000 » et « Boot0003 », est-ce qu’on peut démarrer sur shimx64.efi qui le secure boot n’est pas activé ?
Dans la configuration actuelle elle ne l’est pas vraiment puisqu’il faut au moins deux disques pour démarrer le RAID5, donc il y aura forcément un autre disque dont la partition EFI est référencée dans les variables de boot EFI.
Et c’est bien, puisqu’elle référence une partition EFI différente. Ce qui ne va pas, c’est que Boot0003 référence la même partition EFI que Boot0000 au lieu de la troisième partition EFI n’est pas référencée.
Bien sûr. Comment crois-tu que le système a démarré ?
Bonjour,
Alors non RAID 5 ce n’est pas ca. Pas besoin d’avoir /boot/efi sur chaque disque car en RAID5 c’est comme si tu n’avais qu’un seul disque.
RAID 5
La configuration RAID 5, par un système de parité, répartit une petite partie des données sur chaque disque.
Dans cette configuration, ce n’est pas la performance qu’on recherche mais plutôt la sécurité tout en économisant le volume de stockage.
Soit une donnée A, une donnée B et une donnée C :
• Volumétrie utile = Nombre de disques - 1 X capacité d’un disque
Pour 3 disques de 200 Go, on aurait ainsi 3 -1 X 200 = 400 Go de volumétrie utile.
• Sécurité des données : CORRECTE
Dans cette configuration, on ne peut se permettre de perdre qu’un seul disque.
• Nombre de disques nécessaires : Au moins 3
Donc non il n’y a toujours qu’une seule version d’un fichier accessible. quand un disque est perdu il faut le remplacer et avec les parité celui-ci est reconstruit.
Seulement en RAID matériel. En RAID logiciel, les disques sont vus individuellement par le firmware UEFI qui ne connaît rien au RAID5 de Linux donc il faut une partition EFI sur chacun pour la redondance de l’amorçage.
dans un système normal, tu as un disque système (souvent en RAID 1) et ensuite une grappe RAID5 pour les datas.
C’est tout aussi valable en logiciel.
On utilise pas habituellement du RAID5 pour un système, mais pour des données.
le RAID5 vu du système n’est qu’un seule et même disque (on devrait même quasiment parler de LUN);
les données sont réparti sur l’ensemble.
Toi tu parles de RAID 1 (minimum deux partition/disques ou plus, les performances diminuant avec le nombre)
le RAID 5 est resilient, le raid 1 est redondant
La partition EFI n’est pas pour le système mais pour le firmware UEFI qui ne voit pas le RAID logiciel.
Pour la partition EFI seulement. Celle-ci peut être en RAID pour le système (afin d’être répliquée) mais doit être vue comme une partition normale par le firmware UEFI. Seul le RAID1 avec metadata=1.0 remplit ces deux conditions.
Pour le reste, chacun fait comme il veut chez soi.
Source ? Au contraire les performances en lecture aléatoire augmentent et les performances en écriture restent constantes.
Quelle différence ?
ca ne change rien à ce qu’est un RAID 5
les performances d’un RAID 1 sont celle du disque le plus faible. et le stockage disponible est celui du disque le plus petit; donc au mieux 50% du volume de stockage utilisé.
les performances sont aussi dependantes de la carte RAID, dans le cas d’un RAID logiciel,les performances sont plus faible du faible de la non simultanéité de l’écriture. Les performances sont par contre meilleures qu’un RAID 5. Si l’un des deux disques tombe l’autre continue.
pour le RAID 5 le volume disponible est de 66% du volume total de disque à minima. Du fait du système de répartition des données et du calcul de parité il est moins performant que le RAID 1.Au dela de 3 disque, la perte d’un ou plusieurs disques peuvent être supporté car il reconstruira les donnée, cependant, avec une perte de performance sensible.
ici la résilience c’est la capacité à surmonter la panne/defaut sans avoir de redondance (justement), la redondance c’est le fait que c’est doublé, tu as deux fois la donnée.
bien évidement tu peux avoir plusieurs disques dans chaque noeud RAID 1. caque disque d’un noeud étant en miroir sur un disque de l’autre noeud.
le RAID 1 c’est du miroir, le RAID 5 c’est de la répartition avec un calcul de parité comme pour le RAID 0. Avec 3 disques, chaque donnée est répartie dur deux disque (mais pas redondée) et les bits de parité sont écris sur le troisième disque.
Bien évidement ce ne sont pas toujours les mêmes disque qui font la donnée et la parité.
En logiciel, plus il y a de disque plus les temps d’écriture augmentent, vu qu’il faut tout écrire deux fois; je différenciait ici la partie logicielle vis à vis de la partie matérielle.
Personne ici n’a prétendu le contraire. Où tu veux en venir ?
Idem en RAID5.
Idem en RAID5.
Le RAID5 peut être N-1 fois plus rapide en lecture et écriture séquentielle que le RAID1.
Le RAID1 peut utiliser un nombre quelconque de disques N>1, pas seulement 2.
Pas en accès séquentiel.
Le RAID5 ne supporte la perte que d’un seul disque. Au delà, il faut du RAID6.
Tu joues sur les mots. Ce sont seulement deux façons différentes de faire la même chose. En RAID5 les données sont doublées d’une certaine façon (grâce à la parité) puisqu’on peut reconstituer le contenu de n’importe que disque à partir des autres. La parité, c’est de la redondance.
Qu’appelles-tu un noeud RAID1 ?
Il n’y a pas de parité en RAID0, donc pas de redondance.
Les écritures sur chaque disque peuvent se faire en parallèle, et avec un contrôleur qui fonctionne en DMA c’est transparent pour le processeur.