Prise en charge de plusieurs clusters
La prise en charge de plusieurs clusters a été supprimée dans la v2. La documentation ci-dessous fait référence à Orleans v1. Orleans v.1.3.0 a ajouté la prise en charge de la fédération de plusieurs clusters Orleans en un multicluster faiblement connecté qui agit comme un seul service. Les multiclusters facilitent la géodistribution en tant que service, c’est-à-dire qu’ils facilitent l’exécution d’une application Orleans dans plusieurs centres de données dans le monde entier. En outre, un multicluster peut être exécuté dans un seul centre de données pour obtenir une meilleure isolation des défaillances et des performances.
Tous les mécanismes sont conçus avec une attention particulière pour :
- Réduire au minimum la communication entre les clusters.
- Laisser chaque cluster s’exécuter de façon autonome, même si d’autres clusters sont en échec ou deviennent inaccessibles.
Configuration et exploitation
Nous expliquons ci-après comment configurer et exploiter un multicluster.
Communication. Les clusters communiquent via les mêmes connexions de silo à silo que celles utilisées au sein d’un cluster. Pour échanger des informations d’état et de configuration, les clusters utilisent un mécanisme Gossip et des implémentations de canaux Gossip.
Configuration de silos. Les silos doivent être configurés pour qu’ils sachent à quel cluster ils appartiennent (chaque cluster est identifié par une chaîne unique). En outre, chaque silo doit être configuré avec des chaînes de connexion qui lui permettent de se connecter à un ou plusieurs canaux Gossip au démarrage.
Injection de configuration multicluster. Au moment de l’exécution, l’opérateur de service peut spécifier et/ou modifier la configuration multicluster, qui contient une liste d’ID de cluster, pour spécifier les clusters qui font partie du multicluster actif. Ceci se fait en appelant le grain de gestion dans un des clusters.
Grains multiclusters
Nous expliquons ci-après comment utiliser la fonctionnalité de multicluster au niveau de l’application.
Grains GSI (Global-Single-Instance) Les développeurs peuvent indiquer quand et comment les clusters doivent coordonner leurs annuaires de grains pour une classe de grain particulière. Le GlobalSingleInstanceAttribute signifie que nous voulons le même comportement que lors de l’exécution d’Orleans dans un seul cluster global, c’est-à-dire router tous les appels vers une même activation du grain. À l’inverse, le OneInstancePerClusterAttribute indique que chaque cluster peut avoir son activation indépendante. Cela est approprié si la communication entre les clusters n’est pas souhaitée.
Grains log-view (pas dans v.1.3.0). Un type spécial de grain qui utilise une nouvelle API, similaire à l’approvisionnement en événements, pour synchroniser ou conserver l’état du grain. Il peut être utilisé pour synchroniser automatiquement et efficacement l’état d’un grain entre les clusters et avec le stockage. Comme ses algorithmes de synchronisation sont sûrs pour une utilisation avec des grains réentrants et qu’ils sont optimisés pour utiliser le traitement par lot et la réplication, il peut fonctionner mieux que les grains standard quand un grain fait l’objet d’accès fréquents dans plusieurs clusters et/ou quand il est fréquemment écrit dans le stockage. La prise en charge des grains log-view ne fait pas encore partie de la branche principale. Nous avons une préversion incluant des exemples et un peu de documentation dans la branche geo-orleans. Elle est actuellement en cours d’évaluation en production par un utilisateur précoce.
