Système de fichiers distribué pour le cloud

Un système de fichiers distribué pour le cloud est un système de fichiers qui permet à de nombreux clients d'avoir accès aux données et prend en charge les opérations (créer, supprimer, modifier, lire, écrire) sur ces données. Chaque fichier de données peut être partitionné en plusieurs parties appelées chunks . Chaque chunk peut être stocké sur différentes machines distantes, facilitant l'exécution parallèle d'applications. En général, les données sont stockées dans des fichiers dans une arborescence hiérarchique , où les nœuds représentent des répertoires. Il existe plusieurs façons de partager des fichiers dans une architecture distribuée : chaque solution doit être adaptée à un certain type d'application, en fonction de la complexité de l'application. Parallèlement, la sécurité du système doit être assurée. Confidentialité , disponibilité et intégrité sont les principales clés d'un système sécurisé.

Les utilisateurs peuvent partager des ressources informatiques via Internet grâce au cloud computing , qui se caractérise généralement par des ressources évolutives et élastiques , telles que des serveurs physiques , des applications et des services virtualisés et alloués de manière dynamique. La synchronisation est nécessaire pour garantir que tous les appareils sont à jour.

Les systèmes de fichiers distribués permettent à de nombreuses grandes, moyennes et petites entreprises de stocker et d'accéder à leurs données distantes comme elles le font avec leurs données locales, facilitant ainsi l'utilisation de ressources variables.

Aujourd'hui, il existe de nombreuses implémentations de systèmes de fichiers distribués. Les premiers serveurs de fichiers ont été développés par des chercheurs dans les années 1970. Le système de fichiers en réseau de Sun Microsystems est devenu disponible dans les années 1980. Avant cela, les personnes qui voulaient partager des fichiers utilisaient la méthode sneakernet , transportant physiquement les fichiers sur des supports de stockage d'un endroit à un autre. Une fois que les réseaux informatiques ont commencé à proliférer, il est devenu évident que les systèmes de fichiers existants présentaient de nombreuses limitations et n'étaient pas adaptés aux environnements multi-utilisateurs. Les utilisateurs ont d'abord utilisé le FTP pour partager des fichiers. Le FTP a été lancé pour la première fois sur le PDP-10 à la fin de 1973. Même avec le FTP, les fichiers devaient être copiés de l'ordinateur source sur un serveur, puis du serveur sur l'ordinateur de destination. Les utilisateurs devaient connaître les adresses physiques de tous les ordinateurs impliqués dans le partage de fichiers.

Les centres de données modernes doivent prendre en charge des environnements hétérogènes de grande taille, constitués d'un grand nombre d'ordinateurs de capacités diverses. Le cloud computing coordonne le fonctionnement de tous ces systèmes, avec des techniques telles que la mise en réseau des centres de données (DCN), le framework MapReduce , qui prend en charge les applications informatiques gourmandes en données dans des systèmes parallèles et distribués, et les techniques de virtualisation qui fournissent une allocation dynamique des ressources, permettant à plusieurs systèmes d'exploitation de coexister sur le même serveur physique.

Le cloud computing permet de réaliser des calculs à grande échelle grâce à sa capacité à fournir à l'utilisateur les ressources CPU et de stockage nécessaires en toute transparence. Cela rend le cloud computing particulièrement adapté à la prise en charge de différents types d'applications qui nécessitent un traitement distribué à grande échelle. Ce calcul intensif en données nécessite un système de fichiers hautes performances capable de partager les données entre les machines virtuelles (VM).

Le cloud computing alloue de manière dynamique les ressources nécessaires, les libérant une fois la tâche terminée, obligeant les utilisateurs à payer uniquement pour les services nécessaires, souvent via un accord de niveau de service . Les paradigmes du cloud computing et du cluster computing deviennent de plus en plus importants pour le traitement des données industrielles et les applications scientifiques telles que l'astronomie et la physique, qui nécessitent souvent la disponibilité d'un grand nombre d'ordinateurs pour mener des expériences.

La plupart des systèmes de fichiers distribués sont construits sur l'architecture client-serveur, mais d'autres solutions décentralisées existent également.

