FLASH INFORMATIQUE FI

Un pas en direction de la consolidation et un autre en direction de la sécurité


Les conteneurs Solaris 10




Pascal FABBRI


1ère partie

Le concept de conteneurs Solaris a été mis au point dans les laboratoires de recherche & développement de Sun Microsystems en étroite collaboration entre les architectes et les développeurs, dans le dessein d’établir de nouveaux critères en matière de virtualisation et de consolidation dans le domaine des systèmes d’exploitation. Sun a apporté toute son expérience en tant qu’acteur majeur dans le monde Unix afin de proposer le concept de conteneur, sans aucun doute une des fonctionnalités les plus réjouissantes de Solaris 10.
Les conteneurs donnent la possibilité de créer ces environnements d’exploitation isolés (abstraction virtuelle du système d’exploitation) et de leur assigner différents projets ou groupes d’utilisateurs comme si ceux-ci étaient de véritables machines indépendantes composées de leur propre système de fichiers de leurs utilisateurs et applications. Lors de l’élaboration d’une zone, il peut être nécessaire d’allouer des ressources particulières du système -les processeurs, la mémoire et quelques autres périphériques- à l’usage exclusif d’une zone en particulier ou d’avoir toutes les zones se partageant l’ensemble des ressources du système. Une zone sera alors un environnement protégé dans lequel s’exécute les applications protégées les unes des autres en leur évitant, par exemple, de se corrompre mutuellement. Les zones coexistent à l’intérieur d’une instance du système d’exploitation, et sont habituellement contrôlées en tant qu’entités propres.
Ainsi on appelle un conteneur une zone qui emploie également le service de gestion de ressources du système d’exploitation.

Les conteneurs Solaris

Les conteneurs Solaris sont constitués d’un ensemble de technologies qui collaborent pour gérer efficacement les ressources du système, virtualiser l’environnement et, fournir aux applications un environnement d’exploitation complètement isolé et sûr. Les conteneurs Solaris incluent deux technologies : le partitionnement en zones Solaris et des outils de gestion de ressources. Les zones permettent à un administrateur de créer des environnements séparés pour les applications sur un seul et même système, tandis que la structure de gestion des ressources tient compte de l’allocation, de la gestion et de la comptabilité des ressources du système à attribuer comme le CPU [1] ou la mémoire.

Les zones Solaris

Les zones Solaris peuvent être utilisées pour créer un environnement d’exécution sûr et confiné. Une zone est une abstraction virtuelle du système d’exploitation créée à l’intérieur d’une instance unique du système Solaris. Les zones permettent d’isoler les applications et les processus du reste du système. Cette isolation augmentera la sécurité et la fiabilité des processus contenus dans une zone en empêchant celle-ci d’interférer sur les processus s’exécutant dans une autre zone.
Depuis Solaris 10 chaque système contient un environnement global général - comme les versions précédentes du système d’exploitation, appelé zone globale. La zone globale réalise deux fonctions : elle est la zone par défaut du système et la zone administrative de contrôle de l’ensemble du système. Les zones non globales sont créées par l’administrateur global.

La zone globale

La zone globale est la seule zone depuis laquelle une zone non globale peut-être configurée, installée, gérée ou désinstallée. Seule la zone globale est démarrable par l’enclenchement électrique du système. Les fonctions administratives de l’infrastructure du système comme les périphériques physique, les interfaces au réseau ou encore la reconfiguration dynamique sont seulement possibles depuis la zone globale. Des privilèges appropriés sont nécessaires aux utilisateurs comme aux processus de la zone globale pour manipuler les objets associés aux zones non globales. Ainsi, les zones non globales permettent à l’administrateur de déléguer certaines fonctions administratives pendant que lui-même maintient l’ensemble de la sécurité système.

Les zones non globales

