ITPT

29 nov. 2006

1Vision, un outil pas cher et trés pratique

Colorado Software Architects (www.cosoa.com) est un petit éditeur de logiciels de gestion de stockage et prestataire de services associés. Ses solutions sont commercialisées par 1Vision Software (www.1vision.com). Parmi les produits disponibles citons vSERV et vNAS, 2 outils d'agrégation de serveurs Windows dédiés ou non au service de fichiers.

vSERV est une couche d'agrégation de systèmes de fichiers qui offre une vue unique et globale de tous les espaces de stockage élémentaires composants cet agrégat. Ces systèmes de fichiers mis en jeu dans vSERV sont issus de serveurs de fichiers NAS Windows ou de simples serveurs Windows sans que ces derniers soient dédiés à une activité de services fichiers. L'accés utilisateur se fait par un répertoire parent depuis lequel tous les sous-répertoires réels des systèmes de fichiers existants sont accessibles. vSERV permet d'unifier le comportement des serveurs d'origine en conservant la spécificité de chacun comme les régles de sécurité et de lever les limites physiques de chaque serveur.

1Vision a developpé une couche overlay - Persistent File System (PFS) - sur NTFS, installée sur chaque serveur qui permet de constituer un shared namespace c'est-à-dire un espace de fichiers privé à ces seuls serveurs au sein d'un même domaine Windows. PFS a été depuis sa première version installé à plus de 2 millions d'exemplaires ce qui en fait une technologie éprouvée et a fait l'objet de 3 brevets: le premier sur le backup, le second concernant le "catalogage" et le dernier l'agrégation.

Aucun agent n'est nécessaire sur les clients, l'ensemble de la logique étant embarquée sur chaque serveur échangeant entre eux des données et notamment l'ensemble des meta-data répliqués entre tous les membres. La configuration repose essentiellement sur la définition d'un Aggregation Group (AG) défini par son nom, le share associé et le taux de remplissage en pourcentage - global à l'AG - pilotant le déplacement de fichiers entre les serveurs dans le cas où le taux d'occupation est atteint. Chaque système équipé de vSERV voit l'apparition d'une unité logique locale - V: - qui donne la même vision globale de l'agrégation des systèmes de fichiers mais en accès sur les serveurs composants l'ensemble. Ainsi chaque V: de serveur offre la même vue qui demeure identique pour l'utilisateur au travers du share global. Il peut être intéressant pour des raisons de performance de configurer un réseau dédié à la communication entre serveurs vSERV.

Parmi les gains notoires pour l'administrateur, remarquons l'évolutivité assez transparente, une configuration relativement simple, une administation centralisée, un partage de ressources augmentant les taux d'utilisation et un ROI rapide. Pour l'utilisateur, l'accès par un répertoire maître permet d'homogénéiser les comportements et de couvrir tous les espaces de fichiers, de conserver un accès constant aux données et de maintenir les privilèges Windows. La protection d'un tel environnement est réalisé soit en sauvegardant chaque membre de l'agrégation ou en soumettant V: à l'outil de sauvegarde.

vNAS, le petit frère de vSERV, est lui limité aux serveurs de fichiers Windows de type NAS donc basé sur SAK et ses petits fréres mais fonctionne exactement dans le même esprit.

Encore une petite solution bien pratique pour les environnements pures Windows, trés abordable et apportant un vrai service pour les utilisateurs et les administrateurs. Comment se fait-il qu'une société comme Microsoft n'est rien sur ce plan ? à part DFS mais c'est un peu complexe pour les petites/moyennes configurations. Allez Mr Ozzie, vous nous faites un petit outil sympa, pratique et pas cher...

26 nov. 2006

Entretien avec Arun Taneja

Arun Taneja, Analyste et Fondateur du Taneja Group, était la semaine dernière de passage à Paris pour profiter de Storage-Expo entre la conférence EMEA Partenaires et Utilisateurs FalconStor à Venise et la suite de la Brocade Conférence en Europe. Nous avons pu échanger sur le marché, notamment le FAN - File Area Network. Arun a insisté sur la nécessité de consacrer du temps à l'éducation du marché pour le FAN d'autant plus que le concept est récent et uniquement couvert par 5 acteurs pas tous trés connus: Acopia Networks, Attune Systems, Brocade Communications, EMC Rainfinity et Neopath Networks.

Il ajoute que le second élément d’adoption par le marché passera par la considération du FAN comme une infrastructure fondamentale capable de recevoir une suite de services, tous non disponible à ce jour, mais qui à terme servira de réceptacle pour toute l’activité d’accès et de contrôle de l’activité fichier dans l’entreprise.

