Chers passionnés de bidouille, ce soir je vais vous parler d’un truc qui devrait vous faire saliver d’excitation : le Storage Pod 6.0 de Backblaze !

En gros, vous prenez un châssis 4U, vous y fourrez 60 disques durs de 8 To et paf, ça vous fait un joli bébé de 480 To pour stocker tous vos fichiers, films, photos de vacances et autres données. Ce monstre mesure seulement 19 cm de haut pour une configuration 3×20 disques. Les disques sont montés sur une hauteur de 1U et espacés uniformément dans le châssis pour assurer un flux d’air optimal et un refroidissement au top.

Un seul ventilateur situé en haut du châssis aspire l’air à travers le serveur, tandis que deux ventilateurs supplémentaires en bas évacuent l’air chaud. C’est ce qu’on appelle une ventilation bien pensée !

Mais le Storage Pod c’est pas qu’une grosse boîte à disques, c’est avant tout une philosophie : celle du stockage à prix cassé ! Parce que là où ça devient vraiment intéressant, c’est quand on regarde le coût au Go. Tenez-vous bien, le Storage Pod 6.0 permet d’atteindre un tarif complètement dingue de moins de 5 centimes par Go !

Mais comment c’est possible un prix pareil ? Eh bien c’est là que le côté bidouille intervient. Chez Backblaze, ils ont décidé de concevoir eux-mêmes leur serveur de stockage en utilisant des composants standard, et surtout en optimisant chaque détail pour tirer les coûts vers le bas.

Par exemple, le boîtier a été légèrement allongé par rapport à la version précédente pour pouvoir caser 60 disques au lieu de 45. Un gain de place qui permet d’atteindre une densité de stockage de ouf : 120 To par unité de rack, soit 2,4 Po dans une baie 42U. De quoi voir venir côté capacité !

Les disques sont connectés via des ports SATA à une unique carte mère PCIe 3.0 x16 qui possède aussi un port USB 3.0 pour se connecter à un PC ou un autre appareil pour la gestion et le transfert des données. La carte mère embarque également un slot M.2 2280 NVMe pour un SSD servant à stocker le firmware de boot. Niveau alimentation, ça rigole pas : 6 blocs d’alim 12V 50A sont utilisés, avec 3 branchés de chaque côté du châssis. Chaque bloc alimente un circuit imprimé dédié situé à proximité des disques. Et sur ces circuits, on retrouve des ports USB pour se connecter à la carte mère ainsi que des LED pour le monitoring. Le tout est alimenté par un gros bloc externe 12V 300W qui envoie le jus via des connecteurs SATA 6 broches et Molex 3 broches pour les ventillos. Autant vous dire que ça envoie du lourd niveau watts !

Côté réseau, un port Ethernet Gigabit unique situé en haut du serveur, à côté du ventilo, se charge de la connectivité. Il est relié à la carte mère via un slot PCIe x1. Un petit câble le relie ensuite au switch réseau du datacenter. L’OS et le logiciel de gestion tournent sur une clé USB bootable 3.0 insérée dans le slot M.2. Ce soft permet de monitorer, alerter et mettre à jour le firmware des disques et autres composants.

Et le plus cool dans tout ça, c’est que les gars ont décidé de partager les plans du Storage Pod en open source . Comme ça, vous pouvez télécharger les schémas, les fichiers 3D et toute la doc pour construire votre propre Pod . Bon, faudra quand même mettre les mains dans le cambouis et avoir quelques notions en bricolage, mais rien d’insurmontable pour le vrai geek que vous êtes !

Par contre, je vous préviens tout de suite, si vous voulez atteindre les 5 centimes du Go, va falloir acheter les composants en gros et négocier les prix comme un chef, parce qu’en tarif public, vous serez plus proche des 10 centimes. Mais bon, ça reste quand même une sacrée affaire comparé aux serveurs de stockage traditionnels !

En tout cas, moi je dis chapeau bas à Backblaze pour cette nouvelle version du Storage Pod. Ça fait avancer le schmilblick et qui permettent de démocratiser le stockage de masse, parce qu’à l’heure des vidéos 4K, des bibliothèques photos qui débordent et des sauvegardes dans le cloud, on n’a jamais autant eu besoin de place pour stocker nos précieux octets.

Alors si vous avez un peu de temps devant vous et que vous voulez vous lancer dans l’aventure du stockage DIY, je vous invite à jeter un œil au projet Storage Pod . Vous y trouverez tout ce qu’il faut pour construire votre propre serveur à prix mini. Et qui sait, peut-être que vous aussi vous arriverez à stocker vos téra pour quelques centimes du Go ?

C’est aujourd’hui que prend fin votre calvaire d’avoir à installer et configurer manuellement chaque service auto-hébergé sur votre serveur perso.

Grâce au logiciel open source Tipi, vous allez pouvoir profiter de plus de 120 applications préconfigurées et personnalisables. L’idée derrière ce projet est de démocratiser l’auto-hébergement, et je peux dire que c’est un succès.

Le cœur de Tipi est un orchestrateur Docker, qui permet de lancer et gérer plusieurs services sur un seul serveur. N’ayez pas peur, il est conçu pour être accessible à tous, quelles que soient vos compétences techniques.

Lorsque vous commencez à utiliser Tipi, vous êtes accueilli par une interface web sympathique qui vous permet de gérer très facilement tous vos services mais également d’en ajouter et de les paramétrer. Et si jamais vous vous sentez limité par les applications disponibles, pas d’inquiétude : L’app store inclus dans Tipi vous permettra de demander l’ajout de nouveaux services à la communauté.

Pour vous donner un peu plus envie, voici un aperçu des différentes applications auto-hébergées que vous pouvez installer sur votre serveur. Il y a par exemple Adguard , un excellent bloqueur de publicités dont je vous ai déjà parlé, ou Bazarr , un gestionnaire de sous-titres pour les films et séries. Et bien sûr pour les développeurs, il existe même une interface Web pour Visual Studio Code appelée Code-Server . Avec Tipi, les possibilités sont nombreuses.

Firefly III vous permettra par exemple de suivre vos dépenses et vos revenus en un seul endroit, sans partager vos informations financières avec des services tiers. J’ai également trouvé Gladys Assistant qui est un assistant personnel qui prend soin de votre vie privée tout en vous aidant à gérer votre domotique.

D’autres outils incroyables pour la gestion et la synchronisation de fichiers, la gestion de tâches, la surveillance de serveurs, la gestion de médias, et bien plus encore sont également disponibles. Vous y trouverez aussi WikiJS , un wiki open source extensible, Tautulli , un compagnon pour Plex, et Resilio , une solution basée sur P2P pour la synchronisation et le partage de fichiers.

