Système d'exploitation distribué

Un système d'exploitation distribué est un logiciel système sur un ensemble de nœuds de calcul indépendants, en réseau , communicants et physiquement séparés. Ils gèrent des tâches qui sont traitées par plusieurs processeurs. Chaque nœud individuel contient un sous-ensemble logiciel spécifique du système d'exploitation global agrégé. Chaque sous-ensemble est un composite de deux fournisseurs de services distincts. noyau minimal omniprésent , ou micro-noyau , qui contrôle directement le matériel de ce nœud. Le deuxième est un ensemble de composants de gestion système de niveau supérieur qui coordonnent les activités individuelles et collaboratives du nœud. Ces composants font abstraction des fonctions du micro-noyau et prennent en charge les applications utilisateur.

Le micro-noyau et l'ensemble des composants de gestion fonctionnent ensemble. Ils soutiennent l'objectif du système d'intégrer plusieurs ressources et fonctionnalités de traitement dans un système efficace et stable. Cette intégration transparente de nœuds individuels dans un système global est appelée transparence ou image système unique ; décrivant l'illusion fournie aux utilisateurs de l'apparence du système global comme une entité informatique unique.

Un système d'exploitation distribué fournit les services et fonctionnalités essentiels requis d'un système d'exploitation, mais ajoute des attributs et des configurations particulières pour lui permettre de prendre en charge des exigences supplémentaires telles qu'une évolutivité et une disponibilité accrues. Pour un utilisateur, un système d'exploitation distribué fonctionne de manière similaire à un système d'exploitation monolithique à nœud unique . C'est-à-dire que, bien qu'il soit constitué de plusieurs nœuds, il apparaît aux utilisateurs et aux applications comme un nœud unique.

La séparation des fonctionnalités minimales au niveau du système des services modulaires supplémentaires au niveau de l'utilisateur permet une « séparation du mécanisme et de la politique ». Le mécanisme et la politique peuvent être interprétés simplement comme « ce qui est fait » par rapport à « comment quelque chose est fait », respectivement. Cette séparation augmente la flexibilité et l'évolutivité.

À chaque emplacement (généralement un nœud), le noyau fournit un ensemble minimal complet d'utilitaires de niveau nœud nécessaires au fonctionnement du matériel et des ressources sous-jacents d'un nœud. Ces mécanismes comprennent l'allocation, la gestion et la disposition des ressources d'un nœud, les processus, la communication et les fonctions de support de gestion des entrées/sorties . Au sein du noyau, le sous-système de communication est de la plus haute importance pour un système d'exploitation distribué.

Dans un système d'exploitation distribué, le noyau prend souvent en charge un ensemble minimal de fonctions, notamment la gestion de l'espace d'adressage de bas niveau , la gestion des threads et la communication interprocessus (IPC). Un noyau de cette conception est appelé micro-noyau . Sa nature modulaire améliore la fiabilité et la sécurité, des caractéristiques essentielles pour un système d'exploitation distribué.

Les composants de gestion du système sont des processus logiciels qui définissent les politiques du nœud . Ces composants font partie du système d'exploitation en dehors du noyau. Ils assurent la communication de niveau supérieur, la gestion des processus et des ressources, la fiabilité, les performances et la sécurité. Les composants correspondent aux fonctions d'un système à entité unique, ajoutant la transparence requise dans un environnement distribué.

La nature distribuée du système d'exploitation nécessite des services supplémentaires pour prendre en charge les responsabilités d'un nœud vis-à-vis du système global. De plus, les composants de gestion du système assument les responsabilités « défensives » de fiabilité, de disponibilité et de persistance. Ces responsabilités peuvent entrer en conflit les unes avec les autres. Une approche cohérente, une perspective équilibrée et une compréhension approfondie du système global peuvent aider à identifier les rendements décroissants . La séparation de la politique et du mécanisme atténue ces conflits.

L'architecture et la conception d'un système d'exploitation distribué doivent atteindre à la fois les objectifs des nœuds individuels et ceux du système global. L'architecture et la conception doivent être abordées de manière cohérente avec la séparation des politiques et des mécanismes. Ce faisant, un système d'exploitation distribué tente de fournir un cadre informatique distribué efficace et fiable permettant à l'utilisateur de ne connaître que très peu les efforts de commande et de contrôle sous-jacents.

