Google File System

Google File System

Google File System (GFS) est un système de fichiers distribué propriétaire. Il est développé par Google pour leurs propres applications. Il ne paraît pas être publiquement disponible et il est construit sur du code GPL (ext3 et Linux).

Sommaire

Conception

GFS a été conçu pour répondre aux besoins de stockage de données des applications Google, notamment pour tout ce qui concerne ses activités de recherche sur le Web. Ce système de fichiers est né d'un premier projet initié chez Google, "BigFiles", alors que la firme était encore basée à Stanford.

Il est optimisé pour la gestion de fichiers de taille importante (jusqu'à plusieurs giga-octets), et pour les opérations courantes des applications Google : les fichiers sont très rarement supprimés ou réécrits, la plupart des accès portent sur de larges zones et consistent surtout en des lectures, ou des ajouts en fin de fichier (record append); GFS a donc été conçu pour accélérer le traitement de ces opérations. Il a aussi été optimisé pour fonctionner sur les clusters de Google, composés d'un très grand nombre de machines "standard"; des précautions particulières ont donc été prises pour prévenir les pertes de données dues aux fréquentes pannes pouvant se produire avec ce type de matériel. Du fait de la très grande taille des fichiers, ces derniers sont découpés en blocs stockés sur différentes machines.

Fichiers

Les fichiers étant de très grande taille, ils sont découpés en blocs de 64 Mo nommés chunks. Chaque bloc possède un identifiant unique de 64 bits, ainsi qu'un numéro de version, afin de détecter les incohérences de données (par exemple, lorsqu'un chunkserver a manqué des modifications effectuées sur un fichier tandis qu'il était hors-ligne). Un fichier est répliqué en plusieurs exemplaires dans le système, ainsi, si une copie disparait (à cause d'une panne du serveur qui le stocke), le fichier reste généralement accessible. Le nombre moyen de copies d'un fichier est de 3, mais il peut exister beaucoup plus de copies pour les fichiers fréquemment accédés, comme les exécutables. Les différentes copies sont bien sûr stockées sur des nœuds différents.

Chunk

La taille d'un chunk est habituellement de 64 Mo, mais cette taille peut être modifiée dans certains cas. Au niveau d'un chunkserver, chaque chunk est encore découpé en blocs de 64 Ko, possédant chacun une somme de contrôle. Ainsi, avant d'envoyer les données relatives à ce bloc, le serveur recalcule cette somme de contrôle et la compare à la valeur stockée, afin de détecter d'éventuelles altérations de données. Un chunk est stocké sous la forme d'un simple fichier Linux.

Nœuds

Les nœuds du système sont de deux types différents: le Master et les Chunkservers :

Master

Chaque cluster possède un master. Il ne stocke pas les fichiers directement, mais gère toutes les métadonnées : les informations du namespace, et surtout la correspondance entre chaque fichier et les chunks qui le composent, ainsi que les nœuds stockant ces chunks. Il est chargé de vérifier l'intégrité des données stockées, et c'est lui qui donne les autorisations d'écriture sur les fichiers. Enfin, il est chargé de déterminer le placement des blocs dans le système, pour équilibrer la charge du réseau, et garantir que chaque bloc possède un nombre suffisant de copies. Il communique régulièrement avec les chunkservers par l'intermédiaire de signaux heartbeat, lui permettant de connaître l'état et le nombre des copies.

Le master étant le point sensible du système, il possède toujours un miroir, constamment tenu à jour et capable de le remplacer en cas de problème. Le master a été conçu pour interagir au minimum avec les clients du système de fichiers : étant un composant central, il faut éviter qu'il ne devienne un goulet d'étranglement.

Chunkservers

La plus grande partie des nœuds sont de ce type. Leur tâche est de stocker les chunks, et d'effectuer les accès en lecture et en écriture. Pour les opérations d'écriture, l'un des serveurs stockant le bloc concerné est désigné comme copie primaire; il effectue l'opération d'écriture, puis donne l'ordre aux copies secondaires d'effectuer la même opération. Ce système garantit que les opérations d'écriture soient réalisées dans le même ordre sur toutes les répliques, tout en minimisant les interactions avec le master.

Opérations

Lecture

Pour effectuer une lecture, un client commence par demander au master l'adresse des machines possédant une copie du chunk qui l'intéresse. Si aucune opération d'écriture n'est en cours sur la zone concernée, le master renvoie la liste de ces machines. Le client s'adresse ensuite directement à l'un des chunkservers qui lui envoie les données désirées.