Pour le tester, il y a également une démo ici . (user : user@runtipi.io / mdp : password)

L’installation est facile . Il vous faudra un Linux du genre Ubuntu 18.04 LTS, Docker et le plugin Docker Compose. Ensuite, pour l’installer, il suffit de récupérer et lancer la dernière version avec la commande suivante :

curl -L https://setup.runtipi.io | bash

Et voilà ! A vous des tas d’applications auto-hébergées sans prise de tête. Tipi est un projet plutôt exceptionnel qui rend abordable l’auto-hébergement pour le plus grand nombre.

Je vous encourage à l’essayer par vous-même. Vous trouverez plus d’infos par ici .

Si vous cherchez un bon moyen d’auto-héberger vos magazines, vos livres et bandes dessinées, ne cherchez plus, Komga est la solution !

Si les comics vous intéressent et que vous avez tout ça au format numérique, c’est forcement un peu galère pour organiser tout ça et s’y retrouver. Grâce à Komga vous pourrez vous sortir de ce pétrin et créer des bibliothèques pour vos BDs afin d’organiser totalement vos collections.

Komga est donc un serveur de comics / mangas open source et gratuit. Vous pouvez même y mettre vos magazine PDF ou vos livres. Il supporte les formats epub, pdf, cbz et cbr et une fois en place, vous profiterez d’une jolie d’une interface web responsive.

Vous pourrez ainsi organiser votre bibliothèque avec des collections et des listes de lecture, et même modifier les métadonnées de vos séries de BDs et de vos livres. Komga permet également d’importer automatiquement les métadonnées intégrées à ces fichiers et vous pouvez tout lire sans quitter votre navigateur via le lecteur web.

D’ailleurs plusieurs modes de lecture sont dispo et vous pouvez même gérer plusieurs users avec un contrôle d’accès par bibliothèque, mais également des restrictions d’âge.

En plus de cela, il dispose d’une API REST et de nombreux outils et scripts développés par la communauté qui sont capables d’interagir avec Komga.

Vous pourrez, d’un clic, télécharger les fichiers à l’unité ou des séries entières de BDs entières et si vous avez des petits soucis de mémoire lors de vos imports, l’outil est également capable de détecter les fichiers en double et même les pages en double. Komga peut également importer automatiquement les BDs déposées dans un répertoire.

Le plus beau là-dedans, c’est que ça s’installe très facilement avec Docker Compose, ou lancé directement via le .jar fourni (java). Donc vous l’aurez compris, ça peut tourner sur un Windows, un Linux mais également un NAS.

Si vous voulez tester par vous-même, une démo est accessible ici : https://demo.komga.org/

• Login: demo@komga.org
• Password: komga-demo

Qui n’a jamais rêvé d’avoir une belle page de monitoring sur son serveur pour suivre l’état de santé de ses applications ?

Statping est un outil simple d’utilisation qui permet de créer ce genre de page de statut pour toutes vos applications et vos sites web. Ce script va automatiquement récupérer les données de vos app et en faire une belle page de statut.

Tout est personnalisable donc vous pouvez rendre ça vraiment joli ou en tout cas, adapté à vos besoins. Ainsi, si votre serveur tombe en panne, votre page de statut devrait toujours être en ligne pour informer vos utilisateurs de l’indisponibilité. Veuillez quand même à bien héberger Statping sur un autre serveur que celui de vos applications ^^.

Pour le lancer avec Docker, c’est hyper simple :

docker run -it -p 8080:8080 statping/statping

Il peut aussi se lancer avec le Docker Compose fourni (j’adore Docker Compose ^^). Heureusement pour vous, Statping est une application très légère, dispo pour Linux, Mac et Windows qui peut même tourner sur un simple Raspberry Pi. Ce serait dommage de s’en priver !

Une application mobile est également disponible sur l’App Store et Google Play gratuitement. Elle vous permettra de consulter l’était de vos services et évidemment de recevoir des notifications lorsque l’un d’entre eux est hors ligne. Vous pouvez même envoyer directement des emails ou encore des messages sur Slack grâce à ses webhook.

En résumé, Statping est un outil vraiment utile pour les développeurs et les administrateurs systèmes car il vous permettra enfin de créer une page de statut pour vos applications et sites web, très rapidement, avec toutes les fonctionnalités et la personnalisation dont vous avez toujours rêvé.

Plus d’infos ici.

