Nous avons montré dans le chapitre précédent que les trafics inter-sites sont coûteux. Il est donc important de chercher à les limiter au maximum, à la fois pour améliorer les temps d’accès et pour permettre au système de fonctionner dans un environnement avec
82 Chapitre 5. Conception d’un système de stockage distribué pour le Fog
des latences élevées. Dans l’idéal, les seuls trafics inter-sites devraient être des trafics sollicités, lorsque des objets sont accédés depuis un site distant.
Dans ce chapitre, nous nous concentrons sur le système de stockage IPFS [Benet2014], sur lequel nous avons obtenu les résultats les plus intéressants lors de nos expérimentations. Nous présentons deux améliorations. La première consiste à coupler IPFS avec une solution de stockage de type Scale-Out NAS (cf Section2.1) afin de confiner le trafic au site local lorsque l’objet accédé est stocké localement sur le site. La seconde amélioration consiste à stocker la localisation des données dans un arbre respectant la topologie physique du réseau, de façon à confiner les trafics inter-sites dans le processus de localisation des objets.
5.1
Réduction des trafics réseau inter-sites pour les accès
locaux
Après avoir montré que la table de hachage distribuée ne permettait pas de confiner le trafic réseau, nous proposons dans cette section, de coupler IPFS avec un système de fichiers distribué de type Scale-Out NAS afin de pouvoir accéder aux objets stockés localement sur le site sans émettre de requêtes à destination d’un autre site.
Ce travail a été présenté à la session 2017 de la conférence ICFEC [Confais et al.
2017b].
5.1.1 Description du problème
Bien que nous ayons déjà illustré quels sont les échanges réseaux effectués par IPFS dans la Section4.1.3, nous détaillons les processus d’écriture et de lecture sur la Figure 5.0.
La Figure 5.1(a)montre la création d’un nouvel objet : le client envoie son objet à un nœud du site le plus proche. L’objet est créé localement et la table de hachage stockant la localisation de chaque objet est mise à jour. Comme la DHT ne fournit pas de localité, la localisation d’un objet peut être stockée sur n’importe quel nœud. Dans notre exemple le Nœud 3 appartenant au Site 2 stocke la localisation d’un objet qui a été écrit sur le Site 1.
La Figure 5.1(b)montre ce qu’il se passe lorsqu’un client lit un objet stocké sur le site local. Chaque fois qu’un nœud reçoit une requête pour un objet particulier, il vérifie d’abord si le nœud n’est pas stocké localement. Si cela n’est pas le cas, (i) un hash est calculé en fonction du nom de l’objet, (ii) le nœud stockant la localisation est contacté, (iii) l’objet est téléchargé en utilisant le protocole BitTorrent, (iv) une copie locale est créée pendant que l’objet est transmis au client et (v) la table de hachage distribuée est mise à jour pour refléter l’existence de ce nouveau réplica. Enfin, la Figure5.0(c)décrit le protocole lorsque l’objet est demandé depuis un site distant (c’est-à-dire, lorsque le client s’est déplacé d’un site à l’autre). Dans tous les cas, le client contacte un nœud du site le plus proche.
En d’autres mots, IPFS ne prend pas en compte la topologie physique de l’infrastruc- ture de Fog et considère chaque serveur de façon indépendante plutôt que de considérer
5.1. Réduction des trafics réseau inter-sites pour les accès locaux 83 Site 1 Site 2 store object put object done put location in DHT
Client IPFS Node1 IPFS Node2 IPFS Node3
(a) – Écriture d’un objet.
Site 1 Site 2 read object get object send object find locations in DHT get/read object get object send object store object put location in DHT
Client IPFS Node1 IPFS Node2 IPFS Node3
(b) – Lecture d’un objet stocké localement.
Site 1 Site 2 Site 3
find location in DHT get/read object get/read object get object send object store object put location in DHT
IPFS Node1 IPFS Node2 IPFS Node3 IPFS Node4IPFS Node5 Client
Site 1 Site 2 Site 3
find location in DHT get/read object get/read object get/read object get object send object store object put location in DHT
IPFS Node1 IPFS Node2 IPFS Node3 IPFS Node4IPFS Node5 Client
(c) – Lecture d’un objet stocké sur un autre site (en interrogeant IPFS Node4 ou IPFS Node 5). Figure 5.0 – Diagrammes de séquence montrant les processus d’écriture (a) et de lecture d’un objet stocké sur le site local (b) ainsi que sur un site distant (c), avec la
solution de stockage IPFS.
des groupes de serveurs placés sur chacun des sites. Quand un réplica est créé, que ce soit par un utilisateur ou par relocalisation, les autres nœuds IPFS du site ne sont pas informés de ce réplica et reposent sur la table de hachage distribuée pour le localiser. Cela est illustré par la seconde lecture de la Figure5.0(c). Bien que l’objet est déjà disponible sur le Nœud 4 du Site 3, le Nœud 5 doit contacter la table de hachage distribuée pour le
84 Chapitre 5. Conception d’un système de stockage distribué pour le Fog
localiser.
Ceci a deux principaux inconvénients. Premièrement les temps d’accès ainsi que la quantité de trafic échangé entre les sites sont augmentés. Deuxièmement, les clients ne peuvent accéder à des objets stockés sur le site lorsque celui-ci est déconnecté des autres (partitionnement du réseau) puisque la localisation de l’objet ne peut être trouvée. IPFS fournit donc une manière efficace d’accéder aux données grâce au protocole BitTorrent mais ne prend pas en compte les particularités d’une architecture de Fog Computing.
5.1.2 Solution proposée
Pour améliorer le fonctionnement d’IPFS dans un environnement de Fog Computing, proposons de déployer une solution de stockage de type Scale-Out NAS indépendamment sur chaque site. Ce Scale-Out NAS est utilisé comme solution de stockage sous-jacente à tous les nœuds IPFS d’un même site, comme cela est illustré sur la Figure 5.1. Cette approche permet à un nœud de stockage IPFS d’accéder aux objets stockés par les autres nœuds du même site, en ne faisant que de petites modifications dans le code source du programme. Ce couplage est possible car chaque nœud IPFS stocke de façon interne chaque objet sous la forme de fichiers. Au lieu d’accéder à un fichier stocké sur le disque dur local, IPFS ira simplement chercher l’objet demandé dans sur le système de fichiers distribué.
Figure 5.1 – Topologie utilisée pour déployer une solution de stockage en mode objet au-dessus d’un système de fichiers distribué localement sur chaque site.
Coupler un système de stockage objet avec un Scale-Out NAS n’est pas une idée nouvelle et de nombreuses propositions ont déjà été faites dans ce sens. Par exemple
5.1. Réduction des trafics réseau inter-sites pour les accès locaux 85
Yahoo a développé Walnut [Chen et al.2012], une solution de stockage par objets qui s’appuie sur différents systèmes de fichiers comme HDFS. Cependant, notre approche est différente dans le sens où dans notre topologie, le Scale-Out NAS sous-jacent n’est pas global mais local à chaque site. IPFS n’est qu’une « glue » pour créer un espace de noms global au travers des différents sites. Une approche similaire a été proposée dans le système Group Based FileSystem (GBFS) [Lebre et al. 2014] où différents systèmes de fichiers déployés à différents endroits sont agrégés. Cependant cette solution n’est pas efficace puisque tout accès commence par solliciter le serveur gérant la racine du système de fichiers, qui est alors fortement sollicité.
Enfin, l’intérêt d’utiliser un Scale-Out NAS comme RozoFS [Pertin et al.2014] ou GlusterFS [Davies et al.2013], est la possibilité de pouvoir ajouter des nœuds à la volée, ce qui augmente à la fois l’espace de stockage mais aussi les performances puisque dans un Scale-Out NAS, les requêtes et les données sont réparties de façon uniforme entre les nœuds de stockage. Les modifications du protocole utilisé par IPFS que nous proposons sont illustrées sur les Figure5.1 et5.2.
Nous pouvons observer qu’il n’y a aucun changement dans le protocole lors de la création d’un objet, si ce n’est qu’au lieu de stocker l’objet directement sur le nœud, celui-ci est envoyé dans un système de fichiers distribué.
Les principaux changements apparaissent lorsqu’un client veut accéder à une donnée stockée. La Figure 5.2(b), montre ces changements : grâce au Scale-Out NAS, tout nœud IPFS d’un site voit les objets manipulés par les autres nœuds du même site. En conséquence, peu importe à quel nœud du site les requêtes sont envoyées, lorsque le nœud interrogé recherchera si l’objet est stocké localement, il recherchera dans le Scale-Out NAS et l’enverra au client. Contrairement à la conception originale d’IPFS, il n’y a plus besoin d’accéder à la DHT pour localiser les objets stockés sur les autres nœuds d’un même site.
De manière similaire, la Figure5.2(c) montre le protocole lors de l’accès à une donnée stockée sur un site distant. Lorsque le client est connecté sur un site qui ne stocke pas l’objet, la requête est reçue par n’importe quel nœud du site. Le nœud vérifie si l’objet n’est pas dans le système de fichiers distribué. Si l’objet n’est pas trouvé, la DHT est consultée pour localiser un réplica. L’objet est téléchargé, relocalisé dans le Scale-Out NAS et la table de hachage distribuée est mise à jour. Les futurs accès effectués depuis ce site, pourront être satisfaits sans aucune communication avec les sites extérieurs, peu importe le nœud du site qui sera interrogé. Nous devons enfin préciser que les objets utilisés par IPFS étant immuables, nous n’avons pas à nous préoccuper de savoir s’il est préférable de télécharger la version relocalisée dans le Scale-Out NAS local est plus récente que le réplica original stocké sur un site distant.
Pour résumer, notre approche permet de limiter la quantité de trafic réseau en cas de lecture d’objets stockés localement. Lorsqu’un client accède à un objet disponible sur le site, la table de hachage distribuée n’est pas utilisée, quel que soit le nœud du site interrogé. Dans les autres situations, la quantité de trafic réseau échangé reste la même.
Un dernier point que nous devons préciser est que notre approche permet également de répartir les données stockées sur l’ensemble des nœuds de stockage du site de façon
86 Chapitre 5. Conception d’un système de stockage distribué pour le Fog
Site 1 Site 2
get DFS Nodes to store the object store object
put object
done put
location in DHT
Client IPFS n1 IPFS n2 DFS n1 DFS n2 DFS MDS IPFS n3
(a) – Écriture d’un objet.
Site 1 Site 2
get DFS Nodes storing the object read object
get object
send object
get DFS Nodes storing the object read object
get object
Client IPFS n1 IPFS n2 DFS n1 DFS n2 DFS MDS IPFS n3
(b) – Lecture d’un objet stocké localement.
Site 1 Site 2 Site 3
get DFS Nodes storing the object
object not found find
locations in DHT
get DFS Nodes storing the object read object get/read object get object send object get DFS Nodes
to store the object store object put
location in DHT
get DFS Nodes storing the object read object
get object
send object
IPFS n1 IPFS n2 DFS1 n1 DFS1 n2 DFS1 MDS IPFS n3 DFS2 MDS DFS2 n1 IPFS n4 IPFS n5 Client
(c) – Lecture d’un objet stocké sur un site distant.
Figure 5.2 – Diagrammes de séquences montrant les processus de lecture et d’écriture d’un objet en utilisant IPFS au-dessus d’un système de fichiers distribué (DFS) déployé
indépendamment sur chaque site. « MDS » (ou MetaData Store) est le serveur de métadonnées du système de fichiers distribué.
5.1. Réduction des trafics réseau inter-sites pour les accès locaux 87
uniforme. En effet, si un client envoie une grande quantité de données à un seul nœud IPFS, dans l’approche standard, ce nœud devra stocker lui-même ces données, déséquilibrant la répartition des données au sein du site. Dans notre approche, les données sont réparties sur les différents serveurs de stockage du Scale-Out NAS, aboutissant à conserver à tout moment une répartition homogène sur les différents serveurs de stockage.
5.1.3 Limitations
D’un point de vue des performances, il est important de noter que l’approche que nous venons de présenter mérite d’être améliorée. En effet, dans l’approche par défaut, lorsqu’un nœud IPFS souhaite accéder à un objet situé sur un autre site, l’objet est téléchargé depuis l’ensemble des nœuds stockant un réplica (voir la Figure5.1(b)de la Section5.1.1). Ce comportement permet à IPFS de réaliser le téléchargement de la manière la plus efficace possible : si un nœud est surchargé, tous les autres nœuds sont capables de répondre.
Dans notre approche utilisant un Scale-Out NAS, la situation est différente car la DHT ne connaît qu’un nœud par site stockant le réplica : soit le nœud sur lequel le client a écrit l’objet, soit le premier nœud de chaque site à y accéder. Comme cela est illustré dans la Figure 5.2(c)de la Section 5.1.2, , le nœud IPFS 4 du Site 3 ne peut télécharger l’objet que du Nœud 1 du Site 1 car c’est sur ce nœud que l’objet a été écrit et c’est ce nœud qui est enregistré dans la DHT. Le nœud IPFS 4 du Site 3 ne sait pas qu’il peut aussi contacter le nœud IPFS 2 du Site 1. Cette situation peut mener à des goulets d’étranglements ou à la surcharge de certains nœuds. De la même manière si le nœud IPFS 1 du Site 1 devient inaccessible, l’objet ne peut plus être téléchargé du Site 1 ce qui est « gênant » dans la mesure où celui-ci est toujours accessible au travers des autres nœuds du site. Une solution pour ce problème serait de stocker dans la DHT non pas l’adresse du nœud mais un identifiant correspondant au site stockant l’objet. Nous laissons ces améliorations pour une contribution future.
5.1.4 Conclusions
Nous avons vu dans cette partie que l’utilisation d’une table de hachage distribuée pour localiser les objets ne permettait pas de garantir un confinement du trafic réseau : un site distant doit être contacté lorsque nous souhaitons accéder à un objet stocké sur le site local. Nous avons proposé de coupler IPFS avec un Scale-Out NAS local à chaque site permettait de donner une vue à chaque nœud de l’ensemble des objets stockés sur le site. De cette façon les objets stockés localement n’ont pas besoin d’être localisés en utilisant la table de hachage distribuée, réduisant les trafics réseau inter-sites et améliorant la disponibilité des données en cas de partitionnement du réseau.
Toutefois, avec l’utilisation d’une table de hachage distribuée, devoir contacter un premier site qui n’est pas nécessairement proche de l’objet accédé est un problème plus général qui ne se limite pas aux accès locaux. Dans la prochaine section, nous proposons de remplacer la table de hachage distribuée par une approche permettant de favoriser l’interrogation des sites voisins au sens de la topologie physique du réseau.
88 Chapitre 5. Conception d’un système de stockage distribué pour le Fog
5.2
Confinement des trafics réseau inter-sites lors d’accès
distants
Nous venons de voir que coupler IPFS avec un Scale-Out NAS déployé localement sur chaque site permettait de confiner le trafic lors d’accès locaux. Cependant pour les accès distants, l’utilisation d’une table de hachage distribuée ne permet toujours pas de confiner le trafic au plus près des utilisateurs et ne permet pas de stocker la localisation des données au plus proche de ces dernières. Nous proposons dans cette section de présenter brièvement différents mécanismes permettant de stocker la localisation de données, avant de proposer notre protocole de gestion des localisations.
Ce travail a été soumis dans la conférence IEEE Globecom 2018 [Confais et al.
2018a] et a été présenté à RESCOM 2018 [Confais et al. 2018c].
5.2.1 Approches pour localiser des données
Nous présentons ici, plusieurs méthodes permettant de localiser des données. Toutes se caractérisent sur la quantité de trafic échangé entre les sites lors du processus de localisa- tion, par la garantie ou non de trouver un objet et par la localité des enregistrements, c’est-à-dire, la possibilité ou non de pouvoir placer l’enregistrement associant un nom d’objet à l’emplacement de ses réplicas proche des réplicas de l’objet.
Approches sans annuaire
Dans cette première section, nous présentons les méthodes pour lesquelles il n’y a pas besoin de créer un annuaire contenant la localisation de chaque donnée.
La première approche consiste à inonder le réseau pour trouver la donnée recherchée. Contrairement à l’approche utilisée par Cassandra où l’inondation est réalisée de façon asynchrone et dont le but est d’informer l’ensemble des nœuds de la topologie du réseau, ici, ce sont les requêtes des utilisateurs qui sont propagées dans le réseau.
La requête est transmise à l’ensemble du voisinage jusqu’à ce que le nœud stockant la donnée ou sa localisation soit atteint. Pour limiter les boucles, les requêtes sont assorties d’un TTL (Time To Live) permettant de limiter le nombre de sauts. Le principal défaut de cette méthode est qu’elle ne fournit pas de garantie pour trouver une donnée. Pire, un même client peut trouver une donnée lorsqu’il se trouve à une certaine position du réseau et ne plus y arriver après s’être déplacé. La Figure5.3illustre le cas où le client, situé au milieu du réseau effectue une recherche par inondation en limitant le nombre de sauts (TTL) à 3. Ces voisins émettent à leur tour la requête à leurs voisins (sauf vers le nœud d’où ils ont reçu la requête) avec un TTL égal à 2. Et enfin ces derniers nœuds réémettent la requête avec un TTL égal à 1. Le nombre de sauts n’étant pas suffisant pour atteindre le nœud stockant la donnée, le client restera à penser que la donnée recherchée est inexistante dans le réseau. Augmenter le nombre de sauts permettrait de trouver la donnée mais effectuer un nombre de sauts élevé non seulement augmente les temps d’accès mais aussi génère un trafic conséquent sur le réseau. Dans certains cas où l’utilisateur reste proche du nœud stockant les données accédées, cette approche peut
5.2. Confinement des trafics réseau inter-sites lors d’accès distants 89
être utilisée [Shah et al.2005a]. Toutefois, transférer les requêtes de proche en proche, en inondant le réseau ne permet pas de respecter notre critère du confinement du trafic réseau présenté dans la Section 3.1. Certaines heuristiques permettent de limiter le trafic réseau tout en essayant de maximiser les chances de trouver la donnée recherchée [Rahman et al. 2004; Gkantsidis et al. 2004; Shah et al. 2005b].
Figure 5.3 – Protocole par inondation qui ne garantit pas de pouvoir accéder à la donnée recherchée. Le nuage vert contient les nœuds qui ont été atteints par la requête.
De façon similaire, certains protocoles de routage réseau tel qu’Optimized Link State Routing Protocol (ou OLSR) [Clausen et al. 2003] utilisent également une approche par inondation préalablement à l’échange de table de routage.
Une autre approche est de stocker la localisation de la donnée dans son identifiant [Gif- ford et al. 1988; Satyanarayanan1990]. Le système de stockage n’a pas besoin de retenir la localisation puisque l’utilisateur l’indique à chaque fois qu’il souhaite accéder à une donnée. La contrepartie de faire reposer le processus de localisation sur les utilisateurs eux-mêmes est que lorsque la donnée est déplacée, celle-ci change de nom. Un tel système semble compliqué à utiliser à l’usage. Il est en revanche utile lorsque les données ne sont jamais déplacées. Une telle approche serait similaire à ce qu’il se passe aujourd’hui