[SERVEUR PERSO] Raid, LVM et FS

[HPact]

Bonjour à tous.

Je suis en phase d'acquisition des pièces nécessaires pour me monter un serveur perso à la maison.

Son but sera:

- NAS dans un premier temps (partage Samba, accès FTP)

- serveur de VM

- dans un futur proche, routeur/firewall (carte réseau à ajouter)

- dans un futur moins proche, mediacenter (carte TV à ajouter) ou simplement serveur DLNA

- dans un futur plus ou moins lointain (lorsque je serais fibré -un jour, oh oui, un jour-), serveur HTTP pour diffuser photos (ça, c'est déjà faisable) et mais aussi films persos à la famille par streaming (transcodage de FullHD vers quelque chose de plus facile à transférer par le net)

Je comptais installer un Linux dessus, Ubuntu (avec l'interface graphique, car si la ligne de commande ne me dérange pas, je suis allergique à VI et ses descendants, et puis j'aime bien avoir plusieurs fenêtres bashs :)) par exemple, ou toute autre distrib' permettant et ayant la logithèque pour tout ça.

Je ne suis pas expert Linux, j'y ai touché il y a 15 ans quand il fallait configurer à la mimine la configuration des fréquences des écrans pour faire fonctionner le serveur X, mais depuis, j'ai plutôt passé mon temps sous Windows, tout en lançant de temps en temps un LiveCD pour voir comment ça évoluait.

Voilà les grandes lignes.

Maintenant, le détail de ma question.

Dans ce serveur, 5 disques pour le stockage seront présents (plus 1 pour le système). Je comptais initialement partir sur du Raid5 avec mdam.

Seulement voilà, j'ai vu qu'il existait ZFS qui était plus sécurisant pour les données qu'un simple raid5. Et vient se greffer là-dessus LVM et le ext4, et maintenant, c'est un peu tout embrouillé dans ma tête

Faire un Raid5 avec LVM par dessus, je n'y vois pas spécialement d’intérêt pour mon besoin, à part potentiellement restreindre par exemple la taille d'un dépôt FTP public. Je pourrais faire des volumes pour les fims, les photos, etc., mais comme je ne sais pas prévoir l'évolution de chacun, je n'ai pas spécialement envie de m'amuser régulièrement à retailler les volumes.

Donc, avoir un seul gros volume ne serait-il pas mieux ou y a-t-il d'autres avantages liés à LVM que je ne vois pas?

Pour ZFS (RaidZ1 pour équivalent du Raid5 il me semble?), son désavantage tient selon moi, dans la difficulté à ajouter un disque au raid. Je me trompe?

Et maintenant ext4 qui concurrence ZFS d'après ce que j'ai lu quelque part. Est-ce réel? Possibilité de réaliser une tolérance de pannes équivalente au raid5 (i.e. perte d'un disque sans perte de données)? Ou alors c'est juste au niveau du FS?

Donc voilà, je ne sais plus trop comment mettre en place tout ça et c'est pourquoi j'aurais besoin de votre avis et aide.

Merci d'avance!

[madko]

Bonjour,

LVM peut être surtout pratique si tu prévois d'ajouter un disque pour agrandir le volume. On conseille quand même de faire plusieurs partitions ou LV mais ce n'est en effet pas obligatoire. C'est juste plus pratique/rapide quand tu dois vérifier/reparer une partition. Et au moins tu isoles les services comme tu disais. Mais pour un usage perso...

Pour ZFS je pense que tu te trompe en effet, son avantage étant justement sa souplesse d'administration. Par contre sous Linux, ZFS...

EXT4 est juste un format de système de fichiers, que tu mettras par exemple par dessus ton LVM, si tu veux pouvoir stocker des fichiers. Donc c'est juste au niveau FS.

Habituellement on fait du RAID5, et par dessus du LVM, avec des partitions logiques formatées en EXT4. Le LVM étant la partie optionnelle dans l'histoire.

L'avantage de le faire en plus avec mdadm (raid logiciel) c'est que tu ne seras pas dépendant du matériel, en cas de soucis c'est pratique.

[HPact]

LVM peut être surtout pratique si tu prévois d'ajouter un disque pour agrandir le volume.

Ok, mais si je suis en Raid5, ajouter un disque à la grappe raid signifie reconstruire le raid de toutes façons. Puis étendre ensuite les "Logical Volumes" ou les "Volume Groups" non?

On conseille quand même de faire plusieurs partitions ou LV mais ce n'est en effet pas obligatoire. C'est juste plus pratique/rapide quand tu dois vérifier/reparer une partition. Et au moins tu isoles les services comme tu disais. Mais pour un usage perso...

Il faut peser entre la contrainte de gérer l'espace "au jour le jour" pour étendre tel partition ou telle autre contre le temps passer à vérifier/repair. Il me sera plus contraignant pour moi de faire ces extensions je pense. Le check pouvant être fait de nuit et en journée quand je bosse...

Pour ZFS je pense que tu te trompe en effet, son avantage étant justement sa souplesse d'administration. Par contre sous Linux, ZFS...

Il me semblait pourtant qu'ajouter un DD à un raidZ1 n'était pas possible, mais qu'il était possible de l'importer dans un autre pool ou un truc comme ça...

ZFS sur Linux, il y a ZFS on Fuse qui existe. Maintenant, niveau perf...

EXT4 est juste un format de système de fichiers, que tu mettras par exemple par dessus ton LVM, si tu veux pouvoir stocker des fichiers. Donc c'est juste au niveau FS.

Ok, c'est bien ce qu'il me semblait.

L'avantage de le faire en plus avec mdadm (raid logiciel) c'est que tu ne seras pas dépendant du matériel, en cas de soucis c'est pratique.

Oui, c'est pour ça que je m'orientais dans cette direction avant d'entendre parler de ZFS

[theocrite]

Je comptais installer un Linux dessus, Ubuntu (avec l'interface graphique, car si la ligne de commande ne me dérange pas, je suis allergique à VI et ses descendants, et puis j'aime bien avoir plusieurs fenêtres bashs :)) par exemple, ou toute autre distrib' permettant et ayant la logithèque pour tout ça.