<p>En ces temps troublés, la lecture devient une enclave paisible où il fait bon se réfugier.</p> <p>Charentaises aux pieds, plaid sur les genoux, petit fond musical pour l'ambiance: on est pas mal.<br> Le thé vient d'être servi, allez-y, prenez une tasse!<br> Le feu dans la cheminée est assez fort pour qu'on soit bercé par son crépitement.</p> <p>Ce qui serait vraiment relou, là maintenant, ce serait d'avoir à se relever pour téléverser un livre sur la liseuse.</p> <h3 id="toc-koreader-3-opds">Koreader &lt;3 OPDS</h3> <p><a href="http://koreader.rocks/">Koreader</a> est un lecteur de documents conçu pour les appareils e-ink.<br> C'est un logiciel libre qui apporte de nombreuses fonctionnalités faisant souvent défaut aux logiciels livrés avec les liseuses.<br> Une fonctionnalité particulièrement utile, qui m'évite d'avoir à quitter mon plaid pour ajouter un livre, est le support des catalogues OPDS.</p> <p><a href="https://opds.io/">OPDS</a> c'est le petit nom de Open Publication Distribution System.<br> En gros c'est un format pour décrire une collection de livres, et une manière de se les procurer (téléchargement, achat, prêt, etc).</p> <p>Une URL vers l'OPDS à renseigner dans Koreader et voila des kilo-bytes de lecture a portée de clic!</p> <p>La question qui te brûle maintenant les lèvres c'est bien sûr: mais quelle URL qu'on met?</p> <p>Celle de son serveur bookshelf bien évidemment!</p> <h3 id="toc-serveurs-opds">Serveurs OPDS</h3> <p>Il existe plusieurs manières de publier un flux OPDS.<br> Sans chercher à être exhaustif, j'en ai noté deux principales:<br> - faire tourner un serveur <a href="https://calibre-ebook.com/fr">calibre</a><br> - faire tourner <a href="https://blog.slucas.fr/projects/calibre-opds-php-server/">COPS</a></p> <p>Dans les deux cas la collection doit être gérée par calibre, COPS se base sur la bibliothèque seulement (pas besoin de calibre sur le serveur).<br> Calibre est un super logiciel, mais bien trop lourd pour mon besoin.</p> <p>Et en cherchant des alternatives légères, ben j'en ai pas trouvé bézef…</p> <h3 id="toc-bookshelf">Bookshelf</h3> <p>Je veux pouvoir partager un répertoire contenant des fichiers epubs.<br> Outre l'accès OPDS, je souhaites aussi pouvoir parcourir la collection avec mon navigateur préféré.</p> <p>Comme on est souvent bien servi par soi-même, et que c’était un bon prétexte pour écrire du go, je me suis concocté une petite solution.</p> <p>Ça s'appelle donc <a href="https://gitlab.com/greizgh/bookshelf">Bookshelf</a>, c'est libre et ça ne fait pas grand chose (simple et stupide).</p> <p>Pour commencer, ça mange un répertoire dans lequel il y a des epubs.<br> Ils vont être indexés pour être publiés, c'est la partie la plus gourmande en ressource selon la taille de la collection.<br> Mais c'est un coût unique puisque lors de l'ajout ultérieur d'epub, l'indexation ne passera que sur les nouveaux fichiers.</p> <p>Il n'y a pas de page d'auteur, de série ou autre parce que les métadonnées sont toujours nazes et on se retrouverait avec des "Lewis Carroll", "Carroll Lewis", "Caroll L", etc.<br> On est trop bien au coin du feu pour passer sa journée à corriger des métadonnées: je préfère la recherche plein texte.</p> <p>Tout passe par la recherche. Tu veux un polar? Tape "enquête". Une romance? "bisou"! Tu vois l’idée.<br> Pour peu que le mot apparaisse dans la description, le titre, la série ou l'auteur, le bouquin remontera dans les résultats.</p> <p>Avec ce petit bout de logiciel, je suis satisfait:<br> - je dépose des epubs en SFTP sur le serveur<br> - un cron indexe le répertoire contenant les fichiers<br> - je récupère mon livre en OPDS quand je le souhaite</p> <p>C'est tellement simple que ma maman s'en sert.<br> Et les copains qui ont accès au sftp peuvent également ajouter des bouquins.</p> <p>Voilà, des fois que ça te serait utile, <a href="https://gitlab.com/greizgh/bookshelf">le code est libre</a>.</p> <p>Et si tu cherches des livres, le <a href="http://www.gutenberg.org/">projet Gutenberg</a> est une mine d'or.</p> <p>Sur ce, j'y retourne, mon thé va refroidir.</p> <p>Bisous</p> <div><a href="https://linuxfr.org/users/grzgh/journaux/bookshelf-publier-ses-ebooks-simplement.epub">Télécharger ce contenu au format EPUB</a></div> <p> <strong>Commentaires :</strong> <a href="//linuxfr.org/nodes/122942/comments.atom">voir le flux Atom</a> <a href="https://linuxfr.org/users/grzgh/journaux/bookshelf-publier-ses-ebooks-simplement#comments">ouvrir dans le navigateur</a> </p>

Vous vous en souvenez peut-être, nous avions effectué un tutoriel Let's Encrypt quelques jours après sa mise en bêta publique. D'ailleurs, il mériterait un petit relooking, vu que quelques détails ont un peu changé, et que d'autres clients ACME ont vu le jour. Par exemple on a honteusement passé sou...

Vous vous en souvenez peut-être, nous avions effectué un tutoriel Let's Encrypt quelques jours après sa mise en bêta publique. D'ailleurs, il mériterait un petit relooking, vu que quelques détails ont un peu changé, et que d'autres clients ACME ont vu le jour. Par exemple on a honteusement passé sous silence l'excellent acme.sh qui a le mérite de ne pas demander une ribambelle de dépendance en temps que simple script Bash. De plus, le client principal (dont le nom est désormais Certbot) a désormais implémenté des extensions Apache et Nginx qui fonctionnent (presque) comme on le souhaite, à savoir modifier tout seul les configurations des sites pour fonctionner avec Let's Encrypt. Cependant je reste plus enclin à utiliser la méthode manuelle.

À l'époque, je vous parlais d'une infrastructure simple, à savoir un unique serveur frontal : c'est lui qui interceptait les requêtes et qui les traitait, point barre. L'infra d'un site avec une audience restreinte, car tout doit être traité par une unique machine. Bonjour l'indispo surprise.

Parlons à présent d'une architecture un peu plus ambitieuse, le genre de topologie qu'on peut trouver en production pour des sociétés importantes (et les technophiles enthousiastes). Cette première partie sera dédiée à l'explication de cette mystérieuse architecture et à la présentation d'une manière de la mettre en œuvre. Dans une seconde partie, on apprendra à y déployer ses certificats Let's Encrypt.

Souvent donc, on ne se contente pas d'un unique frontal, mais de plusieurs frontaux, sous la coupe d'un répartiteur de charge, (load-balancer en anglais) qui se chargera de réceptionner les requêtes des utilisateurs et de les distribuer aux frontaux, selon une stratégie définie. Cette architecture a quatre avantages :

• On gagne en charge maximale supportée, donc en nombre de visiteurs.
• Multiplier les frontaux amoindrit fortement les risques de crash du site, car en cas de panne d'un frontal, les autres frontaux se partagent le trafic.
• La mise en production d'une nouvelle version d'un site web peut se faire sans aucune interruption de service : il suffit de déployer sur un frontal à la fois.
• Les frontaux sont sur un réseau privés et non directement accessible sur le réseau global, donc la sécurité du site est renforcée.

On constate que le répartiteur de charge est un potentiel goulot d'étranglement et il nous faut donc un programme optimisé pour la haute disponibilité afin que le flux des requêtes ne soit pas le facteur limitant.

Disons maintenant que l'on souhaite apposer un certificat sur cette architecture. Question à dix sesterces : qui parmi ces serveurs doit porter ce certificat ?

Si on choisit de faire porter le certificat par les frontaux, cela signifie qu'il faut que tous les frontaux doivent le porter, et qu'il faudra déployer le certificat sur toutes ces machine à chaque renouvellement. Mais surtout, cela signifie que, le trafic étant chiffré jusqu'aux frontaux, le répartiteur de charge ne pourra pas prendre en compte le contenu de la requête dans sa stratégie de répartition, ce qui est fort pénalisant. En effet, il est coutume de configurer le répartiteur de charge pour distribuer certaines URL sur un pool de frontaux différent du pool normal, par exemple le back-office (la page d'administration et de saisie de contenu du site). Enfin dernier point, si vous vous souvenez du fonctionnement du protocole ACME comme décrit dans notre tutoriel, vous saurez que le certificat doit être généré sur la machine qui en fait la demande et qui répondra au challenge ACME. Ceci implique qu'un des frontaux doit être désigné pour la génération des certificat, et donc que le répartiteur de charge doit rediriger toutes les requêtes de type ACME vers ce frontal, ce qui est à la fois moche et justement impossible car notre répartiteur de charge ne peut pas comprendre ce qu'il redirige à cause du chiffrement.

