Niveau de travail NVMe ou pool entièrement en disques durs pour les images de machines virtuelles et les bases de données : lequel garantit une latence prévisible ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

NVMe Working Tier vs All-HDD Pool for VM Images and Databases: Which Keeps Latency Predictable? - Zima Store Online

Choisissez un niveau de travail NVMe dédié lorsque les images de VM et les bases de données génèrent des lectures aléatoires soutenues, des écritures synchrones, des instantanés ou des E/S simultanées qui font que le pool HDD met les requêtes en file d’attente. Choisissez un pool tout-HDD lorsque les machines virtuelles sont peu utilisées, que les bases de données sont petites et résident en mémoire, et que la capacité compte davantage qu’une latence prévisible. La plupart des serveurs personnels gourmands en stockage gagnent à séparer les données actives des données froides plutôt qu’à imposer une seule classe de support aux deux.

Commencez par le rôle du stockage, pas par l’étiquette du disque

Un niveau de travail NVMe n’est pas simplement un emplacement plus rapide pour chaque fichier. Il s’agit d’un pool volontairement plus petit destiné aux disques virtuels actifs, aux fichiers de bases de données, aux journaux, aux index et à d’autres données sensibles à la latence. Le pool HDD reste chargé des sauvegardes, des images d’installation, des modèles, des fichiers multimédias, des exportations et des volumes de VM inactifs.

Une conception tout-HDD simplifie la capacité et l’administration, mais elle regroupe des charges de travail aux comportements d’E/S très différents. Une seule tâche de sauvegarde, suppression d’instantanés, opération de scrub ou transfert important de fichiers multimédias peut accroître la pression sur les recherches au moment même où une base de données attend de petites opérations synchrones. La question essentielle est de savoir si ces interactions sont perceptibles dans la latence de l’application.

Axe de décision	Niveau de travail NVMe	Pool tout-HDD
Latence des E/S aléatoires	Faible et plus prévisible en cas de concurrence	Les recherches mécaniques créent des files d’attente et un temps de réponse variable
Coût de la capacité	Coût par téraoctet plus élevé	Idéal pour une grande capacité économique
Démarrage et mise à jour des VM	Traite efficacement de nombreuses petites requêtes	Acceptable pour quelques invités peu utilisés
Journaux et index de bases de données	Particulièrement adapté lorsque les écritures et les recherches sont fréquentes	Peut convenir lorsque les données sont peu volumineuses, mises en cache ou rarement modifiées
Instantanés et clones	Risque moindre de bloquer les invités actifs	Les tâches en arrière-plan peuvent entrer en concurrence avec les E/S des VM
Planification des défaillances	Nécessite une configuration NVMe protégée et une migration clairement définie	Fenêtre de reconstruction plus longue et davantage de données sur un même pool
Rôle principal	Données applicatives actives	Capacité, sauvegardes, archives et ressources de VM inactives

Quand un pool tout-HDD reste suffisamment performant

Le stockage sur HDD peut convenir à un petit lab avec une ou deux machines virtuelles peu actives, des démarrages peu fréquents et des bases de données dont les pages actives restent en RAM. Une VM de domotique, un invité Linux de test ou un service peu utilisé peut ne pas générer suffisamment d’E/S aléatoires simultanées pour justifier un niveau flash séparé.

L’option tout-HDD est également plus simple lorsque l’objectif principal est la capacité et que le propriétaire souhaite un seul pool protégé, une seule politique d’instantanés et une seule procédure de sauvegarde. Déplacer les données entre les niveaux ajoute une tâche de classification supplémentaire. Si le temps de réponse de l’application atteint déjà son objectif pendant les sauvegardes et les scrubs, le pool plus simple est le meilleur choix.

Il s’agit de la première limite à respecter : n’ajoutez pas de NVMe simplement parce que les images de VM et les fichiers de bases de données semblent exigeants. Ajoutez-en lorsque le temps d’attente du stockage, la profondeur de file d’attente ou la latence de queue augmente pendant la charge de service réelle.

