Obstacles à la justesse de la facturation

Au-delà du concept d’unité de consommation, Verghese et al. [VGR98] et Banga et al. [BDM99], soulignent également un autre challenge pour la facturation de l’utilisation des ressources : la justesse. Un des premiers obstacles à la justesse de la facturation dans les systèmes traditionnels est l’effet de QoS crosstalk, originalement identifié par Leslie et al. [LMB+96]. Ce phénomène est dû au partage des gestionnaires de ressources par les différentes applications. Non seulement le maintien de structures algorithmiques partagées dégrade naturel-lement la performance, mais en plus l’exécution des algorithmes de partage est facturée au gestionnaire de la ressource, qui occupe du temps CPU au nom des applications utilisatrices. Enfin, certains traitements liés aux ressources sont ef-fectués lors d’interruptions matérielles, dénuées de tout contexte d’exécution, et provoquent la facturation du traitement au processus arbitraire réveillé lorsque l’interruption matérielle survient.

Réduction des abstractions de haut niveau. Afin de réduire le QoS crosstalk au minimum, Leslie et al. prônent via leur système d’exploitation Ne-mesis [LMB+96] une interface de gestion des ressources minimale, épurée des

abstractions de haut niveau, et la déportation de la complexité algorithmique au sein des applications elles-mêmes. Cette solution est notamment dérivée des principes de l’exokernel [EKO95], qui remettait déjà en cause les abstractions de haut niveau des ressources matérielles faites par les noyaux, empêchant les ap-plications d’obtenir des performances optimales. L’exokernel préfère fournir des librairies en espace utilisateur, implémentant différentes abstractions de haut niveau et politiques de gestion de ressources. Les applications sont ainsi libres d’utiliser l’abstraction qui leur convient le mieux, dans leur propre contexte d’exécution. Ce principe sera ensuite étendu dans le système EROS [SH02], dont le noyau ne fournit que des mécanismes permettant aux gestionnaires en espace utilisateur d’implémenter une facturation et une gestion sur-mesure de la ressource.

Dans les premiers systèmes conçus pour être massivement partagés, comme le noyau d’isolation Denali [WSG02], le QoS crosstalk est ainsi réduit en four-nissant à chaque système invité un espace de noms privé, contenant notamment un gestionnaire de ressource, répliqué pour chaque instance. Cependant, le QoS crosstalk dans ce cas réside dans le fait que les accès effectifs au matériel sont réalisés exclusivement par une machine virtuelle de supervision privilégiée, qui devient donc un point de congestion algorithmique et de mauvaise facturation.

La technique du lazy receiver processing [DB96] (LRP) permet d’atténuer le QoS crosstalk pour certaines ressources, notamment le traitement de pa-quets réseau. Le LRP diffère la majorité du travail CPU lié aux requêtes d’en-trées/sorties, à la lecture effective des données par l’utilisateur. Par exemple, la dissection des entêtes protocolaires n’est effectuée qu’au moment de la lecture via socket, et donc facturée à l’application qui reçoit effectivement au paquet, et non pas au processus victime d’une interruption matérielle ou à la pile réseau. Le QoS crosstalk s’est ensuite naturellement transposé dans les environne-ments virtualisés, où le gestionnaire de ressources devient un système invité à part entière, dédié aux opérations privilégiées : c’est le cas de la machine vir-tuelle de supervision du noyau d’isolation Denali [WSG02], ou de la VM Dom0 dans Xen [BDF+03]. Les travaux ultérieurs sur ce problème des systèmes virtua-lisés ont conduit aux mêmes conclusions que celles de Leslie et al. : la nécessité pour les hyperviseurs d’offrir aux systèmes invités des interfaces de bas niveau, et l’introduction de la notion de notification, virtualisation des interruptions matérielles en LRP, afin de réduire les changements de contexte et de facturer justement les traitements liés à ces interruptions [SVL02, LHAP06, OCR08]. Ajustement de la facturation grâce aux traces. Ces solutions ont le désavantage de coûter très cher en termes d’implémentation, puisque néces-sitant la reconstruction de la gestion des ressources des applications et des gestionnaires. Pour pallier à ce problème, Gupta et al. [GCGV06] proposent l’ajout à Xen de couches de facturation à partir de traces des gestionnaires de ressource, et de l’observation dynamique de l’utilisation des ressources par les différents systèmes invités [GGC05]. Les traces de haut niveau produits par les gestionnaires de ressources permettent de facturer correctement le temps de

