Intel Sierra Forest : cœurs Xeon-E pour les charges de travail parallèles sur serveurs

Sierra Forest au sein de la gamme Xeon

« Intel Sierra Forest » est un nom de code désignant les processeurs serveurs Xeon 6 dotés de Cœurs efficaces (E-Cores). La liste des produits étudiée comprend des modèles dotés de 64 à 144 cœurs, parmi lesquels des processeurs de la série 6700E. Intel destine notamment cette version aux applications cloud et « scale-out », dans lesquelles de nombreuses tâches peuvent être traitées en parallèle.

Pour le choix d'un processeur de serveur, le nom de code constitue donc un point de départ, mais ne représente pas une spécification complète. Les modèles d'une même gamme se distinguent notamment par le nombre de cœurs, la fréquence d'horloge et la conception thermique. Le choix de la combinaison la plus appropriée dépend de la charge de travail simultanée générée par une application et des limites imposées par le système serveur concerné.

Granite Rapids désigne quant à lui une autre gamme de processeurs Xeon 6 dotée de cœurs de performance (P-Cores). Il s'agit d'une option à envisager lorsque les performances des cœurs individuels ou certaines extensions de jeu d'instructions revêtent une importance particulière. Cependant, la classification en P-Core ou E-Core ne permet pas à elle seule de déterminer les performances pour une application concrète.

Clearwater Forest doit être considéré comme la génération suivante d'E-Cores et de Xeon 6+, distincte de Sierra Forest. Une indication selon laquelle la gamme Xeon peut compter jusqu'à 288 cœurs E ne constitue pas une spécification générale pour Sierra Forest. Lorsqu'on compare des offres, il convient donc de vérifier la référence exacte du modèle et ses caractéristiques techniques, plutôt que de se baser sur un maximum issu d'une autre génération.

De nombreux cœurs électroniques pour un traitement parallèle

Sierra Forest utilise une architecture modulaire multipuce : les modules de calcul et d'E/S sont regroupés au sein du même boîtier de processeur. Les modules de calcul fournissent les cœurs nécessaires au traitement ; la partie E/S assure les connexions avec la plateforme. Pour l'application, ce n'est pas tant le nombre de modules qui importe que la possibilité de répartir leur charge de travail sur les cœurs disponibles.

De nombreux cœurs peuvent, par exemple, traiter simultanément de nombreuses requêtes Web indépendantes ou des tâches en arrière-plan. Le Débit Ce chiffre décrit la quantité de travail effectué par unité de temps, par exemple le nombre de requêtes traitées avec succès par seconde. Une augmentation de cette valeur ne signifie pas automatiquement que chaque requête est traitée plus rapidement.

La latence joue ici un rôle déterminant : elle désigne le temps nécessaire pour traiter une requête ou une opération unique. Si plusieurs services attendent d'accéder à la même base de données ou à une mémoire saturée, l'ajout de cœurs de processeur supplémentaires permet certes de prendre en charge davantage de travail, mais ne suffit pas à lui seul à éliminer le temps d'attente. C'est pourquoi, notamment en cas de pics de charge, il faut tenir compte non seulement du débit, mais aussi du temps de réponse.

À l'adresse suivante : Évolutivité horizontale Le travail est réparti entre plusieurs instances ou serveurs. Plusieurs petites instances de service peuvent ainsi fonctionner en parallèle, à condition qu’elles soient suffisamment indépendantes les unes des autres et que les ressources partagées ne constituent pas un goulot d’étranglement. En revanche, une tâche sérielle unique ne s’exécute pas automatiquement plus rapidement grâce à des cœurs supplémentaires inutilisés ; ses étapes successives restent interdépendantes.

La répartition entre les limites des processus ou entre les serveurs ne doit pas être assimilée à la structure d'un processeur. L'article complémentaire sur Informatique en essaim et collaboration décentralisée aborde un autre concept de systèmes distribués. Pour Sierra Forest, l'élément déterminant reste de savoir si le logiciel en question génère suffisamment de tâches pouvant être exécutées en parallèle pour les cœurs disponibles.

Cœurs E, cœurs P et compatibilité logicielle

Sierra Forest et la version P-Core du Xeon 6 font partie de l'univers x86. Cela simplifie la classification de base des logiciels existants, mais cela ne signifie pas pour autant que ces deux types de processeurs prennent en charge toutes les extensions de la même manière ni qu'ils offrent les mêmes performances avec une même application. Pour une migration, il faut donc vérifier à la fois les programmes exécutables et leurs exigences réelles.

Intel cite notamment, pour les cœurs Xeon 6-E, AVX2 et VNNI. Ces extensions de jeu d'instructions peuvent prendre en charge certains calculs ; le fait qu'une application les utilise et en tire parti dépend de son code et de ses bibliothèques. Leur simple présence ne permet donc pas de se prononcer sur le débit réalisable d'un service.

