AMD EPYC Turin : choisir le processeur de serveur adapté aux hébergeurs

Bien cerner l'AMD EPYC Turin

AMD EPYC Turin désigne la Génération EPYC 9005 de processeurs pour serveurs. AMD les a présentés en octobre 2024 comme la cinquième génération EPYC ; cette gamme comprend des modèles équipés de cœurs Zen 5 et Zen 5c.

Pour les hébergeurs, Turin n'est pas un processeur unique présentant des caractéristiques de performances homogènes. La gamme de modèles s'étend de 8 à 192 cœurs par processeur. Le choix du modèle approprié dépend du nombre de requêtes clients indépendantes traitées en parallèle, de la nécessité pour certaines applications de bénéficier de temps de réponse courts ou encore de la quantité de mémoire vive requise par les machines virtuelles.

Parmi les choix à faire figure également la question de la Nombre de socles: Un serveur équipé d'un seul processeur offre une combinaison différente de puissance de calcul, de connectivité mémoire et de possibilités d'extension par rapport à une plateforme à deux sockets. Tous les modèles ne sont pas prévus pour les deux variantes ; selon la fiche technique, les processeurs dont le nom se termine par « P » sont conçus pour les systèmes à socket unique.

La présélection commence donc par l'analyse de la composition concrète de la clientèle et des besoins en matière de RAM, de disques NVMe et de réseau. Un hébergeur VPS à forte densité a par exemple besoin de réserves pour les machines virtuelles actives simultanément, tandis qu’un serveur de base de données peut en outre s’adapter aux besoins en stockage et en E/S. Les licences logicielles et les autorisations accordées par le fabricant du serveur font également partie de la planification.

Le nombre de cœurs ne suffit pas à lui seul à déterminer combien d'hôtes existants peuvent être remplacés. Pour cela, le fournisseur a besoin de profils de charge et de mesures comparables concernant le matériel d'hébergement existant, ainsi que d'une réserve de disponibilité définie. Sans ces éléments de base, il est possible de choisir un modèle, mais pas de déterminer un taux de consolidation fiable.

Comprendre les cœurs, les chiplets et la fréquence d'horloge

Turin utilise un Conception de chiplets: Les unités de calcul et une puce d'E/S distincte sont reliées via l'AMD Infinity Fabric. La puce d'E/S assure notamment les connexions avec la mémoire vive et les périphériques d'entrée-sortie. Concrètement, pour la conception d'un serveur, cela signifie que ce ne sont pas seulement les cœurs qui comptent, mais aussi la connexion aux ressources partagées.

Les modèles Zen 5 et Zen 5c se distinguent par leur conception et l'organisation de leurs cœurs. Le Zen 5c offre la plus forte densité de cœurs au sein de cette génération ; cela ne permet toutefois pas d'établir un classement général en termes de performances. Un mélange de machines virtuelles fortement parallélisées et une application comportant peu de tâches sensibles à la latence peuvent favoriser des modèles différents.

L'EPYC 9965 dispose de 192 cœurs Zen-5c et de 384 threads, tandis que l'EPYC 9755 compte 128 cœurs Zen-5 et 256 threads. AMD annonce une fréquence boost maximale pouvant atteindre 3,7 GHz pour le 9965 et 4,1 GHz pour le 9755. Ces valeurs mettent en évidence des priorités différentes, mais ne remplacent en aucun cas une comparaison réalisée selon votre propre profil de charge.

La valeur indiquée boost maximal Il n'y a notamment aucune garantie quant à la stabilité de la fréquence d'horloge pour tous les cœurs. La fréquence atteinte en charge dépend, entre autres, de la charge et des conditions d'exploitation. Pour choisir un service d'hébergement, le débit et les temps de réponse pour un ensemble d'applications défini sont donc plus révélateurs que la valeur de pointe prise isolément.

