raid0 vs lvm --stripes 2

Le
Daniel Caillibaud
Bonjour,

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je m=
e demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexi=
té (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

J'ai raté un truc ?

C'est dans l'idée unix "faire un seul truc correctement", où on c=
onsidère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces t=
âches ?


J'ai fait des tests avec 2 ssd (partition de 2,5Go au début de chaque =
disque), raid soft ou lvm sans raid (mais sur
les 2 pv avec --stripes 2), en lenny

hdparm -t (3 mesures, toujours dans +/- 5% donc j'ai pris l'intermédia=
ire) :
raid1 64k 202.68 MB/sec
raid1 128k 196.22 MB/sec
raid0 64k 398.62 MB/sec
raid0 128k 428.77 MB/sec
lvm 2/64 398.36 MB/sec (--stripes 2 --stripesize 64)
lvm 2/128 425.87 MB/sec
lvm 2/256 454.28 MB/sec
lvm 2/512 454.98 MB/sec

J'ai aussi fait des tests en écriture ("for i in $(seq -w 1 99); do cp=
-a /sbin /mnt/test/sbin$i; done;",
mesures plus sujettes à caution car nettement plus variables, il aura=
it fallu faire 10 ou 20 mesures, et faire ensuite la
moyenne en virant les extrêmes mais c'était long, je voulais just=
e avoir une idée, et puis il aurait fallu tester avec petits
et gros fichiers, bref)
raid1 64k 0m28.615s
raid1 128k 0m25.864s
raid0 64k 0m13.032s
raid0 128k 0m11.372s
lvm 2/64 0m12.806s
lvm 2/128 0m13.678s
lvm 2/256 0m13.990s
lvm 2/512 0m13.162s

Il faudrait aussi tester lvm au dessus d'un raid0 128k, mais si j'ai besoin=
de perfs je cherche pas trop à gratter qq % de
plus, la fiabilité/stabilité/simplicité de maintenance Ã=
©tant plus importante pour moi.

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir pa=
r ex, les disques sont des X25-M, c'est pour une
utilisation de serveur web assez classique (apache/php/mysql), pas vraiment=
de gros fichiers à manipuler

--
Daniel

Il y a des temps où l’on ne doit dépenser le mépris =
qu’avec économie,
à cause du grand nombre de nécessiteux.
Chateaubriand (Mémoires d'outre-tombe, 1848)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20100720075425.3c859c0d@h2.lairdutemps.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Julien Demange
Le #22377581
Bonjour,

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.



perso, autant, je recommande vivement LVM quand on utilise mdadm (sauf
cas un spé particulier). Auant je ne recommande pas mdadm quand on ne
fait pas de RAID (et le raid0, c'est pas vraiment du RAID).

De mon point de vue, le raid0 avec mdadm peut êtres pratique quand on a
deux disques, plusieurs partitions et que l'on veut que deux de ces
partitions (chacune sur un disque) soit en strpping. Eventuellement deux
autres partitions en raid1. Dans ce genre de cas particulier LVM ajoute
une surcouche peu utile et en plus on a éventuellement déjà mdadm, donc
ça simplifie la gestion.

Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
l'intérêt de mettre mdadm alors qu'il n'y a pas de RAID (je ne considère
pas le raid0 comme du RAID).

En plus de la surcouche, ça diminue l'intérêt de LVM. Car sur ton VG,
rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
noyau est réputé êtres capable de bien gérer la répartition entre les
swap. Tu peux éventuellement avoir des LV qui ne serait pas en striping.
Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est très cohérent en
raid1/5, mais pas forcément en raid0).

Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
déplacer, à chaud, tes donnés d'un disque à un autre. Cas ou SMART te
rapporterait qu'un disque est en train de mourir. Là, où avec LVM, tu
peux aisément , après avoir ajouté un autre disque, déplacer, en
fonctionnement, les LV d'un PV, vers un autre.



J'ai raté un truc ?

C'est dans l'idée unix "faire un seul truc correctement",



pas sur que ça soit forcément cohérent.

où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?



Aucune idée. Je ne sais pas du tout pour les pref !


[...]

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une
utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...



Je ne sais pas. Je ne suis pas un spécialiste des disques.
Mais ça l'intéresse aussi ;



--
a+,
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jean-Yves F. Barbier
Le #22377611
Le 20/07/2010 07:54, Daniel Caillibaud a écrit :
Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

J'ai raté un truc ?



Le fait que lorsque tu planteras un RAID-0 ou un LVM les données seront irrécupérables
(avec de *très* rares exceptions pour LVM.)

C'est dans l'idée unix "faire un seul truc correctement", où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?



"séparer les couches" ne sert qu'à rajouter de la latence.

