🔄 Le plan, revu et corrigé (encore)

🌐 Aussi en: English · Deutsch · Español

Eh bien… c’est encore arrivé 😄

Après avoir rédigé le plan initial et réfléchi un moment à l’architecture, j’ai commencé à remettre en question certains de mes choix. C’est tout l’intérêt d’un homelab : rien n’est gravé dans le marbre. Le principe, c’est d’itérer, d’apprendre et, parfois, de tout reconstruire de zéro.

Alors oui, le plan de reconstruction a changé. Encore.

On se croirait vraiment dans ce moment culte du Monopoly : on est devant le plateau, on tombe sur « Retournez à la case Départ », on râle un peu… et on comprend qu’il faut tout reconstruire depuis le début… 😅🎲

🪟 Windows marchait en fait très bien

Windows 11 sur mes postes de travail a extrêmement bien fonctionné. La prise en charge du matériel était excellente, il y avait des pilotes pour tout, et l’intégration à l’infrastructure Windows Server se comportait comme prévu. Active Directory, DNS, partages de fichiers et GPO restent un écosystème très mature, et techniquement tout marchait parfaitement.

D’ailleurs, j’ai fait tourner cette configuration Windows pendant des semaines sans le moindre souci. J’avais sérieusement envisagé de monter une infrastructure informatique domestique hybride : Windows 11 et Windows Server pour les clients et les services serveur, et à côté Linux et Kubernetes pour d’autres charges de travail.

Mais je me suis rendu compte que je voulais revenir à Linux comme socle de mon homelab. Linux m’est tout simplement plus familier : j’y ai accumulé une expertise bien plus poussée au fil des années. Windows et Windows Server, c’est un autre univers, dans lequel je n’ai jamais eu beaucoup d’expérience pratique, et je n’ai pas envie d’ouvrir un nouveau « chantier » de ce côté-là pour le moment. Dans une autre vie, peut-être. 😄

Ce n’est donc pas l’histoire d’un « échec de Windows » : il a fonctionné à merveille. Mais sur mon parcours personnel de homelab, c’est Linux qui sera au centre. 🐧

🌍 Retour à Linux & souveraineté numérique

Mon homelab est étroitement lié à quelques principes personnels :

• 🐧 Logiciels open source
• 🔐 Maîtrise de ma propre infrastructure
• 🌍 Moins de dépendance aux grands écosystèmes centrés sur les États-Unis
• 🧠 Apprendre des technologies en phase avec les plateformes Linux modernes

Windows a beau très bien fonctionner, il ramène peu à peu l’infrastructure dans l’écosystème Microsoft. Pour mon parcours d’apprentissage et ma philosophie personnelle, je préfère rester dans le monde de l’open source.

Microsoft quitte donc à nouveau le homelab. Complètement. 🐧

🧠 Autre constat : mon troisième serveur s’ennuyait

En relisant la conception d’origine, j’ai remarqué que l’un de mes serveurs allait passer le plus clair de son temps à se tourner les pouces. Une machine dédiée uniquement au stockage et à quelques services, ça ne justifie pas le matériel.

Un serveur, ça doit transpirer un peu. 💻🔥

Plutôt que d’attribuer un rôle fixe à chaque machine physique, j’ai opté pour une architecture plus souple.

🧱 Cluster Proxmox – sans système de fichiers partagé

Pour mon homelab, je monte un cluster Proxmox à trois nœuds, mais sans système de fichiers distribué comme CephFS. Chaque nœud utilisera son stockage SSD local pour les données des VM. L’un de mes serveurs dispose d’un pool RAID5 pour les gros volumes, mais j’accepte là-dessus quelques compromis.

Autre raison de laisser CephFS de côté : mon réseau domestique ne tourne qu’à 1 Gbit/s, bien en dessous de la bande passante recommandée pour de bonnes performances avec CephFS (en général >10 Gbit/s). Un cluster de stockage partagé serait donc plus un goulot d’étranglement qu’un avantage.

La raison principale du cluster, c’est la gestion centralisée : une seule interface web, un seul login pour les trois serveurs. Plus tard, je prévois aussi de migrer des VM hors ligne entre les nœuds pour répartir la charge et mieux exploiter le matériel, sans passer par un stockage partagé.

En bref : cluster = confort + flexibilité, pas stockage distribué. 💻⚡