Avec le Xeon 6, AVX-512 réservée, selon Intel, aux processeurs P-Core. Si un programme nécessite impérativement cette extension, cela constitue un critère de compatibilité immédiat qui s'oppose à son exécution sans modification sur Sierra Forest. S'il n'utilise AVX-512 qu'à titre facultatif, il peut éventuellement fonctionner avec un autre chemin de code ; ses performances doivent toutefois être évaluées séparément.

Avant de changer de plateforme, vérifiez donc non seulement l'application principale, mais aussi son environnement d'exécution et ses bibliothèques gourmandes en ressources, afin de déterminer leurs exigences en matière de CPU. La documentation du fabricant et les versions logicielles effectivement utilisées sont à cet égard plus importantes que l'hypothèse selon laquelle tout paquet x86 offrirait les mêmes fonctionnalités sur n'importe quelle variante de processeur Xeon.

De plus, le test de compatibilité permet uniquement de déterminer si un logiciel peut fonctionner. Seule une comparaison avec l'application réelle et un équipement serveur adapté permet de déterminer si une configuration E-Core est suffisamment performante pour atteindre l'objectif de latence fixé. Pour les tâches fortement séquentielles ou faisant un usage intensif de l'AVX-512, un système P-Core constitue donc une base de comparaison importante, mais n'est pas pour autant automatiquement le meilleur choix.

Comparer les modèles, les capacités de stockage et les connectivités

Chez Sierra Forest, le numéro de modèle est plus révélateur que le nombre de cœurs seul. Pour une présélection, on peut par exemple envisager les modèles 6710E, 6756E, 6766E et 6780E. Outre le nombre de cœurs et de threads, comparez également la fréquence de base et la fréquence turbo, ainsi que le profil de performance correspondant : un même nombre de cœurs ne permet pas à lui seul de déterminer la marge thermique dont un serveur doit disposer.

Le Xeon 6780E dispose de 144 cœurs et de 144 threads. Intel annonce pour ce processeur une fréquence de base de 2,2 GHz et une fréquence Turbo pouvant atteindre 3,0 GHz ; le TDP de 330 W correspond au profil serveur spécifié. La fréquence Turbo maximale n'est pas une valeur garantie en continu pour tous les cœurs et dans toutes les situations de fonctionnement. Pour les modèles 6766E, 6710E et 6756E, il est recommandé de vérifier séparément les données relatives à la fréquence et au profil dans le comparateur de produits avant de faire votre choix.

La différence entre les deux modèles à 144 cœurs concerne donc également la conception du système de refroidissement et de l'alimentation électrique. Cependant, les valeurs TDP ne permettent à elles seules ni de déterminer la consommation réelle, ni les performances d'une application. Ce qui est déterminant, c'est de savoir quel modèle accomplit le travail requis dans les limites de puissance prévues et avec la charge réelle.

Pour le 6780E, Intel en cite huit Canaux de stockage, DDR5-6400 au maximum, jusqu'à 88 voies PCIe 5.0 et prise en charge des systèmes à deux sockets. Pour connaître la vitesse de mémoire effectivement prise en charge avec la configuration DIMM prévue, tu dois vérifier les spécifications du système serveur concerné et des modules de mémoire sélectionnés.

Dimensionnement de l'hébergement et des machines virtuelles

De nombreuses instances Web indépendantes peuvent tirer parti d'un nombre élevé de cœurs si un nombre suffisant de requêtes est effectivement traité simultanément. Pour la planification, ce n'est toutefois pas seulement le nombre d'instances installées qui compte, mais le nombre de services actifs simultanément pour un temps de réponse cible défini. Un serveur peut afficher une capacité CPU disponible tout en manquant l'objectif si des requêtes sont en attente de mémoire ou d'espace de stockage.

Commencez donc par évaluer la mémoire vive par instance, en incluant l'application, le cache et la part réservée au système d'exploitation. Tenez ensuite compte des pics de charge et des réserves nécessaires à la maintenance ou en cas de panne d’un hôte. Si la capacité de la mémoire vive vient à manquer avant la puissance de calcul, un nombre plus élevé de cœurs ne suffira pas à lui seul à permettre la consolidation souhaitée.

Les E/S de stockage influencent également la densité atteignable : lorsque de nombreuses instances lisent, écrivent ou génèrent des journaux simultanément, des files d'attente peuvent se former. Dans des conditions de simultanéité réalistes, il convient donc de vérifier non seulement le débit moyen, mais aussi les requêtes lentes. Un objectif p99 décrit, par exemple, le temps de réponse que doivent respecter au moins 99 % des requêtes considérées.