GNU/Screen permet ça.

Faire un Raid5 avec LVM par dessus, je n'y vois pas spécialement d’intérêt pour mon besoin, à part potentiellement restreindre par exemple la taille d'un dépôt FTP public.

J'utilise du Raid5 (mdadm) + LVM par dessus.

Mais pour le cas du FTP, je pense que les quotas seraient plus appropriés.

Donc, avoir un seul gros volume ne serait-il pas mieux ou y a-t-il d'autres avantages liés à LVM que je ne vois pas?

C'est le même débat que les points de montage.

Tout dans /, ou plusieurs montages définis ?

Moi j'aime bien avoir plusieurs montages. Au moins un /boot en dur (le truc qui ne doit pas casser) puis sous LVM un /, un /home, un /var, un /var/log, un /usr etc.

Du coup une mise à jour ne va jamais remplir mon home et si jamais un logiciel fou crée des fichier de logs de plusieurs centaines de Go, ça ne met pas ma machine à genoux. Et je peux encore envoyer des mails ou mettre à jour mes dns (grâce à un /var/spool disponible).

Et maintenant ext4 qui concurrence ZFS d'après ce que j'ai lu quelque part. Est-ce réel? Possibilité de réaliser une tolérance de pannes équivalente au raid5 (i.e. perte d'un disque sans perte de données)? Ou alors c'est juste au niveau du FS?

ZFS, c'est plus l'équivalent de mdadm + LVM + ext4 en un seul logiciel, mais en bien moins customisable et moins complet.

Aussi sous GNU/Linux, les performances ne sont pas top (passage par fuse en userland). Or le fs est souvent un goulot d'étranglement.

[theocrite]

Ok, mais si je suis en Raid5, ajouter un disque à la grappe raid signifie reconstruire le raid de toutes façons. Puis étendre ensuite les "Logical Volumes" ou les "Volume Groups" non?

Oui.

D'abord « grow » le raid, puis augmenter le pv, puis le vg, puis le lv. Augmenter le lv n'est pas nécessaire tout de suite.

Chez moi, une bonne partie du vg n'est pas allouée. Comme ça, dès qu'un lv est proche de son utilisation max, j'ai juste à faire un lvresize.

[HPact]

GNU/Screen permet ça.

Je connais, il y a aussi les combi ALT+F1..F6 en mode texte qui permettent jusqu'à 6 consoles. Mais je suis plus du genre à vouloir avoir les afficahges en même temps à l'écran.

D'ailleurs, y a-t-il un moyen de changer la police d'affichage lorsqu'on est mode console pure (Ubuntu Server 11.04)?

Aussi sous GNU/Linux, les performances ne sont pas top (passage par fuse en userland). Or le fs est souvent un goulot d'étranglement.

Il y a "ZFS on linux" qui existe et qui est différent de "ZFS-fuse". Qu'en est-il pour lui?

[theocrite]

Je connais, il y a aussi les combi ALT+F1..F6 en mode texte qui permettent jusqu'à 6 consoles.

Ou plus. Ça se règle.

Mais je suis plus du genre à vouloir avoir les afficahges en même temps à l'écran.

C'est possible avec screen. Que ce soit dans un seul terminal (avec un split) ou dans plusieurs différents.

D'ailleurs, y a-t-il un moyen de changer la police d'affichage lorsqu'on est mode console pure (Ubuntu Server 11.04)?

Oui, dans grub. vga=xxx dans GRUB1, set gfxmode=xxxx (ou gfxpayload, je ne sais jamais) sous GRUB 2.

Il y a "ZFS on linux" qui existe et qui est différent de "ZFS-fuse". Qu'en est-il pour lui?

Aucune idée. Ça fait un bout de temps que j'ai arrêté d'espérer du côté de ZFS, du coup je ne me tiens plus à jour des nouveautés.

[seboss666]

Du côté de ZFS, la version "kernel module" a vu son actualité bouger ces derniers jours, merci le capitalisme rampant : http://www.phoronix.com/scan.php?page=news_item&px=OTU1NQ Bon au moins, comme c'est open source, le code n'est pas perdu, mais les ressources humaines qui planchaient dessus oui.

Perso, je pense que rester sur l'équipe mdadm/LVM/ext4 est peut-être le plus simple. Et surtout portable : le jour où pour une raison inconnue il ne veut plus démarrer (logciellement parlant), tu peux simplement accéder aux données à partir d'un liveCD. Pas besoin de compiler un module kernel ou la versions FUSE.

[Latios]

Salut.

Pour ZFS il n'est effectivement pas possible d'ajouter un disque à un RAIDZ existant.

ZFS sous Linux c'est pas top pour l'instant. Avec FUSE ça marche plutôt bien, mais je prendrais pas le risque de l'utiliser sur un truc en production. En revanche, ZFS est dispo sous FreeBSD. Si tu veux pas être trop dépaysé par rapport à Linux, il y a une variante de Debian avec le noyau de FreeBSD (Debian GNU/kFreeBSD, debian.org). Sinon il y a bien sûr y'a Solaris, mais depuis le rachat de Sun par Oracle c'est un peu le bordel, entre ce qui est gratuit ou pas, libre ou pas, etc

En revanche FreeBSD est un peu à la bourre sur les versions de ZFS, mais c'est pas forcément un problème.

J'avais trouvé le blog d'un type qui se faisait un serveur perso avec ZFS, c'est une série d'article assez longue et assez complète sur le sujet : http://breden.org.uk/2008/03/02/a-home-fileserver-using-zfs/ (il y a notamment un article sur l'impossibilité d'ajouter un disque à un RAIDZ).

Il y a une présentation des créateurs de ZFS qui explique bien les concepts de ZFS, les problèmes qu'il résout par rapport à l'existant, etc. : http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf

Je prévois aussi de me faire un serveur perso, et j'utiliserai ZFS, sans aucune hésitation :) C'est vraiment super à utiliser une fois qu'on a bien compris comment ça marche

ZFS, c'est plus l'équivalent de mdadm + LVM + ext4 en un seul logiciel, mais en bien moins customisable et moins complet.

En quoi ZFS est moins customisable et moins complet ? Je connais assez peu mdadm et LVM et assez bien ZFS, donc si t'as un ou deux liens qui détaillent la question je suis preneur

[theocrite]

Si tu veux pas être trop dépaysé par rapport à Linux, il y a une variante de Debian avec le noyau de FreeBSD (Debian GNU/kFreeBSD, debian.org).

C'est technologiquement très intéressant, j'aime beaucoup ce projet, mais ce n'est pas vraiment stable.

En quoi ZFS est moins customisable et moins complet ? Je connais assez peu mdadm et LVM et assez bien ZFS, donc si t'as un ou deux liens qui détaillent la question je suis preneur

Pas de liens ni d'exemples précis non.

Juste des souvenirs de discussions (sur linuxfr.org notamment) dans lesquelles on se demandait comment faire la même chose sous ZFS et personne n'a répondu de manière satisfaisantes.

Après ce ne sont pas forcément des fonctionalités très communes. Mais elle existent.

[fabien29200]

Personnellement j'ai préféré faire un RAID 1 à deux disques et payer un stockage en ligne (qui me coute pas plus cher qu'un disque dur supplémentaire).