Une zone non globale n’a pas besoin d’un CPU dédié, de périphérique physique ou d’une portion de mémoire physique et se présente comme une instance spécifique du système d’exploitation. Ces ressources sont multiplexées sur plusieurs zones [2] en exécution à l’intérieur d’un système, ou allouées par zone sur une base utilisant les fonctionnalités de répartition de ressources offertes par le système d’exploitation. Les zones peuvent être démarrées ou arrêtées sans perturber les autres zones du système.
Pour représenter l’isolement de base des processus : un processus ne peut voir, ou dialoguer, qu’avec les autres processus se trouvant dans la même zone que lui. La communication entre zones n’est possible qu’en donnant au moins une interface réseau logique à chaque zone. Une application s’exécutant dans une zone ne peut pas observer le trafic réseau d’une autre zone, et ceci même si les interfaces réseau logiques de celles-ci partagent une même interface réseau physique.
Les applications ou les outils qui nécessitent certains privilèges de gestion du système comme, par exemple, le chargement de modules du noyau ou le changement de l’adresse IP ne peuvent pas être exécutés à partir d’une zone non globale. On retiendra que de façon générale, toutes les actions qui ont un impact sur la sécurité entre zones doivent être menées depuis la zone globale.

La gestion des ressources

Une bonne consolidation ne peut être atteinte sans disposer au sein du système d’exploitation d’une bonne technique de partage du temps processeur (Time Share Scheduling). En imaginant une application qui dégage, du fait de son architecture, plusieurs files d’exécution (Multi-Thread), elle occupe pour chacune d’elle du temps en fonction de sa priorité, occupe du temps CPU pour son traitement et perd du temps à attendre la disponibilité de celui-ci. Ainsi ce type d’application ne laissera pas, voire peu de temps aux autres applications pour accomplir leurs tâches. Dans ce type de système, les performances enregistrées sont mauvaises et de surcroît imprévisibles lors de périodes de charge importante, puisqu’une instance occupe toutes les ressources. On reconnaîtra ce type de comportement par l’allongement du temps de réponse d’une application, l’accroissement du temps d’exécution d’applications habituelles ou encore à des déconnexions provoquées par des temps de réponse trop longs.
Les outils de gestion des ressources fournis avec le système d’exploitation Solaris aident à accorder les ressources du système, comme les ressources du CPU, à une application en particulier. Sur un système multiprocesseur, les microprocesseurs peuvent être partitionnés logiquement dans des ensembles de processeurs et allouer une réserve de ressources qui, à son tour peut-être mise à la disposition d’une zone Solaris. Les réserves de ressources ont la capacité de séparer les volumes de travail de sorte que la consommation des ressources de l’unité centrale de traitement soient réparties sans perte, et fournissent également un mécanisme persistant de configuration pour les ensembles de processeurs et la classe d’ordonnancement des tâches. De plus, les fonctionnalités dynamiques de réserves de ressources permettent aux administrateurs d’ajuster les ressources du système en fonction de l’évolution des demandes de volume de travail.

Les réserves de ressources

Le mécanisme de réserves de ressources s’utilisait principalement sur de gros systèmes équipés de plus de quatre CPUs. Les systèmes de plus petite taille peuvent néanmoins profiter efficacement de cette fonctionnalité pour répartir les ressources critiques du système depuis la venue des systèmes constitués de processeurs multicoeurs :

  • Le microprocesseur Sun UltraSPARC T1 - Niagara pour les intimes- accueille jusqu’à 8 coeurs comprenant chacun 4 unités de traitement, soit en pratique 32 unités de calcul simultanées cadencées entre 1 et 1,2 GHz de fréquences pour une consommation se situant entre 72 et 79 watt (en terme de fréquence brut le T1 tourne à 9,6 GHz soit 8 × 1,2).
  • Du côté AMD, deux Opteron™ double coeurs équivalent à quatre unités de calcul simultanées et, pour une fréquence de 2,6 GHz chaque coeur consomme 95 watt. Unité de calcul, unité de traitement, file d’exécution ou encore thread sont autant de synonymes qui indiquent un comportement similaire au processeur.