Le système de fichiers en réseau (NFS) utilise une architecture client-serveur qui permet le partage de fichiers entre plusieurs machines sur un réseau comme si elles étaient situées localement, offrant ainsi une vue standardisée. Le protocole NFS permet aux processus de clients hétérogènes, probablement exécutés sur des machines différentes et sous différents systèmes d'exploitation, d'accéder à des fichiers sur un serveur distant, en ignorant l'emplacement réel des fichiers. Le fait de s'appuyer sur un seul serveur entraîne une disponibilité potentiellement faible et une faible évolutivité du protocole NFS. L'utilisation de plusieurs serveurs ne résout pas le problème de disponibilité puisque chaque serveur fonctionne indépendamment. Le modèle de NFS est un service de fichiers distant. Ce modèle est également appelé modèle d'accès à distance, qui s'oppose au modèle de téléchargement :

• Modèle d'accès à distance : offre une transparence, le client a accès à un fichier. Il envoie des requêtes au fichier distant (tandis que le fichier reste sur le serveur).
• Modèle de téléchargement/téléchargement : le client ne peut accéder au fichier que localement. Cela signifie que le client doit télécharger le fichier, y apporter des modifications, puis le télécharger à nouveau pour qu'il soit utilisé par d'autres clients.

Le système de fichiers utilisé par NFS est quasiment identique à celui utilisé par les systèmes Unix . Les fichiers sont organisés hiérarchiquement dans un graphe de nommage dans lequel les répertoires et les fichiers sont représentés par des nœuds.

Une architecture basée sur des clusters améliore certains problèmes rencontrés dans les architectures client-serveur, en améliorant l'exécution des applications en parallèle. La technique utilisée ici est le file-striping : un fichier est divisé en plusieurs morceaux, qui sont « répartis » sur plusieurs serveurs de stockage. L'objectif est de permettre l'accès à différentes parties d'un fichier en parallèle. Si l'application ne bénéficie pas de cette technique, il serait alors plus pratique de stocker différents fichiers sur différents serveurs. Cependant, lorsqu'il s'agit d'organiser un système de fichiers distribué pour de grands centres de données, tels qu'Amazon et Google, qui offrent des services aux clients Web permettant de multiples opérations (lecture, mise à jour, suppression,...) sur un grand nombre de fichiers répartis sur un grand nombre d'ordinateurs, alors les solutions basées sur des clusters deviennent plus avantageuses. Notez qu'avoir un grand nombre d'ordinateurs peut signifier plus de pannes matérielles. Deux des systèmes de fichiers distribués (DFS) les plus utilisés de ce type sont le Google File System (GFS) et le Hadoop Distributed File System (HDFS). Les systèmes de fichiers des deux sont implémentés par des processus de niveau utilisateur exécutés sur un système d'exploitation standard ( Linux dans le cas de GFS).

Google File System (GFS) et Hadoop Distributed File System (HDFS) sont spécifiquement conçus pour gérer le traitement par lots sur de très grands ensembles de données. Pour cela, les hypothèses suivantes doivent être prises en compte :

• Haute disponibilité : le cluster peut contenir des milliers de serveurs de fichiers et certains d'entre eux peuvent être en panne à tout moment
• Un serveur appartient à un rack, une salle, un centre de données, un pays et un continent, afin d'identifier précisément sa situation géographique
• La taille d'un fichier peut varier de plusieurs gigaoctets à plusieurs téraoctets. Le système de fichiers doit pouvoir prendre en charge un nombre considérable de fichiers.
• La nécessité de prendre en charge les opérations d'ajout et de permettre au contenu du fichier d'être visible même pendant l'écriture d'un fichier
• La communication entre les machines en fonctionnement est fiable : TCP/IP est utilisé avec une abstraction de communication RPC par appel de procédure à distance . TCP permet au client de savoir presque immédiatement quand il y a un problème et qu'il est nécessaire d'établir une nouvelle connexion.