Arun a même avoué connaître la réponse concernant le non achat par Brocade de Tacit Networks et de l'avoir laissé passer chez Packeteer pour un montant relativement faible, en tout cas faisable pour Brocade, concentré sur son projet prioritaire McData. La gamme Tapestry, fantastique de part ses fonctionnalités et résultats chez les clients, reste aujourd'hui issue de NuView pour son offre FAN StorageX, extraodinaire pour le monde Windows et de l'accord oem Packeteer pour le WAFS. Est-ce à dire que Brocade nous réserve une surprise quelque mois après la digestion de McData, et ainsi compléter davantage son portefeuille produit dans le domaine IP et ainsi assoir sa stratégie FAN ? L’histoire nous le dira car le FAN est aujourd’hui un des axes d’innovation et de besoins clients très présent et promis à un bel avenir.

En terme de dynamique de marché, on constate que les acteurs issus du monde IP cherchent à compléter leur gamme d’optimisation réseau par l’ajout de l’optimisation applicative voire de fichiers, c’est le cas de Cisco, F5 Networks, Juniper ou Packeteer, et que ceux qui couvrent le WAFS tentent d’ajouter un comportement applicatif plus complet comme Brocade ou Riverbed ou à terme devenir un acteur IP à part entière, pourquoi pas, ces sociétés possèdent une vraie expertise de routage et de commutation. Pour mémoire, Riverbed vaut aujourd'hui plus de 2Mds$ en bourse.

Pour terminer, Arun Taneja envisage clairement, dés les premiers signes d’un décollage fort de l’activité FAN, l’acquisition des autres trois acteurs – Acopia Networks, Attune Systems et Neopath Networks – par les grands fournisseurs de l’industrie absent du segment comme IBM, HP ou SUN sans réelle offre propre. La bataille s’annonce intéressante et positive d’un point de vue client l’aidant à faire le tri entre les offres établies, éprouvées ou prometteuses.

23 nov. 2006

BlueArc/HDS, ça se rapproche...

En effet BlueArc devrait faire son apparition au catalogue d'HDS. Dans les prochains jours, HDS et BlueArc devraient révéler un accord permettant à HDS de distribuer ce qui est considéré comme le haut de gamme des serveurs de fichiers, secteur où sont présents les Isilon, NetApp GX et ancien Spinnaker Networks, CrossWalk, Ibrix, Panasas, Rackable avec la gamme issu de TerraScale ou Exanet, souvent présents dans des secteurs verticaux. Peu présent dans l'hexagone, BlueArc devrait au même titre qu'Archivas pour les plateformes d'archivage CAS*, bénéficiait du trés large et efficace réseau de distribution du géant japonais.

* CAS: Content Addressable|Aware Storage

19 nov. 2006

La nouvelle donne du Stockage orienté Fichier

Une décennie après l’arrivée du SAN, voilà que se profile une nouvelle ère, celle du Fichier ou plutôt du Réseau de Fichiers. De plus en plus important car critique pour l’entreprise, les données non-structurées, à priori les plus simples à créer, partager et échanger, progressent de plus de 80% par an et cristallisent aujourd’hui un vrai besoin chez les utilisateurs. Plusieurs analystes évoquent même comme priorité numéro 1 - 62% des réponses pour l'étude du Taneja Group pour en citer une - les projets de gestion de fichiers au sein des entreprises, focalisant ainsi une bonne partie des budgets des prochains trimestres. Les objectifs historiques du SAN se retrouvent ici avec l’idée de mutualiser et de consolider les espaces de stockage et de permettre une relation complète entre les utilisateurs et les unités de stockage hébergeant leurs données. Et comme par magie, l’industrie fête aussi les vingt ans du protocole NFS, créé par Sun Microsystems, tout ça pour arriver à l’unification de ces technologies pour en génèrer une troisième : la virtualisation de fichier. En fait, on le constate et le vit tous les jours, la simplicité de NFS et depuis quelques temps des services de fichiers NAS ont révolutionné les centres de données en offrant une très grande facilité d’installation, de gestion et d’accès pour les utilisateurs. Malgré tout, un vrai paradoxe est né car le phénomène a dépassé l’espérance. En effet, l’omniprésence et la multiplication de ces serveurs a engendré une complexité grandissante, gérer plus de 5 serveurs de fichiers, dédiés ou non, à fortiori s’ils sont de marques différentes devient de plus en plus délicat, difficile et soumis à une forte pression quant au service délivré. Néanmoins l’existant est là et doit continuer à satisfaire les utilisateurs dans la période d’investissement voulue. Ces derniers souhaitent un accès permanent et les administrateurs une capacité de gestion puissante mais surtout transparente pour les consommateurs de ces espaces de stockage. De ces besoins exprimés sont nées plusieurs tentatives, parmi lesquelles le Network File Management (NFM) ou le Network File Virtualization (NFV) poussés par plusieurs vendeurs.

