Communicatie met meerdere clusters

Artikel
07/03/2024

Het netwerk moet zodanig worden geconfigureerd dat elke Orleans silo via TCP/IP verbinding kan maken met een andere Orleans silo, ongeacht waar de wereld zich bevindt. Precies hoe dit wordt bereikt, valt buiten het bereik van Orleans, omdat het afhankelijk is van hoe en waar silo's worden geïmplementeerd.

In Windows Azure kunnen we bijvoorbeeld VNets gebruiken om meerdere implementaties binnen een regio te verbinden en gateways om VNets te verbinden tussen verschillende regio's.

Cluster-id

Elk cluster heeft een eigen unieke cluster-id. De cluster-id moet worden opgegeven in de globale configuratie.

Cluster-id's zijn mogelijk niet leeg en bevatten ook geen komma's. Als u Azure Table Storage gebruikt, bevatten cluster-id's mogelijk niet de tekens die niet zijn toegestaan voor rijsleutels (/, #, ?).

We raden u aan zeer korte tekenreeksen te gebruiken voor de cluster-id's, omdat cluster-id's regelmatig worden verzonden en door sommige providers voor logboekweergave in de opslag kunnen worden opgeslagen.

Clustergateways

Elk cluster wijst automatisch een subset van de actieve silo's aan die als clustergateways moeten fungeren. Clustergateways adverteren hun IP-adressen rechtstreeks naar andere clusters en kunnen dus fungeren als 'points of first contact'. Standaard worden maximaal 10 silo's (of een willekeurig getal geconfigureerd als MaxMultiClusterGateways) aangewezen als clustergateways.

Communicatie tussen silo's in verschillende clusters passeert niet altijd een gateway. Zodra een silo de locatie van een graanactivering heeft geleerd en in de cache opgeslagen (ongeacht welk cluster), worden berichten rechtstreeks naar die silo verzonden, zelfs als de silo geen clustergateway is.

Gossip

Gossip is een mechanisme voor clusters om configuratie- en statusgegevens te delen. Zoals de naam al aangeeft, is roddel gedecentraliseerd en bidirectioneel: elke silo communiceert rechtstreeks met andere silo's, zowel in hetzelfde cluster als in andere clusters, om informatie in beide richtingen uit te wisselen.

Inhoud. Gossip bevat enkele of alle volgende informatie:

De huidige tijdstempelconfiguratie met meerdere clusters.
Een woordenlijst met informatie over clustergateways. De sleutel is het siloadres en de waarde bevat (1) een tijdstempel, (2) de cluster-id en (3) een status, die actief of inactief is.

Snelle en trage doorgifte. Wanneer een gateway de status wijzigt of wanneer een operator een nieuwe configuratie injecteert, wordt deze roddelgegevens onmiddellijk verzonden naar alle silo's, clusters en roddelkanalen. Dit gebeurt snel, maar is niet betrouwbaar. Als het bericht om welke redenen dan ook verloren gaat (bijvoorbeeld races, verbroken sockets, silofouten), zorgt onze periodieke achtergrond roddel ervoor dat de informatie uiteindelijk verspreidt, zij het langzamer. Alle informatie wordt uiteindelijk overal doorgegeven en is zeer tolerant voor incidenteel berichtverlies en fouten.

Alle roddelgegevens zijn tijdstempels, wat ervoor zorgt dat nieuwere informatie oudere informatie vervangt, ongeacht de relatieve timing van berichten. Nieuwere configuraties met meerdere clusters vervangen bijvoorbeeld oudere configuraties en nieuwere informatie over een gateway vervangt oudere informatie over die gateway. Zie de MultiClusterData klasse voor meer informatie over de weergave van gossip-gegevens. Het heeft een Merge methode die roddelgegevens combineert en conflicten oplost met tijdstempels.

Gossip-kanalen

Wanneer een silo voor het eerst wordt gestart of wanneer deze opnieuw wordt opgestart na een storing, moet deze een manier hebben om de roddel op te starten. Dit is de rol van het gossip-kanaal, dat kan worden geconfigureerd in de siloconfiguratie. Bij het opstarten haalt een silo alle informatie van de roddelkanalen op. Na het opstarten blijft een silo periodiek, elke 30 seconden, of wat er is geconfigureerd als BackgroundGossipInterval. Telkens wanneer de gossip-informatie wordt gesynchroniseerd met een partner die willekeurig is geselecteerd uit alle clustergateways en gossip-kanalen.

Hoewel dit niet strikt vereist is, raden we u aan om altijd ten minste twee gossip-kanalen, in verschillende regio's, te configureren voor een betere beschikbaarheid.
Latentie van communicatie met roddelkanalen is niet essentieel.
Meerdere verschillende services kunnen hetzelfde gossip-kanaal zonder interferentie gebruiken, zolang de ServiceId Guid (zoals opgegeven door hun respectieve configuratie) uniek is.
Er is geen strikte eis dat alle silo's dezelfde roddelkanalen gebruiken, zolang de kanalen voldoende zijn om een silo in eerste instantie verbinding te laten maken met de "gossiping community" wanneer het begint. Maar als een roddelkanaal geen deel uitmaakt van de configuratie van een silo en die silo een gateway is, pusht het de statusupdates niet naar het kanaal (snelle doorgifte), dus het kan langer duren voordat deze het kanaal bereiken via periodieke achtergrond-roddels (trage doorgifte).

Op tabellen gebaseerd gossip-kanaal van Azure

We hebben al een gossip-kanaal geïmplementeerd op basis van Azure Tables. De configuratie bevat standaard verbindingsreeks die worden gebruikt voor Azure-accounts. Een configuratie kan bijvoorbeeld twee gossip-kanalen met afzonderlijke Azure-opslagaccounts usa opgeven en europe als volgt:

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=...")
        });
    })

Meerdere verschillende services kunnen hetzelfde gossip-kanaal zonder interferentie gebruiken, zolang de ServiceId Guid die is opgegeven door hun respectieve configuratie uniek is.

Delen via