Le dimensionnement de la mémoire VDI échoue lorsque les équipes comptent les utilisateurs au lieu des ensembles de travail. Voici un guide brutal de la RAM serveur pour VDI, avec des formules, des exemples de dimensionnement, une marge de manœuvre pour le basculement et les pièges de l'approvisionnement qui nuisent au temps de fonctionnement.
Commencez par les utilisateurs.
La plupart des feuilles de calcul de dimensionnement de la mémoire VDI semblent professionnelles parce qu'elles contiennent des lignes, des formules et quelques hypothèses bien rangées, mais la véritable faiblesse est généralement enfouie dans une cellule paresseuse : “RAM moyenne par utilisateur”, copiée d'un ancien pilote, arrondie à l'inférieur pour protéger le budget, et jamais testée contre les connexions du lundi matin. Qui signe cela et s'attend à des tickets d'assistance calmes ?
Je ne fais pas confiance aux moyennes dans la VDI. Je fais confiance à la simultanéité, à l'ensemble de travail mesuré, aux tempêtes de démarrage, au comportement des profils, à la politique graphique, à la synchronisation de l'antivirus, aux limites NUMA et à l'horrible question à laquelle aucune diapositive de fournisseur ne veut répondre : que se passe-t-il lorsqu'un hôte disparaît à 9 h 12 du matin ?
C'est là que le dimensionnement de la mémoire VDI devient réel.
Le site de Microsoft conseils sur le dimensionnement de la machine virtuelle de l'hôte de session fait la même remarque de manière polie : le type de charge de travail, le nombre d'utilisateurs, les besoins en ressources, les délais de connexion et la marge de manœuvre ont tous leur importance, et Microsoft prévient que les machines virtuelles peuvent représenter un coût de capacité de 15 à 20% par rapport aux machines nues, tandis que les temps de réponse des utilisateurs peuvent être supérieurs de 10 à 20% en raison de la surcharge de l'hyperviseur.
Donc, non, “100 utilisateurs × 4GB = 400GB” n'est pas un plan. Il s'agit d'une serviette de table avec des problèmes de confiance.
Voici la version propre :
Mémoire totale de l'hôte = mémoire VM/session + réserve OS/hyperviseur + graphique/profil/cache + marge de manœuvre pour le basculement + tampon opérationnel
Cela semble ennuyeux.
Les bonnes tailles sont ennuyeuses.
Le mauvais dimensionnement devient excitant au moment précis où la finance, les opérations et le DSI se demandent tous pourquoi la nouvelle infrastructure de bureau virtuel semble plus lente que les ordinateurs portables qu'elle a remplacés.
Pour un premier modèle de dimensionnement de la RAM VDI, je diviserais la population d'utilisateurs en quatre classes de travail :
| Classe d'utilisateurs | Applications typiques | Hypothèse de RAM de départ par utilisateur | Notes que je n'ignorerais pas |
|---|---|---|---|
| Travailleur à la tâche | Navigateur, écran ERP, Office léger | 2-3GB | Observer la croissance des onglets du navigateur et le comportement de délestage des équipes |
| Travailleur du savoir | Office, navigateur, PDF, CRM, light BI | 4-6GB | La plupart des “utilisateurs moyens” sont vraiment ici, pas dans le seau à lumière |
| Utilisateur expérimenté | Modèles Excel, PDF volumineux, bases de données locales, outils de développement | 8-12GB | La pression de la mémoire peut augmenter rapidement pendant les périodes de déclaration |
| Utilisateur graphique / ingénieur | Visionneuse CAO, 3D, SIG, vidéo, outils de conception | 12-32GB | La mémoire tampon du GPU, le profil vGPU et le nombre d'affichages modifient les calculs. |
Ce tableau ne remplace pas les mesures. Il permet d'arrêter de prétendre que tous les utilisateurs se comportent de la même manière.
Le tableau Azure Virtual Desktop de Microsoft fournit des points d'ancrage utiles : les exemples de sessions simples légères, moyennes et lourdes correspondent respectivement à 2 vCPU/8GB RAM, 4 vCPU/16GB RAM et 8 vCPU/32GB RAM ; pour les hôtes multisessions, Microsoft suggère un nombre maximal d'utilisateurs par vCPU de 6 pour les charges légères, 4 pour les charges moyennes et 2 pour les charges lourdes, avec 8 vCPU/16GB RAM comme configuration minimale de la VM pour ces exemples.
Voici la dure vérité : le CPU est souvent blâmé en premier parce que les graphiques du CPU sont bruyants, mais la mémoire est l'endroit où la VDI devient silencieusement méchante. Une fois que l'hôte commence à gonfler, compresser, échanger, paginer ou punir le stockage parce que la RAM était sous-dimensionnée, l'utilisateur ne dit pas “contention de la mémoire”. L'utilisateur dit : “La VDI est une poubelle”.”
Un courtier n'est pas magique.
VMware Horizon, Citrix Virtual Apps and Desktops et Azure Virtual Desktop peuvent tous être bien conçus, mais aucun d'entre eux n'annule l'arithmétique ; si l'hôte a 768 Go installés et que votre demande réelle à l'état stable plus la demande de basculement est de 850 Go, la marque de la plateforme ne change que le logo sur le rapport d'incident. Pourquoi tant d'équipes continuent-elles à faire leurs achats en fonction du nom de la plateforme avant les preuves de la charge de travail ?
Pour le dimensionnement de la mémoire de VMware Horizon, je commencerais par l'affectation du système d'exploitation du poste de travail, la conception du profil, le protocole d'affichage et le modèle de pool. Les postes de travail persistants se comportent différemment des pools non persistants. Windows 10 et Windows 11 se comportent différemment après les mises à jour. Un “point de départ” de 2 Go pour un poste de travail de base peut figurer dans la documentation du fournisseur, mais une fois que les applications Microsoft 365, l'isolation du navigateur, Teams, la synchronisation OneDrive, les agents de sécurité et les conteneurs de profil arrivent, ce chiffre devient un plancher, et non un objectif de production.
Pour les exigences de RAM de Citrix VDI, la politique HDX et les graphiques sont importants. Les exigences système actuelles de Citrix pour HDX 3D Pro indiquent que l'ordinateur hôte doit disposer d'au moins 4 Go de RAM et de quatre vCPU à 2,3 GHz ou plus, et Citrix note également des conseils sur les périphériques utilisateurs tels que 4 Go de RAM minimum et 8 Go de RAM pour des performances optimales du côté des terminaux. Ce détail sur les terminaux ne dimensionne pas le serveur, mais il nous rappelle que l'affichage, le GPU et le comportement de la session font partie de la chaîne complète.
En ce qui concerne Azure Virtual Desktop, les conseils de Microsoft sont utiles parce qu'ils indiquent clairement la partie la plus discrète : la planification de la capacité doit couvrir le type de charge de travail, le nombre d'utilisateurs simultanés, les besoins en ressources, les périodes de connexion, les pics de charge et la marge de manœuvre.
Mon avis : si votre plan VDI n'inclut pas un calcul de l'hôte défaillant, il ne s'agit pas d'une planification de la capacité. C'est de l'optimisme en matière de capacité.
Prenons un exemple concret.
Supposez 400 travailleurs intellectuels simultanés. Vous mesurez, et non devinez, et vous trouvez un objectif réaliste de 5 Go de RAM par session active une fois qu'Office, le navigateur, les applications métier, l'activité du conteneur de profil et l'outil de sécurité se sont stabilisés.
Mémoire de la session de base :
400 utilisateurs × 5GB = 2 000GB
Ajoutez maintenant la plate-forme et la réserve d'exploitation. J'ai l'habitude de séparer ces deux éléments, car le fait de cacher la réserve dans le numéro d'utilisateur crée de mauvais arguments par la suite.
Exemple de réserve :
2 000 GIGAOCTETS × 15% = 300 GIGAOCTETS
Ajoutez maintenant un tampon opérationnel pour les tempêtes de connexion, les bizarreries des jours de correctifs, le gonflement des navigateurs et le bruit de la surveillance :
2 300 GIGAOCTETS × 20% = 460 GIGAOCTETS
Sous-total :
2 760 GO
Ajoutez maintenant le basculement N+1. Si vous utilisez 5 hôtes et qu'un hôte tombe en panne, les 4 autres doivent absorber la charge. Cela signifie que l'objectif de capacité utilisable par hôte n'est pas le total de la RAM installée divisé par la demande du chemin heureux. Il s'agit de la demande totale divisée par les hôtes survivants.
2 760 Go ÷ 4 hôtes survivants = 690 Go de mémoire utilisable par hôte
Cela ne signifie pas qu'il faille installer exactement 690 Go. Cela signifie que le plan de mémoire de votre serveur doit tenir compte des règles de population de mémoire, de l'équilibre des canaux, de la taille des modules DIMM, de l'expansion future et du fait qu'un serveur à deux sockets n'aime pas le chargement négligé des emplacements.
C'est ici que je cesserais de lire les brochures et que je commencerais à vérifier la stratégie réelle du module : Mémoire serveur DDR4 pour les mises à jour courantes qui fonctionnent encore sur des plates-formes d'entreprise étendues, Mémoire serveur DDR5 pour les nouveaux hôtes à densité élevée, et vérification de la compatibilité de la mémoire du serveur avant que quiconque n'achète une palette de modules en se basant uniquement sur la capacité.
Un module DIMM de 64 Go peut toujours être le mauvais module DIMM de 64 Go.
Dans les environnements VDI, je m'intéresse aux ECC RDIMM par rapport aux LRDIMM, aux DDR4 par rapport aux DDR5, aux 2Rx4 par rapport aux 4Rx4, à l'équilibre des canaux, aux DIMM par canal, au downclocking de la vitesse de la mémoire, à la génération du CPU, à la prise en charge du BIOS et au fait que le devis mentionne le numéro de pièce exact du fabricant ou simplement une étiquette de capacité sympathique. Il s'agit là d'une question d'hygiène en matière d'approvisionnement, et non d'une question de nerd.
Les pages de ServerDIMM consacrées à la mémoire pour serveurs montrent pourquoi le chemin d'accès interne est important : le site distingue les nouvelles mémoires DDR4, les nouvelles mémoires DDR5, les mémoires d'occasion, les marques telles que Samsung, Micron, Kingston et SK Hynix, ainsi que les supports de qualité et de garantie pour l'examen de la compatibilité et les tests.
Pour un hôte VDI, je préférerais acheter une vitesse de tête légèrement inférieure et obtenir une capacité validée, des canaux équilibrés, un comportement ECC et une documentation RMA propre. Le commerce inverse relève de l'amateurisme.
L'étude de production de Google Erreurs de DRAM dans la nature a constaté des erreurs de mémoire dans un grand parc de serveurs sur une période de 2,5 ans, couvrant plusieurs millions de jours DIMM, avec des taux d'erreur DRAM observés de 25 000 à 70 000 erreurs par milliard d'heures d'appareil par Mbit et plus de 8% de DIMM affectés par des erreurs par an.
Une étude ultérieure du centre de données de production Alibaba/CUHK, Une étude corrélative approfondie entre les erreurs de DRAM et les pannes de serveur, a analysé plus de 3 millions de modules de mémoire dans 250 000 serveurs sur une période de huit mois, y compris 2 137 pannes de serveurs causées par des erreurs de DRAM ; l'article a révélé que pour plus de 40% de ces pannes, des erreurs de DRAM corrigibles sont apparues dans l'heure qui a précédé la panne.
C'est pourquoi je ne considère pas l'ECC, la validation et la clarté des lots comme facultatifs. Dans une VDI dense, un problème de mémoire n'est pas le problème d'un seul utilisateur. C'est un générateur de plaintes à l'échelle de l'étage.
Voici un tableau de planification brutal des besoins en mémoire des serveurs VDI. Il ne s'agit pas d'une nomenclature finale. Il s'agit d'une amorce de conversation qui permet d'éviter une densité fantaisiste.
| Scénario | Exemple de nombre d'utilisateurs | Objectif de RAM par utilisateur | Mémoire active de base | Ajouter une réserve et un tampon | Véritable note de planification |
|---|---|---|---|---|---|
| Postes de travail légers groupés | 300 | 3GB | 900GB | 1,2-1,4 TO | Sûr uniquement si le navigateur, les équipes et les agents de sécurité sont contrôlés |
| VDI pour travailleurs intellectuels | 400 | 5GB | 2TB | 2,6-3,0 TO | La plupart des déploiements de bureaux atterrissent ici après avoir été mesurés |
| Pool d'utilisateurs | 150 | 10GB | 1,5 TO | 2,0-2,4 TO | Moins de densité, plus de satisfaction |
| Graphique VDI | 80 | 20GB | 1,6 TO | 2,2 TO + | Le profil vGPU, le nombre d'écrans et le comportement de l'application déterminent le nombre final. |
| Domaine mixte | 600 | Segmenté | Ne pas faire la moyenne à l'aveuglette | Modèle par personne | Une grande moyenne cache les utilisateurs qui enfreignent la ferme |
J'obligerais également le service financier à se pencher sur le calcul des pannes. L'Uptime Institute Enquête mondiale sur les centres de données 2024 a indiqué que 54% des personnes interrogées ont déclaré que leur dernière panne importante avait coûté plus de $100 000, tandis que 20% ont déclaré une panne de plus de $1 million.
Comparez maintenant ce chiffre au coût de l'ajout d'une marge de manœuvre avant le déploiement. Soudain, “trop de RAM” semble moins inutile.
Et le marché de la mémoire n'est pas très favorable. Reuters a rapporté le 5 janvier 2026 que la demande d'infrastructures d'IA avait provoqué une pénurie mondiale de mémoires, les prix de certaines mémoires ayant plus que doublé depuis février 2025 et les analystes s'attendant à ce que la reprise se poursuive jusqu'en 2027.
Mon conseil d'achat est donc simple : ne pas sous-dimensionner maintenant et supposer une expansion bon marché plus tard. Cette hypothèse a du mordant.
Ne commencez pas par “500 utilisateurs”. Commencez par les utilisateurs de tâches, de connaissances, de pouvoir, de graphiques, de kiosques, d'entrepreneurs, de développeurs et de cadres. Oui, les cadres comptent. Ils sont souvent les premiers à remarquer que les connexions sont lentes.
La mémoire vive attribuée est un plafond. L'ensemble de travail est un comportement. Suivez l'utilisation de la mémoire pendant la connexion, le travail régulier, les réunions vidéo, les fenêtres de rapport, les périodes de navigation intensive et les écritures de profil de fin de journée.
Un domaine de 1 000 utilisateurs peut avoir 620 sessions simultanées de pointe. Ou 910. La différence réside dans l'achat de matériel.
Il s'agit d'ESXi, de vSphere, d'Hyper-V, d'AHV, du système d'exploitation de l'hôte, des agents de surveillance, de l'EDR, des outils de sauvegarde, des gestionnaires de vGPU et de tout ce qui se trouve sur ou autour de l'hôte.
Si vous ne pouvez pas survivre à une perte d'hôte, inscrivez-le dans le registre des risques. Ne le cachez pas dans la feuille de calcul.
Utilisez le modèle de serveur exact, la génération de CPU, le guide de population DIMM, le type de module pris en charge, le rang et la vitesse. Lorsque la nomenclature devient sérieuse, j'utiliserais ServerDIMM's fournisseur de RAM pour serveur en vrac chemin pour la planification du volume, puis vérification croisée les tests de qualité et l'aide à la garantie avant le déploiement.
Pilotez avec de vrais utilisateurs, et non avec du personnel informatique qui se comporte gentiment pour un test. Capturez les données de charge de type Login VSI si vous les avez. Utilisez la surveillance native si vous n'en avez pas. Mais mesurez.
Le premier piège consiste à mélanger la mémoire avec la RAM d'un ordinateur de bureau. Les hôtes VDI ne sont pas des PC de jeu avec une activité secondaire. Les règles RDIMM et LRDIMM sont importantes. La symétrie des canaux est importante. La population de sockets de l'unité centrale est importante.
Le deuxième piège consiste à acheter en fonction de la vitesse plutôt que de l'adéquation. Un module DDR5-5600 peut s'entraîner moins vite en fonction du CPU, de la population de DIMM par canal, du BIOS et des règles de la plate-forme. Si le serveur fonctionne en DDR5-4800 dans votre configuration, l'autocollant n'a pas menti, c'est votre hypothèse qui l'a fait.
Le troisième piège consiste à confondre bon marché et contrôle. La RAM d'occasion peut s'avérer tout à fait judicieuse dans le cadre de projets de maintenance ou d'expansion, mais uniquement lorsque l'origine, les tests, la classe de modules et la compatibilité sont gérés de manière transparente. C'est pourquoi Mémoire serveur DDR4 utilisée et Mémoire serveur DDR5 utilisée doivent être évaluées comme des options d'approvisionnement contrôlées, et non comme des suppositions d'aubaine.
Ma règle : si le devis ne peut pas m'indiquer la capacité exacte, la génération DDR, l'état ECC, la classe RDIMM/LRDIMM, le rang, la vitesse, la marque, le numéro de pièce, l'état testé et le processus de garantie, ce n'est pas un devis de mémoire VDI. Il s'agit d'un document de transfert de risque.
Le dimensionnement de la mémoire VDI consiste à calculer la quantité de mémoire vive du serveur physique nécessaire pour prendre en charge les bureaux virtuels ou les sessions publiées dans des conditions réelles de charge de travail, de concurrence, de surcharge et de basculement. Il comprend la demande de mémoire par utilisateur, la réserve de l'hyperviseur, le comportement du profil, les exigences graphiques, la mémoire tampon opérationnelle et la planification de la capacité de perte d'hôte.
En clair, il répond à une question : les utilisateurs disposeront-ils encore d'un bureau utilisable lorsque tout le monde se connectera, que les applications deviendront lourdes et qu'un hôte tombera en panne ?
Vous calculez la mémoire pour la VDI en multipliant les utilisateurs simultanés par la demande de RAM mesurée par utilisateur, puis en ajoutant la réserve de l'hyperviseur, les frais généraux du système d'exploitation du bureau, les frais généraux des graphiques ou des profils, la marge opérationnelle et la capacité de basculement. Le modèle le plus sûr sépare les classes de charge de travail des utilisateurs au lieu d'appliquer une moyenne à l'ensemble de l'environnement.
Une formule pratique est la suivante : utilisateurs simultanés × RAM par utilisateur + 15-25% de réserve + 20-30% de mémoire tampon + N+1 failover. Il faut ensuite le valider dans le cadre d'un projet pilote.
Un serveur VDI a besoin de suffisamment de mémoire vive pour prendre en charge les postes de travail virtuels ou les sessions qui lui sont attribués lors des pics de fréquentation, tout en laissant de la place pour les frais généraux de l'hyperviseur, les tempêtes de connexion, le basculement et les opérations de maintenance. Dans de nombreux environnements professionnels, cela signifie des centaines de gigaoctets à plusieurs téraoctets par cluster hôte, et non un nombre universel unique.
Un hôte à deux sockets avec 512 Go peut convenir à un pool et être imprudent pour un autre. C'est la charge de travail qui décide.
Une RAM de 4 Go peut être suffisante pour un utilisateur VDI léger ou modéré exécutant des applications bureautiques contrôlées, mais elle est souvent trop faible pour un travail moderne nécessitant un navigateur, Microsoft 365 Apps, Teams, des agents de sécurité et des conteneurs de profil. Considérez 4 Go comme une hypothèse de départ, et non comme une preuve de l'aptitude à la production.
Je le testerais en fonction du temps de connexion réel et du comportement réel du navigateur avant de le défendre lors d'une revue de conception.
La capacité de la RAM est généralement plus importante que la vitesse de la RAM pour la VDI lorsque l'environnement est soumis à une pression de mémoire, car le swapping, le ballooning et la pagination nuisent à l'expérience de l'utilisateur de manière plus visible que de petites différences dans la fréquence de la mémoire. La vitesse reste importante sur les plateformes modernes et denses, mais la capacité validée et la population correcte sont prioritaires.
Je préfère utiliser des RDIMM ECC stables dans une configuration équilibrée plutôt que de courir après des MT/s que le serveur ne peut pas maintenir.
Les hôtes VDI doivent utiliser le type de mémoire pris en charge par la plateforme du serveur, le plus souvent ECC RDIMM pour les configurations d'entreprise classiques et LRDIMM lorsqu'une capacité plus élevée par hôte est requise et officiellement prise en charge. Les mémoires RDIMM et LRDIMM ne doivent pas être mélangées, à moins que la documentation de la plate-forme ne prenne explicitement en charge cette configuration exacte.
Pour la VDI de production, “ça rentre dans la fente” n'est pas une question de compatibilité.
Voici ma position définitive : Le dimensionnement de la mémoire VDI n'est pas un exercice d'achat. Il s'agit d'un exercice de prévention des pannes déguisé en nomenclature.
Commencez par segmenter les utilisateurs. Mesurer l'ensemble de travail. Ajoutez une marge de manœuvre. Modélisez la survie de l'hôte défaillant. Respectez les directives de VMware Horizon, Citrix et Azure Virtual Desktop, mais ne laissez pas les minimums des fournisseurs devenir votre objectif de production. Ensuite, achetez la RAM du serveur comme un adulte : type de module exact, comportement ECC, règles de population, clarté du numéro de pièce, inventaire testé, et un chemin de garantie qui ne disparaîtra pas lorsque le déploiement commencera.
Pour l'étape suivante, créez une feuille de travail d'une page sur la mémoire VDI avec les classes d'utilisateurs, les pics de concurrence, les objectifs de RAM par utilisateur, le nombre d'hôtes, le basculement N+1 et la configuration DIMM cible. Envoyez ensuite le modèle de serveur, la génération du processeur, la configuration actuelle de la mémoire, la capacité cible, la classe de module DDR4 ou DDR5 préférée et la quantité par l'intermédiaire de l'interface de ServerDIMM contact et chemin d'accès au devis afin que la compatibilité puisse être vérifiée avant que l'approvisionnement ne se transforme en dépannage.
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
