Partager via


Équilibrage de charge

L’équilibrage de charge, au sens large, est l’un des piliers du runtime Orleans. Le runtime Orleans tente de tout équilibrer, car l’équilibrage permet d’optimiser l’utilisation des ressources et d’éviter les points chauds. Cela conduit à de meilleures performances et contribue à l’élasticité. L’équilibrage de charge dans Orleans s’applique à plusieurs endroits. Voici une liste non exhaustive des emplacements où le runtime réalise un équilibrage :

  1. La stratégie de positionnement par défaut des acteurs est aléatoire, les nouvelles activations sont placées de manière aléatoire entre les silos. Cela entraîne un positionnement équilibré et empêche la formation de points chauds pour la plupart des scénarios.
  2. Un ActivationCountBasedPlacement plus avancé tente d’égaliser le nombre d’activations sur tous les silos, ce qui entraîne une distribution plus uniforme des activations entre les silos. Cela est particulièrement important pour l’élasticité.
  3. Le service de répertoire de grain repose sur une table de hachage distribuée, qui est équilibrée par nature. Le service de répertoire mappe les grains aux activations, chaque silo possède une partie de la table de mappage globale, et cette table est globalement partitionnée de manière équilibrée entre tous les silos. Nous utilisons un hachage cohérent avec des compartiments virtuels pour cela.
  4. Les clients se connectent à toutes les passerelles et répartissent leurs demandes de manière équilibrée entre elles.
  5. Le service de rappel est un service d’exécution partitionné distribué. L’affectation du silo responsable de servir le rappel est équilibrée sur tous les silos via un hachage cohérent, comme dans le répertoire de grain.
  6. Les composants critiques en matière de performances au sein d’un silo sont partitionnés, et le travail est équilibré localement entre eux. De cette façon, le runtime de silo peut pleinement utiliser tous les cœurs de processeur disponibles et ne pas créer de goulots d’étranglement dans un silo. Cela s’applique à toutes les ressources locales : allocation de travail aux threads, sockets, responsabilités de dispatch, files d’attente, etc.
  7. QueueBalancerBase équilibre la responsabilité du tirage (pull) d’événements à partir des files d’attente de persistance entre les silos du cluster.

L’équilibrage ne signifie pas nécessairement une perte de localité. Il est possible d’être équilibré et de maintenir une bonne localité. Par exemple, quand l’équilibrage est synonyme de partitionnement, vous pouvez partitionner la responsabilité pour une certaine tâche logique, tout en conservant la localité au sein de chaque partition. Cela s’applique aussi bien pour l’équilibrage local que distribué.