🖥️ Matériel & architecture des serveurs

Tous les nœuds participent désormais pleinement au cluster et fournissent puissance de calcul et stockage selon les besoins.

💾 Installation de Proxmox : ZFS sur le disque système

Pour les hôtes Proxmox eux-mêmes, j’ai choisi ZFS pour le disque système.

• Systèmes de fichiers possibles : ext4, XFS, ZFS → choix de ZFS
• Un seul SSD par hôte pour l’OS
• Pool RAID0 (un seul disque, sans redondance) pour les VM

ZFS apporte des fonctions de stockage dignes de l’entreprise, même dans un petit homelab. 💾

⚙️ Réglages ZFS

• Compression : lz4 → rapide, surcoût CPU minimal, 20 à 40 % d’espace économisé
• Ashift : 12 → blocs de 4K, idéal pour les SSD modernes
• Sommes de contrôle : activées → protègent contre la corruption silencieuse (bitrot)

🧹 Activer le TRIM des SSD

zpool set autotrim=on vmdata

Préserve les performances des SSD dans la durée en libérant les blocs inutilisés. 🚀

🧠 Nœud Proxmox 1 (PVE1)

• Système : HP DL20 Gen10+
• RAM : 64 Go
• iLO : 192.168.10.x
• Hôte Proxmox : 192.168.10.x

Stockage

• SSD de 512 Go – OS / VM d’infrastructure
• SSD de 2 To – données des VM (pool ZFS RAID0)

VM d’infrastructure

☸️ Cluster Kubernetes – partie 1

🧠 Nœud Proxmox 2 (PVE2)

• Système : HP DL20 Gen10+
• RAM : 32 Go
• iLO : 192.168.10.x
• Hôte Proxmox : 192.168.10.x

Stockage

• SSD de 512 Go – OS / VM d’infrastructure
• SSD de 2 To – données des VM (pool ZFS RAID0)

VM d’infrastructure

☸️ Cluster Kubernetes – partie 2

🧠 Nœud Proxmox 3 (PVE3)

• Système : HP MicroServer Gen10+ V2
• Rôle : nœud du cluster Proxmox + stockage des VM

Stockage

• 3 SSD de 2 To – pool ZFS RAIDZ1

Services d’infrastructure

☸️ Cluster Kubernetes – partie 3

💾 Créer les pools ZFS pour le stockage des VM

Récapitulatif des pools de stockage :

• PVE1 & PVE2 → un seul SSD, ZFS RAID0 (sans redondance)
• PVE3 → un seul SSD, ZFS RAID0 (sans redondance) + trois SSD, ZFS RAIDZ1 (protégé par parité)

Les commandes complètes et le tuning (compression lz4, ashift=12, sommes de contrôle activées, atime désactivé) se trouvent dans les sections précédentes.

🏁 Cluster & migration hors ligne des VM

Les trois nœuds font désormais partie d’un seul et même cluster Proxmox. Chacun conserve son pool ZFS local : aucun stockage partagé n’est nécessaire. La migration hors ligne des VM permet de répartir la charge et de mieux exploiter le matériel, tandis que l’interface centrale rend l’administration confortable. 💻⚡

🔁 Planifier la réplication & la sauvegarde des VM

Dans le prochain article, je me pencherai sur la réplication et la sauvegarde des VM :

• Répliquer toutes les VM de PVE1 → PVE2 et inversement
• Sauvegarder toutes les VM sur le Proxmox Backup Server de PVE3

Pour l’instant, j’envisage d’abord Terraform pour redéployer les VM. La réplication suivra. Ses principaux avantages : un démarrage plus rapide des VM quand on déplace des charges de travail, et une redondance supplémentaire en amont des sauvegardes. 😎

🏁 Conclusion mise à jour

• 🐧 Infrastructure 100 % Linux
• 🧱 Cluster Proxmox à 3 nœuds
• ☸️ Kubernetes comme plateforme d’apprentissage centrale
• 📦 Meilleure exploitation du matériel
• 🧠 Accent marqué sur les outils open source

Moins de Microsoft. Plus de Linux. Plus de conteneurs.

La phrase « ce sera l’architecture définitive du homelab » marque généralement le début de la prochaine reconstruction. 😄

📝 Remarque : le nom du jeu de société sur l’image mise en avant est volontairement flouté, car il s’agit de la marque d’un tiers.