Le nombre de threads, qui est toujours doublé, résulte de la technologie SMT : un cœur physique fournit deux threads logiques. Ceux-ci se partagent toutefois les ressources du cœur ; 384 threads ne correspondent ni à 384 cœurs physiques, ni à un doublement automatique de la puissance de calcul. Pour déterminer si la technologie SMT et la surallocation des ressources du processeur sont efficaces, il faut tenir compte de la charge client active simultanée.

La mémoire et les E/S limitent la capacité

De nombreux cœurs de processeur nécessitent une configuration mémoire adaptée. Selon AMD, l’EPYC 9005 prend en charge jusqu’à douze canaux de mémoire DDR5 par processeur. Pour un hôte de machines virtuelles, ce n’est pas seulement la capacité totale de la RAM qui compte : la répartition des modules et la bande passante mémoire disponible influencent également la capacité à prendre en charge efficacement les machines invitées actives simultanément.

La fiche technique indique, pour les modèles mentionnés, une vitesse pouvant atteindre DDR5-6400 à un module DIMM par canal. La vitesse réellement utilisable dépend de la configuration matérielle et de la validation de la plate-forme. De même, la capacité maximale de 6 To de DDR5 mentionnée dans la fiche technique se réfère aux configurations qui y sont indiquées, avec deux barrettes DIMM par canal, et ne constitue pas une garantie pour tous les serveurs.

L'ajout de modules de mémoire vive supplémentaires peut s'avérer utile pour atteindre la capacité requise, mais modifie la configuration à tester. C'est pourquoi les fournisseurs doivent comparer la taille et la configuration souhaitées des modules avec la liste d'homologation du fabricant du serveur, plutôt que d'additionner indépendamment les valeurs maximales de capacité et de vitesse indiquées dans la fiche technique.

Pour les disques NVMe et les cartes réseau, il faut également la Connexion PCIe déterminant. AMD annonce jusqu'à 128 voies PCIe 5.0 pour les systèmes à un socket et jusqu'à 160 pour les serveurs à deux sockets. Le nombre réel de connecteurs mis à disposition par une carte spécifique dépend de la conception de la plateforme et de l'utilisation qui est faite de ces connexions ; le maximum de 2P ne s'applique pas automatiquement à un hôte 1P.

Lors de la configuration, il est donc utile de prêter attention à l'interaction entre les différents composants : l'ajout de disques NVMe peut nécessiter des ports supplémentaires, tandis que les cartes réseau rapides doivent également être connectées. La norme CXL 2.0 fait partie des capacités de la plateforme, mais ce n'est pas une fonctionnalité automatiquement disponible sur tous les serveurs. Il convient de vérifier la prise en charge par le matériel, le micrologiciel et le système d'exploitation pour le système choisi.

Comparer les formules d'hébergement de Turin

La gamme EPYC 9005 présente différentes orientations : le 9965 mise sur une densité de cœurs maximale, tandis que le 9575F vise une fréquence plus élevée. Le choix ne dépend pas uniquement du processeur, mais de la combinaison entre le modèle concret, le type de socket et la charge de travail. Le tableau suivant compare quatre modèles sur la base des données fournies par AMD.

Le 9965 met à disposition un nombre particulièrement élevé de cœurs physiques pour des tâches indépendantes. Cela peut s'avérer intéressant dans le cas d'un mix de machines virtuelles fortement parallélisées, à condition que la mémoire et les E/S suivent le rythme. Le 9755 offre moins de cœurs, mais une fréquence de boost maximale plus élevée et une mémoire cache L3 totale plus importante. Ces données ne permettent pas à elles seules d'établir un classement définitif pour les applications d'hébergement.

Le 9575F constitue une option envisageable lorsque certaines étapes de travail nécessitent des temps de réponse courts. Son boost maximal Il ne s'agit toutefois pas d'une fréquence garantie en permanence pour tous les cœurs. Le fait qu'il soit plus économique qu'un modèle comportant davantage de cœurs dépend, entre autres, des requêtes simultanées et du modèle de licence.

