Freigeben über

Multiclusterkommunikation

Sie müssen das Netzwerk so konfigurieren, dass jeder Orleans Silo über TCP/IP eine Verbindung zu jedem anderen Orleans Silo herstellen kann, unabhängig davon, wo er sich in der Welt befindet. Genau, wie Sie dies erreichen, liegt außerhalb des Umfangs von Orleans, da es davon abhängt, wie und wo Sie die Silos bereitstellen.

Beispielsweise können Sie in Azure VNets verwenden, um mehrere Bereitstellungen in einer Region und Gateways zu verbinden, um VNets in verschiedenen Regionen zu verbinden.

Clusterbezeichner

Jeder Cluster verfügt über eine eigene eindeutige Cluster-ID. Sie müssen die Cluster-ID in der globalen Konfiguration angeben.

Cluster-IDs dürfen nicht leer sein und dürfen keine Kommas enthalten. Wenn Sie Azure Table Storage verwenden, können Cluster-IDs keine Zeichen enthalten, die für Zeilenschlüssel (/, , #, ?) verboten sind.

Es wird empfohlen, sehr kurze Zeichenfolgen für Cluster-IDs zu verwenden, da sie häufig übertragen werden und möglicherweise von einigen Protokollansichtsanbietern im Speicher gespeichert werden.

Clustergateways

Jeder Cluster bezeichnet automatisch eine Teilmenge seiner aktiven Silos, die als Clustergateways dienen sollen. Clustergateways kündigen direkt ihre IP-Adressen bei anderen Clustern an und können somit als "erste Anlaufstellen" dienen. Legt standardmäßig Orleans höchstens 10 Silos (oder die Zahl, die als MaxMultiClusterGateways konfiguriert ist) als Clustergateways fest.

Die Kommunikation zwischen Silos in verschiedenen Clustern verläuft nicht immer über ein Gateway. Sobald ein Silo den Standort einer Kornaktivierung (unabhängig vom Cluster) lernt und zwischenspeichert, sendet es Nachrichten direkt an dieses Silo, auch wenn das Zielsilos kein Clustergateway ist.

Klatsch

Gossip ist ein Mechanismus für Cluster zum Freigeben von Konfigurations- und Statusinformationen. Wie der Name schon sagt, ist Gossip dezentralisiert und bidirektional: Jedes Silo kommuniziert direkt mit anderen Silos (sowohl im selben Cluster als auch in anderen Clustern), um Informationen in beide Richtungen auszutauschen.

Inhalt: Gossip enthält einige oder alle der folgenden Informationen:

  • Die aktuelle mit Zeitstempel versehene Multi-Cluster-Konfiguration.
  • Ein Wörterbuch, das Informationen zu Clustergateways enthält. Der Schlüssel ist die Siloadresse, und der Wert enthält (1) einen Zeitstempel, (2) die Cluster-ID und (3) einen Status (entweder aktiv oder inaktiv).

Schnelle und langsame Verteilung: Wenn ein Gateway seinen Status ändert oder wenn ein Operator eine neue Konfiguration einfüge, werden diese Gossip-Informationen sofort an alle Silos, Cluster und Gossip-Kanäle gesendet. Dies geschieht schnell, ist aber nicht zuverlässig. Wenn die Nachricht aus irgendeinem Grund verloren geht (z. B. Rennen, defekte Sockets, Silofehler), sorgt der regelmäßige Hintergrund gossip dafür, dass sich die Informationen schließlich verbreiten, wenn auch langsamer. Alle Informationen verbreiten sich schließlich überall und sind sehr robust für gelegentliche Nachrichtenverluste und -fehler.

Alle Gossip-Daten werden zeitstempelt. Dadurch wird sichergestellt, dass aktuelle Informationen ältere Informationen unabhängig von den relativen zeitlichen Abläufen von Nachrichten ersetzen. Neuere Multiclusterkonfigurationen ersetzen beispielsweise ältere Konfigurationen, und neuere Informationen zu einem Gateway ersetzen ältere Informationen zu diesem Gateway. Weitere Informationen zur Darstellung von Gossip-Daten finden Sie in der MultiClusterData Klasse. Es verfügt über eine Merge Methode, die Gossip-Daten kombiniert und Konflikte mithilfe von Zeitstempeln löst.

Gossip-Kanäle

Wenn ein Silo zum ersten Mal gestartet wird oder nach einem Fehler neu gestartet wird, benötigt es eine Möglichkeit, das Gossip-Verteilungssystem zu initialisieren. Dies ist die Rolle des Gossip-Kanals, den Sie in der Silokonfiguration konfigurieren können. Beim Start ruft ein Silo alle Informationen aus den Gerüchtekanälen ab. Nach dem Start sendet ein Silo alle 30 Sekunden (oder in dem als BackgroundGossipInterval konfigurierten Intervall) weiterhin periodische Signale. Jedes Mal synchronisiert es seine Gossip-Informationen mit einem Partner, der zufällig aus allen Clustergateways und Gossip-Kanälen ausgewählt wurde.

  • Obwohl nicht unbedingt erforderlich, empfehlen wir, immer mindestens zwei Gossip-Kanäle in unterschiedlichen Regionen für eine bessere Verfügbarkeit zu konfigurieren.
  • Die Latenz der Kommunikation mit Gossip-Kanälen ist nicht wichtig.
  • Mehrere verschiedene Dienste können den gleichen Gossip-Kanal ohne Störungen verwenden, solange die ServiceIdGuid (in ihren jeweiligen Konfigurationen angegeben) unterschiedlich ist.
  • Es gibt keine strikte Anforderung, dass alle Silos dieselben Gossip-Kanäle verwenden, solange die Kanäle ausreichen, um beim Start des Silos die Verbindung mit der "Gossiping-Community" herzustellen. Wenn ein Gossip-Kanal jedoch nicht Teil der Konfiguration eines Silos ist und es sich bei diesem Silo um ein Gateway handelt, verschiebt er seine Statusaktualisierungen nicht an diesen Kanal (schnelle Verteilung). Daher kann es länger dauern, bis diese Updates den Kanal über regelmäßige Hintergrundgerüchte (langsame Weiterleitung) erreichen.

Azure-Tabellen-basierter Gossip-Kanal

Wir haben einen Gossip-Kanal basierend auf Azure Tables implementiert. Die Konfiguration gibt standardverbindungszeichenfolgen an, die für Azure-Konten verwendet werden. Beispielsweise könnte eine Konfiguration zwei Gossip-Kanäle mit separaten Azure-Speicherkonten usa und europe wie folgt angeben:

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

Mehrere verschiedene Dienste können denselben Gossip-Kanal ohne Störung nutzen, solange sie in ihren jeweiligen Konfigurationen unterschiedliche ServiceIdGuid angeben.