Bonjour,
 
J'ai actuellement une machine de test qui a un seul disque physique de 146 Go (sda) :
/boot    ext3     200Mo (sda1)
le reste en LVM (sda2) distribué sur :
/         ext3      40Go       (lv02)
/tmp    ext3      8Go        (lv01)
swap    swap     8Go       (lv00)
/opt     ext3      68Go      (lv03)
le reste dispo dans le VG
 
Je souhaite par la suite lui rajouter un 2eme disque de meme taille (sdb) pour faire du raid soft.
 
Qelle est la meilleure solution en terme de maintenance/perf ? Un RAID1 de sda1 et de sda2 ou un RAID de sda1 et des différents LV ? Ou une autre solution ?
(en résumé, un RAID des PV ou un RAID des LV ? )
 
Edit : CentOS 5.3
 
Je trouve un peu de tout sur le net
 
Merci.

raid de sda2

Merci,
 
tu dis ca pour les possibilités de retaillage des LV je pense ?  
 

retailler une partoche, ça se fait ... un raid, je suis moins sur
 
et puis .. N piles raid = N processus
bon ok ça bouffe pas grand chose, mais c'est tjs ça de gagné

Exactement. Et puis en cas de reconstruction, c'est N trucs à gérer alors que c'est le même disque

vu que grub peut booter sur raid et lvm, c'est fesable de faire un raid sur un sda direct du coup non ?
 
par contre je me demande comment le mbr est géré et le boot secteur, je sais pas si lvm peut gérer une install direct sur disque sans être inclu dans une table de partition.

Oui faisable.

Mais grub (je ne sais pas pour grub2) ne sait pas démarrer direct depuis un RAID0 ou un volume LVM, il faudra un /boot séparé sans rien ou alors en RAID1 (vu qu'en RAID1, la partition est lisible directement même sans la monter dans un volume RAID).

Donc pour ta question, non en fait
(sans /boot séparé en tout cas)

Pas compris

Tiens si ça peut t'aider et résumer un peu, la config du RAID-1 de mon serveur :

2 disques, sda et sdb.

Sur chaque disque j'ai créé à l'identique sur l'un et l'autre deux partitions, sdX1 et sdX2.
sdX1 font 200Mo, sdX2 le reste.

J'ai ensuite créé deux volumes RAID1 :

md1
Est formaté en ext3 et est monté comme /boot, il contient un /boot normal de Debian, dont le kernel et grub

J'ai bien fait attention de répliquer manuellement l'installation de Grub dans le MBR de sda et sdb, comme ça si un des deux tombe en rade, ça boote quand même.

md0
N'est pas formaté directement, je l'ai défini comme volume physique LVM.

Ensuite classique, création d'un groupe de volumes, puis de volumes logiques, dont celui qui sera monté comme racine du système.

Tu peux créer une seule grosse partition sur chaque disque, et l'utiliser dans ton raid c'est ce que j'ai fait, grub2 boote très bien dessus (faut juste connaitre la bonne ligne de commande pour inclure les bons modules à l'image).
 
Par contre utiliser le disque entier sans partition ça pose problème, comme tu l'a dit pas de partition = pas de MBR et surtout pas d'espace libre entre la fin de la table de partition et le début des partitions hors Grub2 a besoin de cet espace pour y stocker les pilotes pour accéder au volumes raid/lvm.
 
Perso j'ai ce schéma  

 
Mais je ne pense pas que Cent'OS te laissera faire ça, la dernière fois que j'ai testé Fedora l'installeur voulais pas entendre parler de partition /boot sur un LVM !

 
Bien vu  

j'ai réfléchis
et
ça n'est pas forcément incompatible
dans la theorie
Ce qu'il faut faire c'est la commande que tu as donnée

mdadm --create --auto=mdp --verbose /dev/md_d0 --level=mirror --raid-devices=2 /dev/sdb missing

(le missing c'est parceque j'ajouterais le disque ensuite, apres avoir transféré toutes les données de sda)

création d'une table de partition dans /dev/md_d0
création d'une partion dans cette table qui apparaitra comme /dev/md_d0p1 et l'utiliser en volume physique LVM par exemple, ou utiliser des partitions normales.

en principe un bootsecteur installé dans /dev/md_d0 devrait bien être le vrai bootsecteur sur lequel le bios demarera, et en principe mdadm ne devrait pas considérer que le device virtuel /dev/md_d0 va jusqu'a la fin du device réel /dev/sdb, il devrait se garder la fin pour ses données.
Grub est capable de se trouver son stage2 sur le raid ou bien lvm, et de trouver le kernel pour le lancer, et le kernel montera le / qui apres avoir assemblé le raid puis lvm.

