Ton mini-datacenter : architecture Proxmox en 1 week-end

Pourquoi monter un mini-datacenter à la maison (et pourquoi Proxmox en 1 week-end)

À un moment, le « home lab » classique atteint sa limite. Tu commences avec un vieux PC ou un NUC, tu lances deux conteneurs, tu te sens invincible. Puis tu ajoutes Nextcloud. Puis Home Assistant. Puis un petit Git. Et un jour tu veux faire une mise à jour... et tout s’arrête, parce que tout vivait sur la même machine. Même disque, même alim, même réseau, même point de stress.

L’idée du mini-datacenter à la maison, ce n’est pas juste « avoir plus de serveurs ». C’est passer d’une boîte unique à une petite infra multi nœuds qui ressemble (un peu) à ce qu’on fait ailleurs. Plus fiable. Et plus le fun, aussi. Et franchement plus utile si tu veux apprendre.

Cas d’usage concrets, parce que sinon ça reste abstrait :

• Virtualisation : des VM pour séparer proprement tes services.
• Conteneurs LXC : légers, rapides, parfaits pour plein de petits services.
• Hébergement autonome : Nextcloud, Home Assistant, Gitea, Vaultwarden, Jellyfin, etc.
• Lab cybersécurité : une VM Kali, une cible vulnérable, un SIEM, un réseau isolé.
• Environnements de dev : CI, runners, environnements éphémères.
• NAS et stockage : ZFS, partages, snapshots.
• Domotique : segmentation réseau, services qui redémarrent « tout seuls ».

La promesse de cet article : une architecture simple, réaliste, reproductible sur 2 ou 3 nœuds Proxmox, avec un plan d’exécution sur 2 jours. Pas besoin d’un budget d’entreprise. Pas besoin de matériel exotique. Et pas de magie.

Ce que cet article n’est pas : un guide de production « bank grade ». On ne va pas simuler un datacenter Tier IV dans un placard. L’objectif, c’est un lab durable. Quelque chose qui survit aux mises à jour et aux week ends où tu n’as pas envie de dépanner pendant 4 heures.

Le piège des homelabs « au hasard » : ce qui casse en premier

Les homelabs « au feeling », ça marche. Jusqu’à ce que ça casse. Et ce qui casse en premier est presque toujours la même chose :

• Stockage bricolé sans redondance : un SSD unique, un RAID logiciel mal compris, des disques hétérogènes.
• Réseau plat sans séparation : tout le monde sur le même VLAN, puis tu exposes un service « juste pour tester ».
• Pas d’IPMI / iDRAC / iLO : dès que ça freeze ou que ça ne boote plus, tu es au sol, clavier écran.
• Sauvegardes inexistantes : ou « sauvegardes » qui sont en fait des snapshots.
• DNS / DHCP improvisés : un Pi hole qui fait DHCP, puis tu changes de box, puis plus rien ne résout.

Les symptômes, tu les connais peut être déjà : latence étrange, VM qui se figent, migrations impossibles, maintenance pénible, consommation électrique qui explose parce que tu compenses par « j’ajoute une machine de plus ».

Ce qu’il faut viser à la place : simplicité. Des chemins de panne identifiés. Des sauvegardes testées (vraiment). Une séparation réseau minimale. Et une doc courte mais claire. Deux pages. Un schéma. Un tableau IP. C’est tout.

Le plan en 1 week-end : architecture cible (vue d’ensemble)

L’architecture cible, on la garde volontairement sobre :

• 2 ou 3 nœuds Proxmox (PVE).
• 1 stockage : NAS en NFS, ou Ceph si tu pars sur 3 nœuds et que tu assumes la complexité.
• 1 switch manageable (VLAN).
• 1 routeur / pare feu (une box peut suffire, mais un vrai pare feu type OPNsense c’est plus propre).

Le concept de « minimum viable cluster » est important. On veut :

