Configurazione multi-cluster

La configurazione multi-cluster determina quali cluster fanno attualmente parte del multi-cluster. Non cambia automaticamente, ma è controllato dall'operatore. Di conseguenza, è molto diverso dal meccanismo di appartenenza usato all'interno di un cluster, che determina automaticamente il set di silo che fanno parte del cluster.

Per i cluster in un servizio viene usata la terminologia seguente:

• Un cluster è attivo se ha almeno un silo attivo e inattivo in caso contrario.
• Un cluster viene aggiunto se fa parte della configurazione multi-cluster corrente e non aggiunto in caso contrario.

Essere attivi/inattivi è indipendente dall'essere unito/non unito: tutte e quattro le combinazioni sono possibili.

Tutti i cluster per un determinato servizio sono connessi da una rete gossip. La rete gossip propaga le informazioni di configurazione e stato.

Inserire una configurazione

Un operatore genera modifiche alla configurazione inserendole nella rete multi-cluster. Le configurazioni possono essere inserite in qualsiasi cluster e distribuite da questa posizione a tutti i cluster attivi. Ogni nuova configurazione è costituita da un elenco di ID cluster che formano il multi-cluster. Ha anche un timestamp UTC usato per tenere traccia della propagazione tramite la rete gossip.

Inizialmente, la configurazione multi-cluster è null, il che significa che l'elenco di più cluster è vuoto (non contiene cluster). Pertanto, l'operatore deve inserire inizialmente una configurazione multi-cluster. Una volta inserita, questa configurazione viene mantenuta in tutti i silo connessi (durante l'esecuzione) e in tutti i canali gossip specificati (se tali canali sono persistenti).

Vengono applicate alcune restrizioni all'inserimento di nuove configurazioni che un operatore deve seguire:

• Ogni nuova configurazione può aggiungere più cluster o rimuovere alcuni cluster (ma non entrambi contemporaneamente).
• Un operatore non deve emettere una nuova configurazione mentre è ancora in corso l'elaborazione di una modifica di configurazione precedente.

Queste restrizioni assicurano che i protocolli, ad esempio il protocollo a istanza singola, possano mantenere correttamente l'esclusione reciproca delle attivazioni anche in caso di modifiche alla configurazione.

Granularità di gestione

Le configurazioni multi-cluster possono essere inserite in qualsiasi nodo di qualsiasi cluster, usando la granularità di gestione Orleans. Ad esempio, per inserire una configurazione multi-cluster costituita dai tre cluster { us1, eu1, us2 }, è possibile passare una stringa enumerabile alla granularità di gestione:

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

Il primo argomento di InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) è una raccolta di ID cluster, che definirà la nuova configurazione multi-cluster. Il secondo argomento è una stringa di commento (facoltativa) che può essere usata per contrassegnare le configurazioni con informazioni arbitrarie, ad esempio chi li ha inseriti e perché.

Esiste un terzo argomento facoltativo, un valore booleano denominato checkForLaggingSilosFirst, che per impostazione predefinita è true. Ciò significa che il sistema esegue un controllo ottimale per verificare se sono presenti silo in qualsiasi punto in cui non sono ancora stati rilevati fino alla configurazione corrente e rifiuta la modifica se trova tale silo. Ciò consente di rilevare violazioni della restrizione che prevede una sola modifica di configurazione alla volta (anche se non può essere garantita in tutte le circostanze).

Configurazione predefinita

Nelle situazioni in cui la configurazione multi-cluster è nota in anticipo e la distribuzione è aggiornata ogni volta (per i test), è possibile specificare una configurazione predefinita. La configurazione globale supporta un attributo DefaultMultiCluster facoltativo che accetta un elenco delimitato da virgole di ID cluster:

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

Dopo che un silo è stato avviato con questa impostazione, verifica se la configurazione multi-cluster corrente è null e, in tal caso, inserisce la configurazione specificata con il timestamp UTC corrente.

Avviso

I canali gossip multi-cluster persistenti (basati su AzureTable) mantengono l'ultima configurazione inserita, a meno che non vengano eliminati in modo esplicito. In tal caso, la specifica di un oggetto DefaultMultiCluster non ha alcun effetto durante la ri-distribuzione di un cluster perché la configurazione archiviata nei canali gossip non è Null.>

Canale Gossip

Un operatore può anche inserire la configurazione direttamente nel canale gossip. Le modifiche nel canale vengono prelevate e propagate automaticamente dal gossip di background periodico, anche se probabilmente molto lentamente (l'uso del grano di gestione è molto più veloce). Una stima approssimativa sul tempo di propagazione è di 30 secondi (o qualsiasi intervallo di gossip specificato nella configurazione globale) moltiplicato per il logaritmo binario del numero totale di silo in tutti i cluster. Tuttavia, poiché le coppie di gossip vengono selezionate in modo casuale, possono essere molto più veloci o molto più lente.

Se si usa il canale gossip basato su tabelle di Azure, gli operatori possono inserire una nuova configurazione semplicemente modificando il record di configurazione in OrleansGossipTable, usando alcuni strumenti per la modifica dei dati nelle tabelle di Azure. Il record di configurazione ha il formato seguente:

Nome	Type	Valore
PartitionKey	String	ServiceId
RowKey	String	"CONFIG"
Clusters (Cluster)	String	elenco delimitato da virgole di ID cluster, ad esempio "us1,eu1,us2"
Commento	String	Commento facoltativo
GossipTimestamp	Data/Ora	Timestamp UTC per la configurazione

Nota

Quando si modifica questo record nella risorsa di archiviazione, è necessario impostare anche GossipTimestamp su un valore più recente rispetto a quello attualmente presente (in caso contrario la modifica viene ignorata). Il modo più pratico e consigliato per eseguire questa operazione consiste nell'eliminare il campoGossipTimestamp. L'implementazione del canale gossip lo sostituisce poi automaticamente con un timestamp corretto e corrente (usa il timestamp tabella di Azure).

Procedure del cluster

L'aggiunta o la rimozione di un cluster dal multi-cluster spesso deve essere coordinata all'interno di un contesto più ampio. È consigliabile seguire sempre le procedure descritte di seguito quando si aggiungono/rimuovono cluster dal multi-cluster.

Procedura per l'aggiunta di un cluster

1. Avviare un nuovo cluster Orleans e attendere che tutti i silo siano operativi.
2. Inserire una configurazione contenente il nuovo cluster.
3. Avviare il routing delle richieste utente al nuovo cluster.

Procedura per la rimozione di un cluster

1. Arrestare il routing delle nuove richieste utente al cluster.
2. Inserire una configurazione che non contiene più il cluster.
3. Arrestare tutti i silo del cluster.

Dopo aver rimosso un cluster in questo modo, è possibile aggiungerlo nuovamente seguendo la procedura per l'aggiunta di un nuovo cluster.

Attività in cluster non aggiunti

Possono essere presenti brevi periodi temporanei in cui un cluster è attivo e non aggiunto:

• Un cluster appena avviato può iniziare a eseguire il codice prima di trovarsi nella configurazione multi-cluster (tra i passaggi 1 e 2 della procedura per l'aggiunta di un cluster)
• Un cluster che viene rimosso può comunque eseguire codice prima dell'arresto dei silo (tra i passaggi 2 e 3 della procedura per la rimozione di un cluster).

Durante queste situazioni intermedie, sono possibili le operazioni seguenti:

• Per i grani a istanza singola globale: una granularità può avere un'attivazione duplicata in un cluster non aggiunto.
• Per i grani con controllo delle versioni: le attivazioni nei cluster non aggiunti non ricevono notifiche quando cambia lo stato di granularità.