La collaboration à plusieurs niveaux entre un noyau et les composants de gestion du système, et à son tour entre les différents nœuds d'un système d'exploitation distribué, constitue le défi fonctionnel du système d'exploitation distribué. C'est le point du système qui doit maintenir une parfaite harmonie des objectifs, tout en maintenant une déconnexion complète entre l'intention et la mise en œuvre. Ce défi est l'occasion pour le système d'exploitation distribué de produire les fondations et le cadre d'un système fiable, efficace, disponible, robuste, extensible et évolutif. Cependant, cette opportunité a un coût très élevé en termes de complexité.

Dans un système d'exploitation distribué, le degré exceptionnel de complexité inhérente pourrait facilement rendre l'ensemble du système insupportable pour n'importe quel utilisateur. En tant que tel, le prix logique de la réalisation d'un système d'exploitation distribué doit être calculé en termes de maîtrise d'énormes quantités de complexité dans de nombreux domaines et à de nombreux niveaux. Ce calcul inclut la profondeur, l'ampleur et la portée des investissements de conception et de la planification architecturale nécessaires pour réaliser même la mise en œuvre la plus modeste.

Ces considérations de conception et de développement sont cruciales et impitoyables. Par exemple, une compréhension approfondie de l'architecture globale et des détails de conception d'un système d'exploitation distribué est requise à un stade exceptionnellement précoce. Un ensemble exhaustif de considérations de conception est inhérent au développement d'un système d'exploitation distribué. Chacune de ces considérations de conception peut potentiellement affecter de nombreuses autres à un degré significatif. Cela conduit à un effort massif d'approche équilibrée, en termes de considérations de conception individuelles et de nombreuses de leurs permutations. Pour aider à cet effort, la plupart s'appuient sur l'expérience et la recherche documentées en matière de puissance de calcul distribuée.

Les efforts de recherche et d'expérimentation ont véritablement commencé dans les années 1970 et se sont poursuivis tout au long des années 1990, l'intérêt ayant culminé à la fin des années 1980. Un certain nombre de systèmes d'exploitation distribués ont été introduits au cours de cette période ; cependant, très peu de ces implémentations ont obtenu un succès commercial même modeste.

Les implémentations fondamentales et pionnières des concepts de composants de systèmes d'exploitation distribués primitifs remontent au début des années 1950. Certaines de ces étapes individuelles n'étaient pas directement axées sur l'informatique distribuée et, à l'époque, beaucoup n'avaient peut-être pas conscience de leur impact important. Ces efforts pionniers ont jeté des bases importantes et ont inspiré la poursuite des recherches dans des domaines liés à l'informatique distribuée.

Au milieu des années 1970, la recherche a permis des avancées importantes dans le domaine du calcul distribué. Ces avancées ont fourni une base solide et stable aux efforts qui se sont poursuivis jusque dans les années 1990.

La prolifération accélérée des recherches sur les systèmes multiprocesseurs et multicœurs a conduit à une résurgence du concept de système d'exploitation distribué.

L'un des premiers efforts fut le DYSEAC , un ordinateur synchrone à usage général . Dans l'une des premières publications de l' Association for Computing Machinery , en avril 1954, un chercheur du National Bureau of Standards (aujourd'hui National Institute of Standards and Technology ( NIST )) présenta une spécification détaillée du DYSEAC. L'introduction se concentrait sur les exigences des applications prévues, notamment les communications flexibles, mais mentionnait également d'autres ordinateurs :

Enfin, les dispositifs externes pourraient même inclure d’autres ordinateurs à grande échelle employant le même langage numérique que le DYSEAC. Par exemple, le SEAC ou d’autres ordinateurs similaires pourraient être reliés au DYSEAC et, grâce à l’utilisation de programmes coordonnés, pourraient être amenés à travailler ensemble en coopération mutuelle sur une tâche commune… Par conséquent, l’ordinateur peut être utilisé pour coordonner les diverses activités de tous les dispositifs externes en une opération d’ensemble efficace.

—  ALAN L. LEINER, Spécifications du système pour le DYSEAC

La spécification a discuté de l'architecture des systèmes multi-ordinateurs, préférant le peer-to-peer plutôt que le maître-esclave.

