10 ans, le bel âge pour un lifting. Google (www.google.com | NASD:GOOG) a décidé de changer l'infrastructure de ses services et notamment celle de son stockage. Caffeine est le nom de code du projet qui couvre l'infrastructure de Search. Celle-ci doit s'appuyer sur la seconde génération de GFS - Google File System - utilisée en interne et propre à Google puisque celui-ci n'est pas disponible pour le monde extérieur quelque soit le mode et la version. Un très bon papier avait été publié par les Labs Google en 2003 à ce sujet et souvenez-vous, j'avais déjà couvert GFS en 2006 par un article assez détaillé. C'est aussi une technologie, les systèmes de fichiers distribués, que je couvre dans le tutorial SNIA Massively Scalable File Storage que je présenterai une nouvelle fois à la conférence SNW Europe fin Octobre à Francfort.
Lors de la genèse de GFS, Google a opté pour des choix apparaissant aujourd'hui stupide mais si on se remet dans le contexte, ces choix trouvent leur sens. Les objectifs de GFS étaient clairs, le besoin de faible latence n'était pas prioritaire mais que la volonté d'adresser les besoins de forte évolutivité, de forte abstraction matérielle et de disponibilité importante étaient au coeur du design. Malgré ces choix, GFS a largement contribué au succès de Google comme élément d'infrastructure supportant les applications maison au-delà des prévisions. Au départ, il a été désigné pour ne supporter que les applications de type batch comme le crawl web ou l'indexation, les applications Gmail et YouTube, développées ou acquises durant les 10 dernières années étant plus orientées temps-réel. GFS s'est montré moins "à l'aise" avec ce type de traitement même si le comportement d'une vidéo servi par YouTube est séquentiel en mode stream. GFS est une architecture à 3 niveaux avec le maître - master - dans le jargon Google, présent en un seul exemplaire, les serveurs secondaires - chunkservers - qui correspondent au serveurs de stockage contrôlés par le maître et répondent aux requêtes des clients, en nombre important. Une souche GFS est donc présente sur ces 3 composants de l'architecture pouvant à priori évoluer indépendemment, sauf le maître, unique. Le second choix fut l'éclatement des écritures avec un pas de 64Mo - le chunksize ou stripe unit - par chunkserver garantissant une bande passante importante, donc un débit global interessant, et une relative indépendance vis-à-vis du maître puisque moins de dialogue était nécessaire. Le but initial de GFS était de stocker les données du crawl web et de l'indexation donc en terme Google plutôt de gros fichiers mais pas adapté à Gmail par exemple. L'intégrité des données étant l'un des axes de design de GFS, le failover ou reprise de l'unique master était manuelle et pouvait engendre jusqu'à 1h d'arrêt réduit aujourd'hui à 10 secondes en mode automatique, ce qui est encore trop long car l'arrêt doit être invisible pour les applications et les utilisateurs. La performance de GFS est liée à la taille mémoire du master qui limite le nombre de fichiers traités pour les 3 types de Meta-Data qu'il stocke: nom de fichiers et chunk handle, correspondance fichiers vers chunks et donc chunkservers et l'adresse des réplicas des chunks. L'évolution de la volumétrie et du nombre de fichiers a été telle que les masters, sur des clusters différents, sont devenus des "trucs" énormes et fragiles. Le paradoxe est saisissant, pourquoi alors un seul master dans l'architecture qui représente un point de défaillance unique, que le bon sens ferait éviter à tout prix ? Ce seul master est aussi un goulot d'étranglement regroupant toutes les requêtes clients et contrôlant tous les serveurs secondaires. Les configurations Google ont évolué d'une cellule (= 1 GFS) par Data Center à plusieurs cellules (= n GFS) avec la possibilité d'asservir un chunkserver à plusieurs masters de GFS différents donc des espaces de stockage différents controlés par l'application ou par un jeu statique d'espace de nommage. GFSv2 introduit le concept de masters distribués, adressant immédiatement la disponibilité et la performance, avec un mode supportant des centaines de maîtres pouvant chacun supporter 100 millions de fichiers. Le boulot de synchronisation et de recouvrement doit être une sacrée galère... Le chunksize est de 64Mo avec GFS et de 1Mo avec la version 2. Comme indiqué ci-dessus, cette valeur correspond à la quantité de données ou segment d'un fichier affecté à 1 serveur de donné (chunkserver). Il demeure incroyable que Google ait pensé et décidé très tôt de partir sur un tel design avec un seul master tellement la lacune est énorme. Cette décision a quand même eu quelques impacts avec plusieurs arrêts de Gmail dont certains sont imputés à GFS et de son unique master. Il fallait réagir. On remarquera que Google aurait pu retenir Hadoop et contribuer à son évolution, mais cela aurait pu être le symbole d'une défaite technologique. Par contre, Il est incroyable que Microsoft centré sur la guerre des moteurs de recherche se ralit à l'Open Source avec Bing qui s'appuit sur Hadoop suite au rachat de PowerSet. Je couvrirai Hadoop dans les prochains jours.
En résumé:
- GFS (1 master en mode failover, chunksize = 64Mo, philosophie: bande passante et intégrité de données)
- GFSv2 (N masters distribués en disponibilité constante, chunksize = 1Mo, philosophie: plus temps-réel, plus réactif, totale intégrité de données et maintien des avantages de la v1)
0 commentaires:
Post a Comment