Boot et RAID5

Le 05/12/17 à 20:36, Pascal Hambourg <pascal@plouf.fr.eu.org> a é crit :
PH> Le 05/12/2017 à 11:09, Daniel Caillibaud a écrit :
PH> > Le 05/12/17 à 00:23, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
PH> > PH> (1,5 fois plus, la belle affaire),
PH> >
PH> > Je penses que c'est bien ×3 si tu donnes au noyau 3 partitions d e swap sur 3 disques
PH> > différents, en tout cas avec 2 disques j'avais effectivement mes uré du ×2 en lecture et
PH> > écriture.
PH>
PH> Peux-tu expliquer comment tu fais du RAID 5 avec deux disques ?

On parlait de swap hors raid, en fournissant directement les partitions phy siques au noyau qui
se débrouille très bien avec (en distribuant les écritures, ce qui revient à un raid0).

Avec 2 disques tu mets dans fstab
/dev/sdaN none swap …
/dev/sdbN none swap …

et ça multiplie les perfs par 2, avec un 3e tu ajoutes
/dev/sdcN none swap …
et ça fait ×3, mais effectivement si un disque lâche le swap est tout cassé et le système va
pas aimer.

Pour s'en prémunir, ce que tu préconises, un swap sur du raid ave c une seule ligne
/dev/mdX none swap

À chacun de voir ce qui est le plus efficace dans son contexte…

--
Daniel

Il est juste que celle qui a tue son mari meure.
Il est beau qu'un fils venge son père.
Donc il est juste et beau qu'un fils tue sa mère.
Aristote, Rhétorique, 2, 24

On 2017-12-05 00:23 +0100, Pascal Hambourg wrote:

Le 04/12/2017 à 15:13, Daniel Caillibaud a écrit :

>Si ça arrive quand même, c'est qu'il
>y a un souci et il vaut mieux qu'il soit le plus rapide possible pour
>éviter que ça ne
>dégénère (car dans ce cas, y'a souvent de l'effet domino, le système sature
>car y'a trop de
>trucs à faire, le swap le ralenti bcp donc il traite moins de chose et
>sature encore plus,
>jusqu'à ce qu'un oomkill passe par là).

Mettre des retours chariot, c'est bien, mais encore faut il que
la longueur de ligne qui en résulte soit assez petite pour être
bénéfique. Faire des lignes de 100 caractères, c'est pire que
tout. Pour ceux qui ont le malheur de lire ça sur un terminal de
80, cette méthode a les inconvénients du texte au kilomètres,
c'est à dire des lignes trop longues (plus de 66 caractères) et
la mocheté du wrapping automatique, /plus/ une marge de droite
en dents de scie (une ligne de 80, une ligne de 20, une ligne de
80...).

On peut soutenir un point de vue opposé : plus le swap est
lent, plus il laisse de temps pour réagir avant que lui aussi
soit plein. D'autre part, swapper ne signifie pas forcément
"thrasher". Par exemple une fuite mémoire va progressivement
remplir le swap mais n'en sortira jamais.

C'est vrai... Jusqu'à ce qu'on veuille terminer le processus en
question. À moins d'être brutal (kill -9), les routines avant
exit() font remonter toute cette cochonnerie en mémoire. La
plupart du temps uniquement pour pouvoir faire free() dessus ou
son équivalent, ce qui ne sert à rien puisqu'on va faire sbrk()
juste après. Mais soyons positifs, ça donne le temps de faire
une pause. <g>

--
André Majorel <http://www.teaser.fr/~amajorel/>
bugs.debian.org, an essential online resource for spammers.

Le 06/12/2017 à 10:53, Daniel Caillibaud a écrit :

Le 05/12/17 à 20:36, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
PH> Le 05/12/2017 à 11:09, Daniel Caillibaud a écrit :
PH> > Le 05/12/17 à 00:23, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
PH> > PH> (1,5 fois plus, la belle affaire),
PH> >
PH> > Je penses que c'est bien ×3 si tu donnes au noyau 3 partitions de swap sur 3 disques
PH> > différents, en tout cas avec 2 disques j'avais effectivement mesuré du ×2 en lecture et
PH> > écriture.
PH>
PH> Peux-tu expliquer comment tu fais du RAID 5 avec deux disques ?