De quoi s’agit-il ? L’idée est la Virtualisation de Fichiers ou du Service de Fichiers pour s’affranchir des limites des systèmes de fichiers et des serveurs de fichiers existants et lever les quelques dernières obstructions à une adoption massive pour tout secteur et toute application. Tout comme son grand frère, la virtualisation mode bloc, celle orientée fichier s’efforce de masquer la complexité du stockage, de fournir une couche d’abstraction entre les clients « consommateurs » et les serveurs « producteurs » quant à la localisation des fichiers et des services associés. Ainsi les actions de gestion ou de production deviennent transparentes pour l’utilisateur, la relation rigide entre un fichier et sa résidence, le serveur et l’utilisateur, est « cassée ». Autrement dit, un fichier devient accessible par plusieurs chemins c’est-à-dire plusieurs serveurs sans que l’utilisateur ne s’en préoccupe et s’en aperçoive, l’essentiel est l’accès au fichier.

Ainsi est né le FAN – File Area Network – véritable sésame du stockage fichier aujourd’hui, qui est devenu le point d’ancrage et de convergence de l’industrie. Le FAN est le résultat de l’abstraction de la localisation et l’appartenance des fichiers aux serveurs de son nommage. Ainsi la visibilité extérieure du nommage du fichier donnée à l’utilisateur est différente de la réalité tout en conservant le contenu intact. Cette nouvelle tendance forte sur le marché se matérialise par l’ajout d’un composant, logiciel ou matériel, essentiel à la constitution d’un tel « réseau de fichiers », qui crée un espace global de nommage des fichiers (global namespace) issu de tous les serveurs présents dans l’environnement et participants à cette logique. Une « super » arborescence est établie, pour simplifier ici notre propos, agrégeant l’ensemble des espaces de stockage sous-jacents, on comprend alors aisément la facilité de navigation offerte à l’utilisateur par une telle approche. L’image ci-après illustre la visibilité offerte à l’utilisateur et l’agrégation complète des environnements fichiers.

La promesse du FAN, en conséquence, est de régler les soucis et problèmes de gestion des environnements fichiers surtout quand ceux-ci deviennent importants par le nombre de serveurs, souvent de marques et modèle différents, critiques quant à leur rôle dans le système d’information et également quand le réseau propose des déclinaisons très variées de systèmes de fichiers, quelque soit leur type : San, Cluster, Globaux, Distribués, Segmentés ou Parallèles, trouvant tous, une vocation à servir des fichiers pour le monde extérieur avec chacun des propriétés différentes et propres. L’existence même de toutes ces solutions au sein d’un réseau justifie l’adoption d’un FAN permettant de s’affranchir de vraies difficultés de gestion en offrant une interface simple et unifiée d’administration et surtout en permettant d’offrir des services additionnels, transparents pour les utilisateurs, comme la migration et la réplication de fichiers, la hiérarchisation de serveurs de fichiers, appelé aussi FLM pour File Lifecycle Management, l’équilibrage de charge entre serveurs, la protection de données ou tout simplement la consolidation logique d’espaces physiques.

Seuls cinq acteurs se distinguent sur le marché du FAN:
  • Brocade, trés actif avec StorageX depuis l'acquisition début 2006 de NuView, seule offre logicielle et out-of-band du marché,
  • Acopia Networks avec la famille ARX,
  • Attune Systems, issu de Z-Force, avec son Maestro File Manager,
  • Neopath Networks et son File Director, ces trois derniers étant positionnés in-band
  • et le dernier de philosophie hybride out-band/in-band est l’offre Rainfinity Global File Virtualization d’EMC acquise mi-2005.