Pourquoi les images de VM et les bases de données peuvent remettre en cause le modèle des HDD

Plusieurs machines virtuelles transforment un seul pool physique en de nombreux flux d’E/S indépendants. Les systèmes d’exploitation invités mettent à jour les paquets, effectuent la rotation des journaux, paginent la mémoire, analysent les systèmes de fichiers et écrivent les données des applications sans se coordonner entre eux. Les têtes des HDD doivent se déplacer entre ces requêtes. Le débit moyen peut donc sembler acceptable alors que certaines machines invitées se mettent en pause.

Les bases de données ajoutent une condition plus stricte. Les petites recherches aléatoires, les journaux, les journaux de transactions anticipées, les index et les validations synchrones dépendent du temps de réponse plutôt que de la vitesse de transfert en volume. Une comparaison actuelle des charges de travail des supports de stockage indique que les bases de données, les VM et les conteneurs sont des charges de travail pour lesquelles les E/S aléatoires et la latence comptent davantage que la capacité séquentielle.

La comparaison doit à nouveau s’arrêter si la contention du processeur, une mémoire vive insuffisante ou les verrous applicatifs restent la principale cause du ralentissement après le déplacement du disque virtuel vers le NVMe. Un niveau de travail ne peut pas résoudre les problèmes d’ordonnancement des calculs, de pression mémoire ou de requêtes inefficaces.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Ce que change le niveau de travail NVMe

Le principal avantage est l’isolation. Les disques actifs des VM et les fichiers de bases de données ne sont plus en concurrence avec les analyses de fichiers multimédias, les flux de sauvegarde ou les écritures de grandes archives sur le même pool mécanique. Le système peut conserver les données à grande capacité sur des HDD tout en réservant la mémoire flash à faible latence aux opérations qui bloquent la progression des applications.

Le NVMe raccourcit également les tâches de clonage, de création d’instantanés, de démarrage, d’application de correctifs et de maintenance des index. Cela peut réduire le temps pendant lequel un lab domestique reste dans un état dégradé ou nécessitant beaucoup de maintenance. Les recommandations de Melbicom sur l’utilisation du stockage NVMe et HDD placent de la même manière les VM sensibles à la latence et les données de type OLTP sur du NVMe, tout en conservant les HDD pour la capacité de stockage en volume.

Le gain n’est pas illimité. Un seul disque NVMe grand public sans redondance peut créer un niveau de services plus rapide, mais plus fragile. La limitation thermique, l’endurance limitée, une coupure de courant soudaine ou la défaillance d’un seul périphérique peuvent mettre plusieurs services actifs hors ligne simultanément.

La récupération et la migration peuvent inverser le choix de performance

Un pool entièrement composé de disques durs conserve toutes les données des machines virtuelles dans un seul modèle de protection et de restauration, mais sa capacité supérieure peut entraîner de longues périodes de reconstruction et de restauration. Une défaillance du pool peut affecter simultanément les machines invitées actives, les sauvegardes, les modèles et les archives, car ils partagent la même frontière de stockage.

Un niveau NVMe distinct réduit l’ensemble de données actives, ce qui peut accélérer la réplication et la restauration. Il exige également que le propriétaire sache précisément quels disques de machines virtuelles, répertoires de bases de données, journaux et états d’application appartiennent à ce niveau. Si seul le disque virtuel est protégé tandis qu’un chemin de base de données externe ou un secret reste ailleurs, la récupération est incomplète.

La comparaison existante de ZimaSpace sur la topologie de stockage pour les machines virtuelles fortement dépendantes du stockage renforce ce point : un stockage plus rapide n’est utile que si le chemin de défaillance reste compréhensible et reproductible.

Utilisez quatre mesures pour décider s’il faut scinder le pool