Dans le cas des machines virtuelles, une mémoire allouée vCPU Il s'agit dans un premier temps d'une unité d'exécution virtuelle ; il n'y a pas de réservation automatique d'un cœur physique. Lorsque plusieurs machines virtuelles partagent les mêmes ressources, le temps de calcul disponible et les temps de réponse dépendent également de leur activité simultanée et des paramètres de l'hyperviseur. Il convient donc de planifier les réservations et la surréservation en fonction des besoins de chaque service.

Pour un serveur à deux sockets équipé d'un 6780E, tu devrais également prévoir la Topologie NUMA Vérifier : les accès à la mémoire peuvent dépendre du socket auquel la mémoire est connectée et de l'emplacement où s'exécute la machine virtuelle. Vérifiez la configuration et l'emplacement de la mémoire dans l'hyperviseur et comparez les accès locaux et distants sous charge. La prise en charge des deux sockets par Intel ne remplace pas la validation du serveur et de l'hyperviseur spécifiques pour le processeur sélectionné.

Comparer concrètement les profils de charge

La planification des mesures commence par une décision concrète : combien de workers en file d'attente ou de requêtes réseau la nouvelle configuration est-elle capable de traiter tout en conservant la même qualité de service que le serveur existant ou qu'un système P-Core ? Pour cela, définissez la même application, le même volume de données et le même niveau de simultanéité pour les deux candidats. La procédure suivante est une recommandation méthodologique propre à l'auteur ; il ne s'agit ni d'une procédure de test documentée par Intel, ni de la description d'un test effectué.

Pour les workers, le test doit comporter suffisamment de tâches indépendantes afin que les cœurs supplémentaires puissent effectivement être sollicités. Enregistrez le nombre de tâches terminées par intervalle de temps ainsi que le temps nécessaire à leur achèvement ; vérifiez également si la base de données, le stockage ou les interfaces externes limitent le déroulement du test. Une seule tâche en série ne constitue pas une base suffisante pour évaluer une plateforme conçue pour le parallélisme.

Pour pouvoir comparer vous-même les services réseau, notez également la taille des paquets, le cryptage, les cartes réseau et les pilotes. Si l'application doit utiliser des accélérateurs, vérifiez leur disponibilité pour la configuration spécifique du processeur et du serveur, ainsi que leur prise en charge par le logiciel utilisé. Comparez ensuite, sous une charge identique, si leur utilisation apporte un avantage, plutôt que de le déduire d’une simple spécification technique.

Prépare d'abord un Objectif de latence p95 ou p99 Maintenez la charge et augmentez-la par paliers raisonnables. Enregistrez le débit et le taux d'erreurs ainsi que la latence : un nombre plus élevé de requêtes par seconde ne constitue pas un résultat équivalent si le délai de réponse cible convenu est dépassé ou si le nombre d'erreurs augmente. Répétez cette analyse pour les pics de charge prévus.

Mesure la puissance électrique du Système global en veille, ainsi qu'en charge partielle et en charge de pointe. Notez la configuration matérielle, le micrologiciel, le profil de performance, les versions logicielles et la durée de mesure afin d'éviter que les différences ne soient attribuées par erreur au seul processeur. À partir du travail effectué et de l'énergie nécessaire à cet effet, il est ensuite possible de comparer le travail par unité d'énergie, à condition que la qualité de service reste la même.

Évaluer les besoins énergétiques et les coûts

La valeur indiquée TDP Il s'agit d'une valeur indicative pour le processeur, et non d'une mesure portant sur l'ensemble du serveur. Pour le Xeon 6780E, Intel indique un TDP de 330 watts pour le profil de serveur spécifié. Cette valeur ne permet toutefois pas de déterminer directement ni la consommation énergétique réelle pour une charge donnée, ni les coûts d'électricité.

Pour obtenir une comparaison fiable, il faut tenir compte de la consommation électrique totale du système, y compris la mémoire, les disques durs et les cartes réseau. Celle-ci varie en fonction de la charge. Il convient donc d'effectuer les mesures sur une période représentative et de prendre en compte aussi bien le fonctionnement au ralenti que les charges typiques et élevées ; une simple valeur de pointe ne donne en effet qu'une image incomplète du fonctionnement.

Le Travail par unité d'énergie peut par exemple s'exprimer sous la forme du nombre de requêtes traitées avec succès divisé par la consommation d'énergie mesurée. Ne comparez à cet égard que les tâches répondant aux mêmes exigences : un débit plus élevé n'a que peu d'intérêt si le taux d'erreur ou les temps de réponse dépassent l'objectif convenu. Le volume de données et l'évolution de la charge doivent également être comparables.

Même ce rapport n'est pas suffisant pour garantir la rentabilité. Il faut prendre en compte l'électricité et le refroidissement, ainsi que l'espace de rack, l'achat de matériel, la maintenance et les licences logicielles. Dans le cas des modèles de licence basés sur le nombre de cœurs, un nombre élevé de cœurs peut modifier le calcul ; ce sont les conditions contractuelles concrètes qui sont déterminantes, et non une règle de licence hypothétique.

