Communication multicluster

Article
06/08/2023

Le réseau doit être configuré pour que tout silo Orleans puisse se connecter à un autre silo Orleans par TCP/IP, quel que soit l’endroit dans le monde où il se trouve. Le déroulement exact des opérations dépasse le cadre de Orleans, car tout dépend de la façon dont les silos sont déployés et de l’endroit où ils le sont.

Par exemple, sur Windows Azure, nous pouvons utiliser des VNet (réseaux virtuels) pour connecter plusieurs déploiements dans une région, et des passerelles pour connecter les VNet entre les différentes régions.

Identificateur de cluster

Chaque cluster a son propre ID de cluster unique. L’ID de cluster doit être spécifié dans la configuration globale.

Les ID de cluster ne doivent pas être vides et ne doivent pas contenir de virgules. De plus, si vous utilisez le service Azure Stockage Table, les ID de cluster ne doivent pas contenir les caractères interdits pour les clés de ligne (/, , #, ?).

Nous vous recommandons d’utiliser des chaînes très courtes pour les ID de cluster, car ils sont transmis fréquemment et peuvent être conservés dans le stockage par certains fournisseurs de vues de journaux.

Passerelles de cluster

Chaque cluster désigne automatiquement un sous-ensemble de ses silos actifs pour servir de passerelles de cluster. Les passerelles de cluster publient directement leurs adresses IP auprès des autres clusters et peuvent ainsi servir de « points de premier contact ». Par défaut, 10 silos au maximum (ou tout autre nombre configuré en tant que MaxMultiClusterGateways) sont désignés en tant que passerelles de cluster.

La communication entre les silos de différents clusters ne passe pas toujours par une passerelle. Une fois qu’un silo a appris et mis en cache l’emplacement d’une activation de grain (quel que soit le cluster), il envoie directement les messages à ce silo, même si celui-ci n’est pas une passerelle de cluster.

Gossip

Gossip est un mécanisme qui permet aux clusters de partager des informations de configuration et d’état. Comme leur nom l’indique, les communications Gossip sont décentralisées et bidirectionnelles : chaque silo communique directement avec d’autres silos, à la fois dans le même cluster et dans d’autres clusters, pour échanger des informations dans les deux sens.

Content. Les communications Gossip contiennent une partie ou la totalité des informations suivantes :

La configuration multicluster actuelle horodatée.
Un dictionnaire qui contient des informations sur les passerelles de cluster. La clé est l’adresse du silo. La valeur contient (1) un horodatage, (2) l’ID de cluster et (3) un état, qui est actif ou inactif.

Propagation rapide et lente. Quand une passerelle change d’état ou quand un opérateur injecte une nouvelle configuration, ces informations Gossip sont immédiatement envoyées à tous les silos, clusters et canaux Gossip. Cela se produit rapidement mais n’est pas fiable. En cas de perte du message pour une raison quelconque (par exemple compétitions, problèmes de sockets, défaillances de silos), nos communications Gossip périodiques en arrière-plan permettent de garantir la propagation des informations jusqu’à leur destination, bien que plus lentement. Toutes les informations sont finalement propagées partout et sont très résilientes face aux pertes de messages et autres défaillances occasionnelles.

Toutes les données Gossip sont horodatées. Ainsi, les informations les plus récentes remplacent obligatoirement les informations plus anciennes, quel que soit le minutage relatif des messages. Par exemple, les configurations multiclusters plus récentes remplacent les anciennes, et les informations plus récentes relatives à une passerelle remplacent les informations plus anciennes la concernant. Pour plus d’informations sur la représentation des données Gossip, consultez la classe MultiClusterData. Elle dispose d’une méthode Merge, qui combine les données Gossip en résolvant les conflits à l’aide d’horodatages.

Canaux Gossip

Quand un silo démarre pour la première fois, ou quand il a redémarré après une défaillance, il doit disposer d’un moyen d’amorcer les communications Gossip. Il s’agit du rôle du canal Gossip, qui peut être défini dans la Configuration du silo. Au démarrage, un silo récupère toutes les informations des canaux Gossip. Après le démarrage, un silo continue d’émettre des données Gossip périodiquement, toutes les 30 secondes, ou selon la valeur configurée en tant que BackgroundGossipInterval. À chaque fois, il synchronise ses informations Gossip avec un partenaire sélectionné de manière aléatoire parmi toutes les passerelles de cluster et tous les canaux Gossip.

Bien que cela ne soit pas strictement nécessaire, nous vous recommandons de toujours configurer au moins deux canaux Gossip, dans des régions distinctes, pour une meilleure disponibilité.
La latence de la communication avec les canaux Gossip n’est pas critique.
Plusieurs services différents peuvent utiliser le même canal Gossip sans interférence, tant que le ServiceId Guid (spécifié par leur configuration respective) est distinct.
Il n’est pas strictement nécessaire que tous les silos utilisent les mêmes canaux Gossip, tant que ces canaux sont suffisants pour permettre à un silo de se connecter initialement à la « communauté Gossip » au démarrage. Toutefois, si un canal Gossip ne fait pas partie de la configuration d’un silo, et si ce silo est une passerelle, il n’envoie (push) pas ses mises à jour d’état au canal (propagation rapide). Cela peut donc prendre plus de temps avant que celles-ci n’atteignent le canal via des communications Gossip périodiques en arrière-plan (propagation lente).

Canal Gossip Azure basé sur des tables

Nous avons déjà implémenté un canal Gossip basé sur des tables Azure. La configuration spécifie les chaînes de connexion standard utilisées pour les comptes Azure. Par exemple, une configuration peut spécifier deux canaux Gossip avec des comptes Stockage Azure distincts, usa et europe, comme indiqué ci-dessous :

var silo = new HostBuilder()
    .UseOrleans(builder =>
    {
        builder.Configure<MultiClusterOptions>(options =>
        {
            options.GossipChannels.Add(
                "AzureTable",
                "DefaultEndpointsProtocol=https;AccountName=usa;AccountKey=...");
            options.GossipChannels.Add(
                "AzureTable",
                "DefaultEndpointsProtocol=https;AccountName=europe;AccountKey=...")
        });
    })

Plusieurs services différents peuvent utiliser le même canal Gossip sans interférence, tant que le ServiceId Guid spécifié par leur configuration respective est distinct.

Partager via