On parlait de swap hors raid, en fournissant directement les partitions physiques au noyau qui
se débrouille très bien avec (en distribuant les écritures, ce qui revient à un raid0).

Plus précisément, on parlait de la comparaison entre trois swaps en
parallèle sur trois disques et un swap en RAID 5 sur les mêmes trois
disques. Je te cite pour mémoire :

C'est aussi ce que je fais sur toutes mes machines à 3 disques
- sd(a|b|c)1 de ~10G pour / en raid1 (ça bootera toujours tant qu'il reste un disque sur les 3)
- sd(a|b|c)2 pour du swap (volume suivant le besoin)
- sd(a|b|c)3 pour le raid5 mdadm

Si je ne m'abuse, le rapport de performance entre un RAID 5 sur N
disques et un disque seul est de N-1, soit 2 pour N=3. Donc le rapport
de performance entre 3 swaps en parallèle (équivalent RAID 0) et un swap
en RAID 5 est de 3/2 = 1,5, pas 3.

Bonjour à tous,

Merci pour vos réponses, je résume ce que j'ai fait au final.
N’ayant jamais été confronté à l’EFi, j’ai dû improviser.
J’ai partitionné comme suis :
/dev/sda1 : Taille : 200Mo, Nom : Efi.
/dev/sda2 : Taille : 200Mo, Nom : Boot.
/dev/sda3 : Taille : Le reste du disque, Nom : Data.

UEFI ne sachant pas traiter le Raid, il a fallu cloner la première
partition.
J’ai fait un petit script de duplication de la partition EFI sur les
autres disques. Ça n’est pas automatique pour l’instant.
dd if=/dev/sda1 of=/dev/sd[bcd]1 bs=1M

J’ai fait un Raid 1 des partitions « Boot » afin quelles soient identiques.
Et j’ai fait un Raid 5 sur les partitions « Data » qui contient un LVM
du système et du home.

Le démarrage est donc possible si on enlève n’importe quel disque.

Il y a juste un risque d’oubli de clonage de la partition EFI. Je ne
sais pas pour l’instant si cela peut-être problématique dans le temps.

Sil

Le 16/12/2017 à 10:12, Sil a écrit :

Merci pour vos réponses, je résume ce que j'ai fait au final.
N’ayant jamais été confronté à l’EFi, j’ai dû improviser.
J’ai partitionné comme suis :
/dev/sda1 : Taille : 200Mo, Nom : Efi.
/dev/sda2 : Taille : 200Mo, Nom : Boot.
/dev/sda3 : Taille : Le reste du disque, Nom : Data.

UEFI ne sachant pas traiter le Raid, il a fallu cloner la première
partition.

Comment l'as-tu clonée exactement ? Tu as aussi cloné le PARTUUID ou
seulement le contenu avec dd ?

A part ça, il y a d'autres méthodes pour installer GRUB dans les autres
partitions EFI. grub-install ou la copie des fichiers.

J’ai fait un petit script de duplication de la partition EFI sur les
autres disques. Ça n’est pas automatique pour l’instant.
dd if=/dev/sda1 of=/dev/sd[bcd]1 bs=1M

dd reconnaît cette syntaxe pour of= ?

J’ai fait un Raid 1 des partitions « Boot » afin quelles soient identiques.

Les membres d'un ensemble RAID 1 ne sont pas identiques. Leurs
méta-données RAID sont légèrement différentes, pour pouvoir les
différencier.

Et j’ai fait un Raid 5 sur les partitions « Data » qui contient un LVM
du système et du home.

Le démarrage est donc possible si on enlève n’importe quel disque.

Tu as testé ?

Il y a juste un risque d’oubli de clonage de la partition EFI. Je ne
sais pas pour l’instant si cela peut-être problématique dans le temps.

En toute rigueur, il faudrait "synchroniser" les partitions EFI après
chaque réinstallation du chargeur GRUB, donc essentiellement après une
mise à jour des paquets grub*.

Le 16/12/2017 à 17:23, Pascal Hambourg a écrit :

Comment l'as-tu clonée exactement ? Tu as aussi cloné le PARTUUID ou
seulement le contenu avec dd ?

Seulement avec dd. C'est pour moi la solution la plus simple. Je n'ai
pas touché aux PARTUUID.

A part ça, il y a d'autres méthodes pour installer GRUB dans les
autres partitions EFI. grub-install ou la copie des fichiers.

J'ai fait un grub-install sur les 4 disques mais ça ne copie pas la
partition. Elle n'est montée que sur le premier disque où GRUB a été
installé.
dd par compte, ne tient pas compte du point de montage.

dd reconnaît cette syntaxe pour of= ?

Non, c'est donnée à titre d'exemple, il faut soit dupliquer les lignes
avec les bonnes lettres ou utiliser une variable.

J’ai fait un Raid 1 des partitions « Boot » afin quelles soient
identiques.

Les membres d'un ensemble RAID 1 ne sont pas identiques. Leurs
méta-données RAID sont légèrement différentes, pour pouvoir les
différencier.

Ce qui m'importe c'est que l'image du noyau y soit dupliquée.

Et j’ai fait un Raid 5 sur les partitions « Data » qui contient un
LVM du système et du home.

Le démarrage est donc possible si on enlève n’importe quel disque.

Tu as testé ?

Oui, j'ai démarré sur tous les disques sans problèmes, Il faut juste que
UEFI ne se limite pas au premier disque dans sa recherche de partition EFI.

Il y a juste un risque d’oubli de clonage de la partition EFI. Je ne
sais pas pour l’instant si cela peut-être problématique dans le temps.

En toute rigueur, il faudrait "synchroniser" les partitions EFI après
chaque réinstallation du chargeur GRUB, donc essentiellement après une
mise à jour des paquets grub*.

C'est ce que j'ai peur d'oublier.
Sil

Le 16/12/2017 à 18:52, Sil a écrit :

Le 16/12/2017 à 17:23, Pascal Hambourg a écrit :

Comment l'as-tu clonée exactement ? Tu as aussi cloné le PARTUUID ou
seulement le contenu avec dd ?

Seulement avec dd. C'est pour moi la solution la plus simple. Je n'ai
pas touché aux PARTUUID.

Note que dd duplique l'UUID du système de fichier, et le système se base
sur cet UUID inscrit dans /etc/fstab pour monter la partition EFI sur
/boot/efi. Donc n'importe laquelle de ces partitions clones est
susceptible d'être montée au démarrage à la place de l'originale.

A part ça, il y a d'autres méthodes pour installer GRUB dans les
autres partitions EFI. grub-install ou la copie des fichiers.

J'ai fait un grub-install sur les 4 disques mais ça ne copie pas la
partition. Elle n'est montée que sur le premier disque où GRUB a été
installé.

Je n'ai pas dit qu'il suffisait d'exécuter grub-install. Je n'ai pas
détaillé les deux méthodes, mais il y a d'autres opérations à effectuer
et/ou des options spécifiques à passer. Si tu as juste exécuté

grub-install /dev/sdX1

pour chacune des partitions, sache qu'en mode EFI l'argument est ignoré
donc ça n'a pas plus d'effet et pas plus d'intérêt qu'exécuter
grub-install sans argument, ce qui installe GRUB dans la partition
montée sur /boot/efi.

Le démarrage est donc possible si on enlève n’importe quel disque.

Tu as testé ?

Oui, j'ai démarré sur tous les disques sans problèmes, Il faut juste que
UEFI ne se limite pas au premier disque dans sa recherche de partition EFI.

Le vrai test, ce serait d'essayer de démarrer sans le disque qui
contient la partition EFI dont le PARTUUID est enregistré dans la
variable d'amorçage EFI "debian", visible avec

efibootmgr -v

Les tables de partition sont-elles au format GPT ou DOS/MBR ?

Si GPT, pour autant que je sache, avec ta façon de cloner ça ne peut
marcher que si lors de l'installation tu avais demandé qu'une copie de
GRUB soit installée dans le chemin de support amovible
/boot/efi/EFI/boot/bootx64.efi.