Toutes ces approches sont issues de startups et pour deux d’entre elles aujourd’hui intégrées au sein de sociétés matures et établies sur le marché. A croire que les gros acteurs ne devancent plus les demandes utilisateurs et font appel à de petites sociétés innovantes, prometteuses et surtout anticipatrices pour se renforcer par accords OEMs ou absorption pure et simple. Elles servent donc de laboratoire d’incubation des « bonnes nouvelles idées ». J’ose parier que les trois autres acteurs mentionnés seront d’ici 18 mois sous la coupe de vendeurs importants du secteur.

Revenons au détail des offres FAN, dans le monde in-band, un frontal est généralement placé « devant » les serveurs de fichiers et ainsi devient le passage obligé de toutes les requêtes les aiguillant vers le bon serveur. En cas de défaillance de ce frontal, il est toujours possible d’accéder au serveur directement puisqu’il n’y a pas de conversion ou de modification des informations sur l’unité de stockage. Dans le cas de l’out-band, un serveur particulier dit serveur de noms, non placé dans le chemin de données, constitue l’agrégation des serveurs de fichiers et fonctionne en dialogue avec les clients afin que ces derniers puissent accéder à la bonne ressource sans passer dans ce fameux serveur de noms. Cette approche est assez assimilable au serveur DNS indispensable au fonctionnement d’Internet.

En terme de système de fichiers, plusieurs approches se côtoient et peuvent exister au sein d’un FAN : les systèmes de fichiers en cluster (cluster file system), les SAN File System (systèmes de partage de fichiers sur un SAN), les systèmes de fichiers distribués, globaux et parallèles et autre WAFS (Wide Area File Services) en omettant volontairement l’existence d’instances unique de systèmes de fichiers c’est-à-dire de serveurs NAS isolés, appelés non-shared namespace dans l’image ci-dessus. Ces trois familles offrent toutes un espace de nommage partagé mais privé dont limité aux seuls serveurs mis en jeu dans cette configuration, le schéma nomme cette catégorie shared-namespace. Cette agrégation est réalisée de manière différente mais permet d’accéder et parcourir les arborescences de fichiers et systèmes de fichiers sans rupture ou saut entre les espaces de stockage sous-jacents.

Le monde du stockage bouge et cet axe de Stockage orienté Fichier est certainement un des plus attractifs du moment en terme de compétition vue les approches variées adoptées par les fournisseurs qui se concrétisent toutes par des succès commerciaux quotidiens. Il n’existe pas néanmoins de format universel mais les protocoles NFS et CIFS permettent de tirer parti de toutes les infrastructures de services fichiers mis en place. Le FAN promet donc de révolutionner l’administration et l’utilisation du monde fichier, sans alourdir la facture et les coûts associés. Encore une fois, l’utilisateur avait adopté une technologie de façon massive – le NAS pour simplifier –, les industriels n’avaient pas anticipé ce boom mais leur réaction, avec le FAN, répond aux conséquences de cette forte adoption garantissant une nouvelle fois la pérennité des investissements.

16 nov. 2006

l'IPO d'Isilon est proche

Isilon vient de remettre à la SEC un nouveau document S1 indiquant une introduction proche au Nasdaq, je pencherai pour la première quinzaine de Décembre, préparez vos dollars, le titre devrait grimper en flèche comme Riverbed.

15 nov. 2006

Le petit dernier du FAN s'active

Attune Systems (www.attunesystems.com), l'un des 5 acteurs FAN du marché avec Acopia Networks, Brocade Communications, NeoPath Networks et EMC Rainfinity, et grand absent de SNW récemment vient de lever 14M$. De philosophie in-band, Maestro File Manager repose sur un appliance Windows renforçant sa capacité à opérer dans des environnements CIFS. Aujourd'hui, cette approche semble limitée par rapport aux offres concurrentes et la levée de fonds devrait permettre de nouveaux développements, on le souhaite car Z-Force, l'entité d'origine d'Attune, avait un produit étonnant et innovant que l'on ne retrouve pas encore dans Maestro. A noter que l'on retrouve au board, Larry Boucher, fondateur d'Alacritech, Auspex et Adaptec, ce qui laisse présager du sérieux de la chose.

9 nov. 2006

Le File Storage à SNW, confirmations et nouveautés

Une semaine aprés SNW, dressons rapidement le bilan de la conférence côté File Storage, qui constitue un axe industriel réel de convergence technologique. Tout d'abord, l'offre de serveurs de fichiers était large et toujours aussi présente avec quasiment toute l'armada du secteur, acteurs établis et émergents, comme Agami, Apple, BlueArc, CrossWalk, EMC, Exanet, Ibrix, Isilon, NetApp, ONstor, Pillar Data, PolyServe, Quantum, Sanbolic, SGI, et SnapAppliance et quelques nouveaux comme Verari Systems et puis tout ceux se réclamant du FAN avec Acopia Networks, Brocade Communications, NeoPath Networks sauf Attune Systems absent et Rainfinity, à peine mentionné par EMC.