• Un réseau management (accès GUI, SSH, corosync).
• Un réseau stockage (si possible séparé).
• Un réseau VM (le trafic applicatif).
• Et idéalement une voie claire pour la migration.

Tu peux commencer sans HA parfaite. Ce n’est pas grave. Ce que tu veux tout de suite, en revanche : migrations, sauvegardes, capacité d’évolution.

Livrables à la fin du week end :

• Cluster Proxmox opérationnel (2 ou 3 nœuds).
• Un datastore clair (ZFS local ou NFS ou Ceph).
• Un réseau propre (au moins management séparé des VM).
• 2 ou 3 services déployés pour valider la pile.
• Une stratégie de backup (et un restore testé).

Matériel : ce qu’il te faut vraiment (sans te ruiner)

Les nœuds Proxmox (2 ou 3)

Tu n’as pas besoin d’un monstre. Mais tu as besoin de cohérence.

• CPU : Intel VT x / AMD V obligatoire, et si tu veux faire du passthrough plus tard, regarde aussi IOMMU.
• RAM : 32 Go minimum conseillé par nœud si tu veux être à l’aise. 16 Go, ça marche, mais tu vas arbitrer en permanence.
• Disque : un SSD NVMe pour l’OS et des VM rapides. Optionnellement un ou deux HDD pour du bulk, mais attention au bruit et à la conso.
• Réseau : idéalement deux interfaces (même si c’est deux fois 1 GbE). Ça te simplifie la séparation.

Un conseil « terrain » : trois petites machines correctes valent mieux qu’une grosse unique, si ton but est d’apprendre l’infra. Et si ton but est juste d’héberger 3 services, une seule machine suffit. Il faut choisir ce que tu veux vraiment.

Le réseau

• Si tu peux : 2.5 GbE ou 10 GbE pour le stockage. Ce n’est pas obligatoire, mais dès que tu mets des disques VM sur un NAS, tu sens la différence.
• Un switch manageable avec VLAN. Même un modèle simple suffit, tant que tu peux tagger et trunker.
• Câbles corrects, et pas trop longs si tu fais du 10 GbE cuivre.

Stockage : deux options réalistes

Tu as deux chemins propres. Choisis en un seul pour démarrer.

Option A (simple) : NAS externe en NFS + ZFS local

• Tu mets les disques VM « importantes » sur un export NFS du NAS.
• Tu gardes du ZFS local sur chaque nœud pour des VM de test, ISO, templates, caches, etc.

Avantages : simple, lisible, rapide à mettre en place. Très bien pour un premier cluster.

Limites : SPOF. Si le NAS tombe, les VM sur NFS sont impactées. Tu peux réduire le risque avec un NAS fiable, des disques en RAID, et surtout de bonnes sauvegardes.

Option B (plus « datacenter ») : Ceph sur 3 nœuds

Avantages : résilience, pas de NAS unique, stockage distribué, ça encaisse la panne d’un nœud (selon réplication).

Limites : plus complexe, plus bavard réseau, demande idéalement un réseau rapide et stable. Et tu vas passer du temps à comprendre ce que tu fais, ce qui est bien… mais pas toujours en « 1 week end détente ».

Règle pratique : si c’est ton premier cluster, commence NAS + NFS ou ZFS local + backups, puis évolue. Ceph, c’est un excellent projet numéro 2.

Deux architectures de stockage simples (choisis une seule pour démarrer)

On résume, parce que sinon tu vas hésiter jusqu’à dimanche soir.

• Option A : NAS NFS pour les VM + ZFS local pour le reste. Simple, efficace, SPOF assumé.
• Option B : Ceph sur 3 nœuds. Résilient, plus exigeant.

Si tu lis cet article parce que tu veux « un truc qui marche », prends l’option A.

Préparation avant d’installer : IP, DNS, noms des nœuds et VLAN