Sur le modèle 9655P, cela limite Suffixe « P » la compatibilité du socket avec les systèmes à socket unique. Ce modèle n'est donc pas une option pour un serveur à deux sockets. Une comparaison plus approfondie des plateformes devrait inclure des configurations et des mesures concrètes ; l'article consacré à la Choix entre les plateformes AMD EPYC et Intel Xeon plus d'informations.

Mapper les charges de travail d'hébergement et les goulots d'étranglement

Le processeur d'un serveur doit être adapté aux services exécutés simultanément. Dans l'hébergement mutualisé, de nombreuses requêtes indépendantes sont générées ; dans le cas des machines virtuelles, des systèmes d'exploitation entiers se disputent les ressources ; et les bases de données sont sensibles, en fonction de la charge de travail, aux accès à la mémoire ou à la latence de stockage. L'aperçu suivant traduit ces différences en questions de vérification pour la conception.

En matière d'hébergement mutualisé, le nombre de workers actifs simultanément est tout aussi important que la durée des requêtes individuelles. Une charge CPU élevée peut être acceptable si le débit est bon ; toutefois, elle ne permet pas à elle seule de déterminer si les clients doivent attendre longtemps. C'est pourquoi les distributions des temps de réponse et les taux d'erreur à des niveaux de charge définis doivent être pris en compte dans la comparaison.

Dans le cas des bases de données, le Cache L3 Ce n'est qu'une partie du tableau. Le 9755 dispose au total de 512 Mo, le 9965 de 384 Mo. Ces caractéristiques techniques ne prouvent pas l'existence d'un avantage en matière de base de données : la taille des enregistrements, les modèles d'accès, la répartition de la charge de travail et la configuration de la mémoire vive influencent la fréquence à laquelle les données provenant d'autres niveaux de stockage sont requises.

Un service Redis géré vient compléter l'ensemble des applications, par exemple en tant que cache. Pour cela, les fournisseurs doivent tenir compte, outre les ressources CPU, notamment de la mémoire vive disponible et des exigences du service concerné. L'article sur Redis 8 et les choix de mise à niveau pour les hébergeurs aborde notamment les limites de stockage et le fonctionnement de ce type de services.

Pour une comparaison équitable des modèles, la composition des machines virtuelles, la quantité de RAM, le stockage et les niveaux de charge doivent rester aussi comparables que possible. Sinon, il n’est pas possible d’attribuer de manière pertinente les différences de temps de réponse ou de débit au choix du processeur. De même, une requête individuelle plus rapide et un débit global plus élevé sont des objectifs distincts qui peuvent être pondérés différemment lors de la planification tarifaire.

Planification à titre d'exemple de la capacité des machines virtuelles

Un exemple de calcul permet de mettre en perspective les ordres de grandeur : un hôte équipé d’un EPYC 9965 dispose de 192 cœurs physiques et de 384 threads. Si l'on y configure 48 machines virtuelles disposant chacune de quatre vCPU, on obtient 48 × 4 = 192 vCPU alloués. Il s'agit là d'un calcul d'allocation et non d'une mesure des performances réalisables par les machines virtuelles.

A vCPU Il ne s'agit pas pour autant d'un cœur physique automatiquement réservé de manière exclusive. L'hyperviseur planifie les processeurs virtuels sur les processeurs logiques disponibles ; l'exécution effective dépend des machines virtuelles qui fonctionnent simultanément et des ressources qui leur sont allouées. De même, les 384 threads du processeur ne correspondent pas à 384 cœurs physiques indépendants.

Pour les Surréservation Vous devriez tout d'abord déterminer la charge simultanée à laquelle vous vous attendez et les performances promises par un forfait. Un nombre plus élevé de vCPU attribués peut fonctionner lorsque les pics de charge coïncident rarement, mais augmente le risque de temps d'attente lorsque de nombreux utilisateurs effectuent des calculs simultanément. Vérifie cette hypothèse en te basant sur la composition réelle de ta clientèle plutôt que sur le seul nombre de threads.

