CMG Brasil

Pomegranate est un nouveau système de fichiers distribué construit sur un stockage tabulaire distribué qui agit terriblement comme un système NoSQL. Il vise à augmenter les performances de l’accès aux objets minuscules afin de prendre en charge des applications telles que les services de photo en ligne et de micro-blogs, qui nécessitent une forte concurrence, un débit élevé et une faible latence. Leurs tests semblent indiquer que cela fonctionne :

Nous avons démontré que le système de fichiers sur le stockage tabulaire est performant pour les accès hautement concurrents. Dans notre cluster de test, nous avons observé une augmentation linéaire de plus de 100 000 demandes agrégées de lecture et d’écriture servies par seconde (RPS).

Plutôt que d’être assis au sommet du système de fichiers comme presque tous les autres magasins K-V, Grenade est cuit dans le système de fichiers. L’idée est que l’API du système de fichiers est commune à toutes les plateformes, de sorte qu’il n’y aurait pas besoin d’une API distincte pour l’utiliser. Chaque application pourrait l’utiliser dès la boîte.

Les fonctionnalités de Pomegranate sont :

• Il gère efficacement des milliards de petits fichiers, même dans un seul répertoire;
• Il fournit une couche de cache séparée et évolutive, qui peut être snapshotable;
• La couche de stockage utilise le stockage structuré log pour absorber les écritures de petits fichiers afin d’utiliser la bande passante du disque;
• Construire un espace de noms global pour les petits fichiers et les gros fichiers ;
• Stockage colonnaire pour exploiter la localité temporelle et spatiale ;
• Hachage extensible distribué pour indexer les métadonnées ;
• Mise en cache instantanée et reconfigurable pour augmenter le parallélisme et tolérer les défaillances ;
• Grenade devrait être le premier système de fichiers qui est construit sur un stockage tabulaire, et l’expérience de construction devrait être digne pour la communauté des systèmes de fichiers.

Can Ma, qui dirige les recherches sur Grenade, a eu la gentillesse d’accepter une courte interview.

Pouvez-vous donner un aperçu de l’architecture et de ce que vous faites de cool et de différent ?

Basiquement, il n’y a pas de système de fichiers distribué ou parallèle qui puisse gérer efficacement des milliards de petits fichiers. Cependant, nous pouvons prévoir que les applications web (comme le courrier électronique, les photos et même les vidéos) et la bio-informatique (séquençage de gènes) ont besoin d’accès massifs à de petits fichiers. Pendant ce temps, l’API du système de fichiers est assez générale et bien comprise pour la plupart des programmeurs.

Donc, nous voulons construire un système de fichiers pour gérer des milliards de petits fichiers, et fournir un haut débit d’accès concurrents. Bien que Grenade soit conçu pour les accès aux petits fichiers, il supporte également les gros fichiers. Il est construit au-dessus d’autres systèmes de fichiers distribués, comme Lustre, et ne gère que l’espace de noms et les petits fichiers. Nous voulons simplement nous tenir sur « les épaules des géants ». Voir la figure ci-dessous:

Pomegranate a de nombreux serveurs de métadonnées et serveurs de stockage de métadonnées pour servir les demandes de métadonnées et les demandes de lecture/écriture de petits fichiers. Les MDS ne sont qu’une couche de mise en cache, qui charge les métadonnées à partir du stockage et commet des instantanés de mémoire au stockage. Le cœur de Pomegranate est un système de stockage tabulaire distribué appelé xTable. Il supporte les recherches multi-colonnes indexées par clé. Nous utilisons le hachage extensible distribué pour localiser le serveur à partir de la clé, parce que le hachage extensible est plus adaptatif à l’augmentation et à la diminution de l’échelle.

Dans les systèmes de fichiers, la table des répertoires et la table des inodes sont toujours séparées pour supporter deux types de recherche différents. Les recherches par nom de chemin sont traitées par la table de répertoire, tandis que les recherches par numéro d’inode sont traitées par la table d’inode. Il n’est pas facile de mettre à jour ces deux index de manière cohérente, surtout dans un système de fichiers distribué. En même temps, l’utilisation de deux index a augmenté la latence de recherche, ce qui est inacceptable pour accéder à de petits fichiers. En général, il y a des caches en mémoire pour la dentry et l’inode, cependant, les caches ne peuvent pas facilement s’étendre. La modification des métadonnées doit mettre à jour plusieurs emplacements. Pour maintenir la cohérence, le journal des opérations est introduit. Alors que, le journal des opérations est toujours un point de série pour les flux de demandes.

Pomegranate utiliser une structure de répertoire de type table pour fusionner la table de répertoire et la table inode. Deux différents types de recherche sont unifiés à des recherches par clé. Pour le système de fichiers, la clé est la valeur de hachage du nom du répertoire. Les conflits de hachage sont résolus par un identifiant unique global pour chaque fichier. Pour chaque mise à jour, il suffit de rechercher et de mettre à jour une table. Pour éliminer le journal des opérations, nous concevons et prenons en charge le snapshot de la mémoire pour obtenir une image cohérente. Les régions sales de chaque instantané peuvent être écrites sur le stockage en toute sécurité sans considérer les modifications concurrentes.(Les mises à jour concurrentes sont COWed.)

Cependant, il y a certaines opérations complexes du système de fichiers telles que mkdir, rmdir, hard link, et rename qui doivent être considérées. Ces ops doivent mettre à jour au moins deux tables. Nous implémentons un service de mise à jour multisite fiable pour propager les deltas d’une table à l’autre. Par exemple, sur mkdir, nous propageons le delta(« nlink +1 ») à la table parente.