La solution la plus sensée, qui maintient également le plus l'isométrie des frontaux, est de faire porter le certificat par le répartiteur de charge.

Zoomons alors sur cette fameuse machine, le répartiteur de charge. On va partir d'un socle OpenBSD. Pourquoi pas un Linux ? Parce qu'on utilise souvent la même machine pour la répartition de charge et pour le pare-feu, et qu'OpenBSD est le système de prédilection pour faire un routeur libre. Et en plus j'aime bien cet OS, ça change un peu les idées.

Sur ce socle, on va utiliser le répartiteur de charge HAProxy. Les seules tâches de HAProxy sont de porter le certificat du ou des sites (on parle de SSL-offloading) et d'aiguiller le trafic web sur les frontaux. Il ne peut pas générer de flux web par lui-même, il peut seulement relayer une requête à un autre service. Et d'ailleurs il est très bon pour ça.

HAProxy est organisé en frontends et en backends : un frontend est la façade présentée au monde extérieur qui va recevoir les requêtes des internautes. Un backend est un pool de serveurs frontaux qui va traiter la requête. HAProxy doit donc choisir sur quel backend envoyer une requête, mais il doit également gérer le pool de frontaux que représente ce backend.

Prenons un exemple de configuration simple. On passera les directives globales HAProxy qui ne sont pas intéressantes et présentent peu de valeur ajoutée. Et bien entendu, on part du principe que vos frontaux sont configurés, écoutent sur des adresses locales et tout le toutim.

frontend mon_super_site
    bind *:80
    mode http

    acl url-back-office path_dir /admin

    use_backend back-office if url-back-office
    default_backend mes-frontaux

backend back-office
    server backoffice 192.168.0.14:80

backend mes-frontaux
    balance roundrobin
    server backoffice 192.168.0.11:80
    server backoffice 192.168.0.12:80
    server backoffice 192.168.0.13:80

Dans cette configuration, le frontend écoute sur toutes les adresses IP attribuées au serveur, sur le port 80 (donc pour le moment, uniquement du trafic en clair). Le mode HTTP signifie qu'on utilise ce frontend pour répartir du flux web, et non pas comme le mode TCP ou l'on redirige un flux TCP intouché.

On a écrit une ACL, autrement dit une condition. Retenez cette notion car les ACL sont au cœur du principe de HAProxy. Ici notre ACL est vraie si le chemin de l'URL commence par /admin et fausse sinon. On utilisera donc le backendback-office si l'ACL est vraie et sinon, on utilisera le backend par défaut mes-frontaux.

Le backendback-office est très simple car il ne comporte qu'un serveur. Le backendmes-frontaux comporte trois serveurs répartis en round-robin.

Et voilà, vous avez un répartiteur de charge. Si vous avez un certificat SSL, vous pouvez ajouter une ligne au frontend :

bind *:443 ssl cert /chemin/vers/mon/certificat.pem

Sauf que ça ne marchera pas. En tout cas pas tant que vous aurez mis votre certificat sous la forme attendue par HAProxy, à savoir la clef privée et le certificat dans le même fichier. Nous verrons cela dans la seconde partie, qui vous expliquera également (et finalement) comment diable utiliser Let's Encrypt avec ce bidule. En tout cas, si vous êtes perspicace, vous vous doutez que ça tournera en partie autour des ACL, car il y a bien une raison pour laquelle c'est le seul élément en gras de l'article.

