FR 3117641 A1 20220617 FR 2110069 A 20210924 Les exemples décrits ici concernent une Unité de Traitement d'Infrastructure (IPU) qui comprend : des circuits d'interface destinés à assurer un couplage de communication avec une plateforme ; des circuits d'interface réseau destinés à assurer un couplage de communication avec un support de réseau ; et des circuits destinés à exposer des services d'infrastructure auxquels des microservices peuvent accéder pour la composition de fonctions. Figure pour l’abrégé : Figure 19 Unité de traitement d'infrastructure Demande connexe La présente demande revendique le bénéfice de la priorité de la demande provisoire américaine 63/087218, déposée le 3 octobre 2020. Le contenu de la présente demande est incorporé dans son intégralité dans le présent document. Description L'informatique en nuage a atteint un point d'inflexion avec deux tendances qui se renforcent mutuellement. On assiste à l'émergence rapide de services Natifs en Nuage (Cloud Native) à pleine échelle avec des microservices de grande dimension, faiblement couplés, rapidement assemblés et déployés, manipulant des données massivement distribuées, tout en maintenant le calcul local par rapport aux données. Des changements ont été apportés à la pile logicielle traditionnelle dans laquelle les abstractions se font à travers une succession de couches horizontales, pour atteindre aujourd'hui un plus grand degré de modularité, d'hétérogénéité, de localisation d'actions étroitement couplées, et de virtualisation des données et de services à l'aide d'interfaces de programmes d'application (API) orientées services. Brève description des figures est un schéma simplifié d'au moins un mode de réalisation d'un centre de données destiné à exécuter des charges de travail au moyen de ressources désagrégées. est un schéma simplifié d'au moins un mode de réalisation d'une armoire (pod) qui peut être intégrée à un centre de données. est un schéma fonctionnel simplifié d'au moins un mode de réalisation de la face supérieure d'un nœud. est un schéma fonctionnel simplifié d'au moins un mode de réalisation de la face inférieure d'un nœud. est un schéma fonctionnel simplifié d'au moins un mode de réalisation d'un nœud de calcul. est un schéma fonctionnel simplifié d'au moins un mode de réalisation d'un nœud accélérateur utilisable dans un centre de données. est un schéma fonctionnel simplifié d'au moins un mode de réalisation d'un nœud de stockage utilisable dans un centre de données. est un schéma fonctionnel simplifié d'au moins un mode de réalisation d'un nœud de mémoire utilisable dans un centre de données. illustre un système destiné à exécuter une ou plusieurs charges de travail. illustre un exemple de système. représente un exemple de système. illustre divers points d'extrémité clients. illustre un exemple de système informatique de périphérie. illustre un déploiement et une orchestration pour des configurations de périphérie virtualisées et à base de conteneurs. illustre un exemple de plateforme de distribution de logiciels. représente divers modes de réalisation d'une CPU et de systèmes de cartes d'interface réseau (NIC) avec accès à la mémoire. représente divers modes de réalisation d'un système. illustre un exemple d'utilisation d'une IPU. illustre un exemple d'une IPU. illustre un exemple de traducteur. illustre un exemple de composants d'un gestionnaire de ressources sécurisé. illustre un exemple de système de sécurité et de racine de confiance. illustre un exemple de système de composition de ressources. illustre un exemple de la manière dont un IPU coordonne des ressources. illustre un exemple d'allocation de ressources par une IPU utilisant des ressources présentes dans une IPU et des ressources d'autres IPU et nœuds. représente divers modes de réalisation d'un système. illustre un exemple de système qui représente le rééquilibrage de points de contrôle de sécurité vers des IPU depuis des CPU. illustre un exemple de système. illustre un exemple de système avec télémétrie de bout en bout. illustre un exemple de système utilisant l'exécution d'une charge de travail sur plusieurs systèmes. Un UUID peut être utilisé pour identifier des microservices. illustre un exemple d'utilisation de la télémétrie pour gérer l'exécution d'une charge de travail. et illustrent un exemple d'utilisation d'une IPU demandant l'exécution d'une charge de travail par une CPU. illustre un exemple de système connecté à l'aide d'un commutateur configurable. illustre un exemple d'accélération de communication de microservices. illustre un exemple de processus d'attestation de ressources. ] illustre un exemple d'utilisation d'un trajet de données sécurisé par l'intermédiaire de ressources attestées. illustre un exemple de composition de ressources système pour une IPU mettant à disposition une capacité de calcul réservée à partir d'une partition distante en ligne, selon certains modes de réalisation. illustre un exemple d'opérations de configuration du Plan de Commande d'IPU qui peuvent être effectuées. et illustrent un exemple de fonctionnement du plan de commande avec utilisation de diverses fonctionnalités de sécurité. illustre un exemple de fonctionnement du plan de données d'IPU. illustre un exemple d'un plan de données et d'un fonctionnement de l'IPU avec des fonctionnalités de sécurité. , et illustrent des vues système de fonctionnalités de sécurité de la . et illustrent un exemple d'utilisation d'un plan RPC de données d'IPU avec un Maillage de Services. et illustrent un exemple de décomposition de services entre des ressources locales et distantes. et illustrent un exemple de système et de fonctionnement d'une décomposition de services IPU pour des scénarios de mémoire et de stockage. illustre un exemple d'interface réseau. illustre un exemple de système. Description détaillée Des abstractions de services telles que les microservices et les Fonctions en tant que Service (FaaS) ou le Serviceless pilotent des services faiblement couplés et dynamiquement orchestrés qui nécessitent un partitionnement des calculs ou des XPU et une normalisation des services permettant la mise en place d'un Dorsal en tant que Service (BaaS). Une XPU ou xPU peut faire référence à une unité de traitement graphique (GPU), une GPU polyvalente (GPGPU), un réseau de portes programmables (FPGA), une Unité de Traitement Accéléré (APU), un accélérateur ou tout autre processeur. Il peut également s'agir de fonctions telles qu'une mise en application d'une qualité de service, un traçage, une surveillance des performances et des erreurs, une journalisation, une authentification, un maillage de services, une transformation de données, etc. En raison des niveaux massifs de traitement des données, il peut arriver que les données ne soient pas stockées localement par rapport aux capacités de calcul et que les exigences de traitement dépassent l'échelle d'une seule XPU. Ces éléments entraînent une croissance des communications entre services. Des ressources mutualisées (par exemple, rattachées localement ou réparties à travers une matrice d'interconnexion ou un réseau) peuvent être agrégées pour réduire les coûts et partitionnées dynamiquement pour les clients à des fins d'efficacité. Les ressources mutualisées entraînent un besoin de connectivité à large bande passante et à faible latence, de virtualisation et de composabilité des ressources, de sécurité à confiance nulle, de télémétrie à grain fin et de qualité de service, ainsi que de déplacement et de traitement optimisés des données. Une tendance importante est l'adoption de microservices à travers le nuage, les entreprises, l'IOT et les fournisseurs de télécommunications (telcos). Des microservices et des services peuvent être mis en œuvre au moyen des architectures des centres de données ou d'architectures informatiques de périphérie. Les microservices peuvent comprendre une décomposition d'une application monolithique en petits services définis et gérables. Un microservice peut être caractérisé par un ou plusieurs des éléments suivants : utilisation d'interfaces à grain fin (vers des services déployables indépendamment), programmation polyglotte (par exemple, code écrit dans plusieurs langages afin d'acquérir des fonctionnalités et une efficacité supplémentaires qui ne sont pas disponibles dans un seul langage), ou déploiement léger de conteneurs ou de machines virtuelles, et fourniture décentralisée et continue de microservices. Les microservices présentent de nombreux avantages qui favorisent leur adoption rapide. Les avantages des microservices entraînent également une nouvelle complexité et un surdébit de traitement qu'il faut pouvoir gérer. Globalement, du point de vue du développeur d'applications, les avantages l'emportent sur la complexité associée. Dans certains exemples, une application peut être composée de microservices, chaque microservice s'exécutant dans son propre processus et communiquant à l'aide de protocoles (par exemple, une API de ressources HTTP, un service de messagerie, des appels de procédure à distance (RPC), la Notation d'Objets JavaScript (JSON), Thrift ou gRPC). Les microservices peuvent être déployés indépendamment par une gestion centralisée de ces services. Le système de gestion peut être écrit dans différents langages de programmation et utiliser différentes technologies de stockage de données. Les microservices impliquent certains coûts et avantages. Les avantages peuvent comprendre la plus grande facilité de construction et de maintenance d'une application, une organisation autour des capacités de l'entreprise, une productivité et une rapidité améliorées, une flexibilité dans l'utilisation des technologies et une évolutivité, ainsi que des équipes autonomes et interfonctionnelles. Les fournisseurs de services en nuage (CSP) font évoluer leurs plateformes matérielles en proposant des unités centrales de traitement (CPU), des unités de traitement graphique polyvalentes (GPGPU), des XPU personnalisées et des dispositifs de stockage et de mémoire mutualisés (par exemple, des DDR, une mémoire persistante, 3D XPoint, Optane ou des dispositifs de mémoire qui utilisent du verre de chalcogénure). Les CSP intègrent verticalement ces éléments avec des plans de commande d'orchestration personnalisés afin de les exposer en tant que services aux clients. Dans certains exemples, le nuage pourrait inclure le nuage de centres de données à différents endroits, pouvant aller de l'entreprise sur place, aux centres de données de nuages de télécommunication, ou encore se référer au nuage de périphérie. Dans certains exemples, les fournisseurs de services en nuage pourraient comprendre plus généralement les fournisseurs de services. Tous les services et microservices peuvent être exécutés sur des configurations informatiques de périphérie. Divers modes de réalisation d'Unités de Traitement d'Infrastructure (IPU, Infrastructure Processing Unit) décrites ici peuvent être utilisées par les CSP pour les performances, la gestion, la sécurité et de coordination de fonctions en plus du délestage d'infrastructure et des communications. À titre d'exemple, les IPU peuvent être intégrées à des NIC intelligentes et à des dispositifs de stockage ou de mémoire (par exemple, sur une même puce, un système sur puce (SoC) ou des puces connectées) situés dans des systèmes sur place, des stations de base, des passerelles, des bureaux centraux de quartier, et autres. Divers exemples d'une IPU peuvent exécuter une application composée de microservices, chaque microservice s'exécutant dans son propre processus et communiquant à l'aide de protocoles (par exemple, une API de ressources HTTP, un service de messages ou gRPC). Des microservices peuvent être déployés indépendamment les uns des autres en utilisant une gestion centralisée de ces services. Un système de gestion peut être écrit dans différents langages de programmation et utiliser différentes technologies de stockage de données. Exemples d'environnements permettant l'utilisation d'unités de traitement d'infrastructure La illustre un centre de données dans lequel des ressources désagrégées peuvent exécuter de manière coopérative une ou plusieurs charges de travail (par exemple, des applications pour le compte de clients) et comprend plusieurs armoires 110, 70, 130, 80, une armoire étant ou comprenant une ou plusieurs rangées de bâtis. Bien entendu, bien que le centre de données 100 soit représenté avec plusieurs armoires, dans certains modes de réalisation, le centre de données 100 peut être constitué d'une seule armoire. Comme décrit plus en détail dans le présent document, chaque bâti abrite plusieurs nœuds, dont certains peuvent être équipés d'un ou plusieurs types de ressources (par exemple, des dispositifs de mémoire, des dispositifs de stockage de données, des dispositifs accélérateurs, des processeurs polyvalents). Des ressources peuvent être couplées de manière logique pour former un nœud composé ou un nœud composite, qui peut par exemple faire office de serveur pour exécuter une tâche, une charge de travail ou des microservices. Dans le mode de réalisation présenté à titre d'illustration, les nœuds de chaque armoire 110, 70, 130, 80 sont connectés à plusieurs commutateurs d'armoire (par exemple, des commutateurs qui acheminent des communications de données vers et depuis les nœuds à l'intérieur de l'armoire). Les commutateurs d'armoire, quant à eux, sont connectés à des commutateurs dorsaux 90 qui commutent les communications entre les armoires (par exemple, les armoires 110, 70, 130, 80) dans le centre de données 100. Dans certains modes de réalisation, les nœuds peuvent être connectés à une matrice d'interconnexion à l'aide de la technologie Intel® Omni-Path. Dans d'autres modes de réalisation, les nœuds peuvent être connectés à d'autres matrices d'interconnexion, par exemple InfiniBand ou Ethernet. Comme décrit plus en détail ici, les ressources présentes dans les nœuds du centre de données 100 peuvent être attribuées à un groupe (appelé ici "nœud géré") contenant des ressources d'un ou plusieurs nœuds à utiliser collectivement dans l'exécution d'une charge de travail. La charge de travail peut s'exécuter comme si les ressources appartenant au nœud géré étaient situées sur un même nœud. Les ressources d'un nœud géré peuvent appartenir à des nœuds appartenant à des bâtis différents, et même à des armoires différentes 110, 70, 130, 80. De ce fait, certaines ressources d'un même nœud peuvent être attribuées à un nœud géré tandis que d'autres ressources du même nœud sont attribuées à un nœud géré différent (par exemple, un processeur attribué à un nœud géré et un autre processeur du même nœud attribué à un nœud géré différent). Un centre de données comprenant des ressources désagrégées, tel que le centre de données 100, peut être utilisé dans une grande variété de contextes, tels que ceux d'une entreprise, d'un gouvernement, d'un fournisseur de services en nuage et d'un fournisseur de services de communications (par exemple, des Telcos), ainsi que dans une grande variété de tailles, allant des méga-centres de données de fournisseurs de services en nuage qui occupent plus de 5600 mètres carrés (60 000 pieds carrés) jusqu'à des installations à un ou plusieurs bâtis destinées à être utilisées dans des stations de base. La désagrégation de ressources en nœuds principalement composés d'un seul type de ressource (par exemple, des nœuds de calcul comprenant principalement des ressources de calcul et des nœuds de mémoire contenant principalement des ressources de mémoire), et l'allocation et la désallocation sélectives des ressources désagrégées pour former un nœud géré affecté à l'exécution d'une charge de travail améliorent le fonctionnement et l'utilisation des ressources du centre de données 100 par rapport à des centres de données typiques composés de serveurs hyperconvergents contenant des ressources de calcul, de mémoire, de stockage et éventuellement des ressources supplémentaires dans un seul châssis. À titre d'exemple, étant donné que les nœuds contiennent principalement des ressources d'un type particulier, des ressources d'un type donné peuvent être mises à niveau indépendamment des autres ressources. En outre, comme les différents types de ressources (processeurs, stockage, accélérateurs, etc.) présentent généralement des fréquences de remise à niveau différentes, il est possible d'obtenir une meilleure utilisation des ressources et de réduire le coût total de possession. Un opérateur de centre de données peut par exemple mettre à niveau les processeurs dans l'ensemble de son installation en remplaçant uniquement les nœuds de calcul. Dans ce cas, les ressources d'accélération et de stockage peuvent ne pas être mises à niveau en même temps et au lieu de cela, peuvent être autorisées à continuer à fonctionner jusqu'à ce qu'une remise à niveau de ces mêmes ressources soit programmée. Le taux d'utilisation des ressources peut également augmenter. À titre d'exemple, si des nœuds gérés sont composés sur la base d'exigences des charges de travail qui s'exécuteront sur eux, les ressources que comporte un nœud ont plus de chances d'être exploitées au mieux. Une telle utilisation peut permettre de faire fonctionner un plus grand nombre de nœuds gérés dans un centre de données avec un ensemble donné de ressources, ou de construire un centre de données destiné à exécuter un ensemble donné de charges de travail en utilisant moins de ressources. La illustre une armoire. Une armoire peut comprendre un ensemble de rangées 200, 210, 220, 230 de bâtis 240. Chaque bâti 240 peut abriter plusieurs nœuds (par exemple, seize nœuds) et fournir des connexions d'alimentation et de données aux nœuds hébergés, comme décrit plus en détail ici. Dans le mode de réalisation présenté à titre d'illustration, les bâtis de chaque rangée 200, 210, 220, 230 sont connectés à plusieurs commutateurs d'armoire 250, 260. Le commutateur d'armoire 250 comprend un ensemble de ports 252 auxquels sont connectés les nœuds des bâtis de l'armoire 110 et un autre ensemble de ports 254 qui connectent l'armoire 110 aux commutateurs dorsaux 90 pour permettre une connectivité à d'autres armoires du centre de données 100. De même, le commutateur d'armoire 260 comprend un ensemble de ports 262 auxquels sont connectés les nœuds des bâtis de l'armoire 110 et un ensemble de ports 264 qui connectent l'armoire 110 aux commutateurs dorsaux 90. De la sorte, l'utilisation de la paire de commutateurs 250, 260 confère une certaine redondance à l'armoire 110. À titre d'exemple, si l'un des commutateurs 250, 260 tombe en panne, les nœuds de l'armoire 110 peuvent encore maintenir la communication de données avec le reste du centre de données 100 (par exemple, avec des nœuds d'autres armoires) par l'intermédiaire de l'autre commutateur 250, 260. Par ailleurs, dans le mode de réalisation présenté à titre d'illustration, les commutateurs 90, 250, 260 peuvent être réalisés sous la forme de commutateurs optiques bimodes, capables d'acheminer à la fois des communications de protocole Ethernet transportant des paquets de protocole Internet (IP) et des communications conformes à un deuxième protocole de couche de liaison hautes performances (par exemple, PCI Express ou Compute Express Link) par l'intermédiaire de supports de signalisation optiques d'une structure optique. Il est à noter que chacune des autres armoires 70, 130, 80 (ainsi que toute autre armoire supplémentaire du centre de données 100) peut être structurée de manière semblable à l'armoire 110 illustrée et décrite à la , et comporter des composants semblables à ceux qu'elle comporte (par exemple, chaque armoire peut comporter des rangées de bâtis accueillant de multiples nœuds, comme décrit plus haut). En outre, bien que deux commutateurs d'armoire 250, 260 soient illustrés, il est à noter que dans d'autres modes de réalisation, chaque armoire 110, 70, 130, 80 peut être connectée à un nombre différent de commutateurs d'armoire, offrant ainsi une capacité de basculement encore plus grande. Bien entendu, dans d'autres modes de réalisation, les armoires peuvent être disposées différemment de la configuration de rangées d'armoires illustrée aux figures 1-2. Une armoire peut par exemple être réalisée sous la forme de plusieurs jeux de bâtis dans lesquels chaque jeu de bâtis est disposé radialement, c'est-à-dire que les bâtis sont équidistants d'un commutateur central. Se référant à présent à la , le nœud 400, dans le mode de réalisation présenté à titre d'illustration, est configuré pour être monté dans un bâti 240 correspondant du centre de données 100, comme évoqué ci-dessus. Dans certains modes de réalisation, chaque nœud 400 peut être optimisé ou configuré d'une autre façon pour exécuter des tâches particulières, telles que des tâches de calcul, des tâches d'accélération, des tâches de stockage de données, etc. Le nœud 400 peut par exemple être réalisé sous la forme d'un nœud de calcul 500, tel que évoqué ci-dessous à propos de la , d'un nœud accélérateur 600, tel que évoqué ci-dessous à propos de la , d'un nœud de stockage 700, tel que évoqué ci-dessous à propos de la , ou d'un nœud optimisé ou autrement configuré pour effectuer d'autres tâches spécialisées, tel qu'un nœud de mémoire 800, évoqué ci-dessous à propos de la . Comme évoqué ci-dessus, le nœud 400 présenté à titre d'illustration comprend un substrat de carte de circuit imprimé 302, qui porte diverses ressources physiques (par exemple, des composants électriques) montées sur celui-ci. Comme évoqué ci-dessus, le nœud 400 présenté à titre d'illustration comprend une ou plusieurs ressources physiques 320 montées sur une face supérieure 350 du substrat de carte de circuit imprimé 302. Bien que deux ressources physiques 320 soient représentées sur la , on notera que, dans d'autres modes de réalisation, le nœud 400 peut comprendre une, deux ou plusieurs ressources physiques 320. Les ressources physiques 320 peuvent être matérialisées sous la forme de tout type de processeur, contrôleur ou autre circuit de calcul capable d'effectuer diverses tâches telles que des fonctions de calcul et/ou de commander les fonctions du nœud 400, par exemple selon le type ou la fonctionnalité prévue du nœud 400. À titre d'exemple, comme exposé plus en détail ci-après, les ressources physiques 320 peuvent être réalisées sous la forme de processeurs hautes performances dans des modes de réalisation dans lesquels le nœud 400 est réalisé sous la forme d'un nœud de calcul, de coprocesseurs ou de circuits accélérateurs dans des modes de réalisation dans lesquels le nœud 400 est réalisé sous la forme d'un nœud accélérateur, de contrôleurs de stockage dans des modes de réalisation dans lesquels le nœud 400 est réalisé sous la forme d'un nœud de stockage, ou d'un ensemble de dispositifs de mémoire dans des modes de réalisation dans lesquels le nœud 400 est réalisé sous la forme d'un nœud de mémoire. Le nœud 400 comprend également une ou plusieurs ressources physiques supplémentaires 330 montées sur la face supérieure 350 du substrat de carte de circuit imprimé 302. Dans le mode de réalisation présenté à titre d'illustration, les ressources physiques supplémentaires comprennent un contrôleur d'interface réseau (NIC) comme évoqué ci-après plus en détail. Bien entendu, selon le type et la fonctionnalité du nœud 400, dans d'autres modes de réalisation, les ressources physiques 330 peuvent comprendre des composants, circuits et/ou dispositifs électriques supplémentaires ou différents. Les ressources physiques 320 peuvent être couplées par voie de communication aux ressources physiques 330 par un sous-système d'entrée/sortie (I/O) 322. Le sous-système I/O 322 peut être réalisé sous la forme de circuits et/ou de composants permettant de faciliter les opérations d'entrée/sortie avec les ressources physiques 320, les ressources physiques 330 et/ou d'autres composants du nœud 400. Le sous-système I/O 322 peut par exemple être réalisé sous la forme, ou par ailleurs être dotés, de contrôleurs centraux de mémoire, de contrôleurs centraux d'entrée/sortie, de capteurs centraux intégrés, de dispositifs à microprogrammes, de liaisons de communication (par exemple, des liaisons point à point, des liaisons de bus, des conducteurs, des câbles, des guides d'ondes, des guides de lumière, des pistes de cartes de circuits imprimés, etc. ), et/ou d'autres composants et sous-systèmes destinés à faciliter les opérations d'entrée/sortie. Dans le mode de réalisation présenté à titre d'illustration, le sous-système I/O 322 est réalisé sous la forme, ou est par ailleurs doté, d'un bus de données à double débit 4 (DDR4) ou d'un bus de données DDR5. Dans certains modes de réalisation, le nœud 400 peut également comprendre une interconnexion de ressource à ressource 324. L'interconnexion de ressource à ressource 324 peut être réalisée sous la forme de tout type d'interconnexion de communication capable de faciliter les communications de ressource à ressource. Dans le mode de réalisation présenté à titre d'illustration, l'interconnexion de ressource à ressource 324 est réalisée sous la forme d'une interconnexion point à point à grande vitesse (par exemple, plus rapide que le sous-système I/O 322). L'interconnexion de ressource à ressource 324 peut par exemple être réalisée sous la forme d'une interconnexion QuickPath (QPI), d'une interconnexion UltraPath (UPI), de PCI express (PCIe) ou d'une autre interconnexion point à point à grande vitesse dédiée aux communications de ressource à ressource. Le nœud 400 comprend également un connecteur d'alimentation 340 configuré pour s'accoupler avec un connecteur d'alimentation correspondant du bâti 240 lorsque le nœud 400 est monté dans le bâti 240 correspondant. Le nœud 400 reçoit de l'énergie d'une alimentation électrique du bâti 240 par l'intermédiaire du connecteur d'alimentation 340 pour alimenter les divers composants électriques du nœud 400. Autrement dit, le nœud 400 ne comprend pas d'alimentation locale (par exemple, une alimentation embarquée) pour alimenter les composants électriques du nœud 400. L'exclusion d'une alimentation locale ou embarquée facilite la réduction de l'empreinte globale du substrat de carte de circuit imprimé 302, cela permettant d'améliorer les caractéristiques de refroidissement thermique des différents composants électriques montés sur le substrat de carte de circuit imprimé 302, comme évoqué ci-dessus. Dans certains modes de réalisation, des régulateurs de tension sont placés sur une face inférieure 450 (voir ) du substrat de carte de circuit imprimé 302, directement à l'opposé des processeurs 520 (voir ), et l'alimentation est acheminée des régulateurs de tension aux processeurs 520 par des trous traversants passant à travers le substrat de carte de circuit imprimé 302. Une telle configuration offre un bilan thermique amélioré, un courant et/ou une tension supplémentaires, et une meilleure commande de la tension par rapport à des cartes de circuit imprimé classiques dans lesquelles la puissance du processeur est délivrée par un régulateur de tension et en partie, par des pistes de circuit imprimé. Dans certains modes de réalisation, le nœud 400 peut également comprendre des éléments de montage 342 configurés pour s'accoupler avec un bras de montage, ou une autre structure, d'un robot pour faciliter le positionnement du nœud 300 dans un bâti 240 par le robot. Les éléments de montage 342 peuvent être réalisés sous la forme de n'importe quel type de structure physique permettant au robot de saisir le nœud 400 sans endommager le substrat de la carte de circuit imprimé 302 ou les composants électriques qui y sont montés. À titre d'exemple, dans certains modes de réalisation, les éléments de montage 342 peuvent être réalisés sous la forme de patins non conducteurs fixés au substrat de la carte de circuit imprimé 302. Dans d'autres modes de réalisation, les éléments de montage peuvent être réalisés sous la forme de supports, d'étriers ou d'autres structures semblables fixés au substrat de carte de circuit imprimé 302. Le nombre, la forme, la taille et/ou la composition de l'élément de montage 342 peuvent dépendre de la conception du robot configuré pour gérer le nœud 400. Se référant à présent à la , en plus des ressources physiques 330 montées sur la face supérieure 350 du substrat de carte de circuit imprimé 302, le nœud 400 comprend également un ou plusieurs dispositifs de mémoire 420 montés sur une face inférieure 450 du substrat de carte de circuit imprimé 302. En d'autres termes, le substrat de carte de circuit imprimé 302 peut être réalisé sous la forme d'une carte de circuit imprimé à double face. Les ressources physiques 320 peuvent être couplées par voie de communication à des dispositifs de mémoire 420 par l'intermédiaire du sous-système I/O 322. À titre d'exemple, les ressources physiques 320 et les dispositifs de mémoire 420 peuvent être couplés par voie de communication par un ou plusieurs trous traversants passant à travers le substrat de carte de circuit imprimé 302. Dans certains modes de réalisation, une ressource physique 320 peut être couplée par voie de communication à un ensemble différent d'un ou plusieurs dispositifs de mémoire 420. En variante, dans d'autres modes de réalisation, chaque ressource physique 320 peut être couplée par voie de communication à chaque dispositif de mémoire 420. Les dispositifs de mémoire 420 peuvent être réalisés sous la forme de tout type de dispositif de mémoire capable de stocker des données destinées aux ressources physiques 320 pendant le fonctionnement du nœud 400, tel qu'un type quelconque de mémoire volatile (par exemple, une mémoire vive dynamique (DRAM), etc.) ou non volatile. La mémoire volatile peut être un support de stockage qui nécessite de l'énergie pour maintenir l'état des données stockées sur le support. Des exemples non limitatifs de mémoire volatile peuvent comprendre divers types de mémoire vive (RAM), tels qu'une mémoire vive dynamique (DRAM) ou une mémoire vive statique (SRAM). Un type particulier de DRAM pouvant être utilisé dans un module de mémoire est une mémoire vive dynamique synchrone (SDRAM). Dans des modes de réalisation particuliers, la DRAM d'un composant de mémoire peut être conforme à une norme promulguée par le JEDEC, telle que la norme JESD79F pour une SDRAM DDR, la norme JESD79-2F pour une SDRAM DDR2, la norme JESD79-3F pour une SDRAM DDR3, la norme JESD79-4A pour une SDRAM DDR4, la norme JESD209 pour une DDR à faible consommation (LPDDR), la norme JESD209-2 pour une LPDDR2, la norme JESD209-3 pour une LPDDR3 et la norme JESD209-4 pour une LPDDR4. Ces normes (et des normes similaires) peuvent être appelées normes à base de DDR et les interfaces de communication des dispositifs de stockage qui mettent en œuvre ces normes peuvent être appelées interfaces à base de DDR. Dans un mode de réalisation, le dispositif de mémoire est un dispositif de mémoire adressable par blocs, par exemple ceux qui sont à base de technologies NAND ou NOR. Un bloc peut être de n'importe quelle taille, comme par exemple, sans s'y limiter, 2ko, 4 ko, 5 ko, etc. Un dispositif de mémoire peut également comprendre des dispositifs non volatils de nouvelle génération, tels que la mémoire Intel Optane® ou d'autres dispositifs de mémoire non volatils adressables par octets et à écriture sur place. Dans un mode de réalisation, le dispositif de mémoire peut être ou peut comprendre des dispositifs de mémoire qui utilisent un verre de chalcogénure, une mémoire flash NAND à plusieurs niveaux de seuil, une mémoire flash NOR, une mémoire à changement de phase (PCM) à un ou plusieurs niveaux, une mémoire résistive, une mémoire à nanofils, une mémoire vive à transistors ferroélectriques (FeTRAM), une mémoire anti-ferroélectrique, une mémoire vive magnétorésistive (MRAM) qui intègre la technologie des mémristors, une mémoire résistive comprenant la base d'oxyde métallique, la base de vacance d'oxygène et la mémoire vive à pont conducteur (CB-RAM), ou une MRAM à couple de transfert de spin (STT), un dispositif à base de mémoire à jonction magnétique spintronique, un dispositif à base de jonction à effet tunnel magnétique (MTJ), un dispositif à base de DW (Domain Wall) et de SOT (Spin Orbit Transfer), un dispositif de mémoire à base de thyristor, ou une combinaison de n'importe lesquels des dispositifs ci-dessus, ou une autre mémoire. Le dispositif de mémoire peut faire référence à la puce elle-même et/ou à un produit de mémoire en boîtier. Dans certains modes de réalisation, le dispositif de mémoire peut comprendre une architecture à points de croisement empilables sans transistor dans laquelle les cellules de mémoire sont situées à l'intersection de lignes de mots et de lignes de bits et sont adressables individuellement et dans laquelle le stockage des bits se fonde sur un changement de la résistance volumique. Se référant à présent à la , dans certains modes de réalisation, le nœud 400 peut être réalisé sous la forme d'un nœud de calcul 500. Le nœud de calcul 500 peut être configuré pour effectuer des tâches de calcul. Bien entendu, comme évoqué ci-dessus, le nœud de calcul 500 peut s'appuyer sur d'autres nœuds, tels que des nœuds d'accélération et/ou des nœuds de stockage, pour effectuer des tâches de calcul. Dans le nœud de calcul 500 présenté à titre d'illustration, les ressources physiques 320 sont réalisées sous la forme de processeurs 520. Bien que seulement deux processeurs 520 soient représentés sur la , il est à noter que, dans d'autres modes de réalisation, le nœud de calcul 500 peut comprendre des processeurs supplémentaires 520. A titre d'illustration, les processeurs 520 sont réalisés sous la forme de processeurs 520 hautes performances et peuvent être configurés pour fonctionner à une puissance nominale relativement élevée. Dans certains modes de réalisation, le nœud de calcul 500 peut également comprendre une interconnexion processeur à processeur 542. L'interconnexion processeur à processeur 542 peut être réalisée sous la forme de tout type d'interconnexion de communication capable de faciliter les communications d'interconnexion processeur à processeur 542. Dans le mode de réalisation présenté à titre d'illustration, l'interconnexion processeur à processeur 542 est réalisée sous la forme d'une interconnexion point à point à grande vitesse (par exemple, plus rapide que le sous-système I/O 322). L'interconnexion processeur à processeur 542 peut par exemple être réalisée sous la forme d'une interconnexion QuickPath (QPI), d'une interconnexion UltraPath (UPI) ou d'une autre interconnexion point à point à grande vitesse dédiée aux communications processeur à processeur (par exemple, PCIe ou CXL). Le nœud de calcul 500 comprend également un circuit de communication 530. Le circuit de communication 530 présenté à titre d'illustration comprend un contrôleur d'interface réseau (NIC) 532, qui peut également être appelé interface de matrice d'interconnexion hôte (HFI). Le NIC 532 peut être réalisé sous la forme, ou par ailleurs être doté, de tout type de circuit intégré, de circuits discrets, de puces de contrôleur, de jeux de puces, de cartes d'extension, de cartes filles, de cartes d'interface réseau ou d'autres dispositifs pouvant être utilisés par le nœud de calcul 500 pour se connecter à un autre dispositif de calcul (par exemple, à d'autres nœuds 400). Dans certains modes de réalisation, le NIC 532 peut être réalisé sous la forme d'une partie d'un système sur puce (SoC) qui comprend un ou plusieurs processeurs, ou être inclus dans un boîtier multi-puces qui contient également un ou plusieurs processeurs. Dans certains modes de réalisation, le NIC 532 peut comprendre un processeur local (non représenté) et/ou une mémoire locale (non représentée) qui sont tous deux locaux vis-à-vis du NIC 532. Dans ces modes de réalisation, le processeur local du NIC 532 peut être capable d'exécuter une ou plusieurs des fonctions des processeurs 520. En outre ou en variante, dans ces modes de réalisation, la mémoire locale du NIC 532 peut être intégrée à un ou plusieurs composants du nœud de calcul au niveau de la carte, au niveau de la prise, au niveau de la puce et/ou à d'autres niveaux. Dans certains exemples, une interface réseau comprend un contrôleur d'interface réseau ou une carte d'interface réseau. Dans certains exemples, une interface réseau peut comprendre un ou plusieurs d'un contrôleur d'interface réseau (NIC) 532, d'une interface de matrice d'interconnexion hôte (HFI), d'un adaptateur de bus hôte (HBA), d'une interface réseau connectée à un bus ou à une connexion (par exemple, PCIe, CXL, DDR, et autres). Dans certains exemples, une interface réseau peut faire partie d'un commutateur ou d'un système sur puce (SoC). Le circuit de communication 530 est couplé par voie de communication à un connecteur de données optique 534. Le connecteur de données optique 534 est configuré pour s'accoupler à un connecteur de données optique correspondant d'un bâti lorsque le nœud de calcul 500 est monté dans le bâti. À titre d'illustration, le connecteur de données optique 534 comprend une pluralité de fibres optiques qui mènent d'une surface d'accouplement du connecteur de données optique 534 à un émetteur-récepteur optique 536. L'émetteur-récepteur optique 536 est configuré pour convertir des signaux optiques entrants provenant du connecteur de données optique côté bâti en signaux électriques et pour convertir des signaux électriques en signaux optiques sortants vers le connecteur de données optique côté bâti. Bien que représenté comme faisant partie du connecteur de données optique 534 dans le mode de réalisation présenté à titre d'illustration, dans d'autres modes de réalisation, l'émetteur-récepteur optique 536 peut faire partie du circuit de communication 530. Dans certains modes de réalisation, le nœud de calcul 500 peut également comprendre un connecteur d'extension 540. Dans de tels modes de réalisation, le connecteur d'extension 540 est configuré pour s'accoupler avec un connecteur correspondant d'un substrat de carte de circuit d'extension afin de fournir des ressources physiques supplémentaires au nœud de calcul 500. Les ressources physiques supplémentaires peuvent par exemple être utilisées par les processeurs 520 pendant le fonctionnement du nœud de calcul 500. Le substrat de carte de circuit imprimé d'extension peut être sensiblement semblable au substrat de carte de circuit imprimé 302 évoqué ci-dessus et peut comprendre divers composants électriques montés sur celui-ci. Les composants électriques particuliers montés sur le substrat de carte de circuit d'expansion peuvent dépendre de la fonctionnalité prévue du substrat de carte de circuit d'extension. À titre d'exemple, le substrat de carte de circuit imprimé d'extension peut fournir des ressources de calcul, des ressources de mémoire et/ou des ressources de stockage supplémentaires. De ce fait, les ressources physiques supplémentaires du substrat de la carte de circuit imprimé d'extension peuvent comprendre, sans s'y limiter, des processeurs, des dispositifs de mémoire, des dispositifs de stockage et/ou des circuits accélérateurs comprenant par exemple des réseaux de portes programmables par l'utilisateur (FPGA), des circuits intégrés spécifiques d'application (ASIC), des coprocesseurs de sécurité, des unités de traitement graphique (GPU), des circuits d'apprentissage automatique ou d'autres processeurs, contrôleurs, dispositifs et/ou circuits spécialisés. Se référant à présent à la , dans certains modes de réalisation, le nœud 400 peut être réalisé sous la forme d'un nœud accélérateur 600. Le nœud accélérateur 600 est configuré pour exécuter des tâches de calcul spécialisées, telles qu'un apprentissage automatique, un chiffrement, un hachage ou toute autre tâche exigeante en termes de calcul. Dans certains modes de réalisation, un nœud de calcul 500 peut par exemple délester des tâches sur le nœud accélérateur 600 pendant le fonctionnement. Le nœud accélérateur 600 comprend divers composants semblables aux composants du nœud 400 et/ou du nœud de calcul 500, qui ont été identifiés sur la par les mêmes références numériques. Dans le nœud accélérateur 600 présenté à titre d'illustration, les ressources physiques 320 sont réalisées sous la forme de circuits accélérateurs 620. Bien que seulement deux circuits accélérateurs 620 soient représentés sur la , il est à noter que, dans d'autres modes de réalisation, le nœud accélérateur 600 peut comprendre des circuits accélérateurs 620 supplémentaires. Les circuits accélérateurs 620 peuvent être réalisés sous la forme de tout type de processeur, coprocesseur, circuit de calcul ou autre dispositif capable d'effectuer des opérations de calcul ou de traitement. À titre d'exemple, les circuits accélérateurs 620 peuvent être réalisés sous une forme telle que des unités centrales de traitement, des cœurs, des réseaux de portes programmables par l'utilisateur (FPGA), des circuits intégrés spécifiques d'application (ASIC), une logique de commande programmable (PCL), des coprocesseurs de sécurité, des unités de traitement graphique (GPU), des unités de traitement neuromorphiques, des ordinateurs quantiques, des circuits d'apprentissage automatique ou d'autres processeurs, contrôleurs, dispositifs et/ou circuits spécialisés. Dans certains modes de réalisation, le nœud accélérateur 600 peut également comprendre une interconnexion accélérateur à accélérateur 642. Comme pour l'interconnexion ressource à ressource 324 du nœud 300 évoquée plus haut, l'interconnexion accélérateur à accélérateur 642 peut être réalisée sous la forme de n'importe quel type d'interconnexion de communication capable de faciliter les communications accélérateur à accélérateur. Dans le mode de réalisation présenté à titre d'illustration, l'interconnexion accélérateur à accélérateur 642 est réalisée sous la forme d'une interconnexion point à point à grande vitesse (par exemple, plus rapide que le sous-système I/O 322). L'interconnexion accélérateur à accélérateur 642 peut par exemple être réalisée sous la forme d'une interconnexion QuickPath (QPI), d'une interconnexion UltraPath (UPI) ou d'une autre interconnexion point à point à grande vitesse dédiée aux communications processeur à processeur. Dans certains modes de réalisation, les circuits accélérateurs 620 peuvent être chaînés en guirlande avec un circuit accélérateur primaire 620 connecté au NIC 532 et à la mémoire 420 par l'intermédiaire du sous-système I/O 322 et un circuit accélérateur secondaire 620 connecté au NIC 532 et à la mémoire 420 par l'intermédiaire d'un circuit accélérateur primaire 620. Se référant à présent à la , dans certains modes de réalisation, le nœud 400 peut être réalisé sous la forme d'un nœud de stockage 700. Le nœud de stockage 700 est configuré pour stocker des données dans une unité de stockage de données 750 locale vis-à-vis du nœud de stockage 700. À titre d'exemple, pendant le fonctionnement, un nœud de calcul 500 ou un nœud accélérateur 600 peut stocker et récupérer des données dans la mémoire de données 750 du nœud de stockage 700. Le nœud de stockage 700 comprend divers composants semblables à des composants du nœud 400 et/ou du nœud de calcul 500, qui ont été identifiés sur la à l'aide des mêmes références numériques. Dans le nœud de stockage 700 présenté à titre d'illustration, les ressources physiques 320 sont réalisées sous la forme de contrôleurs de stockage 420. Bien que seulement deux contrôleurs de stockage 420 soient représentés sur la , il est à noter que, dans d'autres modes de réalisation, le nœud de stockage 700 peut comprendre des contrôleurs de stockage 420 supplémentaires. Les contrôleurs de stockage 420 peuvent être réalisés sous la forme de tout type de processeur, contrôleur ou de circuit de commande capable de commander le stockage et la récupération de données dans l'unité de stockage de données 750 sur la base de demandes reçues par l'intermédiaire du circuit de communication 530. Dans le mode de réalisation présenté à titre d'illustration, les contrôleurs de stockage 420 sont réalisés sous la forme de processeurs ou de contrôleurs à puissance relativement faible. À titre d'exemple, dans certains modes de réalisation, les contrôleurs de stockage 420 peuvent être configurés pour fonctionner à une puissance nominale d'environ 75 watts. Dans certains modes de réalisation, le nœud de stockage 700 peut également comprendre une interconnexion contrôleur à contrôleur 742. Comme pour l'interconnexion ressource à ressource 324 du nœud 400 évoquée plus haut, l'interconnexion contrôleur à contrôleur 742 peut être réalisée sous la forme de tout type d'interconnexion de communication capable de faciliter les communications contrôleur à contrôleur. Dans le mode de réalisation présenté à titre d'illustration, l'interconnexion contrôleur à contrôleur 742 est réalisée sous la forme d'une interconnexion point à point à grande vitesse (par exemple, plus rapide que le sous-système I/O 322). L'interconnexion contrôleur à contrôleur 742 peut par exemple être réalisée sous la forme d'une interconnexion QuickPath (QPI), d'une interconnexion UltraPath (UPI) ou d'une autre interconnexion point à point à grande vitesse dédiée aux communications processeur à processeur. Se référant à présent à la , dans certains modes de réalisation, le nœud 400 peut être réalisé sous la forme d'un nœud de mémoire 800. Le nœud de mémoire 800 est configuré pour fournir à d'autres nœuds 400 (par exemple, à des nœuds de calcul 500, à des nœuds accélérateurs 600, etc.) un accès à une mémoire mutualisée (par exemple, dans deux ou plusieurs jeux 830, 832 de dispositifs de mémoire 420) locale vis-à-vis du nœud de stockage 700. À titre d'exemple, pendant le fonctionnement, un nœud de calcul 500 ou un nœud accélérateur 600 peut écrire et/ou lire à distance dans un ou plusieurs des jeux de mémoires 830, 832 du nœud de mémoire 800 en utilisant un espace d'adressage logique qui réalise un mappage vers des adresses physiques dans les jeux de mémoires 830, 832. Dans le nœud de mémoire 800 présenté à titre d'illustration, les ressources physiques 320 sont réalisées sous la forme de contrôleurs mémoire 820. Bien que seulement deux contrôleurs mémoire 820 soient représentés sur la , il est à noter que, dans d'autres modes de réalisation, le nœud de mémoire 800 peut comprendre des contrôleurs mémoire 820 supplémentaires. Les contrôleurs mémoire 820 peuvent être réalisés sous la forme de tout type de processeur, contrôleur ou circuit de commande capable de commander l'écriture et la lecture de données dans les jeux de mémoires 830, 832 sur la base de demandes reçues en provenance du circuit de communication 530. Dans le mode de réalisation présenté à titre d'illustration, chaque contrôleur mémoire 820 est connecté à un jeu de mémoires 830, 832 correspondant pour écrire et lire dans et depuis des dispositifs de mémoire 420 dans le jeu de mémoires 830, 832 correspondant et appliquer toutes les permissions (par exemple, lecture, écriture, etc.) associées au nœud 400 ayant envoyé une requête au nœud de mémoire 800 pour effectuer une opération d'accès mémoire (par exemple, lecture ou écriture). Dans certains modes de réalisation, le nœud de mémoire 800 peut également comprendre une interconnexion contrôleur à contrôleur 842. Comme pour l'interconnexion ressource à ressource 324 du nœud 400 évoquée plus haut, l'interconnexion contrôleur à contrôleur 842 peut être réalisée sous la forme de tout type d'interconnexion de communication capable de faciliter les communications contrôleur à contrôleur. Dans le mode de réalisation présenté à titre d'illustration, l'interconnexion contrôleur à contrôleur 842 est réalisée sous la forme d'une interconnexion point à point à grande vitesse (par exemple, plus rapide que le sous-système I/O 322). L'interconnexion contrôleur à contrôleur 842 peut par exemple être réalisée sous la forme d'une interconnexion QuickPath (QPI), d'une interconnexion UltraPath (UPI) ou d'une autre interconnexion point à point à grande vitesse dédiée aux communications processeur à processeur. De ce fait, dans certains modes de réalisation, un contrôleur mémoire 820 peut accéder, par l'intermédiaire de l'interconnexion contrôleur à contrôleur 842, à une mémoire qui est située dans le jeu de mémoires 832 associé à un autre contrôleur mémoire 820. Dans certains modes de réalisation, un contrôleur mémoire évolutif est constitué de plusieurs contrôleurs mémoire plus petits, appelés ici "micropuces", sur un nœud de mémoire (par exemple, le nœud de mémoire 800). Les micropuces peuvent être interconnectées (par exemple, en utilisant un EMIB (Embedded Multi-Die Interconnect Bridge)). Le contrôleur mémoire à micropuces combinées peut évoluer vers un nombre relativement important de contrôleurs mémoire et de ports I/O (par exemple, jusqu'à 16 canaux de mémoire). Dans certains modes de réalisation, les contrôleurs mémoire 820 permettent de mettre en œuvre un entrelacement de mémoire (par exemple, une adresse mémoire est mappée sur le jeu de mémoires 830, l'adresse mémoire suivante est mappée sur le jeu de mémoires 832, et la troisième adresse est mappée sur le jeu de mémoires 830, etc.). L'entrelacement peut être géré au sein des contrôleurs mémoire 820, ou à partir de connecteurs logiciels de CPU (par exemple, du nœud de calcul 500) parmi des liaisons de réseau allant vers les jeux de mémoires 830, 832, et permet d'améliorer la latence associée à l'exécution d'opérations d'accès mémoire par rapport à l'accès à des adresses mémoire contiguës depuis un même dispositif de mémoire. De plus, dans certains modes de réalisation, le nœud de mémoire 800 peut être connecté à un ou plusieurs autres nœuds 400 (par exemple, dans le même bâti 240 ou un bâti 240 adjacent) par l'intermédiaire d'un guide d'ondes, à l'aide du connecteur de guide d'ondes 880. Dans le mode de réalisation présenté à titre d'illustration, les guides d'ondes sont des guides d'ondes de 64 millimètres qui fournissent 16 voies Rx (par exemple, en réception) et 16 voies Tx (par exemple, en émission). Dans le mode de réalisation présenté à titre d'illustration, chaque voie est soit à 16 GHz, soit à 32 GHz. Dans d'autres modes de réalisation, les fréquences peuvent être différentes. L'utilisation d'un guide d'ondes peut autoriser un accès à haut débit à la mémoire mutualisée (par exemple, les jeux de mémoires 830, 832) à un autre nœud (par exemple, un nœud 400 dans le même bâti 240 ou dans un bâti 240 adjacent au nœud de mémoire 800) sans augmenter la charge imposée au connecteur de données optique 534. Se référant à présent à la , un système destiné à exécuter une ou plusieurs charges de travail (par exemple, des applications) peut être mis en œuvre. Dans le mode de réalisation présenté à titre d'illustration, le système 910 comprend un serveur orchestrateur 920, qui peut être réalisé sous la forme d'un nœud géré comprenant un dispositif de calcul (par exemple, un processeur 520 sur un nœud de calcul 500) exécutant un logiciel de gestion (par exemple, un environnement d'exploitation en nuage, tel que OpenStack) qui est couplé par voie de communication à de multiples nœuds 400 comprenant un grand nombre de nœuds de calcul 930 (dont chacun est par exemple semblable au nœud de calcul 500), des nœuds de mémoire 940 (dont chacun est par exemple semblable au nœud de mémoire 800), des nœuds accélérateurs 950 (dont chacun est par exemple semblable au nœud de mémoire 600), et des nœuds de stockage 960 (dont chacun est par exemple semblable au nœud de stockage 700). Un ou plusieurs des nœuds 930, 940, 950, 960 peut ou peuvent être regroupé(s) en un nœud géré 970, par exemple par le serveur orchestrateur 920, pour réaliser collectivement une charge de travail (par exemple, une application 932 exécutée dans une machine virtuelle ou dans un conteneur). Le nœud géré 970 peut être réalisé sous la forme d'un assemblage de ressources physiques 320, telles que des processeurs 520, des ressources de mémoire 420, des circuits accélérateurs 620, ou une unité de stockage de données 750, à partir d'un même nœud 400 ou de nœuds différents. De plus, le nœud géré peut être établi, défini ou "lancé" par le serveur orchestrateur 920 au moment où une charge de travail doit être affectée au nœud géré ou à tout autre moment, et peut exister indépendamment du fait que des charges de travail soient actuellement affectées au nœud géré. Dans le mode de réalisation présenté à titre d'illustration, le serveur orchestrateur 920 peut sélectivement allouer et/ou désallouer des ressources physiques 320 parmi les nœuds 400 et/ou ajouter ou supprimer un ou plusieurs nœuds 400 du nœud géré 970 en fonction de qualités de service (QoS) cibles (par exemple, un débit cible, une latence cible, un nombre cible d'instructions par seconde, etc.) associées à un accord de niveau de service pour la charge de travail (par exemple, l'application 932). Ce faisant, le serveur orchestrateur 920 peut recevoir des données de télémétrie représentatives de conditions de performances (par exemple, un débit, une latence, des instructions par seconde, etc.) dans chaque nœud 400 du nœud géré 970 et comparer les données de télémétrie aux qualités de service cibles pour déterminer si les qualités de service cibles sont satisfaites. Le serveur orchestrateur 920 peut en outre déterminer si une ou plusieurs ressources physiques peuvent être désallouées du nœud géré 970 tout en continuant à satisfaire les qualités de service cibles, libérant ainsi ces ressources physiques pour une utilisation dans un autre nœud géré (par exemple, pour exécuter une charge de travail différente). En variante, si les QoS cibles ne sont pas satisfaites à l'instant présent, le serveur orchestrateur 920 peut déterminer qu'il faut allouer dynamiquement des ressources physiques supplémentaires pour aider à l'exécution de la charge de travail (par exemple, l'application 932) pendant l'exécution de la charge de travail. De même, le serveur orchestrateur 920 peut déterminer qu'il est nécessaire de désallouer dynamiquement des ressources physiques d'un nœud géré si le serveur orchestrateur 920 détermine que la désallocation de la ressource physique permettrait d'atteindre les QoS cibles. De plus, dans certains modes de réalisation, le serveur orchestrateur 920 peut identifier des tendances dans l'utilisation des ressources de la charge de travail (par exemple, l'application 932), comme par exemple en identifiant des phases d'exécution (par exemple, des périodes de temps lors desquelles différentes opérations, ayant chacune des caractéristiques d'utilisation de ressources différentes, sont exécutées) de la charge de travail (par exemple, l'application 932) et en identifiant de manière préemptive des ressources disponibles dans le centre de données et en les allouant au nœud géré 970 (par exemple, au cours d'une période de temps prédéfinie du début de la phase associée). Dans certains modes de réalisation, le serveur orchestrateur 920 peut modéliser les performances sur la base de diverses latences et d'un schéma de distribution afin de répartir les charges de travail entre des nœuds de calcul et d'autres ressources (par exemple, des nœuds accélérateurs, des nœuds de mémoire, des nœuds de stockage) dans le centre de données. À titre d'exemple, le serveur orchestrateur 920 peut utiliser un modèle qui tient compte des performances de ressources sur les nœuds 400 (par exemple, les performances des FPGA, la latence des accès mémoire, etc.) et des performances (par exemple, congestion, latence, bande passante) du trajet passant par le réseau et allant vers la ressource (par exemple, le FPGA). De ce fait, le serveur orchestrateur 920 peut déterminer quelle(s) ressource(s) doit (doivent) être utilisée(s) et avec quelles charges de travail sur la base de la latence totale associée à chaque ressource potentielle disponible dans le centre de données 100 (par exemple, la latence associée aux performances de la ressource elle-même en plus de la latence associée au trajet passant à travers le réseau entre le nœud de calcul exécutant la charge de travail et le nœud 400 sur lequel se trouve la ressource). Dans certains modes de réalisation, le serveur orchestrateur 920 peut générer une cartographie du dégagement de chaleur dans le centre de données 100 en utilisant des données de télémétrie (par exemple, des températures, des vitesses de ventilateur, etc.) communiquées par les nœuds 400 et allouer des ressources aux nœuds gérés en fonction de la cartographie du dégagement de chaleur et du dégagement de chaleur prédit associé à différentes charges de travail, afin de maintenir un objectif de température et de répartition de chaleur dans le centre de données 100. En outre ou en variante, dans certains modes de réalisation, le serveur orchestrateur 920 peut organiser les données de télémétrie reçues sous la forme d'un modèle hiérarchique qui est représentatif d'une relation entre les nœuds gérés (par exemple, une relation spatiale telle que les emplacements physiques des ressources des nœuds gérés dans le centre de données 100 et/ou une relation fonctionnelle, telle que des groupements des nœuds gérés par les clients auxquels les nœuds gérés fournissent des services, les types de fonctions typiquement réalisées par les nœuds gérés, les nœuds gérés qui partagent ou échangent typiquement des charges de travail les uns avec les autres, etc.). Sur la base des différences d'emplacements physiques et de ressources dans les nœuds gérés, une charge de travail donnée peut présenter des taux d'utilisation de ressources différents (par exemple, provoquer une température interne différente, utiliser un pourcentage différent de la capacité du processeur ou de la mémoire) parmi les ressources de différents nœuds gérés. Le serveur orchestrateur 920 peut déterminer les différences sur la base des données de télémétrie stockées dans le modèle hiérarchique et prendre en compte les différences dans une prédiction de l'utilisation future des ressources d'une charge de travail si la charge de travail est réaffectée d'un nœud géré à un autre nœud géré, afin d'équilibrer avec précision l'utilisation des ressources dans le centre de données 100. Dans certains modes de réalisation, le serveur orchestrateur 920 peut identifier des tendances dans les phases d'utilisation des ressources des charges de travail et utiliser ces tendances pour prédire l'utilisation future des ressources des charges de travail. Pour réduire la charge de calcul sur le serveur orchestrateur 920 et la charge de transfert de données sur le réseau, dans certains modes de réalisation, le serveur orchestrateur 920 peut envoyer des informations d'auto-test aux nœuds 400 afin de permettre à chaque nœud 400 de déterminer localement (par exemple, sur le nœud 400) si des données de télémétrie générées par le nœud 400 satisfont à une ou plusieurs conditions (par exemple, une capacité disponible qui satisfait à un seuil prédéfini, une température qui satisfait à un seuil prédéfini, etc.). Chaque nœud 400 peut ensuite renvoyer un résultat simplifié (par exemple, oui ou non) au serveur orchestrateur 920, que le serveur orchestrateur 920 peut utiliser pour déterminer l'allocation de ressources à des nœuds gérés. Environnements de réseaux de périphérie L'informatique de périphérie, à un niveau général, désigne la mise en œuvre, la coordination et l'utilisation de l'informatique et de ressources à des emplacements plus proches de la "périphérie" ou de la collection de "périphéries" du réseau. L'objectif de cette organisation est d'améliorer le coût total de possession, de réduire la latence des applications et du réseau, de réduire le trafic de liaison de retour du réseau et la consommation d'énergie associée, d'améliorer les capacités des services et d'améliorer la conformité aux exigences de sécurité ou de confidentialité des données (en particulier par rapport à l'informatique en nuage classique). Les composants qui peuvent effectuer des opérations de calcul en périphérie ("nœuds de périphérie") peuvent résider en un lieu quelconque requis par l'architecture du système ou par un service ad hoc (par exemple, dans un centre de données de calcul à hautes performances ou dans une installation en nuage ; un serveur de nœud de périphérie désigné, un serveur d'entreprise, un serveur de bord de route, un bureau central de télécommunications ; ou un dispositif de périphérie local ou homologue qui est desservi par consommation de services de périphérie). Les applications qui ont été conçues pour l'informatique de périphérie comprennent, sans s'y limiter, la virtualisation de fonctions de réseau traditionnelles (par exemple, pour exploiter des services de télécommunications ou l'Internet) et l'introduction de fonctions et de services de nouvelle génération (par exemple, pour prendre en charge des services de réseau 5G). Comme cas d'utilisation dont on peut projeter qu'ils feront un usage intensif de l'informatique de périphérie on peut citer les voitures connectées à conduite autonome, la surveillance, l'analyse de données de dispositifs de l'Internet des Objets (IoT), le codage et l'analyse vidéo, les services de localisation, la détection de dispositifs dans les villes intelligentes, parmi de nombreux autres services à forte intensité de réseau et de calcul. L'informatique de périphérie peut, dans certains scénarios, offrir ou héberger un service distribué de type nuage, afin d'offrir une orchestration et une gestion des applications et des instances de services coordonnées parmi de nombreux types de ressources de stockage et de calcul. On s'attend également à ce que l'informatique de périphérie soit étroitement intégrée à des cas d'utilisation existants et à la technologie développée pour l'IoT et les configurations de réseaux en Brouillard/distribués, car les dispositifs d'extrémité, les clients et les passerelles tentent d'accéder à des ressources et à des applications du réseau en des lieux plus proches de la périphérie du réseau. Les modes de réalisation suivants se rapportent de manière générale au traitement de données, à la gestion de services, à l'allocation de ressources, à la gestion de calcul, à la communication réseau, au partitionnement d'applications et aux mises en œuvre de systèmes de communication, et en particulier, à des techniques et configurations permettant d'adapter divers dispositifs et entités informatiques de périphérie afin qu'ils prennent en charge dynamiquement de multiples entités (par exemple, de multiples locataires, utilisateurs, parties prenantes, instances de service, applications, etc.) dans un environnement informatique de périphérie distribué. Dans la description qui suit, on divulgue des procédés, des configurations et des appareils associés permettant d'apporter diverses améliorations à la configuration et aux capacités fonctionnelles d'une architecture informatique de périphérie et d'un système informatique de périphérie effectuant une mise en œuvre. Ces améliorations peuvent bénéficier à une variété de cas d'utilisation, en particulier ceux qui impliquent de multiples parties prenantes du système informatique de périphérie, que ce soit sous la forme de multiples utilisateurs d'un système, de multiples locataires (tenants) sur un système, de multiples dispositifs ou équipements utilisateurs interagissant avec un système, de multiples services offerts par un système, de multiples ressources disponibles ou gérées dans un système, de multiples formes d'accès au réseau exposées pour un système, de multiples lieux d'exploitation pour un système, et autres. Ces aspects et considérations multidimensionnels sont généralement évoqués ici comme des contraintes "multi-entités", avec une évocation particulière des ressources gérées ou orchestrées dans des configurations informatiques de périphérie multi-locataires et multi-services. Dans les systèmes de mise en réseau de périphérie présentés à titre d'illustration et décrits ci-après, des ressources de calcul et de stockage sont déplacées plus près de la périphérie du réseau (par exemple, plus près des clients, des dispositifs d'extrémité ou des "choses"). En rapprochant les ressources de calcul et de stockage du dispositif qui produit ou utilise les données, il est possible de respecter diverses contraintes de latence, de conformité et/ou de coût financier ou en ressources par rapport à un système classique en réseau (par exemple, l'informatique en nuage). Pour ce faire, dans certains exemples, des mutualisations de ressources de calcul, de mémoire et/ou de stockage peuvent être situées sur des serveurs locaux, des routeurs et/ou d'autres équipements de réseau, ou en être équipés. Ces ressources locales facilitent le respect de contraintes imposées au système. À titre d'exemple, les ressources locales de calcul et de stockage permettent à un système de périphérie d'effectuer des calculs en temps réel ou quasi réel, ceci pouvant être pris en compte dans les cas d'utilisation à faible latence tels que la conduite autonome, la surveillance vidéo et la consommation multimédia mobile. En outre, ces ressources pourront bénéficier d'une gestion des services dans un système de périphérie qui offre une possibilité d'évolutivité et de respect de SLA locaux, de gestion d'exigences de service à plusieurs niveaux et d'activation de fonctionnalités et de fonctions locales sur une base temporaire ou permanente. Un système informatique de périphérie présenté à titre d'illustration peut prendre en charge et/ou fournir divers services à des dispositifs d'extrémité (par exemple, des équipements utilisateurs (UE) clients), dont chacun peut avoir des exigences ou des contraintes différentes. Certains services peuvent par exemple avoir des contraintes de priorité ou de qualité de service (QoS) (par exemple, des données de trafic destinées aux véhicules autonomes peuvent avoir une priorité plus élevée que des données de capteurs de température), de fiabilité et de résilience (par exemple, des données de trafic peuvent nécessiter une fiabilité critique, tandis qu'une certaine variance des erreurs est acceptable pour des données de température), ainsi que des contraintes de puissance, de refroidissement et de facteur de forme. Ces contraintes techniques, et d'autres encore, peuvent présenter une complexité et des défis techniques importants lors de leur application dans le contexte multipartite. Cependant, les avantages de l'informatique de périphérie s'accompagnent des mises en garde suivantes. Les dispositifs situés à la périphérie sont souvent limités en ressources et il existe donc une pression sur l'utilisation des ressources de périphérie. En général, ce problème est résolu par la mutualisation de ressources de mémoire et de stockage pour une utilisation par plusieurs utilisateurs (locataires) et dispositifs. La périphérie peut être soumise à des contraintes en matière d'alimentation et de refroidissement, et l'utilisation d'énergie doit donc être prise en compte par les applications qui consomment le plus d'énergie. Il peut y avoir des compromis puissance-performances inhérents à ces ressources de mémoire mutualisées, car beaucoup d'entre elles sont susceptibles d'utiliser des technologies de mémoire émergentes, pour lesquelles une plus grande puissance nécessite une plus grande bande passante de mémoire. De même, il est nécessaire d'améliorer la sécurité des matériels et des fonctions dignes de confiance à racine de confiance, car les emplacements de périphérie peuvent être dépourvus de personnels et peuvent même nécessiter un accès autorisé (par exemple, lorsqu'ils sont hébergés en un lieu tiers). Ces problèmes sont amplifiés dans le nuage de périphérie dans un contexte multi-locataires, multi-propriétaires ou multi-accès, dans lequel des services et des applications sont demandés par de nombreux utilisateurs, notamment lorsque l'utilisation du réseau fluctue dynamiquement et lorsque la composition des multiples parties prenantes, des cas d'utilisation et des services change. La est un schéma fonctionnel 1000 représentant une vue d'ensemble d'une configuration destinée à l'informatique de périphérie, qui comprend une couche de traitement désignée dans un grand nombre des exemples suivants sous le nom de "nuage de périphérie". Comme illustré, le nuage de périphérie 1010 est colocalisé à un emplacement de périphérie, tel qu'un point d'accès ou une station de base 1040, un concentrateur de traitement local 1050, ou un bureau central 1020, et peut donc comprendre de multiples entités, dispositifs et instances d'équipements. Le nuage de périphérie 1010 est situé beaucoup plus près des sources de données des points d'extrémité (consommateur et producteur) 1060 (par exemple, des véhicules autonomes 1061, des équipements utilisateurs 1062, des équipements commerciaux et industriels 1063, des dispositifs de capture vidéo 1064, des drones 1065, des villes intelligentes et des dispositifs de construction 1066, des capteurs et des dispositifs IoT 1067, etc.) que le centre de données en nuage 1030. Les ressources de calcul, de mémoire et de stockage qui sont offertes en périphérie dans le nuage de périphérie 1010 sont déterminants pour la fourniture de temps de réponse à très faible latence pour des services et des fonctions utilisés par les sources de données de points d'extrémité 1060, et pour la réduction du trafic de liaison de retour réseau depuis le nuage de périphérie 1010 vers le centre de données en nuage 1030, améliorant ainsi la consommation d'énergie et les utilisations globales du réseau, entre autres avantages. La capacité de calcul, la mémoire et le stockage sont des ressources rares, et diminuent généralement en fonction de l'emplacement de périphérie (par exemple, de moindres ressources de traitement sont disponibles sur des dispositifs d'extrémité consommateurs, qu'au niveau d'une station de base, d'un bureau central). Cependant, plus l'emplacement de périphérie est proche du point d'extrémité (par exemple, de l'équipement utilisateur (UE)), plus l'espace et la puissance sont souvent limités. Par conséquent, l'informatique de périphérie cherche à réduire la quantité de ressources nécessaires pour les services de réseau, en distribuant davantage de ressources qui sont situées plus près tant géographiquement qu'en termes de temps d'accès au réseau. L'informatique de périphérie tente ainsi de rapprocher les ressources informatiques des données de charge de travail lorsque cela est approprié, ou de rapprocher les données de charge de travail des ressources informatiques. On décrit ci-après certains aspects d'une architecture de nuage de périphérie qui couvre de multiples déploiements potentiels et tient compte de restrictions que certains opérateurs de réseau ou fournisseurs de services peuvent imposer dans leurs propres infrastructures. Il s'agit notamment de la variation des configurations en fonction de l'emplacement de périphérie (parce que les périphéries, par exemple au niveau d'une station de base, peuvent avoir des performances et des capacités plus limitées dans un scénario multi-locataires) ; des configurations basées sur le type de ressources de calcul, de mémoire, de stockage, de matrice d'interconnexion, d'accélération ou autres, disponibles à des emplacements de périphérie, des niveaux des emplacements ou des groupes d'emplacements ; des capacités de service, de sécurité, de gestion et d'orchestration ; et des objectifs connexes permettant d'assurer le caractère utilisable et les performances des services d'extrémité. Ces déploiements peuvent effectuer des traitements dans des couches réseau qui peuvent être considérées comme des couches "de périphérie proche", "de périphérie rapprochée", "de périphérie locale", "de périphérie intermédiaire" ou "de périphérie éloignée", en fonction des caractéristiques de latence, de distance et de synchronisation. L'informatique de périphérie est un paradigme en développement dans lequel le calcul est effectué à la "périphérie" d'un réseau ou plus près de celle-ci, typiquement par utilisation d'une plateforme de calcul agencée de manière appropriée (par exemple, x86, ARM, Nvidia ou une autre architecture matérielle de calcul basée sur une CPU/GPU) mise en œuvre dans des stations de base, des passerelles, des routeurs de réseau ou d'autres dispositifs qui sont beaucoup plus proches des dispositifs d'extrémité produisant et consommant les données. À titre d'exemple, des serveurs de passerelles de périphérie peuvent être équipés de ressources de mémoire et de stockage mutualisées pour effectuer des calculs en temps réel pour des cas d'utilisation à faible latence (par exemple, la conduite autonome ou la surveillance vidéo) pour des dispositifs clients connectés. Ou encore, à titre d'exemple, des stations de base peuvent être augmentées de ressources de calcul et d'accélération pour traiter directement des charges de travail de services pour des équipements utilisateurs connectés, sans avoir à échanger davantage de données par l'intermédiaire de réseaux de liaison de retour. Ou encore, à titre d'exemple, des matériels de gestion de réseau du bureau central peuvent être remplacés par des matériels informatiques normalisés qui exécutent des fonctions de réseau virtualisées et offrent des ressources de calcul pour l'exécution de services et de fonctions de consommation destinées à des dispositifs connectés. En variante, un agencement comportant des matériels combinés à des fonctions virtualisées, communément appelé agencement hybride, peut également être mis en œuvre de manière satisfaisante. Dans les réseaux informatiques de périphérie, il peut y avoir des scénarios de services dans lesquels la ressource de calcul sera "déplacée" vers les données, ainsi que des scénarios dans lesquels les données seront "déplacées" vers la ressource de calcul. Ou encore, à titre d'exemple, des ressources de calcul, d'accélération et de réseau de stations de base peuvent fournir des services pour une adaptation aux demandes de charge de travail en fonction des besoins en activant une capacité dormante (abonnement, capacité sur demande) afin de gérer des cas particuliers, des urgences ou d'assurer la longévité des ressources déployées tout au long d'un cycle de vie mis en œuvre nettement plus long. La illustre des couches opérationnelles parmi des points d'extrémité, un nuage de périphérie et des environnements informatiques en nuage. Plus précisément, la illustre des exemples de cas d'utilisation informatiques 1105, utilisant le nuage de périphérie 1010 parmi de multiples couches d'informatique en réseau présentées à titre d'illustration. Les couches commencent par une couche de point d'extrémité (dispositifs et objets) 1100, qui accède au nuage de périphérie 1010 pour mener des activités de création, d'analyse et de consommation de données. Le nuage de périphérie 1010 peut couvrir plusieurs couches réseau, telles qu'une couche de dispositifs de périphérie 1110 comportant des passerelles, des serveurs sur site ou des équipements de réseau (nœuds 1115) situés dans des systèmes de périphérie physiquement proches ; une couche d'accès au réseau 1120, englobant des stations de base, des unités de traitement radio, des concentrateurs de réseau, des centres de données (DC) régionaux ou des équipements de réseau locaux (équipements 1125) ; et tout équipement, dispositif ou nœud situé entre les deux (dans la couche 1112, non illustrée en détail). Les communications en réseau à l'intérieur du nuage de périphérie 1010 et parmi les diverses couches peuvent être effectuées par l'intermédiaire d'un nombre quelconque de supports câblés ou sans fil, y compris par des architectures et des technologies de connectivité non représentées. Des exemples de latence, résultant de la distance de communication du réseau et des contraintes de temps de traitement, peuvent aller de moins d'une milliseconde (ms) dans la couche de points d'extrémité 1100, de moins de 5 ms dans la couche de dispositifs de périphérie 1110, et jusqu'à 10 à 40 ms lors des communications avec des nœuds de la couche d'accès au réseau 1120. Au-delà du nuage de périphérie 1010, se trouvent des couches réseau de cœur 1130 et de centre de données en nuage 1140, qui présentent chacune une latence croissante (par exemple, entre 50 et 60 ms au niveau de la couche réseau de cœur 1130, et 100 ms ou plus au niveau de la couche de centre de données en nuage). Il en résulte que des opérations effectuées dans un centre de données de réseau de cœur 1135 ou un centre de données en nuage 1145, avec des latences d'au moins 50 à 100 ms ou plus, ne seront pas en mesure de réaliser de nombreuses fonctions critiques en termes de temps des cas d'utilisation 1105. Chacune de ces valeurs de latence est présentée à des fins d'illustration et de mise en contraste ; il est clair que l'utilisation d'autres supports et technologies de réseau d'accès peut réduire davantage les latences. Dans certains exemples, les parties respectives du réseau peuvent être classées en tant que couches de "bord rapproché", de "bord local", de "bord proche", de "bord intermédiaire" ou de "bord éloigné", par rapport à une source et à une destination du réseau. À titre d'exemple, du point de vue du centre de données de cœur de réseau 1135 ou d'un centre de données en nuage 1145, un bureau central ou un réseau de données de contenu peut être considéré comme étant situé dans une couche de "bord proche" ("proche" du nuage, ayant des valeurs de latence élevées lors des communications avec des dispositifs et des points d'extrémité correspondant aux cas d'utilisation 1105), tandis qu'un point d'accès, une station de base, un serveur sur site ou une passerelle de réseau peuvent être considérés comme étant situés dans une couche de "bord éloigné" ("éloigné" du nuage, ayant des valeurs de latence faibles lors des communications avec les dispositifs et les points d'extrémité correspondant aux cas d'utilisation 1105). Il est à noter que d'autres catégorisations d'une couche réseau particulière comme constituant un bord "rapproché", "local", "proche", "intermédiaire" ou "éloigné" peuvent être fondées sur la latence, la distance, le nombre de bonds sur le réseau ou d'autres caractéristiques mesurables, telles que mesurées à partir d'une source dans l'une quelconque des couches réseau 1100-1140. Les divers cas d'utilisation 1105 peuvent accéder à des ressources soumises à une pression d'utilisation par des flux entrants, en raison de l'utilisation du nuage de périphérie par de multiples services. Pour obtenir des résultats présentant une faible latence, les services exécutés dans le nuage de périphérie 1010 établissent un équilibre entre des exigences variables en termes de : (a) Priorité (débit ou latence) et Qualité de Service (QoS) (par exemple, le trafic d'une voiture autonome peut avoir une priorité plus élevée qu'un capteur de température en termes d'exigence de temps de réponse ; ou une sensibilité aux performances/goulots d'étranglement peut exister au niveau d'une ressource de calcul/d'accélération, de mémoire, de stockage ou de réseau, selon l'application) ; (b) Fiabilité et Résilience (par exemple, certains flux d'entrée doivent être traités et le trafic être acheminé avec une fiabilité critique pour la mission, tandis que d'autres flux d'entrée peuvent tolérer une défaillance occasionnelle, selon l'application) ; et (c) Contraintes Physiques (par exemple, l'alimentation électrique, le refroidissement et le facteur de forme). La vue de service de bout en bout pour ces cas d'utilisation implique le concept de flux de services et est associée à une transaction. La transaction détaille l'exigence de service globale pour l'entité qui consomme le service, ainsi que les services associés pour les ressources, les charges de travail, les flux de travail et les exigences fonctionnelles et de niveau d'activité. Les services exécutés selon les "termes" décrits peuvent être gérés au niveau de chaque couche de manière à garantir une conformité contractuelle en temps réel et à l'exécution de la transaction pendant le cycle de vie du service. Lorsqu'un composant de la transaction ne respecte pas son SLA convenu, le système dans son ensemble (composants de la transaction) peut offrir la possibilité (1) de comprendre l'impact de la violation du SLA, et (2) de renforcer d'autres composants du système pour rétablir le SLA global de la transaction, et (3) de mettre en œuvre des mesures correctives. Ainsi, compte tenu de ces variantes et caractéristiques de service, l'informatique de périphérie au sein du nuage de périphérie 1010 peut offrir la capacité de desservir et de répondre à de multiples applications relatives aux cas d'utilisation 1105 (par exemple, le suivi d'objets, la vidéosurveillance, les voitures connectées, etc.) en temps réel ou en temps quasi réel, et de répondre à des exigences de latence ultra-faible pour ces multiples applications. Ces avantages permettent une toute nouvelle classe d'applications (Fonctions de Réseau Virtuel (VNF), Fonction en tant que Service (FaaS), Périphérie en tant que Service (EaaS), processus standards, etc.), qui ne peuvent pas tirer parti de l'informatique en nuage classique en raison de la latence ou d'autres limitations. Toutefois, les avantages de l'informatique de périphérie s'accompagnent des réserves suivantes. Les dispositifs situés en périphérie sont souvent limités en ressources et il y a donc une pression sur l'utilisation des ressources de périphérie. En règle générale, ce problème est résolu par la mutualisation des ressources de mémoire et de stockage pour une utilisation par plusieurs utilisateurs (locataires) et dispositifs. La périphérie peut être soumise à des contraintes en matière d'alimentation électrique et de refroidissement, et la consommation d'énergie doit donc être prise en compte par les applications qui consomment le plus d'énergie. Il peut y avoir des compromis puissance-performances inhérents à ces ressources de mémoire mutualisées, car beaucoup d'entre elles sont susceptibles d'utiliser des technologies de mémoire émergentes, pour lesquelles une plus grande puissance nécessite une plus grande bande passante de mémoire. De même, il est nécessaire d'améliorer la sécurité des matériels et des fonctions dignes de confiance à racine de confiance, car les emplacements de périphérie peuvent être dépourvus de personnels et peuvent même nécessiter un accès autorisé (par exemple, lorsqu'ils sont hébergés en un lieu tiers). Ces problèmes sont amplifiés dans le nuage de périphérie 1010 dans un contexte multi-locataires, multi-propriétaires ou multi-accès, dans lequel des services et des applications sont demandés par de nombreux utilisateurs, notamment lorsque l'utilisation du réseau fluctue dynamiquement et lorsque la composition des multiples parties prenantes, des cas d'utilisation et des services change. À un niveau plus générique, un système informatique de périphérie peut être décrit comme englobant un nombre quelconque de déploiements au niveau des couches précédemment évoquées fonctionnant dans le nuage de périphérie 1010 (couches réseau 1100-1140), lesquelles assurent une coordination à partir de dispositifs informatiques clients et distribués. Un ou plusieurs nœuds passerelles de périphérie, un ou plusieurs nœuds d'agrégation de périphérie et un ou plusieurs centres de données de cœur peuvent être répartis parmi des couches du réseau pour fournir une mise en œuvre du système informatique de périphérie par ou pour le compte d'un fournisseur de services de télécommunications ("telco" ou "TSP"), d'un fournisseur de services de l'internet des objets, d'un fournisseur de services en nuage (CSP), d'une entité d'entreprise ou de tout autre nombre d'entités. Diverses mises en œuvre et configurations du système informatique de périphérie peuvent être assurées dynamiquement, par exemple lorsqu'elles sont orchestrées pour atteindre des objectifs de service. Conformément aux exemples fournis ici, un nœud de calcul client peut être réalisé sous la forme de n'importe quel type de composant, dispositif, appareil ou autre élément de point d'extrémité capable de communiquer en tant que producteur ou consommateur de données. En outre, la désignation "nœud" ou "dispositif" telle qu'utilisée dans le système informatique de périphérie ne signifie pas nécessairement que ce nœud ou dispositif fonctionne comme agent/serviteur/suiveur ; les nœuds ou dispositifs du système informatique de périphérie font plutôt référence à des entités, nœuds ou sous-systèmes individuels qui comprennent des configurations matérielles ou logicielles discrètes ou connectées pour faciliter ou utiliser le nuage de périphérie 1010. De ce fait, le nuage de périphérie 1010 est formé de composants de réseau et d'éléments fonctionnels exploités par et dans des nœuds passerelles de périphérie, des nœuds d'agrégation de périphérie ou d'autres nœuds de calcul de périphérie parmi les couches réseau 1110-1130. Le nuage de périphérie 1010 peut donc être réalisé sous la forme de n'importe quel type de réseau qui fournit des ressources de calcul et/ou de stockage de périphérie qui sont situées à proximité de dispositifs d'extrémité à fonctionnalité de réseau d'accès radio (RAN) (par exemple, des dispositifs informatiques mobiles, des dispositifs IoT, des dispositifs intelligents, etc.), qui sont évoqués ici. En d'autres termes, le nuage de périphérie 1010 peut être considéré comme étant une "périphérie" qui relie les dispositifs de points d'extrémité et des points d'accès au réseau traditionnels faisant office de point d'entrée dans des cœurs de réseaux de fournisseurs de services, notamment des réseaux d'opérateurs mobiles (par exemple, des réseaux du Système Global de Communications Mobiles (GSM), des réseaux d'Évolution à Long Terme (LTE), des réseaux 5G/6G, etc.), tout en fournissant également des capacités de stockage et/ou de calcul. D'autres types et formes d'accès au réseau (par exemple, Wi-Fi, réseaux sans fil grande portée, réseaux câblés, notamment réseaux optiques) peuvent également être utilisés au lieu de ces réseaux d'opérateurs 3GPP ou combinés à ceux-ci. Les composants réseau du nuage de périphérie 1010 peuvent être des serveurs, des serveurs multi-entités, des dispositifs informatiques pour appareils et/ou tout autre type de dispositifs informatiques. Le nuage de périphérie 1010 peut par exemple comprendre un dispositif informatique pour appareils qui est un dispositif électronique autonome comprenant un boîtier, un châssis, un coffret ou une coque. Dans certaines circonstances, le boîtier peut être dimensionné pour être portable, de façon à pouvoir être transporté par une personne et/ou expédié. En variante, il peut s'agir d'un module plus petit, par exemple adapté à une installation dans un véhicule. Des exemples de boîtiers peuvent comprendre des matériaux formant une ou plusieurs surfaces extérieures qui protègent partiellement ou totalement le contenu de l'appareil, cette protection pouvant inclure une protection contre les intempéries, une protection contre les environnements dangereux (par exemple, les EMI, les vibrations, les températures extrêmes) et/ou permettre la submersion. Des exemples de boîtiers peuvent comprendre des circuits d'alimentation destinés à fournir de l'énergie à des applications fixes et/ou portables, tels que des entrées d'alimentation AC, des entrées d'alimentation DC, des convertisseurs AC/DC ou DC/AC, des régulateurs de puissance, des transformateurs, des circuits de charge, des batteries, des entrées câblées et/ou des entrées d'alimentation sans fil. Des modes de réalisation plus petits et modulaires peuvent également comprendre un agencement d'antenne extensible ou intégré pour les communications sans fil. Des exemples de boîtiers et/ou de leurs surfaces peuvent comprendre, ou se connecter à, des matériels de montage pour permettre une fixation à des structures telles que des bâtiments, des structures de télécommunication (par exemple, des poteaux, des structures d'antennes, etc.) et/ou des bâtis (par exemple, des bâtis de serveurs, des supports de lames, etc.) Des exemples de boîtiers et/ou de leurs surfaces peuvent porter un ou plusieurs capteurs (par exemple, des capteurs de température, des capteurs de vibrations, des capteurs de lumière, des capteurs acoustiques, des capteurs capacitifs, des capteurs de proximité, etc.). Un ou plusieurs de ces capteurs peuvent être contenus dans, portés par, ou autrement intégrés dans la surface et/ou montés sur la surface de l'appareil. Des exemples de boîtiers et/ou de leurs surfaces peuvent porter un dispositif de connectivité mécanique, tel qu'un matériel de propulsion (par exemple, des roues, des hélices, etc.) et/ou un matériel d'articulation (par exemple, des bras de robot, des appendices pivotants, etc.). Dans certaines circonstances, les capteurs peuvent comprendre un type quelconque de dispositifs d'entrée tels que des matériels d'interface utilisateur (par exemple, des boutons, des interrupteurs, des cadrans, des curseurs, etc.). Dans certaines circonstances, des exemples de boîtiers comprennent des dispositifs de sortie contenus dans, portés par, intégrés dans et/ou fixés à ceux-ci. Des dispositifs de sortie peuvent comprendre des afficheurs, des écrans tactiles, des voyants, des LED, des haut-parleurs, des ports I/O (par exemple, USB), etc. Dans certaines circonstances, les dispositifs périphériques sont des dispositifs se présentant sur le réseau dans un but particulier (par exemple, un feu de signalisation), mais ils peuvent avoir des capacités de traitement et/ou d'autres capacités qui peuvent être utilisées à d'autres fins. De tels dispositifs de périphérie peuvent être indépendants d'autres dispositifs en réseau et peuvent être dotés d'un boîtier ayant un facteur de forme adapté à leur objectif principal, tout en étant disponibles pour d'autres tâches informatiques qui ne perturbent pas leur objectif principal. Des dispositifs de périphérie comprennent des dispositifs de l'Internet des Objets. Le dispositif informatique de l'appareil peut comprendre des composants matériels et logiciels pour gérer des problèmes locaux tels que la température de l'appareil, des vibrations, une utilisation des ressources, des mises à jour, des problèmes d'alimentation, la sécurité physique et du réseau, etc. Le nuage de périphérie 1010 peut également comprendre un ou plusieurs serveurs et/ou un ou plusieurs serveurs multi-propriétaires. Un tel serveur peut comprendre un système d'exploitation et mettre en œuvre un environnement informatique virtuel. Un environnement informatique virtuel peut comprendre un hyperviseur gérant (par exemple, créant, déployant, détruisant, etc.) une ou plusieurs machines virtuelles, un ou plusieurs conteneurs, etc. De tels environnements informatiques virtuels fournissent un environnement d'exécution dans lequel une ou plusieurs applications et/ou d'autres logiciels, codes ou scripts peuvent s'exécuter tout en étant isolés d'un ou plusieurs autres applications, logiciels, codes ou scripts. La illustre divers points d'extrémité clients 1210 (sous la forme de dispositifs mobiles, d'ordinateurs, de véhicules autonomes, d'équipements informatiques d'entreprise, d'équipements de traitement industriel) qui échangent des demandes et des réponses propres au type d'agrégation de réseau de points d'extrémité. Des points d'extrémité clients 1210 peuvent ainsi obtenir un accès au réseau par l'intermédiaire d'un réseau câblé à large bande, en échangeant des demandes et des réponses 1222 par le biais d'un système de réseau sur site 1232. Certains points d'extrémité clients 1210, tels que des dispositifs informatiques mobiles, peuvent obtenir un accès au réseau par l'intermédiaire d'un réseau à large bande sans fil, en échangeant des demandes et des réponses 1224 par le biais d'un point d'accès (par exemple, un pylône de réseau cellulaire) 1234. Certains points d'extrémité clients 1210, tels que des véhicules autonomes, peuvent obtenir un accès au réseau pour des demandes et des réponses 1226 par l'intermédiaire d'un réseau sans fil pour véhicules, par le biais d'un système de réseau situé dans la rue 1236. Cependant, quel que soit le type d'accès au réseau, le TSP peut déployer des points d'agrégation 1242, 1244 à l'intérieur du nuage de périphérie 1010 pour agréger le trafic et les demandes. Ainsi, dans le nuage de périphérie 1010, le TSP peut déployer diverses ressources de calcul et de stockage, par exemple au niveau de nœuds d'agrégation de périphérie 1240, pour fournir le contenu demandé. Les nœuds d'agrégation de périphérie 1240 et d'autres systèmes du nuage de périphérie 1010 sont connectés à un nuage ou à un centre de données 1260, qui utilise un réseau de liaison de retour 1250 pour satisfaire à des demandes à forte latence provenant d'un nuage/centre de données destiné à des sites Web, des applications, des serveurs de base de données, etc. Des instances supplémentaires ou consolidées des nœuds d'agrégation de périphérie 1240 et des points d'agrégation 1242, 1244, notamment celles déployées dans le cadre d'un serveur unique, peuvent également être présentes dans le nuage de périphérie 1010 ou dans d'autres zones de l'infrastructure TSP. La illustre un exemple de système informatique de périphérie 1300 destiné à fournir des services et des applications de périphérie à des entités multipartites, sous une forme répartie entre un ou plusieurs nœuds de calcul clients 1302, un ou plusieurs nœuds passerelles de périphérie 1312, un ou plusieurs nœuds d'agrégation de périphérie 1322, un ou plusieurs centres de données de cœur 1332, et un nuage de réseau global 1342, sous une forme répartie entre des couches du réseau. La mise en œuvre du système informatique de périphérie 1300 peut être assurée au niveau, ou pour le compte d'un fournisseur de services de télécommunications ("telco" ou "TSP"), d'un fournisseur de services de l'Internet des Objets, d'un fournisseur de services en nuage (CSP), d'une entité d'entreprise ou de tout autre nombre d'entités. Diverses mises en œuvre et configurations du système 1300 peuvent être assurées dynamiquement, par exemple lorsqu'elles sont orchestrées pour atteindre des objectifs de service. À titre d'exemple, les nœuds de calcul clients 1302 sont situés au niveau d'une couche de point d'extrémité, tandis que les nœuds passerelles de périphérie 1312 sont situés au niveau d'une couche de dispositifs de périphérie (niveau local) du système informatique de périphérie 1300. En outre, les nœuds d'agrégation de périphérie 1322 (et/ou les dispositifs en brouillard 1324, s'ils sont agencés ou exploités à l'aide ou au sein d'une configuration de réseau en brouillard 1326) sont situés au niveau d'une couche d'accès au réseau (niveau intermédiaire). L'informatique en brouillard (ou "fogging") se rapporte de manière générale à des extensions de l'informatique en nuage à la périphérie du réseau d'une entreprise ou à la capacité de gérer des transactions sur l'ensemble du paysage nuage/périphérie, typiquement dans un réseau distribué ou multi-nœuds coordonné. Certaines formes d'informatique en brouillard assurent le déploiement de services de calcul, de stockage et de mise en réseau entre des dispositifs d'extrémité et des centres de données d'informatique en nuage, pour le compte des sites d'informatique en nuage. Certaines formes d'informatique en brouillard offrent également la possibilité de gérer les services au niveau de la charge de travail/du flux de travail, au niveau de la transaction globale, en repoussant certaines charges de travail vers la périphérie ou vers le nuage en fonction des possibilités qu'il offre de respecter l'accord de niveau de service global. Dans de nombreux scénarios, l'informatique en brouillard fournit une architecture décentralisée et sert d'extension de l'informatique en nuage en collaborant avec un ou plusieurs dispositifs de nœuds de périphérie, assurant ainsi le niveau correspondant de contrôle, de configuration et de gestion localisés, et bien plus encore pour les dispositifs d'extrémité. En outre, l'informatique en brouillard permet à des ressources de périphérie d'identifier des ressources semblables et de collaborer afin de créer un nuage local de périphérie qui peut être utilisé seul ou conjointement avec l'informatique en nuage afin de mener à bien des services liés au calcul, au stockage ou à la connectivité. L'informatique en brouillard peut également permettre à des services à base d'informatique en nuage d'étendre leur portée jusqu'à la périphérie d'un réseau de dispositifs afin d'offrir une accessibilité locale et plus rapide à des dispositifs de périphérie. Par conséquent, certaines formes d'informatique en brouillard fournissent des opérations qui sont compatibles avec l'informatique de périphérie telle qu'évoquée ici ; les aspects relatifs à l'informatique de périphérie évoqués ici peuvent également s'appliquer à des réseaux en brouillard, au fogging et à des configurations de brouillard. En outre, certains aspects des systèmes informatique de périphérie évoqués ici peuvent être configurés sous forme de brouillard, ou certains aspects d'un brouillard peuvent être intégrés à une architecture informatique de périphérie. Le centre de données de cœur 1332 est situé au niveau d'une couche de cœur de réseau (niveau régional ou géographiquement central), tandis que le nuage de réseau global 1342 est situé au niveau d'une couche de centre de données en nuage 240 (couche nationale ou mondiale). Le terme de "cœur" est utilisé pour désigner un emplacement de réseau centralisé - situé plus profondément dans le réseau - qui est accessible à plusieurs nœuds ou composants de périphérie ; toutefois, un "cœur" ne désigne pas nécessairement le "centre" ou l'emplacement le plus profond du réseau. En conséquence, le centre de données de cœur 1332 peut être situé à l'intérieur, au niveau ou à proximité du nuage de périphérie 1300. Bien qu'un nombre illustratif de nœuds de calcul clients 1302, de nœuds passerelles de périphérie 1312, de nœuds d'agrégation de périphérie 1322, de centres de données principaux de périphérie 1332, de nuages de réseau globaux 1342 soient présentés sur la , il est à noter que le système informatique de périphérie 1300 peut comprendre des dispositifs ou des systèmes supplémentaires à chaque couche. Des dispositifs situés au niveau d'une couche quelconque peuvent être configurés en tant que nœuds homologues les uns des autres et par conséquent, agir de manière collaborative pour atteindre des objectifs de service. Conformément aux exemples fournis ici, un nœud de calcul client 1302 peut être réalisé sous la forme de tout type de composant, dispositif, appareil ou autre, de point d'extrémité capable de communiquer en tant que producteur ou consommateur de données. De plus, la désignation "nœud" ou "dispositif" telle qu'utilisée dans le système informatique de périphérie 1300 ne signifie pas nécessairement que ce nœud ou dispositif fonctionne en tant que client ou qu'agent/serviteur/suiveur ; l'un quelconque des nœuds ou dispositifs du système informatique de périphérie 1300 fait plutôt référence à des entités, nœuds ou sous-systèmes individuels qui comprennent des configurations matérielles ou logicielles discrètes ou connectées pour faciliter ou utiliser le nuage de périphérie 1300. De ce fait, le nuage de périphérie 1300 est formé de composants de réseau et d'éléments fonctionnels exploités par et dans les nœuds passerelles de périphérie 1312 et les nœuds d'agrégation de périphérie 1322. Le nuage de périphérie 1300 peut être réalisé sous la forme de n'importe quel type de réseau qui fournit des ressources de calcul et/ou de stockage de périphérie qui sont situées à proximité de dispositifs d'extrémité à fonctionnalité de réseau d'accès radio (RAN) (par exemple, des dispositifs informatiques mobiles, des dispositifs IoT, des dispositifs intelligents, etc.), qui sont représentés sur la sous la forme des nœuds de calcul clients 1302. En d'autres termes, le nuage de périphérie 1300 peut être considéré comme étant une "périphérie" qui relie les dispositifs d'extrémité et des points d'accès au réseau traditionnels faisant office de point d'entrée dans des cœurs de réseaux de fournisseurs de services, notamment des réseaux d'opérateurs mobiles (par exemple, des réseaux du Système Global de Communications Mobiles (GSM), des réseaux d'Évolution à Long Terme (LTE), des réseaux 5G/6G, etc. ), tout en fournissant également des capacités de stockage et/ou de calcul. D'autres types et formes d'accès au réseau (par exemple, Wi-Fi, réseaux sans fil de grande portée, réseaux câblés, notamment réseaux optiques) peuvent également être utilisés au lieu de ces réseaux d'opérateurs 3GPP ou combinés à ceux-ci. Dans certains exemples, le nuage de périphérie 1300 peut faire partie d'une configuration de réseau en brouillard 1326 ou sinon offrir un point d'entrée dans ou à travers celle-ci (par exemple, un réseau de dispositifs en brouillard 1324, non représenté en détail), qui peut être réalisé sous la forme d'une architecture horizontale et distribuée au niveau du système qui distribue des ressources et des services pour réaliser une fonction particulière. Un réseau coordonné et distribué de dispositifs en brouillard 1324 peut par exemple réaliser des aspects de calcul, de stockage, de commande ou de mise en réseau dans le contexte d'un agencement de système IoT. D'autres fonctions mises en réseau, agrégées et distribuées peuvent exister dans le nuage de périphérie 1300 entre le centre de données de cœur 1332 et les points d'extrémité clients (par exemple, les nœuds de calcul clients 1302). Certaines d'entre elles sont évoquées aux paragraphes suivants dans le contexte de fonctions de réseau ou de la virtualisation de services, notamment l'utilisation de périphéries virtuelles et de services virtuels qui sont orchestrés pour de multiples parties prenantes. Comme évoqué ci-après plus en détail, les nœuds passerelles de périphérie 1312 et les nœuds d'agrégation de périphérie 1322 coopèrent pour fournir divers services de périphérie et de sécurité aux nœuds de calcul clients 1302. De plus, étant donné qu'un nœud de calcul client 1302 peut être stationnaire ou mobile, un nœud passerelle de périphérie 1312 respectif peut coopérer avec d'autres dispositifs passerelles de périphérie pour propager des services de périphérie fournis à l'instant présent, des données de services pertinentes et une sécurité lorsque le nœud de calcul client 1302 correspondant se déplace dans une région. À cet effet, les nœuds passerelles de périphérie 1312 et/ou les nœuds d'agrégation de périphérie 1322 peuvent prendre en charge des configurations multi-locataires et multi-parties prenantes, dans lesquelles des services de (ou hébergés pour) plusieurs fournisseurs de services, propriétaires et consommateurs multiples peuvent être pris en charge et coordonnés sur un seul ou plusieurs dispositifs de calcul. Une variété d'approches de sécurité peuvent être utilisées au sein de l'architecture du nuage de périphérie 1300. Dans un environnement multi-parties prenantes, il peut y avoir plusieurs modules de sécurité chargeables (LSM) utilisés pour fournir des politiques qui mettent en application les intérêts des parties prenantes. Des environnements de points de mise en application pourraient prendre en charge de multiples LSM qui appliqueraient la combinaison de politiques LSM chargées (par exemple, là où la politique efficace la plus contraignante est appliquée, de sorte que si l'une des parties prenantes A, B ou C restreint l'accès, alors l'accès est restreint). Dans le nuage de périphérie 1300, chaque entité de périphérie peut fournir des LSM qui mettent en application les intérêts de l'entité de périphérie. L'entité de nuage peut fournir des LSM qui mettent en application les intérêts de l'entité de nuage. De même, les diverses entités du réseau en brouillard et d'IoT peuvent fournir des LSM qui mettent en application les intérêts de l'entité en brouillard. Dans ces exemples, des services peuvent être considérés du point de vue d'une transaction, effectuée par rapport à un ensemble de contrats ou d'ingrédients, qu'ils soient considérés au niveau des ingrédients ou à un niveau perceptible par l'être humain. Ainsi, un utilisateur qui dispose d'un accord de service avec un fournisseur de services s'attend à ce que le service soit fourni selon les termes dudit SLA. Bien que cela ne soit pas évoqué en détail, l'utilisation des techniques informatiques de périphérie évoquées ici peut jouer un rôle lors de la négociation de l'accord et de la mesure de l'exécution de l'accord (pour identifier quels éléments sont requis par le système pour mener à bien un service, comment le système réagit à des conditions et à des changements de service, etc.) Un "service" est un terme large souvent appliqué à divers contextes, mais il fait généralement référence à une relation entre deux entités, dont l'une offre et exécute une tâche au profit de l'autre. Cependant, les services fournis par une entité à une autre doivent être réalisés selon certaines lignes directrices, qui garantissent une certaine confiance entre les entités et gèrent la transaction selon les termes et conditions du contrat établi au début, pendant et à la fin du service. Le déploiement d'un système informatique de périphérie multi-parties prenantes peut être organisé et orchestré de manière à permettre le déploiement de multiples services et instances de périphérie virtuelles, parmi de multiples nœuds et sous-systèmes de périphérie, pour une utilisation par de multiples locataires et fournisseurs de services. Dans un exemple de système applicable à un fournisseur de services en nuage (CSP), le déploiement d'un système informatique de périphérie peut être assuré par l'intermédiaire d'une approche "par contournement", afin d'introduire des nœuds informatiques de périphérie en tant qu'outil complémentaire à l'informatique en nuage. Dans un exemple de système différent applicable à un fournisseur de services de télécommunications (TSP), le déploiement d'un système informatique de périphérie peut être assuré par une approche d'"agrégation de réseau", permettant d'introduire des nœuds informatiques de périphérie à des endroits où sont agrégés les accès au réseau (provenant de différents types de réseaux d'accès aux données). Les figures 5 et 6 mettent en contraste ces approches de contournement et d'agrégation de réseaux aux fins de la mise en réseau et des services fournis dans des systèmes informatiques de périphérie respectifs. Cependant, ces approches de contournement et d'agrégation de réseaux peuvent être mises en œuvre ensemble conformément à une approche ou à une configuration hybride ou fusionnée, comme le suggèrent des exemples ultérieurs. La illustre le déploiement et l'orchestration de configurations de périphérie virtualisées et basées sur des conteneurs dans un système informatique de périphérie exploité entre plusieurs nœuds de périphérie et de multiples locataires (par exemple, des utilisateurs, des fournisseurs) qui utilisent ces nœuds de périphérie. Plus précisément, la illustre la coordination d'un premier nœud de périphérie 1422 et d'un deuxième nœud de périphérie 1424 dans un système informatique de périphérie 1400, pour satisfaire à des demandes et à des réponses de divers points d'extrémité clients 1410 (par exemple, des villes intelligentes/des systèmes de bâtiments, des dispositifs mobiles, des dispositifs informatiques, des systèmes commerciaux/logistiques, des systèmes industriels, etc. ), qui accèdent à diverses instances de périphéries virtuelles. Les instances de périphéries virtuelles 1432, 1434 fournissent ici des capacités de calcul et de traitement de périphérie dans un nuage de périphérie, avec un accès à un nuage/centre de données 1440 correspondant à des demandes à plus forte latence pour des sites Web, des applications, des serveurs de base de données, etc. Toutefois, le nuage de périphérie permet de coordonner le traitement entre plusieurs nœuds de périphérie pour de multiples locataires ou entités. Dans l'exemple de la , ces instances de périphéries virtuelles comprennent : une première périphérie virtuelle 1432, offerte à une première entité (Locataire 1), qui offre une première combinaison de stockage, de calcul et de services de périphérie ; et une deuxième périphérie virtuelle 1434, offrant une deuxième combinaison de stockage, de calcul et de services de périphérie. Les instances de périphéries virtuelles 1432, 1434 sont réparties entre les nœuds de périphérie 1422, 1424, et peuvent comprendre des scénarios dans lesquels une demande et une réponse sont satisfaites à partir d'un même nœud de périphérie ou de nœuds de périphérie différents. La configuration des nœuds de périphérie 1422, 1424 permettant un fonctionnement de façon distribuée mais coordonnée se fait sur la base de fonctions de déploiement de périphérie 1450. La fonctionnalité des nœuds de périphérie 1422, 1424 permettant d'assurer un fonctionnement coordonné pour les applications et les services, parmi de multiples locataires, se produit sur la base de fonctions d'orchestration 1460. Il est à noter que certains des dispositifs indiqués en 1410 sont des dispositifs multi-locataires dans lesquels le Locataire 1 peut fonctionner dans une "tranche" de Locataire 1 tandis que le Locataire 2 peut fonctionner dans une tranche de Locataire 2 (et dans d'autres exemples, il peut y avoir des locataires supplémentaires ou des sous-locataires ; et chaque locataire peut même avoir un droit spécifique et être lié de manière transactionnelle à un ensemble spécifique de caractéristiques, jusqu'à des caractéristiques matérielles spécifiques). Un dispositif multi-locataires de confiance peut en outre contenir une clé cryptographique propre au locataire, de telle sorte que la combinaison de la clé et de la tranche puisse être considérée comme une "racine de confiance" (RoT) ou une RoT propre au locataire. Une RoT peut en outre être calculée et composée de manière dynamique à l'aide d'une architecture DICE (Device Identity Composition Engine), de façon qu'un seul bloc de construction matériel DICE puisse être utilisé pour construire des contextes de base informatiques de confiance en couches à des fins de superposition de capacités des dispositifs (comme un réseau de portes programmables par l'utilisateur (FPGA)). La RoT peut en outre être utilisée pour un contexte informatique de confiance afin de permettre un "éclatement" utile pour la prise en charge du caractère multi-locataires. Dans un environnement multi-locataires, les nœuds de périphérie 1422, 1424 respectifs peuvent fonctionner comme des points de mise en application de fonctions de sécurité destinées à des ressources locales allouées à plusieurs locataires par nœud. De plus, l'exécutable de locataire et l'exécution de l'application (par exemple, dans les instances 1432, 1434) peuvent servir de point de mise en application d'une fonction de sécurité qui crée une abstraction de périphérie virtuelle pour des ressources couvrant potentiellement plusieurs plateformes d'hébergement physiques. Enfin, les fonctions d'orchestration 1460 d'une entité d'orchestration peuvent servir de point de mise en application d'une fonction de sécurité pour rassembler des ressources le long de frontières entre locataires. Des nœuds informatiques de périphérie peuvent partitionner des ressources (mémoire, unité centrale de traitement (CPU), unité de traitement graphique (GPU), contrôleur d'interruption, contrôleur d'entrée/sortie (I/O), contrôleur de mémoire, contrôleur de bus, etc.) dans lesquelles des partitionnements respectifs peuvent contenir une capacité RoT et dans lesquelles un éclatement et une stratification selon un modèle DICE peuvent en outre être appliqués à des Nœuds de Périphérie. Des nœuds d'informatique en nuage utilisent souvent des conteneurs, des moteurs FaaS, des microserveurs (Servlets), des serveurs ou d'autres abstractions de calcul qui peuvent être partitionnés selon une structure en couches et en éventail DICE pour prendre en charge un contexte de RoT pour chaque cas. En conséquence, les dispositifs respectifs couvrant des RoT (1410, 1422 et 1440) peuvent coordonner l'établissement d'une base informatique de confiance distribuée (DTCB) de sorte qu'un canal sécurisé de confiance virtuel propre au locataire et reliant tous les éléments de bout en bout peut être établi. On notera en outre qu'un conteneur peut avoir des données ou des clés spécifiques à la charge de travail protégeant son contenu vis-à-vis d'un nœud de périphérie précédent. En tant que partie de la migration d'un conteneur, un contrôleur d'armoire, au niveau d'un nœud périphérique source, peut obtenir une clé de migration à partir d'un contrôleur d'armoire du nœud de périphérie cible, la clé de migration étant utilisée pour encapsuler des clés spécifiques au conteneur. Lorsque le conteneur/l'armoire est amené à migrer vers le nœud de périphérie cible, la clé de désencapsulation est exposée au contrôleur d'armoire qui déchiffre alors les clés encapsulées. Les clés peuvent alors être utilisées pour effectuer des opérations sur les données spécifiques au conteneur. Les fonctions de migration peuvent être contrôlées par des nœuds de périphérie et des gestionnaires d'armoires correctement attestés (comme décrit ci-dessus). Dans d'autres exemples, un système informatique de périphérie est étendu pour permettre l'orchestration de multiples applications par utilisation de conteneurs (unité logicielle contenue et déployable qui fournit le code et les dépendances nécessaires) dans un environnement multi-propriétaires et multi-locataires. Un orchestrateur multi-locataires peut être utilisé pour effectuer la gestion des clés, la gestion des ancres de confiance et d'autres fonctions de sécurité liées au déploiement et au cycle de vie du concept de "tranche" de confiance de la . Un système informatique de périphérie peut par exemple être configuré pour satisfaire à des demandes et à des réponses de divers points d'extrémité clients provenant de multiples instances de périphérie virtuelles (et d'un nuage ou d'un centre de données distant). L'utilisation de ces instances de périphéries virtuelles peut prendre en charge simultanément plusieurs entités et plusieurs applications (par exemple, de réalité augmentée (AR)/réalité virtuelle (VR), des applications d'entreprise, de fourniture de contenu, de jeux, de délestage des calculs). En outre, il peut y avoir plusieurs types d'applications dans des instances de périphéries virtuelles (par exemple, des applications normales ; des applications sensibles à la latence ; des applications critiques en termes de latence ; des applications du plan utilisateur ; des applications de réseau ; etc.) Les instances de périphéries virtuelles peuvent également être réparties entre des systèmes de multiples propriétaires à différents emplacements géographiques (ou sur des systèmes et ressources informatiques respectifs qui sont en copropriété ou cogérés par de multiples propriétaires). À titre d'exemple, chaque nœud de périphérie 1422, 1424 peut mettre en œuvre l'utilisation de conteneurs, par exemple en association avec l'utilisation d'une "armoire" de conteneurs 1426, 1428 fournissant un groupe d'un ou plusieurs conteneurs. Dans un contexte qui utilise une ou plusieurs armoires de conteneurs, un contrôleur ou orchestrateur d'armoires est responsable du contrôle local et de l'orchestration des conteneurs dans l'armoire. Diverses ressources de nœuds de périphérie (par exemple, destinés au stockage, aux calculs, aux services, représentés par des hexagones) fournies pour les tranches de périphérie 1432, 1434 respectives sont partitionnées en fonction des besoins de chaque conteneur. Du fait de l'utilisation d'armoires de conteneurs, un contrôleur d'armoire supervise le partitionnement et l'allocation des conteneurs et des ressources. Le contrôleur d'armoire reçoit des instructions d'un orchestrateur (par exemple, l'orchestrateur 1460) qui lui indique comment partitionner au mieux les ressources physiques et pour quelle durée, par exemple en recevant des indicateurs de performances clés (KPI) cibles sur la base de contrats SLA. Le contrôleur d'armoire détermine quel conteneur nécessite quelles ressources et pendant combien de temps afin de mener à bien la charge de travail et de respecter le SLA. Le contrôleur d'armoire gère également les opérations du cycle de vie des conteneurs, telles que : la création du conteneur, son provisionnement en ressources et en applications, la coordination des résultats intermédiaires entre plusieurs conteneurs travaillant ensemble sur une application distribuée, le démantèlement des conteneurs lorsque la charge de travail est achevée, et autres. En outre, un contrôleur d'armoire peut jouer un rôle de sécurité qui empêche l'affectation de ressources jusqu'à ce que le locataire approprié s'authentifie ou empêche le provisionnement de données ou d'une charge de travail d'un conteneur jusqu'à ce qu'un résultat d'attestation soit satisfait. Par ailleurs, du fait de l'utilisation d'armoires de conteneurs, des frontières entre locataires peuvent toujours être présentes, mais dans le contexte de chaque armoire de conteneurs. Si chaque armoire spécifique de locataire dispose d'un contrôleur d'armoire spécifique de locataire, il y aura un contrôleur d'armoire partagé qui regroupera les demandes d'allocation de ressources pour éviter les situations typiques de manque de ressources. D'autres commandes peuvent être prévues pour garantir l'attestation et la fiabilité de l'armoire et du contrôleur d'armoire. À titre d'exemple, l'orchestrateur 1460 peut transmettre une politique de vérification d'attestation à des contrôleurs d'armoires locaux qui effectuent la vérification d'attestation. Si une attestation satisfait à une politique pour un premier contrôleur d'armoire de locataire mais pas pour un deuxième contrôleur d'armoire de locataire, alors la deuxième armoire peut être amenée à migrer vers un nœud de périphérie différent qui la satisfait. En variante, la première armoire peut être autorisée effectuer l'exécution et un contrôleur d'armoire partagé différent est installé et invoqué avant l'exécution de la deuxième armoire. La illustre un exemple de plateforme de distribution de logiciels 1505 destinée à distribuer des logiciels, comme l'exemple d'instructions lisibles par ordinateur 1550, à un ou plusieurs dispositifs, comme l'exemple de plateforme(s) de processeurs 1500 et/ou l'exemple de dispositifs de périphérie connectés. La plateforme de distribution de logiciels 1505 peut être mise en œuvre par n'importe quel serveur informatique, installation de données, service en nuage, etc., capable de stocker et de transmettre des logiciels à d'autres dispositifs informatiques (par exemple, des tiers, des dispositifs de périphérie connectés). Des exemples de dispositifs de périphérie connectés peuvent être des usagers, des clients, des dispositifs de gestion (par exemple, des serveurs), des tiers (par exemple, des usagers d'une entité possédant et/ou exploitant la plateforme de distribution de logiciels 1505). Des exemples de dispositifs de périphérie connectés peuvent fonctionner dans des environnements commerciaux et/ou domotiques. Dans certains exemples, un tiers est un développeur, un vendeur et/ou un concédant de licence d'un logiciel tel que les exemples d'instructions lisibles par ordinateur 1550. Les tiers peuvent être des consommateurs, des utilisateurs, des détaillants, des équipementiers, etc. qui achètent et/ou concèdent une licence pour l'utilisation et/ou la revente et/ou la sous-licence du logiciel. Dans certains exemples, le logiciel distribué provoque l'affichage d'une ou plusieurs interfaces utilisateur (UI) et/ou interfaces utilisateur graphiques (GUI) permettant d'identifier le ou les dispositif(s) (par exemple, des dispositifs de périphérie connectés) géographiquement et/ou logiquement séparés les uns des autres (par exemple, des dispositifs IoT physiquement séparés chargés de la responsabilité du contrôle de la distribution d'eau (par exemple, des pompes), du contrôle de la distribution d'électricité (par exemple, des relais), etc.). Dans l'exemple illustré sur la , la plateforme de distribution de logiciels 1505 comprend un ou plusieurs serveurs et un ou plusieurs dispositifs de stockage. Les dispositifs de stockage stockent les instructions lisibles par ordinateur 1550, qui peuvent correspondre aux exemples d'instructions lisibles par ordinateur décrites plus haut. Le ou les serveur(s) de la plateforme de distribution de logiciels 1505 est ou sont en communication avec un réseau 1510, qui peut correspondre à l'un quelconque ou plusieurs des réseaux Internet et/ou à l'un quelconque des exemples de réseaux décrits ci-dessus. Dans certains exemples, le ou les serveur(s) répond/répondent à des demandes de transmission du logiciel à une partie requérante dans le cadre d'une transaction commerciale. Le paiement de la livraison, de la vente et/ou de la licence du logiciel peut être géré par un ou plusieurs serveurs de la plateforme de distribution de logiciels et/ou par une entité de paiement tierce. Les serveurs permettent à des acheteurs et/ou à des concédants de licence de télécharger les instructions lisibles par ordinateur 1550 à partir de la plateforme de distribution de logiciels 1505. À titre d'exemple, le logiciel, qui peut correspondre à l'exemple d'instructions lisibles par ordinateur, peut être téléchargé sur l'exemple de plateforme(s) de processeurs 1500 (par exemple, les exemples de dispositifs de périphérie connectés), qui doit/doivent exécuter les instructions lisibles par ordinateur 1550 pour mettre en œuvre l'un quelconque des modes de réalisation décrits ici. Dans certains exemples, un ou plusieurs serveurs de la plateforme de distribution de logiciels 1505 est ou sont connecté(s) par voie de communication à un ou plusieurs domaines de sécurité et/ou dispositifs de sécurité par le biais desquels doivent passer des demandes et des transmissions de l'exemple d'instructions lisibles par ordinateur 1550. Dans certains exemples, un ou plusieurs serveurs de la plateforme de distribution de logiciels 1505 offrent, transmettent et/ou forcent périodiquement des mises à jour du logiciel (par exemple, l'exemple d'instructions lisibles par ordinateur 1550) pour s'assurer que des améliorations, des correctifs, des mises à jour, etc. sont distribués et appliqués au logiciel sur les dispositifs d'utilisateurs finaux. Dans l'exemple illustré de la , les instructions lisibles par ordinateur 1550 sont stockées sur des dispositifs de stockage de la plateforme de distribution de logiciels 1505 dans un format particulier. Un format d'instructions lisible par ordinateur comprend, sans s'y limiter, un langage de code particulier (par exemple, Java, JavaScript, Python, C, C#, SQL, HTML, etc.), et/ou un état de code particulier (par exemple, un code non compilé (par exemple, ASCII), un code interprété, un code lié, un code exécutable (par exemple, un binaire), etc.). Dans certains exemples, les instructions lisibles par ordinateur 1550 stockées sur la plateforme de distribution de logiciels 1505 sont dans un premier format lorsqu'elles sont transmises à l'exemple de plateforme(s) de processeurs 1500. Dans certains exemples, le premier format est un binaire exécutable dans lequel des types particuliers de la ou des plateforme(s) de processeurs 1500 peuvent s'exécuter. Cependant, dans certains exemples, le premier format est un code non compilé qui nécessite une ou plusieurs tâches de préparation pour transformer le premier format en un deuxième format afin de permettre l'exécution sur l'exemple de plateforme(s) de processeurs 1500. À titre d'exemple, la ou les plateforme(s) de processeur 1500 de réception peut/peuvent avoir besoin de compiler les instructions lisibles par ordinateur 1550 dans le premier format afin de générer un code exécutable dans un deuxième format qui pourra être exécuté sur la ou les plateforme(s) de processeurs 1500. Dans d'autres exemples encore, le premier format est un code interprété qui, lorsqu'il atteint la ou les plateforme(s) de traitement 1500, est interprété par un interpréteur pour faciliter l'exécution des instructions. Unités de traitement d’infrastructure La représente divers modes de réalisation d'une CPU et de systèmes de cartes d'interface réseau (NIC) ayant accès à la mémoire. Des systèmes peuvent être composés différemment en se basant au moins sur la façon dont les fonctions sont mappées et délestées. Un système A peut par exemple comprendre un système dans lequel une CPU fournit des services logiciels tels que l'exécution d'un Gestionnaire de Machine Virtuelle (VMM) (par exemple, un hyperviseur), l'exécution d'opérations de traitement de pile de réseau, l'exécution d'opérations de sécurité (cryptographiques), l'exécution d'un logiciel d'accès au stockage, et la gestion de la surveillance et du maillage de services (par exemple, un contrôle de la façon dont différentes parties d'une application partagent entre elles des données). Un Système B peut par exemple comprendre un système dans lequel une CPU peut exécuter une VMM, effectuer des opérations de sécurité (cryptographiques), gérer la surveillance et le maillage de services (par exemple, contrôler la façon dont différentes parties d'une application partagent entre elles des données). Le Système B peut utiliser une SmartNIC dotée de processeurs pour exécuter des opérations de traitement de pile de mise en réseau (par exemple, un commutateur virtuel ou vSwitch) et un logiciel de stockage (par exemple, des opérations d'accès au stockage par blocs). À titre d'exemple, un Système C peut comprendre un système dans lequel une IPU peut exécuter une gestion de plateforme, des opérations de traitement de pile de mise en réseau, des opérations de sécurité (crypto), un logiciel de stockage, une gestion d'identité et de clé, une télémétrie, une journalisation, une surveillance et un maillage de services (par exemple, un contrôle de la façon dont différents microservices communiquent entre eux). L'IPU peut accéder à une xPU pour délester l'exécution de diverses tâches. La représente divers modes de réalisation d'un système. La configuration 1702 montre un exemple d'utilisation d'un serveur exécutant un traitement de paquets, un conteneur, un maillage de services et un hyperviseur. Dans l'exemple de configuration 1704, une IPU peut exécuter des tâches qui pourraient autrement être exécutées par un système d'exploitation (OS) invité (par exemple, un logiciel installé sur une machine virtuelle (VM) qui est différente du système d'exploitation hôte) en plus des services de l'hyperviseur hôte. À titre d'exemple, les services d'application invités, comme le maillage de services (routage, Traduction d'Adresses Réseau (NAT), équilibrage de charge, etc.), le chiffrement et les services de transport fiables, peuvent être délestés vers l'IPU. À partir de l'hyperviseur hôte, des services tels que la gestion de ressources, la virtualisation de dispositifs, la journalisation des événements et de l'utilisation, la gestion des connexions et le commutateur virtuel (vSwitch) peuvent être délestés vers l'IPU. L'IPU peut exécuter des pilotes permettant un interfaçage avec un OS invité sur un système hôte ainsi qu'avec une XPU ou des dispositifs de stockage. La illustre un exemple d'utilisation d'une IPU. Dans cet exemple, une IPU expose des ressources et des capacités d'XPU, de stockage, de mémoire et de CPU en tant que services auxquels peuvent accéder d'autres microservices pour la composition de fonctions. Cela permet d'améliorer les performances et de réduire le mouvement et la latence des données. Une IPU peut mettre en œuvres des capacités telles que celles de routeur, équilibreur de charge, pare-feu, transport TCP/fiable, maillage de services (par exemple, un proxy ou une passerelle API), sécurité, transformation de données, authentification, qualité de service (QoS), sécurité, mesure de télémétrie, journalisation d'événements, déclenchement et gestion de flux de données, placement de données ou planification de tâches de ressources sur une XPU, stockage, mémoire, ou CPU. Selon divers modes de réalisation, une IPU peut comprendre un ou plusieurs des éléments suivants : un Contrôleur d'Interface Réseau ("SmartNIC") doté d'un ou plusieurs processeurs à fonction programmable ou fixe pour délester des opérations qui auraient pu être effectuées par une CPU telles que : Délestage de Commutateur Virtuel, délestage du stockage (par exemple, compression, crypto, virtualisation) ; délestage d'opérations à partir d'une application ; services de virtualisation par lesquels, au lieu que la CPU soit le centre de la virtualisation de chaque dispositif, l'IPU devient une "bosse sur le conducteur" du point de vue de la virtualisation de toutes les capacités, y compris les CPU. Divers modes de réalisation d'une IPU sont intégrés en association avec les CPU et xPU constitutives ou physiquement séparés de celles-ci. Divers modes de réalisation d'une IPU créent un pont entre l'adressage mémoire local et la mémoire distante à travers la matrice d'interconnexion de centres de données. Selon divers modes de réalisation, une IPU peut fournir des fonctionnalités de sécurité, notamment : (1) Racine de Confiance (RoT), services d'attestation, enclaves sécurisées ; stockage de clés de chiffrement et de tâches de gestion de clés achevées ; points d'extrémité de chiffrement de protocole pour des interfaces de liaison et des interfaces réseau qui connectent l'IPU à d'autres nœuds dans le système distribué ; interface de plan de commande distincte qui peut être mesurée (par des mécanismes de certificat) ; interfaces d'automates finis sur dispositifs, qui peuvent être configurées individuellement et isolées d'autres interfaces de dispositifs ; attestation, autorisation, contrôle d'accès, journalisation, filtrage de journaux, journalisation immuable (par exemple, par chaînes de blocs) ; fonctions de concentrateur de sécurité pour la confidentialité inter-XPU et l'isolation d'identité et d'informations, courtage de visibilité des données entre des clients multiples pour un traitement coopératif ; interfaces sécurisées et chiffrées pour les interfaces externes du SoC d'IPU, notamment la mémoire (par exemple, volatile et persistante), réseau et matrices d'interconnexion IO (PCIe, CXL) ; mise en application passive ou active de politiques et de services de sécurité tels que listes de contrôle d'accès, limitation de débit, détection d'intrusion, attaques par déni de service distribuées, etc. Divers modes de réalisation d'une IPU peuvent également fournir des capacités et des performances de CPU de sorte que des tâches (par exemple, des tâches parallélisées sur des données) puissent être délestées vers l'IPU ainsi que : gestion de plateformes et de dispositifs ; télémétrie, traçage, journalisation et surveillance distribués (inter-nœuds et intra-nœuds) ; mise en application de Qualité de Service ; Maillage de Services ; traitement des données, notamment sérialisation, désérialisation, transformation, notamment conversion de taille et de format, validation de plage, mise en application de la politique d'accès ; sécurité distribuée (inter-nœuds et intra-nœuds) ; et/ou moteurs d'accélération intégrés fournissant des moteurs d'accélération flexibles et programmables permettant de délester et d'améliorer l'exécution pour l'AI et l'apprentissage automatique qui sont intensifs en termes d'opérations en virgule flottante par seconde (FLOPS)/d'opérations tensorielles par seconde (TOPS). À titre d'exemple, par comparaison à un SmartNIC ou à une unité de traitement de données (DPU), divers modes de réalisation fournissent une IPU qui, en réponse à un appel de service, peut programmer l'exécution d'une fonction sur des ressources locales et/ou distantes en utilisant une ou plusieurs interfaces de services. Divers modes de réalisation fournissent des services à un niveau d'abstraction plus élevé (API, RPC, services) qui permettent à l'IPU de fournir une granularité plus fine de délestages et de services (par comparaison aux seuls paquets et 5-tuples). Divers modes de réalisation peuvent permettre d'améliorer la télémétrie/ journalisation/ surveillance, la QoS et la planification de sortie et d'entrée, le placement/l'accélération de charges de travail, la sécurité/l'authentification, etc. Divers modes de réalisation d'une IPU peuvent réduire la contamination de cache et de bande passante de l'XPU en plus de libérer l'utilisation de cœurs de calcul polyvalents, et peuvent intégrer de manière croisée l'utilisation de dispositifs d'accélération. Une IPU peut par exemple effectuer un filtrage des données en cours de diffusion en flux à la périphérie du réseau et du stockage, un chiffrement/déchiffrement/transcription et une compression ou une décompression directement sur le disque, vers/depuis la GPU ou vers/depuis le réseau. Divers modes de réalisation d'une IPU peuvent permettre le placement et la gestion de données de manière à ce que les données soient mises à disposition et stockées dans une mémoire ou un dispositif de stockage physiquement proche ou à proximité du lieu où elles seront traitées afin de réduire la latence d'accès aux données. Une IPU peut comprendre une interface à base de diffusion en flux, de sorte qu'il n'est pas nécessaire que l'hôte mette les données en paquets et effectue un contrôle de flux granulaire par paquets et une planification des files d'exécution. Les données peuvent être regroupées dans des régions de mémoire de masse auxquelles la CPU peut accéder, et où des métadonnées (par exemple, des informations extraites d'en-têtes de paquets réseau) et des structures de données sur disque peuvent être placées directement dans des caches proches de la CPU pour un accès granulaire de chargement/stockage de l'ordre de la nanoseconde. Le surdébit de coordination entre les dispositifs peut être réduit, avec peu ou pas de synchronisation des événements I/O (interrogation, veille, interruption, etc.). Dans certains exemples, la télémétrie est assurée pour le traçage des ressources et de la latence sur un trajet d'exécution qui peut être utilisé pour la surveillance, le provisionnement de ressources et la QoS. Dans certains exemples, la QoS est assurée pour le traçage de ressources sur un trajet d'exécution. Une IPU peut utiliser la télémétrie pour effectuer le traçage de ressources sur le trajet, lesquelles influencent les performances d'un déploiement de microservices, permettant à la fois une traçabilité de bout en bout au niveau des services et des composants et des contrôles ciblés correspondants. Divers modes de réalisation fournissent une IPU qui gère le flux de connectivité, comme la sécurité, le routage, l'accélération et le pontage des accès mémoire (locaux ou distants) et les expose en tant que microservice (par exemple, une API système). Divers modes de réalisation fournissent une IPU qui constitue un point d'extrémité pour des services ou un proxy permettant d'accéder à des services. Divers modes de réalisation fournissent une API système permettant à une application de provoquer l'exécution d'un ou plusieurs microservices sur des dispositifs locaux ou distants. Cela permet d'obtenir une couche d'abstraction qui sépare des capacités de fonctions de service de la complexité d'exécution, des changements de mise en œuvre, de l'échelle de déploiement et du lieu de déploiement. Dans certains exemples, une IPU peut effectuer une composition logicielle destinée à accélérer la connectivité entre plusieurs services. Divers modes de réalisation permettent de délester des opérations de trajets de données I/O vers une IPU, telles que chiffrement, authentification, compression, routage, mise en application de politiques, Inspection Approfondie de Paquets/Messages, accélération des accès directs à la mémoire à distance (RDMA) (par exemple, RoCE ou iWarp, virtualisé ou non), déport de protocoles réseau (par exemple, TCP, UDP, etc.), transport fiable, contrôle de congestion, qualité de service, échantillonnage, réplication/multidiffusion, trajets multiples, NAT, pare-feu, etc. Divers modes de réalisation réalisent un délestage des opérations de trajets de données I/O vers une IPU pour unifier les accès mémoire à la mémoire partagée locale ou distante, telles que chiffrement, contrôle d'accès, remappage d'adresse, gestion de cache, accès fiables, commandes atomiques et gestion de mémoire persistante. Divers modes de réalisation réalisent le délestage d'opérations de trajets de commande I/O vers une IPU telles qu'établissement de connexion, gestion d'identité, gestion de clé, authentification, configurations de tunnelisation, mise en réseau intelligente (par exemple, délestage du contrôle de flux, transport fiable, contrôle de congestion), allocation dynamique de ressources, ou basculement rapide. Divers modes de réalisation réalisent le délestage de la gestion du Plan de Commande Hiérarchique Global défini par Logiciel à une IPU, comme dans le cas d'un plan de commande hiérarchique local hébergé par une IPU pour un ou plusieurs nœuds, par exemple multi-hôtes et multi-hébergements, autorisant ainsi un temps de réponse plus rapide et une meilleure évolutivité sur la base d'exigences de nœuds localisés, de migration en direct, d'allocation de ressources. Divers modes de réalisation fournissent une IPU qui effectue une micro-segmentation sans agent (par exemple, en plaçant une inspection de trafic et des points d'étranglement autour de chaque charge de travail sans avoir à modifier et déployer des agents dans chaque charge de travail, par exemple pour surveiller, analyser un trafic malveillant ou néfaste et y remédier). Divers modes de réalisation fournissent une IPU qui tente d'unifier les stockages local et distant, et d'accélérer les I/O (stockage local/distant), en émulant une Mémoire Non Volatile Express (NVMe) et en délestant la création de commandes de stockage NVMe sur matrices (NVMe-oF, NVMe over Fabrics) (ou la création de commandes de stockage de type Internet Small Computer Systems Interface (iSCSI) pour un stockage hautes performances à grande échelle (par exemple, une émulation NVMe ou iSCSI sur le trajet de stockage). Une NVMe-oF est par exemple décrite au moins dans NVM Express, Inc, "NVM Express Over Fabrics", Révision 1.0, 5 juin 2016, et les spécifications qui y sont référencées et leurs variantes et révisions. La norme iSCSI est décrite au moins dans RFC 3720 (2004) et ses variantes et révisions. Divers modes de réalisation fournissent une IPU pour gérer un réseau de stockage (SAN) virtuel hautes performances pour un fonctionnement virtualisé et de type bare metal. Divers modes de réalisation fournissent une IPU qui assure la terminaison du trafic de stockage. Divers modes de réalisation fournissent une IPU pour gérer un système de stockage composable à partir de dispositifs de stockage locaux ou distants, notamment avec compression et chiffrement. Divers modes de réalisation fournissent une IPU qui assure la protection de données en cours d'utilisation, des données au vol et de données au repos (chiffrement, accélération des clés privées/publiques). Divers modes de réalisation fournissent une IPU qui effectue la gestion de clés et la gestion d'identité. Divers modes de réalisation fournissent une IPU pour effectuer un traitement (par exemple, d'accélération) d'expressions régulières (reg-ex) tel qu'inspection approfondie des paquets à grande vitesse au débit de ligne, recherche d'objets de données structurés et traitement de métadonnées. À titre d'exemple, une IPU peut effectuer un traitement de métadonnées associées au stockage, comme la recherche d'horodateurs d'enregistrement et l'application de contrôles d'accès aux enregistrements. Divers modes de réalisation fournissent une IPU pour effectuer des opérations atomiques à distance, par l'intermédiaire d'une connectivité en utilisant un accès direct à la mémoire à distance (RDMA), mais qui peut être programmée par l'utilisateur à un niveau élevé. On peut citer des exemples tels que la recherche par listes chaînées, la recherche en mémoire/d'objets distants d'un motif de données particulier, et la recherche ou modification d'une mémoire peu dense. Divers modes de réalisation fournissent une IPU qui met en œuvre une racine de confiance matérielle sous forme de contrôleur de stockage intelligent et de point de contrôle de confiance pour l'attestation de dispositifs de plateforme ou d'applications logicielles déployées (tels que conteneurs, fonctions en tant que services, enclaves, etc.). Divers modes de réalisation fournissent une IPU qui joue le rôle d'une CPU sécurisée sans affichage (par exemple, ne nécessitant pas d'instructions ou de contrôle opérationnel de la part d'une CPU séparée supplémentaire) pour gérer des points d'extrémité de CPU/XPU/stockage/mémoire. Divers modes de réalisation fournissent une IPU qui prévoit des politiques centralisées logiquement à l'échelle du centre de données pour la sécurité et l'isolation de points d'extrémité. Divers modes de réalisation fournissent une IPU qui effectue des calculs intensifs accélérés sur le réseau (par exemple, OpenSNAPI du Consortium UCF). Une IPU peut par exemple appliquer une cyberintelligence et des analyses alimentées par Intelligence Artificielle (AI) pour sécuriser des centres de données, et permettre une maintenance prédictive afin d'optimiser les dépenses d'exploitation (OPEX) (télémétrie, surveillance, gestion, orchestration, cybersécurité et détection d'anomalies, maintenance prédictive et préventive). Divers modes de réalisation fournissent une IPU qui fournit des interfaces de plan de commande doubles isolées pouvant être mesurées et attestées pour ensuite appliquer une isolation supplémentaire à travers des charges de travail multi-locataires à l'IPU, par exemple par l'intermédiaire de fonctions virtuelles ; de telle sorte que l'interface de plan de commande non digne de confiance ne puisse pas modifier de manière malveillante (sans événement/erreur) le mode de fonctionnement des services de l'IPU. On fournit ci-après un exemple de fonctionnement et d'utilisation d'une IPU. (1) Une application envoie un appel de fonction (par exemple, une API) à un homologue pour exécuter une fonction, un service ou un microservice (par exemple, un logiciel exécuté par un processeur, un matériel, etc.) (2) L'IPU peut intercepter l'appel de fonction. Dans certains exemples, une IPU pourrait découvrir un ou plusieurs services (locaux ou distants) pour exécuter l'appel de fonction. Dans certains exemples, un service peut comprendre un logiciel et/ou un matériel. Dans certains exemples, une IPU peut être couplée par voie de communication à un ou plusieurs nœuds (par exemple, sur une même puce, par l'intermédiaire d'une ou plusieurs interfaces de dispositif ou par l'intermédiaire d'un réseau ou d'une matrice d'interconnexion) et être accessible pour recevoir un appel de fonction provenant de n'importe quel logiciel ou dispositif sur le ou les nœud(s). L'IPU peut effectuer un équilibrage de charge des appels de fonctions. L'IPU peut effectuer l'attestation et/ou la création de ressources de confiance. Dans certains exemples, l'xPU est une ressource de confiance. (3) Appel de fonction de l'IPU à destination de l'xPU cible pour exécuter le service. (4) L'xPU peut exécuter le service et renvoyer une réponse à l'application ayant émis l'appel de fonction et l'xPU peut mettre à jour son état global. (5) L'IPU peut intercepter la réponse de l'xPU et fournir une réponse à l'application indiquant l'achèvement de la fonction. Les avantages potentiels de l'utilisation d'une IPU peuvent comprendre l'un des éléments suivants : (a) surface d'attaque réduite grâce à une isolation physique des applications de locataires non fiables ; (b) évolutivité pour chaque serveur pour un dimensionnement plus simple et un rayon d'action réduit ; (c) point d'abstraction de connectivité clair et utilisation d'xPU et de CPU indépendamment du fournisseur ; (d) prise en charge multi-locataires et bare metal ; (e) associativité d'état pour une meilleure évolutivité des tables et une meilleure mise en cache ; (f) boîte à outils d'accélérateur pour délester les xPU des services liés à la connectivité ; (g) accélération programmable (transparente pour les applications et les cadres d'application de niveaux supérieurs, les bibliothèques, etc. ) ; (h) calcul distribué hétérogène intra-nœud et inter-nœud à grande échelle, dirigé par des modèles de gestion de politiques et de ressources sécurisés et évolutifs (gestion déclarative de l'échelle et de la sécurité) ; (i) méta-informatique pouvant être utilisée pour organiser le calcul au service du calcul ; auto-observation par un quasi-tiers de confiance, etc. ; (j) nouveaux modèles de conception logicielle reposant sur une informatique consciente d'elle-même ; (k) suppression de trajets de code inutiles, par exemple par virtualisation directe d'un dispositif sans OS, hyperviseur, etc. ; (l) mélange et séparation associatifs dans le flux, redirection, filtrage, réduisant encore le surdébit par exécution d'une opération lorsque nécessaire, et en la faisant rapidement et sur place, évitant ainsi la nécessité de stocker puis d'extraire à nouveau les bits importants ; ou (m) flux de données gérés. La illustre un exemple d'IPU. L'IPU 1900 peut par exemple comprendre ou accéder à au moins un gestionnaire de ressources sécurisé 1902, un contrôleur d'interface réseau (NIC) 1904, un système de sécurité et une racine de confiance 1906, une composition de ressources 1908, un gestionnaire d'horodatage 1910, une mémoire et un stockage 1912, des processeurs 1914, des accélérateurs 1916 ou un traducteur 1918. D'autres composants peuvent être utilisés, comme par exemple, mais sans s'y limiter, d'autres composants représentés sur la . Divers modes de réalisation peuvent utiliser un ou plusieurs composants de l'IPU 1900 ensemble ou séparément. À titre d'exemple, une compression et un chiffrement 1920 peuvent être utilisés en tant que service distinct ou chaîné en tant que partie d'un flux de données avec un vSwitch et un chiffrement de paquets. Dans certains exemples, l'IPU 1900 peut comprendre un réseau de portes programmables par l'utilisateur (FPGA) configuré pour recevoir des commandes d'une CPU, d'une XPU ou d'une application par l'intermédiaire d'une API et exécuter des commandes pour le compte de la CPU, notamment la gestion de la charge de travail et les opérations de délestage ou d'accélération. Le FPGA peut être configuré pour exécuter n'importe quelle opération de n'importe quelle IPU décrite ici. La matrice d'interconnexion de calcul 1950 peut fournir une connectivité à un hôte ou dispositif local (par exemple, un serveur ou un dispositif (par exemple, une xPU, une mémoire ou un dispositif de stockage)). La connectivité avec un hôte ou un dispositif local ou un SmartNIC ou une autre IPU peut être assurée à l'aide d'un ou plusieurs des éléments suivants : Peripheral Component Interconnect express (PCIe), ARM AXI, Intel® QuickPath Interconnect (QPI), Intel® Ultra Path Interconnect (UPI), Intel® On-Chip System Fabric (IOSF), Omnipath, Ethernet, Compute Express Link (CXL), HyperTransport, NVLink, Interconnexion Advanced Microcontroller Bus Architecture (AMBA), OpenCAPI, Gen-Z, CCIX, Infinity Fabric (IF), etc. Divers modes de réalisation de la connectivité d'hôte fournissent une mémoire et une mise en cache symétriques pour permettre un appairage équitable entre CPU, XPU et IPU (par exemple, par CXL.cache et CXL.mem). L'interface multimédia 1960 peut permettre une connectivité à un SmartNIC distant ou à une autre IPU ou un autre service par l'intermédiaire d'un support ou d'une structure de réseau. Ceci peut être réalisé par l'intermédiaire de tout type de support réseau (par exemple, câblé ou sans fil) et à l'aide d'un protocole quelconque (par exemple, Ethernet, InfiniBand, Fiber channel, ATM, pour n'en citer que quelques-uns). Dans certains exemples, au lieu que le serveur/CPU soit le composant principal gérant l'IPU 1900, l'IPU 1900 peut être une racine d'un système (par exemple, un bâti de serveurs ou un centre de données) et peut gérer des ressources informatiques (telles que CPU, xPU, stockage, mémoire, autres IPU, etc.) dans l'IPU 1900 et en dehors de l'IPU 1900. Diverses opérations effectuées par une IPU sont décrites ci-après. L'IPU 1900 peut effectuer une orchestration pour décider du matériel ou du logiciel qui devra exécuter une charge de travail sur la base des ressources disponibles (par exemple, des services et des dispositifs) et en tenant compte des accords de niveau de service et des latences, afin de déterminer si des ressources (telles que CPU, xPU, stockage, mémoire) doivent être allouées à partir de l'hôte local ou d'un hôte distant ou d'une ressource mutualisée. Lorsque l'IPU 1900 est sélectionnée pour exécuter une charge de travail, le gestionnaire de ressources sécurisé 1902 peut délester la tâche vers une CPU, une xPU, ou un autre dispositif et l'IPU 1900 peut accélérer la connectivité des exécutables distribués, réduire la latence, la CPU et augmenter la fiabilité. Le gestionnaire de ressources sécurisé 1902 peut par exemple exécuter un maillage de services pour décider de la ressource qui devra exécuter la charge de travail, et permettre à un trafic de couche L7 (couche application) et à l'appel de procédure à distance (RPC) de contourner entièrement le noyau afin qu'une application de l'espace utilisateur puisse communiquer directement avec l'IPU 1900 (l'IPU 1900 et l'application peuvent par exemple partager un espace mémoire). Un maillage de services peut être une couche d'infrastructure configurable de faible latence conçue pour gérer les communications entre des microservices d'applications à l'aide d'interfaces de programmation d'applications (API) (par exemple, par des appels de procédures à distance (RPC)). Un maillage de services peut assurer une communication rapide, fiable et sécurisée entre des services d'infrastructure d'application en conteneurs ou virtualisés. Le maillage de services permet de fournir des fonctionnalités critiques tels que découverte de services, équilibrage de charge, chiffrement, observabilité, traçabilité, authentification et autorisation, et prise en charge de la configuration de disjoncteurs. Dans certains exemples, des services d'infrastructure peuvent comprendre un nœud composite créé par une IPU à ou après la réception d'une charge de travail provenant d'une application. Dans certains cas, le nœud composite comprend l'accès à des dispositifs matériels, des logiciels utilisant des API, des RPC, des gRPC, ou des protocoles de communication avec des instructions telles que, mais sans s'y limiter, iSCSI, NVMe-oF, ou CXL. Dans certains cas, l'IPU 1900 peut se sélectionner elle-même dynamiquement pour exécuter une charge de travail donnée (par exemple, un microservice) dans une infrastructure composable comprenant une IPU, une xPU, une CPU, un stockage, une mémoire et d'autres dispositifs dans un nœud. Les communications peuvent transiter à travers l'interface multimédia 1960 de l'IPU 1900 par l'intermédiaire d'un support vers un NIC/SmartNIC (pour les communications entre nœuds) ou revenir en boucle vers un service local sur le même hôte. Les communications par le biais de l'interface multimédia 1960 de l'IPU 1900 vers une autre IPU peuvent alors utiliser le transport par support mémoire partagé entre des xPU commutées par l'intermédiaire des IPU locales. L'utilisation de communications d'IPU à IPU permet de réduire la latence et la gigue grâce à une planification d'entrée des messages et au traitement de tâches sur la base d'un objectif de niveau de service (SLO). À titre d'exemple, pour une demande adressée à une application de base de données qui nécessite une réponse, l'IPU 1900 peut rendre prioritaire son traitement afin de minimiser le blocage de l'application demandeuse. L'IPU 1900 peut planifier la demande de message prioritaire émettant l'événement pour exécuter une base de données de requêtes SQL et l'IPU peut construire des microservices qui émettent des requêtes SQL, les requêtes étant envoyées aux dispositifs ou services appropriés. La illustre un exemple de traducteur. Une IPU peut par exemple assurer une médiation du trafic depuis des supports de stockage vers l'IPU et effectuer des transformations telles que compression et chiffrement. L'IPU peut lancer le transfert de données et la formation de paquets en exposant des dispositifs de stockage distants ou virtualisés en tant que services locaux utilisés par des applications. L'IPU peut transformer le contenu de données en un format qui est accepté pour le traitement par un dispositif sans autre traduction. À titre d'exemple, pour la génération de paquets, le délestage effectué par l'IPU peut comprendre la sérialisation (par exemple, le déréférencement de pointeurs ou de décalages), la conversion d'une structure de données du format de mémoire en un format prêt pour les I/O comprenant une charge utile/un tampon et des en-têtes, la validation des données, par exemple pour s'assurer que les valeurs sont comprises dans des plages acceptées, ou le remplissage de structures de données et le transfert des données dans des emplacements mémoire. Divers modes de réalisation du traducteur 2000 fournissent au moins une sérialisation/désérialisation 2002 pour le réseau, le stockage (stockage à distance), et les modèles et ensembles de données d'apprentissage automatique. La sérialisation peut comprendre la traduction d'une structure de données en un format qui peut être stocké (par exemple, dans un fichier ou un tampon de données en mémoire) ou transmis (par exemple, au travers d'un réseau informatique) et reconstruit ultérieurement (éventuellement dans un environnement informatique différent). La désérialisation peut consister à extraire une structure de données d'une série d'octets. Les transformations ou traductions peuvent être effectuées à l'aide d'automates finis matériels, de logiciels exécutés par processeur, de matériels, de moteurs regex utilisant des modèles de schémas. Divers modes de réalisation de la traduction de format de données 2004 permettent d'effectuer une traduction entre un format scalaire (par exemple, une quantité), un format vectoriel (par exemple, une direction et une amplitude) et un format de tenseur (par exemple, des scalaires, des vecteurs, des vecteurs doubles, des mappages multilinéaires entre des espaces vectoriels, etc.). Divers modes de réalisation de la traduction de format de données 2004 permettent de traduire des formats de Ligne en Colonne et inversement. Une GPU peut par exemple accepter un format vectoriel ou tensoriel ou un format colonne/ligne mais des données en format scalaire sont disponibles et la traduction de format de données 2004 permet d'effectuer une telle traduction. Un format de données peut être à virgule flottante (FP) 8 bits, FP16, FP32, FP64, ou tout format à virgule flottante dont le nombre de bits est multiple de 2, ou entier (int) 8 bits, entier 16, entier 32, ou tout entier dont le nombre de bits est multiple de 2. Dans certains exemples, la traduction de format de données 2004 peut effectuer une traduction qui transforme des données du format FP32 en format FP16 ou plus généralement, FPX en FPY, où X et Y sont des entiers différents. Dans certains exemples, la traduction de format de données 2004 peut effectuer une traduction qui transforme des données de intX en intY, où X et Y sont des entiers différents. D'autres formats numériques peuvent être transformés, comme par exemple bfloatZ (Brain Floating Point) qui peut comprendre un format à virgule flottante occupant Z bits dans la mémoire de l'ordinateur et qui représente une large gamme dynamique de valeurs numériques lorsqu'une séparation fractionnaire flottante est utilisée. Un format numérique quelconque peut être converti en tout autre format numérique. Différents modes de réalisation de la traduction de format de données 2004 peuvent effectuer une Séparation, un Mélange, une création et une application de masques de bits pour le flux de données au moins entre l'IPU et l'xPU, l'xPU et la CPU, la CPU et la GPU, la CPU et un contrôleur de stockage, le NIC et la mémoire ou le stockage, etc. Une séparation peut consister à générer une sortie à flux multiples à partir d'un flux. Le mélange peut consister à envoyer des données à une cible et à laisser la cible mélanger les données en un seul bloc de données. Une IPU cible peut par exemple effectuer un mélange. Un masque binaire peut être utilisé pour représenter un format dense dans un format peu dense en utilisant un test de zéro ou une comparaison de seuil afin d'utiliser un bit pour identifier des valeurs comme étant non nulles. Une IPU réceptrice peut générer un format dense en utilisant les données et le masque binaire. Si le récepteur n'est pas une IPU, les données peuvent être stockées dans un format peu dense. Le transfert de données non traitées dans une CPU peut entraîner une perte d'efficacité et réduire le débit global, augmenter la gigue et conduire à ce que les cycles de la CPU soient utilisés pour des activités d'infrastructure plutôt que pour des tâches génératrices de revenus. La terminaison des services de données au niveau d'une IPU (par exemple, la traduction du format de données 2004) peut offrir des capacités efficaces pour analyser, transformer, filtrer et traiter les données qui sont poussées vers la CPU plutôt que de pousser les données vers la CPU à des fins de modification du format. La traduction de format de données 2004 permet de formater des données qui sont appropriées pour l'élément de traitement constituant la destination des données (par exemple, un moteur de requête SQL, etc.). La traduction de format de données 2004 permet d'effectuer des opérations telles qu'analyse syntaxique en schémas, transformations de données, validation de données, Concordance-et-Exécution, Concordance-et-Routage, Concordance-et-Extraction, Compactage, Décompression, remplissage de Modèle, etc. L'IPU peut configurer la traduction de format de données 2004 afin de transformer des données en un format utilisé par un microservice exécuté par processeur. Un délestage des opérations de réseau du Plan de Commande Hiérarchique Global vers l'IPU peut se produire en vue de créer une configuration, de nouveaux services et des modifications de la gestion (par exemple, du réseau) définis par logiciel, à la volée. Qu'il y ait ou non un SmartNIC dans un nœud ou un dispositif de plateforme relié à l'IPU, l'IPU peut également exécuter l'OS du réseau pour la commande par SDN. Pour réaliser des économies de cycles d'IPU, si des SmartNIC sont présents, l'IPU peut alors délester vers un SmartNIC certaines des opérations de bas niveau du plan de données SDN telles qu'encapsulation/désencapsulation, chiffrement/déchiffrement, etc., l'IPU réalisant des opérations du plan de commande comme des politiques SDN telles que gestion de routage, établissement et démantèlement de canaux, gestion de disponibilité et d'évolutivité. Divers modes de réalisation du SDN 2006 de l'IPU peuvent mettre en œuvre une gestion de services tels que politiques d'équilibrage de charge de Maillage de Services, coupe-circuits et authentification. Comme décrit ici, l'IPU peut mettre en œuvre des services de sécurité tels qu'authentification, gestion de clés, attestation, et d'autres fonctions telles que haute disponibilité et gestion des pannes. L'IPU peut également gérer l'allocation de ressources locales, le placement de données, telles que mise en cache locale ou prélecture de données ou de fonctions, réponse rapide aux pannes, migration d'applications. En tant que plan de commande local pour un ou plusieurs nœuds, fonctionnant en tant que partie de la hiérarchie des plans de commande du centre de données global, l'IPU peut fournir un temps de réponse plus rapide et une taille plus limitée de l'état à traiter. La illustre un exemple de composants d'un gestionnaire de ressources sécurisé. Un service logiciel peut être hébergé sur une IPU et l'IPU peut comporter une CPU ou certaines caractéristiques d'une CPU pour porter des applications à exécuter sur l'IPU. Des microservices peuvent être isolés d'autres microservices par isolation de la mémoire, du réseau, du stockage à l'aide de VM ou de conteneurs qui utilisent un hyperviseur, un gestionnaire de machine virtuelle (VMM) ou un gestionnaire de conteneur. L'IPU peut effectuer l'authentification de l'API de microservice. Une IPU peut constituer un point de terminaison de service et utiliser un gestionnaire de ressources sécurisé 2100 comme point de terminaison de service. Le gestionnaire de ressources sécurisé 2100 peut fournir un gestionnaire de plateforme pour commander l'ajustement des performances des ressources de la plateforme (par exemple, l'alimentation, la fréquence, la veille et la tension). Une IPU peut fonctionner comme une xPU pour exécuter une variété de services d'infrastructure en dehors de l'orchestration, de la gestion, du pontage de flux de commande ou du pontage de flux de données. Une IPU peut comprendre des fonctionnalités d'un processeur de service (par exemple, un BMC (baseboard management controller, contrôleur de gestion de carte de base), un moteur d'innovation (IE), une entité de gestion (ME)) et fournir des services qui sont exécutés pour gérer l'alimentation, les conditions thermiques, etc. Une IPU peut être liée à certaines ou à la totalité des xPU d'un serveur, avoir un accès complet à la mémoire, et peut appeler d'autres xPU sur d'autres serveurs par l'intermédiaire d'une matrice d'interconnexion ou d'un réseau, en plus d'établir des ponts entre les xPU. L'IPU peut également fournir des services de virtualisation multi-locataires de plateforme pour offrir à au moins certains clients un contrôle individuel des services, tels que des options d'ajustement de l'alimentation, la gestion des dispositifs et les délestages de services. L'IPU peut gérer et maintenir les objectifs de service pour chaque locataire, notamment les allocations de ressources, les politiques de sécurité et la résilience ou les hautes disponibilités. Le gestionnaire de ressources sécurisé 2100 peut servir de centre de sécurité, du moins pour des microservices devant être déployés par une IPU. Une IPU peut exécuter un certain nombre de services pour la mise sur carte (on-boarding) ou la mise hors carte (off-boarding) de dispositifs et de logiciels (par exemple, des matériels au niveau des systèmes sur puce (SoC) et le logiciel à mettre sur carte ou à mettre hors service en toute sécurité au moment de la mise hors carte) pour contrôler les ressources (notamment les dispositifs ou logiciels personnalisés) auxquelles un service peut accéder. Le gestionnaire de ressources sécurisé 2100 peut effectuer les opérations suivantes : 1. Micro-segmentation inter-composants pilotée par politiques, pour superposer et gérer des réseaux virtuels définis par logiciel sur des compositions d'XPU et de partitions de mémoire et de stockage, 2. Gestion des licences, de la facturation, des frais et d'autres services critiques pour la sécurité, 3. Gestion des mises à niveau sans redémarrage pour les matériels, les logiciels ou les micrologiciels, 4. Hébergement de répertoires/catalogues de flux binaires pour FPGA, conteneurs ou images de fonctions devant être lancées en tant que capacités de branchement à chaud, etc. 5. Gestion de la qualité de service ou des Objectifs de Niveau de Service, qui peuvent être statiques ou changer dynamiquement sur la base de mesures de télémétrie (par exemple, latence, gigue, débit, puissance, coût), et/ou 6. Gestion et établissement de ressources de sécurité, telles que des clés, et politique d'utilisation de la mémoire, du stockage et des supports. Le gestionnaire de ressources sécurisé 2100 peut comprendre un équilibrage de charge 2102 permettant d'effectuer un équilibrage de charge des services s'exécutant sur des xPU, des CPU, des ASIC, des FPGA, une logique ou des circuits sur silicium embarqués spécifiques au client et faire office de plan d'orchestration local garantissant des Objectifs de Niveau de Service, un isolement en termes de sécurité, la télémétrie/surveillance/journalisation. Le gestionnaire de ressources sécurisé 2100 peut comprendre une journalisation d'événements 2104 pour effectuer la journalisation d'événements de bas niveau à partir du matériel de la plateforme, de composants du système sur puce (SoC), des VMM ou d'événements système de niveau supérieur tels que, mais sans limitation, appels RPC, violations de QoS, connexions d'utilisateurs et changements de politique. La journalisation d'événements 2104 peut effectuer la surveillance et la journalisation de modifications apportées à un certain nombre de points d'extrémité du réseau, d'appels de procédure à distance (RPC), de gRPC, d'API, d'emplacements mémoire, d'emplacements de stockage ou de plusieurs états machine nommés sur les dispositifs, l'heure de la journée, la bande passante, l'accès et l'authentification des utilisateurs, les demandes de ressources et l'accès à d'autres services hébergés ou passant par proxys, la journalisation d'événements de sécurité dans une base de données sécurisée et signée avec des horodatages matériels et des signatures vérifiables. La mise en œuvre 2106 d'objectifs de qualité de service (SQO) peut se faire par mise en œuvre de SQO tels que codifiés dans le logiciel de service d'infrastructure, les bibliothèques de configuration et les mémoires de valeurs de clés sécurisées. Bien que la codification (déclaration) des SQO puisse être mise en œuvre par logiciel, cette mise en œuvre peut se faire par une combinaison de matériel et de logiciel, car certains événements nécessitent des mécanismes matériels très réactifs, par exemple un routage vers des points d'extrémité moins chargés, une planification des priorités pour la latence, la gigue, les taux de transaction, une modification des bandes passantes d'entrée-sortie (E/SIO) et de la mémoire, des priorités de mise en cache dans les CPU et les xPU, tandis que d'autres événements peuvent nécessiter une adaptation intelligente plus lente mais davantage axée sur l'historique, le contrôle de l'identifiant de processus (PID), la décision d'activer ou non les états de puissance turbo, la mise en cache d'objets de stockage distribués localement dans des états RW (lecture/écriture) ou RO (lecture seule), etc. Un SQO agrégé se compose souvent d'une chaîne de plusieurs services individuels. L'absence de SQO d'un seul service individuel peut être compensée par fourniture d'un meilleur SQO à des services ultérieurs. Un état agrégé père peut être assuré tout au long de la chaîne dans le cas d'ajustements dynamiques. Des services de télémétrie 2108 peuvent exécuter des services associés à la télémétrie en lien avec un ou plusieurs des éléments suivants : flux inter-composants, messages RPC ou télémétrie API, étiquetage, collecte et analyse syntaxique, extraction et analyse syntaxique de la télémétrie intra-composant, service de bout en bout à travers de multiples composants, fonctions, services ou microservices, ou corrélation entre télémétrie et ID d'événement et temps. La corrélation entre télémétrie et ID d'événement et temps peut impliquer une isolation exacte ou statistique entre différents domaines et des instances de locataires (par exemple, machine virtuelle, conteneur, fonctions, armoires), des accès utilisateurs et des services (par exemple, RPC, API, URL). Les services de télémétrie 2108 peuvent effectuer une détection de franchissement de seuils de télémétrie (par exemple, latence, utilisation de ressources) et le déclenchement de réponses scriptées (par exemple, allocation de ressources, équilibrage de charge). Les services de télémétrie 2108 peuvent effectuer un enregistrement de télémétrie, les API de publication/abonnement constituant des capacités supplémentaires. Les services de télémétrie 2108 peuvent effectuer le traçage du comportement d'un service soit au niveau de la couche réseau (par exemple, en utilisant le 5-tuple ip_src, ip_dest, protocole, ip_src_port, ip_dest_port) soit au niveau de la couche application. Le traçage du comportement d'un service se fait soit au niveau de la couche réseau (en utilisant le 5-tuple ip_src, ip_dest, protocole, ip_src_port, ip_dest_port) soit au niveau de la couche application (par exemple, API/RPC) et peut être réalisé en injectant un identifiant qui est transporté avec la charge utile. Pour réaliser une architecture de traçage de bout en bout, on peut utiliser 1 ou plusieurs identifiants qui peuvent être liés entre eux à un moment donné, puis utilisés collectivement pour surveiller le comportement du service/code. À titre d'exemple, l'IPU pourrait fournir à un agent s'exécutant sur l'hôte un ensemble d'identifiants (par exemple, un UUID pour la couche application, un ID de Moniteur de Ressources (RMID) pour l'Unité de Traitement et un ID d'Espace d'Adresses de Processus (PASID) pour l'unité de gestion de mémoire (MMU), l'IOMMU et un Dispositif SR-IOV). Ces identifiants, conjointement avec l'ID de plateforme, peuvent ensuite être utilisés pour créer un UUID (par exemple, un identifiant haché) et intégrés dans le flux de paquets par l'IPU, par exemple à l'aide d'un P4-INT (télémétrie réseau en bande), pour surveiller le flux de bout en bout. À chaque stade de l'architecture, un ou plusieurs des identifiants, avec la télémétrie associée, peut/peuvent être poussé(s) vers le service de télémétrie. Il est à noter que la QoS peut être assurée de manière semblable sur la base de mesures de SLO, de SQO et de télémétrie. Si un SQO, tel que la latence, n'est pas atteint, alors des ressources supplémentaires (par exemple, allocation de cache, bande passante mémoire, bande passante multimédia, priorité, réplication de structures de données, redirection de demandes, réplication de services pour réduire les charges, etc.) peuvent être allouées par le gestionnaire de ressources sécurisé 2100. Des ajustements peuvent se fonder sur des comportements historiques, des modèles ou des algorithmes machine dynamiques. Le dispositif source d'événements 2110 peut traiter des journaux bruts et des informations de télémétrie pour créer des services d'événements matériels et/ou logiciels inter-composants (hétérogènes) tels que recherche de sources, surveillance, traitement, hiérarchisation, filtrage et livraison d'événements. Le gestionnaire d'événements 2110 peut diviser l'exécution des services entre le logiciel exécuté par une ou plusieurs IPU et des matériels d'IPU, notamment l'activation pilotée par événement de composants récepteurs et/ou de fichiers logiciels. Le gestionnaire de transfert de données 2112 peut effectuer une prise en charge transparente d'invocations synchrones et asynchrones et de transferts de données synchrones et fiables sur des canaux asynchrones de bas niveau et de meilleur effort. Le gestionnaire de transfert de données 2112 peut tenter de fournir des interfaces cohérentes aux applications tout en faisant abstraction du fait que le service est local ou distant sur le réseau (par exemple, accélérateurs mutualisés hétérogènes). Un accélérateur d'intelligence artificielle (AI) 2114 peut être utilisé pour des matériels et des logiciels d'AI distribuée afin d'établir un pont entre des domaines de mémoire partagés locaux et distants (par exemple, CXL) par le biais du réseau du centre de données (par exemple, Ethernet ou autres protocoles). Pour un apprentissage AI distribué à grande échelle, l'accélérateur AI 2114 peut combiner des gradients et distribuer des gradients combinés entre des xPU appropriées (à la fois intra et inter-nœuds) pour chaque micro-lot parmi les nœuds, et pour chaque itération dans chaque micro-lot intra-nœud. Certains exemples d'IPU peuvent gérer ou exécuter des opérations de données en parallèle pour les inférences AI et d'autres fonctions parallèles sur les données, telles qu'opérations d'inférence sur données en mémoire locale ou sur données en flux continu provenant du réseau, décodage et prétraitement de données pour inférences AI, fourniture et partage de services d'inférences AI pour calculs/applications locaux, décodage multimédia, traitement de trafic réseau 5G/parallèle. Certains exemples d'une IPU peuvent gérer ou exécuter des concordances de balises d'Interface de Passage de Messages (MPI), les délestages pour les messages AI, ou le délestage de la couche de sommation d'apprentissage AI. En tant qu'entité programmable distribuée à large bande passante accessible depuis et vers chaque xPU et vers la mémoire système et le réseau, les IPU peuvent facilement effectuer des mises à jour de gradient ou de poids à l'aide de l'accélérateur AI 2114, et permettre à une interface cohérente avec le cache (telle que CXL) de propager automatiquement les nouveaux gradients vers chaque XPU, laquelle peut appliquer ses propres poids mis à jour. Les IPU peuvent permettre aux XPU de s'enregistrer dans un tourniquet, recevoir des gradients ou des poids mis à jour, et poursuivre les mises à jour versionnées des valeurs. De même, au début de chaque micro-lot, une XPU choisie au hasard peut envoyer tous ses poids mis à jour pour obtenir le synchronisme souhaité. Dans certains exemples, ce calcul de gradient (combinaison ou réduction) peut être effectué sur une CPU ou sur un serveur de paramètres (cela pouvant être peu efficace et sujet à des goulots d'étranglement), ou bien nécessite une structure réseau spéciale capable de prendre en charge diverses opérations ALU en réseau. La réalisation de mises à jour des poids par l'intermédiaire d'un serveur de paramètres peut être effectuée de manière asynchrone (pour des raisons de performances et de simultanéité), mais cela peut poser des problèmes de stabilité, en particulier dans l'apprentissage profond probabiliste. Une IPU peut se délester de cette fonction en fournissant directement un flux continu à large bande passante et des transformations de données à mémoire mutualisée, l'accélérateur AI 2114 gérant les tampons et le partage avec les XPU. Le mélange de gradients à base d'IPU peut être agnostique vis-à-vis des XPU en ce sens qu'une XPU peut être une CPU, une GPU, un FPGA, une unité de traitement tensoriel (TPU), un processeur Habana, etc. Il est ainsi possible de bénéficier d'un apprentissage profond à grande échelle quasi-synchrone au moyen des IPU. (On se référera par exemple au Distributed TensorFlow Dev Summit 2018 (qui permet notamment un apprentissage de modèles sur une machine et de multiples GPU et qui introduit une API fondatrice pour la prise en charge future d'autres configurations)). Un détecteur d'intrusion 2118 peut gérer des frontières d'isolation contre les défauts intra-serveur pour appels RPC ou gRPC entre dispositifs, et le partitionnement renforcé sur mémoire partagée de sorte que les accès mémoire entre partitions sont acheminés à travers l'IPU, une IPU faisant office de proxy matériel pour que la mémoire hébergée dans une partition fasse apparaître les accès effectués à partir d'une autre partition. Dans la pratique, des dépassements de pointeurs ou des accès intempestifs à plat peuvent être bloqués par des politiques d'indirection-réflexion à base d'IPU. Ces politiques peuvent également être utilisées pour mettre en application des politiques d'accès de sécurité et pour la détection d'intrusion dans le cas d'accès à des zones restreintes, d'utilisation excessive de ressources (bande passante, stockage), d'accès à des services/données non autorisés, d'échecs d'authentification, d'activité à des moments inhabituels, de localisation géographique, de motifs d'accès (par exemple, par sondage, scannage). Un courtier de communications 2120 peut mettre en œuvre des capacités de courtage de trafic et de communication multiprotocole, non seulement à la frontière du réseau, mais également à l'intérieur d'un système, aux frontières de l'XPU. On peut citer l'exemple suivant. Le code/la bibliothèque de l'hôte de l'IPU ou des IPU peut effectuer un aiguillage entre une version précédente d'une certaine XPU et une nouvelle version de l'XPU qui présente de nouvelles capacités, ou vice versa. À titre d'exemple, il peut le faire en raison du fait qu'une architecture de jeu d'instructions (ISA) dépréciée d'une XPU peut être présente dans la version A et non dans la version B. Un "thunk" peut comprendre une traduction d'instructions, de protocoles ou de données à des fins de compatibilité. Un système peut avoir une XPU à la version A dans le nœud X, et une XPU à la version B dans le nœud Y. Les invocations d'API versionnées A ou B peuvent être mises sous forme de thunks lorsque cela est possible. Lorsqu'il n'est pas possible d'utiliser des thunks, l'IPU peut acheminer les appels vers les bonnes instances (par exemple, sur le nœud X ou le nœud Y) d'une même application selon les versions (A ou B) des XPU sur lesquelles les instances s'exécutent. Une version logicielle (par exemple, émulée) de l'XPU peut également prendre en charge une version Z en fin de vie ; et les appels à la version Z peuvent être acheminés vers l'XPU logicielle. Le gestionnaire de proxy 2122 peut mettre en œuvre des conteneurs de microservices de proxy (par exemple, des side-cars de maillage de services, des passerelles API ou des bus de messages) destinés à des applets. Les applets peuvent fournir une représentation à distance et une mise en cache des services, de sorte que des trajets rapides ou des invocations communes peuvent être traités dans les applets pour le compte d'un service cible (appelé). Dans certains cas, au lieu que les appels se fassent de microservice à microservice, certains appels peuvent être acheminés vers des side-cars de maillage de services à base d'IPU. Cela peut s'appliquer à des proxy de renvoi et/ou à des proxy distants. Ces applets peuvent être utilisés pour effectuer une réduction de données, un filtrage, une mise en cache, etc. pour le compte de microservices appelés, de sorte que (a) moins de la totalité des appels doivent effectivement être effectués de bout en bout et (b) moins de la totalité des données sont déplacées ou copiées de l'appelant à l'appelé. Des IPU peuvent être couplées étroitement à des XPU, de sorte que les applets peuvent s'exécuter efficacement et avec un meilleur partage de données en cache avec l'appelant et dans le contexte de l'appelant (mais peut-être avec un privilège plus élevé). Service par service, les applets peuvent réaliser une attestation et une validation, étant donné que l'IPU n'est pas sous le contrôle de l'appelant ni de l'appelé, de la mise en lots et la consolidation du trafic, et de l'exécution de procédures stockées administrativement (cela permettant donc de mettre en application des contrats intelligents). Dans le cadre d'une opération de proxy à distance, les applets permettent de réduire la charge imposée au microservice de l'appelé et de réduire la latence en renvoyant le contenu en cache, lorsque cela est possible. Les applets peuvent également exécuter une fonction de décompression et de transformation des données, comme un service de bus de messages PubSub délesté vers l'IPU. L'IPU peut gérer le stockage, la transformation de données et la transmission multidestinataire fiable vers des points d'extrémité abonnés. Cela permet de réduire les exigences en matière de CPU hôte, de copies de mémoire et de bus IO. Des agents side-cars de conteneurs délestés vers l'IPU peuvent dans certains exemples effectuer une surveillance de l'état de santé (par exemple, fournir un contrôle local plus rapide de la récupération) ou etcd (par exemple, en utilisant une mémoire de valeurs de clés distribuée et fortement cohérente pour une plus grande sécurité des données pour les secrets partagés). Un gestionnaire d'exécution 2124 peut mettre en œuvre une exécution fiable d'applications de données en flux continu de bout en bout avec et sans SmartNIC, entre un microservice M1 sur une XPU X1 dans un nœud N1, et un microservice M2 sur une XPU X2, dans un autre nœud N2. Un contrôleur SmartNIC réalisant une opération de contrôleur de stockage peut assurer un traitement de protocole dans le SmartNIC et une accélération de divers protocoles de réseau de stockage, de cryptographie, de moteur de délestage TCP, dans les cœurs du SmartNIC, et le SmartNIC peut devenir un point de terminaison de trafic. Un SmartNIC peut ne pas avoir la capacité de répondre à des défaillances de logiciel ou d'XPU et peut donc rediriger le contrôle vers une entité capable d'effectuer un basculement, par exemple de M1 à M3 ou de X1 à X3, ou de M2 à M4 ou de X2 à X4, afin d'obtenir une fiabilité de service à service de plus haut niveau (de bout en bout). Au lieu ou en plus de la responsabilité de traiter la fiabilité des applications de données en flux continu de bout en bout au niveau homologue à homologue, dans un système à base d'IPU, une IPU peut faire office de para-virtualisation d'une XPU et peut donc surveiller l'XPU et les microservices sur cette XPU (par exemple, surveiller leurs battements cardiaques ou d'autres indications), et lancer une action corrective telle que la création d'une nouvelle instance (par exemple, pour des pannes logicielles) et un routage vers une XPU de basculement enregistrée (pour des pannes matérielles) au niveau de l'XPU. Comme décrit ici, une IPU peut fonctionner en tant que plan de commande et décider d'exécuter un service de secours ou de demander des ressources supplémentaires. L'IPU peut exécuter un contrôleur SDN fils ou un hyperviseur. L'IPU a alloué des ressources ou des ressources de secours. L'IPU peut utiliser un chiffrement pour assurer le chiffrement et le déchiffrement du contenu transféré entre dispositifs dans une IPU ou d'une IPU à une autre IPU ou d'une IPU à un autre dispositif. Une IPU peut faire office d'agent de confiance et de passerelle entre communications et services de confiance. Il est possible d'utiliser un chiffrement de mémoire total (TME), un chiffrement de mémoire total à clés multiples (MKTME), des Extensions de Domaine de Confiance (TDX), un chiffrement de DDR, un chiffrement de conteneur de fonction en tant que service (FaaS) ou une enclave/TD (domaine de confiance). Les métadonnées peuvent comprendre un ou plusieurs des éléments suivants : paramètres d'accord de niveau de service (SLA) à respecter (par exemple, TCO), utilisation attendue de bande passante mémoire, débit attendu de réception de paquets, niveau de sensibilité à la latence ou niveau de sensibilité à la gigue. Plusieurs méthodes de chiffrement peuvent être utilisées, telles que virtualisation, partitionnement physique, domaines de confiance, enclaves sécurisées, Intel® SGX, Intel® TDX, AMD Memory Encryption Technology, AMD Secure Memory Encryption (SME) et Secure Encrypted Virtualization (SEV), ARM® TrustZone®, Apple Secure Enclave Processor, ou Qualcomm® Trusted Execution Environment. Une enclave/un domaine de confiance sécurisé peut être une région de mémoire ou un processeur, ou les deux, qui ne sont pas accessibles à des processus, à l'exception de processus désignés et limités, de machines virtuelles ou de conteneurs. Le chiffrement ou le déchiffrement peut par exemple utiliser un chiffrement de mémoire total (TME) et un chiffrement de mémoire total à clés multiples (MKTME) disponibles commercialement auprès d'Intel Corporation (comme décrit dans Intel Architecture Memory Encryption Technologies Specification version 1.1 datée du 17 décembre 2017 et des révisions ultérieures), des composants qui mette en œuvre le TME et le MKTME, la manière dont le TME et le MKTME fonctionnent, etc. Ces technologies peuvent être utilisées pour fournir une perspective facilement compréhensible pour comprendre les divers modes de réalisation divulgués et ne sont pas destinées à limiter les mises en œuvre au seul emploi des TME et MKTME. Le TME fournit un mécanisme de chiffrement de données par interfaces mémoire, au moyen duquel un contrôleur mémoire chiffre les données circulant vers la mémoire ou déchiffre les données circulant depuis la mémoire et fournit un texte en clair pour une consommation interne par le processeur. Dans certains exemples, le TME est une technologie qui effectue un chiffrement de la totalité ou d'une partie de la mémoire d'un dispositif à l'aide d'une clé. Lorsqu'il est activé par la configuration du système I/O de base (BIOS) (ou par l'Interface de Micrologiciel Universel Extensible (UEFI), ou par un chargeur d'amorçage), le TME peut permettre le chiffrement de la mémoire à laquelle accède un processeur sur un bus de mémoire externe, notamment des informations d'identification du client, des clés de chiffrement et d'autres informations de propriété intellectuelle (IP) ou personnelles. Le TME prend en charge une variété d'algorithmes de chiffrement et, dans un mode de réalisation, peut utiliser une norme de chiffrement du National Institute of Standards and Technology (NIST) pour le stockage, comme l'algorithme XTS du système de chiffrement avancé (AES) avec des clés à 128 bits. La clé de chiffrement utilisée pour le chiffrement de la mémoire est générée à l'aide d'un générateur de nombres aléatoires durci dans le processeur et n'est jamais exposée au logiciel. Les données en mémoire et sur les bus mémoire externes peuvent être chiffrées et sont en texte clair à l'intérieur des circuits du processeur. Cela permet à des logiciels existants de fonctionner sans devoir être modifiés tout en protégeant la mémoire à l'aide des TME. Il peut y avoir des scénarios pour lesquels il peut être avantageux de ne pas chiffrer une partie de la mémoire, de sorte que le TME permet au BIOS (ou à l'UEFI ou au chargeur d'amorçage) de spécifier une plage d'adresses physiques de la mémoire qui ne doit pas être chiffrée. Le logiciel fonctionnant sur un système compatible TME a une visibilité totale sur toutes les parties de la mémoire qui sont configurées pour ne pas être chiffrées par le TME. Ceci peut être réalisé en lisant un registre de configuration dans le processeur. Dans certains modes de réalisation, le TME peut prendre en charge plusieurs clés de chiffrement (TME Multi-Clés (MKTME)) et offre la possibilité de spécifier l'utilisation d'une clé spécifique pour une page de mémoire. Cette architecture permet d'utiliser soit des clés générées par processeur, soit des clés fournies par le locataire, offrant ainsi une grande souplesse aux clients. Les VM et les conteneurs peuvent être isolés de manière cryptographique les uns des autres en mémoire à l'aide de clés de chiffrement distinctes, qui peuvent être utilisées dans des environnements de nuage multi-locataires. Les VM et les conteneurs peuvent également être mutualisés pour partager une clé individuelle, cela augmentant encore l'échelle et la souplesse. Un exemple d'enclave/domaine de confiance peut être un Environnement d'Exécution de Confiance (TEE), c'est-à-dire un environnement d'exécution isolé qui fournit des fonctionnalités de sécurité telles que l'exécution isolée (confidentialité), l'intégrité des applications (et des systèmes d'exploitation invités) s'exécutant avec le TEE, ainsi que la confidentialité de leurs actifs. Les TEE aident à se défendre contre les attaques visant les couches sous-jacentes de la pile, notamment le système d'exploitation hôte, l'hyperviseur hôte, les dispositifs, les pilotes et les micrologiciels, en fournissant des environnements d'exécution spécialisés appelés "enclaves/domaines de confiance". Le TEE peut être un plan de commande pour une IPU mais peut comprendre une logique d'exécution matérielle. Chaque domaine de confiance peut avoir sa propre clé éphémère permettant une isolation cryptographique supplémentaire. Des procédés de chiffrement de liens matériels ou logiciels peuvent être utilisés pour connecter deux domaines de confiance, chaque domaine de confiance pouvant fonctionner sur des XPU distinctes par l'intermédiaire d'une IPU. On peut citer comme exemple d'enclave une collection logique d'entités qui appartiennent à un même domaine "de confiance" avec une communication sécurisée entre entités. Il peut y avoir de multiples enclaves à l'intérieur d'une armoire. Une enclave peut couvrir plusieurs armoires. Une enclave peut comprendre un ou plusieurs domaines de mémoire partagée. Des entités situées à l'intérieur d'une enclave peuvent contenir des régions de mémoire non partagée. Il peut exister une relation de confiance entre des enclaves. Une enclave peut exposer des parties de la mémoire à d'autres enclaves. La illustre un exemple de système de sécurité et de racine de confiance. Dans le cas de l'informatique confidentielle, il est essentiel de pouvoir attester auprès d'un service donné (en cas de défi) que tous les éléments du système distribué répondent aux objectifs de sécurité des services. Une technologie telle que la chaîne de blocs peut être utilisée pour construire la chaîne de confiance qui peut ensuite être lue en toute sécurité par un service. Pour construire la chaîne de confiance, il faut toutefois assurer une coordination entre les dispositifs distribués et veiller à ce que le contexte de confiance soit communiqué de manière appropriée (on se référera à la messagerie mentionnée plus haut). L'IPU peut prendre en charge ce modèle de confiance distribué et fournit un pont sécurisé entre domaines. Un pontage sécurisé 2202 permet d'assurer un pontage sécurisé de périmètres de sécurité entre de multiples racines de confiance matérielles indépendantes et des microprogrammes ou logiciels attestés (afin de former des Cliques de Confiance) et d'assurer une propagation/délégation de confiance guidée par des politiques sécurisées au sein des serveurs, et entre des serveurs homologues. Le pontage sécurisé 2202 permet en outre d'assurer le contrôle du noyau et d'espace utilisateur à espace utilisateur ainsi que des transferts et migrations de données sans passer par des couches logicielles de supervision. À titre d'exemple, le pontage sécurisé et l'attestation peuvent être appliqués à des maillons d'une chaîne de fonctions pour assurer un transfert sécurisé de données et un calcul sécurisé. Une renégociation de la confiance pour des services, microservices, éléments ou dispositifs sur un trajet de données au moyen de clés appropriées peut être évitée, mais peut être utilisée. Une IPU peut négocier la sécurité avec un dispositif faisant partie d'une chaîne ou d'un trajet de dispositifs. Une fois la sécurité assurée par un trajet de dispositifs, un trajet de données menant aux dispositifs du trajet peut être considéré digne de confiance. Un chiffrement et un déchiffrement peuvent avoir lieu à chaque point de jonction entre les dispositifs. Des données peuvent être transmises à partir de chaque élément sécurisé de la chaîne. Les données peuvent comprendre un code ou une clé dont on vérifie qu'il est permis de les traiter sur un dispositif, en plus du fait qu'il est vérifié que chaque dispositif est digne de confiance. Si un dispositif change de logiciel ou de propriétés de dispositif (par exemple, mises à jour ou changements d'applications, de services ou de microservices, modifications du routage réseau (par exemple, sur des liaisons non chiffrées), modifications d'emplacements des services (par exemple, déploiement en dehors d'une région de réglementation), changement de micrologiciel, changement de microcode, modification de la quantité de mémoire, modification de la quantité de stockage, ajout ou suppression d'un dispositif à chaud), une IPU peut alors interrompre les sessions actives et réattester ou réauthentifier le dispositif dont les propriétés ont changé avant d'autoriser l'utilisation du dispositif. Un dispositif peut indiquer ou publier à destination d'une IPU si le dispositif est en mode débogage, en réinitialisation de fonction, ou en mise à jour de micrologiciel, et qu'il peut envoyer un message à l'IPU pour indiquer un changement de propriétés. Dans certains cas, une IPU peut autoriser une mise à jour du micrologiciel et continuer de considérer le dispositif comme étant un dispositif de confiance pour des mises à jour particulières du micrologiciel et pour des dispositifs particuliers. L'IPU peut révoquer les droits de certains dispositifs à une utilisation de confiance si les propriétés du dispositif changent. L'IPU peut vérifier périodiquement les dispositifs pour déceler d'éventuels changements et valider le dispositif. Le dispositif peut être validé par un certificat destiné à un logiciel ou à un micrologiciel particulier ou à des propriétés particulières du dispositif. En tant que ressource locale consciente des événements de locataire, le moteur de sécurité 2204 de l'IPU peut également déclencher des actions de sécurité (par exemple, une réattestation ou une réauthentification de dispositifs ou de logiciels) sur la base d'actions de locataire/de types d'événements et de la politique de sécurité ou du risque avant d'autoriser des actions liées à la sécurité telles qu'un accès aux clés, au stockage, aux RPC, aux API, aux régions de mémoire partagée ou le changement d'identité de l'utilisateur, l'utilisation de ressources, etc. Un ensemble d'expressions de confiance peut être appliqué, par exemple un locataire X peut être le colocataire d'un locataire Y à condition que le locataire Y ait été attesté par Z, ou qu'une mesure de Y concorde avec l'une de trois versions récentes approuvées pour Y, etc. Ces expressions peuvent codifier différents trajets avec diverses combinaisons d'attributs de sécurité et de garantie de confiance et de confidentialité de différents services et des XPU d'infrastructure et de la plateforme sur lesquels ils sont distribués. Ces méthodes déclaratives pour exprimer la confiance peuvent conduire à une composition ou une compilation en temps réel des ingrédients nécessaires aux services. Dans certains exemples, au moment où les ressources de la plateforme sont affectées à un microservice, la confiance que le microservice exige pour les ressources de la plateforme, et la confiance qui est requise par la plateforme de ce microservice, peuvent être calculées à partir d'expressions. La confiance requise peut ensuite être obtenue en effectuant différentes mesures, vérifications, attestations et autres opérations. La confiance peut être contrôlée davantage par des politiques qui dictent ou imposent l'exécution de diverses opérations dans un ordre prescrit. Cela présente l'avantage potentiel qu'au lieu de traiter l'orchestration et la sécurité de façon monolithique, il est possible d'établir des spécifications de confiance formelles de manière flexible, en fonction d'options disponibles. Cela conduit à une approche de "sécurité définie par logiciel ou par politique" selon laquelle les IPU, qui sont indépendamment fiables et vérifiées en tant que racines matérielles de confiance, deviennent le mécanisme d'ancrage permettant de composer la confiance conformément à des spécifications formelles, tout en travaillant étroitement avec les fonctions de provisionnement des ressources et d'assemblage des orchestrateurs. Cette façon de procéder permet également un partitionnement non virtualisé (par exemple, sans système d'exploitation) des ressources par l'intermédiaire des IPU, qui font office d'usine pour la mise en place des limites de confiance et d'isolation nécessaires, sans forcer les VEE lorsque des raisons de performance, d'agilité ou autres justifient une exécution de type bare métal. L'orchestration de la confiance peut également être associée à des mécanismes adjacents tels que la journalisation des opérations requises et de leurs résultats, de manière à ce que l'établissement de la confiance soit enregistré en même temps que les raisons qui en permettent l'établissement. L'IPU peut être coordinateur avec d'autres dispositifs, avec les API de confiance et de composition, créer, modifier et effectuer un pontage entre des îlots de confiance qui comprennent des composants matériels, des composants logiciels et des régions de mémoire dans chaque îlot. Cela peut permettre une micro-segmentation flexible sans agent, grâce à laquelle, lorsque les relations informatiques changent ou évoluent, il n'est pas nécessaire de changer de logiciel d'application, de logiciel de bibliothèque, etc. pour redéfinir les limites de confiance. L'IPU peut agir comme une micro-segmentation sans agent et sans obstacles logiciels. Un pontage sécurisé 2202 peut fournir un pont informatique confidentiel sécurisé entre des environnements d'exécution de confiance (TEE) à différentes XPU. De même, une IPU peut faire office de passerelle sécurisée entre le TEE d'une XPU et un TEE d'un contrôleur SmartNIC. Cela peut permettre une reconstitution dynamique d'un TEE couvrant plusieurs XPU, mémoires, stockages et SmartNIC. Cela peut également permettre à l'IPU de coordonner et de gérer les migrations en direct (par exemple, la migration de machines virtuelles, de conteneurs, de données ou de clés) pour des déploiements dans des environnements virtualisés, conteneurisés et de type bare metal. Le code peut être exécuté dans des environnements de confiance. La chaîne de blocs peut être interrogée pour déterminer des profils d'attestation de ressources disponibles et si les ressources sont dignes de confiance. L'IPU peut établir le niveau de confiance avant l'exécution du service ou pendant l'exécution du service. L'IPU peut déterminer la chaîne de confiance avant de fournir des résultats. Une attestation locale et une attestation peuvent être enregistrées dans une chaîne de blocs et après le renvoi d'un résultat, l'IPU peut vérifier si la totalité d'une chaîne de confiance est respectée. L'attestation peut comprendre un environnement virtuel de confiance, des versions de micrologiciels de confiance, un contrôleur de réseau, un micrologiciel de l'IPU. Dans certains exemples, l'attestation peut comprendre la vérification d'un hachage de certificats. Un espace de noms 2206 peut enregistrer chaque entité constitutive avec un UID immuable, coder ses propriétés, stocker dans une zone de mémoire non volatile privée de l'IPU les diverses propriétés codées et leurs noms symboliques lisibles par l'être humain, etc. L'espace de noms 2206 peut être mis en œuvre sous forme de circuits matériels qui peuvent permettre à des IPU d'être autonomes sans avoir besoin d'agents logiciels ou micrologiciels à base de CPU pour exécuter un processus de démarrage sécurisé, un processus de mise sur carte sécurisé, etc. En revanche, cette responsabilité peut être complétée par une base de données créée et maintenue par des circuits d'espace de noms (par exemple, des agents logiciels à base d'IPU). L'espace de noms 2206 peut être tiré de services à base de nuage au lieu de mécanismes d'initialisation ou d'arrêt à base de CPU hôte et peut être utilisé dans des déploiements de type bare metal ou des environnements multi-locataires. Les éléments de sécurité et les clés cryptographiques peuvent tous être incorporés par le biais de capacités sécurisées d'enregistrement et d'injection de clés, de sorte que les unités IPU constituent les mécanismes fondamentaux autour desquels le reste des contrôles de sécurité et de gestion peuvent être automatisés. Le gestionnaire de services 2208 peut fournir un fonctionnement sans affichage des XPU, des FPGA ou d'autres dispositifs, notamment la gestion de leurs flux binaires, les allocations de tranches de FPGA, etc. pour une utilisation par différents services accélérés par FPGA. Les FPGA (ou d'autres dispositifs) peuvent faire partie de FPGA mutualisés ou d'une partition de calcul de FPGA qui est précédée d'une IPU et connectée par un NIC classique. Bien que de telles opérations puissent être mises en œuvre sur un FPGA en faisant en sorte que le FPGA mette en œuvre un train binaire de type "IPU logicielle", cela implique potentiellement (a) un fort surdébit et un nombre important de portes sur le FPGA pour un fonctionnement complexe qu'il est idéal et plus efficace de confier à une IPU et (b) bien qu'en théorie une IPU logicielle puisse évoluer par mise à jour du flux binaire, elle ne présente pas la même souplesse, efficacité ou simplicité qu'une mise à jour du logiciel sur une IPU. Cependant, de telles opérations peuvent être mises en œuvre sur un FPGA dans des modes de réalisation quelconques. Le gestionnaire de services 2208 peut assurer une gestion active de l'imagerie de flux binaire et de la planification de tranches, de l'attestation de sécurité, de la mise en application de politiques, etc. Le gestionnaire de services 2208 peut lancer des objets sur demande, générer des données sur appel en appelant un générateur, et autres. Une IPU peut orchestrer et héberger des microservices enveloppants dont le rôle est d'effectuer la reproduction effective de microservices réels qu'ils enveloppent. Même si des dispositifs (par exemple, des XPU, une mémoire, un stockage, d'autres composants de plateforme) sont attestés et mesurés et regroupés dans des compositions de machines virtuelles, de conteneurs, etc., certains dispositifs sont plus faciles à associer que d'autres à un niveau de confiance établi donné et certains composants logiciels sont plus dignes de confiance que d'autres pour diverses raisons. Des circuits de confiance asymétriques 2210 permettent de mettre en œuvre la possibilité d'appliquer une confiance asymétrique au sein d'une composition donnée, de sorte que, par exemple, des données circulant de la source A vers la destination B sont soumises à un ensemble de conditions mais que des données circulant de B vers A sont soumises à un autre ensemble de conditions qui sont un ensemble de conditions plus strictes. Pour mettre en œuvre de telles règles, les IPU pourraient mettre en œuvre de multiples groupes de tables de pages par l'intermédiaire desquelles les accès aux pages physiques sont traités, et traiter logiquement différents modules comme s'ils étaient des processus différents ("sous-processus"), même si les données se trouvent dans le même ensemble de pages physiques et mappées sur les mêmes adresses virtuelles, sachant que des tables de pages différentes fournissent un point d'indirection permettant de vérifier si, à un moment donné, un sous-processus particulier a le droit de traduire une adresse particulière de l'espace d'adressage. Alors que la mise en application peut être effectuée dans les XPU elles-mêmes, les IPU peuvent jouer le rôle d'unités aidant à composer de manière souple ces espaces à sous-processus multiples dans lesquels les pages des tables de pages peuvent être organisées en une hiérarchie d'ensembles et de sous-ensembles d'équivalence. Différents niveaux de privilège peuvent être associés à un VMM, un OS hôte, un OS invité, un processus d'OS hôte, un processus d'OS invité, une bibliothèque d'OS hôtes/ invités, etc. Cependant, au lieu d'une confiance strictement hiérarchisée, les relations de confiance peuvent être modélisées par un graphe orienté de sorte qu'un sommet A du graphe peut faire confiance à un sommet B si B est atteignable depuis A (mais pour que B fasse confiance à A, A doit être atteignable depuis B). Un courtier de confiance 2212 peut également protéger des structures logiques, telles que des modèles ML, des jeux de données et des résultats, en les protégeant en tant que dispositifs logiques différents dont l'accès est contrôlé indépendamment. Des IPU sont intégrées à la plateforme ; des IPU tierces peuvent être intégrées par conception, c'est-à-dire que certains de leurs éléments fondamentaux peuvent être "gravés" ou "embarqués de manière sécurisée". Une fois cela fait, les IPU peuvent être utilisées pour limiter la visibilité des opérations et de l'état d'un composant SoC fabriqué par le fournisseur A et d'un autre composant SoC fabriqué par le fournisseur B, selon des règles d'engagement entre les composants SoC fabriqués par différents fournisseurs A et B. Ainsi, B ne peut pas "tester" A et A ne peut pas "tester" B autrement que par des règles d'engagement antérieures. Par conséquent, pendant un flux de débogage du silicium, A et B peuvent être en mesure de partager un ensemble d'emplacements mémoire, mais une fois le débogage terminé et la plateforme mise en production, A et B peuvent être partiellement occultés l'un par rapport à l'autre par une randomisation introduite par les IPU. Cela permet d'éviter à la fois l'extraction d'informations par sondage (envoi d'entrées qui ne peuvent jamais se présenter sous la forme d'une combinaison particulière) et par grattage ou traçage physique des circuits intégrés. Toutefois, reconnaissant que, de temps à autre, il peut être nécessaire de rouvrir ou d'élargir la visibilité de A par rapport à B ou de B par rapport à A, des IPU peuvent mettre en œuvre des mécanismes permettant de modifier temporairement les règles d'engagement. En général, cela peut être le cas lorsque le tiers ayant intégré les SoC tiers provenant de A et de B réunit A et B pour les soumettre à un régime de tests dirigés de façon que seuls des tests prescrits soient effectués, que seul le traçage prescrit soit réalisé et qu'une fois les données collectées, les règles d'engagement soient ramenées à l'état initial. La illustre un exemple de système de composition de ressources. Pour une IPU, le système de composition de ressources 2300 peut permettre un fonctionnement sans affichage par l'intermédiaire d'une IPU (par exemple, ne nécessitant pas de CPU) pour lancer des opérations destinées au stockage, aux accélérateurs (comme par exemple la technologie Intel® QuickAssist (QAT) ou équivalente), aux GPU, aux XPU, aux mémoires mutualisées (desservant des homologues de centres de données par le biais d'un NIC classique ou d'un smart-NIC), ou à d'autres dispositifs. L'IPU peut envoyer des commandes à d'autres dispositifs pour le compte du locataire ou de la charge de travail au moyen de dispositifs locaux ou distants. Des fonctions de l'IPU telles qu'accélération, sécurité, télémétrie, etc. permettent de composer dynamiquement des systèmes construits à partir de CPU, d'XPU, de mémoire, de ressources de stockage, qui sont soit locales ou proches du nœud, soit distantes ou éloignées dans des nœuds distribués. Un nœud de mémoire mutualisée peut comprendre un ou plusieurs niveaux de mémoire. À titre d'exemple, plusieurs niveaux de mémoire ou de stockage peuvent comprendre un ou plusieurs des éléments suivants : cache (par exemple, cache L1, L2, L3, ou de niveau inférieur (LLC)), mémoire (par exemple, mémoire compatible JEDEC DDR ou mémoire compatible JEDEC HBM), mémoire persistante (par exemple, Intel® Optane® ou Samsung Z-NAND), stockage (par exemple, NAND ou 3D NAND), disques durs ou mémoire à 2 niveaux (2LM). Divers modes de réalisation peuvent utiliser au moins deux niveaux de mémoire (également appelés ici "2LM") qui comprennent des sous-ensembles mis en cache de stockage au niveau du disque système (par exemple, en plus des données d'exécution). L'hôte 1606 peut comprendre une mémoire principale qui comprend un premier niveau (également appelé ici "mémoire proche") comprenant une mémoire plus petite et plus rapide constituée par exemple de DRAM ou d'une autre mémoire volatile ; et un deuxième niveau (également appelé ici "mémoire éloignée") qui comprend une mémoire volatile plus grande et plus lente (par rapport à la mémoire proche) (par exemple, une DRAM) ou un stockage à mémoire non volatile (par exemple, une mémoire flash ou une mémoire non volatile adressable par octets (par exemple, Intel® Optane® ou Samsung Z-NAND)). La mémoire éloignée peut être présentée au système d'exploitation (OS) hôte comme étant une "mémoire principale", tandis que la mémoire proche est un cache pour la mémoire éloignée, qui est transparent pour l'OS, de sorte que les modes de réalisation décrits ci-après semblent identiques vis-à-vis des solutions de mémoire principale de l'art antérieur. La gestion de la mémoire à deux niveaux peut être effectuée par une combinaison de logique et de modules exécutés par l'intermédiaire de l'unité centrale de traitement (CPU) hôte. La mémoire proche peut être couplée à la CPU du système hôte par des moyens à large bande passante et à faible latence pour un traitement efficace. La mémoire éloignée peut être couplée à la CPU par l'intermédiaire de moyens à faible bande passante et à latence élevée (par comparaison à celle de la mémoire proche). Le système de composition de ressources 2300 peut délester des tâches depuis les xPU, CPU ou GPU vers l'IPU. Des plateformes spécialisées (par exemple, les accélérateurs ou les systèmes de stockage) qui n'ont pas de CPU ou de GPU ou qui n'ont pas suffisamment de ressources de CPU ou de GPU pour renforcer la capacité du centre de données, peuvent délester des tâches vers une IPU. Une application exécutée par CPU peut spécifier des configurations et laisser le reste du système (par exemple, l'IPU et ses entités désignées) gérer les tâches. Le système de composition de ressources 2300 peut permettre un fonctionnement sans affichage. Une IPU peut par exemple gérer des demandes (par exemple, sur la base d'un graphe de dépendance (A écrit avant B, et B écrit avant C, donc si A est reçu en premier, écrire A ou appliquer une validation atomique de A, B et C (tout ou rien)), en définissant l'ordre d'exécution de transactions de mémoire (lecture, lecture, écriture)) ainsi que le stockage de données. Une IPU peut gérer l'ordre des opérations à la place du logiciel déclencheur ayant émis les demandes dans l'ordre. Le système de composition de ressources 2300 peut communiquer avec un lecteur NVMe ou une mémoire persistante. À titre d'exemple, le système de composition de ressources 2300 peut traiter le stockage de blocs comme étant un débordement vis-à-vis la mémoire persistante. Le système de composition de ressources 2300 peut prendre en charge des communications compatibles NVMe-oF. Le système de composition de ressources 2300 peut stocker des données dans un dispositif compatible NVM et renvoyer un ACK, puis finalement écrire dans la mémoire persistante. Le système de composition de ressources 2300 peut faire en sorte qu'un dispositif compatible NVM joue le rôle de cache pour les opérations de lecture. Un dispositif compatible NVM connecté à une IPU peut prendre en charge des transactions de lecture. Une mémoire persistante sur matrice d'interconnexion (par exemple, une Mémoire Persistante sur Matrice d'Interconnexion (PMoF) ou une Mémoire Non Volatile sur Matrice d'Interconnexion (NVMoF) de la Storage Networking Industry Association (SNIA)) peut se connecter à une mémoire distante par l'intermédiaire d'un réseau ou d'une matrice d'interconnexion comme si elle était reliée localement. Le système de composition de ressources 2300 peut créer un nœud de stockage composite. La composition de ressources permet par exemple de fournir de la capacité à un demandeur mais à des fins de stockage éphémère et la composition de ressources permet de gérer l'engagement de stockage envers un demandeur. Le système de composition de ressources 2300 peut effectuer une désagrégation et une nano-composition, un équilibrage de charge, une mise à l'échelle, une migration d'activité et une gestion de puissance. Le système de composition de ressources 2300 peut effectuer des opérations intra-serveur du plan d'orchestration et de gestion. Le système de composition de ressources 2300 peut effectuer la composition de tranches d'XPU et le chaînage de services entre des XPU. Le système de composition de ressources 2300 peut effectuer une orchestration pour prélever des tranches de ressources disponibles dans une machine (par exemple, des tranches de cœurs, d'unités d'ombrage, de stockage et de mémoire). Le système de composition de ressources 2300 peut effectuer l'orchestration et la gestion de compositions de ressources inter-serveurs, par exemple, au-delà des frontières des serveurs (par exemple, entre des dispositifs A et B comportant au moins un NIC sur le trajet entre A et B). Une IPU peut partitionner une machine afin qu'elle soit utilisée par un microservice particulier. Une IPU peut démanteler des ressources après l'achèvement d'un microservice. Le système de composition de ressources 2300 peut partitionner des ressources de mémoire, de stockage et de réseau qui sont assemblées (composées) dans un conteneur/une instance de charge de travail, et désinitialiser de manière sécurisée et sûre des tranches ou des partitions récupérées à partir d'une charge de travail avant qu'elles ne soient provisionnées pour la composition suivante, une telle orchestration devant être hiérarchiquement stratifiée en-dessous d'un orchestrateur de niveau supérieur, par exemple Kubernetes (K8s), Docker Swarm, Openstack, etc., et être prise en charge par redirection des flux de provisionnement par un sous-système de gestion des ressources qui les alloue, initialise, connecte, désinitialise et désalloue dynamiquement. Une IPU peut par exemple exécuter un orchestrateur et une autre IPU peut allouer des ressources. Une IPU peut exécuter un hyperviseur, et l'hyperviseur enlever des parties passives de la plateforme pour les transformer en ressources. Une IPU peut être un homologue d'autres IPU. Le système de composition de ressources 2300 peut permettre à des ressources distantes d'apparaître comme locales vis-à-vis d'un déclencheur de service ou d'une IPU, et les IPU peuvent connecter une ressource distante en exposant la ressource distante en tant que service afin d'établir une connexion et de prendre en charge des opérations de QoS et de faible latence. Des interfaces de gestion en bande et hors bande 2302 peuvent fournir des interfaces de gestion en bande et hors bande pour des XPU et des services fonctionnant sur ces XPU, par le biais d'une traduction à base d'IPU. Des interfaces de gestion en bande et hors bande d'une IPU peuvent servir de calage pour chaque XPU vue de l'extérieur vers l'intérieur, et agir comme un calage de plateforme entre l'XPU et la plateforme réelle dans laquelle se trouve l'XPU vue de l'intérieur vers l'extérieur de chaque XPU. Ainsi, une IPU peut effectuer une gestion hors bande de la plateforme ou d'une XPU par le biais d'interfaces de gestion classiques qui sont souvent hors bande, mais fournir une interface de gestion en bande au demandeur comme si la gestion avait lieu en bande. Inversement, certaines opérations peuvent être mises en œuvre en bande lorsqu'elles sont déclenchées par un événement quelconque (par exemple, le redémarrage d'une machine virtuelle, d'un domaine de confiance ou d'une enclave à la suite de la détection d'une violation de sécurité), mais elles peuvent alors être spécifiées comme étant une action hors bande, ce qui a pour effet que la violation de sécurité fige la machine virtuelle, le domaine de confiance ou l'enclave, passe le contrôle à une IPU, l'IPU agissant maintenant comme un isolateur de machine virtuelle, de domaine de confiance ou d'enclave et l'examinant et simulant diverses actions sur celui-ci à des fins médico-légales et pour comprendre l'étendue de la violation (et prévenir tout effet secondaire négatif) avant de redémarrer finalement la machine virtuelle, le domaine de confiance ou l'enclave. Dans l'ordre dans lequel l'IPU fournit ces services à un TEE tel qu'un domaine de confiance ou une enclave, les mesures de l'IPU doivent être vérifiées par le TEE pour que l'IPU (et ses services sélectionnés) soit acceptée dans la TCB du TEE. Une fois l'IPU acceptée dans la TCB, elle peut fournir des services en bande au TEE. Lorsque le client l'autorise, les IPU peuvent fournir une télémétrie pour des hôtes de type bare metal en accédant à l'état sans perturber les applications en cours d'exécution. Lorsqu'un nouveau dispositif est embarqué (branchement à chaud), la prise en charge de l'échange à chaud et du branchement à chaud 2304 peut mettre un terme aux étapes d'attestation et de configuration pour ce dispositif, et l'intégrer dans la plateforme par exécution de protocoles d'homologue à homologue avec d'autres agents et services IPU, de manière transparente pour le reste de la plateforme. De manière générale, il n'est pas nécessaire de redémarrer la plateforme pour que l'intégration en ligne fonctionne. Pour la mise hors carte ou la mise hors ligne d'un dispositif existant, les ressources du dispositif peuvent être libérées par le logiciel et, tant que cela est possible, le reste du processus de mise hors carte, notamment la désinitialisation sûre et sécurisée de secrets, de clés et de données sensibles, peut être effectué par une IPU. Le système de prise en charge de l'échange à chaud et du branchement à chaud 2304 peut servir d'entité de gestion de dispositifs pour la plateforme et assurer une isolation de sécurité en déplaçant le logiciel de gestion hors de la CPU hôte multi-locataires moins sécurisée. Cette architecture fonctionne également pour des plateformes sans affichage. Un agrégateur de ressources 2306 peut mettre en œuvre le Protocole de Gestion de Réseau Simple (SNMP), l'Interface de Gestion de Plateforme Intelligente (IPMI), RedFish, SwordFish, et des mécanismes déclaratifs RESTful plus récents (issus de la Distributed Management Task Force (DMTF), de l'Open Compute Project (OCP), et d'autres communautés) à travers la matrice d'interconnexion d'IPU pour des nano-compositions agiles de ressources assemblées à partir de différentes XPU, partitions de mémoire et de stockage, et cartes NIC, avec allocation et désallocation rapides. Une émulation de la gestion de plateforme bare metal virtuelle pour des multi-locataires peut être effectuée. Une IPU peut composer des tranches de ressources au niveau de chaque XPU, et le faire par petites unités et au cours du temps avec une granularité fine. Une fédération de responsabilités parmi les éléments d'IPU qui relient les XPU à d'autres XPU peut être formée pour allouer des ressources. Un allocateur de puissance 2308 peut coordonner des locataires ou des services d'allocation de puissance de plateforme à grain fin pour allouer de la puissance au moins sur la base de la priorité du locataire ou du service. À titre d'exemple, un microservice prioritaire fonctionnant sur des XPU1 et XPU2 reçoit des augmentations de fréquence coordonnées sur XPU1 et XPU2, tandis qu'un microservice de meilleur effort (priorité inférieure) fonctionnant sur XPU1 ou XPU2 peut se voir attribuer moins de puissance. Une telle coordination peut faire appel à un engagement simultané d'une politique sur plusieurs XPU et ne peut pas être effectuée par simple coordination entre des exécutables logiciels sur les différentes XPU, sauf à une échelle de temps très grossière (cela nécessitant de plus une prise en charge de la planification de groupe dans des planificateurs). Divers modes de réalisation d'un allocateur de puissance sur une IPU permettent une allocation de puissance à une échelle temporelle fine. Un allocateur de qualité de service (QoS) 2310 peut allouer des contrôles de QoS / accord de niveau de service (SLA) en boucle fermée et ouverte couvrant plusieurs ressources, par utilisation d'un jeu de fonctions de satisfaction fournies (codées) dans les IPU. En tant que point de contrôle local, l'allocateur de QoS 2310 peut assurer des temps de réponse plus rapides pour la surveillance et l'ajustement de paramètres de QoS ou de SLA, évitant ainsi des oscillations qui peuvent conduire à un système instable. Au lieu d'une méthode fixe pour réaliser un contrôle de QoS en boucle fermée, les politiques, les itérations, les mécanismes d'essai et d'erreur peuvent être codifiés dans l'allocateur de QoS 2310, de sorte que les IPU peuvent collaborer pour atteindre des équilibres stables lors de l'allocation de différentes ressources d'XPU entre différents microservices. À titre d'exemple, des fonctions de satisfaction (équations) peuvent définir différentes allocations possibles de ressources par lesquelles chaque microservice peut atteindre un équilibre souhaité entre une fonction de coût et une fonction de récompense (par exemple, un service A peut utiliser 4 cœurs Xeon et 12 UE sur une GPU, ou peut utiliser 2 cœurs Xeon et 18 UE, ou peut utiliser seulement 1 cœur Xeon et 28 UE pour un bon compromis entre coût (latence) et performances. Un service B peut se voir attribuer 6 cœurs Xeon et 13 UE, ou 8 cœurs Xeon et 21 unités d'exécution (UE), etc. L'allocateur de QoS 2310 peut itérer une fonction de satisfiabilité sur différentes configurations possibles pour trouver le meilleur compromis pour chaque service et entre services en pondérant leurs facteurs de mérite normalisés. Des statistiques d'utilisation et de performances et des échantillons de latence provenant des applications et des XPU sont également pris en compte dans tout cela. Un dispositif de mise à l'échelle des ressources 2312 peut effectuer une mise à l'échelle automatique de composants matériels et de capacités d'infrastructure, par exemple en mettant en ligne une capacité de calcul ou de stockage réservée à partir de partitions locales ou distantes, ou en mettant en réserve une capacité inutilisée et en la rendant ainsi disponible pour une consommation à distance. Dans certains modes de réalisation, une ou plusieurs de ces opérations peuvent être mises en œuvre sur la base de modèles d'AI dérivés d'un apprentissage automatique. Des IPU peuvent mettre en œuvre et former des modèles d'AI pour de telles opérations. Le dispositif de mise à l'échelle de ressources 2312 peut permettre à l'IPU de prendre des décisions locales rapides sur l'allocation et l'utilisation de ressources prédéfinies (par exemple, CPU, stockage, mémoire, XPU) afin de fournir une réponse plus rapide au traitement de défaillances ou de changements dynamiques d'exigences en matière de ressources. Une prise de décision locale peut également permettre une meilleure capacité de survie en cas de défaillance catastrophique du Plan de Commande principal, par exemple en cas de panne du Plan de Commande ou de perte de connectivité avec le Plan de Données. Dans de tels cas, le plan de commande local sur l'IPU peut gérer et poursuivre le fonctionnement jusqu'à la correction du défaut. Dans le cadre de la composition du système entre différents XPU, CPU, mémoires, stockages et services, l'IPU peut faciliter la coordination entre ces ressources. Dans certains exemples, une IPU (par exemple, le gestionnaire d'exécution 2124) peut gérer le traçage d'un flux d'appels, la corrélation d'événements pour détecter des événements de sécurité, etc. L'IPU peut également être utilisée en tant que partie active du flux de données pour gérer les dépendances de données et le débogage. Des exemples d'intervention de l'IPU peuvent comprendre des clôtures ou des barrières pour le débogage ou la modification dynamique des données pour la séquence de traitement, une fonction centralisée telle que l'élection d'un meneur, la réplication des demandes ou des données pour le débogage ou la journalisation de la conformité qui peut être insérée dans le flux de données sans avoir d'impact sur les applications finales. La illustre un exemple de la manière dont une IPU peut coordonner l'utilisation de diverses ressources. En 2350, une IPU peut capturer divers événements liés à la sécurité et à la résilience ou des événements d'extrêmes de performances de n'importe quelle XPU. Les événements liés à la sécurité et à la résilience peuvent par exemple comprendre des baisses de tension, un taux de correction d'erreurs mémoire trop élevé (par exemple, un taux supérieur à un seuil), des événements thermiques (par exemple, une température d'un dispositif ou d'un composant dépassant un seuil), la détection d'une intrusion physique du SoC (par exemple, au niveau d'un capteur), la détection de vibrations, etc. Les événements d'extrêmes de performances peuvent comprendre la perte de signaux de battement de cœur de certaines XPU, des dépassements de temps signalés par le matériel (par exemple, en raison de la congestion ou de la perte d'un événement d'éveil après une opération I/O bloquante), etc. Dans certains cas, la télémétrie de l'unité de gestion des performances (PMU) peut être recueillie par un logiciel tel que perf, emon, vtune, etc., et par filtrage de la télémétrie de la PMU, un logiciel peut détecter un nombre anormal d'événements inattendus (par exemple, des augmentations de plusieurs ordres de grandeur des erreurs de vérification de la machine, des événements de dépassement de capacité en virgule flottante, etc.). Dans d'autres cas, des capteurs peuvent détecter des déclenchements thermiques, des chutes de tension, des erreurs de mémoire excessives, des erreurs de disque excessives, une intégrité des données réseau dépassant des seuils acceptés, des expirations de temporisations de battements de cœur (par exemple, aucun signal de battement de cœur reçu avant l'expiration d'une temporisation), etc. De tels événements peuvent survenir sur n'importe quel composant système d'un nœud composite, et peuvent survenir sans être causés par un microservice particulier, mais peuvent affecter d'autres microservices qui peuvent s'exécuter sur divers nœuds composites qui partagent ce composant. Toutefois, il est également possible qu'une XPU particulière, telle qu'un FPGA, signale des signaux anormaux pendant que ce FPGA exécute une fonction dans le contexte d'un microservice, et que l'erreur ou l'anomalie puisse seulement provoquer un arrêt, un plantage ou un autre dysfonctionnement de ce microservice. Cependant, du fait d'une réaction en chaîne, d'autres microservices avec lesquels le microservice affecté interagit peuvent commencer à subir une baisse de performances, des réponses incorrectes de la part du microservice affecté, etc. En 2352, l'IPU peut déterminer s'il faut émettre une commande de barrière à l'échelle du système sur la base d'une configuration à exécuter en réponse à des erreurs ou des anomalies d'un type particulier. À titre d'exemple, une configuration et les actions à effectuer peuvent être déterminées par l'exécution d'un programme de commande sur une IPU. Le programme de commande peut être téléchargé sur l'IPU au démarrage du système, et révisé ou mis à jour par la suite, de concert avec un service de gestion de fiabilité de l'IPU en nuage ou par un utilitaire de console dans un mode spécial. Le programme de commande exécuté par l'IPU peut être conçu pour décider d'émettre une barrière à l'échelle du système à une ou plusieurs conditions, comme la détection d'une corruption dans une région critique de la mémoire appartenant au superviseur ou d'autres événements d'extrêmes de performances. Le programme de commande peut déterminer de ne pas émettre une barrière à l'échelle du système pour une ou plusieurs conditions qui ne sont pas considérées comme importantes, telles qu'un paquet réseau mal formé découvert (et abandonné), un signal de relance provenant d'un dispositif de stockage, moins d'un nombre seuil d'erreurs ou d'événements d'extrêmes de performances détectés, etc. Si l'IPU décide d'émettre une barrière à l'échelle du système, le processus peut passer à 2360. Si l'IPU ne détermine pas qu'il faut émettre une barrière à l'échelle du système, le processus peut passer à 2370. En 2360, l'IPU peut exécuter un protocole de barrière sur des XPU ou des IPU qui fournissent des ressources en tant que nœud composite. Un nœud composite peut comprendre au moins une ressource d'au moins une XPU qui est affectée par une anomalie détectée. À titre d'exemple, si une corruption de la mémoire est détectée à une certaine adresse physique P dans la mémoire, et si cette plage de mémoire est actuellement placée dans un nœud composite C, et que le nœud composite C possède diverses tranches (par exemple, un certain nombre de cœurs de CPU ou de GPU, certaines partitions dans un FPGA, etc.) de diverses XPU X1, X2 et X3, alors toutes ces XPU peuvent passer en mode barrière. Pour chacune de ces XPU, l'IPU peut émettre une notification de barrière. Une XPU peut observer et répondre à la notification de barrière en passant en mode suspendu mais en restant active, dans un mode appelé mode de veille, pour passer dans un mode de consommation réduite et suspendre les opérations concernant le nœud composite. L'XPU peut envoyer un accusé de réception à l'IPU, indiquant que le mode de veille a été activé. La barrière peut être mise en œuvre lorsque toutes les XPU ont répondu à l'IPU par un accusé de réception indiquant le passage en mode de veille active. Lorsque cette situation est atteinte (par exemple, toutes les XPU d'un nœud composite sont en mode barrière et en attente en mode de veille active), le programme de commande de l'IPU passe en 2362 dans un mode appelé mode dirigé. En 2362, le programme de commande d'IPU fonctionne sous la direction d'un utilitaire de console ou d'un service gestionnaire de nuage. En mode dirigé, l'IPU et toutes les XPU que l'IPU a fait passer en mode de veille active fonctionnent sous la direction d'un utilitaire de console ou d'un service de plateforme de gestion de nuage (CMP). À un moment ultérieur, l'utilitaire de console ou le service CMP peut émettre une libération, et cette libération peut permettre à l'IPU et aux XPU de sortir du mode de veille active et d'exécuter tous les microservices non migrés non achevés mais reçus avant le passage en mode barrière. Dans certaines circonstances, lorsque le service CMP ou un utilitaire de console ne répond pas (ou que la communication avec eux s'avère ne pas répondre), le programme de commande de l'IPU peut expirer et déclencher un redémarrage du système et un nouveau test afin que l'IPU et les XPU puissent effectuer toutes les actions de réparation qu'ils sont capables d'effectuer sous le contrôle de leur logiciel de supervision (tel qu'un système d'exploitation stocké dans une partition de récupération). Dans certaines circonstances, l'IPU établit une communication avec un utilitaire de console ou un service CMP, puis exécute diverses opérations selon les instructions de l'utilitaire de console ou du service CMP. Les XPU du nœud composite qui ont été mises en mode de veille active au début de l'exécution en mode dirigé de l'IPU peuvent recevoir des commandes de l'IPU, par exemple sous la forme de divers signaux matériels, de paquets de réseau, ou de communication à base de mémoire. Lorsque les XPU reçoivent les commandes, elles peuvent les exécuter, puis repasser en mode de veille active. En conséquence, l'IPU et les unités XPU avec lesquelles elle est couplée par voie de communication, s'exécutent selon une progression synchrone pour exécuter les actions demandées par l'utilitaire de console et/ou le service CMP. Si l'IPU détermine qu'il ne faut pas émettre de barrière à l'échelle du système, le processus passe à 2370. En 2370, l'IPU capture des données d'événements, marque les données d'événements d'un horodatage et transmet les données d'événements à un service de gestion de nuage désigné. Dans certains exemples, l'IPU enregistre les informations dans un dispositif/service de journalisation désigné. En 2372, le service CMP peut traiter les données d'événements et déterminer s'il faut demander à l'IPU d'exécuter un protocole de barrière. Le service CMP peut déterminer d'exécuter un protocole de barrière s'il détermine, à partir de l'analyse des données d'événements provenant de 2370, que le nœud composite indiqué dans les événements a rencontré une situation de haute gravité. Dans un tel cas, le service CMP peut être programmé pour faire passer l'IPU en exécution dirigée afin que le service CMP puisse réparer le nœud composite, arrêter l'exécution du nœud composite, ou déclencher une évacuation contrôlée (migration) de divers microservices et données depuis le nœud composite affecté vers un autre nœud ou un nœud composite fonctionnant correctement. Dans d'autres cas, le service CMP peut déterminer, à partir d'un examen des données d'événements provenant de 2370, que les données indiquent une occurrence sans gravité, mais très rare et intéressante à étudier en détail. Dans ce cas, le service CMP peut faire en sorte que l'IPU provoque un état de barrière afin que des données supplémentaires d'intérêt médico-légal puissent être recueillies en provenance du nœud composite avant que ces données ne soient obscurcies par la poursuite de l'exécution du nœud composite. En variante, le service CMP peut décider de ne pas exécuter de protocole barrière si les données d'événements issues de 2370 ne justifient pas, après analyse, le retard et la perte de performances liés à l'imposition d'une barrière aux dispositifs du nœud composite. À titre d'exemple, l'analyse des journaux provenant de l'étape 2370 peut indiquer une tentative non malveillante d'effectuer une opération interdite, telle qu'un programme canary de sécurité qui tente de rechercher des vulnérabilités de sécurité. Lorsque le service CMP détermine de ne pas exécuter de protocole barrière, l'exécution normale se poursuit, d'où il résulte que l'IPU n'impose pas de barrière, pas plus que le service CMP, de sorte que les événements collectés en 2370 peuvent être stockés ou rejetés en fonction de leur importance statistique telle que déterminée par le service CMP. Connexion entre IPU-IPU ou IPU-interface réseau Divers modes de réalisation permettent à un agent présent sur une CPU, une XPU ou un contrôleur SmartNIC d'un nœud, au moyen d'une IPU, d'appeler ou d'envoyer un message à tout agent présent sur une CPU, une XPU ou un SmartNIC d'un autre nœud, d'homologue à homologue. Divers modes de réalisation des IPU fournissent un accès cohérent entre la CPU, l'XPU, le stockage, et la mémoire locaux, et la CPU, l'XPU, le stockage, la mémoire distants. L'accélération de la connectivité à distance permet de minimiser la latence ou la gigue et d'améliorer la fiabilité pour fournir une expérience quasi-locale. Des files d'attente sécurisées et des tunnels sécurisés peuvent être utilisés pour fournir une communication connectée à une IPU. Divers modes de réalisation fournissent une architecture de messagerie asynchrone entre les dispositifs, qui crée un plan de commande de bout en bout. Une IPU peut coordonner la messagerie pour permettre à des services de bout en bout de négocier la qualité de service (QoS), de délivrer des informations concernant l'utilisation des ressources, etc. Une IPU peut assurer la QoS et la sécurité pour la prise en charge de plusieurs locataires au moyen de ressources partagées. Une IPU peut permettre à d'autres éléments (par exemple, un équilibreur de charge) de mieux optimiser la répartition des tâches. À titre d'exemple, dans une chaîne de services impliquant une capture vidéo par une caméra vidéo, un compression vidéo et un stockage vidéo, une IPU peut permettre un accès direct au calcul, à la mémoire, au stockage, aux XPU par un autre dispositif via une autre IPU. L'IPU peut comporter un gestionnaire de file d'attente matériel (HQM) et des instructions spéciales (par exemple, des instructions qui ciblent les files d'attente) peuvent autoriser de tels flux de bout en bout. Des IPU peuvent également mettre en œuvre une couche intelligente au-dessus des NIC classiques, notamment le délestage de commutateurs vSwitch et le traitement de paquets. Un pontage du trajet de données et une virtualisation de dispositifs peuvent être réalisés entre des XPU (par exemple, des XPU peuvent comprendre des CPU) qui utilisent une IPU pour communiquer avec des SmartNIC ou des NIC classiques. Un pontage des trajets de données peut être assuré entre une mémoire/un stockage qui utilisent une IPU pour communiquer avec un autre NIC. Les XPU peuvent accéder aux données par le biais du domaine de mémoire et l'IPU établit un pont entre le domaine de mémoire et le domaine de mémoire distant. Lorsque l'XPU accède à un domaine de mémoire, elle peut également accéder à une mémoire distante comme s'il s'agissait d'une mémoire locale. La illustre un exemple d'allocation de ressources par une IPU au moyen de ressources présentes dans une IPU et de ressources présentes dans d'autres IPU et nœuds. Dans cet exemple, des ressources sont allouées à la charge de travail 0 dans l'IPU 0, le NŒUD 0, l'IPU 1, le NŒUD 1, l'IPU 3 et le NŒUD 3 mais pas dans l'IPU 2 ou le NŒUD 2. Dans cet exemple, des ressources sont allouées à la charge de travail 1 dans l'IPU 0, le NŒUD 0, l'IPU 1, le NŒUD 1, l'IPU 2, le NŒUD 2, l'IPU 3 et le NŒUD 3. Dans cet exemple, les ressources allouées à une utilisation par la charge de travail 0 sont partitionnées pour ne pas partager la mémoire ou l'espace de cache avec une autre charge de travail. Des ressources allouées pour une utilisation peuvent être attestées par exemple par l'IPU 0 de sorte que dans une opération de chaîne de services, après qu'un dispositif a terminé de traiter une donnée, le dispositif peut fournir cette donnée en vue de son transfert par l'intermédiaire d'une IPU à un dispositif suivant qui doit traiter la donnée. Dans l'exemple de la , en (1), une charge de travail 0 s'exécutant sur une CPU du NŒUD 0 émet un appel API à un gestionnaire de ressources (accélérateur) de l'IPU 0 pour appeler le fonctionnement d'une chaîne de fonctions de service de microservices. En (2), un accélérateur de l'IPU 0 peut exécuter un microservice d'attestation de ressources et d'autres IPU comme décrit ici pour le microservice 0. En (3), l'interface réseau de l'IPU 0 peut envoyer une demande à l'IPU 1 pour exécuter un microservice d'accès à un accélérateur accessible dans l'IPU 1. En (4), l'accélérateur peut exécuter un microservice de traitement de données (par exemple, un traitement cryptographique ou de paquets) et en (5), exécuter un microservice de stockage de données dans un dispositif de stockage du NŒUD 1. Des microservices peuvent accéder à des données sans demander à un intermédiaire de délivrer une permission ou une attestation de la CPU. En (1), une charge de travail 1 s'exécutant sur une CPU du NŒUD 0 envoie un appel API à un gestionnaire de ressources (accélérateur) de l'IPU 0 pour appeler le fonctionnement d'une chaîne de fonctions de service de microservices. En (2), une interface réseau de l'IPU 0 peut envoyer une demande à l'IPU 2 pour exécuter un microservice d'accès à un accélérateur accessible dans l'IPU 2. En (3), l'interface réseau de l'IPU 2 reçoit la demande de microservice et en (4), l'IPU envoie une demande à l'accélérateur pour effectuer le traitement associé au microservice (par exemple, une compression ou un traitement vidéo). En (5) et (6), l'interface réseau de l'IPU 2 peut envoyer les données à l'interface réseau de l'IPU 3. En (7), l'IPU 3 peut exécuter un microservice de stockage de données (par exemple, la journalisation des résultats ou la vidéo source à des fins de conformité) dans un dispositif de mémoire du NŒUD 3. Des microservices sécurisés peuvent accéder à des données sans demander à un intermédiaire d'en fournir la permission. Se référant à nouveau à la , des accélérateurs 1916 peuvent effectuer une ou plusieurs des opérations range, RegEX et HALO (voir par exemple Y. Yuan, Y. Wang, R. Wang, et J. Huang, "HALO : Accelerating flow classification for scalable packet processing in NFV," in Proceedings of the 46th IEEE/ACM International Symposium on Computer Architecture (ISCA'19), Phœnix, AZ, Juin 2019) au niveau de l'IPU, pour permettre une substitution flexible au sein des RegEx - substitution de variables, de pointeurs, etc., afin que les IPU puissent être des éléments de routage/commutation et de filtrage de trafic polyvalents à états et dynamiques. La capacité regex peut être utilisée pour l'Inspection Approfondie des Paquets (DPI), la Recherche d'Objets de Métadonnées, la politique HTTP et peut être combinée à HALO, avec évaluation générale des conditions au travers du mécanisme d'indirection de HALO. HALO peut être utilisé au moins pour la recherche de clés-valeurs (par exemple, range, m-trie) et la recherche/la consultation chaînée. Bien que tout cela puisse être réalisé dans un logiciel exécuté par un processeur au niveau d'une IPU, l'utilisation de l'accélération matérielle au sein d'une IPU permet d'effectuer une évaluation complexe des conditions à un débit élevé dans le flux de données entre les XPU, et entre les XPU et les NIC classiques/intelligents. Les accélérateurs peuvent analyser, rechercher et transformer des données structurées telles que des objets de stockage, des métadonnées, des valeurs de paramètres RPC/API, des mémoires de clés-valeurs. Gestionnaire d'horodatage Se référant à la , un gestionnaire d'horodatage 1910 peut exécuter diverses fonctions décrites ici. Des microservices peuvent interagir les uns avec les autres par le biais d'appels/messages RPC, API ou d'appels de procédure à distance de Google (gRPC), de sorte que si les messages sont traités par chaque appelé dans un ordre temporel virtuel, les mises à jour sont journalisées de manière distribuée dans un ordre temporel logique et de façon sérialisable. La Surveillance, le Traçage et le Débogage peuvent fournir un Réseau Intégré Sensible au Temps (TSN) / un Calcul Coordonné dans le Temps (TCC) avec des horodatages coordonnés à haute résolution pour les messages entre microservices, que ces microservices soient exécutés dans une même XPU, dans différentes XPU d'un même nœud, ou entre des nœuds. Les horodatages peuvent être automatiquement hachés par rapport aux ID des messages gRPC dans une réserve d'horodatage et signés par des signatures d'IPU pour permettre un ordre sécurisé et granulaire fin entre les invocations et les transferts de données à base de gRPC. Ainsi, une atomicité des transactions distribuées sans verrouillage peut être obtenue par une mise à jour coordonnée et sérialisée des horodatages de l'état aux limites transactionnelles. Une journalisation précise des événements peut permettre une corrélation des événements distribués qui peut être utilisée pour la détection d'intrusions, pour les défaillances de comportement des applications, pour la charge système, etc. Le gestionnaire d'horodatage 1910 peut obtenir et maintenir des statistiques corrélées avec le temps et les événements sur des défauts et des erreurs matérielles et logicielles, et permettre un traitement de mise en service de modèles statistiques distribués afin de prédire les défauts, les défaillances et les événements de performances de haute gravité comme par exemple une croissance du nombre de relances. Divers modes de réalisation permettent une intégration continue et une livraison continue (CI/CD) à une échelle suffisante, couvrant à la fois le matériel et le logiciel. Des politiques intégrées aux IPU peuvent permettre des réparations prédictives ou des arrêts et redémarrages progressifs proactifs, ainsi qu'une régulation anticipée de la vitesse afin de prolonger le temps moyen entre défaillances (MTBF) ; elles permettent également une migration proactive des services essentiels vers des unités homologues. Mémoire et stockage Se référant à la , l'IPU peut fournir un contrôleur de mémoire et de stockage 1912. Le contrôleur de mémoire et de stockage 1912 peut émuler un dispositif de stockage hybride, par exemple en générant des communications cohérentes avec la mise en cache NVMe-oF et la mémoire non volatile sur matrices d'interconnexion (NVM-oF). En outre, le contrôleur de mémoire et de stockage 1912 peut prendre en charge une émulation d'un niveau logique de haute capacité NVM-oF, et assurer cette prise en charge en plus d'une quantité limitée de NVM locale (ou d'une petite quantité de NVDIMM locale de commodité) pour la mise en tampon de données en transit vers un stockage ou une mémoire distante). Une mémoire DDR volatile locale peut être utilisée pour émuler une mémoire NVM de haute capacité en effectuant une mise en cache locale en lecture seule avec écriture immédiate en mémoire distante par RDMA ou RDMA virtuel. Cette émulation hybride avec mise en cache locale peut également s'appliquer à l'émulation de DDR/mémoire distante. Le contrôleur de mémoire et de stockage 1912 peut assurer un contrôle de simultanéité multi-versions à partir de bases de données pour gérer des demandes portant sur une copie versionnée des données et pas seulement la dernière version. Le contrôleur de mémoire et de stockage 1912 peut agir en tant que contrôleur de stockage et prendre en charge le contrôle de simultanéité multi-versions ou de cohérence relâchée. Le contrôleur de mémoire et de stockage 1912 peut prendre en charge le RDMA ou le RDMA virtuel, auquel cas une IPU peut apparaître comme étant une mémoire ou un dispositif de stockage local ou générer une transaction à distance vers une mémoire ou un dispositif de stockage distant. L'IPU peut par exemple apparaître comme représentant 2 POctets de mémoire et créer un nœud composite et des accès par RDMA. Le contrôleur de mémoire et de stockage 1912 peut effectuer l'envoi en arrière-plan de journaux d'écriture anticipée (WAL), et le rendu WAL en arrière-plan sur des homologues distants par l'intermédiaire d'un moteur d'état à base d'IPU permettant des sauvegardes à chaud actives-actives peu coûteuses et un redémarrage et une récupération autonomes par reproduction transparente de la queue du journal WAL. Le journal WAL peut être récupéré sur une IPU en modifiant très peu le logiciel. Le logiciel pourrait écrire en utilisant une bibliothèque enveloppante pour les chargements et les enregistrements, lesquels sont interceptés par une bibliothèque à laquelle le logiciel est indifférent, et cette bibliothèque peut construire le journal WAL et l'envoyer à un nœud homologue actif-actif par l'intermédiaire d'une IPU. L'IPU peut empaqueter et expédier des segments de journaux entre nœuds, idéalement par le biais d'un canal virtuel réservé à haute priorité. Lors d'une défaillance ou d'un redémarrage, la dernière mise à jour du journal WAL est obtenue d'un homologue en veille active et appliquée de manière transparente afin de permettre une récupération et un redémarrage rapides. Le logiciel d'application peut fournir des marqueurs de fin de transaction, ou un marqueur de fin de multi-transactions, de sorte que l'IPU peut efficacement effectuer un rendu atomique jusqu'au dernier marqueur. Le contrôleur de mémoire et de stockage 1912 permet de fournir une PMoF (Persistent Memory over Fabric)/ NVMe-oF avec fermeture transactionnelle par écriture immédiate dans des partitions NVM du système, avec ou sans Intel® Data Direct I/O (DDIO), ce qui permet la copie d'un NIC vers un cache sans avoir à copier d'abord les données en mémoire puis dans un cache. Le contrôleur de mémoire et de stockage 1912 peut gérer des dispositifs rattachés, par exemple en effectuant un partitionnement, une virtualisation, un chiffrement, une compression et des services tels qu'une authentification d'accès, une gestion de clés et un traitement calculatoire (logiciel ou matériel). La illustre divers modes de réalisation d'un système. À titre d'exemple, un serveur de calcul comportant des CPU et un NIC peut être couplé par voie de communication à (A) un serveur de stockage doté d'une CPU et d'un ou plusieurs lecteurs à semi-conducteurs (SSD) par l'intermédiaire d'un NIC et (B) à un nœud d'apprentissage automatique comportant une CPU et une ou plusieurs GPU par l'intermédiaire d'un NIC. Dans le mode de réalisation 2504, des unités de traitement d'infrastructure (IPU) peuvent assurer une certaine interconnectivité entre un serveur de calcul, un système de stockage calculatoire, un nœud d'apprentissage automatique, un serveur d'inférence, un serveur à processeur flexible ou un nœud multi-accélérateurs. La illustre un exemple de système qui représente le rééquilibrage de points de contrôle de sécurité vers les IPU à partir des CPU pour gérer l'exécution de la charge de travail par les fournisseurs de services en nuage (CSP). Divers éléments de l'IPU illustrée à la peuvent être utilisés pour fournir des points de contrôle de sécurité tels que le gestionnaire de ressources sécurisé et la racine de confiance de sécurité. La illustre un exemple de système. Divers modes de réalisation d'une IPU peuvent mettre en œuvre un maillage de services, TCP, QUIC, une pile de transport fiable et un commutateur virtuel (par exemple, Open vSwitch) à la place d'une CPU d'un système hôte. L'IPU peut gérer des flux de données afin de réduire les opérations de copie de données. La illustre un exemple de système doté d'une télémétrie de bout en bout. Un identifiant unique peut être prévu pour un microservice. L'utilisation de l'identifiant (par exemple, un UUID) par des IPU peut permettre de suivre la chronologie d'une exécution et d'un achèvement sur différents composants, plateformes, microservices, etc. pour permettre le suivi et l'attestation des performances dans certains exemples. Un suivi des performances peut être utilisé pour modifier l'allocation de ressources à un service, par exemple en fournissant des ressources supplémentaires ou différentes pour l'exécution d'un service si le service fonctionne trop lentement à un moment donné. La illustre un exemple d'utilisation du système pour l'exécution d'une charge de travail sur plusieurs systèmes. Un UUID peut être utilisé pour identifier les microservices. La illustre un exemple d'utilisation de la télémétrie pour gérer l'exécution de charges de travail. En (1), un agent d'orchestration 2800 s'exécutant sur une IPU peut recevoir un paquet de charge de travail qui identifie un ou plusieurs microservices (uServices) ayant un ensemble d'exigences de QoS et d'exigences matérielles. En (2), l'agent d'orchestration 2800 peut analyser la demande et déterminer quelles ressources sont nécessaires pour exécuter les services et ses uServices associés. L'agent orchestrateur 2800 peut attribuer un identifiant universellement unique (UUID), un Identifiant de Gestionnaire de Ressources (RMID), un identifiant de qualité de service (QoSID) et un Identifiant d'Espace d'Adresses de Processus (PASID) pour le traçage de chaque microservice. En (3), la charge de travail est partitionnée et envoyée, en (4), à des Agents d'Orchestration 2802-0 à 2802-2 recevant le uService et les identifiants associés. En (4), les Agents d'Orchestration 2802-0 à 2802-2 fournissent les identifiants aux entités qui participent à l'exécution du service avant ou pendant l'exécution du uService. Un PASID peut par exemple être configuré dans une unité de gestion de mémoire (MMU) et une unité de gestion de mémoire d'entrée-sortie (IOMMU) et un accélérateur, le RMID peut être configuré dans une CPU rattachée et l'UUID peut être configuré par exemple dans un maillage de services. L'UUID peut également être attribué localement et basé sur un protocole ou un schéma commun compris par les entités présentes dans le flux de données. Au sein d'un système donné, il peut y avoir un ou plusieurs agents qui interagissent pour garantir que le service puisse être exécuté. L'IPU peut faire en sorte que l'Agent d'Orchestration principal communique avec des Agents locaux satellites et fournisse la charge de travail à exécuter et les identifiants appropriés. La illustre un exemple d'utilisation d'une IPU demandant l'exécution d'une charge de travail par une CPU. En (1), un Agent d'Orchestration s'exécutant sur une IPU peut décoder un progiciel de charge de travail. En (2), l'Agent d'Orchestration peut décomposer la demande et en (3) configurer les ressources locales avec des identifiants (par exemple, un Réseau Virtuel). En outre, l'Agent d'Orchestration peut envoyer, en (4), l'UUID, le PASID, le QoSID et le RMID ainsi que le code (ou le pointeur vers le code) du microservice (uService) à traiter à l'Agent d'Orchestration de CPU en (5). En (6), l'agent d'orchestration de CPU peut configurer la MMU et l'IOMMU avec le PASID et, en (7), configurer le conteneur en lui attribuant l'UUID. En (8), l'Agent d'Orchestration de l'unité centrale peut transmettre la poignée au planificateur avec des identifiants ContainerID, RMID et QoSID. En (9), un uService peut être exécuté par la CPU avec les paramètres de planificateur RMID et QoSID en tant que partie du changement de contexte afin d'exécuter le code. Se référant à la , en (10), des Agents de Télémétrie (dans chaque unité d'exécution) peuvent collecter des données de performances au fur et à mesure que le code s'exécute et circule à travers la CPU et les éventuels dispositifs rattachés (par exemple, une IPU). En (11), les données de télémétrie peuvent être rapportées au serveur central de télémétrie. En (12), l'orchestrateur et en (13) d'autres dispositifs peuvent exploiter la télémétrie pour s'assurer que le SLA est respecté et signaler les éventuelles dérives. L'Agent Orchestrateur de l'IPU peut utiliser des données pour s'assurer que les services sont correctement équilibrés en charge dans le système et effectuer des ajustements sur les ressources utilisées pour exécuter des services si les SLA ne sont pas respectés. La illustre un exemple de système connecté à l'aide d'un commutateur configurable 2900. Des IPU peuvent par exemple être couplées par voie de communication à l'aide d'un commutateur programmable Tofino de Barefoot Networks. Le commutateur Tofino peut fournir des informations de télémétrie supplémentaires à l'IPU. Il peut s'agir d'informations relatives à l'utilisation du réseau/multimédia, à la congestion, aux pertes de paquets et à la latence. Ces informations peuvent être utilisées par l'IPU pour ajuster l'équilibrage de charge, le rattachement de services et des demandes de ressources supplémentaires. Cette possibilité peut également permettre à l'opérateur de réseau de disposer d'informations détaillées sur les services et les applications qui sont touchés par les défaillances de service, telles qu'une défaillance de liaison. Une configuration du fonctionnement d'une IPU ou d'un commutateur 2900, notamment de son plan de données, peut être programmée en utilisant les langages P4, C, Python, le langage de programmation Broadcom Network Programming Language (NPL), ou des binaires exécutables compatibles x86 ou d'autres binaires exécutables. Une programmation de consultation par hachage peut avoir lieu pour programmer le réacheminement de paquets par un plan de données du commutateur 2900. À titre d'exemple, on peut utiliser des tables ou des circuits de concordance entre actions par lesquels un hachage d'une partie d'un paquet est utilisé comme index pour trouver une entrée. Le commutateur 2900 ou une IPU peut en outre effectuer une réplication de paquets pour le réacheminement d'un paquet ou d'une trame vers de multiples ports et la mise en file d'attente de paquets ou de trames avant leur transfert vers un port de sortie. La configuration du fonctionnement du commutateur 2900 ou d'une IPU, notamment de son plan de données, peut être programmée en utilisant les langages P4, C, Python, Broadcom Network Programming Language (NPL), ou des binaires exécutables compatibles x86 ou d'autres binaires exécutables. Une programmation de la consultation par hachage peut avoir lieu pour programmer un réacheminement de paquets par un plan de données. La illustre un exemple d'accélération de communication de microservices. Dans certains modes de réalisation, une composition de ressources ou un autre élément de l'IPU peut distribuer l'exécution d'un microservice à un accélérateur situé dans l'IPU ou à un accélérateur situé dans un autre nœud. Les délestages d'IPU (par exemple, transport fiable, TCP, QUIC, chiffrement, maillage de services) permettent de réduire la latence et la latence de queue. Les délestages permettent également de contourner le noyau en ce qui concerne ces fonctions, ce qui permet à l'IPU d'effectuer directement l'envoi à l'application de l'espace utilisateur. La illustre un exemple de processus d'attestation de ressources. En 3102, une IPU peut attester une ou plusieurs ressources pour l'exécution de microservices. L'attestation peut impliquer la vérification de certificats des dispositifs ou de configurations de dispositifs. Un domaine de ressources de confiance peut être formé par l'IPU pour l'exécution d'un ou plusieurs microservices. En 3104, l'IPU peut recevoir un appel API pour exécuter un ou plusieurs microservices pour une charge de travail. L'utilisation d'un appel API pour demander l'exécution d'une charge de travail permet de réduire une surface d'attaque afin de réduire le potentiel d'attaque malveillante de l'IPU. En 3106, pour une charge de travail valide autorisée à utiliser des ressources de calcul gérées par l'IPU, l'IPU peut expédier un ou plusieurs microservices pour exécution. En 3108, pendant l'exécution du ou des microservices, les données résultant de l'exécution de chaque microservice peuvent être fournies en vue d'un accès par un autre microservice. La illustre un exemple d'utilisation d'un trajet de données sécurisé par le biais de ressources attestées. En (1), une demande de données est émise par une XPU (par exemple, des cœurs de calcul) d'une IPU. En (2), une transaction de mémoire protégée (par exemple, une transaction de mémoire chiffrée (utilisant l'Adresse Virtuelle d'Invité)) peut être envoyée de l'IPU 3150 à un codeur (Enc) par l'intermédiaire du Moteur de Chiffrement de Lien (LEE) pour être déchiffrée (Dec) par le deuxième dispositif 3160. Le récepteur peut être une XPU ou une autre IPU. En (3), le LEE peut fournir une demande déchiffrée à une IOMMU pour traduire l'adresse virtuelle d'invité en une adresse physique d'hôte. En (4), l'IOMMU peut effectuer un parcours de traduction d'adresse vers des tables de pages à intégrité protégée (associées au TEE sur l'XPU). En (5), l'adresse virtuelle d'invité (GVA) peut être traduite en adresse physique d'hôte (HPA) et en un identifiant de clé keyID associé en utilisant les tables de pages. En (6), l'IOMMU peut fournir un keyID et une HPA au filtre de keyID. Le filtre de keyID peut vérifier que les ID de clé utilisés sont autorisés (par exemple, qu'ils appartiennent à un Domaine de Confiance/TEE) et, s'ils sont autorisés, peut envoyer, en (7), une demande de lecture d'adresse physique (PA) à des données de locataire Confidentielles (C), d'Intégrité (I), protégées contre la reproduction, en mémoire ou en stockage. Les données de locataire stockées en mémoire ou en stockage peuvent être chiffrées, protégées en matière d'intégrité et de reproduction (par exemple, du type Replay Protected Memory Block (RPMB)). En (8), des données chiffrées peuvent être fournies de la mémoire ou du système de stockage à un Moteur de Chiffrement de Mémoire (MEE) du dispositif 3160. En (9), le MEE peut déchiffrer les données et fournir des données en clair déchiffrées à la matrice d'interconnexion d'IPU/XPU pour leur transfert à l'unité de chiffrement LEE du dispositif 3160. Le LEE du dispositif 3160 peut chiffrer les données et fournir les données en (11) à un décodeur (dec) du dispositif d'IPU demandeur 3150. En (12), le dispositif d'IPU 3150 peut déchiffrer les données et fournir des données en clair à un cache (par exemple, un LLC) pour un accès par une XPU. Dans certains exemples, des données extérieures au boîtier IPU/XPU sont chiffrées, et ce n'est qu'à l'intérieur du boîtier que les données peuvent être en format déchiffré. La représente un exemple de composition de ressources système pour une IPU mettant en ligne un calcul réservé à partir d'une partition distante selon certains modes de réalisation. La illustre un exemple d'opérations de configuration de Plan de Commande d'IPU qui peuvent être réalisées conformément à certains modes de réalisation. En (1), il se produit un événement de déploiement de service ou de ressources, tel qu'une nouvelle charge de travail, une augmentation ou une réduction d'échelle de ressources (ou un changement d'échelle entrant ou sortant), ou des changements de paramètres de charge de travail ou de ressources. À titre d'exemple, une demande de l'utilisateur concernant un nouveau service ou un changement de service peut être émise à l'aide d'une interface de ligne de commande (CLI) ou d'une interface utilisateur graphique (GUI) ou d'une autre API. De plus, ceci peut être déclenché dynamiquement par des événements provenant de la télémétrie et du plan de commande local d'IPU, tels que des événements de surveillance indiquant qu'un SLO, des exigences de qualité du logiciel (SQR), etc. ne sont pas atteints. En (2), un Plan de Commande de Services Hiérarchique Global peut spécifier des Paramètres de Service pour un ou plusieurs plans de commande locaux d'IPU. Les paramètres peuvent comprendre un SLO ou un SQO et être basés sur un ou plusieurs des paramètres suivants : identifiant de locataire, limite de coût, limite de puissance (supérieure ou inférieure), limite de latence (supérieure ou inférieure), limite de gigue (supérieure ou inférieure), exigences de performances (supérieures ou inférieures), sécurité, lieu, exigences réglementaires, ressources ou fiabilité. Le Plan de Commande Global peut segmenter la configuration sur plusieurs nœuds ou ressources mutualisées. Cela peut également être utilisé lors de la connexion de changements/mises à jour à des services existants, comme la connexion d'un nouveau service au système de stockage existant. Cette coordination peut être utilisée pour gérer la confiance distribuée et les SLA et SQR entre ressources. En (3), un ou plusieurs Plans de Commande Locaux d'IPU peuvent être configurés pour effectuer la gestion de dispositifs, l'allocation de ressources, l'établissement de services, la détection et la mise en application de la sécurité, la connectivité, la surveillance, le haut niveau de disponibilité. Des exigences en matière de Locataires, de Politiques et de Ressources peuvent être appliquées à des Moteurs de Politiques pour déterminer la Décomposition de Services parmi les ressources locales et distantes. Certaines des informations utilisées pour prendre des décisions peuvent être fondées sur des politiques propres à chaque locataire et sur des ressources disponibles. Des Plans de Commande d'IPU peuvent utiliser différents processus de décision afin de générer la recette finale pour le déploiement. En (4), le Plan de Commande Local d'IPU peut définir des paramètres de sécurité (par exemple, Politique, Ressource, Actions) pour une ou plusieurs ressources commandées par l'IPU. Les paramètres de sécurité peuvent comprendre l'un ou plusieurs des suivants : politique de chiffrement de données au repos, exigences d'attestation au vol, en cours d'utilisation pour des services et des plateformes, gestion de clés et identité de l'utilisateur, politiques d'accès, isolation, restrictions réglementaires. Les actions de sécurité peuvent comprendre un ou plusieurs des éléments suivants : chiffrement de données et clés, négociation de certificats, exigences relatives aux dispositifs virtuels ou exigences relatives aux services. Une politique de sécurité peut spécifier ce qui est nécessaire pour gérer les exigences de sécurité et peut comprendre les éléments suivants : isolation des locataires, attestation de plateforme ou de services, négociation et gestion de clés, politiques de chiffrement de mémoire, interception légale, etc. Le Plan de Commande Local d'IPU peut faire passer les exigences à d'autres modules de politique, par exemple le chiffrement de réseau (IPsec, Sécurité de la Couche de Transport (TLS), le TLS mutuel (mTLS), le TLS de datagramme (dTLS)) et le pare-feu (ACL, suivi des connexions) au module de Connectivité. En (5), le Plan de Commande Local d'IPU peut définir des paramètres d'Objectifs de Niveau de Service (par exemple, Politique, Ressource, Actions) pour une ou plusieurs ressources commandées par l'IPU. Les paramètres d'Objectifs de Niveau de Service peuvent comprendre un ou plusieurs des éléments suivants : Coût, Fiabilité, Performances, Transactions par seconde, Cœurs de calcul, Taille de la mémoire, Taille du stockage, Bande passante réseau. Les actions SLO peuvent comprendre une ou plusieurs des allocations de ressources ou de la capacité. Les politiques d'Objectifs de Niveau de Service (SLO) peuvent comprendre des exigences en matière de coût, fiabilité, performances, transactions par seconde, nombre de cœurs de calcul, taille de mémoire/cache/stockage, etc. Ceci permet d'établir des configurations statiques ou dynamiques pour les ressources. En (6), le Plan de Commande Local d'IPU peut définir des paramètres d'Objectifs de Qualité de Service (par exemple, Politique, Ressource, Actions) pour une ou plusieurs ressources commandées par l'IPU. Les paramètres d'Objectifs de Qualité de Service peuvent comprendre un ou plusieurs des éléments suivants : Télémétrie, Latence, Gigue, Journalisation, Surveillance, Priorité. Les actions de SQO peuvent comprendre un ou plusieurs des éléments suivants : Allocations de ressources, Bande passante, QoS, Planification, Surveillance et Actions de journalisation. Les Objectifs de Qualité de Service (OQS) peuvent comprendre des éléments tels que télémétrie, journalisation, surveillance, réponses et latence/gigue de bout en bout, etc. Ceci permet de configurer des attributs statiques tels que des poids, des débits, des accélérateurs, etc. ainsi que d'établir des événements de télémétrie et des filtres pour une surveillance continue de l'exécution. En (7), le Plan de Commande Local d'IPU peut définir des paramètres de Connectivité (par exemple, Politique, Ressource, Actions) pour une ou plusieurs ressources commandées par l'IPU. Les paramètres de connectivité peuvent comprendre un ou plusieurs des éléments suivants : Routage, Pare-feu, NAT, Équilibrage de charge, Politique, QoS, Compression, Chiffrement, Applets Proxy de Services, et Stockage, Mappage d'Adresses Mémoire : Local-Local et Local-Distant. La hiérarchie de niveaux peut comprendre un ou plusieurs des éléments suivants : allocations de ressources, Tables de routage, Mappage d'Adresses, NVMe sur matrice d'interconnexion, allocation de Mémoire Mutualisée. La Politique de Connectivité peut couvrir à la fois les politiques de réseau telles que le routage, les pare-feu, la traduction d'adresses réseau (NAT), le suivi des connexions, les listes de contrôle d'accès, les plages de ports, la mise en miroir, l'échantillonnage, etc. Ces fonctions peuvent être appliquées au réseautage par superposition, au réseautage par sous-couche et aux délestages de locataires tels que le Maillage de Services, les passerelles API et les bus de messages. Des fonctions supplémentaires comprennent la gestion du mappage d'interface mémoire, comme le mappage d'adresses vers la mémoire locale ou distante rattachée et des délestages de stockage. Comme pour les autres moteurs de politiques, il peut s'agir de configurations statiques ou d'une utilisation mise à jour dynamiquement de ressources, d'accélérateurs ou de services/microservices. En (8), le Plan de Commande Local d'IPU peut définir des paramètres de Haute Disponibilité et de Gestion des Défauts (par exemple, Politique, Ressource, Actions) pour une ou plusieurs ressources commandées par l'IPU. Les paramètres de Haute Disponibilité (HA) et de Gestion des Défauts peuvent comprendre un ou plusieurs des éléments suivants : Zone de disponibilité, Régions, Erreurs, Migration de Services. Les actions HA et de Défauts peuvent comprendre un ou plusieurs des éléments suivants : événements de surveillance, Migration de données, Basculement rapide, Surveillance active. Les politiques de Haute disponibilité, de Traitement des Défauts et de Fiabilité peuvent comprendre une gestion active telle que la migration, le redémarrage, le retour en arrière de la configuration/mise à jour, le basculement rapide, la surveillance des services, etc. Elles permettent également d'établir des événements de télémétrie pour déclencher des actions. En (9), le Plan de Commande Local d'IPU peut définir des paramètres de Gestion de Ressources Sécurisée (par exemple, Partitions de Ressources, Profil, Accélérateurs, QoS et Configuration) pour une ou plusieurs ressources commandées par l'IPU. La Gestion de Ressources Sécurisée permet de traiter les exigences d'action de chacun des domaines de politique et de les mapper sur des ressources gérées (locales ou distantes) selon les ressources disponibles pour le type de demande de service. La Gestion de Ressources Sécurisée peut comprendre des fonctions telles que des BMC, une gestion d'IPU, des ressources (tables, accélérateurs, mémoire, clés, journalisation, etc.) et tenter de fournir des ressources au niveau de chaque locataire et de faire en sorte que les politiques et les configurations n'aient pas d'effets secondaires ou n'exposent pas les données. En (10), les paramètres de Gestion de Ressources Sécurisée peuvent être utilisés pour définir des paramètres dans un ou plusieurs Plans de Données de Ressources pour différentes IPU et différents nœuds (par exemple, une CPU, IPU, XPU, un stockage/une mémoire utilisant par exemple une Configuration, un État, des Registres). Une configuration de ressources individuelles et du flux de traitement peut être appliquée à la composition des services, au délestage de l'accélération, à la télémétrie. La Gestion de Ressources Sécurisée permet de fournir des mises à jour de configuration et de gestion aux ressources rattachées comme par exemple les XPU, le stockage, la mémoire, les CPU, etc. ainsi que l'IPU. En (11), les paramètres de Gestion de Ressources Sécurisée peuvent être utilisés pour configurer les paramètres de Télémétrie, de Traçage, de Surveillance, de Journalisation (par exemple, Locataire, Horodatage, Génération d'Événements, Mises à Jour Dynamiques, Actions) pour l'IPU. La Gestion de Ressources Sécurisée permet d'assurer la configuration de la télémétrie comme par exemple les politiques de journalisation, les temps d'échantillonnage, le filtrage et la génération d'événements. En (12), les plans de données permettent d'assurer une Surveillance et une Journalisation de Télémétrie dynamique au moment de l'exécution. La télémétrie permet une gestion et une conservation de la télémétrie en tant que politiques de journalisation, temps d'échantillonnage, filtrage et génération d'événements. Il peut s'agir d'un processus actif gérant des événements de ressources ou vérifiant et regroupant périodiquement des états et des événements. Des déclencheurs peuvent être renvoyés au processus du plan de commande principal d'IPU afin d'entreprendre d'autres actions. En (13), la télémétrie, le traçage, la surveillance et la journalisation et la gestion de ressources sécurisée permettent de fournir l'achèvement, l'état, les journaux et les événements à son plan de commande local d'IPU. En (14), des événements locaux, des Journaux, des Changements d'État peuvent amener une boucle de rétroaction permettant des ajustements dynamiques à conserver les Politiques. Celles-ci peuvent également être ramenées au Plan de Commande de Service Hiérarchique Global pour des actions plus étendues. Le plan de commande local d'IPU reçoit des demandes du Plan de Commande Hiérarchique Global externe, des événements de télémétrie au niveau du nœud local, ou s'exécute périodiquement afin de créer des décisions et des actions locales rapides. Cela peut conduire à une architecture évolutive avec un retour d'informations plus rapide. En (15), le plan de commande local d'IPU peut fournir des Événements d'Achèvement et des Changements d'État au plan de commande de services hiérarchique global afin de fournir des rapports sur l'état d'achèvement des demandes, les ressources utilisées et les événements de télémétrie. L'état d'achèvement des demandes, les ressources utilisées et les événements de télémétrie sont fournis au plan de commande hiérarchique local et global à des fins de journalisation, et peuvent déclencher des actions ultérieures telles qu'une augmentation d'échelle de nouvelles ressources ou une migration de services. En (16), des Événements d'Achèvement et des Changements d'État peuvent être renvoyés à un administrateur ou à un utilisateur. Un nouvel événement peut être émis sur la base de l'état reçu. Les Figures. 32C-1 et 32C-2 décrivent un exemple de fonctionnement du plan de commande avec utilisation de divers éléments de sécurité. Les propriétés de sécurité du plan de Commande d'IPU peuvent comprendre : A. L'IPU fournit un plan de commande permettant de négocier des propriétés de sécurité, à savoir la confidentialité, l'intégrité, la protection contre la reproduction et la disponibilité (C, I, R, A) pour le calcul désagrégé, la mémoire/NVM/stockage, le réseau (par exemple, points 1 et 2). B. Blocs constitutifs de Mesure, Rapport, Attestation/Vérification d'Estimation sur IPU avec reconfigurabilité flexible (attestation hiérarchique de plateformes en nuage) (par exemple, point 4). C. Mappage de la charge de travail "SLA de Sécurité" par orchestration (sur l'ensemble du système distribué) vers un ensemble d'IPU, en équilibrant les exigences de performances vis-à-vis des modèles de programmation multi-locataires à grain fin - par exemple, fonction virtuelle, VM, conteneurs, compartiments (par exemple, points 5 et 10). D. Partage de rôles en matière de gestion de l'hyperviseur et de sécurité entre XPU et IPU (le CSP gère l'ensemble de la plateforme distribuée) (par exemple, points 3 et 11). E. Gestion des services de sécurité dans l'IPU et mappage du contrôle d'accès aux données (par exemple, points 5 et 6). F. Dans le cas des systèmes distribués, domaines cryptographiques distincts lorsque les capacités de la plateforme lient différents domaines cryptographiques entre les CPU/IPU/XPU (par exemple, points 8 et 9). G. Retour d'information local du plan de commande sécurisé pour faire respecter le fait qu'une interface liée à un contexte d'exécution de confiance ne soit pas reconfigurée de manière malveillante, et puisse déclencher un événement susceptible de reconfigurer l'interface ou d'effacer des secrets, et puisse être mise en application par un automate fini de sécurité d'interface de dispositif au niveau de l'interface. Comme exemples d'actions dues à des violations de sécurité, on peut citer la journalisation, la suppression de services, la révocation de clés ou de certification, la redirection et l'isolation de services, ou le confinement de services pour un débogage actif de la vulnérabilité et de la profondeur d'intrusion. Comme exemple de séquence pour le fonctionnement du plan de commande avec utilisation de diverses fonctionnalités de sécurité on peut citer ce qui suit. Se référant aux figures 32C-1, en (1), un événement de déploiement d'un service ou de ressources se produit, comme par exemple une nouvelle charge de travail, une augmentation ou une diminution d'échelle des ressources, ou des modifications de paramètres de charge de travail ou de ressources. En (2), le Plan de Commande Global peut mettre en application la configuration sur plusieurs nœuds ou ressources mutualisées sur la base d'exigences de sécurité. À titre d'exemple, pour un Échange de Données de Confiance (TDX), la mémoire peut être chiffrée, l'intégrité et la reproduction protégées, les liaisons de dispositifs externes devant être protégés de manière semblable et les mesures de dispositifs accompagnées de certificats devant être disponibles pour une évaluation. Le Plan de Commande d'Orchestration Globale/Services peut effectuer un partitionnement de haut niveau des services sur une ou plusieurs plateformes. Le Plan de Commande d'Orchestration Globale/Services peut comprendre des fonctions de VMM, de Service OS, et/ou de plan de commande de gestion sur une IPU. Le Plan de Commande d'Orchestration Globale/Services peut demander une Activation/Modification de Service pour une exécution de confiance. Des éléments TCB isolés du Plan de Commande d'Orchestration Globale/Services peuvent mettre en application des paramètres de sécurité et des automates finis. En (2), le Plan de Commande d'Orchestration Globale/Services peut demander une Activation/Modification de Service à un plan de commande local de l'IPU en utilisant des interfaces existantes. En (2), des éléments TCB Isolés du Plan de Commande d'Orchestration Globale/Services peuvent communiquer avec un plan de commande local d'IPU par le biais d'un contrôle de l'Interface d'Abstraction de Commutateur (SAI) de la CPU ou par l'intermédiaire d'un protocole de bus protégé. Il est à noter qu'en (1) et (2), le plan de commande d'IPU peut fournir des propriétés de sécurité, l'IPU fournissant un plan de commande permettant de négocier des propriétés de sécurité (C, I, R, A) pour le calcul désagrégé, la mémoire/NVM/le stockage et le réseau. En (3), le Plan de Commande Local d'IPU peut exécuter une fonction de gestion sur l'IPU/le Dispositif pour fournir des API de gestion afin d'énumérer des mesures et des capacités de dispositif, de transférer des messages au Plan de Commande Local d'IPU - Moteur de Sécurité de Dispositif, d'initialiser la mémoire locale telle qu'elle est attribuée au logiciel existant, ou d'initialiser des associations de sécurité de fonctions virtuelles pour les dispositifs situés en aval. En (3), le Plan de Commande Local d'IPU - Moteur de Sécurité de Dispositifs peut fournir une fonction de sécurité sur l'IPU pour fournir des API de commande, pour énumérer des mesures et des capacités de dispositifs, pour configurer des clés destinées à des protocoles de liaison, pour initialiser la mémoire locale telle qu' attribuée aux domaines de confiance, ou pour vérifier des associations de sécurité des fonctions virtuelles pour des dispositifs situés en aval et affectés à des environnements d'exécution de confiance (domaines ou enclaves de confiance). En (3), un autre Plan de Commande Local d'IPU peut fournir une fonction de sécurité sur l'IPU/le Dispositif (appelé Moteur de Sécurité de Dispositif/DSE) et fournit des API de commande permettant d'énumérer des mesures et des capacités de dispositifs, de configurer des clés pour des protocoles de liaison, d'initialiser la mémoire locale telle qu'attribuée à des domaines de confiance, ou de vérifier des associations de sécurité de fonctions virtuelles pour des dispositifs situés en aval affectés à des environnements d'exécution de confiance (par exemple, des domaines ou enclaves de confiance). Une session sécurisée peut être établie entre des plans de commande locaux d'IPU. Se référant à la figure 32C-2, en (4), une configuration d'Attestation et de Mesure peut comprendre une politique de chiffrement de données au repos, en vol, en utilisation, fournir des exigences d'attestation pour des services et des plateformes, configurer la gestion de clés et l'Identité de l'Utilisateur, configurer des Politiques d'Accès, l'Isolation, les Restrictions Réglementaires. Les actions de sécurité peuvent comprendre : stockage et accès au chiffrement des données et aux clés, négociation de certificats, et application des Exigences relatives aux Dispositifs Virtuels. En (5), la Configuration des Interfaces de Confiance permet le mappage de politiques de sécurité locales pour le domaine de confiance afin de maintenir les associations de sécurité au niveau de chaque contexte TEE, qui peuvent s'appliquer aux MMU, interfaces et autres interfaces de liaison (par exemple, réseau, PCIe, etc.). Les actions peuvent comprendre la programmation de clés éphémères/persistantes, ou des associations de sécurité de protocole pour la couche de liaison. En (6), la configuration de la disponibilité et de la migration de confiance peut fournir les aspects Politique, Ressource, Actions et Zone de disponibilité, Régions, Erreurs, Migration de Services. La haute disponibilité (HA) et les Actions pour Défauts peuvent comprendre les événements de Surveillance, la migration de Données, le Basculement Rapide, et la Surveillance Active. En (7), la Gestion de Ressources Sécurisée permet de traiter des exigences d'action de chacun des domaines de politique et de les mapper sur la configuration de contrôles de sécurité individuels sur la base des exigences (C, I, R, A). En (8), le contrôleur mémoire d'IPU, les interfaces réseau, les interfaces de dispositifs (par exemple, CXL ou PCIe ou les interfaces de N à M dispositifs (où N et M sont supérieurs à 1)), d'autres ressources du plan de données, ou le stockage, la mémoire ou les accélérateurs rattachés, peuvent être configurés par la gestion de ressources sécurisée. En (9), des IPU, XPU ou plans de commande locaux en aval et des moteurs de sécurité de dispositifs peuvent être configurés par le gestionnaire de ressources sécurisé. En (10), la télémétrie, le traçage, la surveillance et la journalisation sécurisés peuvent recevoir des informations de télémétrie protégées en termes d'intégrité (et de confidentialité) qui seront fournies au locataire de la charge de travail. Se référant à la figure 32C-1, en (11), des événements d'achèvement de confiance, des changements d'état, des défauts d'interruption peuvent être fournis à des éléments TCB (Trusted Computing Base) isolés du Plan de Commande d'Orchestration Globale/Services pour mettre en application des paramètres et des automates finis de sécurité. Se référant à la figure 32C-2, en (12), pour l'isolation de sécurité, le Plan de Commande de Sécurité peut être un processus distinct. Des mises à jour et des actions provenant du Plan de Commande de Sécurité peuvent fournir des mises à jour au Plan de Commande d'IPU afin de résumer les événements au Plan de Commande Hiérarchique Global. Le plan de commande d'IPU peut être mis dans un état d'erreur pour une reconfiguration potentielle ou rester dans un état d'erreur et être retiré en tant que candidat à l'exécution d'un service. Se référant à la figure 32C-1, en (13), des événements d'achèvement, des changements d'état et des défauts d'interruption peuvent être fournis par le plan de commande local d'IPU au Plan de Commande d'Orchestration Globale/Services. Comme exemples d'actions dues à des violations de sécurité, on peut citer la journalisation, la suppression de services, la révocation de clés ou de certification, la redirection et l'isolation de services, ou le confinement de services pour un débogage actif de la vulnérabilité et de la profondeur d'intrusion. Il est à noter que l'orchestration globale et chaque IPU peuvent se trouver dans des domaines cryptographiques différents. La illustre un exemple de plan de données et de fonctionnement d'une IPU. En (1), des demandes de traitement sont mises en file d'attente, telles que LAN, RDMA, NVMe ou des demandes de service pour le traitement de RPC ou de Messages. Pour la télémétrie, ces demandes peuvent être horodatées. À titre d'exemple, pour le délestage RPC, l'IPU peut horodater chaque session RPC individuelle pour déterminer la latence et la gigue, ainsi que les erreurs et les événements associés. Ceux-ci peuvent être renvoyés dans le plan de commande d'IPU à des fins d'ajustements dynamiques. En (2), des demandes sont planifiées sur la base d'une variété de paramètres tels que la QoS du locataire, les SLA min/max/poids, les exigences de priorité, de temps de traitement le plus tôt/le plus tard. En (3), le traitement de protocole peut générer le traitement de sous-commandes nécessaires pour mener à bien la demande. En (4), un DMA (accès direct à la mémoire) regroupe les données nécessaires au traitement. En (5), une classification et un traitement des données peuvent avoir lieu sur la base de la composition du plan de commande des fonctions désagrégées. Sur la base de la configuration, il est possible d'utiliser pour cela un ensemble ou une séquence quelconque des éléments suivants : accélérateurs, calcul, stockage, mémoire, sécurité, télémétrie et traitement temporel. Certains cas d'utilisation peuvent nécessiter plusieurs passages rebouclés pour traiter différentes couches de la pile de protocoles. L'IPU peut également insérer des informations de télémétrie telles que des UUID pour permettre le traçage des RPC entre les services. En (6), le traitement achevé peut être planifié pour sa transmission par l'intermédiaire de la Matrice d'Interconnexion Multimédia. Pour des services qui sont hébergés localement, le paquet peut alors être renvoyé en boucle localement au traitement de Réception. En (7), une mise en tampon de réception peut se produire sur la base de la priorité du trafic, du locataire, du type. Un horodatage de la télémétrie peut se produire. En (8), une planification du trafic de réception peut se produire sur la base de paramètres divers. En (9), une classification et un traitement des données peuvent avoir lieu sur la base de la composition du plan de commande de fonctions désagrégées. Sur la base de la configuration, il est possible d'utiliser pour cela un ensemble ou une séquence quelconque des éléments suivants : accélérateurs, calcul, stockage, mémoire, sécurité, télémétrie et traitement temporel. Certains cas d'utilisation peuvent nécessiter plusieurs passages rebouclés pour traiter différentes couches de la pile de protocoles. Une classification peut également déterminer le placement des charges de travail, comme l'emplacement et la hiérarchie de la mémoire et du cache, l'affinité avec les cœurs, la prise en compte du NUMA, la moindre utilisation des XPU, etc. En (10), il peut se produire des copies d'accès direct à la mémoire (DMA) de données vers la mémoire cible dans les éléments Calcul, XPU, Stockage, Mémoire. En (11), le traitement de protocole peut générer le traitement de sous-commande nécessaire pour mener à bien la demande. En (12), des demandes peuvent être planifiées sur la base d'une variété de paramètres tels que QoS du locataire, SLA min/max/poids, et exigences de priorité, de gigue, de latence, de temps de traitement le plus tôt/le plus tard. En (13), des demandes achevées peuvent être mises en file d'attente, telles que LAN, RDMA, NVMe traditionnels ou un service requis pour le traitement des RPC ou des Messages. Pour la télémétrie, ces demandes peuvent être horodatées. Des demandes peuvent également être redirigées vers le trajet de transmission. Cela peut être exigé si l'IPU peut achever la demande de traitement de manière indépendante ou si la ressource a été déplacée vers un dispositif distant. En (14), l'IPU peut gérer des commandes I/O, de Mémoire et de Mise en cache par le biais de la matrice d'interconnexion de calcul afin de basculer vers des ressources mutualisées locales ou d'établir un pont/routage de la demande vers des ressources mutualisées distantes. En (15), la MMU et une Traduction d'Adresses peuvent être utilisées pour le suivi du cache et la classification des adresses mémoire afin de déterminer le traitement requis et les politiques à appliquer. Un accès mémoire à une mémoire mutualisée distante peut nécessiter une encapsulation de l'accès dans une demande de message à traiter sur le trajet de Transmission. La illustre l'exemple d'un plan de données d'IPU et d'un fonctionnement avec des fonctionnalités de sécurité. L'IPU peut fournir un plan de données pour la protection des données en cours d'utilisation pour une isolation améliorée ainsi qu'un calcul confidentiel pour des uServices de locataires distribués. Une Matrice d'Interconnexion de Calcul peut assurer la Virtualisation des Dispositifs et l'Isolation des Locataires pour le transfert de messages du plan de données. Le processeur de sécurité peut assurer la vérification des estimations pour les attestations au moment de de l'exécution de charges de travail pour le traitement des protocoles, le DMA et la configuration des clés. Des moteurs de sécurité de délestage de services peuvent par exemple fournir un agent de Migration ou un Maillage de services. Des moteurs de sécurité de délestage de services peuvent configurer des clés pour la classification programmable, le séquençage de processus, les proxys de services et les applets. Des fonctions d'accélération et de calcul avec isolation au niveau de chaque locataire peuvent être appliquées par classification programmable, séquençage de processus, proxys de service et applets. Un moteur de sécurité en ligne (par exemple, un chiffrement de la mémoire) peut être appliqué par la classification programmable, le séquençage de processus, les proxys de service et les applets. Une MMU locale et une Traduction d'adresses peuvent être utilisées pour conserver un contrôle d'accès par locataire et une isolation cryptographique. Les caractéristiques de sécurité suivantes, identifiées par des numéros encerclés, peuvent être utilisées pour les opérations du plan de données. Fonctionnalité de sécurité (1) : Les propriétés TEE peuvent être configurées par l'intermédiaire du plan de commande sur des dispositifs non uniformes et hétérogènes (par exemple, CPU, FPGA, GPU, XPU, accélérateurs, mémoire mutualisée, dispositifs de stockage) et peuvent être mises en application sur le trajet de données de sorte que toute donnée de locataire exposée à l'extérieur du SOC est protégée par C, I, R. Fonctionnalité de sécurité (2) : l'IPU peut fournir une interface de dispositif virtuelle pour les accélérateurs sur le SOC (pas sur l'IPU). Fonctionnalité de sécurité (3) : Une migration transparente des charges de travail (par exemple, des VM, des conteneurs, des uServices, des fonctions) entre des plateformes désagrégées peut se faire par l'intermédiaire de l'IPU. L'IPU peut par exemple aider à la migration en direct de VM. Fonctionnalité de sécurité (4) : dans le contexte d'un TEE distribué, Il est possible d'utiliser les associations de sécurité confidentielles du dispositif/de la structure I/O pour la totalité de la plateforme en nuage, par exemple, IPSEC, TLS (logique), CXL, PCIe (lien), RDMA sur Ethernet, etc. Fonctionnalité de sécurité (5) : Partage des rôles de gestion de l'hyperviseur et de sécurité entre XPU et IPU ; un CSP peut gérer l'ensemble de la plateforme distribuée. Fonctionnalité de sécurité (6) : la sécurité de communication/RPC/sidecar peut être utilisée pour des charges de travail natives en nuage comme WASM/microservices/FaaS - sous-processus et mémoire sécurisée/partagée. Fonctionnalité de sécurité (7) : Communication inter-uServices sécurisée efficace (à base d'ISA/matériel) par des messages d'accélérateur à accélérateur. Fonctionnalité de sécurité (8) : attestation à la volée de microservices (uSvc) par l'intermédiaire de l'IPU. Les figures 33C-1 à 33C-3 illustrent des vues système de fonctionnalités de sécurité de la . La figure 33C-1 illustre un exemple dans lequel une IPU configure des propriétés de TEE par l'intermédiaire du plan de commande au travers de différentes interfaces correspondant au point (1) de la . La figure 33C-2 illustre un exemple dans lequel une IPU configure une interface de dispositif virtuel et une migration de charge de travail. Les fonctionnalités de sécurité (2) et (3) de la sont illustrées à titre d'exemple. La figure 33C-3 illustre un exemple dans lequel une IPU assure l'isolation de la charge de travail. À titre d'exemple, les fonctionnalités de sécurité (1), (4), (6), (7) et (8) de la sont illustrées. Les figures 34A et 34B illustrent un exemple d'utilisation d'un plan de données RPC d'IPU avec un Maillage de Services. Des variantes de déploiement sont possibles, les composantes de services pouvant résider sur l'unité de calcul ou sur l'XPU. La séquence exacte d'exécution des services peut également varier sur la base du déploiement. Dans certains exemples, une IPU source peut exécuter (2) - (5) tandis qu'une IPU de destination peut exécuter (6)-(10). Se référant à la , en (1), une demande RPC porte sur un microservice/service. L'application peut être hébergée dans une variété d'environnements, comme par exemple les environnements sans serveur, les conteneurs, les VM, les conteneurs dans des VM, le bare metal, etc. Un RPC est un exemple de type d'appel de service ou de fonction, et peut comprendre d'autres méthodes comme SOAP (Protocole Simple d'Accès aux Objets), REST (Transfert d'État Représentatif), gRPC, GraphQL, Thrift, JSON-RPC, HTTP, OpenAPI, etc. En (2), des demandes envoyées par le biais d'un connecteur logiciel tel qu'une interface de mémoire peuvent tirer parti de la cohérence de la mémoire et du cache des matrices d'interconnexion de calcul. En (3), un Traitement de Maillage de Services RPC de Locataire peut être effectué, tel que DNS, Classification RPC, Politique de Sécurité, Équilibrage de Charge, Politique de Transfert, Transformation de Données, Compression, Chiffrement, Télémétrie, et Journalisation. En (3), un délestage d'IPU du traitement RPC et de Maillage de Services peut avoir lieu. Il peut s'agir d'un mélange d'accélérateurs ou de calculateurs fixes/statiques/programmables. Cela libère le Calcul hôte et réduit la puissance, la latence, etc. En (4), un délestage d'IPU du Traitement de Superposition de Locataire peut avoir lieu, tel qu'Horodatage, Planification de QoS, Classification, Politique de Sécurité, Politique de Réacheminement, Traduction d'Adresses Réseau (NAT), Pare-feu, ou traitement vSwitch. En (5), un délestage d'IPU du Traitement de Sortie de Locataire peut avoir lieu tel que LAG/ECMP, Modifications de Paquets, Segmentation, Transport Fiable, Contrôle de Congestion, Planification de QoS Multimédia, ou Journalisation. Un délestage d'IPU du TCP/transport fiable et du contrôle de congestion dynamique supprime les copies d'hôte entre l'espace utilisateur et le noyau et réduit les latences, la gigue et les latences de queue. Cela peut permettre de faire en sorte que l'accès à des ressources partagées distantes se comporte de manière semblable à des ressources locales dédiées. Se référant à la , en (6), une IPU de destination (nœud 2) peut effectuer un délestage du Traitement de Sortie de Locataire, tel qu'Horodatage, Classification, Mise en Tampon, Planification de QoS, Contrôle de Congestion, Transport Fiable, ou Journalisation. Un délestage d'IPU du TCP/transport fiable et du contrôle de congestion dynamique permettent de supprimer des copies d'hôte entre l'espace utilisateur et le noyau et de réduire les latences, la gigue et les latences de queue. Cela peut permettre de faire en sorte que l'accès à des ressources partagées distantes se comporte de manière semblable à des ressources locales dédiées. En (5) et (6), un délestage d'IPU du TCP/transport fiable et du contrôle de congestion dynamique supprime les copies d'hôte entre l'espace utilisateur et le noyau. Cela réduit les latences, la gigue et les latences de queue. Cela permet de faire en sorte que l'accès à des ressources partagées distantes se comporte de manière semblable à des ressources locales dédiées. En (7), une IPU de destination peut délester un Traitement de Superposition de Locataire tel que classification, politique de sécurité, pare-feu, NAT, désencapsulation ou traitement vSwitch. En (8), une IPU de destination peut délester un Traitement de Maillage de Service RPC de Locataire tel que Classification RPC, Politique de Sécurité, Réassemblage, Déchiffrement, Décompression, Transformation de Données, Télémétrie, Journalisation, Affinité de Cœur de Processus, et QoS de Service. Délestage par IPU des fonctions de Maillage de Services et de Passerelle API. Il peut s'agir de fonctions de sécurité telles qu'authentification d'utilisateur pour le contrôle d'accès, validation de champs, limitation de débit, priorisation et planification de services d'entrée lors d'une congestion. En (9), (9a) et (9b), une IPU de destination peut déterminer si le service est hébergé localement dans l'IPU ou non. L'IPU de destination peut héberger des services/microservices/applets qui peuvent être exécutés sur des cœurs ou des accélérateurs, le service fonctionnant entièrement localement sur l'IPU ou étant réparti entre l'IPU et des XPU/stockages/mémoires rattachés pour mener à bien la fonction de service. L'IPU peut également renvoyer la demande au système de Calcul pour des applications de locataires ou si un calcul à plus grande échelle est nécessaire. Il est également possible de faire en sorte que le service soit hébergé sur le nœud demandeur avec l'IPU. L'IPU fournit une abstraction au demandeur et l'achemine (par exemple, à l'aide d'un Maillage de Services) vers le point d'extrémité de service voulu. Des RPC entre hôtes peuvent être utilisés pour construire des microservices et offrir une meilleure évolutivité, une isolation contre les défauts et un développement indépendant plus rapide. En (10), une IPU de destination peut planifier l'exécution ou l'envoi d'une demande de traitement interne aux ressources de l'IPU ou à des ressources rattachées. Sur la base de la classification et de la télémétrie, la planification de l'IPU peut prendre en compte des exigences de SLO, SQR ainsi que la congestion et l'exploitation des ressources. La priorisation et la planification de la réception permettent de minimiser la latence et de gérer les SLA de locataires. Les figures 35A et 35B illustrent un exemple de décomposition de services entre des ressources locales et distantes. Se référant à la , en (1), une application peut demander un service / microservice par l'intermédiaire de gRPC. En (2), une partie Protobuf du gRPC reste sur la CPU et crée un message sérialisé. En (3), l'IPU peut planifier et diffuser le message et effectuer une accélération gRPC telle qu'une compression et un chiffrement qui seraient normalement exécutés sur la CPU. En (4), l'IPU peut délester des fonctions de Maillage de Services, de Transport Fiable et de vSwitch. Celles-ci fournissent de meilleures performances et une latence plus faible et permettent de faire en sorte que des services distants désagrégés et l'accès aux XPU se comportent davantage comme une demande locale. Le Plan de Commande peut configurer le Maillage de Services pour envoyer une demande à un service distant pour une exécution à distance (5) par l'intermédiaire d'une interface multimédia et pour une commutation à travers une autre IPU ou vers un Applet local (5a). Le terme d'exécution à distance peut désigner l'exécution d'un service sur un dispositif accessible par l'intermédiaire d'une interface réseau ou de matrice d'interconnexion. Dans certains exemples, un service peut comprendre un ou plusieurs des éléments suivants : logiciel exécuté par un processeur, fonction, matériel fixe ou programmable, logiciel exécuté par une CPU, processus exécuté par une GPU ou GPGPU, utilisation d'un accélérateur, ou d'un RPC. En (5a), le plan de commande peut facultativement déployer un applet local hébergé par l'IPU pour l'API de service XPU. Un service local peut procurer une latence plus faible que l'utilisation d'une autre IPU avec des compromis possibles notamment en termes de performances. Des commutateurs intelligents 100 tels que le Tofino de Barefoot Networks peuvent exporter des informations de télémétrie de paquets et de messages/RPC en fonction de l'UUID. Cela permet de déterminer les impacts des défaillances, des sources d'erreurs et de la latence, ainsi que des types de trafic transportés. La illustre des activités d'une deuxième IPU. Pour un message reçu, la deuxième IPU peut exécuter des actions (4) - (7). En (5), l'IPU héberge une API de Service pour exposer des capacités d'XPU et gère un éventuel prétraitement de la demande. Priorisation et planification Rx pour minimiser la latence et gérer les SLA de locataires. En (6), l'IPU envoie des demandes à l'XPU pour le traitement nécessaire. En (7), un traitement par XPU peut avoir lieu. En (8), l'IPU peut utiliser un achèvement d'XPU pour générer une réponse RPC en retour à l'Application. Cela établit un pont entre le comportement des XPU et des RPC de microservices. Les figures 36A et 36B illustrent un exemple de système et de fonctionnement de décomposition de services IPU pour des scénarios de mémoire et de stockage. Se référant à la , en (1), une Application peut émettre une demande de stockage avec une demande de service pour un accès à une Base de données et un Chargement de Mémoire/Stockage/Invalidation de Cache, etc. En (2), pour des transactions de mémoire, la MMU de la CPU peut envoyer la demande à l'IPU par le biais de la Matrice de Calcul. D'autres types peuvent être exposés en tant que services ou demandes NVMe. En (3), une MMU et une traduction d'adresses peuvent être utilisées pour le suivi du cache et la classification des adresses mémoire afin de déterminer le traitement requis et les politiques à appliquer. Un accès mémoire à une mémoire mutualisée distante peut exiger que l'encapsulation de l'accès dans une demande de message soit traitée sur le trajet de transmission. En (4), une authentification et une identité d'utilisateur peuvent définir des espaces de noms et des politiques telles qu'accès, QoS, connectivité, etc. En (5), des commandes d'IO, de mémoire et de mise en cache sur matrice d'interconnexion de calcul peuvent être gérées par l'IPU pour le basculement vers des ressources mutualisées locales ou pour le pontage/routage de la demande vers une ressource mutualisée locale ou distante. En (6), une encapsulation et une conversion de protocole peuvent avoir lieu. En (7), une IPU peut délester des fonctions de Maillage de Services, Transport Fiable, vSwitch. Ce traitement peut également déterminer l'emplacement local ou distant du service. Dans cet exemple, le service doit ensuite être exécuté sur une deuxième IPU. Une interface multimédia est utilisée pour transmettre un message ou un RPC à une deuxième IPU. Comme le montre la , l'IPU peut communiquer avec une deuxième IPU à l'aide du commutateur 100. Le commutateur 100 peut comprendre un commutateur qui peut exporter des informations de télémétrie de paquets et de messages ou RPC sur la base de l'UUID. Cela permet de déterminer les impacts de défaillances, de sources d'erreur et de latence, et des types de trafic transportés. Se référant à la , il est possible d'accéder à une deuxième IPU. La deuxième IPU peut comprendre un contrôleur SmartNIC doté d'une accélération de stockage pour des transactions locales et distantes NVMe ou NVMe sur de Matrice d'Interconnexion. En (20), la deuxième IPU peut exécuter des fonctions de délestage par IPU de type Maillage de Services, Transport Fiable, vSwitch. Délestage de cœurs de CPU et réduction de la latence. Des demandes de mémoire et de stockage sont identifiées comme passant par proxy par les services d'IPU. En (21), la deuxième IPU peut exécuter des fonctions de délestage d'IPU pour le Maillage de Services, et l'Exposition de Services pour les demandes de mémoire et de stockage. Celles-ci sont identifiées comme passant par proxy par les services d'IPU. En (22), la deuxième IPU peut effectuer une authentification et une identité d'utilisateur et définir des espaces de noms et des politiques telles que contrôle d'accès, plages d'adresses valides, QoS, politique de sécurité, etc. L'accès basé sur l'utilisateur garantit que les clés de chiffrement ne soient jamais exposées. Politique et décisions concernant le placement des données, telles que hiérarchie de la mémoire ou du cache, et invalidation. En (23), la deuxième IPU peut effectuer un placement de charge de travail, cela permettant de placer des données le plus près possible de l'endroit où le traitement ultérieur aura lieu. En (24), la deuxième IPU peut exécuter des Moteurs de Protocole pour la mémoire et l'interface de stockage. En (25), la deuxième IPU peut effectuer un traitement pour des systèmes de fichiers, un magasin d'objets, des métadonnées associées, des clés-valeurs. Cela comprend l'analyse syntaxique des structures, la recherche et le filtrage (REGEX/HALO) et la mise en application de politiques. Les actions de politique peuvent comprendre la réplication de données, la multidiffusion pour la journalisation, etc., comme par exemple : un contrôle d'accès basé sur l'authentification de l'utilisateur. En (26), la deuxième IPU peut effectuer un traitement de transaction et de commande, par exemple des commandes programmables et atomiques qui réduisent la latence en s'exécutant localement et en supprimant la latence pour les actions ultérieures comme les parcours Trie et la recherche de base de données sans avoir à renvoyer les données au demandeur. La mise en ordre des commandes minimise le blocage entre des commandes non associées, assure une mise en ordre atomique et un achèvement des commandes permettant un stockage persistant. La transformation des données et le traitement en flux continu permettent des conversions de type de format, un mélange, un fractionnement, un codage par effacement, etc. En (27), la deuxième IPU peut effectuer une mise en cache qui réduit la latence et optimise l'utilisation de la matrice d'interconnexion de calcul et des ressources. La mise en cache peut comprendre une mise en cache en lecture/écriture, une mise en cache en écriture immédiate et une mise en cache distribuée. En (28), la deuxième IPU peut effectuer une compression un chiffrement de données au vol, en cours d'utilisation, au repos. Planification de la QoS pour réduire la latence des demandes à haute priorité et mise en application des SLA. Télémétrie pour la journalisation des transactions, la surveillance, les mesures de latence, etc. En (29), la deuxième IPU peut effectuer une prise en charge d'une multitude de types de mémoire, notamment DDDR, Optane, Persistante, NVMe. Des services de traduction d'adresses permettent un chargement/stockage à distance. Divers modes de réalisation peuvent comprendre l'exécution d'un service dans un environnement informatique distribué. Un ou plusieurs serveurs et/ou un ou plusieurs systèmes clients peuvent exécuter des instructions. Diverses tâches peuvent être exécutées sur un système distant, un système local et/ou un autre système. Des instructions peuvent être stockées et exécutées sur différents systèmes pour une exécution sur plusieurs systèmes. Il est à noter qu'une destination peut être accessible à l'aide d'un SmartNIC. Le SmartNIC peut effectuer le point (20) à la place de la deuxième IPU. Un résultat peut être fourni par la deuxième IPU ou le SmartNIC à l'IPU. En (10), des services qui sont hébergés localement sont renvoyés en boucle par l'IPU pour le traitement en pipeline, la politique de service, l'accélération de Commandes, les Transactions, etc. Il s'agit des mêmes options de traitement que celles fournies du côté distant. La représente un exemple d'interface réseau qui peut utiliser des modes de réalisation ou être utilisé par des modes de réalisation. Dans certains modes de réalisation, l'interface réseau peut être utilisée dans une IPU, une DPU, ou comme partie d'un SmartNIC. Dans certains exemples, l'interface réseau 3700 peut être réalisée sous la forme d'un contrôleur d'interface réseau, d'une carte d'interface réseau, d'une interface de matrice d'interconnexion (HFI) ou d'un adaptateur de bus hôte (HBA), et ces exemples peuvent être interchangeables. L'interface réseau 3700 peut être couplée à un ou plusieurs serveurs au moyen d'un bus, PCIe, CXL ou DDR. L'interface réseau 3700 peut être réalisée sous la forme d'une partie d'un système sur puce (SoC) qui comprend un ou plusieurs processeurs, ou contenue dans un boîtier multi-puces qui contient également un ou plusieurs processeurs. L'interface réseau 3700 peut comprendre un émetteur-récepteur 3702, des processeurs 3704, une file d'attente de transmission 3706, une file d'attente de réception 3708, une mémoire 3710, une interface de bus 3712 et un moteur DMA 3752. L'émetteur-récepteur 3702 peut être capable de recevoir et de transmettre des paquets en conformité avec des protocoles applicables tels qu'Ethernet, comme décrit dans IEEE 802.3, bien que d'autres protocoles puissent être utilisés. L'émetteur-récepteur 3702 peut recevoir et transmettre des paquets depuis et vers un réseau par l'intermédiaire d'un support de réseau (non représenté). L'émetteur-récepteur 3702 peut comprendre des circuits PHY 3714 et des circuits de contrôle d'accès au support (MAC) 3716. Les circuits PHY 3714 peuvent comprendre des circuits de codage et de décodage (non représentés) pour coder et décoder des paquets de données selon les spécifications ou les normes applicables de la couche physique. Les circuits MAC 3716 peuvent être configurés pour effectuer un filtrage d'adresses MAC sur les paquets reçus, traiter les en-têtes MAC des paquets reçus en vérifiant l'intégrité des données, supprimer les préambules et effectuer un remplissage, puis fournir le contenu des paquets devant être traités par des couches supérieures. Les circuits MAC 3716 peuvent être configurés pour assembler les données à transmettre en paquets, qui comprennent des adresses de destination et de source ainsi que des informations de commande de réseau et des valeurs de hachage pour la détection d'erreurs. Les processeurs 3704 peuvent être n'importe quelle combinaison des éléments suivants : processeur, cœur, unité de traitement graphique (GPU), matrice de portes programmable par l'utilisateur (FPGA), circuit intégré spécifique d'application (ASIC), ou autre dispositif matériel programmable permettant la programmation de l'interface réseau 3700. À titre d'exemple, une "interface réseau intelligente" ou SmartNIC peut fournir des capacités de traitement de paquets dans l'interface réseau à l'aide des processeurs 3704. Dans certains exemples, les processeurs 3704 peuvent être mis en œuvre en tant que composant de processeur pour un SmartNIC. L'allocateur de paquets 3724 peut assurer la distribution des paquets reçus pour leur traitement par plusieurs CPU ou cœurs en utilisant l'allocation de tranches de temps décrite ici ou RSS. Lorsque l'allocateur de paquets 3724 utilise le système RSS, l'allocateur de paquets 3724 peut calculer un hachage ou effectuer une autre détermination sur la base du contenu d'un paquet reçu pour déterminer quelle CPU ou quel cœur doit traiter un paquet. Un dispositif de coalescence d'interruptions 3722 peut effectuer une modération des interruptions par laquelle le dispositif de coalescence d'interruptions d'interface réseau 3722 attend l'arrivée de plusieurs paquets, ou l'expiration d'un délai d'attente, avant de générer une interruption à destination du système hôte pour traiter le(s) paquet(s) reçu(s). Une Coalescence de Segments de Réception (RSC) peut être exécutée par l'interface réseau 3700 de manière à ce que des parties de paquets entrants soient combinées en segments de paquets. L'interface réseau 3700 fournit ce paquet soumis à coalescence à une application. Un moteur d'accès direct à la mémoire (DMA) 3752 peut copier un en-tête de paquet, une charge utile de paquet et/ou un descripteur directement de la mémoire de l'hôte vers l'interface réseau ou vice versa, au lieu de copier le paquet vers un tampon intermédiaire au niveau de l'hôte, puis d'utiliser une autre opération de copie du tampon intermédiaire vers le tampon de destination. Dans certains modes de réalisation, plusieurs moteurs DMA sont disponibles pour le transfert du contenu des paquets vers une mémoire de destination associée à un dispositif hôte ou vers une mémoire de destination associée à un dispositif accélérateur. La mémoire 3710 peut être un type quelconque de dispositif de mémoire volatile ou non volatile et peut stocker une file d'attente ou des instructions quelconques utilisées pour programmer l'interface réseau 3700. La file d'attente de transmission 3706 peut comporter des données ou des références à des données devant être transmises par l'interface réseau. La file d'attente de réception 3708 peut comprendre des données ou des références à des données qui ont été reçues en provenance d'un réseau par l'interface réseau. Des files d'attente de descripteurs 3720 peuvent comprendre des descripteurs qui font référence à des données ou à des paquets dans la file d'attente de transmission 3706 ou la file d'attente de réception 3708 et à des régions de mémoire de destination correspondantes. L'interface de bus 3712 peut fournir une interface avec le dispositif hôte (non représenté). L'interface de bus 3712 peut par exemple être compatible avec une interface compatible PCI, PCI Express, PCI-x, Serial ATA et/ou USB (bien que d'autres normes d'interconnexion puissent être utilisées). Dans certains exemples, l'interface réseau 3700 peut comprendre un réseau de portes programmables par l'utilisateur (FPGA) configuré pour recevoir des commandes d'une CPU ou XPU et exécuter des commandes. La illustre un exemple de système. Le système peut utiliser des modes de réalisation décrits ici pour répartir des microservices afin d'exécuter une application au niveau d'une carte NIC, IPU, DPU ou SmartNIC. Le système 3800 comprend un processeur 3810 qui assure le traitement, la gestion des opérations et l'exécution des instructions pour le système 3800. Le processeur 3810 peut comprendre un type quelconque de microprocesseur, d'unité centrale de traitement (CPU), d'unité de traitement graphique (GPU), de cœur de traitement ou d'autres matériels de traitement pour assurer le traitement pour le système 3800, ou une combinaison de processeurs. Le processeur 3810 commande le fonctionnement global du système 3800, et peut être ou comprendre un ou plusieurs microprocesseurs programmables polyvalents ou spécialisés, des processeurs de signaux numériques (DSP), des contrôleurs programmables, des circuits intégrés spécifiques d'applications (ASIC), des dispositifs logiques programmables (PLD), ou autres, ou une combinaison de ces dispositifs. La CPU 3802 ou l'un quelconque de ses cœurs peut exécuter un environnement d'exécution virtualisé. Un environnement d'exécution virtualisé (VEE) peut comprendre au moins une machine virtuelle ou un conteneur. Les VEE peuvent s'exécuter dans des environnements de type bare metal (par exemple, à locataire unique) ou hébergés (par exemple, à locataires multiples). Une machine virtuelle (VM) peut être un logiciel qui exécute un système d'exploitation et une ou plusieurs applications. Une VM peut être définie par des spécifications, des fichiers de configuration, un fichier de disque virtuel, un fichier de configuration de mémoire vive non volatile (NVRAM) et le fichier journal, et est assistée par les ressources physiques d'une plateforme informatique hôte. Une VM peut être un OS ou un environnement d'application qui est installé sur un logiciel, qui imite le matériel dédié. L'utilisateur final a la même expérience sur une machine virtuelle que sur un matériel dédié. Un logiciel spécialisé, appelé hyperviseur, émule entièrement la CPU, la mémoire, le disque dur, le réseau et les autres ressources matérielles du client PC ou du serveur, ce qui permet aux machines virtuelles de partager les ressources. L'hyperviseur peut émuler plusieurs plateformes matérielles virtuelles qui sont isolées les unes des autres, ce qui permet aux machines virtuelles d'exécuter des systèmes d'exploitation Linux®, FreeBSD, VMWare ou Windows® Server sur le même hôte physique sous-jacent. Un conteneur peut être un ensemble logiciel d'applications, de configurations et de dépendances afin que les applications fonctionnent de manière fiable d'un environnement informatique à un autre. Des conteneurs peuvent partager un système d'exploitation installé sur la plateforme du serveur et s'exécuter en tant que processus isolés. Un conteneur peut être un progiciel qui contient tout ce dont le logiciel a besoin pour fonctionner, comme des outils système, des bibliothèques et des paramètres. Les conteneurs ne sont pas installés comme des logiciels traditionnels, ce qui leur permet d'être isolés des autres logiciels et du système d'exploitation proprement dit. L'isolation peut comprendre un accès autorisé d'une région de mémoire adressable ou de stockage par un conteneur particulier mais pas par un autre conteneur. Le caractère isolé des conteneurs offre plusieurs avantages. En premier lieu, le logiciel d'un conteneur s'exécutera de la même manière dans différents environnements. À titre d'exemple, un conteneur qui comprend PHP et MySQL peut fonctionner de manière identique sur un ordinateur Linux et sur une machine Windows®. En deuxième lieu, les conteneurs offrent une sécurité accrue puisque le logiciel n'affectera pas le système d'exploitation hôte. Alors qu'une application installée peut altérer les paramètres du système et modifier des ressources, telles que le registre Windows®, un conteneur ne peut modifier que les paramètres utilisés à l'intérieur du conteneur. Certains exemples de VEE peuvent comprendre CRI-O et des Conteneurs Kata. Des applications peuvent par exemple comprendre un service, un microservice, un microservice natif de nuage, une charge de travail ou un logiciel. L'une quelconque des applications peut effectuer un traitement de paquets sur la base d'un ou plusieurs des éléments suivants : kit de développement de plan de données (DPDK), kit de développement de performances de stockage (SPDK), OpenDataPlane, virtualisation de fonction réseau (NFV), réseautage défini par logiciel (SDN), cœur de paquets évolué (EPC) ou découpage en tranches de réseau 5G. Certains exemples de mise en œuvre de la NFV sont décrits dans les spécifications de l'Institut Européen des Normes de Télécommunications (ETSI) ou dans le document Open Source NFV Management and Orchestration (MANO) du groupe Open Source Mano (OSM) de l'ETSI. Une fonction de réseau virtuel (VNF) peut comprendre une chaîne de services ou une séquence de tâches virtualisées exécutées sur un matériel configurable générique tel que des pare-feu, un système de noms de domaine (DNS), une mise en cache ou une traduction d'adresses réseau (NAT) et peut s'exécuter dans des VEE. Les VNF peuvent être reliées entre elles sous la forme d'une chaîne de services. Dans certains exemples, l'EPC est une architecture de cœur spécifiée par le 3GPP, au moins pour l'accès d'Évolution à Long Terme (LTE). Le découpage du réseau 5G peut permettre le multiplexage de réseaux logiques virtualisés et indépendants sur une même infrastructure de réseau physique. Certaines applications peuvent effectuer un traitement vidéo ou un transcodage multimédia (par exemple, modifier le codage de fichiers audio, image ou vidéo). Dans un exemple, le système 3800 comprend une interface 3812 couplée à un processeur 3810, qui peut être une interface à plus grande vitesse ou une interface à haut débit pour des composants système qui ont besoin de connexions à plus grande bande passante, tels que le sous-système de mémoire 3820, les composants d'interface graphique 3840 ou les accélérateurs 3842. L'interface 3812 est un circuit d'interface, qui peut être un composant autonome ou intégré à une puce de processeur. Lorsqu'elle est présente, l'interface graphique 3840 s'interface avec des composants graphiques pour fournir un affichage visuel à un utilisateur du système 3800. Dans un exemple, l'interface graphique 3840 peut piloter un écran haute définition (HD) qui délivre une sortie à un utilisateur. Le terme de haute définition peut désigner un affichage ayant une densité de pixels d'environ 100 PPI (pixels par pouce) ou plus et peut comprendre des formats tels que full HD (par exemple, 1080p), des affichages retina, 4K (ultra-haute définition ou UHD), ou autres. Dans un exemple, l'affichage peut comprendre un affichage à écran tactile. Dans un exemple, l'interface graphique 3840 génère un affichage sur la base de données stockées dans une mémoire 3830 ou sur la base d'opérations exécutées par le processeur 3810 ou les deux. Dans un exemple, l'interface graphique 3840 génère un affichage sur la base de données stockées dans la mémoire 3830 ou sur la base d'opérations exécutées par le processeur 3810 ou les deux. Des accélérateurs 3842 peuvent être un moteur de délestage de fonctions programmable ou fixe auquel un processeur 3810 peut accéder ou qu'il peut utiliser. À titre d'exemple, un accélérateur, parmi les accélérateurs 3842, peut fournir une capacité de compression (DC), des services de cryptographie tels qu'un chiffrement à clé publique (PKE), un chiffrement, des capacités de hachage/authentification, un déchiffrement, ou d'autres capacités ou services. Dans certains modes de réalisation, en plus ou en variante, un accélérateur, parmi les accélérateurs 3842, fournit des capacités de contrôleur de sélection de champ comme décrit ici. Dans certains cas, les accélérateurs 3842 peuvent être intégrés à un connecteur de CPU (par exemple, un connecteur de carte mère ou de carte de circuit imprimé qui comprend une CPU et fournit une interface électrique avec la CPU). À titre d'exemple, les accélérateurs 3842 peuvent comprendre un processeur à un ou plusieurs cœurs, une unité de traitement graphique, une unité d'exécution logique avec cache à un ou plusieurs niveaux, des unités fonctionnelles utilisables pour exécuter indépendamment des programmes ou des fichiers, des circuits intégrés spécifiques d'applications (ASIC), des processeurs de réseaux neuronaux (NNP), une logique de commande programmable et des éléments de traitement programmables tels que des réseaux de portes programmables par l'utilisateur (FPGA). Les accélérateurs 3842 peuvent fournir plusieurs réseaux neuronaux, cœurs de processeur ou unités de traitement graphique qui peuvent être mis à disposition de modèles d'intelligence artificielle (AI) ou d'apprentissage automatique (ML). À titre d'exemple, le modèle d'AI peut utiliser ou comprendre l'un quelconque ou une combinaison des éléments suivants : schéma d'apprentissage par renforcement, schéma d'apprentissage Q, apprentissage Q profond ou système Avantage asynchrone Critique d'Acteur (A3C), un réseau neuronal combinatoire, un réseau neuronal combinatoire récurrent ou un autre modèle d'AI ou ML. De multiples réseaux neuronaux, cœurs de processeur ou unités de traitement graphique peuvent être mis à disposition pour une utilisation par des modèles d'AI ou ML. Le sous-système de mémoire 3820 constitue la mémoire principale du système 3800 et fournit un stockage pour le code devant être exécuté par le processeur 3810, ou des valeurs de données devant être utilisées dans l'exécution d'une routine. Le sous-système de mémoire 3820 peut comprendre un ou plusieurs dispositifs de mémoire 3830 tels qu'une mémoire morte (ROM), une mémoire flash, une ou plusieurs variétés de mémoire vive (RAM) telles qu'une DRAM, ou d'autres dispositifs de mémoire, ou une combinaison de ces dispositifs. La mémoire 3830 stocke et héberge, entre autres, le système d'exploitation (OS) 3832 afin de fournir une plateforme logicielle pour l'exécution d'instructions dans le système 3800. De plus, des applications 3834 peuvent s'exécuter sur la plateforme logicielle de l'OS 3832 à partir de la mémoire 3830. Les applications 3834 représentent des programmes qui ont leur propre logique opérationnelle pour effectuer l'exécution d'une ou plusieurs fonctions. Des processus 3836 représentent des agents ou des routines qui offrent des fonctions auxiliaires à l'OS 3832 ou à une ou plusieurs applications 3834 ou à une combinaison. L'OS 3832, les applications 3834 et les processus 3836 fournissent une logique sous forme logicielle permettant de fournir des fonctions au système 3800. Dans un exemple, le sous-système de mémoire 3820 comprend le contrôleur mémoire 3822, qui est un contrôleur mémoire permettant de générer et de délivrer des commandes à la mémoire 3830. Il est à noter que le contrôleur mémoire 3822 peut être une partie physique du processeur 3810 ou une partie physique de l'interface 3812. À titre d'exemple, le contrôleur mémoire 3822 peut être un contrôleur mémoire intégré, lui-même intégré sur un circuit avec le processeur 3810. Dans certains exemples, l'OS 3832 peut déterminer une capacité d'un dispositif associé à un pilote de dispositif. À titre d'exemple, l'OS 3832 peut recevoir une indication de la capacité d'un dispositif (par exemple, d'une IPU) à mettre en œuvre l'un quelconque des modes de réalisation décrits ici. L'OS 3832 peut demander à un pilote d'activer ou de désactiver la carte réseau 3850 ou une IPU pour exécuter l'une des capacités décrites ici. Dans certains exemples, l'OS 3832 peut lui-même activer ou désactiver le NIC 3850 ou une IPU pour mettre en œuvre l'une quelconque des capacités décrites ici. L'OS 3832 peut fournir des demandes (par exemple, en provenance d'une application ou d'une VM) au NIC 3850 ou à une IPU pour utiliser une ou plusieurs capacités de la carte NIC 3850 ou d'une IPU. À titre d'exemple, une application quelconque peut demander l'utilisation ou la non-utilisation de l'une des capacités décrites ici par le NIC 3850. Bien que cela ne soit pas spécifiquement illustré, il est à noter que le système 3800 peut comprendre un ou plusieurs bus ou systèmes de bus entre les dispositifs, par exemple un bus de mémoire, un bus graphique, des bus d'interface, ou autres. Les bus ou autres lignes de signaux peuvent coupler des composants entre eux par voie de communication ou électriquement, ou coupler des composants à la fois par voie de communication et électriquement. Les bus peuvent comprendre des lignes de communication physiques, des connexions point à point, des ponts, des adaptateurs, des contrôleurs ou d'autres circuits ou une combinaison de ceux-ci. Les bus peuvent par exemple comprendre un ou plusieurs bus système, un bus d'Interconnexion de Composants Périphériques (PCI), un bus HyperTransport ou un bus d'architecture standard de l'industrie (ISA), un bus d'interface système de petit ordinateur (SCSI), un bus série universel (USB) ou un bus à la norme 1394 de l'Institute of Electrical and Electronics Engineers (IEEE). Dans un exemple, le système 3800 comprend une interface 3814, qui peut être couplée à l'interface 3812. Dans un exemple, l'interface 3814 constitue un circuit d'interface qui peut comprendre des composants autonomes et des circuits intégrés. Dans un exemple, de multiples composants d'interface utilisateur ou composants périphériques, ou les deux, sont couplés à l'interface 3814. Une interface réseau 3850 permet au système 3800 de communiquer avec des dispositifs distants (par exemple, des serveurs ou d'autres dispositifs informatiques) par le biais d'un ou plusieurs réseaux. L'interface réseau 3850 peut comprendre un adaptateur Ethernet, des composants d'interconnexion sans fil, des composants d'interconnexion de réseaux cellulaires, un bus USB (bus série universel), ou d'autres interfaces filaires ou sans fil basées sur des normes ou propriétaires. L'interface réseau 3850 peut transmettre des données à un dispositif distant, cela pouvant comprendre l'envoi de données stockées en mémoire. L'interface réseau 3850 peut recevoir des données en provenance d'un dispositif distant, cela pouvant comprendre le stockage en mémoire des données reçues. Divers modes de réalisation peuvent être utilisés en relation avec l'interface réseau 3850, le processeur 3810 et le sous-système de mémoire 3820. Dans un exemple, le système 3800 comprend une ou plusieurs interface(s) d'entrée/sortie (I/O) 3860. L'interface I/O 3860 peut comprendre un ou plusieurs composants d'interface par lesquels un utilisateur interagit avec le système 3800 (par exemple, une interface audio, alphanumérique, tactile ou autre). L'interface de périphérique 3870 peut comprendre une interface matérielle quelconque non mentionnée spécifiquement ci-dessus. Le terme de périphérique désigne de manière générale des dispositifs qui se connectent de manière dépendante au système 3800. Une connexion dépendante est une connexion pour laquelle le système 3800 fournit la plateforme logicielle ou la plateforme matérielle, ou les deux, sur laquelle l'opération s'exécute, et avec laquelle un utilisateur interagit. Dans un exemple, le système 3800 comprend un sous-système de stockage 3880 destiné à stocker des données de manière non volatile. Dans un exemple, dans certaines mises en œuvre du système, au moins certains composants du stockage 3880 peuvent chevaucher des composants du sous-système de mémoire 3820. Le sous-système de stockage 3880 comprend le(s) dispositif(s) de stockage 3884, qui peut(vent) être ou comporter un support classique quelconque permettant de stocker de grandes quantités de données de manière non volatile, tel qu'un ou plusieurs disques magnétiques, semi-conducteurs ou optiques, ou une combinaison de ceux-ci. Le système de stockage 3884 contient le code ou les instructions et les données 3886 dans un état persistant (la valeur est par exemple conservée même en cas d'interruption de l'alimentation du système 3800). Le système de stockage 3884 peut être considéré de manière générique comme une "mémoire", bien que la mémoire 3830 soit typiquement la mémoire d'exécution ou de fonctionnement destinée à fournir des instructions au processeur 3810. Alors que le système de stockage 3884 est non volatile, la mémoire 3830 peut comprendre une mémoire volatile (la valeur ou l'état des données est par exemple indéterminé si l'alimentation du système 3800 est interrompue). Dans un exemple, le sous-système de stockage 3880 comprend un contrôleur 3882 destiné à assurer l'interface avec le système de stockage 3884. Dans un exemple, le contrôleur 3882 est une partie physique de l'interface 3814 ou du processeur 3810 ou peut comprendre des circuits ou une logique dans le processeur 3810 et l'interface 3814. Une mémoire volatile est une mémoire dont l'état (et donc les données qui y sont stockées) est indéterminé si l'alimentation du dispositif est interrompue. Une mémoire volatile dynamique nécessite le rafraîchissement des données stockées dans le dispositif pour maintenir son état. Un exemple de mémoire volatile dynamique comprend une DRAM (Dynamic Random Access Memory), ou une variante telle qu'une DRAM synchrone (SDRAM). Un autre exemple de mémoire volatile comprend un cache ou une mémoire statique à accès direct (SRAM). Un sous-système de mémoire tel que décrit ici peut être compatible avec un certain nombre de technologies de mémoire, telles que DDR3 (Double Data Rate version 3, version originale publiée par le JEDEC (Joint Electronic Device Engineering Council) le 27 juin 2007). DDR4 (DDR version 4, spécification initiale publiée en septembre 2012 par le JEDEC), DDR4E (DDR version 4), LPDDR3 (Low Power DDR version3, JESD209-3B, août 2013 par le JEDEC), LPDDR4) LPDDR version 4, JESD209-4, publiée initialement par le JEDEC en août 2014), WIO2 (Wide Input/output version 2, JESD229-2 publiée initialement par le JEDEC en août 2014, HBM (High Bandwidth Memory, JESD325, initialement publié par le JEDEC en octobre 2013, LPDDR5 (actuellement en cours de discussion par le JEDEC), HBM2 (HBM version 2), actuellement en cours de discussion par le JEDEC, ou autres, ou des combinaisons de technologies de mémoire, et des technologies basées sur des dérivés ou des extensions de ces spécifications. Les normes JEDEC sont disponibles à l'adresse www.jedec.org. Un dispositif de mémoire non volatile (NVM) est une mémoire dont l'état est déterminé même si l'alimentation du dispositif est interrompue. Dans un mode de réalisation, le dispositif NVM peut comprendre un dispositif de mémoire adressable par blocs, tel que les technologies NAND, ou plus spécifiquement, une mémoire flash NAND à plusieurs niveaux de seuil (par exemple, Cellule à un Seul Niveau ("SLC"), Cellule à Niveaux Multiples ("MLC"), Cellule à Quatre Niveaux ("QLC", Quad-Level Cell), Cellule à Trois Niveaux ("TLC"), ou toute autre NAND). Un dispositif NVM peut également comprendre un dispositif de mémoire tridimensionnelle à points de croisement adressables par octets et à écriture sur place, ou un autre dispositif NVM à écriture sur place adressable par octets (également appelé mémoire persistante), tel qu'une mémoire à changement de phase (PCM) à un ou plusieurs niveaux ou une mémoire à changement de phase avec commutateur (PCMS), une mémoire Intel® Optane™, des dispositifs NVM qui utilisent un matériau à changement de phase de chalcogénure (par exemple, un verre de chalcogénure), une mémoire résistive comprenant une base d'oxyde métallique, une base de vacance d'oxygène et une mémoire à accès direct à pont conducteur (CB-RAM), une mémoire à nanofils, une mémoire à accès aléatoire ferroélectrique (FeRAM, FRAM), une mémoire à accès direct magnétorésistive (MRAM) qui intègre la technologie des memristors, une MRAM à couple de transfert de spin (STT), un dispositif à base de mémoire à jonction magnétique spintronique, un dispositif à base de jonction à effet tunnel magnétique (MTJ), un dispositif à base de DW (Domain Wall) et de SOT (Spin Orbit Transfer), un dispositif de mémoire à base de thyristor, ou une combinaison de n'importe lesquels des dispositifs ci-dessus, ou une autre mémoire. Une source d'alimentation (non représentée) fournit de l'énergie aux composants du système 2000. Plus précisément, la source d'alimentation s'interface typiquement avec une ou plusieurs alimentations électriques dans le système 2000 pour fournir de l'énergie aux composants du système 2000. Dans un exemple, l'alimentation électrique comprend un adaptateur AC à DC (courant alternatif à courant continu) qui se branche sur une prise murale. Cette alimentation en courant alternatif peut être une source d'énergie renouvelable (par exemple, de l'énergie solaire). Dans un exemple, la source d'alimentation comprend une source d'alimentation en courant continu, telle qu'un convertisseur externe de courant alternatif en courant continu. Dans un exemple, la source d'alimentation ou l'alimentation en énergie comprend un matériel de charge sans fil destiné à charger par proximité au moyen d'un champ de charge. Dans un exemple, la source d'alimentation peut comprendre une batterie interne, une alimentation en courant alternatif, une alimentation basée sur le mouvement, une alimentation solaire ou une source à pile à combustible. Dans un exemple, le système 3800 peut être mis en œuvre à l'aide de traîneaux de calcul interconnectés composés de processeurs, de mémoires, de stockages, d'interfaces réseau et d'autres composants. Des connexions à haut débit peuvent être utilisées telles que : Ethernet (IEEE 802. 3), accès direct à la mémoire à distance (RDMA), InfiniBand, Protocole RDMA sur Internet à Réseau Étendu (iWARP), Protocole de Contrôle de Transmission (TCP), Protocole de Datagramme Utilisateur (UDP), Connexions Internet rapides UDP (QUIC), RDMA sur Ethernet Convergé (RoCE), Peripheral Component Interconnect express (PCIe), Intel® QuickPath Interconnect (QPI), Intel® Ultra Path Interconnect (UPI), Intel® On-Chip System Fabric (IOSF), Omnipath, Compute Express Link (CXL), HyperTransport, Infinity Fabric (IF), NVLink, interconnexion Advanced Microcontroller Bus Architecture (AMBA), OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, DisplayPort, embedded DisplayPort, MIPI, HDMI, Infinity Fabric (IF), et leurs successeurs ou variantes. Certains modes de réalisation présentés ici peuvent être mis en œuvre dans divers types d'équipements informatiques et de réseautage, tels que des commutateurs, des routeurs, des bâtis et des serveurs lames, comme ceux qui sont utilisés dans un environnement de centre de données et/ou de ferme de serveurs. Les serveurs utilisés dans les centres de données et les fermes de serveurs comprennent des configurations de serveurs en réseau telles que des serveurs en bâti ou des serveurs lames. Ces serveurs sont interconnectés en communication par le biais de diverses installations de réseau, telles que le partitionnement d'ensembles de serveurs en réseaux locaux (LAN) avec des installations de commutation et de routage appropriées entre les LAN pour former un intranet privé. À titre d'exemple, les installations d'hébergement en nuage utilisent généralement de grands centres de données dotés d'une multitude de serveurs. Une lame comprend une plateforme informatique distincte qui est configurée pour exécuter des fonctions de type serveur, c'est-à-dire un "serveur sur une carte". En conséquence, chaque lame comprend des composants communs aux serveurs classiques, notamment une carte de circuit imprimé principale (carte principale) fournissant un câblage interne (par exemple, des bus) pour coupler des circuits intégrés (IC) appropriés et d'autres composants montés sur la carte. Dans certains exemples, l'interface réseau et d'autres modes de réalisation décrits ici peuvent être utilisés en liaison avec une station de base (par exemple, 3G, 4G, 5G et ainsi de suite), une macro-station de base (par exemple, des réseaux 5G), une picostation (par exemple, un point d'accès compatible IEEE 802.11), une nanostation (par exemple, pour des applications Point-à-MultiPoint (PtMP)), des centres de données sur site, des centres de données hors site, des éléments de réseau de périphérie, des éléments de réseau en brouillard, et/ou des centres de données hybrides (par exemple, un centre de données qui utilise la virtualisation, le nuage et un réseau défini par logiciel pour délivrer des charges de travail d'applications parmi des centres de données physiques et des environnements multi-nuages distribués). Divers exemples peuvent être mis en œuvre en utilisant des éléments matériels, des éléments logiciels ou une combinaison des deux. Dans certains exemples, les éléments matériels peuvent comprendre des dispositifs, des composants, des processeurs, des microprocesseurs, des circuits, des éléments de circuit (par exemple, des transistors, des résistances, des condensateurs, des inductances, etc.), des circuits intégrés, des ASIC, des PLD, des DSP, des FPGA, des unités de mémoire, des portes logiques, des registres, des dispositifs à semi-conducteurs, des puces, des micropuces, des jeux de puces, etc. Dans certains exemples, les éléments logiciels peuvent comprendre des composants logiciels, des programmes, des applications, des programmes informatiques, des programmes d'application, des programmes système, des programmes machine, des logiciels de système d'exploitation, des intergiciels, des microprogrammes, des modules logiciels, des routines, des sous-programmes, des fonctions, des méthodes, des procédures, des interfaces logicielles, des API, des jeux d'instructions, du code informatique, des segments de code, des segments de code informatique, des mots, des valeurs, des symboles, ou toute combinaison de ceux-ci. La détermination du fait de savoir si un exemple est mis en œuvre à l'aide d'éléments matériels et/ou d'éléments logiciels peut varier en fonction d'un nombre quelconque de facteurs, tels que la vitesse de calcul souhaitée, les niveaux de puissance, les tolérances thermiques, le bilan des cycles de traitement, les débits de données d'entrée, les débits de données de sortie, les ressources de mémoire, les vitesses des bus de données et d'autres contraintes de conception ou de performances, comme souhaité pour une mise en œuvre donnée. Il est à noter que les éléments matériels, micrologiciels et/ou logiciels peuvent être désignés collectivement ou individuellement ici par les termes de "module" ou de "logique". Un processeur peut être une ou plusieurs combinaisons d'un automate fini matériel, d'une logique de commande numérique, d'une unité centrale de traitement, ou de tout élément matériel, micrologiciel et/ou logiciel. Certains exemples peuvent être mis en œuvre à l'aide ou sous la forme d'un article de fabrication ou d'au moins un support lisible par ordinateur. Un support lisible par ordinateur peut comprendre un support de stockage non transitoire destiné à stocker une logique. Dans certains exemples, le support de stockage non transitoire peut comprendre un ou plusieurs types de supports de stockage lisibles par ordinateur capables de stocker des données électroniques, notamment une mémoire volatile ou non volatile, une mémoire amovible ou non amovible, une mémoire effaçable ou non effaçable, une mémoire inscriptible ou réinscriptible, et autres. Dans certains exemples, la logique peut comprendre divers éléments logiciels, tels que des composants logiciels, des programmes, des applications, des programmes informatiques, des programmes d'application, des programmes système, des programmes machine, des logiciels de système d'exploitation, des intergiciels, des microprogrammes, des modules logiciels, des routines, des sous-programmes, des fonctions, des méthodes, des procédures, des interfaces logicielles, des API, des jeux d'instructions, du code informatique, des segments de code, des segments de code informatique, des mots, des valeurs, des symboles, ou toute combinaison de ceux-ci. Selon certains exemples, un support lisible par ordinateur peut comprendre un support de stockage non transitoire destiné à stocker ou à maintenir des instructions qui, lorsqu'elles sont exécutées par une machine, un dispositif informatique ou un système, amènent la machine, le dispositif informatique ou le système à mettre en œuvre des procédés et/ou des opérations conformément aux exemples décrits. Les instructions peuvent comprendre tout type de code approprié, tel qu'un code source, un code compilé, un code interprété, un code exécutable, un code statique, un code dynamique, et autres. Les instructions peuvent être mises en œuvre selon un langage informatique, une méthode ou une syntaxe prédéfinis, pour demander à une machine, un dispositif ou un système informatique d'exécuter une certaine fonction. Les instructions peuvent être mises en œuvre à l'aide d'un langage de programmation quelconque approprié de haut niveau, de bas niveau, orienté objet, visuel, compilé et/ou interprété. Un ou plusieurs aspects d'au moins un exemple peuvent être mis en œuvre par des instructions représentatives stockées sur au moins un support lisible par machine, qui représente diverses logiques dans le processeur, qui, lorsqu'elles sont lues par une machine, un dispositif informatique ou un système, amènent la machine, le dispositif informatique ou le système à créer une logique destinée à mettre en œuvre les techniques décrites ici. De telles représentations, connues sous le nom de "cœurs IP", peuvent être stockées sur un support tangible lisible par machine et fournies à divers clients ou installations de fabrication pour être chargées dans les machines de fabrication qui produisent réellement la logique ou le processeur. Les apparitions des expressions "un exemple" ou "exemple" ne se réfèrent pas nécessairement toutes au même exemple ou au même mode de réalisation. Tout aspect décrit ici peut être combiné avec tout autre aspect ou aspect semblable décrit ici, indépendamment du fait que les aspects soient décrits par rapport à une même figure ou à un même élément. La division, l'omission ou l'inclusion de fonctions par blocs représentées dans les figures annexées n'implique pas que les composants matériels, les circuits, les logiciels et/ou les éléments permettant de mettre en œuvre ces fonctions soient nécessairement divisés, omis ou inclus dans les modes de réalisation. Certains exemples peuvent être décrits en utilisant les expressions "couplé" et "connecté" ainsi que leurs dérivés. Ces termes ne sont pas nécessairement considérés comme synonymes les uns des autres. Par exemple, les descriptions utilisant les termes "connecté" et/ou "couplé" peuvent indiquer que deux éléments ou plus sont en contact physique ou électrique direct l'un avec l'autre. Toutefois, le terme "couplé" peut également signifier que deux éléments ou plus ne sont pas en contact direct l'un avec l'autre, mais qu'ils coopèrent ou interagissent néanmoins l'un avec l'autre. Les termes "premier", "deuxième" etc. utilisés ici ne désignent pas un ordre, une quantité ou une importance quelconque, mais servent plutôt à distinguer un élément d'un autre. Les termes "un" et "une" ne désignent pas ici une limitation de la quantité, mais indiquent plutôt la présence d'au moins l'un des éléments auxquels il est fait référence. Le terme "validé" utilisé ici en référence à un signal indique un état du signal dans lequel le signal est actif, et qui peut être atteint en appliquant n'importe quel niveau logique, soit 0 logique, soit 1 logique, au signal. Les termes "suivre" ou "après" peuvent désigner le fait de suivre immédiatement ou de succéder à un ou plusieurs autres événements. D'autres séquences d'étapes peuvent également être réalisées selon d'autres modes de réalisation. En outre, des étapes supplémentaires peuvent être ajoutées ou supprimées selon les applications particulières. Une combinaison quelconque de modifications peut être utilisée et une personne normalement compétente dans l'art, bénéficiant de la présente divulgation, comprendrait les nombreuses variantes, modifications et autres modes de réalisation de celle-ci. Une formulation disjonctive telle que l'expression "au moins l'un de X, Y, ou Z", sauf indication contraire spécifique, est comprise dans son contexte comme étant utilisée de manière générale pour indiquer qu'un élément, un terme, etc. peut être soit X, soit Y, soit Z, ou toute combinaison de ceux-ci (par exemple, X, Y et/ou Z). Par conséquent, ce langage disjonctif n'est généralement pas destiné à, et ne doit pas impliquer que certains modes de réalisation exigent qu'au moins l'un de X, au moins l'un de Y, ou au moins l'un de Z soit présent. En outre, une formulation conjonctive telle que l'expression "au moins l'un de X, Y, et Z", sauf indication contraire spécifique, doit également être comprise comme signifiant X, Y, Z ou toute combinaison de ceux-ci, y compris "X, Y et/ou Z". Des exemples illustratifs des dispositifs, systèmes et procédés décrits ici sont présentés ci-après. Un mode de réalisation des dispositifs, systèmes et procédés peut comprendre un ou plusieurs des exemples décrits ci-après, et toute combinaison de ceux-ci. Des organigrammes tels qu'illustrés ici fournissent des exemples de séquences de diverses actions de processus. Les organigrammes peuvent indiquer des opérations destinées à être exécutées par une routine logicielle ou microprogrammée, ainsi que des opérations physiques. Dans certains modes de réalisation, un organigramme peut illustrer l'état d'un automate fini (FSM), qui peut être mis en œuvre sous forme matérielle et/ou logicielle. Bien que représenté sous la forme d'une séquence ou d'un ordre particulier, sauf indication contraire, l'ordre des actions peut être modifié. En effet, les modes de réalisation présentés à titre d'illustration ne doivent être compris qu'à titre d'exemple, le processus peut être réalisé dans un ordre différent, et certaines actions peuvent être réalisées en parallèle. En outre, dans divers modes de réalisation, une ou plusieurs actions peuvent être omises ; ainsi, toutes les actions ne sont pas nécessaires dans tous les modes de réalisation. D'autres flux de traitement sont possibles. Divers composants décrits ici peuvent constituer un moyen d'exécuter les opérations ou les fonctions décrites. Chaque composant décrit ici peut comprendre des logiciels, des matériels ou une combinaison de ceux-ci. Les composants peuvent être mis en œuvre sous forme de modules logiciels, de modules matériels, de matériel spécialisé (par exemple, un matériel spécifique d'application, des circuits intégrés spécifiques d'application (ASIC), des processeurs de signaux numériques (DSP), etc. L'exemple 1 comprend un système comportant : une Unité de Traitement d'Infrastructure (IPU) qui comprend : des circuits d'interface destinés à assurer un couplage de communication avec une plateforme ; des circuits d'interface réseau destinés à assurer un couplage de communication avec un support réseau ; et des circuits destinés à exposer des services d'infrastructure auxquels des microservices peuvent accéder pour la composition de fonctions. L'exemple 2 comprend un exemple quelconque dans lequel les services d'infrastructure comprennent des capacités de routeur, équilibreur de charge, pare-feu, TCP, transport fiable, maillage de services, transformation de données, authentification, qualité de service (QoS), sécurité, mesure de télémétrie, journalisation d'événements, déclenchement et gestion de flux de données, placement de données ou planification de tâches de ressources sur une XPU, un stockage, une mémoire, ou une CPU. L'exemple 3 comprend un exemple quelconque dans lequel l'IPU est couplée par voie de communication auxdits un ou plusieurs nœuds composites, et dans lequel l'IPU doit recevoir un appel de fonction de n'importe quel logiciel ou dispositif sur lesdits un ou plusieurs nœuds composites. L'exemple 4 comprend un exemple quelconque dans lequel l'IPU est couplée par voie de communication auxdits un ou plusieurs nœuds composites sur une même puce, par l'intermédiaire d'une ou plusieurs interfaces de dispositif, ou par l'intermédiaire d'un réseau ou d'une matrice d'interconnexion. L'exemple 5 comprend un exemple quelconque dans lequel les circuits d'interface réseau comprennent un SmartNIC doté d'un ou plusieurs processeurs à fonction programmable ou fixe pour effectuer un délestage d'opérations qui auraient pu être effectuées par une unité centrale de traitement (CPU). L'exemple 6 comprend un exemple quelconque dans lequel les opérations comprennent une ou plusieurs des opérations suivantes : tâches de parallélisation de données, gestion de plateforme et de dispositif, collecte de télémétrie distribuée, traçage, journalisation et surveillance, mise en application de qualité de service (QoS), maillage de services, sérialisation et désérialisation, conversion de taille et de format des données, validation de plage, mise en application de politique d'accès, ou sécurité inter-nœuds et intra-nœuds. L'exemple 7 comprend un exemple quelconque dans lequel le ou les processeur(s) à fonction programmable ou fixe comprend/comprennent des moteurs d'accélération qui fournissent une accélération flexible et programmable pour effectuer des opérations en virgule flottante, des opérations tensorielles ou d'intelligence artificielle (AI) et d'Apprentissage Automatique intensifs ou d'inférence. L'exemple 8 comprend un exemple quelconque dans lequel l'IPU est intégrée à au moins une unité centrale de traitement (CPU) ou XPU dans un système sur puce. L'exemple 9 comprend un exemple quelconque dans lequel l'IPU est physiquement séparée d'au moins une CPU ou XPU et connectée par l'intermédiaire d'une interface de dispositif. L'exemple 10 comprend un exemple quelconque dans lequel les circuits destinés à exposer les services d'infrastructure auxquels les microservices doivent accéder pour la composition de fonctions sont destinés à exécuter des services d'infrastructure de sécurité, les services d'infrastructure de sécurité comprenant un ou plusieurs des éléments suivants : Racine de Confiance (RoT), services d'attestation, enclaves sécurisées, stockage de clés de chiffrement, points d'extrémité de chiffrement de protocole pour des interfaces de liaison et des interfaces réseau connectant l'IPU à d'autres nœuds composites, interface de plan de commande, interfaces d'automates finis sur dispositifs, qui peuvent être configurées individuellement et isolées d'autres interfaces de dispositifs, attestation, autorisation, contrôle d'accès, journalisation, filtrage de journaux, journalisation immuable, fonctions de concentrateur de sécurité pour la confidentialité inter-XPU et l'isolation d'identité et d'informations, courtage de visibilité des données entre des clients multiples pour un traitement coopératif, mise en application de politiques et de services de sécurité, notamment des listes de contrôle d'accès, une limitation de débit, une détection d'intrusion ou des attaques par déni de service distribuées. L'exemple 11 comprend un exemple quelconque dans lequel l'IPU fait partie d'un système sur puce (SoC), et dans lequel les services d'infrastructure de sécurité comprennent des interfaces sécurisées et chiffrées pour des interfaces externes à partir du SoC de l'IPU, notamment la mémoire. L'exemple 12 comprend un exemple quelconque dans lequel l'IPU est destinée à réduire la contamination du cache et de la bande passante de l'XPU tout en libérant l'utilisation de cœurs de calcul polyvalents. L'exemple 13 comprend un exemple quelconque dans lequel les circuits destinés à exposer des services d'infrastructure sont destinés à effectuer un placement de données en mettant à disposition et en stockant des données dans une mémoire ou un dispositif de stockage physiquement proche de l'endroit où elles seront traitées. L'exemple 14 comprend un exemple quelconque dans lequel les services d'infrastructure comprennent des opérations de trajet de données I/O, notamment : chiffrement, authentification, compression, routage, mise en application de politique, Inspection Approfondie de Paquets, accélération des accès directs à la mémoire à distance (RDMA), délestage de protocoles de réseau, transport fiable, contrôle de congestion, qualité de service (QoS), échantillonnage, réplication/multidiffusion, trajets multiples, traduction d'adresses réseau (NAT), ou pare-feu. L'exemple 15 comprend un exemple quelconque dans lequel les circuits destinés à exposer des services d'infrastructure doivent déclencher et gérer des flux de données comprenant des accès mémoire unificateurs à une mémoire partagée locale ou distante, les accès mémoire unificateurs comprenant un chiffrement, un contrôle d'accès, un remappage d'adresse, une gestion de cache, un accès fiable, des commandes atomiques ou une gestion de mémoire persistante. L'exemple 16 comprend un exemple quelconque, et comprend un nœud géré comprenant un ou plusieurs nœuds composites, un nœud composite comprenant des ressources informatiques qui sont couplées logiquement, les ressources informatiques comprenant des dispositifs de mémoire, des dispositifs de stockage de données, des unités accélératrices ou des processeurs polyvalents, les ressources du ou des nœud(s) composite(s) étant utilisée(s) collectivement dans l'exécution d'une charge de travail et l'exécution de la charge de travail étant mise en œuvre par un groupe de microservices. L'exemple 17 comprend un exemple quelconque, et comporte un appareil comprenant : une unité de traitement d'infrastructure (IPU) comprenant : des circuits d'interface destinés à assurer un couplage de communication avec une plateforme ; des circuits d'interface réseau destinés à assurer un couplage de communication avec un support de réseau ; et des circuits comprenant une passerelle vers une ou plusieurs ressources, la passerelle devant recevoir une demande d'exécution d'une charge de travail pour amener la passerelle à gérer l'exécution de la charge de travail par allocation de microservices pour une exécution sur la ou les ressource(s). L'exemple 18 comprend un exemple quelconque dans lequel la passerelle comprend : un circuit de contrôle d'accès destiné à déterminer s'il faut accorder ou refuser l'accès à tout service ou microservice à la charge de travail qui fournit l'API, et dans lequel le circuit de contrôle d'accès comprend un processeur de plan de commande. L'exemple 19 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à authentifier la charge de travail pour déterminer s'il faut accorder ou refuser l'accès à tout service ou microservice à la charge de travail qui fournit l'API. L'exemple 20 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à allouer des ressources informatiques pour exécuter un ou plusieurs services ou microservices pour la charge de travail, les ressources informatiques comprenant un ou plusieurs éléments suivants : une XPU, une unité centrale de traitement, une unité de traitement graphique, une unité de traitement graphique polyvalente, des accélérateurs, des caches, des système de stockage, une mémoire, une mémoire persistante ou une mémoire non volatile. L'exemple 21 comprend un exemple quelconque dans lequel des accélérateurs effectuent une ou plusieurs des opérations suivantes : traitement de paquets, inférence d'apprentissage automatique, cryptographie, sécurité, compression ou vérification à base de chaîne de blocs. L'exemple 22 comprend un exemple quelconque dans lequel une partie des ressources informatiques se trouve à l'intérieur de l'IPU et dans lequel ladite partie des ressources informatiques est accessible à l'IPU par l'intermédiaire des circuits d'interface réseau ou des circuits d'interface. L'exemple 23 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à partitionner des ressources informatiques en plusieurs zones pour assurer une isolation entre des ressources informatiques exécutant un ou plusieurs microservices ou services pour la charge de travail et un ou plusieurs microservices ou services exécutés pour une deuxième charge de travail, la deuxième charge de travail étant associée à un locataire différent de celui de la charge de travail. L'exemple 24 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à fournir un ou plusieurs microservices ou services pour la charge de travail avec accès à un réseau physique ou à une matrice de calcul physique et à au moins l'une des multiples zones. L'exemple 25 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à réallouer des ressources informatiques exécutant un service ou des microservices pour la charge de travail afin d'essayer d'atteindre un accord de niveau de service (SLA), des objectifs de niveau de service (SLO), un objectif de qualité de service (SQO), une qualité de service (QoS), une sécurité, une haute disponibilité, une gestion des pannes ou une allocation efficace de ressource informatiques applicables. L'exemple 26 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à effectuer une télémétrie, une journalisation, une surveillance, un traçage pour la surveillance des performances, le débogage et la facturation de services et microservices exécutés pour la charge de travail. L'exemple 27 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à effectuer une conversion de format des données associées à la charge de travail avant de fournir les données en vue de leur traitement par un service ou un microservice associé à la charge de travail. L'exemple 28 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à effectuer la traduction d'une instruction de la charge de travail avant de fournir l'instruction en vue de son exécution par un service ou un microservice associé à la charge de travail. L'exemple 29 comprend un exemple quelconque dans lequel la passerelle comprend : des circuits destinés à effectuer une traduction de protocole pour un paquet associé à la charge de travail avant de fournir le paquet en vue de son traitement par un service ou un microservice associé à la charge de travail. L'exemple 30 comprend un exemple quelconque et comporte des circuits destinés à allouer des ressources informatiques pour exécuter un ou plusieurs services ou microservices pour la charge de travail, les ressources informatiques comprenant un ou plusieurs des éléments suivants : une XPU, une unité centrale de traitement, une unité de traitement graphique, une unité de traitement graphique polyvalente, des accélérateurs, des caches, un système de stockage, une mémoire, une mémoire persistante ou une mémoire non volatile, et des circuits destinés à gérer une séquence d'exécution de services ou de microservices par les ressources informatiques allouées. L'exemple 31 comprend un exemple quelconque et comporte des circuits destinés à allouer des ressources informatiques pour exécuter un ou plusieurs services ou microservices pour la charge de travail et un serveur ou un commutateur de bâti couplé aux circuits d'interface, le serveur ou le commutateur de bâti comprenant une partie des ressources informatiques. L'exemple 32 comprend un exemple quelconque dans lequel la passerelle est destinée à multiplexer des interfaces par le biais d'interfaces virtuelles qui peuvent être mappées vers différentes instances virtuelles sur des ressources en utilisant des communications chiffrées. L'exemple 33 comprend un exemple quelconque et comprend une deuxième IPU comportant : des circuits de matrice de calcul destinés à fournir un couplage de communication avec une plateforme ; des circuits de matrice de stockage destinés à fournir un couplage de stockage avec une plateforme ; des circuits d'interface réseau destinés à fournir un couplage de communication avec un support de réseau ; et des circuits destinés à fournir une passerelle pour qu'une charge de travail accède à des services ou à des microservices à l'aide d'une interface de programme d'application (API), les circuits d'interface réseau de la deuxième IPU étant couplés par voie de communication avec l'IPU. L'exemple 34 comprend un exemple quelconque dans lequel l'IPU et la deuxième IPU partagent un domaine de mémoire et des files d'attente de travail et de données. L'exemple 35 comprend un exemple quelconque dans lequel l'IPU doit diriger l'utilisation des ressources informatiques d'une deuxième IPU ou des ressources informatiques couplées à la deuxième IPU. L'exemple 36 comprend un exemple quelconque dans lequel les communications entre l'IPU et la deuxième IPU ont lieu au moyen de files d'attente partagées. L'exemple 37 comprend un exemple quelconque dans lequel l'IPU et la deuxième IPU fournissent une isolation cryptographique et par contrôle d'accès à des services sur différents nœuds pour différentes charges de travail. L'exemple 38 comprend un exemple quelconque dans lequel l'IPU et la deuxième IPU fournissent une isolation de sécurité à travers différentes zones pour différentes charges de travail. L'exemple 39 comprend un exemple quelconque et comporte un appareil doté d'une unité de traitement d'infrastructure (IPU) comprenant : une unité de traitement destinée à fournir un domaine de sécurité séparé pour un locataire, qui isole les données et les processus du locataire d'un autre locataire, et à fournir un domaine de sécurité pour un service d'infrastructure qui est séparé d'un domaine de sécurité d'un locataire. L'exemple 40 comprend un exemple quelconque dans lequel un locataire comporte un ou plusieurs des éléments suivants : un client identifié de manière unique, un environnement de type bare metal, une machine virtuelle, un conteneur, un microservice, une interface de programme d'application (API), un appel de procédure à distance (RPC) ou un bloc de code d'exécution. L'exemple 41 comprend un exemple quelconque dans lequel les services d'infrastructure comprennent des ressources intérieures à l'IPU et des ressources désagrégées d'une plateforme, qui peuvent être utilisées en toute confiance. L'exemple 42 comprend un exemple quelconque et comporte une racine de confiance matérielle qui fournit à une charge de travail un accès à un trajet ou à une infrastructure de traitement et permet l'accès à des domaines informatiques confidentiels. L'exemple 43 comprend un exemple quelconque et comporte une racine de confiance matérielle destinée à fournir un proxy à une charge de travail pour accéder à des ressources sécurisées. L'exemple 44 comprend un exemple quelconque dans lequel l'unité de traitement doit fournir une interface limitée par l'intermédiaire d'une interface de programmation d'application (API). L'exemple 45 comprend un support lisible par ordinateur comportant une ou plusieurs instructions qui, si elles sont exécutées par un ou plusieurs processeurs, font en sorte que lesdits processeurs : exécutent un pilote qui doit indiquer la disponibilité de capacités d'une unité de traitement d'infrastructure (IPU) à exposer des services et des dispositifs d'infrastructure auxquels des microservices doivent accéder pour la composition de fonctions en relation avec l'exécution d'une charge de travail à partir d'une application, d'un environnement d'exécution virtualisé ou d'un dispositif. Système comprenant : un nœud géré comprenant un ou plusieurs nœuds composites, dans lequel un nœud composite comprend des ressources informatiques qui sont couplées logiquement, dans lequel les ressources informatiques comprennent des dispositifs de mémoire, des dispositifs de stockage de données, des dispositifs accélérateurs ou des processeurs polyvalents, dans lequel des ressources provenant d'un ou plusieurs nœuds composites sont utilisées collectivement dans l'exécution d'une charge de travail, et dans lequel l'exécution de la charge de travail est mise en œuvre par un groupe de microservices ; et une Unité de Traitement d'Infrastructure (IPU) qui expose des services d'infrastructure auxquels les microservices peuvent accéder pour la composition de fonctions. Système selon la revendication 1, dans lequel les services d'infrastructure comprennent des capacités de routeur, équilibreur de charge, pare-feu, transport TCP/fiable, maillage de services, transformation de données, authentification, qualité de service (QoS), services d'infrastructure de sécurité, mesure de télémétrie, journalisation d'événements, déclenchement et gestion de flux de données, placement de données ou planification de tâches de ressources sur une XPU, un stockage, une mémoire, ou une unité centrale de traitement (CPU). Système selon la revendication 1, dans lequel l'IPU comprend au moins un contrôleur d'interface réseau ou SmartNIC doté d'un ou plusieurs processeurs à fonction programmable ou fixe pour effectuer le délestage d'opérations qui auraient pu être effectuées par une unité centrale de traitement (CPU). Système selon la revendication 3, dans lequel les opérations comprennent les suivantes : tâches de parallélisation de données, gestion de plateforme et de dispositif, télémétrie, traçage, journalisation et surveillance distribués inter-nœuds et intra-nœuds, mise en application de qualité de service (QoS), maillage de services, traitement de données notamment sérialisation et une désérialisation, transformation y compris conversion de taille et de format, validation de plage, mise en application de politique d'accès, ou sécurité distribuée inter-nœuds et intra-nœuds. Système selon la revendication 3, dans lequel les opérations comprennent des moteurs d'accélération intégrés qui fournissent une accélération flexible et programmable pour délester et améliorer les performances pour des opérations en virgule flottante par seconde (FLOPS)/des opérations tensorielles par seconde (TOPS), ou l'intelligence artificielle (AI) et l'Apprentissage Automatique intensifs. Système selon la revendication 2, dans lequel les services d'infrastructure de sécurité comprennent les suivants : Racine de Confiance (RoT), services d'attestation, enclaves sécurisées, stockage de clés de chiffrement et de tâches de gestion de clés achevées, points d'extrémité de chiffrement de protocole pour des interfaces de liaison et des interfaces réseau qui connectent l'IPU à d'autres nœuds composites dans le système, interface de plan de commande distincte, interfaces d'automates finis sur dispositifs, qui sont configurées individuellement et isolées d'autres interfaces de dispositifs, attestation, autorisation, contrôle d'accès, journalisation, filtrage de journaux, journalisation immuable, fonctions de concentrateur de sécurité pour la confidentialité inter-XPU et l'isolation d'identité et d'informations, courtage de visibilité des données entre des clients multiples pour un traitement coopératif, matrices d'interconnexion de réseau et d'entrée-sortie (IO), ou mise en application passive ou active de politiques et de services de sécurité, dans lequel la mise en application de politiques et de services de sécurité comprend des listes de contrôle d'accès, une limitation de débit, un contrôle d'accès, une détection d'intrusion ou des attaques par déni de service distribuées. Système selon la revendication 6, dans lequel l'IPU est un système sur puce (SoC), et dans lequel le SoC comprend une mémoire, et dans lequel les services de sécurité comprennent des interfaces sécurisées et chiffrées pour des interfaces externes par rapport au SoC d'IPU. Système selon la revendication 1, dans lequel l'IPU est capable de réduire la contamination du cache et de la bande passante de l'XPU tout en libérant l'utilisation de cœurs de calcul polyvalents, et dans lequel l'IPU est capable de réaliser une intégration croisée de l'utilisation de dispositifs d'accélération. Système selon la revendication 2, dans lequel le placement de données comprend la mise à disposition et le stockage de données dans une mémoire ou un dispositif de stockage sur un dispositif qui est à moins d'un petit nombre de bonds d'un nœud sur lequel les données seront traitées. Système selon la revendication 1, dans lequel les services d'infrastructure comprennent des opérations de trajet de données I/O, notamment : chiffrement, authentification, compression, routage, mise en application de politique, Inspection Approfondie de Paquets ou de Messages, accélération des accès directs à la mémoire à distance (RDMA), notamment RoCE ou iWARP, délestage de protocole de réseau, transport fiable, contrôle de congestion, qualité de service (QoS), échantillonnage, réplication ou multidiffusion de paquets, trajets multiples, traduction d'adresses réseau (NAT), ou pare-feu. Système selon la revendication 2, dans lequel les flux de données de déclenchement et de gestion comprennent des accès mémoire unificateurs à une mémoire partagée locale ou distante, dans lequel les accès mémoire unificateurs comprennent un chiffrement, un contrôle d'accès, un remappage d'adresse, une gestion de cache, un accès fiable, des commandes atomiques ou une gestion de mémoire persistante. Système selon l'une quelconque des revendications 1-11, dans lequel l'IPU est couplée par voie de communication auxdits un ou plusieurs nœuds composites, et dans lequel l'IPU est capable de recevoir un appel de fonction en provenance d'un logiciel ou dispositif quelconque sur lesdits un ou plusieurs nœuds composites, dans lequel l'IPU est couplée par voie de communication auxdits un ou plusieurs nœuds composites sur une même puce, par l'intermédiaire d'une ou plusieurs interfaces de dispositif, ou par l'intermédiaire d'un réseau ou d'une matrice d'interconnexion. Système selon l'une quelconque des revendications 1-12, dans lequel l'IPU est intégrée à au moins une unité centrale de traitement (CPU) ou XPU. Système selon l'une quelconque des revendications 1-12, dans lequel l'IPU est physiquement séparée d'au moins une unité centrale de traitement (CPU) ou XPU. Appareil d'unité de traitement d'infrastructure (IPU), comprenant : au moins une interface réseau ; au moins une interface hôte ; et au moins un processeur, dans lequel au moins un processeur parmi le ou les processeurs est configuré pour exécuter des instructions afin d'exposer des services d'infrastructure auxquels doivent accéder des microservices pour la composition de fonctions et dans lequel les microservices mettent en œuvre une exécution de charge de travail sur un ou plusieurs nœuds composites, un nœud composite comprenant des ressources informatiques qui sont couplées logiquement, les ressources informatiques comprenant des dispositifs de mémoire, des dispositifs de stockage de données, des dispositifs accélérateurs ou des processeurs polyvalents. Appareil selon la revendication 15, dans lequel les services d'infrastructure comprennent des capacités de routeur, équilibreur de charge, pare-feu, transport TCP/fiable, maillage de services, transformation de données, authentification, qualité de service (QoS), services d'infrastructure de sécurité, mesure de télémétrie, journalisation d'événements, déclenchement et gestion de flux de données, placement de données ou planification de tâches de ressources sur une XPU, un stockage, une mémoire, ou une unité centrale de traitement (CPU). Appareil selon la revendication 15, dans lequel l'IPU est couplée par voie de communication auxdits un ou plusieurs nœuds composites, et dans lequel l'IPU est capable de recevoir un appel de fonction en provenance d'un logiciel ou dispositif quelconque sur lesdits un ou plusieurs nœuds composites. Appareil selon la revendication 17, dans lequel l'IPU est couplée par voie de communication auxdits un ou plusieurs nœuds composites sur une même puce, par l'intermédiaire d'une ou plusieurs interfaces de dispositif, ou par l'intermédiaire d'un réseau ou d'une matrice d'interconnexion. Appareil de la revendication 15, dans lequel l'IPU comprend au moins un Contrôleur d'Interface Réseau ou un SmartNIC doté d'un ou plusieurs processeurs à fonction programmable ou fixe pour effectuer un délestage d'opérations qui auraient pu être effectuées par une unité centrale de traitement (CPU). Appareil selon la revendication 19, dans lequel les opérations comprennent les suivantes : tâches de parallélisation de données, gestion de plateforme et de dispositif, télémétrie distribuée inter-nœuds et intra-nœuds, traçage, journalisation et surveillance, mise en application de qualité de service (QoS), maillage de services, traitement de données notamment sérialisation et désérialisation, transformation notamment conversion de taille et de format, validation de plage, mise en application de politique d'accès, ou sécurité distribuée inter-nœuds et intra-nœuds. Appareil selon la revendication 19, dans lequel les opérations comprennent des moteurs d'accélération intégrés qui fournissent une accélération flexible et programmable pour délester et améliorer les performances pour des opérations en virgule flottante par seconde (FLOPS) ou des opérations tensorielles par seconde (TOPS), ou l'intelligence artificielle (AI) et l'Apprentissage Automatique intensifs. Appareil selon la revendication 16, dans lequel les services d'infrastructure de sécurité comprennent les suivants : Racine de Confiance (RoT), des services d'attestation, des enclaves sécurisées, stockage de clés de chiffrement et de tâches de gestion de clés achevées, points d'extrémité de chiffrement de protocole pour des interfaces de liaison et des interfaces réseau qui connectent l'IPU à d'autres nœuds composites dans le système, interface de plan de commande distincte, interfaces d'automates finis sur dispositifs, qui sont configurées individuellement et isolées d'autres interfaces de dispositifs, attestation, autorisation, contrôle d'accès, journalisation, filtrage de journaux, journalisation immuable, fonctions de concentrateur de sécurité pour la confidentialité inter-XPU et l'isolation d'identité et d'informations, courtage de visibilité des données entre des clients multiples pour un traitement coopératif, matrices d'interconnexion de réseau et d'entrée-sortie (IO), ou mise en application passive ou active de politiques et de services de sécurité, dans lequel la mise en application de politiques et de services de sécurité comprend des listes de contrôle d'accès, une limitation de débit, un contrôle d'accès, une détection d'intrusion ou des attaques par déni de service distribuées. Appareil selon la revendication 22, dans lequel l'IPU est un système sur puce (SoC), et dans lequel le SoC comprend une mémoire, et dans lequel les services de sécurité comprennent des interfaces sécurisées et chiffrées pour des interfaces externes par rapport au SoC d'IPU. Appareil selon la revendication 15, dans lequel l'IPU est capable de réduire la contamination du cache et de la bande passante de l'XPU tout en libérant l'utilisation de cœurs de calcul polyvalents, et dans lequel l'IPU est capable de réaliser une intégration croisée de l'utilisation de dispositifs d'accélération. Appareil selon la revendication 16, dans lequel le placement de données comprend la mise à disposition et le stockage de données dans une mémoire ou un dispositif de stockage sur un dispositif qui est à un plus petit nombre de bonds d'un nœud sur lequel les données seront traitées. Appareil selon la revendication 16, dans lequel les services d'infrastructure comprennent des opérations de trajet de données I/O, notamment : chiffrement, authentification, compression, routage, mise en application de politique, Inspection Approfondie de Paquets ou de Messages, accélération des accès directs à la mémoire à distance (RDMA), notamment RoCE ou iWARP, délestage de protocole de réseau, transport fiable, contrôle de congestion, qualité de service (QoS), échantillonnage, réplication ou multidiffusion de paquets, trajets multiples, traduction d'adresses réseau (NAT), ou pare-feu. Appareil selon la revendication 16, dans lequel les flux de données de déclenchement et de gestion comprennent des accès mémoire unificateurs à une mémoire partagée locale ou distante, dans lequel les accès mémoire unificateurs comprennent un chiffrement, un contrôle d'accès, un remappage d'adresse, une gestion de cache, un accès fiable, des commandes atomiques ou une gestion de mémoire persistante. Appareil de l'une quelconque des revendications 15-27, dans lequel l'IPU est intégrée à au moins l'une d'une unité centrale de traitement (CPU) ou d'une XPU ou l'IPU est physiquement séparée d'au moins l'une d'une CPU ou d'une XPU.