RAID et Debian, modification prévue mais

Tags: #<Tag:0x00007f63f4acb1d8>

Bonjour à tous,

Allez une petite question tirée par les cheveux en ce jeudi ensoleillé :smiley:

Quand j’ai installé mon serveur il y a quelques mois, j’ai créé un RAID logiciel pendant l’installation du système.
Le truc, c’est que j’ai été très très généreux avec la partition système comme vous pouvez le voir dans ce document :

La partition système est la MD0
MD1 = Cloud
MD2 = SWAP
MD3 = Sauvegarde

Mon problème aujourd’hui, c’est que MD0 n’occupe que 10Go des 186 alloué et j’ai des soucis d’espace saturé sur MD3

Voila ma question : est ce qu’il est possible de modifier la partition système MD0 facilement et de réattribuer l’espace libéré sur MD3 (ou MD1 et MD3) ? et ceux, sans planter le système :smile:

J’avais pensé désactiver le RAID MD0 et MD3. Modifier les partitions sur chacun des disques et remonter le RAID derrière.
Ce qui me fait peur, c’est que l’espace libéré de la partition système et que je souhaite affecter à la partition sauvegarde sera séparée par la partition cloud (qui elle sera toujours monté en MD1) . Et je ne sais pas si c’est faisable.

Après il y aussi la crainte de la perte de données. Mon serveur tourne depuis des mois. Et cela m’a pris pas mal d’heures pour le mettre en place et si la modification se croute en plein milieu avec pertes de données, je risque de l’avoir mauvaise.

Alors d’après vous ? C’est plus du genre “touche pas à ça petit con” ou “t’inquiète, c’est gérable” ? :smile:

Salut,
Je sais qu’il y a une commande “grow” dans mdadm pour agrandir, mais je pense qu’il n’y a rien pour réduire.

Moi je pense que l’idée serait de :
-Sauvegarder le contenu de ta partition système.
-Supprimer la partition
-La recréer à la taille souhaitée
-Recopier les données dessus sur la nouvelle partition système
-Agrandir la partition raid (et son filesystem) souhaitée avec le volume libéré restant.

Par contre il va falloir faire attention au grub.

Evidemment, tu peux faire ces manipulations sur 1 seul disque comme ça si ça ne fonctionne pas t’as juste à le réintégrer dans l’ancien raid si tu vois ce que je veux dire :slight_smile:

Enfin pour moi c’est faisable, mais ya un peu de boulot qd même.

Une sauvegarde vraiment safe ne devrais pas être stocker sur les disque de ton serveur mais sur un espace distant, afin de te prémunir d’un problème de disque, j’ai déjà vue 3 disque rendre l’âme sur une même grappe d’un raid 10, et on n’a finit marron sans pouvoir récupérer autre chose que des miettes.

Pour moi le problème devrais être pris autrement, effectue un e sauvegarde externe de tes données et reprends à zéro ton installation.

