Multiclusterkonfiguration

Die Multiclusterkonfiguration bestimmt, welche Cluster derzeit Teil des Multiclusters sind. Sie ändert sich nicht automatisch, sondern wird durch Operator*innen gesteuert. Daher unterscheidet sie sich erheblich von dem in einem Cluster verwendeten Mitgliedschaftsmechanismus, der automatisch den Satz an Silos bestimmt, die Teil des Clusters sind.

Wir verwenden die folgende Terminologie für die Cluster in einem Dienst:

• Ein Cluster ist aktiv, wenn er mindestens einen aktiven Silo aufweist, andernfalls ist er inaktiv.
• Ein Cluster ist eingebunden, wenn er Teil der aktuellen Multiclusterkonfiguration ist, andernfalls ist er nicht eingebunden.

Die Zustände „aktiv/inaktiv“ sind unabhängig von den Zuständen „eingebunden/nicht eingebunden“: Alle vier Kombinationen sind möglich.

Alle Cluster für einen bestimmten Dienst sind durch ein Gossip-Netzwerk miteinander verbunden. Das Gossip-Netzwerk leitet Konfigurations- und Statusinformationen weiter.

Einfügen einer Konfiguration

Operator*innen geben Konfigurationsänderungen durch Einfügen in das Multiclusternetzwerk aus. Die Konfigurationen können in einen beliebigen Cluster eingefügt und von dort auf alle aktiven Cluster verteilt werden. Jede neue Konfiguration besteht aus einer Liste der Cluster-IDs, die den Multicluster bilden. Sie verfügt auch über einen UTC-Zeitstempel, mit dem ihre Verteilung über das Gossip-Netzwerk nachverfolgt wird.

Zunächst ist die Multiclusterkonfiguration NULL, was bedeutet, dass die Multiclusterliste leer ist (also keine Cluster enthält). Daher müssen Operator*innen zunächst eine Multiclusterkonfiguration einfügen. Nach der Einfügung wird diese Konfiguration in allen verbundenen Silos (während der Ausführung) und in allen angegebenen Gossip-Kanälen (wenn diese Kanäle persistent sind) beibehalten.

Es gibt bei der Einfügung neuer Konfigurationen einige Einschränkungen, auf die Operator*innen achten müssen:

• Jede neue Konfiguration kann Cluster hinzufügen oder Cluster entfernen (aber nicht beides gleichzeitig).
• Operator*innen sollte keine neue Konfiguration ausgeben, während eine vorherige Konfigurationsänderung noch verarbeitet wird.

Diese Einschränkungen stellen sicher, dass Protokolle wie z. B. das Einzelinstanzprotokoll den gegenseitigen Ausschluss von Aktivierungen auch bei Konfigurationsänderungen ordnungsgemäß beibehalten können.

Management-Grain

Multiclusterkonfigurationen können mit dem Orleans-Management-Grain auf jedem Knoten in jedem Cluster eingefügt werden. Um beispielsweise eine Multiclusterkonfiguration einzufügen, die aus den drei Clustern „{ us1, eu1, us2 }“ besteht, können wir eine aufzählbare Zeichenfolge an das Management-Grain übergeben:

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

Das erste Argument für InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) ist eine Auflistung von Cluster-IDs, mit der die neue Multiclusterkonfiguration definiert wird. Das zweite Argument ist eine (optionale) Kommentarzeichenfolge, mit der Konfigurationen mit beliebigen Informationen versehen werden können, z. B. wer sie eingefügt hat und warum.

Es gibt ein optionales drittes Argument, einen booleschen Wert namens checkForLaggingSilosFirst, der standardmäßig auf „true“ festgelegt ist. Das bedeutet, dass das System eine Best-Effort-Prüfung durchführt, um festzustellen, ob es Silos gibt, die noch nicht auf die aktuelle Konfiguration aktualisiert wurden, und die Änderung ablehnt, wenn ein solcher Silo gefunden wird. Dadurch lassen sich Verstöße gegen die Einschränkung erkennen, dass jeweils immer nur eine Konfigurationsänderung ausstehend sein darf (dies kann jedoch nicht unter allen Umständen garantiert werden).

Standardkonfiguration

In Situationen, in denen die Multiclusterkonfiguration im Voraus bekannt ist und die Bereitstellung jedes Mal (zum Testen) neu ist, kann es wünschenswert sein, eine Standardkonfiguration bereitzustellen. Die globale Konfiguration unterstützt das optionale Attribut DefaultMultiCluster, das eine durch Trennzeichen getrennte Liste von Cluster-IDs akzeptiert:

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

Nachdem ein Silo mit dieser Einstellung gestartet wurde, überprüft er, ob die aktuelle Multiclusterkonfiguration NULL ist, und fügt in diesem Fall die angegebene Konfiguration mit dem aktuellen UTC-Zeitstempel ein.

