Konfiguration av flera kluster

Konfigurationen för flera kluster avgör vilka kluster som för närvarande ingår i flera kluster. Den ändras inte automatiskt utan styrs av operatorn. Det skiljer sig alltså helt från den medlemskapsmekanism som används i ett kluster, som automatiskt avgör vilken uppsättning silor som ingår i klustret.

Vi använder följande terminologi för klustren i en tjänst:

• Ett kluster är aktivt om det har minst en aktiv silo och annars inaktivt .
• Ett kluster är anslutet om det ingår i den aktuella konfigurationen för flera kluster och inte är anslutet på annat sätt.

Att vara aktiv/inaktiv är oberoende av att vara ansluten/icke-ansluten: alla fyra kombinationer är möjliga.

Alla kluster för en viss tjänst är anslutna via ett skvallernätverk. Skvallernätverket sprider konfigurations- och statusinformation.

Mata in en konfiguration

En operatör utfärdar konfigurationsändringar genom att mata in dem i nätverket med flera kluster. Konfigurationerna kan matas in i alla kluster och spridas därifrån till alla aktiva kluster. Varje ny konfiguration består av en lista över kluster-ID:n som utgör flera kluster. Den har också en UTC-tidsstämpel som används för att spåra dess spridning genom skvallernätverket.

Inledningsvis är konfigurationen för flera kluster null, vilket innebär att listan över flera kluster är tom (innehåller inga kluster). Därför måste operatorn först mata in en konfiguration med flera kluster. När den här konfigurationen har matats in finns den kvar i alla anslutna silor (när den körs) och i alla angivna skvallerkanaler (om dessa kanaler är beständiga).

Vi har vissa begränsningar för inmatning av nya konfigurationer som en operatör måste följa:

• Varje ny konfiguration kan lägga till flera kluster eller ta bort vissa kluster (men inte båda samtidigt).
• En operatör bör inte utfärda en ny konfiguration medan en tidigare konfigurationsändring fortfarande bearbetas.

Dessa begränsningar säkerställer att protokoll, till exempel protokollet med en enskild instans, korrekt kan upprätthålla ömsesidig uteslutning av aktiveringar även under konfigurationsändringar.

Hanteringsintervall

Konfigurationer med flera kluster kan matas in på valfri nod i valfritt kluster med hjälp av hanteringsintervallet Orleans . Om du till exempel vill mata in en konfiguration med flera kluster som består av de tre klustren { us1, eu1, us2 }, kan vi skicka en sträng som kan räknas upp till hanteringsintervallet:

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

Det första argumentet till InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) är en samling kluster-ID:n, som ska definiera den nya konfigurationen för flera kluster. Det andra argumentet är en (valfri) kommentarssträng som kan användas för att tagga konfigurationer med godtycklig information, till exempel vem som injicerade dem och varför.

Det finns ett valfritt tredje argument, ett booleskt värde med namnet checkForLaggingSilosFirst, som standard är true. Det innebär att systemet utför en bra kontroll för att se om det finns några silor någonstans som inte har kommit ikapp den aktuella konfigurationen ännu och avvisar ändringen om den hittar en sådan silo. Detta hjälper till att identifiera överträdelser av begränsningen att endast en konfigurationsändring ska vänta i taget (även om den inte kan garantera det under alla omständigheter).

Standardkonfiguration

I situationer där konfigurationen för flera kluster är känd i förväg och distributionen är ny varje gång (för testning) kanske vi vill ange en standardkonfiguration. Den globala konfigurationen stöder ett valfritt attribut DefaultMultiCluster som tar en kommaavgränsad lista över kluster-ID:t:

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

När en silo har startats med den här inställningen kontrollerar den om den aktuella konfigurationen för flera kluster är null och i så fall matar in den angivna konfigurationen med den aktuella UTC-tidsstämpeln.

Varning

Beständiga skvallerkanaler för flera kluster (baserat på AzureTable) behåller den senast inmatade konfigurationen såvida de inte tas bort explicit. I så fall har det ingen effekt att ange en DefaultMultiCluster när du distribuerar om ett kluster eftersom konfigurationen som lagras i skvallerkanalerna inte är null.>

Gossip-kanal

En operator kan också mata in konfigurationen direkt i skvallerkanalen. Ändringar i kanalen plockas upp och sprids automatiskt av det periodiska bakgrundsskvalleret, men möjligen mycket långsamt (att använda hanteringskornet är mycket snabbare). En grov uppskattning av spridningstiden är 30 sekunder (eller vilket skvallerintervall som anges i den globala konfigurationen) gånger binär logaritmen för det totala antalet silor i alla kluster. Men eftersom skvallerparen väljs slumpmässigt kan de vara både mycket snabbare eller mycket långsammare.

Om du använder den Azure-tabellbaserade skvallerkanalen kan operatorerna mata in en ny konfiguration genom att redigera konfigurationsposten i OrleansGossipTable, med hjälp av något verktyg för att redigera data i Azure-tabeller. Konfigurationsposten har följande format:

Namn	Typ	Värde
PartitionKey	String	ServiceId
RowKey	String	"CONFIG"
Kluster	String	kommaavgränsad lista över kluster-ID:n, t.ex. "us1,eu1,us2"
Kommentar	String	valfri kommentar
GossipTimestamp	Datum/tid	UTC-tidsstämpel för konfigurationen

Kommentar

När du redigerar den här posten i lagringen måste också GossipTimestamp anges till ett nyare värde än det har för närvarande (annars ignoreras ändringen). Det mest praktiska och rekommenderade sättet att göra detta är att ta bort GossipTimestamp fältet – vår implementering av skvallerkanalen ersätter den sedan automatiskt med en korrekt, aktuell tidsstämpel (den använder Tidsstämpeln för Azure Table).

Klusterprocedurer

Att lägga till eller ta bort ett kluster från flera kluster måste ofta samordnas i en större kontext. Vi rekommenderar att du alltid följer de procedurer som beskrivs nedan när du lägger till/tar bort kluster från flera kluster.

Procedur för att lägga till ett kluster

1. Starta ett nytt Orleans kluster och vänta tills alla silor är igång.
2. Mata in en konfiguration som innehåller det nya klustret.
3. Börja dirigera användarbegäranden till det nya klustret.

Procedur för att ta bort ett kluster

1. Sluta dirigera nya användarbegäranden till klustret.
2. Mata in en konfiguration som inte längre innehåller klustret.
3. Stoppa alla silor i klustret.

När ett kluster har tagits bort på det här sättet kan det läggas till igen genom att följa proceduren för att lägga till ett nytt kluster.

Aktivitet i icke-anslutna kluster

Det kan finnas korta, tillfälliga perioder där ett kluster är både aktivt och icke-anslutet:

• Ett nystartat kluster kan börja köra kod innan det finns i konfigurationen för flera kluster (mellan steg 1 och 2 i proceduren för att lägga till ett kluster)
• Ett kluster som inaktiveras kan fortfarande köra kod innan silor stängs av (mellan steg 2 och 3 i proceduren för att ta bort ett kluster).

Under dessa mellanliggande situationer är följande möjliga:

• För global-single-instance grains: Ett korn kan ha en dubblettaktivering på ett icke-anslutet kluster.
• För versionsbebyggda korn: aktiveringar på icke-anslutna kluster tar inte emot meddelanden när korntillståndet ändras.