La grande majorité des acteurs présents de serveurs de fichiers ciblent des sujets verticaux comme par exemple le calcul scientifique (HPC), l'Oil & Gas ou le "multimédia" au sens large avec le streaming, le rendering... pour justifier d'une architecure innovante et performante. J'en veux pour preuve Isilon qui martèle son architecture cluster avec répartition (stripe) des données entre plusieurs serveurs de stockage tous actifs, redondants, et visibles des clients NAS ou des acteurs comme CrossWalk ou Ibrix. Un des avantages de toutes ces solutions est le maintien du protocole NAS - NFS et/ou CIFS - donc la non-modification des clients et la transparence des déploiements. Toute la nouveauté apportait par ces nouvelles offres, pas toutes nouvelles quand même, est rendue disponible à l'utilisateur sans rupture et le différentiateur prix ou performance, brut ou relatif, est important qu'il soit fourni sur un matériel le plus standard possible tantôt en offre logicielle seule ou matériel-logiciel couplé.

La tendance du stockage orienté fichier de plus en plus universel s'est confirmée par l'affichage du concept de FAN (File Area Network) qui aujourd'hui fait foi sur le marché. Ainsi les quelques acteurs qui ont tous introduits par le passé leur acronyme - Network File Management, Network File Virtualization - sont donc passés au FAN en appuyant leur différence. Certains supportent le WAFS, d'autres se limitent à la simple agrégation de serveurs de fichiers - génériques ou dédiés -, et les instances produits sont en offre pure soft ou appliance, dans une philosophie in-band ou out-of-band.

La beauté de toutes ces offres reste une formidable adhérence aux configurations NAS établies sans rupture technologique coûteuse. Le passage à de telles solutions est aujourd'hui justifié par la volonté de consolider les filers existants, d'apporter un niveau de service plus fin et de meilleur qualité, de fournir une richesse fonctionnelle supérieure comme le FLM - File Lifecycle Management - et donc d'épouser au mieux les exigences techniques et budgétaires de l'entreprise sans révolutionner le parc installé. Foncez vers le FAN, c'est simple, souple et économique alors n'hésitez plus...

7 nov. 2006

Sanbolic ferait bien chez Microsoft

Sanbolic (www.sanbolic.com), éditeur de solutions de stockage pour Windows, assimilable à un petit VERITAS Software historique car détenteur d'un vrai savoir-faire côté Système de Fichiers et Gestion de Volumes disques, se verrait bien chez Microsoft notamment pour enrichir Windows Computer Cluster Server.

MelioFS, LaScala et LaScala Disto sont de vrais bons produits assez uniques et natifs sous Windows. LaScala est le gestionnaire de volumes, la partie Disto offre sa gestion distante et MelioFS est le système de fichiers clustérisé maison qui permet de batir de vraies architectures de partage de données. Il supporte plusieurs éléments clés d'un environnement Windows: DFS, Active Directory, ACL, MPIO, iSCSI initiator et les verrous Microsoft le plus possible compatibles avec NFS et CIFS. La dernière nouveauté de Sanbolic, surfant sur la vague ILM (si, il existe une vraie vague) est une mouture assez simple d'une gestion du cycle de vie de données (SILM) couplable notamment à MelioFS.

Momchil Michailovic, co-Fondateur de Sanbolic, me confiait lors de SNW la semaine dernière, qu'il aimerait bien céder sa société, on peut le comprendre quand on voit le deal EMC/Avamar pour 165M$, celui de LSI Logic/StoreAge pour 55M$ et d'autres qui arrivent trés vite, soyez à l'écoute, ça va bouger. Nelson Nahum, CTO et co-Fondateur de StoreAge, était lui aussi aux anges, sans stress, et se baladait vraiment détentu entre les stands... Bravo les gars.

1 nov. 2006

Encore un truc sympa chez Google...

Au moment où Google est considéré comme le grand Innovateur de l'Informatique d'aujourd'hui seul capable de révolutionner notre quotidien malgré aussi la tentation d'incarner Big Brother, il est intéressant de couvrir un service non visible de l'extérieur mais utilisé au quotidien par tous, son Système de Fichiers le Google File System ou GoogleFS (GFS).