[HPact]

[...] payer un stockage en ligne (qui me coute pas plus cher qu'un disque dur supplémentaire).

Ca m’intéresse ça aussi pour faire une sauvegarde supplémentaire de mes données les plus importantes (avec chiffrage au cas où)... Chez qui? Quel prix? Quelle capacité max? Quel(s) moyen(s) d'upload?

Quoiqu'il en soit, ce n'est pas un moyen viable de stockage pour moi: mon NAS stocke un ensemble de médias (rip de mes musiques par exemple), et je ne me vois pas y accéder en ligne sans être fibré, et avec les aléas de disponibilités de la connexion internet...

[fabien29200]

J'ai pris un abonnement chez Crashplan. Un PC (mon serveur NAS) en stockage illimité pour 140$ sur 4 ans.

Ca m'a couté un peu plus de 100 euros pour 4 ans, donc pas beaucoup plus cher qu'un disque dur avec cette même durée de vie. Tu peux choisir les répertoires à synchroniser, à quelle heure les synchroniser (il peut s'arrêter la journée et reprendre la nuit ...)

Et les chances que mes deux disques durs lachent et que eux aussi au même moment sont très faibles ...

[16ar]

Je me suis renseigné fortement pour créer une solution de stockage sécurisée et j'ai donc hesité entre zfs et raid+dmcrypt+lvm

Il s'avere que ZFS a des avantages sérieux, mais il a aussi des limitations ennuyeuse (impossible de supprimer un disque d'un pool si j'ai bien compris, et idem, si un pool en raidz est deja créé, pas possible d'ajouter un device a ce raid)

Mais les fonctionnalités de récupération d'erreur de ZFS me faisaient pas mal les yeux doux ( http://www.unixgarden.com/index.php/administration-systeme/zfs-sous-gnulinux et aussi http://hydra.geht.net/tino/howto/zfs/why/ ), alors j'ai cherché un moyen d'avoir une récupération de cluster défectueux avec mdadm. Solution trouvée ici même :

http://www.sjvs.nl/?p=12

Ca me semble bien, par contre, je me demande, si le RAID a écrit des données sur un secteur défectueux (dans l'exemple, le secteur 1261069669) auparavant, et que donc, ces données sont inaccessibles (vu qu'un read renvoit un I/O error) et qu'on arrive a réallouer le secteur ailleurs en forcant une ecriture avec hdparm, le nouveau secteur alloué sera surement vierge, et les données qui étaient inaccessibles sont vraiment perdues. Commment le systeme pourrait se débrouiller ? (dans l'exemple, le raid 5 était formé de /dev/sdb, sdc, sdd, or sdd était deja tombé en panne (donc raid 5 dégradé), et sdb avait des secteurs defectueux)

