Konfiguration av flera kluster

2025-05-29

Konfigurationen för flera kluster avgör vilka kluster som för närvarande ingår i flera kluster. Den ändras inte automatiskt. i stället styr operatorn den. 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 kluster 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 ansluter via ett skvallernätverk. Skvallernätverket sprider konfigurations- och statusinformation.

Infoga en konfiguration

En operatör utfärdar konfigurationsändringar genom att mata in dem i nätverket med flera kluster. Du kan mata in konfigurationer i valfritt kluster och de sprids 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 inför vissa begränsningar för att mata in 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 som protokollet med en instans korrekt kan upprätthålla ömsesidig uteslutning av aktiveringar, även under konfigurationsändringar.

Ledningsgranularitet

Du kan injicera konfigurationer med flera kluster på valfri nod i valfritt kluster med hjälp av Orleans Management Grain. Om du till exempel vill infoga en konfiguration med flera kluster som består av de tre klustren { us1, eu1, us2 }, skickar du en uppräkningssträng till hanteringskornet.

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 definierar den nya konfigurationen för flera kluster. Det andra argumentet är en valfri kommentarssträng som du kan använda 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 några silor någonstans inte har kommit ikapp den aktuella konfigurationen ännu. Om den hittar en sådan silo avvisar den ändringen. Detta hjälper till att identifiera överträdelser av begränsningen att endast en konfigurationsändring ska vara väntande i taget (även om den inte kan garantera detta 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 du 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 börjar med den här inställningen kontrollerar den om den aktuella konfigurationen för flera kluster är null. Om så är fallet injicerar silon 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 påverkar det inte att ange en DefaultMultiCluster när ett kluster omdistribueras, eftersom konfigurationen som lagras i gossip-kanalerna inte är null.>

Gossip-kanal

En operatör kan också mata in konfigurationen direkt i gossipkanalen. Periodiska bakgrundsprocesser plockar automatiskt upp och sprider ändringar i kanalen, även om det kan gå mycket långsamt (att använda en hanteringsmekanism är mycket snabbare). En grov uppskattning av spridningstiden är 30 sekunder (eller spridningsintervallet som anges i den globala konfigurationen) gånger den binära logaritmen av det totala antalet silor över alla kluster. Men eftersom skvallerpar väljs slumpmässigt kan spridningen vara mycket snabbare eller mycket långsammare.

Om du använder den Azure-tabellbaserade gossipkanalen kan operatörer enkelt införa en ny konfiguration genom att redigera konfigurationsposten i OrleansGossipTable med hjälp av ett verktyg för att redigera Azure-tabelluppgifter. Konfigurationsfilen har följande format:

Namn	Typ	Värde
Partitionsnyckel	Sträng	tjänste-ID
RadNyckel	Sträng	Konfiguration
Kluster	Sträng	kommaavgränsad lista över kluster-ID:t, till exempel "us1,eu1,us2"
Kommentar	Sträng	valfri kommentar
GossipTimestamp	Datum och tid	UTC-tidsstämpel för konfigurationen

Anmärkning

När du redigerar den här posten i lagringen måste du också ange GossipTimestamp till ett nyare värde än dess aktuella värde (annars ignoreras ändringen). Det mest praktiska och rekommenderade sättet att göra detta är att ta bort fältetGossipTimestamp. Implementeringen av gossipkanalen ersätter den sedan automatiskt med en korrekt, aktuell tidsstämpel (den använder Azure Tables tidsstämpel).

Klusterprocedurer

Att lägga till eller ta bort ett kluster från flera kluster behöver 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 eller tar bort kluster från flera kluster.

Procedur för att lägga till ett kluster

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

Procedur för att ta bort ett kluster

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

När du tar bort ett kluster på det här sättet kan du lägga till det 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 när ett kluster är både aktivt och icke-anslutet:

Ett nystartat kluster kan börja köra kod innan det ingår 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.
När det gäller versionerade korn: Aktiveringar i icke-anslutna kluster tar inte emot meddelanden när kornets tillstånd ändras.

Dela via