Après moultes questions autour du stockage et du raid logiciel sous Linux, je me suis enfin lancé ce week-end après avoir acheté 3 disques durs de 500 Go.
1 partition /swap de 500 Mo sur chacun des disques
1 partition /boot en Raid 1 (/dev/md0) de 150 Mo sur les trois disques
1 volume groupe (datavg) en Raid 5 (/dev/md1) de 50 Go sur les trois disques et je tiens à ce que datavg prenne toujours 100% du volume de /dev/md1
Dans datavg, j’ai quelques filesystems dont /, /tmp et /var.
Vous allez me dire “hey !!! il te reste presque 450 Go inutilisables ?!? pourquoi ton raid 5 il ne fait pas tout ton disque ??”… vivi je sais et j’ai trois (bonnes ?) raisons d’avoir fait ça… enfin, ces raisons sont basées sur des suppositions alors ça vaut ce que ça vaut.
Peut-être qu’un jour je voudrai étendre mon swap ou mon /boot, si je n’ai plus du tout d’espace, je suis cuit
J’ai vu que la reconstruction d’un raid 5 de 50 Go pouvait durer longtemps… je me dis qu’il n’est pas nécessaire d’avoir un raid immense si au final je n’en utilise que 10%, le gain de temps en vaut surement la chandelle
Je voulais faire des tests d’extension de Raid, volume group et filesystem, et j’ai bien fait car ça n’a pas marché.
En effet, mon système fonctionnait à merveille sous la dernière debian (lenny c’est ça ?) en 64 bits sans interface graphique. J’ai voulu étendre mon raid 5 et le passer à 80 Go en tapant la commande (de mémoire) :
Je vérifie l’avancement
Extraordinaire !!! c’est déjà fait
Pourtant, c’est le drame
Des dossiers ne sont plus accessibles, vgdisplay me sort une erreur d’i/o, les commandes reboot et shutdown ne veulent rien savoir à cause d’un problème d’i/o bref… je me retrouve dans la même situation que ce pauvre gars en 2005 : linuxquestions.org/questions … ay-329413/
Vu le soutien qu’il a obtenu, je désespère vite et me décide à formater mes trois disques avec un bon vieu
Entre 6 et 8h pour chacun des disques, autant dire que je retente l’installation ce week-end.
Les questions ci-dessous me permettront de scripter les quelques actions que je serai amené à faire pour faire évoluer mon système. Je serai d’ailleurs ravi de vous les faire partager. Par exemple, je préfère largement augmenter un raid que lui fixer une valeur (en gros, je préfère taper +1Gb que 80000000, je trouve qu’il y a moins de chance de faire une grosse bétise genre alloué moins d’espace qu’il n’y en a actuellement).
Ai-je mal tapé la commande mdadm --grow ?
Vous remerciant par avance pour vos idées/conseils/suggestions/…,
Pourquoi n’avoir pas mis le swap en RAID 5 (voire en LVM sur le RAID) ? En cas de défaillance d’un disque, tu perds le swap et les applications qui l’utilisaient. Pas terrible pour la disponibilité qu’est censé apporter le RAID.
Tu as bien agrandi les trois partitions RAID avant d’agrandir l’ensemble RAID ?
LVM permet d’éviter de redimenensionner les partitions, pourquoi s’en priver ? Tu aurais pu créer un nouvel ensemble RAID, y mettre un nouveau PV LVM et l’ajouter au VG LVM existant.
D’après la page de manuel de mdadm, l’option pour spécifier la taille est -z, pas -s. Et après avoir agrandi les partitions il aurait dû suffire d’indiquer -z max.
Merci pour ces pistes, je vais tenter d’apporter des précisions
J’ai appliqué le tuto doc.ubuntu-fr.org/tutoriel/installation_raid_lvm où le /swap est à part mais en effet, je n’avais pas pensé à cette éventualité et je tiendrai compte lors de la prochaine installation.
Non, j’ai juste agrandi /dev/md1, d’où mon erreur certainement, j’ai utilisé cette page : wiki.depuille.net/index.php/LVM_Linux
et notamment cette ligne
mdadm --grow -z /dev/mdx
(en effet, j’avais bien mis -z, j’ai tapé ce texte de mémoire)
Je ne vois nulle part qu’il faut d’abord agrandir les partitions raids… tu as une doc là-dessus ? une commande pour le faire ?
C’est une bonne idée mais je me pose des questions, ça voudrait dire que je vais créer autant de /dev/mdx que le nombre de fois que je vais agrandir tout ça ? Ca risque de faire très fouilli assez rapidement.
Non je n’ai pas de doc, mais la logique élémentaire me dicte que pour agrandir un contenu (le volume correspondant à l’ensemble RAID) il faut d’abord agrandir le contenant (les partitions RAID).
Halte !
Sans l’avoir utilisée, j’ai l’impression que la commande --grow sert à augmenter la taille d’un ensemble RAID mais pas des volumes (disques/partitions) RAID sous-jacents. J’explique. Par défaut, le superbloc d’une partition RAID est à la fin de celle-ci. Mais si on agrandit la partition avec fdisk ou équivalent, alors le superbloc n’est plus à la fin. D’autre part, il me semble que le noyau ne peut pas recharger la table de partition d’un disque contenant des partitions RAID actives, par conséquent il ne sait pas que la partition a été agrandie à moins de redémarrer. Mais si on redémarre à ce moment, le système risque de ne pas retrouver le superbloc qui est quelque part au milieu de la partition et ne pas pouvoir assembler la partition.
Bref, je trouve que c’est casse-gueule.
Une méthode sûre serait d’agrandir chaque partition RAID une par une pendant qu’elle est inactive (sortie de l’ensemble RAID), puis de la réintégrer. Ensuite quand toutes les partitions seront agrandies, il sera possibles d’agrandir l’ensemble avec --grow -z max. Mais cela implique la reconstruction des partitions, c’est lourd.
oulàlà, en effet, ça me parait être un sacré chantier
Le week-end prochain, après réinstallation complète de mon système, je pensai tester en créant une nouvelle partition /dev/md2 en Raid 5 de 1 Go seulement, y poser un petit fichier texte par exemple et faire mumuse avec. L’agrandir, étendre le vg, étendre le ou les lv, … Ainsi, si je la casse, je n’aurai pas tout à refaire.
Faut dire aussi qu’après avoir bien cassé mon raid le week-end dernier, quand j’ai voulu réinstaller debian il me dit qu’il ne trouve absolument aucun disque alors qu’ils fonctionnent parfaitement biens tous les trois, à moins de ne vraiment pas avoir de chance lol. Surtout que mon coté parano m’a fait commandé 3 disques de caractéristiques identiques mais de marques différentes.
Je me pose ces questions aujourd’hui car je compte bien, dans 2 ou 3 ans, échanger mes actuels disques par du 1 ou 2 To. Et là, évidemment, j’aurai besoin d’étendre mon raid une fois que je le pourrai. Certes les logiciels seront meilleurs mais je préfère me casser les dents aujourd’hui et blinder un éventuel script d’extension que de pleurer pour avoir à tout réinstaller plus tard.
Titillé par le sujet, j’ai testé et effectivement mes craintes étaient fondées.
Après agrandissement d’une partition RAID appartenant à un ensemble actif, impossible de recharger la table de partition du disque pour que la nouvelle taille soit prise en compte puisque des partitions sont en cours d’utilisation.
Après arrêt de l’ensemble RAID, j’ai pu recharger la table de partition. Mais mdadm -E ne reconnaît plus le superbloc sur la partition RAID agrandie, comme prévu.
Je redémarre l’ensemble RAID qui s’assemble sans la partition agrandie, normal. Je réintègre la partition agrandie, qui doit se resynchroniser.
J’agrandis l’ensemble RAID avec mdadm --grow -z max. Ça marche apparemment (et ça prend un certain temps à synchroniser).
J’agrandis à chaud le système de fichier ext3 monté qui est dessus avec resize2fs. Ça marche apparemment.
Ah, un détail : la partition RAID agrandie avait été créée initialement avec une taille inférieure aux deux autres, ce qui avait conditionné la taille de l’ensemble RAID 5.
Donc pour agrandir toutes les partitions et finalement l’ensemble, il faut faire une par une. Idem en cas de changement de disques.
C’est parfait, mon df-h indique 183 Mo disponibles et mon fichier test.txt est lisible.
[size=150]Le Test à Chaud[/size]
Je refais la même chose en passant cette fois à 200 Mo chacune des partitions (soit 400 Mo dispos pour le raid5) mais je veux que mon filesystem reste disponible pendant toute la durée de la manipulation (pas de umount ni reboot).
Grrrrr, la taille n’a pas changé… je suis certain qu’en rebootant et en refaisant un mdadm --create, ça fonctionnera pourtant.
Je n’ai aucun message d’erreur et je ne sais pas dans quel log regarder. On dirait que mdadm ne sait pas que les partitions ont été augmentées. Comment je peux le lui dire ??
En gros, je met le disque en erreur, je l’enlève du raid et je le remet au raid mais ça n’a rien donné non plus. J’espérai qu’il trouve la nouvelle taille en faisant ça.
Je trouve aussi étonnant que le cat /proc/mdstat soit à chaque fois quasi instantané.
Bref, il y forcément quelque chose que je fais mal. Je peux néanmoins dormir tranquille car je sais maintenant comment agrandir mon raid sans perdre mes données mais comme je suis grourmand, j’en veux plus…
Quelqu’un a-t-il déjà augmenter son volume raid à chaud sans déconnecter ses utilisateurs ? Et si oui, comment ?
Dans le test à froid, tu as “agrandi” l’ensemble RAID 5 en le recréant entièrement, et ça n’a pas altéré le système de fichiers ? J’aurais éventuellement osé faire ainsi avec du RAID miroir (RAID 1), mais pas avec du RAID en bandes comme le RAID 5 car la structure des bandes aurait pu être modifiée par le changement de taille.
Dans le test à chaud, j’ai déjà expliqué ce qui se passe dans un précédent message : le noyau refuse de recharger la table de partition modifiée d’un disque dont des partitions sont en cours d’utilisation (système de fichier monté, volume RAID assemblé, LVM actif, swap utilisé…). Tu peux le constater dans /proc/partitions qui indique la taille des volumes telle que vue par le noyau.
La seule solution que je vois consiste à sortir toutes les partitions d’un disque de leurs ensembles RAID respectifs, pour pouvoir recharger la table de partition de celui-ci, puis de les réintégrer avec leur nouvelle taille, et de refaire la même chose avec les autres disques. Ensuite, il sera possible d’agrandir les volumes RAID. Evidemment cela implique de resynchroniser toutes les partitions réintégrées à chaque fois, donc ce n’est pas très efficace.
Je pense en effet qu’il n’y a pas d’autres solutions… je n’ose pas imaginer le temps que ça va prendre lorsque mes disques vont commencer à bien se remplir, aujourd’hui par exemple, 6 minutes pour 3 partitions de 40 Go en RAID 5
Je fais le test de suite à ce propos.
Au boulot on utilise un NAS pour serveur AIX. Il est possible d’agrandir à chaud ce genre de choses. Je ne sais pas exactement comment ça fonctionne mais je sais qu’on créé des LUN sur le NAS et c’est sur ces LUN qu’on applique un Raid. Ensuite, on déclare le nouveau LUN sur notre serveur AIX et il n’y a plus qu’à étendre les volumes groupe et volumes logiques existants.
C’est ce genre de fonctionnalité que j’espérai retrouver.
Merci Pascal pour le temps que tu y a consacré, ça m’a permis de bien dégrossir le sujet et mieux comprendre comment tout ces machins fonctionnent
Un LUN est une sorte de disque virtuel. C’est un peu l’équivalent d’un LV avec LVM.
D’ailleurs si je voulais une fonctionnalité équivalente avec des disques internes, j’utiliserais LVM sur un gros ensemble RAID plutôt qu’une multitude d’ensembles RAID.
Il y a hélas quelque chose de très archaïque dans la gestion à chaud des partitions par Linux. LVM permet de s’en affranchir.
[/quote]