D'apres moi, ces données sont totalement foutues car il n'y aurait pas le sdd pour assurer la parité, et les données en elle même n'existent plus. J'ai bon ?

Et dans cet exemple, la personne n'a de toute manière pas pu écrire sur ce secteur défectueux, car si il l'avait fait, cela aurait realloué automatiquement ce secteur la et le raid n'aurait jamais considéré sdb comme invalide car il n'aurait pas détecté de I/O error au montage. C'est ça ?

Par contre, est il possible d'avoir des notifications en "temps réel" d'un disque réallouant des secteurs ? Monitoring avec smartctl ? logger le /vaR/log/syslog a la recherche de IO Errors ?

[Latios]

Il s'avere que ZFS a des avantages sérieux, mais il a aussi des limitations ennuyeuse (impossible de supprimer un disque d'un pool si j'ai bien compris, et idem, si un pool en raidz est deja créé, pas possible d'ajouter un device a ce raid)

On peut supprimer un disque d'un mirror (zpool detach) et en ajouter (zpool attach). On peut également toujours remplacer un disque par un autre (auquel cas zfs recopie les données sur le nouveau, et ensuite on peut débrancher l'ancien).

En revanche pour un raidz/raidz2/raidz3, on ne peut pas ajouter de disque, ni en supprimer. Dans ce cas, il faut détruire puis recréer le zpool. Cependant, est-ce que c'est possible d'ajouter/supprimer un disque sur un RAID 5 classique sans tout recréer ?

Ca me semble bien, par contre, je me demande, si le RAID a écrit des données sur un secteur défectueux (dans l'exemple, le secteur 1261069669) auparavant, et que donc, ces données sont inaccessibles (vu qu'un read renvoit un I/O error) et qu'on arrive a réallouer le secteur ailleurs en forcant une ecriture avec hdparm, le nouveau secteur alloué sera surement vierge, et les données qui étaient inaccessibles sont vraiment perdues. Commment le systeme pourrait se débrouiller ? (dans l'exemple, le raid 5 était formé de /dev/sdb, sdc, sdd, or sdd était deja tombé en panne (donc raid 5 dégradé), et sdb avait des secteurs defectueux)