Chaque système contient au moins un ensemble processeur - l’ensemble processeur par défaut se constitue de tous les processeurs, ou unités de calcul, du système. D’autres ensembles processeur peuvent être dynamiquement ajoutés ou retirés sur un système en production, tout en laissant au moins un processeur à disposition de la ressource qui gère les ensembles processeur.
La définition d’un ensemble processeur n’est pas liée à un type particulier de matériel. Il est également possible d’indiquer un nombre minimum et maximum de processeurs pour une réserve de ressources, de plus des configurations multiples peuvent être définies pour s’accorder dynamiquement aux charges de travail variables liées à un ensemble d’applications confinées.
Les réserves de ressources peuvent avoir différentes classes d’ordonnancement (scheduling classes) rythmant une réserve de ressources. Les classes d’ordonnancement sont fixées par réserve de ressources. Les deux classes d’ordonnanceur les plus utilisées sont le partage équitable et le temps partagé - respectivement Fair Share Scheduler et TimeSharing Scheduler :

  • Fair Share Scheduler (FSS)  : L’ordonnanceur partage équitable alloue des ressources processeur en utilisant des parts d’unité de traitement. Le FSS s’assure que les ressources processeur soient distribuées équitablement en se basant sur la proportion de processeurs alloués à un projet en divisant les parts du projet par le nombre total des parts des projets actifs. Un projet actif est un projet dont au moins l’un des processus utilise du temps processeur.
  • TimeSharing Scheduler (TS)  : L’ordonnanceur par défaut sous Solaris, l’ordonnanceur temps partagé, tente de procurer à chaque processus un accès relativement équitable aux processeurs disponibles, en allouant le temps processeur en fonction de la priorité. Le TS ne nécessite aucune gestion, il est simple à utiliser, mais ne permet pas de garantir les performances d’une application ou d’un projet en particulier.

Tous les processus exécutés dans un conteneur sont associés à un même identificateur de projet, par analogie le projet représente le conteneur. Rapidement trois autres classes d’ordonnancement sont prises en charge par Solaris :

  • real-time  : pour les processus qui ont besoin d’un temps de réponse rapide et déterministe
  • interactive  : orienté pour des processus en interaction avec un utilisateur
  • fixed priority  : Pour des processus exigeant que les priorités ne soient pas dynamiquement ajustées par le système Une des grandes différences entre les conteneurs Solaris et les autres formes de confinement, est sa capacité de prendre en charge plusieurs classes d’ordonnancement dynamiquement et en même temps. Sur un seul et même système, on peut trouver par exemple une zone qui s’exécute avec le FSS, une seconde zone avec le TS et une dernière rythmée par un ordonnanceur interactif.

Vue d’ensemble

La capacité d’isoler les applications les unes des autres au sein d’un même serveur en toute fiabilité est cruciale pour la consolidation des charges de travail, de l’approvisionnement des applications et du partage sécurisé des ressources. De cette façon, on obtient une augmentation sensible des taux d’utilisation des serveurs, et un rehaussement de la sécurité.
D’une certaine façon, les zones sont aux systèmes d’exploitation ce que sont les sites Web virtuels aux serveurs Web. Comme les sites Web virtuels donnent le sentiment que le service Web fonctionne sur une machine propre - alors que les ressources du serveur sont partagées par plusieurs autres sites Web -, les zones donnent le sentiment d’intégrer toutes les ressources d’un système à part entière.
Si l’on imagine un système équipé de 4 processeurs, une application nécessite l’usage dédié d’un processeur et un groupe d’autres applications se partage les 3 autres processeurs restants. Ainsi on allouerait un ou plusieurs processeurs à l’usage exclusif de l’application la plus gourmande en ressources à travers sa zone et on laisserait le reste des processeurs à discrétion des autres applications qui en auraient le besoin. Au même moment on peut être certain que chacune des autres zones aura à disposition un partage raisonnable des processeurs restant en leur garantissant la disponibilité de ces partages. Ceci se réalisant par l’emploi des services de l’ordonnanceur Fair Share Scheduler.
De façon similaire, les zones peuvent avoir leur propre système de fichier (à leur usage exclusif) ou elles peuvent partager les arborescences telles que /usr, /lib, /sbin et /platform avec d’autres zones d’un même système.
Comme il est déjà écrit plus haut, il y a toujours une zone référencée comme zone globale qui représente l’installation originale de Solaris (l’environnement d’exploitation de l’installation de base de Solaris). Cette zone peut voir toutes les arborescences et tous les périphériques qui constituent le système et depuis cette zone principale toutes les autres - nommées zones non globales ou tout simplement zones - sont configurées et gérées.
Si l’on n’y prête pas attention, il est difficile de se rendre compte que l’on est bloqué à l’intérieur d’une zone utilisant seulement une partie du système. Aussi la plupart du temps, évoluer à l’intérieur d’une zone ne diffère en rien d’un système Solaris habituel. Un utilisateur peut se rendre compte qu’il ne voit pas une partition disque en suivant le chemin usuel /dev/dsk/c0t0d0s0 lorsqu’il emploie la commande df -h permettant de voir l’utilisation de l’espace disque. Il peut aussi se rendre compte de subtiles différences au résultat de la commande psrinfo -v. Presque tout le reste, évidemment, se présente comme on pourrait s’y attendre dans un système classique, comme l’examen des processus en cours, la liste du contenu des arborescences habituelles jusqu’à l’emploi des outils système, rien ne semble inhabituel et en mesure de désorienter le travail quotidien. Dans la pratique, la gestion des zones change peu l’administration d’un système. Il n’y a que trois nouvelles commandes à apprendre : zoneadm, zonecfg et zlogin avec lesquelles on établit, on gère et on utilise les zones. Une fois familiarisé avec ce petit ensemble de commandes la mise en place de zones sur un système devient aisée et le travail supplémentaire d’administration se révèle faible et sans complexité. On s’aperçoit très vite que la gestion d’un système comprenant plusieurs zones demande beaucoup moins de travail que la gestion d’un nombre équivalant de systèmes à part entière (systèmes séparés classiques).
Chaque zone comporte sa propre adresse IP (IPv4 et-ou IPv6) ainsi que sa propre arborescence de fichiers sous /etc. Le redémarrage d’une zone n’a aucune influence sur le reste du système que se soit la zone globale ou les zones non globales. De cette façon, on peut imaginer de donner tous les droits d’accès (accès root) à l’administrateur d’un service particulier contenu dans une zone sans pour autant lui laisser l’accès au reste du système. Ce modèle d’administration rend obsolète les commandes du type sudo.
Dans un prochain article seront présentées la configuration de zones et les commandes relatives à cet environnement de confinement.