Ensuite, tu calcules séparément les besoins en mémoire : additionne la quantité de RAM prévue pour les machines virtuelles et prends également en compte les besoins de l'hyperviseur ainsi que les réserves opérationnelles. Le calcul du CPU ne permet pas de déterminer si l'hôte fournit suffisamment de RAM ni si la bande passante mémoire requise est suffisante lorsque plusieurs machines invitées sont actives simultanément.

Il en va de même pour le stockage et le réseau. De nombreuses machines virtuelles peuvent accéder simultanément à des disques NVMe ou transférer des données ; dans ce contexte, outre le débit global, les latences d'E/S et les pics de charge sont également des facteurs importants. Il convient donc de prendre en compte la connectivité et les performances des disques et des cartes réseau effectivement utilisés.

Enfin, vous devez prévoir une marge pour la maintenance et les pannes. Si un hôte doit prendre en charge des machines virtuelles supplémentaires après la panne d'un autre, l'occupation normale ne doit pas déjà mobiliser toutes les ressources nécessaires à cet effet. L'exemple avec 48 machines virtuelles ne fixe ni une limite d'occupation sûre ni un taux de consolidation ; ces deux éléments doivent être évalués en fonction de l'environnement concret.

Préparation de la plateforme et de la virtualisation

Commencez la planification de la plate-forme en choisissant un modèle de processeur précis et en déterminant si un ou deux sockets sont nécessaires. Les besoins en cœurs, en mémoire vive et en E/S doivent, pris dans leur ensemble, correspondre au système hôte souhaité. Un modèle « P » tel que l'EPYC 9655P est conçu pour un seul socket et n'est donc pas adapté à une configuration à deux sockets.

Vérifie ensuite la Autorisation du fabricant pour le processeur, la carte mère et le BIOS. Turin utilise certes le socket SP5 ; toutefois, un serveur SP5 existant ne prend pas en charge tous les modèles 9005 pour cette seule raison. L'alimentation électrique et le système de refroidissement doivent également être compatibles avec le processeur choisi et le boîtier prévu.

Choisissez les modules de RAM en fonction de leur capacité, de la configuration des canaux et des spécifications du fabricant du serveur. À cela s'ajoutent les disques NVMe et les cartes réseau nécessaires : ce n'est pas seulement leur nombre qui est déterminant, mais aussi les emplacements ou baies de disques auxquels ils sont connectés dans le système concerné. Cela permet de vérifier, avant de passer commande, si la combinaison souhaitée est réellement possible sur la plateforme.

Pour les machines virtuelles confidentielles des clients, il est possible de SEV-SNP compléter la protection de la mémoire VM par des mécanismes d'intégrité. L'E/S de confiance via TDISP constitue un autre élément possible pour l'accès aux périphériques. La mise en place d'une offre exploitable dépend toutefois de la combinaison entre le micrologiciel, l'hyperviseur, le système d'exploitation invité et, le cas échéant, les périphériques.

Avant de valider un produit, tu dois également vérifier comment les invités sont configurés, certifiés et gérés, ainsi que les restrictions applicables aux fonctionnalités des machines virtuelles proposées. Une fonctionnalité CPU à elle seule ne garantit pas la compatibilité de l'ensemble de la pile et ne protège pas contre toutes les attaques. Documentez donc la configuration réellement prise en charge et mettez-la à jour lors des mises à jour.

Mesurer le fonctionnement et identifier les goulots d'étranglement

Pour pouvoir comparer avec le matériel d'hébergement existant, il te faut un système compréhensible profil de charge: à peu près le même mélange de machines virtuelles, des volumes de données comparables et des types de requêtes bien définis. Notez la configuration de la mémoire vive, du stockage, du réseau et des logiciels. C'est la seule façon de déterminer ultérieurement si un écart est davantage lié au processeur ou à une autre modification apportée au système.