D'apres moi, ces données sont totalement foutues car il n'y aurait pas le sdd pour assurer la parité, et les données en elle même n'existent plus. J'ai bon ?

Oui (sauf erreur de ma part). Dans ce cas de figure, il faut restaurer les données perdues depuis une sauvegarde...

[HPact]

Il s'avere que ZFS a des avantages sérieux, mais il a aussi des limitations ennuyeuse (impossible de supprimer un disque d'un pool si j'ai bien compris, et idem, si un pool en raidz est deja créé, pas possible d'ajouter un device a ce raid)

On peut supprimer un disque d'un mirror (zpool detach) et en ajouter (zpool attach). On peut également toujours remplacer un disque par un autre (auquel cas zfs recopie les données sur le nouveau, et ensuite on peut débrancher l'ancien).

En revanche pour un raidz/raidz2/raidz3, on ne peut pas ajouter de disque, ni en supprimer. Dans ce cas, il faut détruire puis recréer le zpool. Cependant, est-ce que c'est possible d'ajouter/supprimer un disque sur un RAID 5 classique sans tout recréer ?

Sur un raid5, il suffit de l'ajouter avec MDADM et automatiquement, il y aura reconstruction du raid pour repartir les données sur X+1 disques, sans pertes de données.

[NoarZ]

Sur un raid5, il suffit de l'ajouter avec MDADM et automatiquement, il y aura reconstruction du raid pour repartir les données sur X+1 disques, sans pertes de données.

Toutes facons le RAID logiciel c est du gros caca en barre (et pas le soft du chipset integré a la CM non plus), rien ne vaut une vraie carte digne de ce nom, avec batterie si possible

Il devrait faire un raid 1+0 avec tout ses durs (possible avec une carte Raid)

[16ar]

n).

En revanche pour un raidz/raidz2/raidz3, on ne peut pas ajouter de disque, ni en supprimer. Dans ce cas, il faut détruire puis recréer le zpool.

détruire puis recréer un zpool, ca implique bien perte totale de toutes les données, non ?

moitié HS :

Les disques durs USB, c'est vraiment merdoyeux j'ai l'impression. J'ai 5 disques durs maxtor en pata/sata de maximum 300 Go qui ont pour certains un âge vénérable (8 ans, je pense) en interne, et 0 ont des secteurs defectueux en attente de reallocation ou autre.

Et là, j'ai 2 disque durs (WD) externe (2.5 et 3.5) qui ont maximum 3 ans, et les 2 ont des secteurs defectueux en attente de reallocation dont 1 qui en a 10 ! Evidemment, c'est celui qui en a 10 qui se fait le moins balader (c'est le 3.5"). Il a d'ailleurs nettement moins bougé que les disques qui ont 8 ans (qui ont fait plusieurs allers retour Paris-Strasbourg en voiture dans la tour, un voyage en Mayenne, bref)

Alors soit c'est Western Digital qui est moins bon, mais ca m'étonnerait, il me semble que c'est plutot du bon matos, soit l'usb aurait tendance a corrompre plus facilement des disques durs ? (pourquoi ? comment ?)

[RaphAstronome]

soit l'usb aurait tendance a corrompre plus facilement des disques durs ? (pourquoi ? comment ?)

Les boitiers USB ont tendance à être de mauvaise qualité et donc à faire des erreurs mais cela devrait ce limiter à des corruptions logiciels pas des secteurs défectueux.

L'alimentation utilisé peut par contre entrainer des dommages.

Sinon pour le RAID soft il permet aussi de ne pas dépendre du contrôleur ce qui est préférable si ce dernier tombe en panne. En tout cas pour ce genre de carte il faut vraiment de la qualité car les cartes à bas cout c'est pas terrible. Quant aux batteries elles deviennent inefficaces rapidement et là bonjour les dégâts en cas de coupure, mieux vaut un onduleur.

[Latios]

n).

En revanche pour un raidz/raidz2/raidz3, on ne peut pas ajouter de disque, ni en supprimer. Dans ce cas, il faut détruire puis recréer le zpool.

détruire puis recréer un zpool, ca implique bien perte totale de toutes les données, non ?

Tout à fait.

En revanche, ce qu'il est possible de faire c'est d'ajouter des top-level vdev à un pool, en particulier un raidz. Mais le résultat n'est pas le même qu'ajouter un disque à un raidz existant (ce qui n'est pas possible donc).

Alors soit c'est Western Digital qui est moins bon, mais ca m'étonnerait, il me semble que c'est plutot du bon matos, soit l'usb aurait tendance a corrompre plus facilement des disques durs ? (pourquoi ? comment ?)