Le système si tu ne stocke rien dans /var devrais sans doute être taillé entre 12 à 15 Go.
La swap devrait être placé en tout premier ou en dernier (c’est rarement une partition que l’on retouche, de plus sa taille me semble tout aussi démesurée que l’est ton système.
La sauvegarde comme expliquée auparavant ne devrais être qu’un espace de confort pour rétablir rapidement certaines données (à l’image de la possibilité de faire une image instantanée, il est inutile de garder plus de deux sauvegardes).

Et réfléchir à une véritable solution de sauvegarde externe, avec pourquoi pas une solution compatible à un baremetal (très pratique pour réinstaller de zéro depuis ta sauvegarde en cas de crash importants).

D’après la page de manuel de mdadm, le mode “grow” permet aussi de réduire la taille d’un ensemble RAID. Je ne l’ai jamais fait et ne peut donc fournir aucune aide. Même si c’est possible, il faudra ensuite déplacer les partitions situées les partitions à réduire et les partitions à agrandir.

Le redimensionnement aurait été beaucoup plus simple avec des volumes logiques LVM par dessus un unique ensemble RAID au lieu de plusieurs ensembles RAID. Mais ce n’est possible que si tous les disques sont assez grands, ce qui n’est peut-être pas le cas ici et expliquerait que md3 n’utilise pas de partition sur sda.

Je suis d’accord, mais principalement pour une autre raison que celle que tu évoques ensuite :

Je suppose que tu voulais dire “RAID 1”. La défaillance d’une seul disque en RAID 0 suffit à causer la perte de toutes les données.

A mon avis il y a un risque bien plus important que la défaillance de tous les disques : la perte de données par effacement accidentel, corruption, malveillance… Tout le monde a probablement entendu parler de l’histoire du type qui prétendait avoir perdu toutes ses données suite à une fausse manip (qui n’était en fait qu’un canular).

C’était un raid 10, c’est corrigé, et effectivement les risques lié à une compromission sont bien plus grave surtout si les sauvegarde sont accessibles.

Hello tout le monde,

Tout d’abord, merci pour vos conseils (et désolé pour la réponse tardive)
J’ai bien lu tout ce que vous m’avez écrit et je me rends compte que je n’ai pas forcément fait tout bien comme il le faut. Première installation d’un serveur perso à la maison (sous debian) et je me suis aidé de nombreux tutos pour le mettre en place.

J’ai cherché quelle était la meilleure solution à appliquer… et… je suis un peu perdu :smile:

Celle qui pourrait cadrer avec vos conseils, c’est de changer mon matériel. J’entends par la de séparer mes serveurs. Une machine qui s’occuperait de toute la partie mail, owncloud etc et une autre qui ferait office de NAS… bon après j’ai vu les prix des NAS et c’est vachement pas donné si je veux un truc qui tienne la route.

En faisant une recherche sur google sur comment monter son propre NAS maison, je suis tombé sur les microserver HP

http://www8.hp.com/fr/fr/products/proliant-servers/product-detail.html?oid=5379860

saisir ici la description du lien

Faudrait que j’en trouve 2 pas trop chers (prix varient entre 150 et 250€ avec ou sans DD)

Cette solution serait top mais ca voudrait dire que je devrais réinstaller tout le serveur… et ca me fait aussi peur que le redimensionnement des répartitions car ca risque d’être long.

Bon j’ai déjà les fichiers de config, c’est une bonne chose vous allez me dire :slight_smile:
Et puis j’ai l’expérience des “choses à ne pas faire”

Autre avantage de ce genre de système, le bruit serait en nette baisse. Aujourd’hui, mon serveur est dans une tour un peu bruyante + alim idem. Pour la consommation électrique, je ne sais pas par contre. Je passerai d’une alim 500w à 2 x 150w…

Ce post m’ouvre à d’autres perspectives auxquelles je n’avais pas pensé jusqu’ici.

A votre avis ?

A propos du MicroServer HP :
il y a plusieurs modèles. J’en ai un avec (dans /proc/cpuinfo )

model name      : Intel(R) Pentium(R) CPU G2020T @ 2.50GHz

Je m’en sers comme système d’archivage, c-a-d simplement piloter des disques enfichés dans un boîtier StarTech avec une connexion eSata.

Suite à votre message, je viens de faire la mise à jour de la Debian de 8.3 à 8.4.

Pour l’instant je n’ai que deux disques enfichés dans le StaTech
pour deux douzaines d’études environ.

fp2x@drmas:~$ sudo vgs
  VG         #PV #LV #SN Attr   VSize   VFree
  archive_vg   2  23   0 wz--n-   7,28t   3,17t
  system_vg    1   2   0 wz--n- 931,51g 621,51g
fp2x@drmas:~$ sudo pvs
  PV         VG         Fmt  Attr PSize   PFree
  /dev/sdb   system_vg  lvm2 a--  931,51g 621,51g
  /dev/sdc   archive_vg lvm2 a--    3,64t   2,08t
  /dev/sdd   archive_vg lvm2 a--    3,64t   1,09t
fp2x@drmas:~$

J’ai fait simple : Quand on veut archiver on calcule au plus juste la taille nécessaire. On crée un volume logique dans le VG, le script fait la copie par rsync et crée un entrée dans /etc/auto.archives pour monter plus tard en lecture seule le volume logique si on veut récupérer les fichiers.
On conserve un journal de la copie et d’autres métadonnées dans un répertoire /aindex/Nom_archive sur le disque interne, avec une copie dans un répertoire logs dans le lv associé ( archive_vg ).

Un ls /archives/Nom_archive fait un montage automatique.

Ce micro server HP répond bien aux besoins somme toute modestes. Je ne procède à un archivage tous les 36 du mois (quand il y a besoin de place sur les systèmes de calcul et qu’on a peu de chances de reprendre les calculs faits par un stagiaire, ou par un ingénieur qui est parti, ou …)

Attention à ne pas se leurrer en voyant la référence à un contrôleur RAID sur le HP. C’est un faux contrôleur matériel. Il faut un pilote spécifique avec une licence et indisponible sous Debian (système non “supporté” )[*]

Dans votre cas d’usage je doute que le HP soit une bonne solution, mais je peux me tromper car votre présentation est beaucoup trop “buzzword compliant” pour moi. Si vous précisiez vraiment ce que vous voulez faire, avec des données techniques, les flux d’information, une estimation de la volumétrie, les contraintes de fiabilité, etc … là on pourrait peut être vous donner un avis.

Note
(*) Système non supporté : manière élégante de dire d’aller voir ailleurs. Il n’y a rien qui m’insupporte plus !

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean

Là où la femme fait défaut, la chèvre est appelée “chérie”.
Les proverbes philosophiques du Professeur Choron