(Source de l'image d'en-tête : Great A'tuin par Schiraki)

Récemment j'ai du intervenir sur ma tour parce que j'avais plus tellement de place. J'ai du vite acheter un autre disque dur pour y remédier. Ce qui me donne l'occasion de parler de cette belle technologie sur laquelle je m'étais promis de faire un petit tuto un de ces jours. En théorie RAID est l'a...

Récemment j'ai du intervenir sur ma tour parce que j'avais plus tellement de place. J'ai du vite acheter un autre disque dur pour y remédier. Ce qui me donne l'occasion de parler de cette belle technologie sur laquelle je m'étais promis de faire un petit tuto un de ces jours.

En théorie

RAID est l'acronyme de Redundant Array of Independent Disks (Alignement redondant de disques indépendants), et comme son nom l'indique, il va permettre de regrouper plusieurs disques durs et d'y instaurer une politique de stockage pour faire de la redondance, de l’agrégation de taille, enfin ça répond à plein de besoins différents. En fait on ne devrait pas vraiment parler d'un seul RAID, mais bel et bien de la famille des RAIDs, car en effet il y a autant de RAIDs que de besoins différent.

On va présenter les assemblages RAID les plus utilisés. Pour plus de détails, je vous conseille la page Wikipédia qui est très claire et qui contient des schémas très explicites.

Dans la suite, on va beaucoup parler de bandes de stockage : il s'agit d'une quantité de stockage de valeur prédéfinie, qui correspond à une "section" contiguë du disque qui la contient. Dans ce modèle, lors de l'écriture sur le volume, une bande est d’abord remplie avant d'en entamer une suivante. Il s'agit en fait d'abstraire le stockage et de pouvoir mieux comprendre la répartition des données sur les différents disques.

RAID 0

Les bandes sont tout bonnement distribuées sur les disques, toujours dans le même ordre. On remplit donc une bande par disque, puis une fois qu'on a touché à tous les disques, on repart du premier disque et on recommence une couche de bandes. Tous les disques contiennent des données différentes. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera nx.

• Avantages : Ce montage permet d'utiliser le plus grand espace possible de votre assemblage. De plus, en moyenne, les accès disques parallèles seront plus rapide, pour peu que ces accès disques se fassent dans des bandes différentes et sur des disques différents.
• Inconvénients : Il suffit de perdre un seul disque pour corrompre l'intégralité des données. Or, statistiquement, plus on a de disques, plus on a de chances d'en perdre.

RAID 1

Les bandes sont écrites à l’identique sur tous les disques. Tous les disques contiennent exactement les même données. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera x.

• Avantages : C'est le montage qui permet la plus grande sécurité des données faces aux pannes : tant qu'il vous reste un disque fonctionnel, vos données sont intactes et complètes. Les accès disques sont aussi nettement améliorés, avec une vitesse théorique multipliée par le nombre de disques dans le montage.
• Inconvénients : Il est frustrant d'avoir beaucoup de disques durs pour avoir au final l'espace d'un seul disque. Évidemment les données sont très sûres mais quand même, faut pas pousser...

RAID 5

Les bandes sont réparties sur tous les disques sauf un, qui reçoit une bande de parité. La bande de parité est tout simplement une bande dont chaque bit est obtenu en appliquant le OU exclusif (XOR) à l'ensemble des bits correspondants dans les bandes alignées des autres disques. Cette bande de parité est attribuée à chaque disque alternativement au fil des couches de bandes remplies. Donc si un disque vient à tomber en panne, pour chaque couche de bande, si la bande du disque en panne est la bande de parité, alors les données de la couche sont intactes. Si la bande contient de la donnée, alors elle peut être recalculée à partir des autres couches de données et celle de parité. C'est du calcul logique, et c'est la force du XOR. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera (n-1)x.

• Avantages : Un bon compromis entre place exploitable et sécurité des données. On se donne le droit de perdre un disque dur dans la bataille. Pour retrouver l'usage des données, il suffit de remplacer le disque défaillant et les données sont reconstruites.
• Inconvénients : Ça dépends des cas, mais un droit à un unique disque dur en panne, ça peu être peu. Pour certain ça peut être insuffisant.

RAID 6

Il s'agit d'une extension du RAID 5 dans laquelle on se permet de pouvoir perdre plus d'un disque. La solution étant d'attribuer plus de bandes de "parité" par couche, une par nombre de pannes maximum permises. Ici, j'utilise les guillemets car il ne s'agit plus vraiment de la parité simple de la logique de base, mais d'un truc chelou reposant sur un principe tout autre dont je ne pas trop vous parler parce que j'en ignore tout. Donc si vous avez n disques durs de capacité exploitable x, et si vous mettez en place k bandes de redondance par couche, la capacité totale du montage sera (n-k)x.

• Avantages : On se sent un peu plus à l’abri des intempéries matérielles, au pris d'un peu de place de stockage.
• Inconvénients : Le principe chelou dont je vous ai parlé, enfin dont je ne vous ai pas parlé pour être honnête, eh bien il est tellement chelou qu'il pète pas mal les performances. Et pour couronner le tout, la plupart des implémentations de ce type d'assemblage est bien moins stable que les autres.

Il est également possible de combiner les RAIDs. Une combinaison fréquente est le RAID 10 (RAID 1 + RAID 0). Par exemple si on a 10 disques, on peu monter 2 RAID 1 de 5 disques chacun, puis assembler ces deux volumes en RAID 0. On a également aussi le RAID 50, combinaison dur RAID 5 et du RAID 0 selon le même principe.

La gestion du RAID

Je vous parlais de différentes implémentations du RAID. En fait, le RAID n'est pas un programme en tant que soi, juste un ensemble de spécifications. Du coup chacun y va de sa sauce : il existe des implémentations libres et propriétaires, logicielles et matérielles. Les solutions matérielles se basent sur du matériel dédié (un contrôleur RAID), le système d'exploitation n'a donc pas à s'occuper de ça et le plus souvent ces solutions marchent out of the box, sans avoir besoin de configurer quoi que ce soit. Mais elles ont l'immense inconvénient d'être propriétaire dans leur quasi-totalité, et pour le coup il n'existe aucun standard. Dans certains cas, si votre contrôleur RAID rend l'âme, il vous faudra acquérir exactement le même modèle de contrôleur, sinon, peu importe que vos disques soient tous intacts, plus rien ne pourra les lire, et vous serez alors en légitime position d'être fort contrarié. À mon humble avis, le principal argument des RAIDs matériel auparavant était les meilleures performances. Aujourd'hui cet avantage est de plus en plus obsolète, car désormais les machines sont bien plus puissantes qu'il y a 15 ans et les programmes de RAID ont été nettement optimisés et stabilisés. Cette différence de performance est aujourd'hui presque intangible.

En pratique

J'ai hérité par un ami d'une tour de bureau. Elle est bien cool car elle contient une grande baie de disques et pas mal de ports SATA (bien entendu, vous pouvez faire votre RAID avec des disques branchés en USB si vous le souhaitez). J'ai donc décidé d'en faire un NAS fait main.

Choix des armes

J'ai donc initialement acheté 3 disques de 3 To chacun (des Western Digital Red, gamme dédiée justement aux usage en RAID) et j'ai opté pour un RAID 5 logiciel. Et sur Linux, le programme de RAID par excellence est mdadm. J'ai décidé de garder branché le disque dur d'origine (500 Go) mais de ne pas l'intégrer au RAID, il sert uniquement de disque de démarrage. Notez que si j'avais voulu optimiser les performances, j'aurais pu troquer ce disque pour un petit SSD, mais bon, je suis déjà content comme ça.

Par ailleurs, pour faire de la place dans la baie de disques, j'ai du déménager le disque de démarrage dans la baie frontale, celle destinée à accueillir les périphériques comme le lecteur optique.

Le 4ème disque du RAID, on en parlera plus tard. Je l'ai acheté bien après.

Pour ça j'ai utilisé un adaptateur 3,5 pouces vers 5,25 pouces bien pratique, qui m'a permis de fixer bien solidement le disque dur au lieu de le laisser se balader dans la tour.

Partitionnement et formatage

Du côté software, je me retrouve avec un disque sda de démarrage, et sdb, sdc et sdd des disques vierges prêts à être assemblés en RAID. Avant ça, j'ai besoin de les partitionner. J'utilise donc fdisk pour les trois disques à tour de rôle, je choisis une table de partitions GPT et j'y crée une unique partition de type "Linux RAID" (code 29 dans fdisk).

Création de l'assemblage RAID

C'est tout bête, ça tient en une seule ligne de commande :

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

Dans cette commande, j'indique que le nom du volume abstrait sera /dev/md0, que ce sera un RAID 5, qu'il comporte 3 disques et je lui précise les partitions que je veux utiliser.

Pour suivre l'évolution de la création de l'assemblage, jetez un coup d'oeil au fichier /proc/mdstat. Ce fichier sera votre nouvel ami, c'est lui qu'il faudra consulter dès que vous ferez une opération qui touche au RAID.

Puis j'ajoute l'assemblage à la configuration de mdadm pour que celui-ci me l'assemble au démarrage :

mdadm --detail --scan >> /etc/mdadm.conf

Puis il ne vous reste plus qu'à mettre votre système de fichier préféré sur le volume créé !

mkfs.ext4 /dev/md0

Pour que votre assemblage soit monté au démarrage, j'ajoute à mon /etc/fstab :

/dev/md0 /mnt/data ext4 defaults 0 0

Il ne faut pas confondre assemblage et montage, il s'agit de deux étapes lors de la connexion d'un RAID. On doit assembler un RAID afin qu'il soit reconnu comme un volume propre, puis on doit monter notre volume pour pouvoir lire et écrire dessus.

Enfin on monte le volume :

mkdir /mnt/data
mount /mnt/data

Ayé vous avez un RAID 5 qui fonctionne !

Il est recommandé de procéder régulièrement à des reconstruction de RAID, opération qui va vérifier la cohérence de l'assemblage. Il s'agit d'une opération transparente mais qui dure plusieurs heures et qui va se traduire par une forte augmentation de l'activité des disques. Pour ça il vous faudra lancer un petit programme sans arguments, raid-check, à un intervalle raisonnable, disons, toutes les semaines. Choisissez un horaire de faible activité, comme la nuit du samedi au dimanche à 3h du matin. Pour ça, faites vous plaisir, entre la crontab et les timers de systemd, on manque pas de solutions.

Ajout d'un nouveau disque à l'assemblage

Mon RAID 5 était constitué de 3 disques de 3 To ce qui nous fait 6 To exploitables, si vous avez bien suivi. 6 To, c'est un grand espace, il m'a suffi pendant presque 2 ans... Puis j'ai eu besoin de plus de place. J'ai donc racheté un autre disque (même modèle, même taille) que j'ai fourré dans ma tour. Je vous avoue que sur le coup, j'étais encore puceau au niveau extension de RAID, j'ai donc flippé énormément et j'ai fait une sauvegarde de mes 6 To sur divers disques externes que j'ai pu trouver dans ma caverne. Je vous raconte pas comme c'était pénible...

Petites observations à ce niveau :

1. Remarquez que l'ordre des disques dans le nommage des périphériques physiques (sdX) et tout sauf fixe. En théorie, il faut être préparé à ce que vos disques changent de noms. Votre petit sdb chéri que vous avez bordé et vu s'endormir dans le creux douillet de son lit un soir peut très bien vous trahir et s'appeler sdc au petit matin dès le prochain redémarrage. Bon c'est un peu exagéré, mais une chose est sure, il ne faut jamais faire confiance au nommage des périphériques physiques (c'est pour ça entre autres qu'il faut privilégier la désignation par UUID dans la fstab).
2. mdadm se fiche complètement du nommage de ses périphériques. Il utilise sa propre magie noire pour déterminer les membres d'un assemblages. En conclusion, ne vous tracassez pas pour retrouver le nom de vos disques de votre assemblage, mdadm, lui, s'y retrouvera toujours.

Cependant, faites quand même gaffe lorsque vous allez ajoutez votre nouveau disque dur. Par exemple chez moi, le nouveau disque s'est vu nommé sdb, tandis que les autres s'étaient vu relégués en sdc, sdd et sde. Faut juste le savoir et traiter les disques pour ce qu'ils sont, et non pas des étiquettes à trois lettres.

Tout ce que j'ai eu à faire, en définitive, a été de partitionner-formater mon nouveau disque ainsi que l'ont été ses aînés, puis j'ai lancé les deux commandes suivantes :

mdadm --add /dev/md0 /dev/sdb1
mdadm --grow --raid-devices=4 --backup-file=/root/grow\_md0.bak /dev/md0

La première va juste indiquer à mdadm qu'on lui ajoute un disque, mais sans plus. C'est la deuxième commande qui va lancer l'opération de reconstruction (rééquilibrage de l'assemblage). Opération qui dure plusieurs heures, donc suivez son déroulement dans /proc/mdstat.

