The Google File System

Note de dernière minute

Cela fait maintenant plusieurs mois que cet article est prêt.
A l'origine, ce billet devait être accompagné de 6 autres articles, qui faute de temps, ne verrons pas le jour.
C'est qu'il est assez ardu de résumer mes découvertes tellement les surprises et points d'intérêts sont abondants.
Il n'en reste pas moins que la lecture de "Google File System" fut un bon et grand moment. Rentrer et inspecter l'antre du monstre fut en soit une riche expérience.
Si les informations techniques ne vous rebutent pas de trop, plongez y la tête baissée.

L'article...

J'ai récemment terminé la lecture de l'article "The Google File System" (GFS pour les intimes) publié par Google.
Ce dernier traitait du système de fichier mis en place par Google pour répondre à ses besoins de stockages que l'on sait gigantesque.
Bien évidemment, on n'imagine pas Google maintenir tout ses indexes et ses fichiers sur un seul et gros serveur bourré à craquer de disques.
Google utilise un système de fichier distribué constitués de serveurs montés en grappes (cela s'appelle un cluster).
Plutôt que d'opter pour une solution clé en main, Google a étudié les solutions disponibles et ses propres besoins (en accès lecture/écriture) afin de construire un système de fichiers distribués optimisé pour ses activités. Ce système de fichier porte le charmant nom de Google File System (GFS).

Plusieurs éléments m'ont interpelé durant la lecture de cet article.
En premier, il y a réplication intelligente des données.
Mais sans conteste, l'élément le plus marquant était le principe de base de GFS, à savoir que "tout est faillible". Le réseau, les machines, les disques, les systèmes d'exploitations et les logiciels sont susceptibles de connaître des problèmes et qu'immanquablement ces éléments défaillirons.
GFS a donc été conçu avec cette idée qu'il doit résister seul (ou presque) à toutes les défaillances.
Ainsi, selon son principe du "ca va quand même foirer" :

• Si un disque croit avoir correctement écrit une information, le GFS ne prend pas cela pour un acquis et écrit également une clé de vérification (checksum).
• Si le noeud master du système de fichier (contenant la liste des fichiers et leur localisation dans le cluster) crash et ne réponds plus, un autre master sera redémarré endéans la seconde sur la même machine (ou une machine redondante).
• Les noeuds du cluster ou les disques peuvent à tout moment disparaître, devenir défaillants ou réapparaître... et GFS n'en est pas perturbé le moins du monde. Mieux encore, le Master programmera même les tâches de maintenances nécessaires à la restauration des données.
• Si une partie du réseau tombe, ce n’est pas grave, le câblage est redondant. Mais si cela ne permet toujours pas d’accéder aux données, le Master ira extraire les informations depuis un réplica distant.
• Même les API utilisés dans les programmes accédant aux fichiers de GFS partent du principe que l’appel échouera et qu’il faudra réessayer (ce qui présente un avantage décisif durant l’exploitation de GFS).
  

GFS pousse ce principe de tolérance à la défaillance tellement loin que le redémarrage d'un cluster entier (+/- 180 Tb) s'effectue simplement en tuant les processus du master (kill process).

En concevant son système de fichier, Google voulait obtenir un système fiable, rapide, évolutif et autonome. Ces dix dernières années leur donne raison.