La plupart de mes disques sont des WD, et ils tournent tous toujours comme une horloge (certains on près de 10 ans ) avec 0 secteurs défectueux, y compris les externes USB

[16ar]

Pour information, ca fait quelques années que les disques durs possèdent des secteurs de 4k, qui, pour différentes raisons sont mieux. Seulement, suffit qu'un constructeur (western digitial par exemple) indique que ses disques sont toujours en 512 octet par secteur pour que le système s'optimise sur la mauvaise valeur (tout ca pour une retro compatibilité avec windows xp ....). Or, un mauvais alignement se paye par des performances mauvaise, voire, dans mon cas, très mauvaise.

Ma config : RAID 5 de 3xWD2000EARS (2To) + dm-crypt + lvm2 + ext4

Faire un raid5 pareil sous linux est assez aisé... Par contre, faire le même raid performant c'est nettement moins facile, et si on rajoute les problemes d'alignement, c'est plus problématique.

Bref, quand j'aurais le temps, je ferais un tuto, ou, déja, je copierais ma configuration. Pour l'alignement, il faut retenir que chaque couche doit etre alignée, et que certaines couches utilisant des metadata peuvent décaler les sous couches suivantes.

Ensuite, pour le raid, il faut optimiser avec les tailles de chunk du raid lui meme, puis ensuite les taille de stripe, stride et stripe_width sur les autres couches (jusqu'au FS).

Je suis passé d'un RAID 5 qui faisait du 25 Mo/sec en écriture (sur un raid completement fonctionnel : 3 disque sur 3) à du RAID5 qui tourne a 65Mo/sec en écriture (sur un raid dégradé avec seulement 2 disques sur 3). Ouais, ca change beaucoup la donne ....

[HPact]

Ma config : RAID 5 de 3xWD2000EARS (2To) + dm-crypt + lvm2 + ext4

Faire un raid5 pareil sous linux est assez aisé... Par contre, faire le même raid performant c'est nettement moins facile, et si on rajoute les problemes d'alignement, c'est plus problématique.

Bref, quand j'aurais le temps, je ferais un tuto, ou, déja, je copierais ma configuration. Pour l'alignement, il faut retenir que chaque couche doit etre alignée, et que certaines couches utilisant des metadata peuvent décaler les sous couches suivantes.

Ensuite, pour le raid, il faut optimiser avec les tailles de chunk du raid lui meme, puis ensuite les taille de stripe, stride et stripe_width sur les autres couches (jusqu'au FS).

Je suis passé d'un RAID 5 qui faisait du 25 Mo/sec en écriture (sur un raid completement fonctionnel : 3 disque sur 3) à du RAID5 qui tourne a 65Mo/sec en écriture (sur un raid dégradé avec seulement 2 disques sur 3). Ouais, ca change beaucoup la donne ....

Je suis preneur d'un tuto pour expliquer clairement ce que sont ces paramètres et leurs interactions... Je m'oriente vers un raid5 de 7 DDs, et avoir de bonnes perfs m’intéresse.

[16ar]

J'ai pas encore le temps de faire le tuto, mais je peux copier mes commandes et expliquer 1 par 1 ce que fait chaque param

Tout d'abord, mes partitions étaient toutes alignées, donc formatée avec fdisk -u (pour afficher par LBA et non pas par cylindre/tete/secteur). Le début de la partition était un multiple de 8 secteurs et la longueur de la partition aussi.

Explication : le secteur est une unité physique du disque dur qui permet de stocker des données. Quand un disque écrira, il écrira au minimum sur 1 secteur. Ca marche de cette manière physiquement. Pendant des années, la taille du secteur était de 512 octets. Après différentes réflexions d'ingénierie, il s'avère que des secteurs de 4096 octets sont plus efficaces car ils réduisent la taille des ECC pour chaque secteur (ECC sont des calcul de vérifications pour éviter des corruptions de données en gros) et d'autres avantages. Seulement, certains OS (Windows XP et < ) ne comprennent pas les secteurs de 4096. Pour lui, un secteur vaut 512, point barre.

Donc les gens ont réfléchi à des astuces pour faire croire qu'un secteur vaut 512 pour le systeme, mais que derriere, le disque continue à traiter des secteurs de 4096 (vu qu'il ne sait pas faire autrement sur ces nouveaux modeles de toute manière). D'ou la notion de taille de secteur physique et taille de secteur logique. Le systeme qui sait gérer les secteurs logique, allait gérer comme il fallait, sinon il se basait sur la taille des secteurs physique, comme avant.

Donc un disque avec des secteurs physiques de 4096 allait indique qu'il avait une taille de secteur logique de 512 et une taille de secteur physique de 4096. Donc le systeme qui comprends les notions de taille de secteur logique et taille de secteur physique va utiliser 4096, et le systeme has been utilisera la taille de secteur logique qui lui indique 512(qui pour lui, il le comprendra comme une taille de secteur tout court vu qu'il n'a pas cette notion de taille de secteur logique/physique).

Sauf que Western Digital a eu la bonne idée de mettre les tailles de secteur logique et physique a 512, quand bien meme le disque ecrivait sur des secteurs de 4096. Donc un systeme qui connait les notions de secteur logique/physique (comme linux) se faisait avoir et imaginait que le disque utilisait des secteurs de 512.

Donc pour lui, aucun problème d'écrire une partition entre le secteur 6 et le secteur 128. sauf que le secteur 6 (de 512 octets) se retrouve en fait au 3/4 du secteur 1 (de 4096). Mettons par dessus un systeme de fichier ext4 avec 4096 octets de taille de block ((donc le systeme de fichier écrira sur 4096 octets au minimum) quand on écrira un fichier texte de 12 octets, le file system va écrire ça sur le premier block du filesystem. Mais sur le disque dur, le premier block du filesystem correspond aux secteurs de 512 octets entre le secteur 6 et le secteur 14 (14-6=8, 8 * 512 = 4096). Or le secteur 6 (secteur physique mal renseigné de 512, toujours, merci western digital) correspond au secteur 1 physique de 4096. Et le secteur 14 (de 512) correspond au secteur 2 physique. Donc pour chaque ecriture sur le file system, le disque dur va écrire en réalité sur 2 secteurs car il y'a un décalage entre la partition et le secteurs physiques du disque dur.

Pour que ce décalage soit annulé, il faut aligner les partitions, et donc il faut que le début d'une partition soit aligné sur un numéro secteur (de 512 octets) multiple de 8 (puisque 4096/512 = . Et idem pour la taille de la partition, car sinon, on décale les partitions suivantes, et ainsi de suite.

Mais évidement, ce problème ne s'arrête pas la, la je parlais d'1 disque dur, 1 partition, 1 file system. Maintenant, on rajoute le fait qu'on empile des couches de block device avec les device mapper et autre raid. Suivant l'implémentation de chaque device mapper, il se peut qu'il mette des métadonnées en début de son block device (le cas pour lvm), or celui ci décale le début des données sur ce block device et peut recréer un désalignement... Il faut connaitre comment chaque outil fonctionne pour éviter un desalignement au fur et a mesure de la superposition des couches... (encore merci western digital)

sudo mdadm --create /dev/md0 -c 128 -l 5 -n 3 /dev/sdc1 /dev/sdd1 missing

--create /dev/md0 : on crée le raid sur le nom de block device /dev/md0

-c 128 : chunk de 128ko, c'est ce qui donne a priori les meilleurs performances dans plusieurs tests. Je crois que ca correspond à la taille de chaque unité de stockage sur chaque disque. Le raid écrit 128k sur un disque, puis 128k sur un autre, ca fait la bande, puis 128k de parité, et ensuite il écrit une nouvelle bande avec 128k sur le premier disque, puis le suivant puis parité (ca c'est explication simpliste, l'algorithme de RAID5 de linux par défaut ne fonctionne pas vraiment, mais c'est l'idée)

-l 5 : level 5 = RAID5

-n 3 : number 3, nombre de disque du RAID

/dev/sdc1 /dev/sdd1 missing : on liste les partitions qui vont créer cet RAID. Pour mon besoin, je créais un RAID5 avec 3 disques, seulement, 1 des disque contenait des données que je voulais sauvegarder sur le RAID ensuite, donc j'ai créé un RAID5 dégradé (car il manquait le disque de parité. En indiquant avec le mot clé missing que le disque allait venir plus tard) sur lequel j'ai copié les données du 3eme disque, et ensuite j'ai rajouté ce 3eme disque dans le RAID.

sudo cryptsetup -c aes-cbc-essiv:sha256 -s 128 -h sha256 --align-payload=512 luksFormat /dev/md0

-c aes-cbc-essiv:sha256 : On chiffre la partition avec de l'AES

-s 128 : size 128, la taille de clé de chiffrement en bit (ici, AES 128 bit)

-h sha256 : hash sha256, l'algo de hash sera du sha256

--align-payload=512 : payload alignment de 512k. Ca permet d'optimiser les performances de son chiffrement sur le RAID en utilisant la longueur d'une bande du RAID sous-jacent comme unité d'écriture. Là, je me suis foiré, car à priori, ma bande fait 256k (2 chunk de 128k, le dernier chunk de parité n'était pas compté dans la bande). J'aurais du mettre 256 ici si j'ai bien tout compris