Ce dernier est parti d'un constat simple: il n'existe rien sur le marché qui offre et répond aux attentes et besoins de Google. Il fallait donc développer un truc sur mesure pour les besoins internes transparent, suffisament souple et customizable mais d'une trés grande performance et résilience. Cette fois-ci, ce développement n'est pas destiné à une quelconque commercialisation, directe ou indirecte. A regarder de plus près, les exigences de Google sont incroyables: agréger des milliers de machines, gérer plusieurs Po de stockage, utiliser des machines les plus courantes et standards possibles d'où la nécessité d'augmenter la résistance à la panne de cet environnement, permettre un débit important en lecture et écriture et offrir une capacité de traitement "évolutive", tout ça pour un prix élémentaire du Go/s trés faible. L'avantage certain de Google est de posséder l'ensemble des élements c'est-à-dire de maîtriser parfaitement les applications, ce sont les leurs, et l'OS, l'ouverture de Linux est là pour ça.

Le résultat est là, ça marche sinon on le saurait et on s'en rendrait vite compte. Aujourd'hui, il existe plus de 50 clusters GFS sur la planète, chaque GFS est constitué de plus de 1000 machines serveurs pour une surface disque supérieure au Po, connectées à des pools de 1000 clients, permettant un débit en lecture écriture de plus de 10Go/s en présence de pannes matérielles.

L'esprit est donc de partir de système le plus standard possible et le moins cher et de coupler un grand nombre de machines entre elles pour délivrer le niveau de performance et de disponibilité souhaité, de toutes les façons le plus petit défi de Google ne peut être, dans un temps raisonnable, traité par une simple machine.

Regarder la configuration "étudiante" en 1997,

celle juste 3 ans aprés, une révolution est passée par là ou la dernière actuellement en place à Mountain View.
Google possède en effet la plus importante capacité de calcul du monde, cela ne signifie plus le plus gros ordinateur car ce temps-là est révolu même les grands centres scientifiques n'en achétent plus, le CEA peut en témoigner, comme Sandia Labs, Lawrence Livermore ou la NASA, leur coût est prohibitif ayant fait les beaux jours de Cray, Thinking Machines ou Convex.

Google est parti d'un constat simple qui tient compte de la nature distribuée d'Internet, de la volonté de répartir les traitements et de cloner des entités entières - leurs clusters par exemple - de répondre aux millions de requêtes par seconde sur le moteur de recherche et surtout de ne pas consacrer une fortune à cette couche, certes critique, mais sans modèle économique immédiat, visible ou direct. N'oublions pas que Google n'utilise que des PCs standards, peut-être certains gonflés, mais de vraies machines "jetables", des consommables finalement, avec tous les aspects universels associés: Linux, Ethernet, IP, SCSI... et peu onéreux, et bien sûr tout ce qui est gratuit, qu'il enrichisse et complète à leur sauce... On compte au moins 450000 machines organisées en cluster installées sur plusieurs sites et zones géographiques, le plus gros en Europe est en Irlande. Pour la petite histoire, Google stocke des dizaines d'exemplaires du Web !!! alors, quand ils indiquent avoir indexé 9 milliards de pages, je vous laisse estimer, pas simple calcul, l'espace nécessaire. Ils ont bien trouvé leur nom: Google c'est un 1 suivi de 100 zéros.

Alors comment ça marche ? simple et compliqué à la fois. Une philosophie asymmétrique a été retenue avec un serveur maître - le GFS Master - protégé par une série de Replicas, qui contrôle plusieurs centaines de serveurs de stockage - les Chunkservers - à la merci des requêtes des machines clientes. L'diée est donc de découper les fichiers en morceau de 64Mo et de répartir les segments élémentaires sur les différents chunkservers le tout en ajoutant la redondance nécessaire. Quand un client souhaite accéder à un fichier, un requête est envoyé au GFS master qui retourne l'identification du chunkserver - un entier sur 64 bits - possédant la donnée ainsi que sa position sur ce serveur et dans le fichier élémentaire. En fait, chaque élément de fichier stocké sur un serveur de stockage est lui-même un fichier dans l'arborescence locale, on a ainsi des fichiers de fichiers et le RAID est effectué entre serveurs et pas seulement entre disques "derrière" chaque serveur. Un chunk est présent au moins 3 fois dans un cluster. La figure ci-dessous illustre la configuration simplifiée d'un cluster GFS. Ouf, c'est quand même pas trivial leur truc, c'est Google... et ce n'est pas fini à voir ce qu'ils préparent.