Comment j'ai construit un cluster Proxmox à 3 nœuds autour du ZimaCube 2 comme backend de stockage partagé

Trois nœuds Proxmox. Un ZimaCube 2. Ethernet dix gigabits. Le tout installé dans une étagère Ikea Kallax, fonctionnant 24/7, plus silencieux que le réfrigérateur dans la pièce voisine.

Ce n’est pas une configuration hypothétique. C’est mon homelab — une baie 10 pouces entièrement imprimée en 3D qui s’intègre parfaitement dans un cube Kallax standard, avec le ZimaCube 2 en bas agissant comme cerveau de stockage partagé pour tout le cluster. Voici pourquoi j’ai choisi le ZimaCube 2 pour ce rôle, comment je l’ai intégré, et ce que j’ai appris en chemin.

L’architecture

Mon cluster comprend trois nœuds de calcul sous Proxmox avec stockage de démarrage eMMC et réplication ZFS entre eux. L’objectif est une HCI haute disponibilité complète — si un nœud tombe, les charges migrent automatiquement et le stockage reste cohérent.

Mais la réplication ZFS entre trois nœuds a ses limites. Il faut encore un backend de stockage partagé — avec assez de capacité, de bande passante et de fiabilité pour servir de source unique de vérité pour tout le cluster. C’est là qu’intervient le ZimaCube 2.

Pourquoi le ZimaCube 2 comme backend SAN/NAS

J'ai examiné beaucoup d'options avant de choisir le ZimaCube 2. Voici ce qui en a fait le bon choix :

Ce dont j'avais besoin

• Plus de 6 baies pour pools mixtes HDD/NVMe

• 10GbE pour servir le cluster sans goulot d'étranglement

• Extension PCIe pour futures mises à niveau GPU/NIC

• Natif Docker pour exécuter des services d'infrastructure en parallèle du stockage

• Assez silencieux pour un espace de vie (pas un sous-sol)

• Assez compact pour tenir dans un cube Kallax

Ce que le ZimaCube 2 offre

• 6× baies SATA3 + 4× M.2 NVMe dans la 7e baie

• 10GbE (Marvell AQC113) + 2× 2.5GbE (Intel i226)

• Slots PCIe x16 Gen4 + PCIe x8 Gen3

• ZimaOS préinstallé avec support Docker

• 240 × 221 × 220 mm — exactement compatible Kallax

• Châssis métallique avec refroidissement actif, quasi silencieux au repos

Le port 10GbE a été le facteur décisif. Si vous servez du stockage à trois nœuds hyperviseurs simultanément, un seul lien gigabit devient le goulot d'étranglement dès le premier jour. Le 10GbE du ZimaCube 2 me permet de saturer le réseau du cluster avant de saturer le backend de stockage.

Configuration de stockage

Voici comment j'ai organisé les pools de stockage sur le ZimaCube 2 :

Le cluster accède au ZimaCube 2 via un lien 10GbE dédié. Chaque nœud Proxmox se connecte via 2.5GbE à un switch manageable, avec le ZimaCube 2 sur le port uplink 10GbE. Les migrations à chaud des VM se font via NFS depuis le pool NVMe. Les médias et sauvegardes résident sur le pool HDD. Tout est supporté par ZFS avec snapshots.
Note sur la mise à niveau de la RAM : Le ZimaCube 2 est livré avec 8 Go DDR5 (Standard) ou 16 Go (Pro). Pour un backend de stockage basé sur ZFS, plus de RAM est préférable — ZFS utilise ARC (Adaptive Replacement Cache) en mémoire, et chaque gigaoctet d’ARC est un gigaoctet de stockage qui n’écrit pas sur le disque. J’ai ajouté une barrette SODIMM DDR5 de 32 Go pour atteindre un total de 40 Go, ce qui donne à ZFS une grande marge d’ARC sans priver les conteneurs Docker.

La construction physique : tout est imprimé en 3D

L’ensemble est installé dans un format rack 10 pouces, imprimé en 3D sur une Elegoo Centauri Carbon et conçu pour s’adapter exactement à l’intérieur d’un cube d’étagère Ikea Kallax standard.

Le ZimaCube 2 est placé en bas du rack — son poids et ses besoins en refroidissement en font la base naturelle. Au-dessus : trois nœuds de calcul, une appliance pare-feu dédiée et un panneau de brassage. Tout est monté avec des supports et panneaux d’aération imprimés en 3D sur mesure.

