Kommunikation med flera kluster

Artikel
07/03/2024

Nätverket måste konfigureras på ett sådant sätt att alla Orleans siloer kan ansluta till andra Orleans silo via TCP/IP, oavsett var i världen det finns. Exakt hur detta uppnås ligger utanför omfånget Orleansför , eftersom det beror på hur och var silor distribueras.

I Windows Azure kan vi till exempel använda virtuella nätverk för att ansluta flera distributioner inom en region och gatewayer för att ansluta virtuella nätverk mellan olika regioner.

Klusteridentifierare

Varje kluster har ett eget unikt kluster-ID. Kluster-ID:t måste anges i den globala konfigurationen.

Kluster-ID:t kanske inte är tomma och får inte heller innehålla kommatecken. Om du använder Azure Table Storage kanske kluster-ID:t inte innehåller de tecken som är förbjudna för radnycklar (/, , #, ?).

Vi rekommenderar att du använder mycket korta strängar för kluster-ID:t, eftersom kluster-ID:t överförs ofta och kan lagras i lagring av vissa loggvisningsproviders.

Klustergatewayer

Varje kluster anger automatiskt en delmängd av sina aktiva silor som ska fungera som klustergatewayer. Klustergatewayer annonserar direkt sina IP-adresser till andra kluster och kan därmed fungera som "första kontaktpunkter". Som standard är högst 10 silor (eller det tal som har konfigurerats som MaxMultiClusterGateways) avsedda som klustergatewayer.

Kommunikation mellan silor i olika kluster passerar inte alltid genom en gateway. När en silo har lärt sig och cachelagrat platsen för en kornaktivering (oavsett i vilket kluster) skickar den meddelanden till silon direkt, även om silon inte är en klustergateway.

Skvaller

Gossip är en mekanism för kluster för att dela konfigurations- och statusinformation. Som namnet antyder är skvaller decentraliserat och dubbelriktat: varje silo kommunicerar direkt med andra silor, både i samma kluster och i andra kluster, för att utbyta information i båda riktningarna.

Innehåll. Gossip innehåller en del av eller all följande information:

Den aktuella tidsstämplade konfigurationen för flera kluster.
En ordlista som innehåller information om klustergatewayer. Nyckeln är siloadressen och värdet innehåller (1) en tidsstämpel, (2) kluster-ID och (3) status, som antingen är aktiv eller inaktiv.

Snabb och långsam spridning. När en gateway ändrar sin status, eller när en operatör matar in en ny konfiguration, skickas den här skvallerinformationen omedelbart till alla silor, kluster och skvallerkanaler. Detta sker snabbt men är inte tillförlitligt. Om meddelandet skulle gå förlorat på grund av några orsaker (t.ex. tävlingar, brutna sockets, silofel), säkerställer vårt periodiska bakgrundsskvaller att informationen så småningom sprids, om än långsammare. All information sprids så småningom överallt och är mycket motståndskraftig mot enstaka meddelandeförluster och fel.

Alla skvallerdata tidsstämplas, vilket säkerställer att nyare information ersätter äldre information oavsett den relativa tidpunkten för meddelanden. Nyare konfigurationer med flera kluster ersätter till exempel äldre konfigurationer, och nyare information om en gateway ersätter äldre information om den gatewayen. Mer information om representation av skvallerdata finns i MultiClusterData klassen . Den har en Merge metod som kombinerar skvallerdata och löser konflikter med hjälp av tidsstämplar.

Skvallerkanaler

När en silo startas först, eller när den startas om efter ett fel, måste den ha ett sätt att starta skvaller. Det här är rollen för skvallerkanalen, som kan konfigureras i Silo-konfigurationen. Vid start hämtar en silo all information från skvallerkanalerna. Efter starten fortsätter en silo att skvallra regelbundet, var 30:e sekund eller vad som än är konfigurerat som BackgroundGossipInterval. Varje gång den synkroniserar sin skvallerinformation med en partner slumpmässigt vald från alla klustergatewayer och skvallerkanaler.

Även om det inte är absolut nödvändigt rekommenderar vi att du alltid konfigurerar minst två skvallerkanaler, i olika regioner, för bättre tillgänglighet.
Svarstiden för kommunikation med skvallerkanaler är inte kritisk.
Flera olika tjänster kan använda samma skvallerkanal utan interferens, så länge ServiceId Guid (som anges i respektive konfiguration) är distinkt.
Det finns inget strikt krav på att alla silor använder samma skvallerkanaler, så länge kanalerna är tillräckliga för att låta en silo först ansluta till "skvallergemenskapen" när den startar. Men om en skvallerkanal inte är en del av en silos konfiguration, och den silon är en gateway, push-överför den inte sina statusuppdateringar till kanalen (snabb spridning), så det kan ta längre tid innan de når kanalen via periodiskt bakgrundsskvaller (långsam spridning).

Tabellbaserad skvallerkanal i Azure

Vi har redan implementerat en skvallerkanal baserad på Azure Tables. Konfigurationen anger standard anslutningssträng som används för Azure-konton. En konfiguration kan till exempel ange två skvallerkanaler med separata Azure-lagringskonton usa och europe på följande sätt:

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

Flera olika tjänster kan använda samma skvallerkanal utan interferens, så länge det ServiceId Guid som anges i respektive konfiguration är distinkt.

Dela via