Chaque membre d'un tel groupe interconnecté d'ordinateurs distincts est libre à tout moment de lancer et d'envoyer des ordres de contrôle spéciaux à l'un de ses partenaires dans le système. En conséquence, le contrôle de surveillance sur la tâche commune peut être initialement réparti de manière lâche dans tout le système, puis temporairement concentré dans un ordinateur, ou même transféré rapidement d'une machine à l'autre selon les besoins. …les diverses fonctions d'interruption qui ont été décrites sont basées sur la coopération mutuelle entre l'ordinateur et les dispositifs externes qui lui sont subordonnés, et ne reflètent pas simplement une simple relation maître-esclave.

—  ALAN L. LEINER, Spécifications du système pour le DYSEAC

Il s'agit de l'un des premiers exemples d'ordinateur à commande distribuée. Le Département de l'Armée a rapporté qu'il était fiable et qu'il avait passé tous les tests d'acceptation en avril 1954. Il a été terminé et livré à temps, en mai 1954. Il s'agissait d'un « ordinateur portable », logé dans un semi-remorque , avec 2 véhicules d'accompagnement et 6 tonnes de capacité de réfrigération .

Décrit comme un système d'entrée-sortie expérimental, le Lincoln TX-2 mettait l'accent sur des dispositifs d'entrée-sortie flexibles et opérationnels simultanément, c'est-à -dire sur la multiprogrammation . La conception du TX-2 était modulaire, prenant en charge un degré élevé de modification et d'extension.

Le système utilisait la technique de programmation à séquences multiples. Cette technique permettait à plusieurs compteurs de programme de s'associer chacun à l'une des 32 séquences possibles de code de programme. Ces séquences explicitement prioritaires pouvaient être entrelacées et exécutées simultanément, affectant non seulement le calcul en cours, mais également le flux de contrôle des séquences et la commutation des périphériques. De nombreuses discussions portaient sur le séquençage des périphériques.

Similaires au DYSEAC, les appareils TX-2 programmés séparément peuvent fonctionner simultanément, augmentant ainsi le débit . La pleine puissance de l'unité centrale était disponible pour n'importe quel appareil. Le TX-2 était un autre exemple de système présentant un contrôle distribué, son unité centrale n'ayant pas de contrôle dédié.

L'un des premiers efforts visant à abstraire l'accès à la mémoire a été celui des cellules intercommunicantes, où une cellule était composée d'un ensemble d' éléments de mémoire . Un élément de mémoire était essentiellement une bascule électronique binaire ou un relais . Dans une cellule, il y avait deux types d'éléments, un symbole et une cellule . Chaque structure de cellule stocke les données dans une chaîne de symboles, composée d'un nom et d'un ensemble de paramètres . Les informations sont liées par des associations de cellules.

La théorie soutenait que l'adressage était un niveau d'indirection inutile et sans valeur . L'accès aux informations se faisait de deux manières : la récupération directe et la récupération croisée. La récupération directe accepte un nom et renvoie un ensemble de paramètres. La récupération croisée se projette via des ensembles de paramètres et renvoie un ensemble de noms contenant le sous-ensemble de paramètres donné. Cela était similaire à une structure de données de table de hachage modifiée qui autorisait plusieurs valeurs (paramètres) pour chaque clé (nom).

Cette configuration était idéale pour les systèmes distribués. La projection à temps constant à travers la mémoire pour le stockage et la récupération était intrinsèquement atomique et exclusive . Les caractéristiques distribuées intrinsèques de la mémoire cellulaire seraient inestimables. L'impact sur l' utilisateur , le matériel / l'appareil ou les interfaces de programmation d'application était indirect. Les auteurs envisageaient des systèmes distribués, en déclarant :

Nous avons voulu présenter ici les idées de base d'un système logique distribué avec... le concept macroscopique de conception logique, loin de la numérisation, de la recherche, de l'adressage et du comptage, est tout aussi important. Nous devons, à tout prix, nous libérer du fardeau des problèmes locaux détaillés qui ne conviennent qu'à une machine située en bas de l'échelle évolutive des machines.

—  Chung-Yeol (CY) Lee, Cellules intercommunicantes, base d'un ordinateur logique distribué

Algorithmes de synchronisation évolutive sur multiprocesseurs à mémoire partagée

Mesures d'un système de fichiers distribué
Cohérence de la mémoire dans les systèmes de mémoire virtuelle partagée

Sagas de transactions