luksFormat /dev/md0 : on formate le raid /dev/md0 avec le format LUKS.

sudo cryptsetup luksOpen /dev/md0 raidDechiffre

luksOpen /dev/md0 raidDechiffre : On ouvre notre RAID chiffré /dev/md0 avec LUKS en créant un block device raidDechiffre sur lequel on pourra faire toutes nos opérations

sudo pvcreate --metadatasize 250k /dev/mapper/raidDechiffre

--metadatasize 250k : on créé notre Physical Volume de LVM avec un metadatasize de 250k. Ici, typiquement, c'est une bidouille pour de l'alignement. On marque 250k, et le systeme va enregistrer le prochain block valide qui sera 256k. Même Ted Tso n'avait pas tout compris, mais ca permet d'aligner le début des données stockées sur le LVM avec un multiple de 4096 et donc de respecter l'alignement du disque dur.

/dev/mapper/raidDechiffre : le chemin du block device raid déchiffré

sudo vgcreate monVolumeGroup /dev/mapper/raidDechiffre

Je créé un volume group nommé monVolumeGroup qui utilisera /dev/mapper/raidDechiffre comme physical volume LVM

sudo lvcreate -L 3t -n "monLogicalGroup" monVolumeGroup

-n "monLogicalGroup" : Je créé un logical volume nommé monLogicalGroup dans mon volume groupe monVolumeGroup