Y a-t-il des points uniques de défaillance ?

Il n’y a pas de SPOF dans la conception. Nous utilisons un cluster de MDS pour servir la demande de métadonnées. Si un MDS s’est écrasé, les demandes sont redirigées vers d’autres MDS(hachage cohérent et heartbeats sont utilisés). Les métadonnées et les petits fichiers sont répliqués sur plusieurs nœuds. Cependant, cette réplication est déclenchée par des outils de synchronisation externes qui sont asynchrones aux écritures.

Les petits fichiers ont généralement été la mort des systèmes de fichiers en raison de la maintenance de la structure de répertoire. Comment contournez-vous cela ?

Oui, c’est mortellement lent pour l’accès aux petits fichiers dans les systèmes de fichiers traditionnels. Nous remplaçons la table de répertoire traditionnelle (arbre B+ ou arbre de hachage) par une table de hachage extensible distribuée. Le nom du répertoire et les métadonnées de l’inode sont traités comme des colonnes de la table. Les requêtes des clients sont envoyées (ou routées si nécessaire) vers le MDS correct. Ainsi, pour accéder à un petit fichier, il suffit d’accéder à une ligne de la table pour trouver l’emplacement du fichier. Chaque petit fichier est stocké de manière séquentielle dans le système de fichiers natif. En conséquence, un accès E/S peut servir à la lecture d’un petit fichier.

Quelles apis posix sont supportées ? Les fichiers peuvent-ils être verrouillés, mappés, symlinks, etc?

À l’heure actuelle, le support POSIX progresse. Nous supportons les symlinks, l’accès mmap. Alors que, flock n’est pas supporté.

Pourquoi faire un système de fichiers au niveau du noyau plutôt qu’un K-V store par dessus ?

Notre objectif initial est d’implémenter un système de fichiers pour supporter plus d’applications existantes. Bien que, nous supportons l’interface K/V sur le dessus de xTable maintenant. Voir la figure d’architecture, le client AMC est le client clé/valeur de Grenade. Nous supportons des prédicats simples sur la clé ou la valeur, par exemple nous supportons « select * from table where key < 10 and ‘xyz’ in value » pour obtenir les paires k/v que la valeur contient « xyz » et key < 10.

Comment se compare-t-il à d’autres systèmes de fichiers distribués ?

Nous voulons comparer les performances du petit fichier avec d’autres systèmes de fichiers. Cependant, nous ne l’avons pas encore testé. Nous le ferons dans le mois à venir. Bien que, nous croyons que la plupart des systèmes de fichiers distribués ne peuvent pas gérer efficacement les accès massifs aux petits fichiers.

Les index et toute sorte de requêtes sont-ils supportés ?

Pour l’instant, ces supports n’ont pas encore été correctement considérés. Nous prévoyons de considérer les requêtes de plage prochainement.

Est-ce qu’il fonctionne à travers les centres de données, c’est-à-dire, comment gère-t-il la latence ?

Grenade ne fonctionne que dans un centre de données. Le support WAN n’a pas encore été envisagé.

Il semble que vous utilisiez une architecture en mémoire pour la vitesse. Pouvez-vous en parler ?

Nous utilisons une couche de cache mémoire dédiée pour la vitesse. Les lignes de la table sont regroupées en tranches de table. En mémoire, les sl
ices de table sont hachées dans une table de hachage locale extensible à la fois pour la performance et la consommation d’espace. Montré par la figure ci-dessous,

Les clients émettent une requête en hachant le nom du fichier et en cherchant dans le bitmap. Ensuite, en utilisant un anneau de hachage cohérent pour localiser le serveur de cache(MDS) ou le serveur de stockage(MDSL). Chaque mise à jour obtient d’abord le groupe de transactions *ouvert*, et ne peut s’appliquer qu’à la ligne de la table en mémoire. Chaque changement de groupe de transaction est atomique. Une fois que toutes les mises à jour en attente sont terminées, le groupe de transactions peut être transféré au stockage en toute sécurité. Cette approche est similaire au ZFS de Sun.

Comment la haute disponibilité est-elle gérée ?

Bien, le serveur central pour la gestion cohérente de l’anneau de hachage et le coordinateur de défaillance devrait être répliqué par l’algorithme Paxos. Nous prévoyons d’utiliser ZooKeeper pour le service central à haute disponibilité.
Les autres composants sont conçus pour être tolérants aux pannes. Les crashs de MDS et MDSL peuvent être configurés comme récupérés immédiatement en routant les demandes vers de nouveaux serveurs (en sélectionnant le prochain point dans l’anneau de hachage cohérent).

Opérationnellement, comment cela fonctionne-t-il ? Comment les nœuds sont ajoutés dans le système?

L’ajout de nœuds à la couche de mise en cache est simple. Le serveur central (R2) ajoute le nouveau nœud à l’anneau de hachage cohérent. Tous les serveurs de cache doivent agir sur ce changement et juste invalider leurs tranches de table en cache si elles seront gérées par le nouveau nœud. Les requêtes des clients sont acheminées vers le nouveau serveur, et une notification de changement d’anneau CH sera piggyback au client pour tirer le nouvel anneau du serveur central.

Comment gérez-vous les gros fichiers ? Est-ce que cela convient pour le streaming vidéo?

Comme décrit précédemment, les gros fichiers sont relayés à d’autres systèmes de fichiers distribués. Notre couche de mise en cache ne sera pas polluée par les données vidéo en streaming.

Autre chose que vous voudriez ajouter?

Une autre figure pour l’interaction des composants de Grenade.

.