Avant de booter sur une clé USB, tu prends 30 minutes. Vraiment. Tu dessines un schéma, même moche. Et tu fais un tableau IP.

Plan d’adressage (exemple)

• VLAN 10 : management Proxmox (ex : 192.168.10.0/24)
• VLAN 20 : VM services (ex : 192.168.20.0/24)
• VLAN 30 : stockage (ex : 192.168.30.0/24) si tu peux

IP statiques pour les nœuds, toujours. Par exemple :

• pve-01 : 192.168.10.11
• pve-02 : 192.168.10.12
• pve-03 : 192.168.10.13
• passerelle : 192.168.10.1
• DNS : ton Pi hole ou ton routeur, mais décide maintenant

Plage VM : tu peux réserver 192.168.20.50 à 192.168.20.200, par exemple. Ce n’est pas une loi. C’est juste pour ne pas te marcher dessus.

Nommage

Fais simple : pve-01, pve-02, pve-03. Et garde des conventions pour les bridges :

• vmbr0 : réseau VM (VLAN aware si trunk)
• vmbr1 : stockage ou management, selon ta topologie

Le but, c’est que dans 3 mois tu comprennes encore ton propre système.

VLAN minimal

Au minimum : séparer management et réseau VM. Si tu peux ajouter un VLAN stockage, c’est le bonus le plus rentable pour éviter que les copies de backup ou les migrations saturent tes services.

Jour 1 — Installation propre de Proxmox VE sur chaque serveur

Tu installes Proxmox VE sur chaque nœud. Classique :

1. Clé USB bootable.
2. Choix du disque d’installation (idéalement le NVMe).
3. Config réseau initiale (IP statique, gateway, DNS).
4. Mot de passe root + email.

Ensuite, avant de faire quoi que ce soit d’autre :

• Mets à jour. Oui, tout de suite.
• Vérifie les dépôts. Beaucoup de gens activent n’importe quoi et se retrouvent avec des soucis de mise à jour plus tard. Choisis une stratégie adaptée à ton usage (community vs enterprise, selon ton contexte).
• Vérifie l’heure et NTP. Les clusters détestent les horloges en vrac.
• Vérifie les interfaces réseau, les noms, et la MTU si tu joues avec du 2.5/10G. MTU incohérente = debugging pénible.

Si tu prévois du passthrough plus tard : active IOMMU dans le BIOS maintenant. Ça évite de rebooter et de réouvrir le serveur quand tout sera en prod.

Côté accès :

• Active SSH.
• Ajoute des clés.
• Tu peux désactiver le login root distant si tu veux un peu plus de discipline.
• Active le firewall Proxmox au moins sur le management, même avec des règles simples.

Jour 1 — Créer le cluster Proxmox (et comprendre le quorum)

Tu crées le cluster sur le nœud 1, puis tu ajoutes les autres.

L’idée simple : Proxmox utilise corosync pour la communication cluster, et le quorum sert à éviter le split brain, c’est à dire deux groupes de nœuds qui pensent être « le vrai cluster » en même temps. Mauvaise journée assurée.

Pourquoi 2 nœuds c’est fragile : si tu en perds un, il ne reste qu’un nœud et il peut perdre le quorum selon la config. Donc ton cluster peut refuser certaines actions.

Pourquoi 3 nœuds c’est confortable : tu peux perdre un nœud et garder la majorité.

Si tu n’as que 2 nœuds :

• Option propre : ajouter un qdevice (corosync qnetd) sur une petite machine à part (même un Raspberry Pi ou un petit VM ailleurs, tant que c’est stable).
• Option assumée : accepter les limites, documenter le plan de panne, et ne pas activer des trucs « HA » comme si tu avais une infra à 3 nœuds.

Vérifications après ajout :

• Latence réseau inter nœuds.
• État corosync.
• Accès GUI sur chaque nœud via l’interface cluster.
• Certificats, et résolution DNS si tu utilises des noms.