Je le vois comme ça, je vous dirait comment ça se passe
Je pense pas utiliser lvm, je me tate.

Y'a beaucoup de suppositions dans la démarche, mais pourquoi pas
 
On te regarde  

bouef, la vraie supposition c'est qu'il n'y ai pas un bug quelque part, et aussi la capacité non bugguée de grub à dépiler raid et lvm pour trouver le kernel

qu'un device soft raid mette ses infos à la fin du device qui le contient ça on le sait
donc ça devrait bien se passer

et en googlant j'ai eu une réponse à une de mes questions sur LVM. On ne peut pas booter sur un disque ou LVM utilise le device du disque comme volume physique. Donc par exemple /dev/sda, car LVM va commencer dès le secteur zéro, donc si t'éssaye de mettre grub il va écraser l'entête LVM et tout flinguer, et vice versa, LVM va écraser le secteur 0, donc il faut au moins une partition, et ils ont pas l'intention de changer ce comportement.
Avec le dm raid il n'y a pas ce probleme, mais ça n'empeche pas qu'il faille du coup créer une table de partition et une partition pour lvm dans le raid, car le problème est le même.

De même il devrait être possible de convertir une partition ext4 /dev/sdbX existante en raid 1, en réduisant la taille de la partition de plusieurs mégas, en integrant la partition dans le raid /dev/md1 par exemple, puis ensuite en agrandissant le système de fichier pour qu'il remplisse /dev/md1 .
Mais bon si c'est pas du raid1 c'est pas la peine bien entendu, et ça reste moyen comme manip.