Analysez plusieurs niveaux de charge plutôt qu’une seule valeur de pointe. Mesurez le débit, la distribution des temps de réponse et les taux d'erreur : un débit élevé n'a que peu d'intérêt pour une offre d'hébergement si, dans le même temps, de nombreuses requêtes sont ralenties ou échouent. Déterminez au préalable quels temps de réponse et quels taux d'erreur sont acceptables pour le service concerné.

Surveillez simultanément l'utilisation de la mémoire vive (RAM) et le comportement de la mémoire, ainsi que la latence et l'utilisation du stockage et du réseau. Si les temps de réponse augmentent alors que le processeur dispose encore de réserves, cela peut signifier, par exemple, qu'un autre composant de la plateforme constitue un goulot d'étranglement. À l'inverse, une utilisation élevée du processeur ne prouve pas à elle seule que les clients subissent une mauvaise expérience utilisateur.

En cas de temps de réponse des machines virtuelles anormaux, vérifiez la simultanéité supposée et la Surutilisation du processeur. Comparez ensuite la configuration réelle de la mémoire vive, les paramètres du micrologiciel et de l'hyperviseur avec la configuration prévue. Modifiez les différents facteurs de manière aussi ciblée que possible et répétez le même niveau de charge afin de ne pas confondre la cause avec une modification simultanée de la charge de travail.

L'exploitation courante comprend également les bulletins de sécurité, la mise à jour du micrologiciel, les contrôles d'accès et les sauvegardes vérifiables. AMD publie également des avis concernant les failles de sécurité et les mesures à prendre pour les processeurs EPYC ; les opérateurs doivent prévoir les mises à jour appropriées fournies par le fabricant du serveur. Après chaque intervention de maintenance, vérifiez à nouveau si les fonctions de protection et les configurations d'invité proposées sont disponibles comme prévu.

L'approvisionnement et la rentabilité sont déterminants

Une décision d'achat commence par se demander si la plateforme existante répond toujours aux exigences. Si la capacité et les réserves sont suffisantes, il peut être judicieux de la maintenir en service. En revanche, pour une mise à niveau vers Turin, le modèle concret de processeur, le micrologiciel et les autres composants doivent être validés par le fabricant du serveur ; le fait qu’ils partagent le même socket SP5 ne suffit pas comme preuve.

Compare un Hôte 1P avec une configuration 2P, en fonction des besoins globaux en cœurs, en mémoire vive et en ports. Deux sockets ne sont pas nécessaires uniquement en raison d'un nombre élevé de machines virtuelles visé. À l'inverse, une plateforme à un seul socket peut être écartée si la combinaison requise de mémoire et d'E/S ne peut pas être prise en charge par le serveur choisi.

Lorsque de nombreuses tâches indépendantes s'exécutent simultanément, la densité de cœurs peut constituer un critère de sélection important. En revanche, pour les applications sensibles à la latence, il vaut la peine d'étudier également des modèles dotés d'une fréquence d'horloge plus élevée dans votre propre mix d'applications. Calculez également le modèle de licence concret : les coûts par cœur, par socket ou par machine virtuelle peuvent modifier l'ordre de priorité économique des plateformes.

Le TDP Il ne s'agit pas d'une mesure de la consommation électrique d'un serveur complet. AMD indique un TDP de 500 watts pour les modèles EPYC 9755 et 9965 ; cela ne permet toutefois pas de déterminer ni la consommation électrique sous ta charge, ni les coûts énergétiques annuels. La mémoire vive (RAM), les disques durs, le réseau et le refroidissement font partie intégrante de l'analyse du système.

Pour comparer la consommation d'énergie et les coûts, évaluez l'ensemble du système à des niveaux de charge représentatifs et tenez compte des réserves nécessaires. Vous devriez comparer les coûts d'acquisition, les licences logicielles et les frais d'exploitation sur toute la durée d'utilisation prévue. Sans données comparables sur la situation actuelle, il n'est pas possible de promettre ni une économie précise ni un taux de consolidation fiable.