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é ?
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)
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.
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.
Ces messages étaient en rapport avec ma configuration, ils sont donc plus pertinent sur mon sujet, comme ça ne concernait pas la demande initiale et que ça prenait beaucoup de place, j’ai déplacé vos messages.
en RAID on met toujours des disques identiques, la pratique montre que mettre des disques différents n’est as une bonne idée et surtout certains système de gestion RAID 5 n’accepte pas (mon NAS par exemple refuse des disques de taille différentes).
sauf qu’on utilise pas le RAID 5 pour ses performances.
ta grappe oui, mais sinoon tes disques sont mirrorés un à un.
sur deux noeud de 5 disques, c’est N1-1 sur N2-1, N1-2 sur N2-2, etc…
ta réponse laisse croire qu’on pourrais avoir des ecritures sr des disques différents dans les grappes du moment que c’est sur chaque noeud.
Rien que par fainéantise utilisez un seul et même raid c’est plus simple
Ce qui n’est pas le cas chez moi et sur énormément de NAS du marché pro ou pas.
En séquentiel, les performances sont plus que honorable.
Tu aurais une source de ce que tu avance, car j’en suis pas sûr du tout, pour moi le comportement serait surtout d’avoir une parité présente de chaque côté, et ce peux importe le disque utilisé.
De mon côté, je ne vois pas l’intérêt de monter deux RAID différents. Si l’intérêt est de gagner un peu en performance, le jeu n’en veux largement pas la chandelle, ou comme le dit si bien @Clochette :
Et puis, faire deux RAID, ça veut dire graver la taille de ma partition pour le système dans le marbre, et donc, impossible (à moins d’une acrobatie qui ne me dérange pas mais que j’aime bien éviter quand elle n’est indispensable) de mettre plus de truc dans le système ou d’ajouter un espace pour une mise à jour.
Parce que, oui, j’ai installé cette machine en Debian 10 en juillet 2019, mais j’ai l’intention de passer à une version ultérieure et il est hors de question pour moi de faire une mise à jour en place ou d’installer la nouvelle version par dessus l’ancienne directement en mode YOLO.
Dans ce cas ta remarque précédente selon laquelle le stockage disponible dépend du disque le plus petit était sans objet. Ton discours est incohérent.
On se fiche des limitations arbitraires de tel ou tel appareil. Ici il est question du RAID logiciel de Linux, qui accepte des disques de taille quelconque.
Qu’est-ce que c’est que ce charabia incompréhensible ? Tu n’as toujours pas expliqué ce qu’est un noeud pour toi dans ce contexte.
N’importe quel contrôleur hôte SATA sur bus PCI fait les transferts en DMA sans intervention du logiciel qui ne fait que lancer les commandes. Le PIO, c’est fini depuis longtemps.