Mémoire transactionnelle
Transactions de mémoire composables
Mémoire transactionnelle : support architectural pour structures de données sans verrouillage
Mémoire transactionnelle logicielle pour structures de données de taille dynamique
Mémoire transactionnelle logicielle

OceanStore : une architecture pour le stockage persistant à l'échelle mondiale

Vote pondéré pour les données répliquées
Consensus en présence de synchronie partielle

Vérifications de cohérence
Le problème des généraux byzantins
Processeurs à arrêt automatique : une approche pour la conception de systèmes informatiques tolérants aux pannes

Récupération Snapshots distribués : détermination des états globaux des systèmes distribués Récupération optimiste dans les systèmes distribués

Pour mieux illustrer ce point, examinons trois architectures de système : centralisée, décentralisée et distribuée. Dans cet examen, considérons trois aspects structurels : l'organisation, la connexion et le contrôle. L'organisation décrit les caractéristiques de l'agencement physique d'un système. La connexion couvre les voies de communication entre les nœuds. Le contrôle gère le fonctionnement des deux considérations précédentes.

Un système centralisé possède un seul niveau de structure, où tous les éléments constitutifs dépendent directement d'un seul élément de contrôle. Un système décentralisé est hiérarchique. Le niveau inférieur réunit des sous-ensembles d'entités d'un système. Ces sous-ensembles d'entités se combinent à leur tour à des niveaux supérieurs, pour finalement aboutir à un élément maître central. Un système distribué est un ensemble d'éléments autonomes sans notion de niveaux.

Les systèmes centralisés connectent les composants directement à une entité centrale maîtresse selon un modèle en étoile. Un système décentralisé (également appelé système réseau ) intègre des chemins directs et indirects entre les éléments constitutifs et l'entité centrale. Il est généralement configuré sous forme de hiérarchie avec un seul chemin le plus court entre deux éléments. Enfin, le système d'exploitation distribué ne nécessite aucun modèle ; des connexions directes et indirectes sont possibles entre deux éléments quelconques. Considérez les phénomènes des années 1970 de « l'art des cordes » ou d'un dessin au spirographe comme un système entièrement connecté , et la toile d'araignée ou le réseau routier inter-États entre les villes américaines comme des exemples de systèmes partiellement connectés .

Les systèmes centralisés et décentralisés ont des flux de connexion dirigés vers et depuis l'entité centrale, tandis que les systèmes distribués communiquent selon des chemins arbitraires. C'est la notion centrale de la troisième considération. Le contrôle consiste à attribuer des tâches et des données aux éléments du système en équilibrant l'efficacité, la réactivité et la complexité.

Les systèmes centralisés et décentralisés offrent davantage de contrôle, facilitant potentiellement l'administration en limitant les options. Les systèmes distribués sont plus difficiles à contrôler explicitement, mais ils s'adaptent mieux horizontalement et offrent moins de points de défaillance à l'échelle du système. Les associations sont conformes aux besoins imposés par leur conception, mais pas par le chaos organisationnel.

La transparence ou l'image d'un système unique fait référence à la capacité d'une application à traiter le système sur lequel elle fonctionne, indépendamment du fait qu'il soit distribué ou non, et indépendamment du matériel ou d'autres détails d'implémentation. De nombreux domaines d'un système peuvent bénéficier de la transparence, notamment l'accès, l'emplacement, les performances, la dénomination et la migration. La prise en compte de la transparence affecte directement la prise de décision dans tous les aspects de la conception d'un système d'exploitation distribué. La transparence peut imposer certaines exigences et/ou restrictions sur d'autres considérations de conception.

Les systèmes peuvent éventuellement violer la transparence à des degrés divers pour répondre aux exigences spécifiques des applications. Par exemple, un système d'exploitation distribué peut présenter un disque dur sur un ordinateur comme « C: » et un lecteur sur un autre ordinateur comme « G: ». L'utilisateur n'a pas besoin de connaître les pilotes de périphérique ou l'emplacement du lecteur ; les deux périphériques fonctionnent de la même manière, du point de vue de l'application. Une interface moins transparente peut nécessiter que l'application sache quel ordinateur héberge le lecteur. Domaines de transparence :