J'ai fait des tests avec 2 ssd (partition de 2,5Go au début de chaque disque), raid soft ou lvm sans raid (mais sur


^^^^^^^^^^^^^^^^^^^^^^
Mouarf: le truc du début de HD, c'est pour... les HDz, pas pour les SSD
qui sont par essence statiques (le temps de latence reste le même qq soit
l'emplacement sur le "disque" puisqu'on parle d'adressage mémoire et pas
de déplacements de têtes.)

les 2 pv avec --stripes 2), en lenny

hdparm -t (3 mesures, toujours dans +/- 5% donc j'ai pris l'intermédiaire) :
raid1 64k 202.68 MB/sec
raid1 128k 196.22 MB/sec
raid0 64k 398.62 MB/sec
raid0 128k 428.77 MB/sec



Là je ne comprends plus, tu mélanges du RAID-0 et du RAID-1 dans ton
test alors que les finalités sont totalement opposées.

lvm 2/64 398.36 MB/sec (--stripes 2 --stripesize 64)
lvm 2/128 425.87 MB/sec
lvm 2/256 454.28 MB/sec
lvm 2/512 454.98 MB/sec

J'ai aussi fait des tests en écriture ("for i in $(seq -w 1 99); do cp -a /sbin /mnt/test/sbin$i; done;",
mesures plus sujettes à caution car nettement plus variables, il aurait fallu faire 10 ou 20 mesures, et faire ensuite la
moyenne en virant les extrêmes mais c'était long, je voulais juste avoir une idée, et puis il aurait fallu tester avec petits
et gros fichiers, bref...)
raid1 64k 0m28.615s
raid1 128k 0m25.864s
raid0 64k 0m13.032s
raid0 128k 0m11.372s
lvm 2/64 0m12.806s
lvm 2/128 0m13.678s
lvm 2/256 0m13.990s
lvm 2/512 0m13.162s

Il faudrait aussi tester lvm au dessus d'un raid0 128k, mais si j'ai besoin de perfs je cherche pas trop à gratter qq % de
plus, la fiabilité/stabilité/simplicité de maintenance étant plus importante pour moi.

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une



Comme le dit la doc, seule l'expérimentation peut indiquer les résultats
escomptés en fonction de l'utilisation de chacun.

utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...



Dans cette configuration, les goulets d'étranglement seraient plutôt apache et php
que mysql (et d'ailleurs, que font-ils tous sur le même HD?)
Si la vitesse et le temps de réponse sont primordiaux, considère plutôt des
serveurs HTTP performants comme nginx ou yaws.

--
<Overfiend> penis jokes are okay in mixed company. VMS is NOT!!!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Daniel Caillibaud
Le #22377951
Le 20/07/10 à 12:00, Julien Demange JD> Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
JD> l'intérêt de mettre mdadm alors qu'il n'y a pas de RAID (je n e considère
JD> pas le raid0 comme du RAID).

OK, j'avais la même impression.

JD> En plus de la surcouche, ça diminue l'intérêt de LVM. Ca r sur ton VG,
JD> rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
JD> noyau est réputé êtres capable de bien gérer la r épartition entre les
JD> swap.

Donc, la swap dans le vg, il vaudrait mieux avoir deux lv, un sur chaque pv (me suis jamais demandé si c'était possible),
plutôt qu'un lv avec 2 stripes ?

JD> Tu peux éventuellement avoir des LV qui ne serait pas en striping.
JD> Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est très cohà ©rent en
JD> raid1/5, mais pas forcément en raid0).
JD>
JD> Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
JD> déplacer, à chaud, tes donnés d'un disque à un autr e. Cas ou SMART te
JD> rapporterait qu'un disque est en train de mourir. Là, où avec LVM, tu
JD> peux aisément , après avoir ajouté un autre disque, dà ©placer, en
JD> fonctionnement, les LV d'un PV, vers un autre.

C'est vrai aussi.
De toute façon il me faut du lvm (pour les snapshots), donc je vais me passer de mdadm.

JD> > Par ailleurs, si vous avez des conseils, sur le chunksize à choi sir par ex, les disques sont des X25-M, c'est pour une
JD> > utilisation de serveur web assez classique (apache/php/mysql), pas vr aiment de gros fichiers à manipuler...
JD>
JD> Je ne sais pas. Je ne suis pas un spécialiste des disques.
JD> Mais ça l'intéresse aussi ;

Entre temps, j'ai testé lvm "standard" au dessus de mdadm en raid0 ave c des chunk de 128k, on perd ~15% sur du hdparm -t (par
rapport à du raid0 seul ou du lvm --stripes 2 seul).

--
Daniel

