Configuratie van meerdere clusters

De configuratie van meerdere clusters bepaalt welke clusters momenteel deel uitmaken van het multicluster. Deze wordt niet automatisch gewijzigd, maar wordt beheerd door de operator. Het is dus heel anders dan het lidmaatschapsmechanisme dat in een cluster wordt gebruikt, waarmee automatisch de set silo's wordt bepaald die deel uitmaken van het cluster.

We gebruiken de volgende terminologie voor de clusters in een service:

• Een cluster is actief als het ten minste één actieve silo heeft en anders inactief is.
• Een cluster wordt toegevoegd als het deel uitmaakt van de huidige configuratie met meerdere clusters en anders niet is gekoppeld .

Actief/inactief zijn is onafhankelijk van deelname/niet-lid zijn: alle vier combinaties zijn mogelijk.

Alle clusters voor een bepaalde service worden verbonden door een gossip-netwerk. Het gossip-netwerk geeft configuratie- en statusgegevens door.

Een configuratie injecteren

Een operator geeft configuratiewijzigingen door ze in het netwerk met meerdere clusters te injecteren. De configuraties kunnen in elk cluster worden geïnjecteerd en van daaruit worden verspreid naar alle actieve clusters. Elke nieuwe configuratie bestaat uit een lijst met cluster-id's die het cluster met meerdere clusters vormen. Het heeft ook een UTC-tijdstempel die wordt gebruikt voor het bijhouden van de doorgifte via het gossip-netwerk.

In eerste instantie is de configuratie met meerdere clusters null, wat betekent dat de lijst met meerdere clusters leeg is (geen clusters bevat). De operator moet dus in eerste instantie een configuratie met meerdere clusters invoeren. Zodra deze configuratie is geïnjecteerd, blijft deze configuratie aanwezig in alle verbonden silo's (terwijl deze worden uitgevoerd) en in alle opgegeven roddelkanalen (als deze kanalen persistent zijn).

Er gelden enkele beperkingen voor de injectie van nieuwe configuraties die een operator moet volgen:

• Elke nieuwe configuratie kan meerdere clusters toevoegen of sommige clusters verwijderen (maar niet beide tegelijk).
• Een operator mag geen nieuwe configuratie uitgeven terwijl een eerdere configuratiewijziging nog steeds wordt verwerkt.

Deze beperkingen zorgen ervoor dat protocollen zoals het protocol met één exemplaar de wederzijdse uitsluiting van activeringen, zelfs onder configuratiewijzigingen, correct kunnen handhaven.

Beheergranen

Configuraties met meerdere clusters kunnen worden geïnjecteerd op elk knooppunt in elk cluster, met behulp van de Orleans beheergranten. Als u bijvoorbeeld een configuratie met meerdere clusters wilt injecteren die bestaat uit de drie clusters { us1, eu1, us2 }, kunnen we een tekenreeks doorgeven die kan worden opgesomd aan het beheergranum:

var clusters = "us1,eu1,us2".Split(',');
var mgtGrain = client.GetGrain<IManagementGrain>(0);
mgtGrain.InjectMultiClusterConfiguration(clusters, "my comment here"));

Het eerste argument hiervoor InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) is een verzameling cluster-id's, die de nieuwe configuratie voor meerdere clusters gaat definiëren. Het tweede argument is een (optionele) opmerkingtekenreeks die kan worden gebruikt om configuraties te taggen met willekeurige informatie, zoals wie deze heeft geïnjecteerd en waarom.

Er is een optioneel derde argument, een Booleaanse waarde genaamd checkForLaggingSilosFirst, die standaard waar is. Het betekent dat het systeem een best effort-controle uitvoert om te zien of er silo's zijn waar de huidige configuratie nog niet is bijgekomen en de wijziging weigert als een dergelijke silo wordt gevonden. Dit helpt bij het detecteren van schendingen van de beperking die slechts één configuratiewijziging tegelijk in behandeling moet zijn (hoewel deze niet onder alle omstandigheden kan worden gegarandeerd).

Standaardconfiguratie

In situaties waarin de configuratie met meerdere clusters van tevoren bekend is en de implementatie telkens nieuw is (voor testen), willen we mogelijk een standaardconfiguratie opgeven. De globale configuratie ondersteunt een optioneel kenmerk DefaultMultiCluster dat een door komma's gescheiden lijst met cluster-id's gebruikt:

var silo = new HostBuilder()
    .UseOrleans(builder =>
    {
        builder.Configure<MultiClusterOptions>(options =>
        {
            options.DefaultMultiCluster = new[] { "us1", "eu1", "us2" };
        })
    })
    .Build();