Une consolidation entraîne également des efforts de migration : il faut vérifier les applications, transférer les données et adapter les procédures d'exploitation. Il convient de mettre en balance ces coûts ponctuels et les risques d'indisponibilité éventuels avec les coûts d'exploitation courants. La poursuite de l'exploitation des serveurs existants reste une option sérieuse si leur capacité utile et leurs coûts d'exploitation sont suffisants pour la période prévue.

Vérifier le fonctionnement, le micrologiciel et les goulots d'étranglement

Si la latence de queue, commencez par identifier l'heure et la chaîne de requêtes concernée. Vérifiez si, parallèlement, le taux d'erreur, les files d'attente ou le nombre de requêtes parallèles augmentent. Une latence p99 élevée signifie que les requêtes les plus lentes peuvent dépasser le délai souhaité ; la moyenne seule ne permet pas nécessairement de mettre en évidence ce problème.

Examine ensuite l'utilisation du processeur et la répartition de la charge de travail. Une utilisation globalement faible n'exclut pas l'existence d'un goulot d'étranglement au niveau de certains threads. En revanche, si de nombreux cœurs sont sollicités, vérifie s'il y a suffisamment de tâches indépendantes ou si la synchronisation et les temps d'attente limitent le débit supplémentaire.

Dans un système à deux sockets, la Lieu de stockage Pour le dépannage : vérifiez l'affectation NUMA des processus ou des machines virtuelles et de leur mémoire. Le Xeon 6780E prend en charge les systèmes à deux sockets ; toutefois, l'opportunité d'un placement spécifique pour une application dépend également du serveur et des paramètres de l'hyperviseur.

Si la cause reste indéterminée, surveillez les E/S de mémoire et de stockage, ainsi que les chemins réseau et les services externes. Des réponses de base de données retardées ou des connexions réseau saturées peuvent allonger la durée des requêtes sans que le processeur du serveur soit constamment sollicité à pleine capacité. Comparez les valeurs mesurées dans le temps avec les requêtes lentes, au lieu de considérer trop hâtivement le nombre de kernels comme la cause du problème.

Avant l'acquisition et le déploiement, vérifiez la liste des processeurs compatibles fournie par le fabricant du serveur, le type de socket, la version de BIOS requise et la prise en charge par l'hyperviseur. Intel utilise le LGA4710-2 pour la série 6700E et le LGA7529-1 pour la série 6900P ; on ne peut toutefois pas en déduire une interchangeabilité générale entre les différentes séries Xeon.

Consultez également la mise à jour des spécifications relative à la gamme de processeurs utilisée. Vérifiez les errata et les précisions pertinents en fonction du stepping et de la version du micrologiciel concernés, et tenez compte, le cas échéant, des solutions documentées. Ainsi, la validation de l'ensemble du système tient compte des limitations techniques connues.

Choisir la plateforme serveur adaptée

Le choix commence par l'application, et non par la valeur la plus élevée indiquée dans la fiche technique. Intel positionne les cœurs Xeon 6-E comme offrant une densité de cœurs élevée et un débit parallèle aux tâches, tandis que les cœurs P sont destinés à offrir une puissance élevée par cœur. Cela ne permet toutefois pas encore de déterminer quelle plateforme répondra à vos objectifs en matière de latence et à vos besoins en capacité.

Utilise le tableau comme point de départ pour un Comparaison à qualité de service égale, et non comme un classement des performances. La méthode de sélection suivante est une recommandation propre à l'auteur et ne constitue pas une procédure de test documentée par Intel : comparez la plate-forme existante, une configuration Sierra Forest adaptée et, le cas échéant, un système à cœurs P, en tenant compte des mêmes exigences en matière de temps de réponse, de taux d'erreur et de volume de données. Documentez la configuration de chaque système et déterminez le travail utile du système complet.

Voir aussi Serveurs basés sur ARM constituent une option envisageable. Pour cela, le système d'exploitation, les applications et les progiciels nécessaires doivent être adaptés à l'architecture ; de plus, le portage et l'exploitation peuvent nécessiter des modifications. La désignation de l'architecture ne garantit pas à elle seule un gain d'efficacité général et celle-ci doit être évaluée dans les mêmes conditions de charge.

Choisissez enfin la plateforme qui offre la capacité requise avec une réserve suffisante et des conditions d'exploitation adaptées, au coût global le plus avantageux. Tenez compte à cet égard de la migration et des licences, et évaluez, le cas échéant, les risques et l'encombrement. Le nombre de cœurs est un critère de sélection, mais il ne remplace ni les tests d'application ni l'analyse des coûts.