• Transparence de localisation – La transparence de localisation comprend deux aspects distincts de la transparence, la transparence de dénomination et la mobilité de l'utilisateur. La transparence de dénomination exige que rien dans les références physiques ou logiques à une entité système ne révèle une quelconque indication de la localisation de l'entité, ou de sa relation locale ou distante avec l'utilisateur ou l'application. La mobilité de l'utilisateur nécessite le référencement cohérent des entités système, quel que soit l'emplacement système d'où provient la référence.
• Transparence de l'accès – Les entités système locales et distantes doivent rester indiscernables lorsqu'elles sont visualisées via l'interface utilisateur. Le système d'exploitation distribué maintient cette perception grâce à l'exposition d'un mécanisme d'accès unique pour une entité système, que cette entité soit locale ou distante pour l'utilisateur. La transparence impose que toute différence dans les méthodes d'accès à une entité système particulière, qu'elle soit locale ou distante, doit être à la fois invisible et indétectable par l'utilisateur.
• Transparence de la migration – Les ressources et les activités migrent d’un élément à un autre sous le contrôle exclusif du système et sans que l’utilisateur/l’application en ait connaissance ou n’intervienne.
• Transparence de réplication – Le processus ou le fait qu'une ressource a été dupliquée sur un autre élément se produit sous le contrôle du système et sans la connaissance ou l'intervention de l'utilisateur/de l'application.
• Transparence de la concurrence – Les utilisateurs/applications ne sont pas conscients de la présence/des activités des autres utilisateurs et ne sont pas affectés par celles-ci.
• Transparence des pannes – Le système est responsable de la détection et de la correction des pannes du système. Aucune connaissance/action de l'utilisateur n'est impliquée, à part attendre que le système résolve le problème.
• Transparence des performances – Le système est responsable de la détection et de la correction des insuffisances de performances locales ou globales. Notez que les politiques système peuvent privilégier certains utilisateurs/classes d'utilisateurs/tâches par rapport à d'autres. Aucune connaissance ou interaction de l'utilisateur n'est impliquée.
• Transparence de la taille/échelle – Le système est responsable de la gestion de sa portée géographique, du nombre de nœuds et du niveau de capacité des nœuds sans aucune connaissance ou interaction requise de l'utilisateur.
• Transparence des révisions – Le système est responsable des mises à niveau, des révisions et des modifications de l’infrastructure du système sans que l’utilisateur en ait connaissance ou n’intervienne.
• Transparence du contrôle – Le système est responsable de fournir toutes les informations système, constantes, propriétés, paramètres de configuration, etc. dans une apparence, une connotation et une dénotation cohérentes à tous les utilisateurs et applications.
• Transparence des données – Le système est chargé de fournir des données aux applications sans que l'utilisateur n'ait connaissance ou n'ait à intervenir sur l'endroit où le système les stocke.
• Transparence du parallélisme – Le système est responsable de l'exploitation de toute capacité à paralléliser l'exécution des tâches sans que l'utilisateur en ait connaissance ou n'interagisse. Il s'agit sans doute de l'aspect le plus difficile de la transparence, décrit par Tanenbaum comme le « Saint Graal » des concepteurs de systèmes distribués.

La communication interprocessus (IPC) est l'implémentation de la communication générale, de l'interaction entre les processus et du flux de données entre les threads et/ou les processus au sein d'un nœud et entre les nœuds d'un système d'exploitation distribué. Les exigences de communication intra-nœud et inter-nœud déterminent la conception IPC de bas niveau, qui est l'approche typique pour implémenter des fonctions de communication qui prennent en charge la transparence. En ce sens, la communication interprocessus est le concept sous-jacent le plus important dans les considérations de conception de bas niveau d'un système d'exploitation distribué.

La gestion des processus fournit des politiques et des mécanismes pour un partage efficace et efficient des ressources entre les processus distribués. Ces politiques et mécanismes prennent en charge les opérations impliquant l'allocation et la désallocation de processus et de ports aux processeurs, ainsi que les mécanismes d'exécution, de suspension, de migration, d'arrêt ou de reprise de l'exécution des processus. Bien que ces ressources et opérations puissent être locales ou distantes les unes par rapport aux autres, le système d'exploitation distribué conserve l'état et la synchronisation de tous les processus du système.