Quelques modèles de consolidation

De nos jours, les applications fournissant les services de l’IT se composent d’éléments qui sont distribués à travers une multitude de serveurs communiquant entre eux par les voies du réseau. Ce modèle de gestion des services augmente sensiblement et régulièrement les frais généraux administratifs et contribue massivement au gaspillage d’énergie ; de plus, en tenant compte du nombre important d’éléments interagissant entre eux - les serveurs comme les éléments constituant le réseau -, sécuriser cet ensemble devient une tâche difficile si ce n’est impossible à concrétiser et qui demande des couches matérielles ou logicielles supplémentaires à ajouter aboutissant à un équilibre peu probable, mais très souvent instable. Pour pallier ces inconvénients, le seul recours pratique s’appelle la consolidation des services, non pas sur un système unique, mais sur un nombre restreint de systèmes de choix.
Pour une consolidation efficace, les applications doivent être gérées indépendamment. Cela suppose la possibilité d’ajuster l’utilisation des ressources, d’isoler les applications défaillantes et maintenir la sécurité entre les multiples applications contenues sur un même serveur.
Il existe une grande variété de stratégies de virtualisation permettant de parvenir à la consolidation, dont chacune peut répondre à des besoins spécifiques. Souvent il n’y a pas lieu de déployer une grande structure pour virtualiser un service ou une application, mais dans tous les cas bien connaître l’application ou l’ensemble des applications qui forment un service permettra de choisir le bon modèle de virtualisation conduisant à une consolidation aboutie.

VMware®

VMware®, que tous les spécialistes connaissent - issu d’anciens étudiants de l’EPFL -, est vaguement semblable aux conteneurs, tous deux sont très utiles à la consolidation de serveurs. Cependant, le modèle de base n’est pas le même. VMware® permet d’accueillir plusieurs instances de systèmes d’exploitation, alors que les conteneurs forment des environnements d’application isolés qui se partagent une seule instance du système d’exploitation. Comme autres différences on notera :

  • Les conteneurs sont seulement disponibles depuis Solaris™10. VMware® supporte simultanément, par exemple : Solaris™, FreeBSD, GNU/Linux - étrangement pas Debian - ou encore Windows ;
  • VMware® emploie beaucoup de ressources processeur uniquement pour la gestion des ces environnements multiples (instances), entre 5 et 15%. Le temps d’inactivité du processeur (overhead) pour la gestion des conteneurs est à peine mesurable (typiquement moins de 1%) pour quelques zones et, les applications n’ont que peu d’influence sur cette mesure ;
  • Les conteneurs n’ont aucun coût financier au-delà d’un contrat de service. Un environnement de production en VMware® coûte très vite quelques milliers de francs auxquels il faut ajouter le prix d’une licence pour chaque instance Windows, ou Red Hat accueillie sur VMware®.