L'équilibrage de charge est essentiel pour un fonctionnement efficace dans des environnements distribués. Il s'agit de répartir le travail entre différents serveurs, de manière équitable, afin d'accomplir plus de travail dans le même laps de temps et de servir les clients plus rapidement. Dans un système contenant N chunkservers dans un cloud (N étant 1000, 10000 ou plus), où un certain nombre de fichiers sont stockés, chaque fichier est divisé en plusieurs parties ou chunks de taille fixe (par exemple, 64 mégaoctets), la charge de chaque chunkserver étant proportionnelle au nombre de chunks hébergés par le serveur. Dans un cloud à charge équilibrée, les ressources peuvent être utilisées efficacement tout en maximisant les performances des applications basées sur MapReduce.

Dans un environnement de cloud computing, les pannes sont la norme, et les serveurs de blocs peuvent être mis à niveau, remplacés et ajoutés au système. Les fichiers peuvent également être créés, supprimés et ajoutés de manière dynamique. Cela conduit à un déséquilibre de charge dans un système de fichiers distribué, ce qui signifie que les blocs de fichiers ne sont pas répartis équitablement entre les serveurs.

Les systèmes de fichiers distribués dans les clouds tels que GFS et HDFS s'appuient sur des serveurs centraux ou maîtres ou des nœuds (Master pour GFS et NameNode pour HDFS) pour gérer les métadonnées et l'équilibrage de charge. Le maître rééquilibre périodiquement les répliques : les données doivent être déplacées d'un DataNode/chunkserver vers un autre si l'espace libre sur le premier serveur tombe en dessous d'un certain seuil. Cependant, cette approche centralisée peut devenir un goulot d'étranglement pour ces serveurs maîtres, s'ils deviennent incapables de gérer un grand nombre d'accès aux fichiers, car cela augmente leurs charges déjà lourdes. Le problème de rééquilibrage de charge est NP-difficile .

Afin de permettre à un grand nombre de serveurs de blocs de travailler en collaboration et de résoudre le problème de l'équilibrage de charge dans les systèmes de fichiers distribués, plusieurs approches ont été proposées, telles que la réaffectation des blocs de fichiers afin que les blocs puissent être distribués aussi uniformément que possible tout en réduisant autant que possible le coût de déplacement.

Google, l'une des plus grandes entreprises Internet, a créé son propre système de fichiers distribués, appelé Google File System (GFS), pour répondre aux besoins croissants de Google en matière de traitement de données. Il est utilisé pour tous les services cloud. GFS est un système de fichiers distribué évolutif pour les applications gourmandes en données. Il fournit un stockage de données hautes performances et tolérant aux pannes auquel un grand nombre de clients accèdent simultanément.

GFS utilise MapReduce , qui permet aux utilisateurs de créer des programmes et de les exécuter sur plusieurs machines sans se soucier des problèmes de parallélisation et d'équilibrage de charge. L'architecture GFS est basée sur un seul serveur maître pour plusieurs serveurs de blocs et plusieurs clients.

