4.2.1 Rappel de la problématique
Conformément à ce qui a été discuté au début de ce chapitre, les SIP se caractérisent par l’hétérogénéité et le dynamisme de leur environnement. Tels les environnements considérés par le
Fog Computing, les environnements dans les SIP contiennent des ressources très variées et variables,
avec des ressources évoluant entre les serveurs haute performance et machines virtuelles sur le cloud aux tablettes et nano-ordinateurs pour l’IoT. Des nombreuses ressources se retrouvent déjà disponibles, intégrées dans cet environnement. Ces ressources ne sont pas toutes dans les data
centers. Elles sont réparties au sein de l’organisation, et même au-delà, dédiées (ou pas) à différents
usages. Ces ressources ne sont pas toujours dédiées exclusivement à certains services ou certaines tâches, et, même si elles ne sont pas toujours très puissantes, elles offrent malgré tout un pouvoir de calcul non négligeable. Malheureusement, en dehors des ressources sur les data centers et celles sur le cloud, des nombreuses ressources disponibles dans un SIP demeurent souvent peu utilisées, voir sous-utilisées pour certaines.
Nous avons donc des nombreuses ressources qui peuvent être disponibles de manière permanente ou temporaire. Ces ressources sont très hétérogènes, pouvant être mobiles et présenter des caractéristiques très distinctes. Leurs capacités de calcul peuvent également varier dans le temps, puisqu’il ne s’agit pas forcément de ressources dédiées à une tâche précise, pouvant donc exécuter différentes tâches simultanément, ce qui fait varier les capacités disponibles.
Vu la disponibilité de toutes ces ressources, on peut considérer dans le SIP, à l’instar du Fog Computing, l’usage de ressources de proximité pour l’exécution de services au nom du SIP. Or cet usage demande une gestion de ressources qui soit opportuniste, puisque guidée par la disponibilité de ces ressources et des capacités disponibles. L’objectif n’est donc pas forcément d’optimiser l’usage d’un pool fixe de ressources, comme bien souvent dans les data centers ou le cloud [231, 250], mais d’essayer d’utiliser au mieux un pool de ressources hétérogènes, dont la composition et les capacités offertes peuvent varier dans le temps et dont l’usage n’est pas exclusif aux calculs et services considérés. Telle la gestion de ressources pour les plateformes Fog [94, 106], la gestion de ressources dans un pool ainsi constitué représente un problème complexe, surtout lorsqu’il est comparé aux plateformes cloud.
Dans cette section, nous nous intéressons à cette question, avec l’objectif de permettre un usage opportuniste des ressources dans un SIP, pendant qu’elles soient disponibles et dans la mesure des possibilités offertes par ces ressources à un instant t. Selon notre point de vue, les SIP demanderaient une gestion de ressources qui soit sensible au contexte afin de tenir compte de l’hétérogénéité et du dynamisme de cet environnement. Les travaux présentés dans ce qui suit s’attaquent donc à cette question, et plus particulièrement au placement de services dans les ressources disponibles et à l’architecture nécessaire pour répondre aux besoins d’un SIP. On poursuit ainsi la vision initiée par l’Espace de Services (cf. section 4.1), en nous concentrant davantage sur ce point précis de la vue architectural (Figure 51), nécessaire à l’exécutabilité des espaces de services.
120
4.2.2 Contribution & Impact
Les travaux que nous avons menés autour du projet PER-MARE (cf. section 2.2), entre 2013 et 2016, nous ont ouvert des nouvelles perspectives de recherche autour de la gestion de ressources dans les environnements de Fog Computing. Les SIP étant caractérisés par la même hétérogénéité et le même dynamisme que ces environnements (le Fog Computing faisant partie de l’écosystème fomentant l’apparition des SIP), il nous paraissait logique de continuer nous recherches autour de ce sujet au-delà du projet PER-MARE (qui s’est terminé en 2014). Depuis 2016, nous avons poursuivi les travaux autour de la gestion de ressources, notamment avec la plateforme CloudFIT. Ces travaux font l’écho d’un constat, dont la littérature fait aujourd’hui état, concernant les difficultés pour le placement de tâches dans un environnement Fog Computing [31,79,106,152,228] pour lesquelles les SIP sont également concernés. Dès 2016, nous avons voulu explorer davantage l’impact de l’hétérogénéité dans l’exécution des tâches dans ce type d’environnement, afin justement de mieux comprendre son effet dans le cas d’un SIP, tout aussi caractérisé par cette hétérogénéité.
Afin de bien explorer cette question, il nous semblait nécessaire de d’abord mieux comprendre d’une part les effets de l’hétérogénéité sur l’exécution des tâches dans ces environnements, et d’autre part, les besoins et les caractéristiques de la gestion de ressources de manière générale et dans les SIP. Pour cela, nous avons premièrement réalisé un ensemble d’expérimentations en environnement réel (pas en simulateur) à l’aide de la plateforme CloudFIT, qui sont venues compléter les résultats du projet PER-MARE (cf. section 2.2). Puis, nous avons réalisé une étude de la littérature sur la gestion de ressources, aussi bien dans les environnements de calcul « traditionnels » (HPC et cloud), que dans les environnements de Fog Computing. Les résultats de ces deux travaux (résumés dans ce qui suit) ont conduit à la définition d’une architecture conceptuelle pour la gestion de ressources dans un SIP dans le cadre de la thèse de David Beserra (thèse toujours en cours).
Notre premier objectif était ainsi de réaliser plusieurs benchmarks expérimentaux nous permettant de démontrer qu’il était possible d’obtenir des niveaux de performance satisfaisants avec des ressources de proximité. Ceci représente la condition sine quoi non pour l’usage de ces ressources dans un SIP. En effet, un usage opportuniste des ressources disponibles ne pourrait être envisagé que si cet usage apporte de bénéfices pour l’organisation sans trop dégrader les performances d’exécution.
Une catégorie de ressources nous a particulièrement intéressée, les nano-ordinateurs construits à partir de ce qu’on appelle « systèmes sur puce » (SoC - System on a chip). Ces systèmes représentent une rupture avec l'architecture d'une machine traditionnelle car ils encapsulent la CPU, la GPU, la mémoire vive ainsi que autres composants sur une même puce [267]. Ils sont généralement utilisés pour réduire le coût des ordinateurs à carte unique, tels que RaspberryPi, Odroid ou BananaPi. Ceux-ci sont utilisés pour une large gamme d’applications, de l’enseignement de l’informatique [5] à l'Internet des Objets [165]. C’est notamment ce dernier usage qui nous a attiré l’attention. Les coûts particulièrement bas de ces ressources les rend très attractives pour l’implantation d’applications de type IoT dans une organisation, et donc, dans un SIP. Par ailleurs, les nano-ordinateurs de type RaspberryPi illustrent bien les limitations propres aux ressources en « bordure » du réseau. Ces ressources sont, selon Hong & Varghese [106], bien souvent : (i) limitées, i.e. disposant des capacités de calcul limitées, avec notamment des processeurs moins puissants ; (ii) hétérogènes, avec des processeurs de différentes architectures ; et (iii) dynamiques, puisque leur charge de travail peut changer, les applications se plaçant en compétition pour ces ressources.
Les résultats que nous avons eu dans le projet PER-MARE (discutés dans la section 2.2) nous ont indiqué qu’il était possible (et même intéressant) de proposer un placement de tâches (qui représentent, à nous yeux, les services dans un SIP) selon les capacités disponibles dans l’environnement. Nous avons donc poursuivi les expériences en nous concentrant sur des ressources dont la puissance serait semblable à des RaspberryPi. Nous avons concentré notre analyse sur deux éléments qui nous semblaient le plus significatifs pour le placement de tâches en fonction du contexte : le contexte d’exécution observée sur la ressource (notamment la charge de la CPU), et la présence sur
la ressource (ou à proximité) des données nécessaires à l’exécution de la tâche. Même si ces deux critères paraissent particulièrement simples, ils permettent de considérer, d’une part un élément de contexte couramment observé par les mécanismes de placement de tâches, et d’autre part, un contexte requis par le service, représenté ici par la présence de données à proximité.
La présence de données à proximité évoque la notion de « data locality », tenue comme particulièrement pertinente dans l’usage de ressources de proximité. La localisation des données peut avoir un impact potentiellement important, car non seulement les communications et les transferts de données peuvent s’éteindre du réseau local aux plateformes cloud, mais également parce que les transferts de données peuvent dépendre des capacités de chaque nœud (ressource) à traiter certains volumes de données, ce qui nous amène à la question de l’hétérogénéité de ces ressources. D’un côté, le maintien des données en local présenterait non seulement l’avantage de la réduction du trafic d’accès, mais aussi de réduire la dépendance par rapport au cloud [110]. De l’autre côté, la capacité de ces ressources à gérer des données va être tout aussi significative que les caractéristiques liées au réseau (latence, débit, etc.), qui, à leur tour, vont aussi avoir un impact. Nous avons d’ailleurs pu constater l’impact de la gestion de données dans les travaux à l’origine de la plateforme CloudFIT dans le projet PER-MARE (cf. section 2.2.2.2). Nous avons donc voulu approfondir nos études à ce sujet. Dans un premier moment, nous avons donc voulu étudier, à travers des expérimentations, le comportement des ressources de proximité peu puissants, semblables aux RaspberryPI, sur différents scénarios de lecture et d’écriture des données. Ces expérimentations avaient pour but de mieux identifier la place de ces ressources dans un SIP, à mesure qu’on souhaite les utiliser de manière opportuniste pour l’exécution de certains services. Très souvent, ces ressources dites de proximité vont participer à la production des données. Les nano-ordinateurs comme les RaspberryPi sont souvent intégrés dans un scénario de IoT, se comportant comme une source de données. Pouvoir placer des calculs à proximité des données qu’ils manipulent pourrait permettre en théorie la réduction de la latence et des coûts de transfert vers des structures distantes (cloud ou data center), mais à condition que la faible puissance de ces dispositifs, notamment en ce qui concerne l’I/O, n’impactent pas (trop) négativement les performances.
Nous avons conduit des multiples expérimentations dans lesquelles on comparait les temps obtenus pour la lecture et l’écriture des données sur un RaspberryPi 332, utilisant différentes configurations (lecture/écriture en mémoire, en carte SD et en disque externe USB), et les temps obtenus en utilisant une plateforme distante33. Nous avons également considéré l’usage d’un serveur de proximité34, situé sur le même réseau local que le RaspberryPi. Trois scénarios ont été envisagés : (i) opérations sur la même machine ; (ii) sur le même réseau ; et (iii) sur des nœuds situés dans le cloud. Le premier cas représente les situations dans lesquelles la localité de données est utilisée pour stocker des données directement à la machine qui les traitera (le RaspberryPi en occurrence). Le deuxième scénario représente le cas intermédiaire où les données sont envoyées vers un équipement à proximité qui les traitera (le serveur de proximité ici). Enfin, le dernier scénario représente les situations où les données sont envoyées vers un nœud distant (représenté ici par la machine virtuelle sur le cloud).
La Figure 54 résume les résultats obtenus en termes de performance de lecture et d’écriture à partir d’un RaspberryPi 3. Nous pouvons observer que pour la lecture des données (Figure 54a), les scénarios « même réseau » (LAN) et local présentent des performances similaires pour la lecture de messages de moins de 1 Mo. Cependant, pour les messages plus volumineux, le temps de lecture entre deux nœuds devient beaucoup plus important avec le scénario LAN, passant à des niveaux presque
32 Équipé d’un processeur ARM Cortex-A53 à 4 cœurs, 1GB RAM, et connexion 100Mbps Ethernet.
33 Machine virtuelle du type n1-standard-2 (2vCPU, 7,5 Go de RAM) située sur la plateforme Google Cloud (GCP) aux USA.
122 comparables à ceux d’accès aux nœuds distants, qui pourtant sont les plus pénalisés par la latence des communications. Ce ralentissement met en évidence non seulement les limites du réseau (réseau à 100 Mbits/s dans notre cas), mais également le temps de traitement de la demande que, dans le cas de la plateforme CloudFIT, se fait grâce à une DHT (Distributed Hash Table). Pour ce qui est de l’écriture des données sur la DHT, la Figure 54b démontre, sans surprise, que l’option de stockage en mémoire locale est beaucoup plus rapide, car elle ne paie pas la surcharge d’accès au stockage persistant. Nous retrouvons des comportements presque similaires à ceux observés en lecture, notamment dans le cas du scénario « même réseau », dans lequel le temps nécessaire pour le stockage de petits blocs de données (jusqu’à 1MB) affiche des performances similaires au stockage en local, alors que pour des données de plus grande taille le coût tend vers celui d’un stockage sur le cloud. Autrement dit, dès que le volume des données devient plus important, les coûts (en termes de performance) pour envoyer les données à une autre machine distante ou à un nœud plus puissant à proximité deviennent semblables.
Figure 54. Résultats sur les temps de lecture (a) et d'écriture (b) sur un RaspberryPi 3 [238].
(a) (b)
Figure 55. Résultats obtenus en transférant des données distantes vers un équipement de proximité.
Nous avons ensuite étudié le cas du RaspberryPi en tant que simple « réceptacle » ou « passerelle », recevant des données d’une autre machine. Dans ce scénario, dont les résultats sont illustrés dans la Figure 55, une machine distante va lire et écrire des données sur le RaspberryPi. On observe alors un comportement semblable au scénario précédent, même si l’ordre des valeurs impliquées n’est pas tout à fait le même35, attestant d’une certaine asymétrie dans les performances (c.a.d. les performances ne sont pas tout à fait les mêmes en fonction du sens de communication). Cette asymétrie est due notamment au temps de traitement nécessaire à la plateforme CloudFIT pour la manipulation de la DHT.
35 Il convient d’observer que les graphiques sur la Figure 54 et la Figure 55 utilisent une échelle logarithmique.
Compas’2019 : Parallélisme/ Architecture / Système LIUPPA - IUT de Bayonne, France, du 24 au 28 juin 2019
1 10 100 1000 10000 100000 1k 10k 100k 1M 10M 100M Te m ps (m s)
Taille fichiers (Octets)
Raspberry Pi - Performances Lecture
Local MicroSD Local USB Local Mémoire LAN Cloud (a) 1 10 100 1000 10000 100000 1000000 1k 10k 100k 1M 10M 100M Te m ps (m s)
Taille fichiers (Octets)
Raspberry Pi - Performances d'Ecriture
Local MicroSD Local USB Local Mémoire LAN Cloud (b)
FIGURE1 – Performances de (a) lecture et (b) écriture d’un Raspberry Pi 4.2. Résultats et Analyse
La Figure 1a représente les différents temps pour les opérations de lecture des données, selon la taille des données et le scénario (même nœud, même réseau, sur le cloud). Nous pouvons observer que pour la lecture des données, les scénarios "même réseau" et local présentent des performances similaires pour la lecture de messages de moins de 1 Mo. Cependant, pour les messages plus volumineux, le temps de lecture entre deux nœuds devient beaucoup plus im-portant, passant à des niveaux presque comparables à ceux d’accès aux nœuds distants, qui pourtant sont les plus pénalisés par la latence des communications. Ce ralentissement met en évidence non seulement les limites du réseau (réseau à 100 Mbits/s), mais également le temps système nécessaire pour demander une ressource par le biais du DHT, qui finit par masquer l’impact de la latence sur les transmissions.
En ce qui concerne l’accès à la DHT locale, les trois options de stockage affichent des perfor-mances presque similaires. Une explication possible est que l’implémentation DHT conserve les données récentes dans la mémoire, masquant ainsi le coût supplémentaire d’accès aux uni-tés de stockage. Des améliorations futures sur le protocole d’expérimentation pourront aider à mieux comprendre ce résultat.
Pour ce qui est de l’écriture des données sur la DHT, la Figure 1b démontre, sans surprise, que l’option de stockage en mémoire locale est beaucoup plus rapide, car elle ne paie pas la sur-charge d’accès au stockage persistant. En ce qui concerne les options de stockage MicroSD et de stockage sur disque USB, leurs performances sont au même ordre de grandeur, mais l’échelle logarithmique des images ne permet pas une analyse plus détaillée. Un examen plus attentif montre que le disque USB devrait être préféré, car il faut en moyenne 22,7 secondes pour écrire 100 Mo sur le DHT, contre 27,3 secondes pour le stockage MicroSD (une amélioration de 16%). Dans le cas du scénario "même réseau", nous retrouvons des comportements presque similaires à ceux observés en lecture, où le temps nécessaire pour le stockage de petits blocs de données (jusqu’à 1MB) affiche des performances similaires au stockage en local, alors que pour des données de plus grande taille le coût tend vers celui d’un stockage sur le cloud.
Les résultats présentés sur ces deux figures semblent démontrer qu’un accès en lecture locale à partir d’un Raspberry Pi ne présente un avantage considérable que si les données sont de plus grande taille. Le même constat peut se faire sur l’écriture des données à partir du Raspberry, à l’exception du cas où le stockage se fait directement en mémoire.
Il faut aussi considérer que, dans la plupart des cas d’usage du fog, les sources de données se situent sur le réseau proche des machines "passerelle" (dispositifs IoT, etc.). Ainsi, nous avons procédé à un deuxième ensemble de mesures où une machine située sur le réseau local lit/écrit
1 10 100 1000 10000 100000 1k 10k 100k 1M 10M 100M Ti m e (m s)
Message size (Bytes)
Raspberry Pi Local Performance
Write on MicroSD Write on USB Write on Memory Read from MicroSD Read from USB Read from Memory
Fig. 8. Raspberry Pi read/write performance on local host
cluster” and ”cloud” locality scenarios described precedently. In addition, we conducted the experiences using three different storage supports on the Raspberry Pi: the built-in MicroSD memory card (class 10), an external USB 2.0 hard disk and a memory-only storage. The comparison between the MicroSD and the external USB disk drive is motivated by their relative performance differences: a class 10 MicroSD should support at least at 10MB/s when writing (with a reading speed depending on the constructor) while an USB external disk on a Raspberry Pi can reach about 20MB/s.Further, as both methods suffer from bottlenecks due to the Raspberry Pi chipset configuration, we also included memory-only storage tests in our experiments. This latter option could benefit volatile datasets that will be discarded after being processed, like in the example of ”gateway” nodes that store intermediate data and preprocess it before sending to other nodes. The experiment protocol (number of runs, DHT reset, etc.) is similar to the previous benchmark.
2) Results and Analysis: Taking the ”same machine” case, Fig. 8 show the performances when the Raspberry Pi tries to save data to the DHT address at its own location, and when it reads data from that address. With no surprise, the memory storage option is faster on writing, as it does not pay the overload of accessing the persistent storage. Concerning the MicroSD and the USB disk storage, their performances are in the same order of magnitude. Nevertheless, a closer look on the performance numbers shows that the USB disk should be preferred, as it need 22.7s in average to write 100MB on the DHT, against 27.3s for the MicroSD (a 16% improvement).
Concerning the DHT access (reading), all three storage op-tions show similar performances. One possible explanation is that the DHT implementation keeps recent data in the memory, hiding therefore the extra cost of accessing the storage units. Further improvements on the benchmarking protocol should help studying this result, and also to identify why writing on the memory is faster than any read operation.
In the case of the ”same cluster” scenario, we performed benchmarks in two directions: the Raspberry Pi performing read/write in the other machine, and the distant machine performing read/write on the Raspberry Pi. This is justified by the fact that the difference on the processing speeds from the machines (as well as their memory and storage speeds)
1 10 100 1000 10000 100000 1k 10k 100k 1M 10M 100M Ti m e (m s)
Message size (Bytes)
Raspberry Pi -> LAN/Cloud Write Performances
Pi -> PC Disk Pi -> PC Memory Pi -> Cloud Disk Pi -> Cloud Memory
Fig. 9. Raspberry Pi to PC write performance
1 10 100 1000 10000 100000 1k 10k 100k 1M 10M 100M Ti m e (m s)
Message size (Bytes)
Raspberry Pi -> LAN/Cloud Read Performances
Pi <- PC Disk