Une fois que c'est terminé, il faut maintenant procéder à l'extension du système de fichier lui même. Et là vous priez pour avoir choisi un système de fichier pas trop stupide qui accepte ce genre d'opération. Rassurez-vous, ext4 le supporte très bien.

Il le supporte même tellement bien que vous pouvez le faire directement à chaud, sans démonter votre volume. Pour ça, premièrement, si vous utilisez une connexion SSH, ouvrez une session tmux. Il serait bête qu'un incident réseau de rien du tout vienne corrombre tout votre système de fichire tout de même. Puis il vous faudra exécuter :

resize2fs -p /dev/md0

Il va vous mettre en garde et ronchonner un tantinet que votre disque est toujours monté, mais écoutez, il s'en remettra, dans la vie on fait pas toujours ce qu'on veut. Les minutes passent, vous vous rongez les ongles, vous prenez un café, vous videz un pot de glace, et normalement, si tout se passe bien, le système de fichier aura été étendu à tout l'espace disponible sur l'assemblage. Félicitations !

Conclusion

J'ai rencontré beaucoup de monde m'ayant dit qu'ils préféraient rester éloigner autant que possible de RAID parce que ça leur faisait peur. En réalité, il n'y a rien d'effrayant là dedans. mdadm est un outil ma foi fort bien codé et les années ont prouvé qu'il était fiable. Il ne faut pas avoir peur du RAID. Enfin un peu quand même, faut pas faire n'importe quoi.

Récemment j'ai du intervenir sur ma tour parce que j'avais plus tellement de place. J'ai du vite acheter un autre disque dur pour y remédier. Ce qui me donne l'occasion de parler de cette belle technologie sur laquelle je m'étais promis de faire un petit tuto un de ces jours. En théorie RAID est l'a...

Récemment j'ai du intervenir sur ma tour parce que j'avais plus tellement de place. J'ai du vite acheter un autre disque dur pour y remédier. Ce qui me donne l'occasion de parler de cette belle technologie sur laquelle je m'étais promis de faire un petit tuto un de ces jours.

En théorie

RAID est l'acronyme de Redundant Array of Independent Disks (Alignement redondant de disques indépendants), et comme son nom l'indique, il va permettre de regrouper plusieurs disques durs et d'y instaurer une politique de stockage pour faire de la redondance, de l’agrégation de taille, enfin ça répond à plein de besoins différents. En fait on ne devrait pas vraiment parler d'un seul RAID, mais bel et bien de la famille des RAIDs, car en effet il y a autant de RAIDs que de besoins différent.

On va présenter les assemblages RAID les plus utilisés. Pour plus de détails, je vous conseille la page Wikipédia qui est très claire et qui contient des schémas très explicites.