Jour 1 — Réseau Proxmox : bridges, VLAN et bonnes pratiques

Là, tu gagnes ou tu perds ton dimanche.

Tu veux au moins :

• vmbr0 pour le trafic VM.
• un second bridge ou un VLAN dédié pour stockage et ou cluster, selon ton design.

Définis ce qui passe où :

• Management : GUI, SSH, corosync.
• Stockage : NFS, iSCSI, Ceph, réplication.
• Migrations : idéalement pas sur le même lien que les services exposés.
• Trafic VM : le réseau « applicatif ».

Erreurs fréquentes :

• Tout mettre sur une seule carte et espérer que ça ira.
• MTU incohérente entre switch, nœuds, NAS.
• VLAN tag mal posé. Trunk vs access confondus.
• Oublier que « VLAN aware » sur un bridge change la façon dont tu tagues côté VM.

Test rapide :

• Ping inter nœuds sur chaque VLAN.
• iperf si tu peux, au moins entre un nœud et le NAS.
• Migration à blanc d’une VM de test (même éteinte au début), juste pour valider le chemin.

Jour 2 — Stockage : ZFS, NFS/iSCSI ou Ceph (mise en place sans se perdre)

Le principe : tu dois pouvoir faire ce cycle sans surprise : créer une VM → disque sur le bon stockage → snapshot → restore.

Si ZFS local

Crée un pool ZFS propre. Quelques pratiques simples :

• Compression activée (souvent lz4), c’est presque gratuit et souvent bénéfique.
• atime off sur les datasets orientés VM.
• Pense à la RAM. ZFS aime la RAM. Sans UPS, évite de jouer au héros avec des réglages agressifs.
• Surveille la santé : scrubs planifiés, SMART, alertes.

ZFS local ne te donne pas du stockage partagé. Donc migrations live limitées selon tes volumes. Mais pour un lab, c’est souvent très correct si tu as PBS.

Si NAS NFS

Sur le NAS :

• Crée un export NFS dédié pour les disques VM.
• Fixe les droits, et limite aux IP de tes nœuds.
• Active des options raisonnables côté perf selon ton NAS.

Dans Proxmox :

• Ajoute le storage NFS.
• Fais un test simple : crée une VM, place le disque sur ce storage, démarre, fais un snapshot.

Tu dois aussi regarder la latence. Le débit brut, c’est bien. La latence, c’est ce qui fait « VM qui rame bizarrement ».

Si iSCSI (aperçu)

iSCSI peut être pertinent si tu veux du block storage, et parfois de meilleures perfs selon la pile. Mais c’est plus piégeux à bien configurer. Pour un premier week end, je le classerais dans la catégorie « plus tard », sauf si tu sais exactement pourquoi tu en as besoin.

Si Ceph (3 nœuds)

Haute niveau :

• Déployer MON et MGR.
• Ajouter des OSD (tes disques dédiés au cluster Ceph).
• Réseau dédié conseillé.
• Réplication (souvent 3) donc calcule ta capacité utile.

Tests basiques :

• État du cluster Ceph OK.
• Création d’un pool, puis d’une RBD pour une VM.
• Snapshot et restore.

Si tu sens que tu es en train d’apprendre Ceph au lieu de construire ton lab, stop. Reviens à NFS. Ce n’est pas un échec, c’est juste une priorisation.

Backups : la différence entre « j’ai un cluster » et « j’ai une infra fiable »

On va le dire clairement : snapshots ≠ sauvegardes. Et un cluster ≠ une stratégie de backup.

Le plus simple et le plus propre avec Proxmox : Proxmox Backup Server (PBS). Idéalement sur une machine séparée. Sinon sur un NAS. Mais séparé logiquement, au minimum.

Mise en place PBS (niveau concept) :

• Créer un datastore.
• Gérer les clés, le chiffrement si tu veux.
• Définir la rétention.

Plan simple qui marche :