Par exemple, l'équilibrage de charge est une fonction courante de gestion des processus. L'équilibrage de charge surveille les performances des nœuds et est responsable du déplacement de l'activité entre les nœuds lorsque le système est déséquilibré. L'une des fonctions d'équilibrage de charge consiste à choisir un processus à déplacer. Le noyau peut utiliser plusieurs mécanismes de sélection, notamment le choix basé sur la priorité. Ce mécanisme choisit un processus en fonction d'une politique telle que « demande la plus récente ». Le système implémente la politique

Les ressources système telles que la mémoire, les fichiers, les périphériques, etc. sont réparties sur l'ensemble d'un système et, à tout moment, l'un de ces nœuds peut avoir des charges de travail légères ou inactives. Le partage et l'équilibrage de la charge nécessitent de nombreuses décisions axées sur les politiques, allant de la recherche de processeurs inactifs, au moment de les déplacer et à ceux à déplacer. De nombreux algorithmes existent pour aider à ces décisions. Cependant, cela nécessite un deuxième niveau de politique de prise de décision pour choisir l'algorithme le mieux adapté au scénario et aux conditions entourant le scénario.

Les systèmes d'exploitation distribués peuvent fournir les ressources et les services nécessaires pour atteindre des niveaux élevés de fiabilité , ou la capacité de prévenir et/ou de récupérer des erreurs. Les pannes sont des défauts physiques ou logiques qui peuvent provoquer des erreurs dans le système. Pour qu'un système soit fiable, il doit d'une manière ou d'une autre surmonter les effets négatifs des pannes.

Les principales méthodes de gestion des pannes comprennent l'évitement des pannes , la tolérance aux pannes , la détection des pannes et la récupération des pannes . L'évitement des pannes couvre les mesures proactives prises pour minimiser l'occurrence des pannes. Ces mesures proactives peuvent prendre la forme de transactions , de réplications et de sauvegardes . La tolérance aux pannes est la capacité d'un système à continuer de fonctionner en présence d'une panne. Dans ce cas, le système doit détecter et récupérer toutes ses fonctionnalités. Dans tous les cas, toutes les actions entreprises doivent faire tout leur possible pour préserver l' image unique du système .

La disponibilité est la fraction de temps pendant laquelle le système peut répondre aux demandes.

De nombreuses mesures de référence quantifient les performances : débit, temps de réponse, achèvements de tâches par unité de temps, utilisation du système, etc. En ce qui concerne un système d'exploitation distribué, les performances se résument le plus souvent à un équilibre entre le parallélisme des processus et l'IPC. La gestion de la granularité des tâches du parallélisme dans une relation judicieuse avec les messages requis pour le support est extrêmement efficace. De plus, il est également efficace d'identifier quand il est plus avantageux de migrer un processus vers ses données, plutôt que de copier les données.

Les processus concurrents coopérants ont un besoin inhérent de synchronisation , qui garantit que les changements se produisent de manière correcte et prévisible. Trois situations de base définissent la portée de ce besoin :

• un ou plusieurs processus doivent se synchroniser à un moment donné pour qu'un ou plusieurs autres processus puissent continuer,
• un ou plusieurs processus doivent attendre une condition asynchrone pour continuer,
• ou un processus doit établir un accès exclusif à une ressource partagée.

Une synchronisation incorrecte peut entraîner plusieurs modes de défaillance, notamment la perte d' atomicité, de cohérence, d'isolement et de durabilité , le blocage , le blocage en direct et la perte de sérialisation .

La flexibilité d'un système d'exploitation distribué est renforcée par les caractéristiques modulaires du système d'exploitation distribué et par la fourniture d'un ensemble plus riche de services de niveau supérieur. L'exhaustivité et la qualité du noyau/micro-noyau simplifient la mise en œuvre de ces services et offrent potentiellement aux fournisseurs de services un plus grand choix de fournisseurs pour ces services.

Conception architecturale du système d'exploitation distribué E1
Le système d'exploitation distribué Cronus
Conception et développement du système d'exploitation distribué MINIX

Échelle et performances dans le noyau d'isolation Denali.

Le multi-noyau : une nouvelle architecture de système d'exploitation pour les systèmes multi-cœurs évolutifs.

Corey : un système d'exploitation pour plusieurs cœurs.

Almos : système d'exploitation de gestion de localité avancé pour cc-NUMA Many-Cores.

Helios : multitraitement hétérogène avec noyaux satellites.

Tessellation : partitionnement spatio-temporel dans un système d'exploitation client multicœur.