Ecriture

Pour les opérations d'écriture, GFS utilise un système de bail : il choisit l'une des chunkservers, possédant une copie du bloc, et lui accorde pour une durée limitée le droit d'effectuer des écritures. Ce serveur est alors appelé primaire. Le master envoie ensuite au client l'adresse du primaire et des copies secondaires. Le client peut alors envoyer les données aux différents serveurs, puis demander à effectuer son opération d'écriture. Toutes les erreurs se produisant au cours de cette opération sont gérées par le client, afin d'alléger le travail du master.

Mise à jour des sommes de contrôle

Lors d'une écriture, les clients doivent mettre à jour la somme de contrôle des blocs (64 Ko) concernés. Le mode de calcul de cette somme a été optimisé pour les opérations d'ajout en fin de fichier : il est possible d'incrémenter la somme de contrôle du dernier bloc encore partiellement rempli, sans avoir à le recalculer intégralement. En revanche, pour réécrire une zone d'un fichier, il est nécessaire de vérifier la somme de contrôle avant l'opération, puis de la recalculer après avoir effectué l'écriture: si on ne vérifie pas la somme avant, il est possible que le bloc contienne des erreurs qui ne seront plus détectables après l'opération, et le bloc sera considéré comme valide alors qu'il ne l'est pas.

Flux de données

Lors d'une écriture, les données sont transmises à la façon d'un pipeline : le client envoie les données à écrire au primaire, accompagné de la liste des autres copies. Le primaire tente de trouver dans la liste la machine la plus proche de lui (les adresses IP sont distribuées de telle façon qu'elles peuvent être utilisées pour évaluer la distance entre deux machines), et lui envoie les données avec la liste des machines ne les ayant pas encore reçues. Ainsi, de proche en proche, toutes les répliques reçoivent les données. Le réseau étant en mode full-duplex, un serveur peut transmettre les données dès qu'il commence à les recevoir. Ce système permet de grouper les flux de données, et ne demande au client d'envoyer les données qu'une seule fois.

Sources


Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Google File System de Wikipédia en français (auteurs)

Игры ⚽ Нужна курсовая?

Regardez d'autres dictionnaires:

  • Google File System — (GFS) is a proprietary distributed file system developed by Google for its own use. Despite having published details on technologies like the Google File System, Google has not released the software as open source and shows little interest in… …   Wikipedia

  • Google File System — (GFS)  распределенная файловая система, используемая компанией Google. Является коммерческой тайной компании Google. Несовместима с POSIX и создавалась Google для своих внутренних потребностей. GFS  кластерная система, оптимизированная… …   Википедия

  • Google File System — Das Google File System (GFS) ist ein proprietäres, auf Linux basierendes verteiltes Dateisystem, das Google für seine Anwendungen benutzt. Es ist für Googles Internetsuche optimiert. Die Daten sind bleibend in teilweise mehrere Gigabyte großen… …   Deutsch Wikipedia

  • File system — For library and office filing systems, see Library classification. Further information: Filing cabinet A file system (or filesystem) is a means to organize data expected to be retained after a program terminates by providing procedures to store,… …   Wikipedia

  • Lustre (file system) — Infobox software name = Lustre developer = Sun Microsystems latest release version = 1.6.5.1 latest release date = release date|2008|07|10 operating system = Linux genre = Shared disk file system license = GPL website = http://www.lustre.org,… …   Wikipedia

  • Coda (file system) — Coda Developer Carnegie Mellon University Introduced 1987 Features Supported operating systems Linux, NetBSD FreeBSD Coda is a distributed file system developed as a research project at Carnegie Mellon University since 19 …   Wikipedia

  • Veritas File System — For other uses, see Veritas (disambiguation). VERITAS File System Full name VERITAS File System Introduced 1991 Structures Directory contents extensible hash Limits Max file size 8 EB ( …   Wikipedia

  • Be File System — BFS Developer Be Inc. Full name Be File System Introduced May 10, 1997 (BeOS Advanced Access Preview Release[1]) Partition identifier Be BFS (Apple Partition Map) 0xEB (MBR) …   Wikipedia

  • MINIX file system — Developer Open Source Community Full name MINIX file system version 3 Introduced 1987 (MINIX 1.0) Partition identifier 0x81 (MBR) Features Dates recorded …   Wikipedia

  • NetWare File System — NWFS Developer Novell Full name NetWare File System Limits Max file size 4 GiB Max volume size 1 TiB Features …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”