Système d’exploitation de stockage ou hyperviseur sur un mini-PC NAS : quelle couche doit gérer les disques ?
Installez le système d’exploitation de stockage directement sur le matériel lorsque le stockage fiable est la fonction principale du Mini PC ; ne placez d’abord un hyperviseur que lorsque de véritables frontières entre machines virtuelles justifient la couche supplémentaire de défaillance et de récupération.
La question importante n’est pas de savoir si les deux architectures peuvent fonctionner. Il s’agit de déterminer quelle couche peut voir les disques physiques, signaler leur état, contrôler le pool et récupérer après la défaillance du périphérique de démarrage ou de la carte mère. Sur un NAS compact, un contrôleur SATA ou un pont USB peut desservir plusieurs appareils ; la réponse dépend donc du chemin matériel réel plutôt que d’un schéma.
Attribuez aux disques un propriétaire unique et sans ambiguïté
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 à comprendre, car la même couche possède à la fois le système de fichiers et les informations matérielles qui l’étayent.
Une architecture reposant d’abord sur un hyperviseur peut conserver cette visibilité en transmettant un HBA ou un contrôleur SATA entier à la machine virtuelle de stockage. La présentation de disques virtuels peut au contraire masquer ou transformer les données d’état et crée une dépendance vis-à-vis de la configuration du stockage de l’hôte avant même que le pool invité puisse démarrer.
Choisissez un propriétaire avant de créer des données. Si l’hôte et l’invité sont tous deux autorisés à partitionner, monter, mettre en cache ou surveiller les mêmes appareils physiques, l’architecture a échoué dès son premier contrôle, quelles que soient ses performances.
Vérifiez que le Mini PC peut transmettre un appareil proprement
Répertoriez chaque chemin de disque : SATA interne, emplacements NVMe, ponts USB vers SATA et adaptateur PCIe. Déterminez ensuite quels appareils partagent un contrôleur ou un groupe IOMMU avec le disque de démarrage de l’hyperviseur, l’interface réseau ou un autre appareil que l’hôte doit conserver.
Un cas rapporté par la communauté, concernant un contrôleur SATA intégré partagé avec l’hôte, illustre le piège concret : attribuer ce contrôleur à l’invité de stockage peut également supprimer le propre chemin de disque de l’hyperviseur. La transmission de disques virtuels individuels a évité le plantage, mais a réduit la télémétrie des disques physiques.
L’option hyperviseur n’est viable que si l’invité de stockage peut recevoir un contrôleur complet et stable, ou un autre chemin d’appareil explicitement pris en charge, tandis que l’hôte conserve des appareils de démarrage et de gestion indépendants. Si cette séparation est impossible, il est plus cohérent de laisser le stockage être géré directement sur le matériel.
Déterminez si la virtualisation répond à un problème précis
Un hyperviseur peut isoler un invité Windows, un réseau de laboratoire ou une application qui nécessite son propre noyau. Il peut également simplifier les instantanés et les reconstructions au niveau de l’invité. Ces avantages comptent lorsque les charges de travail sont réelles et présentent des limites de maintenance ou de confiance différentes.
Ils comptent moins lorsque le projet se limite à un service de stockage et à quelques conteneurs. Dans ce cas, l’ajout d’un hôte, d’une machine virtuelle de stockage, d’un réseau virtuel et d’un ordre de démarrage des invités peut augmenter le nombre de composants nécessaires pour le même partage de fichiers sans créer de nouvelle limite utile.
Effectuez un test avec le transfert de fichiers le plus lourd pendant que les charges de travail invitées prévues sont actives. Écartez l’option hyperviseur si la concurrence processeur, la pression sur la mémoire ou le redémarrage d’un invité peut interrompre le stockage d’une manière que l’architecture installée directement sur le matériel aurait évitée.
Comparez les chemins de récupération avant de comparer les fonctionnalités
Un deuxième cas de transmission, concernant un HBA et un pool TrueNAS existant, montre pourquoi l’ordre de démarrage et le comportement du micrologiciel doivent faire partie du plan de récupération. Le pool lui-même peut être intact alors que la machine virtuelle suit toujours 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é d’hyperviseur ne suffit pas s’il dépend du même hôte défaillant ou s’il ne peut pas recréer le mappage des appareils ; une exportation de configuration du système d’exploitation de stockage ne suffit pas non plus si vous n’avez jamais importé le pool sur un matériel de remplacement.
| Événement de récupération | Le système d’exploitation de stockage possède les disques | L’hyperviseur possède la plateforme |
|---|---|---|
| Défaillance du périphérique de démarrage | Réinstaller, importer le pool, restaurer la configuration | Reconstruire l’hôte, restaurer la définition de la machine virtuelle, puis importer ou connecter le stockage |
| Défaillance du contrôleur | Déplacer les disques vers un chemin compatible et importer | Remplacer le chemin de transmission compatible avant que l’invité ne voie les disques |
| Défaillance de l’invité de stockage | Sans objet | Restaurer l’invité sans modifier la propriété du pool physique |
| Échec de la mise à jour de l’hôte | Restauration ou réinstallation du système d’exploitation de stockage | Le stockage et chaque invité peuvent attendre la récupération de l’hôte |
| Migration matérielle | Importer le pool sur un hôte de stockage pris en charge | Recréer d’abord les dépendances de transmission et de l’invité |
Choisissez la couche correspondant au principal domaine de défaillance
Choisissez la gestion du stockage directement sur le matériel lorsque le partage de fichiers est le rôle principal, que l’état direct des disques et l’importation simple du pool sont importants, ou que le Mini PC ne peut pas isoler proprement un contrôleur. N’exécutez que les applications dont vous acceptez de coupler les défaillances à celles de l’hôte de stockage.
Choisissez d’abord un hyperviseur lorsque vous pouvez nommer plusieurs invités indépendants, que les chemins de l’hôte et des appareils de données sont séparés et que vous avez déjà testé la transmission, l’ordre de démarrage, les mises à jour de l’hôte et la récupération. Pour une question plus large sur le rôle logiciel, la décision entre un système d’exploitation NAS et Linux généraliste constitue la prochaine distinction utile.
Arrêtez 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 simplicité d’utilisation ou la qualité du tableau de bord n’entre en jeu.
Produits recommandés
Comparaisons de produits
Plus à lire
LXC vs Docker sur Proxmox pour les mises à jour et les restaurations d’applications
Docker offre un contrôle des versions au niveau de l’application ; LXC permet un retour en arrière au niveau du système invité. Le meilleur...
Limites de sécurité de Docker par rapport à LXC pour les services domestiques privilégiés
Docker convient aux applications empaquetées de manière ciblée ; LXC convient à des services Linux plus complets, mais aucun des deux ne remplace une...
Système d’exploitation NAS clé en main vs Linux modulaire pour un débutant
Choisissez un logiciel NAS clé en main pour des opérations de stockage guidées ; choisissez Linux modulaire lorsque l’apprentissage et un contrôle explicite justifient...