Warnung

Persistente Multicluster-Gossip-Kanäle (basierend auf AzureTable) behalten die letzte eingefügte Konfiguration bei, es sei denn, sie werden explizit gelöscht. In diesem Fall hat die Angabe eines DefaultMultiCluster-Elements keine Auswirkung beim erneuten Bereitstellen eines Clusters, da die in den Gossip-Kanälen gespeicherte Konfiguration nicht NULL ist.

Gossip-Kanal

Operator*innen können die Konfiguration auch direkt in den Gossip-Kanal einfügen. Änderungen im Kanal werden automatisch durch den regelmäßigen Gossip-Hintergrundvorgang aufgenommen und verteilt, obwohl dies möglicherweise sehr langsam vonstatten geht (die Verwendung eines Management-Grains ist viel schneller). Die Verteilungszeit beträgt grob geschätzt 30 Sekunden (bzw. das in der globalen Konfiguration angegebene Gossip-Intervall) mal den binären Logarithmus der Gesamtanzahl der Silos in allen Clustern. Da die Gossip-Paare jedoch zufällig ausgewählt werden, können sie sowohl viel schneller als auch viel langsamer sein.

Bei Verwendung des tabellenbasierten Azure-Gossip-Kanals können Operator*innen eine neue Konfiguration einfach einfügen, indem sie mit einem beliebigen Tool zum Bearbeiten von Daten in Azure-Tabellen den Konfigurationsdatensatz in der OrleansGossipTable bearbeiten. Der Konfigurationsdatensatz weist das folgende Format auf:

Name	type	Wert
PartitionKey	String	die ServiceId
RowKey	String	„CONFIG“
Cluster	String	durch Trennzeichen getrennte Liste der Cluster-IDs, z. B. „us1,eu1,us2“
Kommentar	String	optionaler Kommentar
GossipTimestamp	Datetime	UTC-Zeitstempel für die Konfiguration

Hinweis

Beim Bearbeiten dieses Datensatzes im Speicher muss das GossipTimestamp-Element auch auf einen neueren Wert als den vorhandenen festgelegt werden (andernfalls wird die Änderung ignoriert). Die bequemste und empfohlene Möglichkeit hierfür besteht darin, das Feld GossipTimestamp zu löschen – unsere Implementierung des Gossip-Kanals ersetzt es dann automatisch durch einen korrekten, aktuellen Zeitstempel (unter Verwendung des Azure-Tabellenzeitstempels).

Clusterverfahren

Das Hinzufügen oder Entfernen eines Clusters in den bzw. aus dem Multicluster muss häufig in einem größeren Kontext koordiniert werden. Es wird empfohlen, beim Hinzufügen/Entfernen von Clustern in den bzw. aus dem Multicluster immer die unten beschriebenen Verfahren zu befolgen.

Verfahren zum Hinzufügen eines Clusters

1. Starten Sie einen neuen Orleans-Cluster, und warten Sie, bis alle Silos ausgeführt werden.
2. Fügen Sie eine Konfiguration ein, die den neuen Cluster enthält.
3. Starten Sie die Weiterleitung von Benutzeranforderungen an den neuen Cluster.

Verfahren zum Entfernen eines Clusters

1. Beenden Sie die Weiterleitung neuer Benutzeranforderungen an den Cluster.
2. Fügen Sie eine Konfiguration ein, die den Cluster nicht mehr enthält.
3. Beenden Sie alle Silos des Clusters.

Nachdem ein Cluster auf diese Weise entfernt wurde, kann er mithilfe des Verfahrens zum Hinzufügen eines neuen Clusters erneut hinzugefügt werden.

Aktivität in nicht eingebundenen Clustern

Es kann kurze, temporäre Zeiträume geben, in denen ein Cluster sowohl aktiv als auch nicht eingebunden ist:

• Ein frisch gestarteter Cluster beginnt möglicherweise schon mit dem Ausführen von Code, bevor er sich in der Multiclusterkonfiguration befindet (zwischen den Schritten 1 und 2 des Verfahrens zum Hinzufügen eines Clusters).
• Ein Cluster, der außer Betrieb genommen wird, kann weiterhin Code ausführen, bevor die Silos heruntergefahren werden (zwischen den Schritten 2 und 3 des Verfahrens zum Entfernen eines Clusters).

In solchen vorübergehenden Situationen ist Folgendes möglich:

• Globale Grains mit einer einzigen Instanz: Ein Grain kann eine doppelte Aktivierung in einem nicht eingebundenen Cluster aufweisen.
• Grains mit Versionsverwaltung: Aktivierungen in nicht eingebundenen Cluster erhalten keine Benachrichtigungen, wenn sich der Zustand des Grains ändert.