Nadat een silo met deze instelling is gestart, wordt gecontroleerd of de huidige multiclusterconfiguratie null is en zo ja, wordt de opgegeven configuratie met de huidige UTC-tijdstempel geïnjecteerd.

Waarschuwing

Permanente gossip-kanalen met meerdere clusters (op basis van AzureTable) behouden de laatst geïnjecteerde configuratie, tenzij ze expliciet worden verwijderd. In dat geval heeft het opgeven van een cluster DefaultMultiCluster geen effect bij het opnieuw implementeren van een cluster, omdat de configuratie die is opgeslagen in de gossip-kanalen niet null is.>

Gossip-kanaal

Een operator kan de configuratie ook rechtstreeks in het gossip-kanaal injecteren. Wijzigingen in het kanaal worden opgehaald en automatisch doorgegeven door de periodieke achtergrond-roddel, hoewel mogelijk zeer langzaam (het gebruik van het beheerinterval is veel sneller). Een ruwe schatting van de doorgiftetijd is 30 seconden (of elk roddelinterval wordt opgegeven in de globale configuratie) keer de binaire logaritme van het totale aantal silo's in alle clusters. Maar omdat de roddelparen willekeurig worden geselecteerd, kunnen ze zowel veel sneller als veel langzamer zijn.

Als u het op tabellen gebaseerde gossip-kanaal van Azure gebruikt, kunnen operators een nieuwe configuratie injecteren door de configuratierecord in het OrleansGossipTable, met behulp van een hulpprogramma voor het bewerken van gegevens in Azure-tabellen, te bewerken. De configuratierecord heeft de volgende indeling:

Name	Type	Weergegeven als
PartitionKey	String	de ServiceId
RowKey	String	"CONFIG"
Clusters	String	door komma's gescheiden lijst met cluster-id's, bijvoorbeeld 'us1,eu1,us2'
Opmerking	String	optionele opmerking
GossipTimestamp	Datum en tijd	UTC-tijdstempel voor de configuratie

Notitie

Wanneer u deze record in de opslag bewerkt, moet de GossipTimestamp record ook worden ingesteld op een nieuwere waarde dan op dit moment (anders wordt de wijziging genegeerd). De handigste en aanbevolen manier om dit te doen, is door het GossipTimestamp veld te verwijderen. De implementatie van het gossip-kanaal vervangt het vervolgens automatisch door een juiste, huidige tijdstempel (het maakt gebruik van de Tijdstempel van de Azure-tabel).

Clusterprocedures

Het toevoegen of verwijderen van een cluster uit het cluster met meerdere clusters moet vaak binnen een grotere context worden gecoördineerd. U wordt aangeraden altijd de procedures te volgen die hieronder worden beschreven bij het toevoegen/verwijderen van clusters uit het cluster met meerdere clusters.

Procedure voor het toevoegen van een cluster

1. Start een nieuw Orleans cluster en wacht totdat alle silo's actief zijn.
2. Injecteer een configuratie die het nieuwe cluster bevat.
3. Start het routeren van gebruikersaanvragen naar het nieuwe cluster.

Procedure voor het verwijderen van een cluster

1. Stop de routering van nieuwe gebruikersaanvragen naar het cluster.
2. Injecteer een configuratie die het cluster niet meer bevat.
3. Stop alle silo's van het cluster.

Zodra een cluster op deze manier is verwijderd, kan het opnieuw worden toegevoegd door de procedure voor het toevoegen van een nieuw cluster te volgen.

Activiteit op niet-gekoppelde clusters

Er kunnen korte, tijdelijke perioden zijn waarbij een cluster zowel actief als niet-gekoppeld is:

• Een nieuw gestart cluster kan beginnen met het uitvoeren van code voordat deze zich in de configuratie met meerdere clusters bevindt (tussen stap 1 en 2 van de procedure voor het toevoegen van een cluster)
• Een cluster dat buiten gebruik wordt gesteld, kan nog steeds code uitvoeren voordat de silo's worden afgesloten (tussen stap 2 en 3 van de procedure voor het verwijderen van een cluster).

Tijdens deze tussenliggende situaties zijn het volgende mogelijk:

• Voor korrels met één exemplaar wereldwijd: Een grain kan een dubbele activering hebben op een cluster dat niet is gekoppeld.
• Voor versies van korrels: activeringen op niet-gekoppelde clusters ontvangen geen meldingen wanneer de korrelstatus verandert.