Mise en œuvre du répertoire des grains

Vue d’ensemble et architecture

Le répertoire des grains dans Orleans est un magasin clé-valeur où la clé est un identifiant de grain et la valeur est une entrée d'enregistrement qui pointe vers un silo actif qui héberge (potentiellement) le grain.

Bien que Orleans fournisse une implémentation d'annuaire distribué en mémoire par défaut (décrite dans cet article), le système d'annuaire des grains est conçu pour être enfichable. Les développeurs peuvent implémenter leur propre annuaire en implémentant l’interface IGrainDirectory et en l’inscrivant auprès de la collection de services du silo. Cela permet des implémentations d’annuaire personnalisées qui peuvent utiliser différents back-ends de stockage ou modèles de cohérence afin de mieux répondre aux besoins spécifiques de l’application. Depuis l’introduction du nouveau répertoire de cohérence forte, il n’y a guère besoin d’implémentations d’annuaires externes, mais l’API reste à des fins de compatibilité descendante et de flexibilité. Le répertoire grain peut être configuré par type grain.

Pour optimiser les performances, les recherches de répertoires sont mises en cache localement dans chaque silo. Cela signifie que les lectures de répertoire potentiellement distantes sont nécessaires uniquement lorsque l’entrée de cache locale est manquante ou non valide. Ce mécanisme de mise en cache réduit la surcharge réseau et la latence associées aux recherches d’emplacement des grains.

À l'origine, Orleans a implémenté un répertoire éventuellement cohérent structuré en tant que table de hachage distribuée. Il a été remplacé par un annuaire fortement cohérent dans Orleans v9.0, basé sur la méthodologie Virtually Synchronous en deux phases et également structuré comme une table de hachage distribuée, mais avec un meilleur équilibrage de la charge grâce à l'utilisation de nœuds virtuels. Cet article décrit cette dernière implémentation de répertoire de grain plus récente.

Répertoire de grain distribué

L'annuaire à grains distribués de Orleans offre une grande cohérence, un équilibrage régulier de la charge, des performances élevées et une tolérance aux pannes. L’implémentation suit une conception en deux phases basée sur la méthodologie de synchronisation virtuelle avec des similitudes avec Paxos vertical.

Les partitions d’annuaire ont deux modes d’opération :

1. Opération normale : les partitions traitent les demandes localement sans coordination avec d’autres hôtes.
2. Changement de vue : les hôtes se coordonnent pour transférer la propriété des plages de l'annuaire.

L'annuaire s'appuie sur le système d'appartenance à un cluster à forte cohérence de Orleans, dans lequel les configurations appelées « vues » ont des numéros de version qui augmentent de façon monotone. Au fur et à mesure que les silos rejoignent et quittent le cluster, des vues successives sont créées, ce qui entraîne des changements dans la propriété des plages.

Toutes les opérations d’annuaire incluent la coordination des vues :

• Les requêtes portent le numéro de vue de l'appelant.
• Les réponses incluent le numéro de vue de la partition.
• La non-concordance des numéros de vue déclenche la synchronisation.
• Les demandes sont automatiquement réessayées lors des changements d’affichage.

Cela garantit que toutes les requêtes sont traitées par le propriétaire correct de la partition d’annuaire.

Stratégie de partitionnement

Le répertoire est partitionné à l’aide d’un anneau de hachage cohérent avec des plages affectées aux silos actifs dans le cluster. Les identificateurs de grains sont hachés pour trouver le silo qui possède la section de l'anneau correspondant à son hachage.

Chaque silo actif possède un nombre préconfiguré de plages, par défaut à 30 plages par silo. Ceci est similaire au schéma utilisé par Amazon Dynamo et Apache Cassandra, où plusieurs « nœuds virtuels » (plages) sont créés pour chaque nœud (hôte).

La taille d’une partition est déterminée par la distance entre son hachage et le hachage de la partition suivante. Il est possible qu’une plage soit divisée entre plusieurs silos lors d’une modification d’affichage, ce qui ajoute de la complexité à la procédure de modification d’affichage, car chaque partition doit potentiellement coordonner avec plusieurs autres partitions.

Afficher la procédure de modification

Les partitions d'annuaire (mises en œuvre dans GrainDirectoryPartition) utilisent des verrous de plage versionnés pour empêcher l'accès non valide aux plages lors des changements de vue. Les verrous de plage sont créés lors du changement de vue et sont libérés lorsque le changement de vue est terminé. Ces verrous sont analogues aux « wedges » utilisés dans la méthodologie de synchronisation virtuelle.

Lorsqu’une modification d’affichage se produit, une partition peut augmenter ou réduire :

• Si un nouveau silo a rejoint le cluster, les partitions existantes peuvent être réduites pour faire de la place.
• Si un silo a quitté le cluster, les partitions restantes peuvent s'élargir pour couvrir les plages orphelines.

Les inscriptions d’annuaire doivent être transférées de l’ancien propriétaire au nouveau propriétaire avant que les demandes puissent être traitées. Le processus de transfert suit les étapes suivantes :

1. L'ancien propriétaire scelle la plage et crée un instantané de ses entrées de répertoire.
2. Le nouveau propriétaire demande et applique l'instantané.
3. Le nouveau propriétaire commence à répondre aux requêtes pour la plage.
4. Le propriétaire précédent est averti et supprime l’instantané.

Processus de récupération

Lorsqu'un hôte se bloque sans transférer correctement ses partitions de répertoire, les propriétaires des partitions suivantes doivent effectuer une récupération. Cela implique :

1. Interrogation de tous les silos actifs du cluster pour leurs enregistrements de grain.
2. Reconstruction de l'état du répertoire pour les plages concernées.
3. en s'assurant qu'il n'y a pas de doublons dans l'activation des grains.

La récupération est également nécessaire lorsque les modifications d’appartenance au cluster se produisent rapidement. Bien que l'appartenance à un cluster garantisse la monotonicité, il est possible que les silos manquent des vues d'appartenance intermédiaires. Dans ce cas :

• Les transferts d'instantanés sont abandonnés.
• La récupération est effectuée au lieu du transfert normal entre partitions.
• Le système maintient la cohérence malgré les états intermédiaires manquants.

Une amélioration future de l’appartenance au cluster peut réduire ou éliminer ces scénarios en garantissant que toutes les vues sont vues par tous les silos.