Dans la suite, on va beaucoup parler de bandes de stockage : il s'agit d'une quantité de stockage de valeur prédéfinie, qui correspond à une "section" contiguë du disque qui la contient. Dans ce modèle, lors de l'écriture sur le volume, une bande est d’abord remplie avant d'en entamer une suivante. Il s'agit en fait d'abstraire le stockage et de pouvoir mieux comprendre la répartition des données sur les différents disques.

RAID 0

Les bandes sont tout bonnement distribuées sur les disques, toujours dans le même ordre. On remplit donc une bande par disque, puis une fois qu'on a touché à tous les disques, on repart du premier disque et on recommence une couche de bandes. Tous les disques contiennent des données différentes. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera nx.

• Avantages : Ce montage permet d'utiliser le plus grand espace possible de votre assemblage. De plus, en moyenne, les accès disques parallèles seront plus rapide, pour peu que ces accès disques se fassent dans des bandes différentes et sur des disques différents.
• Inconvénients : Il suffit de perdre un seul disque pour corrompre l'intégralité des données. Or, statistiquement, plus on a de disques, plus on a de chances d'en perdre.

RAID 1

Les bandes sont écrites à l’identique sur tous les disques. Tous les disques contiennent exactement les même données. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera x.

• Avantages : C'est le montage qui permet la plus grande sécurité des données faces aux pannes : tant qu'il vous reste un disque fonctionnel, vos données sont intactes et complètes. Les accès disques sont aussi nettement améliorés, avec une vitesse théorique multipliée par le nombre de disques dans le montage.
• Inconvénients : Il est frustrant d'avoir beaucoup de disques durs pour avoir au final l'espace d'un seul disque. Évidemment les données sont très sûres mais quand même, faut pas pousser...

RAID 5

Les bandes sont réparties sur tous les disques sauf un, qui reçoit une bande de parité. La bande de parité est tout simplement une bande dont chaque bit est obtenu en appliquant le OU exclusif (XOR) à l'ensemble des bits correspondants dans les bandes alignées des autres disques. Cette bande de parité est attribuée à chaque disque alternativement au fil des couches de bandes remplies. Donc si un disque vient à tomber en panne, pour chaque couche de bande, si la bande du disque en panne est la bande de parité, alors les données de la couche sont intactes. Si la bande contient de la donnée, alors elle peut être recalculée à partir des autres couches de données et celle de parité. C'est du calcul logique, et c'est la force du XOR. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera (n-1)x.

• Avantages : Un bon compromis entre place exploitable et sécurité des données. On se donne le droit de perdre un disque dur dans la bataille. Pour retrouver l'usage des données, il suffit de remplacer le disque défaillant et les données sont reconstruites.
• Inconvénients : Ça dépends des cas, mais un droit à un unique disque dur en panne, ça peu être peu. Pour certain ça peut être insuffisant.

RAID 6

Il s'agit d'une extension du RAID 5 dans laquelle on se permet de pouvoir perdre plus d'un disque. La solution étant d'attribuer plus de bandes de "parité" par couche, une par nombre de pannes maximum permises. Ici, j'utilise les guillemets car il ne s'agit plus vraiment de la parité simple de la logique de base, mais d'un truc chelou reposant sur un principe tout autre dont je ne pas trop vous parler parce que j'en ignore tout. Donc si vous avez n disques durs de capacité exploitable x, et si vous mettez en place k bandes de redondance par couche, la capacité totale du montage sera (n-k)x.

• Avantages : On se sent un peu plus à l’abri des intempéries matérielles, au pris d'un peu de place de stockage.
• Inconvénients : Le principe chelou dont je vous ai parlé, enfin dont je ne vous ai pas parlé pour être honnête, eh bien il est tellement chelou qu'il pète pas mal les performances. Et pour couronner le tout, la plupart des implémentations de ce type d'assemblage est bien moins stable que les autres.

Il est également possible de combiner les RAIDs. Une combinaison fréquente est le RAID 10 (RAID 1 + RAID 0). Par exemple si on a 10 disques, on peu monter 2 RAID 1 de 5 disques chacun, puis assembler ces deux volumes en RAID 0. On a également aussi le RAID 50, combinaison dur RAID 5 et du RAID 0 selon le même principe.

La gestion du RAID

Je vous parlais de différentes implémentations du RAID. En fait, le RAID n'est pas un programme en tant que soi, juste un ensemble de spécifications. Du coup chacun y va de sa sauce : il existe des implémentations libres et propriétaires, logicielles et matérielles. Les solutions matérielles se basent sur du matériel dédié (un contrôleur RAID), le système d'exploitation n'a donc pas à s'occuper de ça et le plus souvent ces solutions marchent out of the box, sans avoir besoin de configurer quoi que ce soit. Mais elles ont l'immense inconvénient d'être propriétaire dans leur quasi-totalité, et pour le coup il n'existe aucun standard. Dans certains cas, si votre contrôleur RAID rend l'âme, il vous faudra acquérir exactement le même modèle de contrôleur, sinon, peu importe que vos disques soient tous intacts, plus rien ne pourra les lire, et vous serez alors en légitime position d'être fort contrarié. À mon humble avis, le principal argument des RAIDs matériel auparavant était les meilleures performances. Aujourd'hui cet avantage est de plus en plus obsolète, car désormais les machines sont bien plus puissantes qu'il y a 15 ans et les programmes de RAID ont été nettement optimisés et stabilisés. Cette différence de performance est aujourd'hui presque intangible.

En pratique

J'ai hérité par un ami d'une tour de bureau. Elle est bien cool car elle contient une grande baie de disques et pas mal de ports SATA (bien entendu, vous pouvez faire votre RAID avec des disques branchés en USB si vous le souhaitez). J'ai donc décidé d'en faire un NAS fait main.

Choix des armes

J'ai donc initialement acheté 3 disques de 3 To chacun (des Western Digital Red, gamme dédiée justement aux usage en RAID) et j'ai opté pour un RAID 5 logiciel. Et sur Linux, le programme de RAID par excellence est mdadm. J'ai décidé de garder branché le disque dur d'origine (500 Go) mais de ne pas l'intégrer au RAID, il sert uniquement de disque de démarrage. Notez que si j'avais voulu optimiser les performances, j'aurais pu troquer ce disque pour un petit SSD, mais bon, je suis déjà content comme ça.

Par ailleurs, pour faire de la place dans la baie de disques, j'ai du déménager le disque de démarrage dans la baie frontale, celle destinée à accueillir les périphériques comme le lecteur optique.

Le 4ème disque du RAID, on en parlera plus tard. Je l'ai acheté bien après.