Le confinement chroot

L’ancêtre du confinement, chroot (change root directory) fit son apparition dans le jeu de commande Unix1983 à la naissance de la branche 4.2BSD. À cette époque déjà, ce mécanisme très puissant offrait une granularité plus fine des privilèges et de la gestion des utilisateurs, le tout mis en marge dans un environnement sanitaire du système d’exploitation. Bien des applications sont prévues nativement pour s’intégrer à un confinement chroot, comme named [3] ou certains ftpd [4] par exemple. Chroot s’emploie aussi à d’autres fins que le confinement pur d’application, on le retrouve notamment chez les développeurs de systèmes d’exploitation pour la compilation du noyau et de ses outils, chez les administrateurs pour la restauration d’arborescence de fichiers sauvegardés avec un chemin absolu.

Le partitionnement selon Jail

FreeBSD offre un mécanisme de partitionnement appelé Jail depuis la version 4.0-Release de l’an 2000. Son principe est issu de chroot tout en étant beaucoup plus fort en permettant de rejoindre le modèle du vrai serveur virtuel en limitant les pouvoirs de l’administrateur. Une fois la prison mise en place, tout le trafic réseau transite par sa propre adresse IP et les privilèges accordés à l’administrateur sont fortement limités. Pour l’heure, Jail souffre encore de quelques imperfections ; les mécanismes de communication interprocessus [5] ne sont pas possibles, les pouvoirs de l’administrateur sont très limités, sans que l’on puisse savoir se que signifie très limité. Cependant, Jail reste une pièce maîtresse dans le partitionnement d’application au sein d’un environnement sécurisé.
Ainsi on voit que Jail offre des dispositifs proches des zones Solaris™ sans apporter d’outils d’administration ou de gestion des ressources élaborés - puisque le modèle choisi pour le partage du temps CPU est fixé lors de la compilation du noyau BSD, et n’est de ce fait pas dynamique.
Étonnamment Apple Mac OS X, malgré son héritage - FreeBSD 5.0-Release - ne propose pas d’environnement Jail.

sysjail

Le très jeune projet disponible depuis peu pour les systèmes d’exploitation Net et OpenBSD, sysjail, est similaire au Jail de FreeBSD. Cet environnement de virtualisation évolue - à la différence de Jail - en dehors du noyau (userland) afin d’emprisonner les processus. Ce mode de fonctionnement devrait pénaliser de façon significative les temps d’exécution des processus ainsi emprisonnés au contraire de Jail qui se situe au niveau du noyau FreeBSD, mais augmenter la stabilité du système lorsque des difficultés interviennent au sein d’un environnement virtualisé.

Hyperviseur Xen

Proposé par le Computer Laboratory de l’Université de Cambridge, le projet Xen s’ouvrit à la communauté open source en 2003.
Xen Source™ fédère les deux entités Xen à savoir Xen Enterprise™- commerciale -, et Xen.
Selon plusieurs sources, Xen aurait atteint sa maturité en prouvant sa stabilité à la suite de milliers d’heures de tests d’assurance qualité réalisés par un grand nombre de constructeurs. Xen fait partie maintenant de quelques distributions commerciales et non commerciales respectivement comme Novell (SuSE) et Fedora.
Xen autorise l’accès direct aux composants matériels du système et aux périphériques de stockage - comme les disques, ce qui peut potentiellement compromettre l’intégrité de ce type de confinement. Pour être exploitable, Xen nécessite que le noyau du système d’exploitation hôte soit modifié pour implémenter son modèle de confinement.

OpenVZ

OpenVZ est une solution de serveur de virtualisation au niveau du système d’exploitation basée sur le noyau GNU/Linux. Il permet à une machine physique d’exécuter plusieurs instances de systèmes d’exploitation (GNU/Linux uniquement) isolés. Cette méthode de virtualisation emploie peu de ressources pour la gestion des environnements virtuels.
Un inconvénient de cette solution est qu’elle se compose d’un noyau qui remplace celui mis en place par la distribution GNU/Linux en production.
Le noyau d’OpenVZ est un noyau GNU/Linux modifié qui implémente le concept d’environnement virtuel. La virtualisation est malheureusement un des virages que les concepteurs du noyau GNU/Linux n’ont pas vu venir, c’est probablement pour cette raison qu’il est absent et qu’il s’est vu proposé de diverses façons par des architectes venus d’autres cercles.