• Quotidien sur 7 ou 14 jours.
• Hebdo sur 4 à 8 semaines.
• Mensuel sur 6 à 12 mois.

Le point obligatoire, celui que presque tout le monde zappe : tester un restore.

• Restaurer une VM.
• Restaurer un conteneur.
• Démarrer.
• Vérifier que le service répond.

Option hors site : copie chiffrée sur disque externe, ou réplication vers un autre stockage, ou cloud selon tes contraintes. Pas besoin de faire compliqué. Mais il faut une sortie de secours si ta maison et ton rack décident de vivre une mauvaise aventure.

Déployer tes premiers services (pour valider que tout est « production-ready »)

Ne déploie pas 15 trucs. Tu veux valider ton infra, pas te perdre.

Choisis 2 ou 3 services max, par exemple :

• DNS filtrant : Pi hole ou AdGuard.
• Reverse proxy : Nginx Proxy Manager ou Traefik.
• Un gros service : Nextcloud ou Home Assistant.
• Option dev : Gitea.

Standardise dès le début :

• Un template VM.
• Cloud init si possible.
• Ou des conteneurs LXC propres avec une base identique.

Même des détails bêtes comptent : même user, mêmes clés SSH, updates automatiques ou au moins un rituel de patching.

Réseau et sécurité :

• Reverse proxy pour éviter d’exposer 12 ports.
• Certificats Let’s Encrypt.
• Segmentation VLAN si tu peux.
• Ports exposés minimum. Et pas « juste pour tester » sur le VLAN management.

Observabilité légère :

• Alertes email Proxmox.
• SMART, santé ZFS.
• Logs centralisés si tu as le temps, sinon au moins une discipline de vérification.

Haute disponibilité et maintenance : ce que tu peux faire dès maintenant

Même sans HA, tu peux déjà travailler proprement.

Migrations live

Ça marche bien quand tu as du stockage partagé (NFS ou Ceph). Pré requis :

• Réseau correct.
• Stockage partagé accessible par tous les nœuds.
• VM configurée de façon compatible.

Utilité immédiate : tu peux patcher un nœud en déplaçant les VM ailleurs, puis rebooter sans downtime notable.

HA Proxmox

Proxmox propose une couche HA (ressources HA, watchdog, etc). Mais active la HA après stabilisation. Quand tu as un cluster sain, un réseau propre, et des backups testés. Sinon tu automatises juste des pannes.

Stratégie de mises à jour

• Rolling update : un nœud à la fois.
• Snapshot avant changement (quand ça a du sens).
• Fenêtre de maintenance, même si c’est juste « dimanche matin 9h ».

Documentation minimale

Tu veux un petit dossier, pas un roman :

• Schéma réseau.
• Tableau IP et VLAN.
• Où sont les mots de passe (idéalement un vault).
• Procédure restore PBS.
• Liste des services et où ils tournent.

Budget, bruit, énergie : optimiser sans sacrifier l’architecture

Un mini datacenter, ça peut devenir une machine à brûler des watts si tu ne regardes pas.

Budget par paliers (grossier, mais utile)

• Démarrage : 2 nœuds + NAS + switch manageable.
• Palier confort : 3 nœuds + réseau 2.5 GbE ou 10 GbE.
• Palier résilience : Ceph + UPS + disques dédiés + vraie séparation réseau.

Réduire la consommation

• Réglages BIOS power.
• CPU efficients plutôt que CPU « serveur d’il y a 12 ans ».
• Consolidation : moins de VM, plus de services par VM, tant que c’est maîtrisé.
• Planification : certains workloads peuvent dormir la nuit.

Bruit et chaleur

• Évite le serveur dans le salon. Vraiment.
• Emplacement ventilé.
• Nettoyage, airflow, pas de câbles en boule devant les entrées d’air.

Rappel utile : l’objectif est un lab durable. Si c’est trop bruyant ou trop cher à alimenter, il finit éteint. Et là tu n’apprends plus rien.