Enregistrez la latence du stockage et la profondeur de file d’attente pendant l’activité normale des machines virtuelles et des bases de données.
Répétez la mesure pendant les sauvegardes, le scrubbing, la suppression d’instantanés et les transferts de fichiers volumineux.
Mesurez le temps de réponse de l’application, et pas uniquement le débit du pool ou les IOPS synthétiques.
Vérifiez si la mémoire vive contient déjà les pages actives de la base de données et le cache du système de fichiers.
Déplacez une machine virtuelle ou une copie de base de données représentative vers le NVMe, puis répétez la même charge de travail.
Vérifiez que l’amélioration reste perceptible après prise en compte des limites du processeur, de la mémoire et du réseau.
Calculez la capacité NVMe protégée nécessaire pour les données actives, les instantanés et la croissance.

Le guide de ZimaSpace sur les charges NAS qui bénéficient du NVMe propose le test média complémentaire. La décision abordée dans cet article est plus ciblée : ces charges actives justifient-elles un niveau distinct au lieu de rester dans un pool entièrement composé de disques durs ?

Quelle architecture de stockage convient au serveur ?

Quand choisir une couche de travail NVMe

Choisissez le NVMe lorsque plusieurs machines virtuelles ou bases de données présentent une attente visible liée au stockage, lorsque les opérations en arrière-plan sur les disques durs provoquent des pauses, ou lorsque les instantanés et les clones perturbent les services actifs. Protégez cette couche avec une redondance ou une réplication adaptée et conservez suffisamment d’espace libre pour les instantanés, la croissance des bases de données et la maintenance.

Quand choisir un pool entièrement composé de disques durs

Choisissez un seul pool de disques durs lorsque les machines virtuelles sont peu sollicitées, que le temps de réponse reste acceptable pendant la maintenance et que la simplicité de la capacité constitue l’objectif principal. Si les mesures ne révèlent aucune charge de travail sensible aux performances du stockage flash, investissez d’abord dans la RAM, les sauvegardes et une architecture de pool cohérente.

Quand utiliser une architecture hybride

Pour la plupart des serveurs domestiques en croissance, conservez les disques actifs des machines virtuelles, les fichiers de bases de données, les index et les journaux sur du NVMe protégé. Conservez les sauvegardes, les modèles, les images ISO, les exportations, les médias et les volumes de machines virtuelles inactifs sur des disques durs. Définissez des règles de migration afin qu’une charge de travail change de couche parce que son comportement a évolué, et non parce que le nom d’un dossier semble important.

FAQ

Toutes les machines virtuelles doivent-elles être hébergées sur du NVMe ?

Non. Les machines virtuelles d’infrastructure qui écrivent rarement, les modèles éteints, les appliances de test et les disques virtuels froids peuvent rester sur des disques durs. Donnez la priorité aux machines virtuelles dont l’attente liée au stockage affecte un service réel ou plusieurs applications dépendantes.

Un cache SSD peut-il remplacer une couche NVMe dédiée ?

Parfois, lorsque les blocs actifs sont réutilisés de manière prévisible et que le cache reste chaud. Une couche dédiée offre un comportement plus déterministe pour les disques de machines virtuelles et les fichiers de bases de données qui doivent toujours bénéficier de la latence du stockage flash, notamment après un redémarrage ou une modification de la charge de travail.

Une base de données a-t-elle toujours besoin de NVMe ?

Non. Une petite base de données dont l’ensemble de travail tient en mémoire et dont le taux d’écriture est faible peut fonctionner correctement sur des disques durs. Le NVMe devient intéressant lorsque des attentes liées au stockage apparaissent lors des validations, dans les journaux, lors des opérations sur les index, des points de contrôle ou des requêtes simultanées.

Verdict final

Utilisez une couche de travail NVMe lorsque les images de machines virtuelles et les bases de données créent des files d’attente d’E/S aléatoires mesurables ou des pics de latence sur le pool de disques durs. Conservez une conception entièrement composée de disques durs lorsque les services restent peu sollicités et que la simplicité de la capacité est plus importante qu’une latence réduite. La meilleure architecture à long terme sépare l’état actif des applications du stockage en masse, tout en attribuant à chaque couche des plans indépendants de protection et de restauration.