Pour ça j'ai utilisé un adaptateur 3,5 pouces vers 5,25 pouces bien pratique, qui m'a permis de fixer bien solidement le disque dur au lieu de le laisser se balader dans la tour.

Partitionnement et formatage

Du côté software, je me retrouve avec un disque sda de démarrage, et sdb, sdc et sdd des disques vierges prêts à être assemblés en RAID. Avant ça, j'ai besoin de les partitionner. J'utilise donc fdisk pour les trois disques à tour de rôle, je choisis une table de partitions GPT et j'y crée une unique partition de type "Linux RAID" (code 29 dans fdisk).

Création de l'assemblage RAID

C'est tout bête, ça tient en une seule ligne de commande :

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

Dans cette commande, j'indique que le nom du volume abstrait sera /dev/md0, que ce sera un RAID 5, qu'il comporte 3 disques et je lui précise les partitions que je veux utiliser.

Pour suivre l'évolution de la création de l'assemblage, jetez un coup d'oeil au fichier /proc/mdstat. Ce fichier sera votre nouvel ami, c'est lui qu'il faudra consulter dès que vous ferez une opération qui touche au RAID.

Puis j'ajoute l'assemblage à la configuration de mdadm pour que celui-ci me l'assemble au démarrage :

mdadm --detail --scan >> /etc/mdadm.conf

Puis il ne vous reste plus qu'à mettre votre système de fichier préféré sur le volume créé !

mkfs.ext4 /dev/md0

Pour que votre assemblage soit monté au démarrage, j'ajoute à mon /etc/fstab :

/dev/md0 /mnt/data ext4 defaults 0 0

Il ne faut pas confondre assemblage et montage, il s'agit de deux étapes lors de la connexion d'un RAID. On doit assembler un RAID afin qu'il soit reconnu comme un volume propre, puis on doit monter notre volume pour pouvoir lire et écrire dessus.

Enfin on monte le volume :

mkdir /mnt/data
mount /mnt/data

Ayé vous avez un RAID 5 qui fonctionne !

Il est recommandé de procéder régulièrement à des reconstruction de RAID, opération qui va vérifier la cohérence de l'assemblage. Il s'agit d'une opération transparente mais qui dure plusieurs heures et qui va se traduire par une forte augmentation de l'activité des disques. Pour ça il vous faudra lancer un petit programme sans arguments, raid-check, à un intervalle raisonnable, disons, toutes les semaines. Choisissez un horaire de faible activité, comme la nuit du samedi au dimanche à 3h du matin. Pour ça, faites vous plaisir, entre la crontab et les timers de systemd, on manque pas de solutions.

Ajout d'un nouveau disque à l'assemblage

Mon RAID 5 était constitué de 3 disques de 3 To ce qui nous fait 6 To exploitables, si vous avez bien suivi. 6 To, c'est un grand espace, il m'a suffi pendant presque 2 ans... Puis j'ai eu besoin de plus de place. J'ai donc racheté un autre disque (même modèle, même taille) que j'ai fourré dans ma tour. Je vous avoue que sur le coup, j'étais encore puceau au niveau extension de RAID, j'ai donc flippé énormément et j'ai fait une sauvegarde de mes 6 To sur divers disques externes que j'ai pu trouver dans ma caverne. Je vous raconte pas comme c'était pénible...

Petites observations à ce niveau :

1. Remarquez que l'ordre des disques dans le nommage des périphériques physiques (sdX) et tout sauf fixe. En théorie, il faut être préparé à ce que vos disques changent de noms. Votre petit sdb chéri que vous avez bordé et vu s'endormir dans le creux douillet de son lit un soir peut très bien vous trahir et s'appeler sdc au petit matin dès le prochain redémarrage. Bon c'est un peu exagéré, mais une chose est sure, il ne faut jamais faire confiance au nommage des périphériques physiques (c'est pour ça entre autres qu'il faut privilégier la désignation par UUID dans la fstab).
2. mdadm se fiche complètement du nommage de ses périphériques. Il utilise sa propre magie noire pour déterminer les membres d'un assemblages. En conclusion, ne vous tracassez pas pour retrouver le nom de vos disques de votre assemblage, mdadm, lui, s'y retrouvera toujours.

Cependant, faites quand même gaffe lorsque vous allez ajoutez votre nouveau disque dur. Par exemple chez moi, le nouveau disque s'est vu nommé sdb, tandis que les autres s'étaient vu relégués en sdc, sdd et sde. Faut juste le savoir et traiter les disques pour ce qu'ils sont, et non pas des étiquettes à trois lettres.

Tout ce que j'ai eu à faire, en définitive, a été de partitionner-formater mon nouveau disque ainsi que l'ont été ses aînés, puis j'ai lancé les deux commandes suivantes :

mdadm --add /dev/md0 /dev/sdb1
mdadm --grow --raid-devices=4 --backup-file=/root/grow\_md0.bak /dev/md0

La première va juste indiquer à mdadm qu'on lui ajoute un disque, mais sans plus. C'est la deuxième commande qui va lancer l'opération de reconstruction (rééquilibrage de l'assemblage). Opération qui dure plusieurs heures, donc suivez son déroulement dans /proc/mdstat.

Une fois que c'est terminé, il faut maintenant procéder à l'extension du système de fichier lui même. Et là vous priez pour avoir choisi un système de fichier pas trop stupide qui accepte ce genre d'opération. Rassurez-vous, ext4 le supporte très bien.

Il le supporte même tellement bien que vous pouvez le faire directement à chaud, sans démonter votre volume. Pour ça, premièrement, si vous utilisez une connexion SSH, ouvrez une session tmux. Il serait bête qu'un incident réseau de rien du tout vienne corrombre tout votre système de fichire tout de même. Puis il vous faudra exécuter :

resize2fs -p /dev/md0

Il va vous mettre en garde et ronchonner un tantinet que votre disque est toujours monté, mais écoutez, il s'en remettra, dans la vie on fait pas toujours ce qu'on veut. Les minutes passent, vous vous rongez les ongles, vous prenez un café, vous videz un pot de glace, et normalement, si tout se passe bien, le système de fichier aura été étendu à tout l'espace disponible sur l'assemblage. Félicitations !

Conclusion

J'ai rencontré beaucoup de monde m'ayant dit qu'ils préféraient rester éloigner autant que possible de RAID parce que ça leur faisait peur. En réalité, il n'y a rien d'effrayant là dedans. mdadm est un outil ma foi fort bien codé et les années ont prouvé qu'il était fiable. Il ne faut pas avoir peur du RAID. Enfin un peu quand même, faut pas faire n'importe quoi.