traitement des requêtes aux systèmes invités initiateurs ou destinataires. Cette technique leur permet d’équilibrer efficacement les bandes passantes attribuées à deux serveurs Web concurrents, en n’imposant qu’une modification minimale, la production de traces, aux gestionnaires de ressources. La facturation à base de traces a également été définie de manière plus générique dans le cadre des systèmes à micro-noyaux L4 par Stoess et al. [SU06]. Stoess et al. exposent notamment des techniques permettant d’optimiser la production et le traite-ment des traces, comme le filtrage ou la modification à chaud des routines de production de traces. Leur travail se base sur une production coopérative des traces entre les différentes entités, que ce soient les applications, systèmes invi-tés ou middlewares. Dans le cas général de systèmes partagés ayant des charges de travail égoïste, les seuls composants de confiance sont les gestionnaires de ressource, ce qui correspond au travail de Gupta et al..

Prêt et transfert de ressources. Lemerre et al. [LDVN09] proposent de réduire le QoS crosstalk en supprimant l’utilisation de ressources effectuée par les gestionnaires, ayant lieu par effet de bord de requêtes des applications. Leur solution combine les concepts avancés par L4 [Lie95] et EROS [SH02] notamment, à savoir les mécanismes de transfert et de prêt de ressources. Ces transferts peuvent être implicites ou explicites : un processus envoyant un pa-quet réseau va prêter de manière implicite au gestionnaire réseau son temps CPU afin de gérer la requête ou d’analyser les entêtes et devra avoir alloué au préalable, puis prêté de manière explicite, la mémoire nécessaire au traitement et à l’envoi de la requête. Ceci permet d’éliminer une partie importante du QoS crosstalk et donc de la facturation erronée due aux actions effectuées par le noyau.

Facturation basée sur les évènements. Du côté des techniques de factura-tion, l’attaque de Tsafrir et al. [TEF07], ensuite appliquée à l’ordonnancement de machines virtuelles dans Xen [ZGDS11] a montré qu’une facturation juste de l’utilisation d’une ressource doit être basée sur les évènements, et non pas échantillonnée. En effet, comme démontré dans la section 2.2.3, une factura-tion à base d’échantillonnage périodique peut mesurer des parts d’utilisafactura-tion mesurées opposées à la réalité : non seulement un attaquant peut monopoliser la ressource, mais sa consommation est facturée à d’autres utilisateurs n’ayant que peu accès à celle-ci.

3.2.3 Discussion

Les travaux passés sur la facturation des ressources ont prôné la définition d’unités de consommation de ressources indépendantes de l’unité d’exécution, permettant une gestion plus fine de l’utilisation des ressources, et plus adaptée aux applications dynamiques. Ce principe vient notamment du fait que le CPU n’est devenu qu’une ressource parmi les autres, et que ces dernières se sont révélées être des goulots d’étranglement significatifs pour certaines applications.

Ce paradigme n’a été implémenté que très tard dans les systèmes d’exploitation classiques, un exemple étant les cgroups de Linux ajoutés au noyau fin 2007, ou le très restreint gestionnaire de ressources Windows introduit avec Windows Server 2008.

D’un autre côté, les travaux passés dans le domaine de la justesse de factura-tion ont pointé du doigt les problèmes rencontrés dans la facturafactura-tion du temps CPU, mais se sont peu intéressés à la facturation de l’utilisation des autres ressources, jugeant que les algorithmes d’équité et d’optimisation présents per-mettaient un contrôle a priori suffisant. Pourtant, les réordonnancements et heuristiques dédiées décrits dans la section 3.1.2 révèlent qu’une facturation réellement représentative de l’utilisation du périphérique par une ressource in-duit également des problèmes non-triviaux. Il en va de même pour la difficulté de facturation des optimisations génériques du système, comme l’utilisation du Page Cache partagé décrit dans la section 2.2.1. Par exemple, les cgroups Li-nux ne sont pas capables de facturer correctement les requêtes d’entrées/sorties bufferisées [Doc09].