Conclusion : ton mini-datacenter est prêt, et la prochaine amélioration la plus rentable

Si tu as suivi le plan, ta checklist de fin de week end ressemble à ça :

• Cluster OK (2 ou 3 nœuds).
• Réseau propre (management séparé, VLAN si possible).
• Stockage validé (ZFS local ou NFS ou Ceph) avec un cycle VM snapshot restore testé.
• Backups PBS en place, restore testé.
• 2 ou 3 services en ligne, accessibles proprement.

La prochaine amélioration la plus rentable, selon moi, c’est souvent une de ces trois :

• Automatisation (Ansible) pour installer et configurer tes VM sans refaire à la main.
• PBS hors site, même basique.
• Upgrade réseau côté stockage (passer à 2.5 GbE ou mieux), si tu sens que tout se traîne.

Évolue par itérations. Un changement à la fois. Tu testes. Et tu gardes toujours une possibilité de rollback, même si c’est juste « je restaure depuis PBS ».

Si tu veux, partage ton schéma et ta stack (matériel, switch, NAS, nombre de nœuds, ce que tu veux héberger). Et dis moi ton budget et ta contrainte bruit. Je peux te proposer une évolution logique, sans te vendre un rêve.

Questions fréquemment posées

Pourquoi monter un mini-datacenter à la maison plutôt qu'un simple homelab ?

Monter un mini-datacenter à la maison permet de passer d'une unique machine à une infrastructure multi-nœuds, offrant plus de fiabilité, de flexibilité et une meilleure expérience d'apprentissage. Cela évite les points de défaillance uniques et facilite la gestion des services comme Nextcloud, Home Assistant ou des environnements de développement.

Quels sont les pièges courants des homelabs faits au hasard ?

Les principaux problèmes rencontrés sont le stockage sans redondance, les réseaux plats sans séparation VLAN, l'absence d'accès IPMI/iDRAC pour la gestion à distance, des sauvegardes inexistantes ou insuffisantes, ainsi que des configurations DNS/DHCP improvisées qui entraînent latence, gel des VM et maintenance compliquée.

Quelle architecture cible est recommandée pour un mini-datacenter Proxmox en 1 week-end ?

Une architecture sobre comprenant 2 ou 3 nœuds Proxmox (PVE), un stockage partagé via NAS NFS ou Ceph (si 3 nœuds), un switch manageable avec VLANs et un routeur/pare-feu (comme OPNsense) est recommandée. Il faut prévoir au minimum un réseau management, stockage et VM séparés pour garantir simplicité et évolutivité.

Quels cas d'usage concrets peut-on réaliser avec un mini-datacenter maison sous Proxmox ?

On peut virtualiser des machines pour séparer les services, déployer des conteneurs LXC légers, héberger Nextcloud, Home Assistant, Gitea ou Jellyfin en self hosting, créer un lab cybersécurité avec Kali Linux et SIEM, mettre en place des environnements de développement CI/CD, gérer du NAS avec ZFS et segmenter son réseau domotique.

Quel matériel est nécessaire pour démarrer un mini-datacenter Proxmox sans se ruiner ?

Il faut 2 ou 3 nœuds Proxmox basés sur du matériel accessible (vieux PC ou NUC), un stockage partagé via NAS NFS ou Ceph selon la complexité souhaitée, un switch manageable supportant VLANs et un routeur/pare-feu performant. Pas besoin de matériel exotique ni coûteux pour démarrer efficacement.

Comment assurer la durabilité et la maintenance facile d'un mini-datacenter maison ?

Il faut privilégier la simplicité avec des chemins de panne identifiés, une stratégie de sauvegarde testée réellement (pas juste des snapshots), une séparation minimale mais claire des réseaux (management vs VM), une documentation concise incluant schéma et tableau IP, ainsi que l'utilisation d'outils comme Proxmox facilitant migrations et backups.