basketor63-> Les metadata d'un array RAID sont stockés en fin de volume sous Linux, donc dans le cas d'un RAID1 mettre la table de partition par dessus le RAID fonctionnera !
Par contre en RAID0 (c'est mon cas) non et il n'est toujours pas possible de mettre du LVM directement par dessus du RAID sans créer de table de partition de type PC quelque-pars si on veut que ce soit bootable.

C'est en rapport avec Linux ta citation ?
 

bon ça marche pas, les outils de grub ne sont pas adaptés au /dev/md_p0  
ce qui fait que quand je fais un grub-install sur ce périphérique, il me sort ne peut trouver /dev/md0

Ici moi j'utilise un raid 0 sur 2 disques (2 grosse partition en raid) et j'ai mis par dessus un LVM pour pouvoir faire mon petit découpage de partitions et ça marche du feu de dieux avec Grub2

Pareil  

je vais devoir faire pareil

je ne vois pas en quoi c'est un problème ...

c'est moins beau

bon j'ai un petit soucis, le kernel se charge bien mais il parvient pas à trouver ma partition lvm. En fait le mdraid ne semble pas s'être assemblé au boot, j'ai du le faire à la main dans le busybox

si tu as du assembler ta pile dans busybox, faudra surement aussi que tu actives la couche lvm :

vgscan -ay

as tu bien embarqué tous les pilotes nécessaires dans ton image initrd ?
edit : ta pile mdadm se base sur des partitions "linux raid, type fd" ? as tu configuré mdadm pour qu'il assemble automatiquement au moins ta pile hébergeant / ?

en fait c'est le mdadm.conf qui n'était pas configuré dans /etc, et donc pas inclu dans le initrd.
en principe le kernel est censé autodétecter en scannant les partitions, mais là comme c'est du gpt et pas du msdos, il y arrive peut être pas, ce qui me parait pas trop plausible vu que grub2 y arrive

autre soucis que j'ai eu qui est survenu après, j'avais pas les bons modules dans le core.img de grub, j'ai donc ajouté grub-install --modules="ext2 chain part_msdos part_gpt biosdisk raid mdraid lvm"
normalement grub le fait tout seul, et n'a besoin que de raid mdraid lvm, mais j'ai du merder et là j'ai un truc qui marche, donc j'évite d'y toucher.

je verrais bien quand j'ajouterai le second disque à l'array, car je vais devoir y installer grub aussi.
donc là je tourne bien sur le raid1 mais avec une seule jambe
Il faut maintenant que je face la table de partition à l'identique et que j'installe grub dans l'autre, puis que j'ajoute le disque. Mais bon, là il faut que je sois sur de moi, car si ça foire, je suis dans la merde
Je pense que je vais faire un backup de mes photos et mp3 sur un autre disque avant
Il ne devrais pas y avoir de raison, j'ai déjà migré toutes les données vers le nouveau systeme, qui est en fait le même, mais par dessus raid1+lvm.

Un truc que je me demandais, c'est comment le raid fait pour savoir quel est le disque maitre.
Par exemple quand le systeme est tout le temps online, c'est plutot évident, il y a forcément un disque actif.

Mais si par un exemple un coup tu démarres sur un disque sans que l'autre soit dans l'array.
Puis un coup tu fais le contraire, car les disques sont bootables.

si après tu démarres la machine avec les deux, il fait comment ???

avec un mdraid sur le disque complet j'aurai pas eu à faire un partitionnement ou à installer grub, il suffisait d'installer le device
 
mais bon, ça je le retenterais avec une machine virtuelle, car certains messages sont étranges.
Mais je vois pas de raisons que ça fonctionne pas, si ils ont bien conçu le truc.
 
les messages étrange que j'avais, c'est du style lors du partprobe, il previent que gpt n'utilise pas tout le disque. Ce qui est logique, vu mdraid met son metablock à la fin du disque, et que le partition gpt est crée à partir de /dev/md0 qui se base sur /dev/sda.
 
Normalement, grub au démarage charge son core.img avec les modules lui permettant d'assembler les raid et lvm, mais là c'est pas sur qu'il comprenne correctement si on lui dit de s'installer dans /dev/md0

bon le raid tourne, je me sens maintenant un peu plus tranquille
les accès en lecture on l'air plus rapide
je pensais qu'un deuxième disque produirait encore plus de nuisance sonore, mais ces western green sont plutot silencieux.

j'ai tenté dans une vm de faire un raid sur disque entier, mais c'est trop bencale, la plupart des outils ne s'attendent pas à ça.
On peut se retrouver avec la table de partition lue deux fois, donc sda1 sda2  et md0p1 md0p2.
lvm n'a l'air de vouloir s'installer dans les mdraids partitionés qui sont créés au préalable avec --auto=mdp.
l'installer d'ubuntu comprend rien, d'ailleurs le cd desktop permet pas de choisir des partitions lvm, même si on à installé lvm dans le live cd.
le cd alternate ne lit pas la table de partition de /dev/md0.
Et si ça marchait avec /dev/md_p0, les outils grubs tripent et veulent installer dans /dev/md0 même si on spécifie md_p0.

Bref c'est trop bancal à mettre en œuvre pour un disque qui sera bootable.

Pour ma part je comprends pas trop sur le plan technique pourquoi une distinction est necéssaire entre les raids partionables et non partionables /dev/md0 et /dev/md_p0, car dans la pratique j'ai déjà déclaré des images disques en périphérique de bloc loop avec système de fichier direct dessus, ou bien table de partition.
Dans la pratique on peut faire mkfs.ext4 /dev/sdb par exemple et faire mount /dev/sdb /mnt/sdb il me semble.

si qqun à une raison précise, ça satisfera ma curiosité

est ce que quelqu'un à déjà tenté l'inverse en mettant le raid sur les partitions lvm pour pouvoir mixer différents types de raid.
par exemple faire un volume lvm pour chaque disque en utilisant une grosse partition en volume physique pour chaque.
partitionner à l'identique, faire les raids, avec par exemple os et données jetables sur des partitions distinctes en raid0 , et données sensibles en raid1.
 
du coup là pour redimentionner il faut redimentionner système de ficher, puis le raid, et lvm, c'est pas top, surtout qu'avec lvm tu sais pas bien ou il alloue les données sur le disque pour avoir des perfs symétriques

Je suis du même avis : autant en théorie ça passe, autant je le ferais jamais en pratique vu qu'en LVM les données vont un peu partout.

en principe lvm est censé abstraire ce soucis
donc ça ne devrait pas être une préocupation.
je pense pas que techniquement ça pose problème si le mirroir possède des données identiques au début d'un disque et à la fin de l'autre. En lecture non, ça tend à uniformiser la lecture d'ailleurs.
Mais pour de l'écriture en raid 1 il faudrait attendre le disque le plus lent et on se retrouverait donc toujours dans le pire des cas comme si on écrivait toujours en fin de disque.

Par contre la redimensionnement serait encore plus lourd, il faudrait redimensionner 2 partions lvm, 2 partitions raids, 1 système de ficher, et il y a pas de commande permettant de tout gérer d'un coup.
Avec du lvm dans un raid1 ou 0, ça fait juste 1 lvm et 1 système de fichier.
Ca serait tellement lourd que t'y réfléchirait à deux fois avant de le faire, et lvm perdrait de son intérêt

Ah non ça ne pose pas vraiment de gros problème de fonctionnement, mais placer LVM en dessous du RAID, ça me paraît bancal.
Et en fait je ne vois pas ce que tu gagnerais à le faire.

bah si, tu peux mixer facilement des raids et redimentionner plus facilement qu'avec deux tables de partition fixes.
Par exemple os en raid 0, données jetables en raid 0 pour gagner en place disque, données sensible en raid1.

Mais d'ailleurs au fond je pense que le raid1 soft est plus performant en lecture que le raid 0.
En raid 1 l'os choisit le disque le plus disponible pour chercher les données, qui se trouvent sur les deux disques, là où en raid 0 il y a pas le choix du disque, et tu peux pas paralléliser.

par exemple en raid 1 tu peux lire un fichier sur un disque et un autre fichier sur l'autre disque. En raid 0 c'est pas possible. Par contre en écriture le raid 0 est plus performant.

Tu parles en temps d'accès donc  ?
 
Parce que en débit, en lecture le RAID-0 est forcément devant  

bah non
le raid 1 avec lecture parallèle peut pas être plus lent

en raid 0 tu as les blocs A1,C1,E1 sur un disque et sur l'autre B2,D2,F2
sur le raid 1 tu as A1,B1,C1,D1,E1,F1 sur un disque et A2,B2,C2,D2,E2,F2 sur l'autre

Tu peux lire la séquence A1,B2,C1,D2,E1,F2 de la même façon en raid 1 ou 0, à ceci près que si les données sont contigues, le raid 0 n'aura pas faire de sauts.

Il y a que en vitesse d'écriture et en espace que le raid 0 est plus performant.

Ah oui c'est vrai on peut faire du parallèle en 1
 
Et au fait on fait ça comment ?

je pense que c'est géré par le kernel.
Si il doit lire un fichier, il doit charger depuis le fs les blocs nécéssaires, qui sont traduits en blocs LVM puis mdraid puis en bloc disque et mdraid choisit "intelligement" la répartition sur les disques
d'ou peut être l'intérêt d'avoir mdraid au dessous ...

du coup si il doit lire A,B,C,D,E,F
je pense qu'il lira pas en sautant genre A1,C1,E1 et B2,D2,F2, il lira en parallèle A1,B1,C1 et D2,E2,F2 du coup pour du contigu je pense que le raid1 ne serait pas désavantagé

reste à savoir si c'est actif par défaut et si ils ont codé comme des stars

ce qui manquerait juste c'est une meilleure protection contre les rm -fr machin * , ça m'est déjà arrivé , mais ctr+c à permis de limiter la casse
Il me semble qu'il y a une lib qui permet de gérer une corbeille pour rm.
C'est dommage que ça soit pas géré direct par ext4 par exemple.

Non mais ok, sauf que par défaut il ne le fait pas
Donc si c'est possible il doit y avoir une option quelque part.

je vois pas trop pourquoi il le ferait pas par défaut
mais bon j'ai pas fait de tests concrets pour le moment

 
Parce que je te le dis
 
Chez moi les perfs sont celle d'un disque, puis de l'autre, mais pas du tout celles d'une parallélisation.

ok
je sais que linux avec multipath permet de supporter le load balancing
j'ai déjà installé ce package, ça créé une couche d'abstraction supplémentaire dans /dev/mapper/ par contre je sais pas si on peut passer par là pour obtenir ce qu'on veut, ce qui m'étonnerait, ou si mdraid suffit et peut le faire lui même

ok en fait multipath permet de faire du load balancing quand il y a plusieurs lien vers un seul device, ce qui n'est pas notre cas, mais si virtuellement mdraid à potentiellement deux liens vers le même device virtuel en lecture, ce qui n'est pas le cas en écriture.

 
Ton linux vient de quelle planète ??    
Parce que pour ma part, 3 Debian squeeze (actuelle testing), noyau 2.6.32, 3 systèmes en raid 1, quand je lis un gros fichier (et je ne fais que ça, à part les 3-4 services de base qui tournent, même en single), j'ai tantôt la loupiotte d'activité d'un disque qui s'allume tantôt celle de l'autre disque (mes disques sont dans des racks hotswap)
Preuve que ça parallélise nan ?

Ben non justement, ça alterne, ça parallélise pas.

Si ça parallélisait les 2 loupiotes seraient actives en même temps.

Planète debian.org sinon