Virtualisation Java™

Un environnement auquel on ne pense pas, Java™ 2 Enterprise Edition (J2EE), cependant très utilisé dans les solutions Web-bases, implémente les mêmes concepts généraux en utilisant plusieurs technologies employées dans les conteneurs ou autres types de confinement. La technologie Java™ se base sur la machine virtuelle indépendante du matériel, nommée Java™ Virtual Machine (JVM), les programmes écrits en Java s’exécutent dans un environnement confiné et, lorsque ceux-ci se trouvent liés à un environnement du type serveur d’application, ils bénéficient des avantages fournis par la technologie des conteneurs.

Conclusion

Le concept de zones Solaris [6] est idéal pour des environnements qui consolident plusieurs applications sur un seul serveur. Le coût et la complexité de la gestion de machines nombreuses rendent avantageuse la consolidation d’applications sur des machines performantes et plus extensibles. Plusieurs solutions sont disponibles lorsque le moment est venu de faire le choix d’un type de consolidation à envisager. On pourra ainsi choisir dans trois catégories de solutions de consolidation de serveur :

  • Domaines et Partitions - Ces schémas de consolidation sont basés sur des solutions matérielles, comme les Domaines Sun Fire™ et les LPARs IBM (ces deux principes n’ont pas été évoqués dans cet article) ;
  • Machines virtuelles - Ces solutions de consolidation se situent au niveau des applications, comme Xen, OpenVZ ou VMware® ;
  • Partitionement de systèmes d’exploitation - Ces solutions de consolidation se placent au niveau du système d’exploitation, comme Jail de FreeBSD. Les Zones Solaris rejoignent naturellement la catégorie partitionnement de systèmes d’exploitation.

Les zones fournissent des services d’un système d’exploitation virtuel qui ressemble à différentes instances de Solaris d’utilisateurs et d’applications. Cette architecture isole les processus, cache la plate-forme sous-jacente et permet aux administrateurs d’allouer très finement l’utilisation des ressources du système.
Cette séparation contribue fortement à la mise en place d’un environnement plus sécurisé, là où de multiples applications s’animaient auparavant sur différentes machines physiques, maintenant par le concept de zones, les mêmes applications peuvent coexister dans différentes zones sur un seul système.
Il reste bien des aspects du concept de zones Solaris à explorer, que ce soit au niveau de la mise en place de liens intimes entre une zone et ZFS [7], la réplication (déplacement d’une zone d’une machine physique à une autre), les conteneurs Solaris accueillants des applications GNU/Linux ou encore la translation d’adresse pour des zones utilisant des adresses IPv4 privées.
J’espère que cet avant-goût des possibilités des zones Solaris aura convaincu le lecteur de l’intérêt de cet environnement de confinement. Le meilleur moyen d’en savoir plus reste encore de le pratiquer, en prenant la peine de parcourir les références fournies ci-dessous qui permettront de rapidement combler les lacunes de cet article.

Références

  1. Présentation au Domaine IT de l’EPFL, conduite par la société LANexpert, sur la virtualisation selon VMware®, le 3 mai 2006.
  2. systrace userland virtualisation
  3. OpenVZ, Operating System-level server virtualization
  4. Flash Informatique 2/2005 du 1er mars 2005 : Solaris 10 - Les nouvelles fonctionnalités majeures.
  5. Présentation au Domaine IT de l’EPFL conduite par Dr. Marc Hamilton, Director of Technology Sun Microsystems Global Education and Research, le 19 janvier 2005.
  6. Sun Network Computer Launch 2004-Q4, le 7 décembre 2004 à Genève
  7. Page officielle Solaris 10

[1] Central Processing Unit, ou en français : Unité Centrale de Traitement (UCT), habituellement le ou les microprocesseur(s)

[2] Les termes zone(s) et zone(s) non-globale(s) sont en principe interchangeables

[3] Le DNS : Internet Domain Name Server

[4] Transfert de fichier par Internet : Internet File Transfer Protocol

[5] IPC : Inter-Process Communication

[6] Connu sous le nom de code Kevlar chez Sun

[7] Zettabyte File System : ce système de fichiers de nouvelle génération combine un gestionnaire de volumes avec un système de fichier ayant une capacité extrêmement plus important que celle des systèmes de fichiers 32 ou 64-bits actuels.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.