Le serveur maître exécuté sur un nœud dédié est responsable de la coordination des ressources de stockage et de la gestion des métadonnées des fichiers (l'équivalent, par exemple, des inodes dans les systèmes de fichiers classiques). Chaque fichier est divisé en plusieurs blocs de 64 mégaoctets. Chaque bloc est stocké dans un serveur de blocs. Un bloc est identifié par un handle de bloc, qui est un numéro 64 bits unique au monde attribué par le maître lors de la première création du bloc.

Le serveur maître conserve toutes les métadonnées des fichiers, y compris les noms de fichiers, les répertoires et le mappage des fichiers à la liste des segments qui contiennent les données de chaque fichier. Les métadonnées sont conservées dans la mémoire principale du serveur maître, avec le mappage des fichiers aux segments. Les mises à jour de ces données sont enregistrées dans un journal des opérations sur le disque. Ce journal des opérations est répliqué sur des machines distantes. Lorsque le journal devient trop volumineux, un point de contrôle est effectué et les données de la mémoire principale sont stockées dans une structure B-tree pour faciliter le mappage dans la mémoire principale.

Pour faciliter la tolérance aux pannes , chaque bloc est répliqué sur plusieurs serveurs de blocs (par défaut, trois). Un bloc est disponible sur au moins un serveur de blocs. L'avantage de ce schéma est la simplicité. Le maître est responsable de l'allocation des serveurs de blocs pour chaque bloc et n'est contacté que pour les informations de métadonnées. Pour toutes les autres données, le client doit interagir avec les serveurs de blocs.

Le maître garde une trace de l'emplacement d'un bloc. Cependant, il ne tente pas de maintenir les emplacements des blocs avec précision, mais contacte seulement occasionnellement les serveurs de blocs pour voir quels blocs ils ont stockés. Cela permet une évolutivité et aide à éviter les goulots d'étranglement dus à une charge de travail accrue.

Dans GFS, la plupart des fichiers sont modifiés en ajoutant de nouvelles données et non en écrasant les données existantes. Une fois écrits, les fichiers sont généralement lus de manière séquentielle plutôt que de manière aléatoire, ce qui fait de ce DFS le plus adapté aux scénarios dans lesquels de nombreux fichiers volumineux sont créés une fois mais lus plusieurs fois.

Lorsqu'un client souhaite écrire/mettre à jour un fichier, le maître lui assigne une réplique, qui sera la réplique principale s'il s'agit de la première modification. Le processus d'écriture se compose de deux étapes :

• Envoi : Tout d'abord, et de loin le plus important, le client contacte le maître pour savoir quels serveurs de blocs contiennent les données. Le client reçoit une liste de répliques identifiant les serveurs de blocs primaires et secondaires. Le client contacte ensuite le serveur de blocs de répliques le plus proche et lui envoie les données. Ce serveur enverra les données au serveur le plus proche, qui les transmettra ensuite à un autre serveur de répliques, et ainsi de suite. Les données sont ensuite propagées et mises en cache en mémoire, mais pas encore écrites dans un fichier.
• Écriture : lorsque toutes les répliques ont reçu les données, le client envoie une demande d'écriture au serveur de blocs principal, en identifiant les données qui ont été envoyées lors de la phase d'envoi. Le serveur principal attribue ensuite un numéro de séquence aux opérations d'écriture qu'il a reçues, applique les écritures au fichier dans l'ordre des numéros de série et transmet les demandes d'écriture dans cet ordre aux serveurs secondaires. Pendant ce temps, le serveur maître est tenu à l'écart de la boucle.

Par conséquent, nous pouvons différencier deux types de flux : le flux de données et le flux de contrôle. Le flux de données est associé à la phase d'envoi et le flux de contrôle est associé à la phase d'écriture. Cela garantit que le serveur de blocs principal prend le contrôle de l'ordre d'écriture. Notez que lorsque le maître attribue l'opération d'écriture à une réplique, il incrémente le numéro de version du bloc et informe toutes les répliques contenant ce bloc du nouveau numéro de version. Les numéros de version des blocs permettent de détecter les erreurs de mise à jour, si une réplique n'a pas été mise à jour parce que son serveur de blocs était en panne.

Certaines nouvelles applications Google ne fonctionnaient pas bien avec la taille de bloc de 64 mégaoctets. Pour résoudre ce problème, GFS a commencé, en 2004, à mettre en œuvre l' approche Bigtable .

HDFS , développé par l' Apache Software Foundation , est un système de fichiers distribué conçu pour contenir de très grandes quantités de données (téraoctets ou même pétaoctets). Son architecture est similaire à celle de GFS, c'est-à-dire une architecture serveur/client. HDFS est normalement installé sur un cluster d'ordinateurs. Le concept de conception de Hadoop s'inspire de celui de Google, avec Google File System, Google MapReduce et Bigtable , mis en œuvre respectivement par Hadoop Distributed File System (HDFS), Hadoop MapReduce et Hadoop Base (HBase). Comme GFS, HDFS est adapté aux scénarios avec accès aux fichiers en écriture unique et lecture multiple, et prend en charge les ajouts et les troncatures de fichiers au lieu de lectures et d'écritures aléatoires pour simplifier les problèmes de cohérence des données.

Un cluster HDFS se compose d'un seul NameNode et de plusieurs machines DataNode. Le NameNode, un serveur maître, gère et conserve les métadonnées des DataNodes de stockage dans sa RAM. Les DataNodes gèrent le stockage attaché aux nœuds sur lesquels ils s'exécutent. NameNode et DataNode sont des logiciels conçus pour s'exécuter sur des machines d'usage courant, qui fonctionnent généralement sous un système d'exploitation Linux. HDFS peut être exécuté sur n'importe quelle machine prenant en charge Java et peut donc exécuter soit un NameNode, soit le logiciel Datanode.

Sur un cluster HDFS, un fichier est divisé en un ou plusieurs blocs de taille égale, à l'exception de la possibilité que le dernier bloc soit plus petit. Chaque bloc est stocké sur plusieurs DataNodes, et chacun peut être répliqué sur plusieurs DataNodes pour garantir la disponibilité. Par défaut, chaque bloc est répliqué trois fois, un processus appelé « réplication au niveau du bloc ».

Le NameNode gère les opérations de l'espace de noms du système de fichiers telles que l'ouverture, la fermeture et le changement de nom des fichiers et des répertoires, et régule l'accès aux fichiers. Il détermine également le mappage des blocs aux DataNodes. Les DataNodes sont responsables du traitement des demandes de lecture et d'écriture des clients du système de fichiers, de la gestion de l'allocation ou de la suppression des blocs et de la réplication des blocs.

Lorsqu'un client souhaite lire ou écrire des données, il contacte le NameNode et le NameNode vérifie où les données doivent être lues ou écrites. Après cela, le client connaît l'emplacement du DataNode et peut lui envoyer des demandes de lecture ou d'écriture.

Le système HDFS se caractérise généralement par sa compatibilité avec les schémas de rééquilibrage des données. En général, la gestion de l'espace libre sur un DataNode est très importante. Les données doivent être déplacées d'un DataNode à un autre si l'espace libre n'est pas suffisant ; et dans le cas de la création de répliques supplémentaires, les données doivent être déplacées pour assurer l'équilibre du système.

Les systèmes de fichiers distribués peuvent être optimisés à différentes fins. Certains, comme ceux conçus pour les services Internet, notamment GFS, sont optimisés pour l'évolutivité. D'autres conceptions de systèmes de fichiers distribués prennent en charge les applications gourmandes en performances, généralement exécutées en parallèle. Quelques exemples incluent : MapR File System (MapR-FS), Ceph-FS , Fraunhofer File System (BeeGFS) , Lustre File System , IBM General Parallel File System (GPFS) et Parallel Virtual File System .

MapR-FS est un système de fichiers distribué qui constitue la base de la plate-forme convergée MapR, avec des capacités de stockage de fichiers distribués, une base de données NoSQL avec plusieurs API et un système de diffusion de messages intégré. MapR-FS est optimisé pour l'évolutivité, les performances, la fiabilité et la disponibilité. Sa capacité de stockage de fichiers est compatible avec l'API Apache Hadoop Distributed File System (HDFS) mais avec plusieurs caractéristiques de conception qui le distinguent de HDFS. Parmi les différences les plus notables, on trouve le fait que MapR-FS est un système de fichiers entièrement en lecture/écriture avec des métadonnées pour les fichiers et les répertoires distribués dans l'espace de noms, il n'y a donc pas de NameNode.

Ceph-FS est un système de fichiers distribué qui offre d'excellentes performances et une excellente fiabilité. Il répond aux défis de la gestion de fichiers et de répertoires volumineux, de la coordination de l'activité de milliers de disques, de l'accès parallèle aux métadonnées à grande échelle, de la manipulation de charges de travail scientifiques et à usage général, de l'authentification et du chiffrement à grande échelle, et de l'augmentation ou de la diminution dynamique en raison de la mise hors service fréquente des appareils, des pannes d'appareils et des extensions de cluster.

BeeGFS est le système de fichiers parallèle hautes performances du Centre de compétences Fraunhofer pour le calcul hautes performances. L'architecture de métadonnées distribuées de BeeGFS a été conçue pour fournir l'évolutivité et la flexibilité nécessaires à l'exécution d'applications HPC et similaires avec des exigences d'E/S élevées.

Lustre File System a été conçu et implémenté pour traiter le problème des goulots d'étranglement traditionnellement rencontrés dans les systèmes distribués. Lustre se caractérise par son efficacité, son évolutivité et sa redondance. GPFS a également été conçu dans le but de supprimer ces goulots d'étranglement.

Les performances élevées des systèmes de fichiers distribués nécessitent une communication efficace entre les nœuds de calcul et un accès rapide aux systèmes de stockage. Les opérations telles que l'ouverture, la fermeture, la lecture, l'écriture, l'envoi et la réception doivent être rapides pour garantir les performances. Par exemple, chaque demande de lecture ou d'écriture accède au stockage sur disque, ce qui introduit des latences de recherche, de rotation et de réseau.

Les opérations de communication de données (envoi/réception) transfèrent les données du tampon d'application vers le noyau de la machine, TCP contrôlant le processus et étant implémenté dans le noyau. Cependant, en cas de congestion du réseau ou d'erreurs, TCP peut ne pas envoyer les données directement. Lors du transfert de données d'un tampon du noyau vers l'application, la machine ne lit pas le flux d'octets de la machine distante. En fait, TCP est responsable de la mise en mémoire tampon des données pour l'application.

Le choix de la taille du tampon, pour la lecture et l'écriture de fichiers, ou l'envoi et la réception de fichiers, se fait au niveau de l'application. Le tampon est maintenu à l'aide d'une liste chaînée circulaire . Il se compose d'un ensemble de BufferNodes. Chaque BufferNode possède un DataField. Le DataField contient les données et un pointeur appelé NextBufferNode qui pointe vers le BufferNode suivant. Pour trouver la position actuelle, deux pointeurs sont utilisés : CurrentBufferNode et EndBufferNode, qui représentent la position dans le BufferNode pour les dernières positions d'écriture et de lecture. Si le BufferNode n'a pas d'espace libre, il enverra un signal d'attente au client pour attendre qu'il y ait de l'espace disponible.

De plus en plus d'utilisateurs possèdent plusieurs appareils avec une connectivité ad hoc. Les ensembles de données répliqués sur ces appareils doivent être synchronisés entre un nombre arbitraire de serveurs. Cela est utile pour les sauvegardes et également pour le fonctionnement hors ligne. En effet, lorsque les conditions du réseau de l'utilisateur ne sont pas bonnes, l'appareil de l'utilisateur réplique de manière sélective une partie des données qui seront modifiées ultérieurement et hors ligne. Une fois que les conditions du réseau deviennent bonnes, l'appareil est synchronisé. Il existe deux approches pour résoudre le problème de la synchronisation distribuée : la synchronisation peer-to-peer contrôlée par l'utilisateur et la synchronisation maître-réplique dans le cloud.

• peer-to-peer contrôlé par l'utilisateur : un logiciel tel que rsync doit être installé sur tous les ordinateurs des utilisateurs qui contiennent leurs données. Les fichiers sont synchronisés par synchronisation peer-to-peer où les utilisateurs doivent spécifier les adresses réseau et les paramètres de synchronisation, et il s'agit donc d'un processus manuel.
• Synchronisation maître-réplique cloud : largement utilisée par les services cloud, dans laquelle une réplique maître est maintenue dans le cloud, et toutes les mises à jour et opérations de synchronisation sont effectuées sur cette copie maître, offrant un niveau élevé de disponibilité et de fiabilité en cas de panne.

Dans le cloud computing, les concepts de sécurité les plus importants sont la confidentialité, l'intégrité et la disponibilité (« CIA »). La confidentialité devient indispensable pour empêcher la divulgation de données privées. L'intégrité garantit que les données ne sont pas corrompues.

La confidentialité signifie que les données et les tâches de calcul sont confidentielles : ni le fournisseur de cloud ni les autres clients ne peuvent accéder aux données du client. De nombreuses recherches ont été menées sur la confidentialité, car c'est l'un des points cruciaux qui présentent encore des défis pour le cloud computing. Le manque de confiance envers les fournisseurs de cloud est également un problème connexe. L'infrastructure du cloud doit garantir que les données des clients ne seront pas consultées par des parties non autorisées.

L'environnement devient instable si le fournisseur de services peut effectuer toutes les opérations suivantes :

• localiser les données du consommateur dans le cloud
• accéder et récupérer les données des consommateurs
• comprendre la signification des données (types de données, fonctionnalités et interfaces de l'application et format des données).

La localisation géographique des données permet de déterminer la confidentialité et la protection de la vie privée. La localisation des clients doit être prise en compte. Par exemple, les clients en Europe ne seront pas intéressés par l'utilisation de centres de données situés aux États-Unis, car cela affecte la garantie de confidentialité des données. Afin de faire face à ce problème, certains fournisseurs de cloud computing ont inclus la localisation géographique de l'hôte comme paramètre de l'accord de niveau de service conclu avec le client, permettant aux utilisateurs de choisir eux-mêmes l'emplacement des serveurs qui hébergeront leurs données.

Une autre approche de la confidentialité consiste à chiffrer les données. Dans le cas contraire, il existe un risque sérieux d'utilisation non autorisée. Il existe une variété de solutions, comme le chiffrement des données sensibles uniquement, et la prise en charge de certaines opérations seulement, afin de simplifier les calculs. De plus, des techniques et des outils cryptographiques tels que FHE sont utilisés pour préserver la confidentialité dans le cloud.

L'intégrité dans le cloud computing implique l'intégrité des données ainsi que l'intégrité informatique. Cette intégrité signifie que les données doivent être stockées correctement sur les serveurs cloud et, en cas de panne ou de calcul incorrect, que les problèmes doivent être détectés.

L'intégrité des données peut être affectée par des événements malveillants ou par des erreurs d'administration (par exemple lors de la sauvegarde et de la restauration, de la migration des données ou de la modification des adhésions aux systèmes P2P ).

L'intégrité est facile à obtenir en utilisant la cryptographie (généralement via un code d'authentification de message , ou MAC, sur des blocs de données).

Il existe des mécanismes de contrôle qui affectent l'intégrité des données. Par exemple :

• HAIL (High-Availability and Integrity Layer) est un système cryptographique distribué qui permet à un ensemble de serveurs de prouver à un client qu'un fichier stocké est intact et récupérable.
• La méthode Hach PORs (preuves de récupérabilité pour les fichiers volumineux) est basée sur un système cryptographique symétrique, où il n'y a qu'une seule clé de vérification qui doit être stockée dans un fichier pour améliorer son intégrité. Cette méthode permet de chiffrer un fichier F puis de générer une chaîne aléatoire nommée « sentinelle » qui doit être ajoutée à la fin du fichier chiffré. Le serveur ne peut pas localiser la sentinelle, qui est impossible à différencier des autres blocs, donc un petit changement indiquerait si le fichier a été modifié ou non.
• La vérification PDP (possession prouvable des données) est une classe de méthodes efficaces et pratiques qui fournissent un moyen efficace de vérifier l'intégrité des données sur des serveurs non fiables :
  • PDP : Avant de stocker les données sur un serveur, le client doit stocker, localement, certaines métadonnées. A un moment ultérieur, et sans télécharger les données, le client peut demander au serveur de vérifier que les données n'ont pas été falsifiées. Cette approche est utilisée pour les données statiques.
  • PDP évolutif : Cette approche repose sur une clé symétrique, qui est plus efficace que le chiffrement à clé publique. Elle prend en charge certaines opérations dynamiques (modification, suppression et ajout), mais elle ne peut pas être utilisée pour la vérification publique.
  • PDP dynamique : Cette approche étend le modèle PDP pour prendre en charge plusieurs opérations de mise à jour telles que l’ajout, l’insertion, la modification et la suppression, ce qui est bien adapté au calcul intensif.

La disponibilité est généralement assurée par la réplication . En même temps, la cohérence doit être garantie. Cependant, la cohérence et la disponibilité ne peuvent pas être obtenues en même temps ; chacune est prioritaire au détriment de l'autre. Il faut trouver un équilibre.

Les données doivent avoir une identité pour être accessibles. Par exemple, Skute est un mécanisme basé sur le stockage clé/valeur qui permet une allocation dynamique des données de manière efficace. Chaque serveur doit être identifié par une étiquette sous la forme continent-pays-centre de données-salle-rack-serveur. Le serveur peut référencer plusieurs nœuds virtuels, chaque nœud ayant une sélection de données (ou plusieurs partitions de plusieurs données). Chaque élément de données est identifié par un espace clé qui est généré par une fonction de hachage cryptographique unidirectionnelle (par exemple MD5 ) et est localisé par la valeur de la fonction de hachage de cette clé. L'espace clé peut être partitionné en plusieurs partitions, chaque partition faisant référence à un élément de données. Pour effectuer la réplication, les nœuds virtuels doivent être répliqués et référencés par d'autres serveurs. Pour maximiser la durabilité et la disponibilité des données, les répliques doivent être placées sur des serveurs différents et chaque serveur doit être dans un emplacement géographique différent, car la disponibilité des données augmente avec la diversité géographique. Le processus de réplication comprend une évaluation de la disponibilité de l'espace, qui doit être supérieure à un certain seuil minimum sur chaque serveur de bloc. Dans le cas contraire, les données sont répliquées sur un autre serveur de blocs. Chaque partition, i, a une valeur de disponibilité représentée par la formule suivante :

où sont les serveurs hébergeant les répliques, et sont la confiance des serveurs et (en fonction de facteurs techniques tels que les composants matériels et non techniques comme la situation économique et politique d'un pays) et la diversité est la distance géographique entre et .

La réplication est une excellente solution pour garantir la disponibilité des données, mais elle coûte trop cher en termes d'espace mémoire. DiskReduce est une version modifiée de HDFS qui repose sur la technologie RAID (RAID-5 et RAID-6) et permet l'encodage asynchrone des données répliquées. En effet, il existe un processus en arrière-plan qui recherche les données largement répliquées et supprime les copies supplémentaires après leur encodage. Une autre approche consiste à remplacer la réplication par un codage d'effacement. De plus, pour garantir la disponibilité des données, de nombreuses approches permettent la récupération des données. En fait, les données doivent être codées, et si elles sont perdues, elles peuvent être récupérées à partir de fragments qui ont été construits pendant la phase de codage. D'autres approches qui appliquent différents mécanismes pour garantir la disponibilité sont : le code Reed-Solomon de Microsoft Azure et RaidNode pour HDFS. Google travaille également toujours sur une nouvelle approche basée sur un mécanisme de codage d'effacement.

Il n’existe pas d’implémentation RAID pour le stockage en cloud.

L'économie du cloud computing connaît une croissance rapide. Le gouvernement américain a décidé d'y consacrer 40 % de son taux de croissance annuel composé (TCAC), qui devrait atteindre 7 milliards de dollars d'ici 2015.

De plus en plus d'entreprises ont recours au cloud computing pour gérer l'énorme quantité de données et pour surmonter le manque de capacité de stockage, et parce qu'il leur permet d'utiliser ces ressources en tant que service, garantissant ainsi que leurs besoins informatiques seront satisfaits sans avoir à investir dans l'infrastructure (modèle de paiement à l'utilisation).

Chaque fournisseur d'application doit payer périodiquement le coût de chaque serveur sur lequel sont stockées les répliques de données. Le coût d'un serveur est déterminé par la qualité du matériel, les capacités de stockage et les frais de traitement des requêtes et de communication. Le cloud computing permet aux fournisseurs d'adapter leurs services en fonction des demandes des clients.

Le modèle de paiement à l'utilisation a également allégé la charge des start-ups qui souhaitent bénéficier d'activités à forte intensité de calcul. Le cloud computing offre également une opportunité à de nombreux pays du tiers monde qui ne disposeraient pas autrement de telles ressources informatiques. Le cloud computing peut réduire les obstacles informatiques à l'innovation.

Malgré l’utilisation généralisée du cloud computing, le partage efficace de grands volumes de données dans un cloud non fiable reste un défi.