Système de stockage ou hyperviseur sur un NAS mini PC : quelle couche doit gérer les disques ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les laboratoires informatiques personnels et les logiciels open source, elle se spécialise dans la vulgarisation de concepts techniques complexes au moyen de guides pratiques et concrets. Eva pense que l’hébergement personnel doit être amusant, et non intimidant. À travers ses tutoriels, elle aide la communauté à démystifier les configurations matérielles, de la construction de leur premier NAS à la maîtrise des conteneurs Docker.

Installez le système d’exploitation de stockage directement sur le matériel lorsque le stockage fiable est la mission principale du mini-PC ; ne placez un hyperviseur en première couche que si de véritables frontières entre machines virtuelles justifient cette couche supplémentaire de défaillance et de récupération.

La question importante n’est pas de savoir si les deux conceptions peuvent fonctionner. Il s’agit de déterminer quelle couche peut voir les disques physiques, signaler leur état, gérer le pool et rétablir le système après une défaillance du périphérique de démarrage ou de la carte mère. Sur un NAS compact, un seul contrôleur SATA ou pont USB peut desservir plusieurs périphériques : la réponse dépend donc du chemin matériel réel, et non d’un schéma.

Confiez clairement les disques à une seule couche

Un système d’exploitation de stockage installé directement sur le matériel voit directement les disques, leurs numéros de série, leurs compteurs d’erreurs, leurs températures et les membres du pool. Les alertes et le remplacement des disques sont ainsi plus faciles à gérer, car la même couche gère à la fois le système de fichiers et les données matérielles qui permettent de vérifier leur état.

Une conception où l’hyperviseur est prioritaire peut préserver cette visibilité en transférant un HBA ou un contrôleur SATA complet à la machine virtuelle de stockage. La présentation de disques virtuels peut plutôt masquer ou transformer les données d’état et crée une dépendance à la configuration du stockage de l’hôte avant même que le pool de la machine virtuelle puisse démarrer.

Choisissez à qui confier les disques avant de créer des données. Si l’hôte et la machine virtuelle peuvent tous deux partitionner, monter, mettre en cache ou surveiller les mêmes périphériques physiques, la conception échoue dès la première étape, quelles que soient ses performances.

Vérifiez si le mini-PC permet un transfert direct de périphériques sans conflit

Répertoriez chaque chemin d’accès aux disques : SATA interne, emplacements NVMe, adaptateurs USB-SATA et cartes PCIe. Déterminez ensuite quels périphériques partagent un contrôleur ou un groupe IOMMU avec le disque de démarrage de l’hyperviseur, l’interface réseau ou un autre périphérique que l’hôte doit conserver.

Un cas évoqué par la communauté, concernant un contrôleur SATA intégré partagé avec l’hôte, illustre le piège en pratique : attribuer ce contrôleur à la machine virtuelle de stockage peut aussi supprimer l’accès de l’hyperviseur à son propre disque. Le transfert de disques virtuels individuels a évité le plantage, mais a réduit la visibilité sur l’état des disques physiques.

La solution avec hyperviseur n’est acceptable que si le système de stockage invité peut disposer d’un contrôleur complet et stable ou d’un autre accès à un périphérique explicitement pris en charge, tandis que l’hôte conserve ses propres périphériques de démarrage et de gestion. Si cette séparation est impossible, confier le stockage directement au système installé sur le matériel est la solution la plus simple.

Déterminez si la virtualisation résout un problème précis

Un hyperviseur peut isoler une machine virtuelle Windows, un réseau de laboratoire ou une application qui nécessite son propre noyau. Il peut également faciliter la création d’instantanés et la reconstruction au niveau des machines virtuelles. Ces avantages comptent lorsque les charges de travail sont réelles et présentent des besoins de maintenance ou des frontières de confiance différents.

Ils comptent moins lorsque le projet se limite à un service de stockage et à quelques conteneurs. Dans ce cas, ajouter un hôte, une VM de stockage, un réseau virtuel et un ordre de démarrage des invités peut augmenter le nombre de composants nécessaires pour fournir le même partage de fichiers, sans créer de nouvelle séparation utile.

Effectuez un test pilote avec le transfert de fichiers le plus lourd prévu, pendant que les charges de travail des invités prévues sont actives. Écartez l’option de l’hyperviseur si la contention du processeur, la pression sur la mémoire ou le redémarrage d’un invité peut interrompre le stockage d’une manière que la conception bare metal éviterait.

Comparez les chemins de récupération avant les fonctionnalités

Un second cas de passthrough, avec un HBA et un pool TrueNAS existant, montre pourquoi l’ordre de démarrage et le comportement du micrologiciel doivent figurer dans le plan de récupération. Le pool lui-même peut être intact alors que la machine virtuelle suit un chemin de démarrage inattendu.

Testez la restauration de la configuration et l’importation du pool à l’aide de disques non critiques. Un instantané de l’hyperviseur ne suffit pas s’il dépend du même hôte défaillant ou ne peut pas recréer le mappage des périphériques ; un export de configuration de l’OS de stockage ne suffit pas non plus si vous n’avez jamais importé le pool sur du matériel de remplacement.

Événement de récupération L’OS de stockage gère les disques L’hyperviseur gère la plateforme
Défaillance du périphérique de démarrage Réinstallez, importez le pool et restaurez la configuration Reconstruisez l’hôte, restaurez la définition de la VM, puis importez ou rattachez le stockage
Défaillance du contrôleur Déplacez les disques vers un chemin compatible et importez le pool Remplacez le chemin de passthrough par un chemin compatible avant que l’invité n’accède aux disques
Défaillance de l’invité de stockage Sans objet Restaurez l’invité sans modifier la propriété physique du pool
Échec de la mise à jour de l’hôte Retour à une version précédente ou réinstallation de l’OS de stockage Le stockage et tous les invités peuvent attendre la récupération de l’hôte
Migration matérielle Importez le pool sur un hôte de stockage compatible Recréez d’abord le passthrough et les dépendances des invités

Choisissez la couche correspondant au principal domaine de défaillance

Choisissez un OS de stockage bare metal si le partage de fichiers est le rôle principal, si l’accès direct à l’état des disques et l’importation simple des pools sont importants, ou si le Mini PC ne permet pas d’isoler proprement un contrôleur. N’exécutez que les applications dont vous êtes prêt à lier les pannes à celles de l’hôte de stockage.

Choisissez d’abord un hyperviseur si vous pouvez nommer plusieurs invités indépendants, disposez de chemins distincts pour l’hôte et les périphériques de données et avez déjà testé le passthrough, l’ordre de démarrage, les mises à jour de l’hôte et la récupération. Pour une question plus générale sur les rôles logiciels, la décision entre un OS NAS et un Linux généraliste constitue la prochaine étape utile.

Cessez de comparer les listes de fonctionnalités dès que le matériel attribue un même contrôleur à l’hôte et aux disques de données. Sur un NAS Mini PC, la topologie physique peut déterminer l’architecture logicielle avant même que la facilité d’utilisation ou la qualité du tableau de bord n’entrent en jeu.

Comparaison de produits

À lire aussi

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.