Tous les fichiers STL et remixes sont disponibles sur MakerWorld et Printables. J’ai conçu des supports personnalisés pour le ZimaCube 2, les unités ZimaBlade et l’appliance pare-feu.

Pourquoi pas TrueNAS ou Unraid ?

J’ai conservé ZimaOS sur le ZimaCube 2 au lieu de le réinitialiser pour TrueNAS ou Unraid. Voici mes raisons :

1.Docker natif dès le premier jour. Pas de système de plugins à gérer. docker-compose up et c’est prêt.

2.Support ZFS intégré. Le gestionnaire de stockage ZimaOS gère la création de pools ZFS et la planification des snapshots sans nécessiter de temps en terminal.

3.IceWhale le développe activement. Je teste une version Beta de ZimaOS directement de leur équipe — la réactivité aux retours de la communauté est vraiment bonne.

4.Je voulais tester la plateforme telle qu'elle est conçue. Vous pouvez toujours tout effacer et installer autre chose plus tard. Mais si ZimaOS gère la charge, c’est un système d’exploitation de moins à configurer et maintenir.

Pour un backend de stockage en cluster, la stabilité compte plus que les fonctionnalités. Jusqu'à présent, ZimaOS a tenu ses promesses.

Ce qui tourne sur le cluster

Les trois nœuds Proxmox hébergent actuellement :

• Home Assistant avec Zigbee2MQTT — automatisation domotique
• Frigate NVR sur un ZimaBlade dédié avec TPU Coral — 4 caméras extérieures, détection d'objets déléguée au TPU
• Paperless-ngx — gestion documentaire
• Vaultwarden — gestion des mots de passe
• Nginx Proxy Manager — proxy inverse et SSL
• Pi-hole — filtrage DNS à l'échelle du réseau
• Gitea — Git auto-hébergé pour projets personnels
• Plusieurs machines virtuelles de développement pour tester et apprendre

Le ZimaCube 2 exécute également quelques conteneurs d'infrastructure directement : Uptime Kuma pour la surveillance, un orchestrateur de sauvegarde et le planificateur de snapshots ZFS.

Construisez votre propre backend de stockage en cluster avec ZimaCube 2 →

Questions fréquemment posées

Pourquoi utiliser un ZimaCube 2 plutôt qu'un NAS traditionnel pour un cluster Proxmox ?

Trois raisons : 10GbE, extension PCIe et architecture native ZFS. La plupart des NAS grand public sont équipés de 1GbE, ce qui crée un goulot d'étranglement dès qu'ils servent plusieurs hyperviseurs. Le port 10GbE du ZimaCube 2, associé à deux ports 2,5GbE, vous offre la bande passante nécessaire pour servir le stockage sans contention. Et le slot PCIe permet d'ajouter une carte GPU ou une carte réseau plus rapide plus tard sans remplacer l'appareil entier.

ZimaOS gère-t-il suffisamment bien ZFS pour le stockage en cluster ?

Oui. ZimaOS inclut la création de pools ZFS, la planification des snapshots et la surveillance de la santé dans son gestionnaire de stockage. Pour un backend de cluster, les fonctionnalités clés — création de pools, partage NFS/SMB, automatisation des snapshots — sont toutes présentes sans nécessiter de configuration en terminal.

De combien de RAM le ZimaCube 2 a-t-il besoin pour ZFS ?

ZFS utilise la RAM pour l'ARC (cache), et plus de RAM signifie des performances de lecture plus rapides. Les 8 Go ou 16 Go d'origine conviennent pour des charges légères, mais pour servir plusieurs machines virtuelles ou conteneurs avec un grand ensemble de données, il est recommandé de passer à 32 Go ou 64 Go. Les emplacements SODIMM DDR5 sont accessibles à l'utilisateur — la mise à niveau prend quelques minutes.

Quel est l'avantage de garder le TPU Coral sur un ZimaBlade séparé plutôt que sur le ZimaCube 2 ?

Déléguer la détection d'objets Frigate à un ZimaBlade dédié avec TPU Coral décharge entièrement le CPU et le GPU du ZimaCube 2. Le ZimaCube 2 gère le stockage et les services Docker ; le ZimaBlade s'occupe de l'analyse vidéo en temps réel. Séparer ces charges de travail évite que le traitement des caméras ne concurrence les E/S des machines virtuelles ou l'inférence IA sur le système principal.