Le philosophe cherche des solutions aux problèmes et
ne trouve que des problèmes sans solutions.
Sim

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Daniel Caillibaud
Le #22377941
Le 20/07/10 à 12:10, "Jean-Yves F. Barbier" JYFB> Le 20/07/2010 07:54, Daniel Caillibaud a écrit :
JYFB> > J'ai raté un truc ?
JYFB>
JYFB> Le fait que lorsque tu planteras un RAID-0 ou un LVM les données seront irrécupérables
JYFB> (avec de *très* rares exceptions pour LVM.)

Non, ça je suis au courant, c'est pareil dans les deux cas, mais c'est pas grave, si ça crash y'en a une autre qui prend le
relai.

JYFB> "séparer les couches" ne sert qu'à rajouter de la latence.

C'est ce qu'il me semblait, mais comme plein de gens apparemment calés ajoutent du lvm au dessus de mdadm, je me posais la
question...

JYFB> Mouarf: le truc du début de HD, c'est pour... les HDz, pas pour les SSD

Oui, merci de le rappeler ;-)

JYFB> Là je ne comprends plus, tu mélanges du RAID-0 et du RAID-1 dans ton
JYFB> test alors que les finalités sont totalement opposées.

Oui, c'était juste pour vérifier que j'avais bien mon facteur 2 ( et aussi parce que la machine était livrée en raid1, donc
avant de le casser je l'ai testé aussi).

JYFB> > Par ailleurs, si vous avez des conseils, sur le chunksize à ch oisir par ex, les disques sont des X25-M, c'est pour une
JYFB>
JYFB> Comme le dit la doc, seule l'expérimentation peut indiquer les r ésultats
JYFB> escomptés en fonction de l'utilisation de chacun.

Certes...
Mais si y'a des trucs à éviter, autant le savoir (j'ai lu qq part qu'il valait mieux des chunk de 128k sur ces ssd, mais dans
un seul post sur un forum, sans l'avoir lu ailleurs).

JYFB> > utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...
JYFB>
JYFB> Dans cette configuration, les goulets d'étranglement seraient pl utôt apache et php
JYFB> que mysql (et d'ailleurs, que font-ils tous sur le même HD?)

Ils sont dans des VM différentes.
Si mysql devient trop goinfre il migrera sur un host pour lui seul.

JYFB> Si la vitesse et le temps de réponse sont primordiaux, considà ¨re plutôt des
JYFB> serveurs HTTP performants comme nginx ou yaws.

Sans vouloir lancer de troll, j'ai pas vu de différence significative (avec php en fastCgi) entre apache2 "minimaliste" (sans
rewrite ni htaccess) et nginx, et comme je connais mieux apache je l'ai gar dé.

Chez moi, la saturation viendrait plutôt du wrapper fastCgi (unique po ur profiter du cache APC), mais il faut que je teste
davantage.

--
Daniel

Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Julien Demange
Le #22378201
Le 20/07/2010 13:56, Daniel Caillibaud a écrit :

JD> En plus de la surcouche, ça diminue l'intérêt de LVM. Car sur ton VG,
JD> rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
JD> noyau est réputé êtres capable de bien gérer la répartition entre les
JD> swap.

Donc, la swap dans le vg, il vaudrait mieux avoir deux lv, un sur chaque pv (me suis jamais demandé si c'était possible),
plutôt qu'un lv avec 2 stripes ?



ben, je ne garanti pas que c'est plus performant, mais ça enlève une
couche. J'ai lu plusieurs fois que c'est mieux. Je n'ai jamais fait de
test de perf.
Et donc oui, c'est possible, faut bien spécifier au noyau que chaque
swap doit être utliser en même temp, i.e avec la même priorité. Ceci
avec l'option "pri=X" dans le "fstab" ou "-p X" dans les paramètres de
"swapon".


--
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Vincent Danjean
Le #22380861
On 20/07/2010 13:58, Daniel Caillibaud wrote:
JYFB> > Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une
JYFB>
JYFB> Comme le dit la doc, seule l'expérimentation peut indiquer les résultats
JYFB> escomptés en fonction de l'utilisation de chacun.

Certes...
Mais si y'a des trucs à éviter, autant le savoir (j'ai lu qq part qu'il valait mieux des chunk de 128k sur ces ssd, mais dans
un seul post sur un forum, sans l'avoir lu ailleurs).



Il faut aussi aligner les partitions correctement (gpt fait ça mieux que
msdos : l'outil parted permet de manipuler tout ça) sinon ça ne sert à rien
d'aligner les chunk.
Je viens de faire ces manip pour deux DD avec des secteurs physiques
de 4ko (mais un firmware qui persiste à les déclarer en 512o :-( )

Un bon point d'entrée pour la doc :
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

A+
Vincent

--
Vincent Danjean GPG key ID 0x9D025E87
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme