Pourquoi les noyaux Unikernels sont parfaits pour les Devs

 PUBLIC VISE : ADMINISTRATION SYSTEME

PUBLIC VISE : SYS-ADMIN NOYAU KERNEL

Les Unikernels sont des images personnalisables, à amorçage d'espace d'adressage unique, composées d'une application et de la fonctionnalité de noyau minimale requise. Les réseaux uninnels actuels ont démontré des avantages substantiels en termes de performances et de sécurité par rapport aux monolithes et aux microcristaux, mais aucun n'a encore été adopté à grande échelle.

Le problème fondamental est que les unikernels actuels, qui ont été développés à partir de systèmes d'exploitation existants ou de conceptions optimistes, ont abandonné le processus évolutif de la communauté qui a fait de Linux un tel succès. Dans ce billet, nous décrivons une approche alternative que nous poursuivons dans le but de faire de unikernels une capacité évolutive de Linux et de la GNU C LIbrary (glibc), prise en charge par la communauté.

Qu'est-ce un Unikernel ?

Les Unikernels sont des systèmes d'exploitation de bibliothèques à espace d'adressage unique. Une application compilée en unikernel ne possède que les fonctionnalités requises du noyau et rien d’autre. Un tel noyau allégé rend les unikernels extrêmement légers, à la fois en termes de taille d'image et d'encombrement de la mémoire, et peut également apporter des avantages en termes de sécurité grâce à une surface d'attaque réduite. Il y a beaucoup de ces implémentations unikernel léger, par exemple, LING , IncludeOS et MirageOS . Le site Web de LING utilise 25 Mo de mémoire, car il s’appuie sur son unikernel. La machine virtuelle de base d’InclusOS commence à 1 Mo et un serveur DNS fonctionnant sur MirageOS est compilé en une image de 449 Ko.

Etant donné qu'un unikernel n'a pas besoin d'initialiser des périphériques ou des services non nécessaires à l'exécution de l'application, les temps de démarrage peuvent être très rapides. Il n'y a pas de surcharge de transition d'anneau dans les unikernels (par exemple, la surcharge de passer de l'anneau le moins privilégié 3 où les applications fonctionnent à l'anneau le plus privilégié 0 où vit le noyau) car les transitions en anneau sont nécessaires pour implémenter le multitraitement plusieurs processus.

Des améliorations supplémentaires viennent du fait que le code noyau / application peut être co-optimisé pour répondre aux besoins de l'application spécifique. Par exemple, des chercheurs du département d'informatique de l'université de Boston ont mené des expériences afin de comparer les performances de Linux et de leur unikernel spécialisé appelé Elastic Building Block Runtime ( Ebbrt ). L’application qu’ils ont choisie était Memcached, qui est un magasin de valeurs de clé basé sur la mémoire, également utilisé par Facebook pour leurs propres centres de données.. Les chercheurs ont généré des modèles d'accès représentatifs des charges de travail de Facebook et ont découvert qu'EbbRT améliore presque deux fois le débit de Memcached à une latence cible de 99% par rapport à l'exécution de Memcached sur le noyau Linux en optimisant la gestion de la mémoire, la mise en réseau et la planification du noyau. aux besoins de l'application.

Pourquoi les unikernels ne sont-ils pas plus populaires?

Compte tenu de tous les avantages, pourquoi les unikernels ne sont-ils toujours pas largement utilisés, même après des décennies d'existence? Des réponses possibles peuvent être trouvées dans la façon dont ces unikernels ont été développés. Au cours des années, différents efforts pour le développement d’un noyau ont suivi l’une des deux approches: nettoyer l’ardoise ou forger une base de code existante.

Avec l'approche de la table rase, les développeurs ont beaucoup plus de contrôle sur le code et l'API. Ils ne doivent pas nécessairement suivre l'API POSIX et peuvent utiliser des langages plus récents, comme c'est le cas pour HalVM, qui utilise Haskell. Avec une telle liberté, ces unikernels peuvent offrir de meilleurs avantages en termes de performances / sécurité.

Le problème avec cette approche est que ces unikernels abandonnent le code Linux éprouvé au combat, et avec cela, toute la communauté Linux qui maintient Linux et continue à corriger les bugs. Les nouvelles bases de code peuvent être parfaitement structurées et bien écrites, mais ne peuvent correspondre aux milliers d'années-personnes investies dans le développement de Linux au cours des décennies.

De plus, Linux est devenu le noyau idéal pour le déploiement dans le cloud et d'autres paramètres. S'éloigner de cela et développer quelque chose de complètement nouveau signifie persuader tout le monde de laisser tomber Linux. Si ces unikernels s'écartent de l'API POSIX, les logiciels hérités ne peuvent pas s'exécuter sur ces unikernels. Les applications doivent être portées ou réécrites pour différentes API non standard.

L’autre approche du développement unikernel consiste à créer une base de code du noyau existante, telle que Linux ou NetBSD, et à la supprimer pour créer un noyau. Lors de la suppression de la base de code, certains projets modifient tellement le code d'origine que les modifications ne sont pas intégrées dans les bases de code d'origine. Cela conduit essentiellement à conserver le code en tant que nouveau projet. Aucune communauté de développeurs existante ne gère le code non spécifique à une cible et peut même garantir que des cibles bien intégrées ne se brisent pas sans que le contributeur d'origine du port ne travaille plus.

Une approche progressive et communautaire

Pouvons-nous adopter une approche différente pour développer un noyau unique? Peut-il suivre l'approche adoptée par Linux, glibc et d'autres projets similaires: créer une version de travail et l'améliorer progressivement? Un tel noyau unique peut-il réellement faire partie de la base de code Linux et de la glibc, de sorte que la vaste communauté gère également le noyau unique?

De cette façon, nous serions en mesure d'utiliser l'intégralité de la base de code de Linux et de la glibc sans avoir à réinventer la roue. Cela peut fournir aux développeurs une interface Linux inchangée, avec prise en charge des pilotes de périphérique existants, des systèmes de fichiers, etc. Un tel noyau peut être déployé dans un environnement virtuel ou sur des machines sans système d'exploitation. Si nous y parvenons, nous aurons peut-être un noyau unique prenant en charge, par exemple, les GPU!

Au cours de l'été 2018, j'ai travaillé chez Red Hat en tant que stagiaire sur ce projet. Ulrich Drepper et Richard WM Jones de Red Hat, ainsi que mon conseiller de doctorat, le professeur Orran Krieger de l'Université de Boston, étaient mes superviseurs. James Cadden et Tommy Unger (équipe EbbRT de l'Université de Boston) ont également été consultés sur le projet.

Nous avons commencé avec quelques objectifs en tête. Nous voulions créer un un noyau à partir de Linux et de la glibc. L'idée était de l'accepter finalement en amont, nous devions donc apporter le moins de modifications possible aux bases de codes. Nous voulions garder l'interface Linux inchangée; toute modification (mise en réseau sans copie, par exemple) devrait intervenir une fois le projet mis en amont et passer par les processus normaux de la communauté Linux / GCC.

L'architecture que nous avons créée comportait une application et des bibliothèques d'espace utilisateur pertinentes reposant sur glibc, qui au lieu de passer des appels système au noyau, appelait des fonctions. Pour le moment, nous avons créé une bibliothèque wrapper autour des appels système pour les traduire en appels de fonction directs dans le noyau.

Pour conserver l'application et le noyau dans le même espace adresse, nous avons empêché le noyau de créer le processus init. Au lieu de cela, nous avons appelé notre code d'application à cet endroit. Enfin, tout était lié entre eux dans un seul binaire amorçable. Nous avons testé notre configuration en exécutant un simple serveur d'écho à l'intérieur du noyau unikernel dans QEMU.

Cette version initiale de notre unikernel est extrêmement prometteuse car nous n’avons changé qu’une ligne de la base de code Linux. Les modifications apportées à la gibc par Ulrich Drepper sont également minimes. Ils se trouvent dans une sous-arborescence séparée qui traduit les appels système en appels de fonction. Des changements aussi modestes pourraient augmenter nos chances d'acceptation éventuelle en amont.

Les API Linux et glibc inchangées permettent aux applications de s'exécuter sur cet unikernel avec peu ou pas de modifications. De plus, cela signifie que les bibliothèques qui ne font pas d'appels système elles-mêmes peuvent être utilisées sans modification. Nous pourrions avoir besoin de plus de code pour émuler les utilisations de pseudo-fichiers dans / proc et / sys, mais ces derniers peuvent être des détails d’implémentation masqués dans la glibc et / ou dans le noyau.

Itérations à venir de UKL

Nous travaillons actuellement sur les prochaines itérations de notre unikernel. Nous allons nous débarrasser de la bibliothèque wrapper et déplacer une partie de la fonctionnalité dans le noyau Linux et le reste dans la glibc. Nous prévoyons d'introduire des options de configuration permettant aux utilisateurs d'activer ou de désactiver les fonctionnalités requises par l'application au moment de la compilation. Plus loin, nous prévoyons de le faire automatiquement par optimisation du temps de liaison.

Nous travaillons également actuellement sur le nettoyage du processus de génération unikernel. Nous empruntons actuellement des fonctionnalités du processus de construction du noyau Linux. Finalement, nous espérons que ce sera une cible GCC différente et que tout ce que l’on aura à faire pour créer un uni- noyau spécifique à une application consiste à exécuter «make CC = ukl-gcc…», en supposant que les bibliothèques utilisées remplissent les conditions requises. Une telle facilité de création du noyau unique constituera un énorme pas en avant pour rendre les noyaux universels omniprésents.

Une fois toute la plomberie terminée, nous prévoyons d’y intégrer davantage de soutien. Nous commencerons par des fonctionnalités telles que le stockage local des threads, le support de pthreads, l'appel de constructeurs C ++ au démarrage, etc. Nous utiliserons les recherches effectuées par différents unikernels tels que EbbRT et y ajouterons des solutions similaires, par exemple la mise en réseau sans copie.

En utilisant des optimisations de programme complètes et des optimisations de temps de liaison sur la base de code résultante, nous pouvons créer automatiquement des unikernels spécifiques à une application. L'idée est d'être acceptée par la communauté et d'ajouter progressivement des fonctionnalités que la communauté peut accepter et maintenir.

À long terme, nous pensons qu'un unikernel basé sur Linux peut constituer une alternative viable aux packages qui, totalement ou partiellement, contournent ou évitent le noyau et effectuent la plupart des traitements dans l'espace utilisateur, tels que DPDK et SPDK. De tels paquets n'auront pas besoin de ré-implémenter la fonctionnalité qui réside déjà dans le noyau et serait capable de construire dessus. Une approche unikernel pourrait éliminer le temps système que ces approches de contournement de noyau adressent.

Il sera intéressant de voir les avantages en termes de performances pour les applications que nous pouvons obtenir par rapport à Linux à la vanille. Des pistes de recherche intéressantes peuvent être explorées tout en améliorant les performances de notre noyau unique en les comparant à des efforts spécialisés, tels que EbbRT.

Ce noyau unique basé sur Linux n’est peut-être pas la réponse à toutes les questions de performances et de sécurité, mais il est possible de commencer à répondre à ces questions dès qu’il sera plus facile de déployer des applications avec ce dernier. Et c'est là que nous avons l'intention d'aller.

Source :next.redhat 

---***---