La plupart des équipes ne manquent pas de mémoire vive. Elles manquent d'une planification honnête de la capacité. Voici comment dimensionner la mémoire des hôtes de virtualisation comme les opérateurs devraient le faire, en utilisant des ensembles de travail, une réserve d'hôte, une marge de basculement et le comportement réel de la plate-forme au lieu des contes de fées des fournisseurs.
Pas autant. Pas aussi peu non plus.
Je vais être franc : les conseils habituels sur les besoins en mémoire des hôtes de virtualisation sont bâclés parce qu'ils traitent la RAM configurée des VM comme s'il s'agissait de la même chose que la demande de mémoire vive, même si Microsoft, Red Hat et VMware documentent tous la récupération de mémoire, le comportement au démarrage par rapport à l'état stable ou les mécanismes d'overcommit qui rendent ce raccourci peu fiable dans la production. Pourquoi prétendons-nous encore que la somme d'une feuille de calcul équivaut à la réalité ?
La dure vérité est la suivante : un hôte de virtualisation a réellement besoin de suffisamment de RAM physique pour quatre catégories en même temps - la réserve de l'hôte, les frais généraux de l'hyperviseur, les ensembles de travail des VM et la marge opérationnelle pour le redémarrage, le basculement ou les fenêtres de correctifs. Si vous dimensionnez uniquement en fonction de la mémoire d'invité provisionnée, vous ne planifiez pas la capacité, vous achetez de l'espoir.
Trois mots d'abord. Arrêtez de deviner maintenant.
Une VM à laquelle 16 Go ont été attribués ne consomme pas automatiquement 16 Go d'une manière qui justifie l'achat d'un autre plateau de modules DIMM, car Hyper-V sépare la RAM de démarrage, la RAM minimale, la RAM maximale et la mémoire tampon, tandis que KVM traite les invités comme des processus Linux dont la mémoire est allouée à la demande, et VMware prévient explicitement que la mémoire au-delà de l'ensemble de travail d'une VM ne devient souvent que de la mémoire cache et des frais généraux supplémentaires. Pourquoi acheter du silicium pour les pages de cache inactives ?
Ma règle est simple et, oui, je m'y fie plus qu'aux brochures commerciales :RAM de l'hôte = réserve de l'hôte + frais généraux de l'hyperviseur/VM + ensemble de travail de la VM à l'état stable + marge de manœuvre pour le basculement/redémarrage
Cette formule est ennuyeuse. C'est bien. L'ennui est ce qui maintient les clusters en vie à 2h13 du matin, lorsqu'un nœud redémarre et que chaque exception “temporaire” devient soudain votre problème. Microsoft indique qu'Hyper-V réserve de la mémoire pour le système d'exploitation hôte de gestion et n'utilise la pagination intelligente que comme un pont temporaire pendant les redémarrages ; Red Hat indique que le surcommit de mémoire n'est pas une solution idéale pour les pénuries générales et publie une règle de base consistant à laisser jusqu'à 4 Go pour le système d'exploitation hôte, plus au moins 4 Go d'espace de pagination sur les hôtes KVM.
Je déteste les fausses équivalences.
Les gens parlent d'ESXi, d'Hyper-V et de KVM comme s'ils géraient tous la mémoire de la même manière, mais il s'agit là d'un discours d'opérateur paresseux : Hyper-V propose des contrôles dynamiques pour le démarrage, le minimum, le maximum et la mémoire tampon ; KVM s'appuie sur la gestion de la mémoire Linux et le swap ; VMware traite l'overcommit comme un problème d'empreinte de travail et s'appuie sur des méthodes de récupération telles que le ballooning lorsque la pression augmente. Même objectif, douleur différente.
| Plate-forme | Ce que disent les documents du fournisseur | Ce que je pense que cela signifie en pratique |
|---|---|---|
| VMware ESXi / vSphere | L'overcommit commence lorsque l'empreinte combinée de la mémoire de travail des VM dépasse la mémoire de l'hôte ; VMware note également que la mémoire attribuée au-delà de l'ensemble de travail se transforme généralement en cache de l'invité et augmente la surcharge des VM. | Ne pas dimensionner uniquement en fonction de la vRAM totale attribuée. Dimensionner en fonction de la mémoire active observée, puis garder de la place pour la récupération afin qu'elle reste rare et non constante. |
| Microsoft Hyper-V | Hyper-V réserve de la mémoire pour le système d'exploitation de gestion et utilise la RAM de démarrage, la RAM minimale, la RAM maximale, la mémoire tampon et la pagination intelligente pour gérer la pression d'exécution et la fiabilité du redémarrage. | Séparez les besoins de démarrage des besoins en régime permanent, sinon vous surdimensionnerez toutes les machines virtuelles pour toujours. |
| KVM / Red Hat | Les invités n'obtiennent pas de blocs physiques dédiés en permanence ; l'hôte Linux alloue la mémoire à la demande. Red Hat indique que l'overcommit n'est pas le bon remède aux pénuries générales et conseille de laisser la mémoire et l'échange à l'hôte. | Traitez l'hôte comme un système Linux vivant, et non comme un firmware invisible. Si le swap est constamment occupé, votre dimensionnement était erroné. |
Quel est donc l'enseignement pratique à en tirer ?
Si vous exécutez une virtualisation dense et mixte, je préférerais voir un hôte avec une marge de manœuvre réelle plutôt qu'un hôte se vantant d'avoir des ratios de consolidation héroïques. Les directives de VMware indiquent clairement que la récupération existe, mais cela ne signifie pas qu'il faille réduire la taille au point que le gonflement et l'échange fassent partie de la vie normale. Ce n'est pas de l'efficacité. C'est une panne au ralenti.
Maintenant, ça devient cher.
Selon le ministère américain de l'énergie, les centres de données utiliseront environ 4,4% de l'électricité totale des États-Unis en 2023, passant de 58 TWh en 2014 à 176 TWh en 2023, et le ministère de l'énergie estime que ce chiffre pourrait atteindre 325 à 580 TWh d'ici 2028, soit environ 6,7% à 12% de l'électricité totale des États-Unis. Surdimensionner les hôtes “juste pour être sûr” n'est plus gratuit ; cela se répercute sur les budgets d'alimentation, de refroidissement, de densité des racks et d'approvisionnement.
Et les temps d'arrêt sont toujours aussi brutaux.
Les Analyse des pannes de l'Uptime Institute en 2024 Selon l'étude, 54% des personnes interrogées ont déclaré que leur dernière panne importante avait coûté plus de $100 000, et 16% ont déclaré qu'elle avait coûté plus de $1 million ; l'étude a également révélé que quatre personnes interrogées sur cinq pensaient que leur dernière panne importante aurait pu être évitée avec une meilleure gestion, un meilleur processus ou une meilleure configuration. Si les besoins en mémoire de votre hôte VM sont basés sur des suppositions, vous jouez avec six ou sept chiffres pour économiser quelques lignes dans une feuille de calcul de capacité. Intelligent ?
La plupart des articles de blog polis évitent également la question de l'octroi de licences.
En avril 2024, Reuters a rapporté que les régulateurs de l'UE ont interrogé Broadcom sur les modifications apportées aux licences VMware à la suite de plaintes déposées par des utilisateurs professionnels et des groupes commerciaux. Je ne dis pas que le dimensionnement de la mémoire résout à lui seul les problèmes de licence. Je dis qu'une planification bâclée de la mémoire est encore plus difficile à défendre lorsque l'économie de la plate-forme est sous surveillance et que chaque hôte supplémentaire ou cycle de rafraîchissement est désormais examiné ligne par ligne.
Voici le modèle.
Je commence par la réserve de l'hôte, car prétendre que l'hôte est en apesanteur est l'une des habitudes les plus stupides en matière de virtualisation. Hyper-V garde explicitement de la mémoire pour le système d'exploitation de gestion, et Red Hat dit explicitement que l'hôte KVM a besoin de sa propre RAM et de son propre budget d'échange, donc je ne laisse jamais “disponible pour les machines virtuelles” être égal à “installé dans le châssis”.”
Je m'intéresse alors à la demande en régime permanent, et non à la demande en période de démarrage.
Pour Hyper-V, cela signifie qu'il faut séparer la RAM de démarrage de la mémoire stable inférieure que la mémoire dynamique peut récupérer après le démarrage, tandis que pour VMware, cela signifie qu'il faut vérifier si l'ensemble de travail est réellement actif ou si l'invité ne fait qu'accumuler de la mémoire cache. Pour KVM, cela signifie qu'il faut respecter le fait que l'overcommit peut fonctionner techniquement tout en restant une mauvaise habitude opérationnelle lorsque le swap et la contention commencent à faire le vrai travail.
Voici le tableau de planification que j'utiliserais avant d'acheter un seul module DIMM :
| Modèle de charge de travail | Ce qu'il faut compter en premier | Ce qu'il faut éviter | Mon parti pris |
|---|---|---|---|
| VM de production mixtes | Mémoire active observée, réserve d'hôtes et marge de manœuvre pour le basculement N+1 | Dimensionnement en fonction des totaux de vRAM configurés | Conservateurs |
| Environnements Hyper-V lourds | RAM de démarrage vs. RAM minimale vs. comportement de la mémoire tampon | Verrouiller à jamais la mémoire de chaque VM au démarrage | Modéré |
| Consolidation KVM | RAM de l'hôte, swap, demande réelle de l'invité | Traiter le surengagement comme un substitut à la capacité | Conservateurs |
| VDI / pools à faible charge | Demande d'exécution et comportement de redémarrage | En supposant que le ralenti est inoffensif sous la pression du redémarrage. | Modéré |
| Bases de données gourmandes en mémoire | Mémoire engagée maximale et événements HA | Miser sur le ballooning ou le swap pour vous sauver | Agressif seulement avec des preuves |
Qu'en pensez-vous ? Laissez suffisamment de RAM libre pour qu'une défaillance de l'hôte ou un événement de maintenance continue ne transforme pas le reste du cluster en chambre de panique. Je préférerais expliquer un ratio de consolidation légèrement inférieur à la finance plutôt que d'expliquer pourquoi les tempêtes de redémarrage ont poussé la pagination intelligente, le swapping ou le ballooning au premier plan.
Les modules DIMM sont également importants.
Si vous rafraîchissez des clusters plus anciens où le coût par Go est encore la règle, un catalogue tel que Mémoire serveur DDR4 utilisée est la conversation pratique, et non la théorie brillante ; si vous construisez des hôtes modernes plus denses, Mémoire serveur DDR5 devient la voie la plus réaliste, et les pages de catégorie en direct de ServerDimm montrent des pièces concrètes telles que Micron 64GB DDR5-5600 2RX4 et SK hynix 128GB DDR5-4800 2S2RX4 du côté de la DDR5. C'est le genre de détails d'inventaire que je souhaite obtenir avant d'approuver la nomenclature d'un hôte.
Le choix d'une marque n'est pas une question de religion. C'est une question de compatibilité et d'offre.
La structure actuelle du site de ServerDimm permet d'intégrer facilement cet aspect dans la logique d'achat : vous pouvez comparer Mémoire serveur DDR4 contre Modules de mémoire Micron pour serveurs ou Inventaire de la mémoire vive des serveurs Samsung, La gamme de produits visibles comprend des éléments tels que Samsung 64GB DDR4-3200 2RX4 et Micron 16GB DDR5-4800 1RX8. En d'autres termes, le site prend déjà en charge la conversation que les équipes de virtualisation devraient avoir : génération, densité, marque, et si le pool de rechange correspond au cluster que vous exécutez réellement.
Les tests ne sont pas facultatifs.
Le site les tests de qualité et l'assistance à la garantie pour les mémoires de serveurs est l'un des rares liens internes que je conserverais absolument dans cet article, car il traite directement de l'examen des spécifications, de l'adéquation du système, de la validation de la compatibilité et de l'assistance après-vente. C'est important, car la qualité d'un plan de mémoire dépend des modules qui arrivent, qui démarrent et qui survivent à une fenêtre de maintenance.
Les besoins en mémoire des hôtes de virtualisation correspondent à la mémoire physique totale dont un hôte a besoin pour faire fonctionner l'hyperviseur, le système d'exploitation hôte, les services de gestion, les ensembles de travail des machines virtuelles, les frais généraux de redémarrage et la marge de sécurité sans avoir à recourir à des mécanismes de ballooning, de swapping ou de pagination temporaire dans le cadre d'un fonctionnement quotidien normal.
C'est pourquoi je n'utilise pas la mémoire totale attribuée à l'invité comme chiffre principal de dimensionnement. J'utilise la demande observée plus la réserve de l'hôte plus suffisamment d'espace libre pour survivre aux événements de maintenance et de défaillance.
Un hôte de virtualisation a réellement besoin de suffisamment de RAM pour couvrir sa propre mémoire réservée, l'empreinte de la mémoire vive de ses machines virtuelles, les frais généraux de l'hyperviseur et une capacité supplémentaire pour les redémarrages, le basculement et les conditions de rafale, plutôt que de simplement correspondre à la mémoire totale configurée attribuée à chaque invité.
En clair, la bonne réponse est “plus que ce dont le système d'exploitation hôte a besoin, moins que la somme de tous les numéros de vanité des invités, et jamais trop serré pour que la récupération devienne normale”. Ce n'est pas une esquive. C'est de l'ingénierie honnête.
La surcharge de la mémoire dans la virtualisation est une fonction de la plate-forme qui permet à la mémoire totale attribuée à l'invité de dépasser la RAM physique de l'hôte, mais elle n'est sûre que lorsque les charges de travail réelles restent en dessous des seuils de pression et que l'opérateur traite la récupération comme un coussin d'urgence plutôt que comme le modèle d'entreprise par défaut pour la consolidation.
J'utilise l'overcommit dans le monde réel comme tampon contrôlé, en particulier dans les domaines mixtes ou éclatés. Mais je ne construis pas de plans de production qui dépendent du swapping, du ballooning ou de la pagination intelligente pour paraître compétents.
Les besoins en mémoire de l'hôte ESXi tournent autour de la pression et de la récupération de l'ensemble de travail, les besoins en mémoire de l'hôte Hyper-V tournent autour de la RAM de démarrage, de la RAM minimale, de la RAM maximale, de la mémoire tampon et de la réservation de l'hôte, tandis que les besoins en mémoire de l'hôte KVM dépendent fortement du comportement de l'hôte Linux, de la disponibilité de l'espace de pagination et de la question de savoir si l'overcommit masque une véritable pénurie.
Cette différence est la raison pour laquelle copier un ratio de dimensionnement sur les trois plates-formes est généralement une mauvaise idée. Même classe de problèmes, mécanismes de mémoire différents.
Le choix de la DDR4 ou de la DDR5 pour un hôte de virtualisation doit se faire en fonction de la génération de la plate-forme, de la densité cible, de la stratégie de réserve et des aspects économiques de l'approvisionnement, la DDR4 étant plus judicieuse pour les parcs installés plus anciens et la DDR5 plus judicieuse pour les nœuds denses plus récents qui bénéficient de la disponibilité de modules de plus grande capacité et de plus grande vitesse.
Si le cluster est ancien et que vous avez besoin d'une capacité validée et bon marché, la DDR4 reste une solution rationnelle. Si vous souhaitez une consolidation dense sur du matériel plus récent, la DDR5 est généralement le point final de la conversation.
Faites les calculs. Puis recommencez.
Si je publiais cet article sur ServerDimm, je ne me contenterais pas d'une vague inspiration. Je dirais aux lecteurs d'auditer leur réserve d'hôte actuelle, de comparer la mémoire active réelle des VM à la vRAM configurée, de décider de la marge de manœuvre N+1 ou de redémarrage dont ils ont réellement besoin, puis de fixer le prix du résultat par rapport à l'inventaire en temps réel dans Mémoire serveur DDR4, Mémoire serveur DDR5, et le site les tests de qualité et l'aide à la garantie avant d'acheter. Ensuite, si la nomenclature est réelle, je les pousserais directement à contacter l'équipe de ServerDimm avec les références, les capacités cibles et les détails du modèle hôte. C'est ainsi que la question “De quelle quantité de RAM ai-je besoin ?” devient une réponse qui survit à l'approvisionnement et à la production.
ServerDimm fournit des mémoires de serveur de marque, neuves et d'occasion, aux distributeurs, aux acheteurs OEM, aux revendeurs et aux équipes des centres de données. Nous prenons en charge l'approvisionnement en DDR4 et DDR5 avec des stocks testés, des vérifications de compatibilité et un service de devis réactif.
Copyright © 2026 Shenzhen Lux Telecommunication Technology Co.,Ltd. Tous droits réservés