-L 3t : je créé ce volume logique de 3To. (je garde de la place en rab pour faire des snapshots et peut etre un autre logical volume avec un autre usage.

sudo mkfs.ext4 -b 4096 -T largefile4 -m 0 -E stride=32,stripe_width=64 /dev/mapper/monVolumeGroup-monLogicalGroup

-b 4096 : taille d'un bloc de systeme de fichier en octet.

-T largefile4 : on optimise le système de fichier pour stocker des grosses données en majorité

-m 0 : on réserve 0% de block pour le super user, cette partition n'est pas une partition systeme qui pourrait crasher le systeme en cas d'un syslog s'écrivant dessus lorsqu'il est plein a 100%.

-E stride=32,stripe_width=64 : Options d'optimisation du filesystem avec un RAID fonctionnant en stripping (RAID0, RAID5) sous jacent. stride=32, cela correspond à (chunk/taille d'un bloc). Dans mon cas 128k/4k=32. stripe_width=64 correspond à (stride*(nombre de disques du raid - 1)). Pour moi (32*(3-1))=64. Nombre de disque du raid - 1 car le dernier disque sert de parité. Avec ces paramètres, le filesysteme va essayer d'écrire par 64 blocs a la fois pour que la charge d'écriture des disques en raid soit bien répartie sur la longueur de la bande)

/dev/mapper/monVolumeGroup-monLogicalGroup : le nom du périphérique de bloc de LVM

J'espère que j'ai été assez clair :)

Mes lectures/références :

http://alephnull.com/benchmarks/sata2009/

http://pegasus45.free.fr/index.php?title=RAID:_performances_des_diff%C3%A9rents_niveaux_du_RAID#RAID_5

http://pegasus45.free.fr/index.php?title=Debian_5/RAID_5:_chunk,_stride_et_stripe-width

http://fr.wikipedia.org/wiki/Cylindre/T%C3%AAte/Secteur

+ d'autres liens dont j'ai perdu l'adresse mais qui m'ont bien aidé pour la compréhension de l'alignement, des cylindres/LBA etc

[fabien29200]

Et si on a pas de disque WD, est-ce que ça change quelque chose ?

[16ar]

Ca dépend si le constructeur de disque a bien implémenté ses Physical_Sector_Size et ses Logical_Sector_Size.

Si c'est un bon qui veut de la rétrocompatibilité, ca devrait donner PSS=4096 et LSS=512. Si c'est un WD, ca donne PSS=512 et LSS=512, alors que la vraie taille des secteur physique est de 4096.

Si le systeme peut savoir que le PSS vaut 4096, normalement, il devrait aligner tout seul.

Mais apres, je ne suis pas sur, les seuls disque avec 4k de secteur que j'ai, ce sont des WD...

En tout cas, du coup, normalement, tous les utilitaires devraient bien se débrouiller, donc pas besoin de tuner le metadatasize du pvcreate etc...