Comunicazione multi-cluster

La rete deve essere configurata in modo che qualsiasi silo Orleans possa connettersi a qualsiasi altro silo Orleans tramite TCP/IP, indipendentemente dal punto in cui si trova nel mondo. Come si ottiene esattamente questo risultato non rientra nell'ambito di Orleans, perché dipende da come e dove vengono distribuiti i silo.

Ad esempio, in Windows Azure è possibile usare le reti virtuali per connettere più distribuzioni all'interno di un'area e i gateway per connettere le reti virtuali tra aree diverse.

Identificatore del cluster

Ogni cluster ha un proprio ID cluster univoco. L'ID cluster deve essere specificato nella configurazione globale.

Gli ID cluster non possono essere vuoti, né contenere virgole. Inoltre, se si usa Archiviazione tabelle di Azure, gli ID cluster potrebbero non contenere i caratteri non consentiti per le chiavi di riga (/, , #, ?).

È consigliabile usare stringhe molto brevi per gli ID cluster, perché gli ID cluster vengono trasmessi di frequente e possono essere archiviati nell'archiviazione da alcuni provider di visualizzazione log.

Gateway del cluster

Ogni cluster designa automaticamente un subset dei relativi silo attivi da usare come gateway del cluster. I gateway del cluster annunciano direttamente gli indirizzi IP ad altri cluster e possono quindi fungere da "punti del primo contatto". Per impostazione predefinita, al massimo 10 silo (o qualsiasi numero sia configurato come MaxMultiClusterGateways) sono designati come gateway del cluster.

La comunicazione tra silo in cluster diversi non passa sempre attraverso un gateway. Dopo che un silo ha appreso e memorizzato nella cache la posizione di un'attivazione granulare (indipendentemente dal cluster), invia direttamente messaggi a tale silo, anche se il silo non è un gateway del cluster.

Gossip

Gossip è un meccanismo che consente ai cluster di condividere informazioni di configurazione e stato. Come suggerisce il nome, gossip è decentralizzato e bidirezionale: ogni silo comunica direttamente con altri silo, sia nello stesso cluster che in altri cluster, per scambiare informazioni in entrambe le direzioni.

Contenuto. Gossip contiene alcune o tutte le informazioni seguenti:

• Configurazione multi-cluster con timestamp corrente.
• Dizionario che contiene informazioni sui gateway del cluster. La chiave è l'indirizzo del silo e il valore contiene (1) un timestamp, (2) l'ID cluster e (3) uno stato, attivo o inattivo.

Propagazione veloce e lenta. Quando un gateway modifica lo stato o quando un operatore inserisce una nuova configurazione, queste informazioni di gossip vengono inviate immediatamente a tutti i silo, i cluster e i canali di gossip. Questo avviene velocemente, ma non è affidabile. Se il messaggio andrà perso a causa di qualsiasi motivo (ad esempio, gare, socket interrotti, errori di silo), il nostro gossip periodico di sfondo garantisce che le informazioni alla fine si diffondano, anche se più lentamente. Tutte le informazioni vengono propagate ovunque ed è altamente resiliente a occasionali perdite ed errori dei messaggi.

Tutti i dati di gossip vengono sottoposti a timestamp, cosa che garantisce che le informazioni più recenti sostituiscano le informazioni meno recenti indipendentemente dalla tempistica relativa dei messaggi. Ad esempio, le configurazioni multi-cluster più recenti sostituiscono quelle meno recenti e le informazioni più recenti su un gateway sostituiscono le informazioni meno recenti sul gateway. Per altri dettagli sulla rappresentazione dei dati di gossip, vedere la classe MultiClusterData. Dispone di un metodo Merge che combina i dati di gossip, risolvendo i conflitti che usano i timestamp.

Canali Gossip

Quando un silo viene avviato per la prima volta o quando viene riavviato dopo un errore, deve avere un modo per avviare il gossip. Si tratta del ruolo del canale gossip, che può essere configurato nella configurazione silo. All'avvio, un silo recupera tutte le informazioni dai canali di gossip. Dopo l'avvio, un silo mantiene periodicamente il gossiping, ogni 30 secondi, o qualsiasi elemento configurato come BackgroundGossipInterval. Ogni volta sincronizza le informazioni sul gossip con un partner selezionato in modo casuale da tutti i gateway del cluster e i canali di gossip.

• Anche se non è strettamente richiesto, è consigliabile configurare sempre almeno due canali di gossip, in aree distinte, per una migliore disponibilità.
• La latenza della comunicazione con i canali di gossip non è fondamentale.
• Più servizi diversi possono usare lo stesso canale gossip senza interferenze, purché il ServiceId Guid (come specificato dalla rispettiva configurazione) sia distinto.
• Non è necessario che tutti i silos utilizzino gli stessi canali di gossip, purché i canali siano sufficienti per consentire a un silos di connettersi inizialmente con la "community di gossiping" quando viene avviato. Tuttavia, se un canale gossip non fa parte della configurazione di un silo e tale silo è un gateway, non esegue il push degli aggiornamenti dello stato nel canale (propagazione rapida), quindi potrebbe richiedere più tempo prima che questi raggiungano il canale tramite gossip periodico in background (propagazione lenta).

Canale gossip basato su tabelle di Azure

È già stato implementato un canale gossip basato su tabelle di Azure. La configurazione specifica le stringhe di connessione standard usate per gli account Azure. Ad esempio, una configurazione può specificare due canali gossip con account di archiviazione di Azure separati usa e europe come indicato di seguito:

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

Più servizi diversi possono usare lo stesso canale di gossip senza interferenze, purché il ServiceId Guid specificato dalla rispettiva configurazione sia distinto.