Télécharger le fichier pdf d’un mémoire de fin d’études
Hypothèses de travail
Dans ce manuscrit, nous considérons principalement une hiérarchie avec un seul niveau de Fog : les clients situés en bordure du réseau, une couche de Fog et le Cloud en haut de la hiérarchie. Cette hiérarchie est illustrée par la Figure 1.2 Les clients, interrogent toujours le site de Fog le plus proche, atteignable, bien souvent à l’aide d’un lien radio, ayant une latence réseau (LF og) de l’ordre de 10 ms [Sui et al. 2016 ; Huang et al. 2012]. Nous considérons également que la latence réseau entre les différents sites de Fog est comprise entre 50 et 100 ms. Cela correspond à la latence moyenne d’un lien de type Wide Area Network [Markopoulou et al. 2006]. Enfin, joindre l’infrastructure de Cloud Computing nécessite 200 ms [Couto et al. 2014 ; Firdhous et al. 2014].
Exemples d’applications du Fog Computing
De nombreux cas d’utilisations qui nécessitent l’utilisation d’une architecture de type Fog Computing ont été proposés.
Des feux de signalisation intelligents à la ville intelligente
Plusieurs travaux [Bonomi et al. 2012 ; Bonomi et al. 2014 ; Stojmenovic et al. 2014] ont proposé d’utiliser une infrastructure de Fog Computing pour réguler le trafic routier. L’idée proposée est qu’un feu de signalisation envoie son état aux voitures proches afin que ces dernières ralentissent. L’état des feux et la position des véhicules est régulièrement envoyée vers une plateforme de Fog qui établit une politique globale afin que les usagers attendent le moins longtemps possible et aient la durée de trajet la plus courte. De façon plus générale, le Fog a été proposé pour aider à la prise de décisions dans un réseau de véhicules (VANET) [Truong et al. 2015].
L’utilisation Fog a été proposée dans un contexte de « villes intelligentes » [Tang et al. 2015]. L’idée générale est d’utiliser les sites de Fog comme une plateforme de traitement pour les données collectées par des capteurs au sein de la ville.
Domaine de la santé
Dans le domaine de la santé, Dubey et al. [Dubey et al. 2015] proposent d’utiliser le Fog dans la surveillance médicale. L’idée est que des capteurs mesurent différents paramètres de la personne. Transmettre cette grande quantité de mesures sur une plateforme de Cloud Computing pour l’analyser est très coûteux. L’idée proposée est d’introduire un Fog entre l’utilisateur et le Cloud afin d’agréger les données. Seul un agrégat des données rejoint le Cloud. L’infrastructure de Fog est également utilisée pour détecter des motifs dans les données qui signifient que la personne est en danger. L’objectif est de pouvoir être alerté le plus rapidement possible sans attendre que le calcul soit traité sur une plateforme de Cloud. D’autres auteurs [Cao et al. 2015 ; Dastjerdi et al. 2016b] proposent quant à eux d’utiliser le Fog pour détecter les accidents vasculaires cérébraux. Masip-Bruin et al. proposent quant à eux d’utiliser le Fog Computing dans le cadre de patients ayant des difficultés à respirer. Des capteurs mesurent des données sur la personne, les transmettent à un site de Fog. À partir des données, le site de Fog prend la décision d’augmenter ou de réduire la quantité d’oxygène fournie à l’utilisateur [Masip-Bruin et al. 2016].
Réalité augmentée
Les infrastructures de type Fog Computing ne profitent pas seulement aux capteurs mais également aux périphériques utilisés par les utilisateurs. Des utilisations du Fog Computing ont aussi été proposées pour de la réalité augmentée [Satyanarayanan 2013 ; Yi et al. 2015b ; Dastjerdi et al. 2016a]. L’idée est d’utiliser le Fog pour analyser rapidement une image issue de l’environnement. Dans ce cas d’utilisation, seule la contrainte de latence rend l’utilisation du Cloud non appropriée. Plus généralement, le Fog Computing peut être utilisé pour fournir de la puissance de calcul à des terminaux qui en ont besoin. Par exemple, un téléphone portable peut avoir besoin de plus de mémoire qu’il n’en possède. Une idée est alors de déporter la mémoire utilisée par les applications inutilisées sur un serveur de Fog Computing [Yi et al. 2015a]. L’utilisation d’un serveur proche permet de rapatrier rapidement les pages lorsque celles-ci seront demandées par le système.
Traitement vidéo
Pour Satyanarayanan et al. [Satyanarayanan et al. 2015], le Fog pourrait être utilisé pour stocker des vidéos enregistrées par des caméras situées en bordure du réseau. Les flux vidéos sont conséquents et le Cloud ne pourrait pas supporter un grand nombre de caméras. Toutefois, leur proposition ne s’arrête pas là, la hiérarchie de Fog permettrait de réaliser des traitements sur les vidéos, et notamment créer une base de centralisée dans le Cloud qui permette de rechercher dans les vidéos stockées dans le Fog.
Un autre cas d’utilisation des infrastructures de Fog Computing est la reconnaissance de visage [Hu et al. 2017]. Les passants sont filmés par une caméra et les images sont transmises à un site de Fog afin de reconnaître en temps réel les personnes.
Mise en cache de contenu
La mise en cache de contenus est un cas d’usage très fréquemment proposé. L’idée générale est d’utiliser l’infrastructure de Fog pour réduire le temps d’accès à une donnée (comme un site web [Zhu et al. 2013]), en répliquant le contenu proche des utilisateurs mais également pour réduire la charge des serveurs stockant lesdites données et permettre un meilleur passage à l’échelle [Zeydan et al. 2016].
Pour Luan et al. [Luan et al. 2015], un site de Fog peut être placé dans un bus pour mettre en cache du contenu vidéo diffusé pendant que ce dernier roule. Le Fog peut être également utilisé dans un magasin pour stocker des informations utiles de façon très localisée.
Par exemple, lorsque des spectateurs enregistrent une vidéo dans un stade et veulent la partager entre-eux. En utilisant une infrastructure de type Cloud, cela non seulement génère des temps de réponse élevés, génère une charge importante sur le Cloud (plusieurs centaines d’utilisateurs se connectent en même temps), mais aussi, cela occupe de façon importante les liens réseaux entre le stade et le centre de données hébergeant le service. Utiliser une infrastructure de Fog Computing permet de réduire les latences et de limiter la quantité de trafic réseau qui sort du stade.
Fonctions de virtualisation réseau
Un autre usage souvent proposé est d’utiliser une infrastructure de type Fog Computing pour déployer des fonctions réseau au plus près des utilisateurs [Vaquero et al. 2014 ; Yi et al. 2015b ; Vilalta et al. 2016 ; Chiang et al. 2016] L’approche consiste à virtualiser les équipements qui composent les réseaux informatiques (pare-feux, serveurs mandataires, routeurs, commutateurs) au sein des sites de Fog. Il n’est donc plus question d’aller déployer un pare-feu physique à tel ou tel endroit du réseau mais d’installer une machine virtuelle ayant ce rôle dans le site de Fog correspondant. Cette approche permet de créer des réseaux flexibles, reconfigurables et adaptés aux besoins des utilisateurs tout en garantissant une latence pour l’accès aux différents services. Placer des machines virtuelles accessibles avec une faible latence pour décharger des équipements mobiles a également été envisagé [Bittencourt et al. 2015].
Robotique et industrie du futur
L’Internet des Objets est aussi présent dans les usines et les processus industriels [Xu et al. 2014]. Dans cet environnement, le Fog Computing permet également de fournir de la puissance de calcul à des robots mobiles [Dey et al. 2016] afin de permettre une prise de décision rapide. Dans les usines du futur, le Fog peut être utilisé pour analyser les données issues de capteurs mais également pour contrôler la production de façon centralisée. Des machines virtuelles sont alors automatiquement déployées pour en contrôler le bon fonctionnement mais aussi pour les commander [Brito et al. 2016]. De même, pour Wan et al. [Wan et al. 2016], une infrastructure de Fog peut être utilisée pour produire des marchandises personnalisées selon les besoins de l’utilisateur. Par exemple, l’utilisateur donne les caractéristiques du produit qu’il souhaite sur le site web de l’entreprise puis le système de production est reparamatré afin que les machines fabriquent ce qui a été demandé.
Systèmes de stockage pour les grappes
Les données sont souvent stockées dans des fichiers, au sein de systèmes de fichiers en réseau qui mettent à disposition de l’ensemble des utilisateurs, une arborescence de dossiers et de fichiers [Levy et al. 1990]. Tous les utilisateurs accèdent simultanément à la même arborescence et le système de stockage s’occupe de gérer les permissions, les accès concurrents et la consistance. D’un point de vue de l’utilisateur, une fois le système de stockage monté dans son arborescence virtuelle (Virtual FileSystem ou VFS), les accès se font comme des accès aux fichiers stockés localement. Les accès aux fichiers se font avec certaine granularité (4 Ko, 8 Ko).
Historiquement, ces systèmes de fichiers en réseau étaient fournis par un seul et unique serveur de stockage centralisé auquel tous les nœuds de calcul se connectaient. Des proto-coles réseau comme NFS [Beame et al. 2003] (Network FileSystem) ou CIFS [Hertel 2003] (Common Internet FileSystem) étaient les plus couramment utilisés. Toutefois, le principal problème de cette approche est sa capacité à passer à l’échelle : le serveur central n’a pas le débit réseau nécessaire et devient un goulet d’étranglement lorsque beaucoup de clients souhaitent accéder à des données simultanément. De même, augmenter l’espace de stockage fourni n’était pas quelque chose de facile puisqu’il fallait bien souvent changer le serveur par un serveur permettant d’insérer plus de périphériques de stockage ou bien l’arrêter pour remplacer les disques durs par des disques de plus grande capacité.
Afin de pallier ces inconvénients, une nouvelle architecture fut proposée. Plusieurs serveurs de stockage sont utilisés simultanément et un serveur de métadonnées est utilisé en guise d’annuaire, pour stocker la localisation de chaque fichier. Pour accéder à une donnée, le client interroge le serveur de métadonnées pour déterminer la localisation de celle-ci, puis interroge le serveur de données stockant l’information souhaitée. Un tel protocole est décrit par le diagramme de la Figure L’intérêt d’une telle approche est non seulement de répartir la charge entre plusieurs serveurs de stockage mais également de permettre une meilleure parallélisation des accès. Bien que le serveur de métadonnées reçoit autant de requêtes que dans le cas d’un serveur centralisé, ce dernier a beaucoup moins de données à stocker et à transmettre aux clients, lui permettant d’avoir une charge plus faible qu’un serveur de stockage centralisé. Cette approche a été utilisée dans de nombreux systèmes de fichiers comme PVFS [Carns et al. 2000], Lustre [Donovan et al. 2003], ou encore RozoFS [Pertin et al. 2014].
Une telle approche propose un passage à l’échelle horizontal (Scale-Out NAS), cela signifie que pour augmenter de l’espace de stockage, il suffit simplement de rajouter des serveurs de stockage. Cela est très différent des approches proposant un passage à l’échelle vertical qui consistent à augmenter la capacité de stockage de chaque nœud en y ajoutant des disques durs, voire en remplaçant les machines par des machines ayant plus de ressources. L’avantage principal d’une telle approche est que l’ajout de serveurs de stockage n’augmente pas seulement la capacité de stockage du système de fichiers mais augmente également la capacité totale du réseau, ce qui permet à un nombre toujours plus important de clients d’accéder à l’infrastructure.
Cependant, l’ajout de serveurs augmente également la probabilité de défaillance du système. Afin de fournir une disponibilité des données conséquente, les pannes doivent être tolérées tout en permettant aux utilisateurs de continuer à accéder aux données. Elles ne sont plus l’exception mais la norme. En effet, les durées de vie des périphériques de stockage (Mean Time To Failure) ne sont pas infinies et plus il y a de périphériques de stockage, plus la probabilité que l’un d’entre eux soit défaillant est élevée. Certains systèmes comme Lustre [Donovan et al. 2003] proposent de répliquer les données (généralement 3 fois) tandis que d’autres comme RozoFS [Pertin et al. 2014] proposent d’utiliser des codes à effacement.
Plusieurs stratégies de réplication existent. Parmi les plus simples et les plus utilisées, une première consiste à faire que ce soit le client qui écrive l’ensemble des réplicas lorsqu’il modifie un objet tandis qu’une second stratégie consiste à ce que ce soit les serveurs de stockage qui réalisent la création et la modification des réplicas, permettant au client de ne réaliser l’écriture que d’un seul d’entre eux [Weil et al. 2006a].
Ces solutions s’appuient sur un réseau haute performance, fournissant des débits très élevés et de faibles latences. Elles ne sont par conséquent, pas adaptées pour fonctionner dans un environnement géographiquement distribué, où les sites sont interconnectés par un réseau de type WAN (Wide Area Network). Dans ce contexte, le site stockant le serveur de métadonnées concentrera une grande partie du trafic réseau, pouvant occasionner la saturation des liens mais aussi une indisponibilité des données dans le cas où ce serveur ne peut pas être atteint.
Systèmes de stockage pour les grilles
Comme nous l’avons détaillé dans la Section 1.1, la particularité des grilles est qu’elles sont réparties sur différents sites, interconnectés par un réseau de type WAN, avec un faible débit et une forte latence. Les systèmes de fichiers distribués présentés précédemment ne sont pas adaptés à un tel environnement car accéder à un serveur de stockage situé sur un site distant demande beaucoup de temps, limitant les performances fournies aux utilisateurs.
Des systèmes de fichiers spécifiques ont été développés comme XtreemFS [Hupfeld et al. 2008], GFarm [Tatebe et al. 2010], GlobalFS [Pacheco et al. 2016] ou certaines adaptations de Lustre [Simms et al. 2007 ; Walgenbach et al. 2010]. Afin de permettre un fonctionnement dans un environnement multi-sites ces systèmes de fichiers répliquent les données sur les sites où les utilisateurs y accèdent. En introduisant cette localité des données, cela permet aux utilisateurs de bénéficier d’accès rapides aux données, une fois que ces dernières ont été relocalisés.
Toutefois, cette approche ne résout pas le problème des métadonnées. Solliciter un serveur centralisé pour stocker la localisation des fichiers est coûteux et empêche le déploiement des systèmes de fichiers sur plusieurs sites. En effet, contacter, à l’aide de liens à forte latence, un premier site distant pour localiser le fichier puis un second site distant pour accéder à la donnée demande beaucoup de temps ce qui limite très fortement les performances du système. En plus de cette difficulté d’accès au serveur de métadonnées qui peut être atteignable avec une latence plus élevée que les données elles-mêmes, ces systèmes ont également des problèmes de consistance entre les sites.
Fondamentalement, il n’y a pas de grandes différences architecturales entre ces solutions et les solutions développées pour les grilles. L’architecture est la même. Les principales adaptations sont que les solutions de stockage pour les grilles s’appuient généralement sur des protocoles qui traversent facilement les pare-feu réseau comme le protocole HTTP mais également, comme nous venons de le dire, ces solutions utilisent une stratégie de placement et de réplication des données qui favorise la localité.
Systèmes de stockage pour les infrastructures de Cloud Computing
Traverser un système de fichiers est coûteux puisque par exemple, à chaque niveau, les permissions de l’utilisateur doivent être vérifiées. De plus, l’utilisation d’un serveur de métadonnées est l’élément le plus problématique, à la fois car cela crée un point unique de défaillance dans le réseau mais aussi parce qu’il peut également devenir le facteur limitant dans les performances du système.
Afin de permettre un meilleur passage à l’échelle, les solutions de stockage pour le Cloud reposent sur un stockage en mode objet. L’idée du stockage par objets est de proposer un espace de nommage « à plat ». La notion de dossiers disparaît, permettant de limiter les accès aux métadonnées, et chaque objet est uniquement identifié par son nom [Nightingale et al. 2012]. Les systèmes fournissent une interface basique et simple aux utilisateurs : les utilisateurs ne peuvent que demander à connaître le contenu d’un objet ou écrire un objet. Cette interface d’accès aux données est proposée notamment par Amazon S3 qui s’appuie notamment sur la solution de stockage Dynamo [DeCandia et al. 2007]. Cassandra est quant à lui une solution de stockage utilisée dans l’infrastructure de Facebook pour indexer les messages échangés entre les utilisateurs [Lakshman et al. 2010]
. Enfin, Rados [Weil et al. 2007] est également très souvent utilisé pour stocker les images de machines virtuelles au sein de la solution de virtualisation Openstack [Fitfield 2013]. Cette interface simple d’accès aux données permet de proposer des solutions de stockage qui ne reposent pas sur un serveur de métadonnées centralisées, supprimant le goulet d’étranglement que cela peut engendrer. Ces solutions peuvent donc fonctionner dans des environnements de plus large échelle tout en fournissant de meilleures performances tout que les solutions de stockage développés pour les grilles de calcul. Nous détaillerons par la suite, pourquoi ces systèmes sont des candidats potentiels pour les infrastructures de Fog Computing.
Nous notons toutefois que quelques systèmes de fichiers ont été proposés pour fonc-tionner dans des infrastructures de Cloud Computing. C’est le cas par exemple de Glusterfs [Davies et al. 2013] qui ne repose pas sur un serveur de métadonnées mais sur des fonctions de hachage. L’inconvénient majeur de cette solution est que les clients doivent connaître l’ensemble de la topologie, sans qu’aucun mécanisme ne soit proposé pour automatiser cela. D’autres personnes ont proposé de développer des systèmes de fichiers au-dessus des approches par objets, afin de retrouver une interface utilisable par les applications. C’est le cas notamment de CephFS [Weil et al. 2006a] qui s’appuie sur Rados ou encore Cassandra FileSystem (CFS) qui s’appuie sur la solution Cassandra [Lu-ciani 2012]. Du fait de leur implémentation considérant chaque bloc du fichier comme un objet, ces solutions sollicitent fortement le système de stockage par objets sous-jacent.
Réseaux de distribution de contenus
La problématique du stockage de données n’a pas été seulement étudiée sous une approche « système », mais elle a également été étudiée sous un aspect réseau. Dans les réseaux, la problématique est de stocker des données accédées par un grand nombre d’utilisateurs simultanément, tout en évitant une saturation des liens connectant la solution de stockage à ces derniers.
Les réseaux de diffusion de contenus (Content Distrbution Network ou CDN) consistent à mettre en cache des données issues d’une source sur des serveurs situés au plus près des utilisateurs. Cela a deux principaux intérêts : (i) accéder à un serveur proche permet de réduire les temps d’accès aux ressources demandées (ii) cela permet de réduire la charge du serveur central puisque ce dernier n’a plus qu’à envoyer le contenu une fois au plus, à chaque serveur de cache. Cette technique permet d’améliorer le passage à l’échelle. Akamai [Nygren et al. 2010] ou Cloudflare font partie des réseaux de distribution de contenus publics les plus connus mais nombreux sont ceux déployés en interne par les entreprises comme Google [Gill et al. 2007], afin d’améliorer leur qualité de service et d’usage.
Il n’y a pas d’architecture typique pour ces réseaux. Différentes architectures ont été proposées et sont aujourd’hui utilisées. Bien que les serveurs soient situés physique-ment près des utilisateurs, l’architecture du réseau dont nous parlons est un réseau de recouvrement.
Réseau de recouvrement organisé en arbre
La première approche consiste à organiser le réseau en arbre. La source de données se trouve à la racine de l’arbre. Les clients interrogent un serveur de cache. Lorsque celui-ci ne contient pas la donnée recherchée, il contacte à son tour son serveur parent. La requête remontre jusqu’au parent qui contient un réplica de la donnée, ou dans le pire des cas, jusqu’à la source de données située à la racine de l’arbre. Chaque nœud qui demande l’objet à son parent mettra en cache cette dernière lorsque le parent lui répondra. De cette façon, les données les plus fréquemment demandées sont plus à même de se trouver dans les serveurs caches situés près des clients
Ce mécanisme simple permet d’accéder au réplica de données le plus proche.
Le problème de cette approche est que la charge n’est pas équilibrée entre les nœuds, un nœud proche des feuilles de l’arbre sera bien plus souvent sollicité qu’un nœud proche de la racine. Pour faire face à cela, Karger et al. [Karger et al. 1997] proposent d’utiliser un arbre différent pour chaque objet, afin que toutes les requêtes ne suivent pas le même chemin. Pour cela, une fonction de hachage est utilisée. Dans l’approche proposée, l’empreinte de l’identifiant de la donnée à accéder est utilisée pour déterminer l’arbre.
À partir de cette empreinte chaque nœud détermine son nœud parent. Le problème de cette approche est qu’elle ne prend pas en compte la latence réseau. Le nœud parent d’un serveur peut physiquement être atteignable avec une latence élevée. De la même façon, les clients sont alors affectés à un serveur choisi aléatoirement.
Au lieu de construire un arbre en utilisant une fonction de hachage, d’autres ap-proches [Tran et al. 2005 ; Ganguly et al. 2005] proposent de prendre en compte le débit réseau et de construire un arbre dans lequel le débit est suffisant pour garantir que la donnée pourra être transférée en un temps relativement faible. Les algorithmes proposés reviennent à chercher un arbre couvrant de poids maximum.
Tout comme dans les approches de stockage distribuées, certaines approches consi-dèrent le placement des réplicas dans un réseau CDN [Kangasharju et al. 2002]. Au lieu de répliquer sur tous les nœuds du chemin sur lequel la donnée est demandée, des approches proposent de prendre en compte d’autres contraintes comme la capacité de stockage des nœuds ou la disponibilité de ces derniers [Khan et al. 2009].
Solutions reposant sur une table de hachage distribuée
Une autre architecture possible pour construire un réseau de diffusion de contenus est de reprendre les architectures utilisées dans les soluions de stockage distribués. Bien que certaines peuvent localiser les objets avec une approche centralisée, beaucoup d’autres reposent sur un mécanisme de placement distribué, comme nous pouvons trouver dans les solutions de stockage par objets. Ainsi CoralCDN [Freedman et al. 2004] ou encore UsenetDHT [Sit et al. 2005], deux réseaux de diffusion de contenu, reposent tous les deux sur une table de hachage distribuée pour stocker les données. Les nœuds ont également un cache local des derniers objets demandés afin de servir les clients plus rapidement. Les inconvénients d’une telle approche sont les mêmes que ceux des systèmes de stockage distribué, à savoir que le nœud devant stocker un réplica de données est déterminé à partir d’une fonction de hachage, limitant la localité.
Comme dans les systèmes de stockage distribués, certaines approches stockent loca-lement un réplica de la donnée et ne stockent que la localisation des données dans une structure de données telles qu’une table de hachage distribuée. C’est le cas par exemple de FlowerCDN [El Dick et al. 2009] qui utilise une table de hachage distribuée entre les sites et un serveur de métadonnées centralisé au sein de chaque site.
La principale différence de ces systèmes par rapport à un « véritable » système de stockage distribué est que les réplicas sont immuables. Les données en cache ne sont accédées qu’en lecture et ne sont jamais modifiées, ce qui simplifie les stratégies de réplication et la gestion de la consistance des données. Cela permet également de créer des réplicas à la volée. Dans les systèmes de fichiers distribué, le niveau de réplication est fixe, c’est-à-dire que les données sont répliquée deux ou trois fois par exemple. En revanche, dans les approche de type CDN, le nombre de réplicas de chaque donnée dépend de sa popularité.
Protocoles pairs à pairs
Au lieu d’organiser le réseau en arbre, des protocoles pairs à pairs comme BitTorrent [Le-gout et al. 2005] peuvent être utilisés entre les nœuds. De cette façon, les données ne sont pas téléchargées d’un seul et unique nœud parent mais de plusieurs nœuds simultanément. Cela permet de réduire le temps de transfert ainsi que la charge des liens réseau tout en augmentant la disponibilité de la donnée.
Le protocole BitTorrent fonctionne de la façon suivante. Les données sont découpées en pièces de taille fixe (par exemple 64 Ko). Le nœud voulant télécharger des données, récupère la liste des identifiants des pièces composant la donnée qu’il souhaite télécharger. Un serveur central appelé tracker ou une table de hachage distribuée est interrogée pour connaître la liste des nœuds stockant les pièces demandées. Le client se connecte alors à plusieurs nœuds stockant au moins une pièce et leur transmet la liste des pièces qu’il aimerait recevoir. Les pièces sont envoyées par blocs (par exemple de 512 octets) d’un nœud à l’autre. Au fur et à mesure que le client reçoit les morceaux de pièces dont il a besoin, il transmet des mises à jour de cette liste afin d’éviter de recevoir plusieurs fois les données. En effet, si deux nœuds stockent une même pièce, il est probable que les deux nœuds l’envoient au client puisque ce dernier demande à chaque nœud auquel il est connecté, la liste de toutes les pièces dont il a besoin. Il existe des mécanismes permettant de télécharger en premier les pièces rares, c’est-à-dire les pièces ayant le moins de réplicas et qui sont susceptibles de ne plus être disponibles en cas de panne d’un nœud ou de partitionnement du réseau. Nous noterons que les données dans BitTorrent, identifiées par leur empreinte, sont également immuables et ne peuvent pas être modifiées. Une telle approche est mise en œuvre dans des outils de synchronisation comme BitSync [Farina et al. 2014] ou Syncthing [Borg 2015].
Les protocoles pairs à pairs peuvent être utilisés exclusivement en bordure du réseau, entre les périphériques des utilisateurs [Palazzi et al. 2009] ou bien s’appuyer sur une infrastructure de Fog pour former un réseau de distribution de contenus hybride [Ghareeb et al. 2013 ; Xu et al. 2006] dans lesquels les clients n’interrogent pas directement le serveur de l’infrastructure de Fog mais essaient dans un premier temps de télécharger la donnée voulue depuis l’un de leurs voisins. Les clients ont également un rôle de serveur de cache, ce qui permet de réduire la charge des serveurs du réseau de diffusion de contenus. Xu et al. [Xu et al. 2006] proposent d’utiliser les serveurs du réseau de contenus pour y placer le tracker nécessaire à l’échange de données entre les clients. Afin de privilégier l’accès aux réplicas stockés sur des nœuds « proches » de l’utilisateur, plusieurs protocoles existent. Le protocole Vivaldi [Dabek et al. 2004b] permet de créer une « carte du réseau ». Une fois cette carte construite, il est alors possible de privilégier les nœuds situés à une faible distance. L’inconvénient de cette approche est que construire et maintenir la carte, génère une quantité importante de trafic sur le réseau.
Le protocole P4P [Xie et al. 2008 ; Kiesel et al. 2014] est quant à lui constitué d’un serveur central qui est interrogé par les nœuds voulant télécharger des données. Son rôle est de retourner une distance entre deux nœuds spécifiés. La distance peut être calculée de plusieurs façons et prendre en compte de nombreux paramètres tels que la latence réseau, l’homogénéité des débits sur le chemin, la sortie d’un système autonome (AS), etc. Les clients vont ensuite essayer de privilégier de télécharger les données depuis les nœuds ayant une faible distance. Cette approche intéresse fortement les opérateurs afin de confiner le trafic pair à pair au sein de leur réseau, évitant ainsi de toujours déployer des liens d’interconnexion avec les autres opérateurs de plus grandes capacités.
Réseaux centrés sur l’information (ICN)
Les réseaux centrés sur l’information (ou Information-Centric Networks ou ICN) et sa variante de Networking Named Content [Jacobson et al. 2009] est une technologie qui consiste à utiliser le réseau pour router les requêtes directement vers la machine stockant la donnée demandée. L’étape consistant à localiser la donnée avant d’y accéder a été supprimée. Le client envoie une requête dans le réseau à destination de la donnée qu’il souhaite accéder et non à destination d’une machine. Le réseau s’occupe alors de diriger celle-ci vers le serveur stockant la donnée qui répondra au client. Il est possible de considérer que l’ICN consiste, au lieu d’utiliser un serveur de métadonnées, à répartir celles-ci dans tout le réseau. Plusieurs mises en œuvre ont été proposées [Koponen et al. 2007 ; Jacobson et al. 2009 ; Hahm et al. 2017].
Une telle approche a été proposée pour fonctionner au sein d’un centre de données [Ko et al. 2012], au niveau d’une grille de calcul mais également dans un contexte distribué sur plusieurs sites et plus particulièrement dans un réseau de diffusion de contenu [Passa-rella 2012 ; Wires et al. 2017]. L’intérêt est de ne pas avoir à émettre de requête pour localiser la donnée et par conséquent de gagner du temps. Toutefois, la principale difficulté dans cette approche est que les routeurs du réseau doivent connaître l’emplacement de chaque réplica de données ce qui est coûteux en stockage.
Dans un réseau traditionnel, router le trafic internet demande beaucoup de ressources.Les routeurs d’aujourd’hui ont beaucoup de mal à fonctionner avec plus de 512 000 routes IPv4 [Shen 2014]. Pour limiter le nombre de routes, des méthodes d’agrégations consistant à utiliser la même route pour plusieurs destinations sont utilisées [Li 2011]. Dans IPv6, il est même proposé de ne pas annoncer de routes plus spécifiques qu’un préfixe de taille 32 ou 48 bits dans les tables de routage globales [Popoviciu et al. 2008] afin de limiter la taille de ces dernières. Les approches comme le protocole LISP (Locator/Identifier Separation Protocol) visent à séparer le rôle d’identificateur de l’adresse IP de son rôle permettant de localiser une machine. Dans ce contexte, de nombreuses propositions visant à résoudre le problème de passage à l’échelle des tables de routage ont été proposées mais aucune ne semble satisfaisante [Jakab et al. 2010 ; Mathy et al. 2008].
Il est évident qu’en enregistrant dans chaque routeur, une route par objet, l’ICN n’est pas une approche qui pourra passer à l’échelle. Afin de réduire la quantité de routes à déployer, Fayazbakhs et al. [Fayazbakhsh et al. 2013] proposent de regrouper les données stockées aux mêmes endroits et d’annoncer seulement les routes correspondant aux différents groupes. L’inconvénient d’une telle approche est que l’utilisateur a besoin de connaître le groupe auquel la donnée fait partie pour y accéder, ce qui peut revenir à devoir connaître l’endroit où elle est stockée. Cela pose également des difficultés lors de la création d’un nouveau réplica puisque lorsque un réplica d’une donnée est ajoutée, cette donnée n’a plus la même localisation que les autres du groupe, obligeant à la changer de groupe.
Réseaux logiciels (SDN)
Les réseaux logiciels ou Software Defined Networks (SDN) sont généralement utilisés pour déployer une configuration réseau de manière centralisée [Qin et al. 2014]. L’utilisation d’une telle infrastructure a également été proposée pour maintenir les tables de routage au sein d’un ICN [Veltri et al. 2012]. Le Software Defined Network consiste à déployer le paramétrage d’un réseau de façon logicielle, notamment les routes des routeurs. Trois composants sont utilisés : une base de données qui contient la description du service à fournir ; des routeurs qui reçoivent leur table de routage par le réseau ; un contrôleur centralisé qui déploie les routes de chaque routeur.
Dans le SDN, le routage ne se fait pas forcément uniquement sur le critère de l’adresse de destination d’un paquet mais peut se faire sur d’autres critères comme la source ou encore le type de paquet. Dans le cas d’un réseau centré sur l’information, la localisation des objets est stockée dans la base de données. Le contrôleur calcule ensuite la table de routage de chaque router et la déploie. Cela est illustré par la Figure 2.2.
Dans certaines approches, le contrôleur est également utilisé pour réaliser le placement des données (ou de machines virtuelles [Costa-Requena et al. 2015]). Dans ce cas, il est facile d’assimiler le rôle du contrôleur à celui d’un serveur de métadonnées, comme dans les solutions de stockage distribuées traditionnelles.
Nous noterons que le SDN a les mêmes difficultés de passage à l’échelle que celles mentionnées précédemment [Casado et al. 2012 ; Yeganeh et al. 2013] Ainsi, de plus en plus d’approches cherchent à utiliser plusieurs contrôleurs simultanément [Sun et al. 2013 ; Jiménez et al. 2014 ; Wan et al. 2016], ou encore, cherchent à placer ces derniers dans une infrastructure de Cloud Computing, là où les ressources virtuellement infinies [Kahvazadeh et al. 2017]. Une chose est sûre, le placement du ou des contrôleurs est un problème à part entière [Heller et al. 2012].
|
Table des matières
Introduction
I Contexte & État de l’art
1 Informatique utilitaire : quelles infrastructures après le Cloud ?
1.1 Petit historique de l’informatique utilitaire
1.2 Les besoins de l’Internet des Objets (IdO)
1.3 Une taxonomie des infrastructures
1.3.1 Informatique en nuage ou Cloud Computing
1.3.2 Edge Computing
1.3.3 Extrême Edge Computing
1.3.4 Mobile Cloud Computing
1.3.5 Fog Computing
1.3.6 Hypothèses de travail
1.4 Exemples d’applications du Fog Computing
1.4.1 Des feux de signalisation intelligents à la ville intelligente
1.4.2 Domaine de la santé
1.4.3 Réalité augmentée
1.4.4 Traitement vidéo
1.4.5 Mise en cache de contenu
1.4.6 Fonctions de virtualisation réseau
1.4.7 Robotique et industrie du futur
1.5 Conclusions
2 Les solutions de partage de données dans une infrastructure distribuée
2.1 Systèmes de stockage pour les grappes
2.2 Systèmes de stockage pour les grilles
2.3 Systèmes de stockage pour les infrastructures de Cloud Computing
2.4 Réseaux de distribution de contenus
2.4.1 Réseau de recouvrement organisé en arbre
2.4.2 Solutions reposant sur une table de hachage distribuée
2.4.3 Protocoles pairs à pairs
2.4.4 Réseaux centrés sur l’information (ICN)
2.4.5 Réseaux logiciels (SDN)
2.5 Conclusions
3 Les spécificités du stockage de données dans une infrastructure de Fog Computing
3.1 Caractéristiques attendues d’un système de stockage pour le Fog
3.1.1 Localité des données
3.1.2 Disponibilité des données
3.1.3 Confinement du trafic réseau
3.1.4 Fonctionnement en mode déconnecté
3.1.5 Support de la mobilité
3.1.6 Passage à l’échelle
3.2 Modèles de charge
3.3 Adéquations des systèmes existants au modèle de Fog Computing
3.3.1 Solutions issues des grappes et les grilles de calcul
3.3.2 Solutions issues des infrastructures de Cloud Computing
3.3.3 Solutions issues des réseaux de distribution de contenus (CDN) . . 45
3.4 Conclusions
Conclusion
II Contributions
4 Comparaison de solutions existantes en matières de temps d’accès de trafic résea
4.1 Configuration et déploiement de solutions de stockage par objets dans un environnement de Fog Computing
4.1.1 Rados
4.1.2 Cassandra
4.1.3 Interplanetary FileSystem (IPFS)
4.1.4 Conclusions
4.2 Comparaison expérimentale des différentes solutions
4.2.1 Matériels et méthodes
4.2.2 Évaluation des accès locaux
4.2.3 Évaluation des accès distants
4.2.4 Résumé de l’évaluation des trois solutions de stockage
4.3 Conclusions
5 Conception d’un système de stockage distribué pour le Fog
5.1 Réduction des trafics réseau inter-sites pour les accès locaux
5.1.1 Description du problème
5.1.2 Solution proposée
5.1.3 Limitations
5.1.4 Conclusions
5.2 Confinement des trafics réseau inter-sites lors d’accès distants
5.2.1 Approches pour localiser des données
5.2.2 Tables de hachages distribuées
5.2.3 Le Domain Name System : un protocole de résolution de noms
5.2.4 Notre proposition de protocole
5.2.5 Algorithmes pour la génération d’arbres couvrants
5.2.6 Notre approche de construction de l’arbre
5.2.7 Surcoût de notre approche
5.2.8 Conclusions
5.3 Conclusion
6 Évaluation expérimentale des approches proposées
6.1 Évaluation du couplage IPFS et d’un Scale-Out NAS
6.1.1 Matériels et méthodes
6.1.2 Écriture/Lecture depuis le site local
6.1.3 Lecture depuis un site distant
6.1.4 Conclusion
6.2 Évaluation de l’approche en arbre
6.2.1 Matériels & méthodes
6.2.2 Micro-comparaisons
6.2.3 Macro-comparaison
6.2.4 Conclusion
6.3 Utilisation simultanée des plateformes Grid’5000 et FIT/IoT-Lab
6.3.1 Présentation de FIT/IoT-Lab
6.3.2 Proposition / expérimentation
6.3.3 Interconnexion des plateformes
6.3.4 Limitations
6.3.5 Conclusion
6.4 Conclusion
Conclusion générale
Perspectives
6.4.1 Amélioration de l’implémentation
6.4.2 Améliorations théoriques
6.4.3 Perspectives de déploiement et d’utilisation
Références
Télécharger le rapport complet
