puting . . . . 44
3.3.1 Solutions issues des grappes et les grilles de calcul . . . 44
3.3.2 Solutions issues des infrastructures de Cloud Computing. . . . 44
3.3.3 Solutions issues des réseaux de distribution de contenus (CDN) 45
3.4 Conclusions . . . . 46
Dans ce chapitre, nous nous intéressons aux particularités et aux caractéristiques que nous souhaitons avoir pour qu’une solution soit adaptée à un fonctionnement dans
42
Chapitre 3. Les spécificités du stockage de données dans une infrastructure de Fog Computing
un environnement de Fog Computing. Dans une seconde partie, nous vérifierons de manière théorique si les solutions de stockage proposées pour les infrastructures de Cloud Computing satisfont ces caractéristiques.
3.1
Caractéristiques attendues d’un système de stockage
pour le Fog
Notre objectif est de créer un système de stockage unifié dans le Fog, cela signifie que chaque utilisateur doit pouvoir accéder à l’ensemble des données stockées, quel que soit le site auquel ce dernier est connecté. Nous avons défini plusieurs caractéristiques qu’un système de stockage idéal doit satisfaire.
3.1.1 Localité des données
L’idée de la localité des données est que les temps d’accès doivent être les plus faibles possibles. Pour cela, les données doivent toujours se trouver à l’endroit où elles sont utilisées. Lorsqu’un utilisateur écrit une donnée, il doit écrire sur le site de Fog le plus proche, c’est-à-dire, celui atteignable avec la plus faible latence possible. Il en est de même lors de la lecture : les données accédées doivent se trouver sur le site auquel l’utilisateur est connecté, toujours dans ce même but de minimisation des temps d’accès. Nous voulons donc limiter les accès pour lesquels la donnée accédée n’est pas présente sur le site.
3.1.2 Disponibilité des données
Nous voulons un système dans lequel les nœuds des sites puissent tomber en panne sans affecter les performances du système en général. Les pannes isolées doivent être dans la mesure du possible, gérées au sein du site dans lequel elles se sont produites, sans impacter les autres sites.
3.1.3 Confinement du trafic réseau
Le confinement du trafic réseau consiste à limiter le trafic réseau circulant entre les sites de Fog. Cette caractéristique peut se détailler en trois éléments. Premièrement, le trafic doit être limité aux actions initiées par les utilisateurs : lorsqu’aucun utilisateur ne sollicite le système, il ne doit pas y avoir d’échanges entre les sites. Deuxièmement, lorsqu’un utilisateur accède à des données stockées localement, cela ne doit pas non plus générer de trafic réseau vers les autres sites. Si un site a une activité plus élevée, les performances des autres sites ne doivent pas être impactées. Enfin, lorsqu’un utilisateur accède à des données qui ne sont pas stockées localement sur le site de Fog auquel il est connecté, les données doivent être rapatriées. Les sites qui ne sont pas concernés par cet échange de données ne doivent pas être sollicités.
La topologie physique du réseau doit également être prise en compte : lorsque deux sites échangent des données, il semble préférable que ces échanges concernent des sites
3.2. Modèles de charge 43
physiquement proches et interconnectés par un lien réseau de faible distance plutôt que deux sites éloignés, sollicitant un nombre important d’équipements intermédiaires.
3.1.4 Fonctionnement en mode déconnecté
La possibilité d’accéder aux données localement en cas de partitionnement du réseau est une caractéristique essentielle. En cas de panne des liens réseaux entre les sites de Fog, les données stockées localement sur le site auquel l’utilisateur est connecté doivent rester accessibles. Les sites doivent donc être les plus indépendants possibles les uns des autres.
3.1.5 Support de la mobilité
Le support de la mobilité consiste pour les utilisateurs à pouvoir se déplacer et par conséquent à changer le site auquel ils sont connectés. Lorsque la donnée accédée n’est pas présente localement, celle-ci doit être rapatriée et relocalisée de manière transparente sur le site courant afin de réduire les temps d’accès des futurs accès.
3.1.6 Passage à l’échelle
Enfin, le passage à l’échelle consiste, lorsque la quantité de données stockées augmente, à éviter que les performances se dégradent. De la même façon, le système doit pouvoir supporter à la fois un grand nombre de sites, un grand nombre de clients et être capable de stocker de grandes quantités de données. Dans ce travail, nous ne traitons pas le problème de savoir à quel site de Fog un client doit-il être rattaché. Nous considérons que le site le plus prêt en matière de latence est celui utilisé. Certains travaux étudient la possibilité de vérifier les contraintes, notamment si les ressources fournies sont suffisantes pour le client avant de réaliser l’affectation [Fan et al.2015]. Nous ne traitons pas non plus le problème consistant à déterminer si une requête doit être envoyée dans le Fog, traitée en local ou envoyée directement dans une infrastructure de Cloud Computing. Cette question a été traitée dans plusieurs travaux [Yousefpour et al.2017; Olaniyan
et al. 2018].
3.2
Modèles de charge
Une des questions principales lorsqu’un système de stockage est conçu est de savoir si celui-ci va pouvoir répondre au besoin, c’est-à-dire, qu’il pourra faire face au nombre et à la fréquence des requêtes et s’il pourra stocker la quantité de données souhaitée. Il n’existe pas à notre connaissance d’article mentionnant le modèle de charge dans une infrastructure Fog : quelle est la taille des données à écrire, à lire ainsi que leur nombre et leur fréquence d’accès. Plusieurs auteurs [Anwar et al. 2016; Atikoglu et al. 2012] proposent cependant des exemples de charges pour des systèmes de stockage clés/valeurs dans un contexte de Cloud Computing. Pour Anwar et al., les petits objets ayant une taille d’environ 128 Ko et qui sont très souvent accédés en lecture peuvent correspondre à des pages web tandis que les jeux vidéos en ligne nécessitent des accès en écriture plus
44
Chapitre 3. Les spécificités du stockage de données dans une infrastructure de Fog Computing
fréquents. Les objets de plus grande taille (128 Mo), les cas d’usage proposés sont le partage de vidéo et la sauvegarde.