Teilen über


Kommunikation in mehreren Clustern

Das Netzwerk muss so konfiguriert sein, dass jedes Orleans-Silo sich mit jedem anderen Orleans-Silo über TCP/IP verbinden kann, und zwar unabhängig von seinem Speicherort auf der Welt. Wie dies genau erreicht wird, liegt nicht im Einflussbereich von Orleans, da es davon abhängt, wie und wo Silos bereitgestellt sind.

In Windows Azure können wir beispielsweise mithilfe von VNets mehrere Bereitstellungen in einer Region miteinander verbinden und VNets mit Gateways in verschiedenen Regionen miteinander verbinden.

Clusterbezeichner

Jeder Cluster hat eine eigene eindeutige Cluster-ID, die in der globalen Konfiguration angegeben werden muss.

Cluster-IDs dürfen nicht leer sein und keine Kommas enthalten. Bei Verwenden von Azure Table Storage dürfen Cluster-IDs auch keine der für Zeilenschlüssel unzulässigen Zeichen (/, , #, ?) enthalten.

Es werden sehr kurze Zeichenfolgen für die Cluster-IDs empfohlen, da Cluster-IDs häufig übertragen werden und möglicherweise von einigen Anbietern von Protokollansichten im Speicher gespeichert werden.

Clustergateways

Jeder Cluster legt automatisch eine Teilmenge seiner aktiven Silos fest, die als Clustergateways dienen sollen. Clustergateways kündigen ihre IP-Adressen anderen Clustern direkt an und können somit als Erstkontaktpunkte dienen. Standardmäßig werden höchstens 10 Silos (oder eine beliebige als MaxMultiClusterGateways konfiguriert Anzahl) als Clustergateways festgelegt.

Kommunikation zwischen Silos in verschiedenen Clustern erfolgt nicht immer über ein Gateway. Sobald ein Silo den Speicherort einer Grain-Aktivierung (unabhängig vom Cluster) kennt und zwischengespeichert hat, sendet es Nachrichten direkt an dieses Silo, auch wenn das Silo kein Clustergateway ist.

Gossip

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

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

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

Schnelle und langsame Weitergabe. Wenn ein Gateway seinen Status ändert oder ein Operator eine neue Konfiguration einfügt, wird diese Gossip-Information sofort an alle Silos, Cluster und Gossip-Kanäle gesendet. Dies geschieht schnell, ist aber nicht zuverlässig. Sollte die Nachricht aus irgendwelchen Gründen verloren gehen (z. B. Race-Bedingungen, defekte Sockets, Siloausfälle), sorgt unser regelmäßiger Gossip im Hintergrund dafür, dass die Informationen schließlich weitergegeben werden, wenn auch langsamer. Alle Informationen werden schließlich überall weitergegeben und sind gegen gelegentliche Nachrichtenverluste und -fehler äußerst resilient.

Alle Gossip-Daten werden mit Zeitstempel versehen, wodurch sichergestellt ist, dass neuere Informationen ältere Informationen unabhängig vom relativen Zeitpunkt von Nachrichten ersetzen. Beispielsweise ersetzen neuere Konfigurationen mit mehreren Clustern ältere, und neuere Informationen zu einem Gateway ersetzen ältere Informationen zu diesem Gateway. Weitere Details zur Darstellung von Gossip-Daten finden Sie in den Informationen zur MultiClusterData-Klasse. Sie verfügt über eine Merge-Methode, die Gossip-Daten kombiniert und Konflikte anhand von Zeitstempeln auflöst.

Gossip-Kanäle

Wenn ein Silo erstmals gestartet oder nach einem Ausfall neu gestartet wird, muss es über eine Möglichkeit verfügen, für den Gossip ein Bootstrapping durchzuführen. Dies ist Aufgabe des Gossip-Kanals, der in der Silokonfiguration konfiguriert werden kann. Beim Start ruft ein Silo alle Informationen aus den Gossip-Kanälen ab. Nach dem Start führt ein Silo regelmäßig (alle 30 Sekunden oder entsprechend dem für BackgroundGossipInterval konfigurierten Wert) einen Gossip-Vorgang durch. Dabei werden jedes Mal seine Gossip-Informationen mit einem Partner synchronisiert, der zufällig aus allen Clustergateways und Gossip-Kanälen ausgewählt wird.

  • Obwohl nicht unbedingt erforderlich, empfehlen wir stets die Konfiguration von mindestens zwei Gossip-Kanälen in unterschiedlichen Regionen, um bessere Verfügbarkeit zu gewährleisten.
  • Die Latenz der Kommunikation mit Gossip-Kanälen ist nicht kritisch.
  • Mehrere unterschiedliche Dienste können denselben Gossip-Kanal nutzen, ohne sich gegenseitig zu stören, solange die ServiceId Guid (wie in der jeweiligen Konfiguration angegeben) eindeutig ist.
  • Es ist nicht zwingend erforderlich, dass alle Silos die gleichen Gossip-Kanäle verwenden, solange die Kanäle ausreichen, um ein Silo beim Start mit der „Gossip-Community“ zu verbinden. Wenn jedoch ein Gossip-Kanal nicht Teil der Konfiguration eines Silos ist und dieses Silo ein Gateway ist, überträgt es seine Statusaktualisierungen nicht an den Kanal (schnelle Weitergabe), sodass es länger dauern kann, ehe diese den Kanal über regelmäßige Gossip-Vorgänge im Hintergrund erreichen (langsame Weitergabe).

Auf Azure-Tabellen basierender Gossip-Kanal

Wir haben bereits einen auf Azure-Tabellen basierenden Gossip-Kanal implementiert. Die Konfiguration gibt standardmäßige Verbindungszeichenfolgen an, die für Azure-Konten verwendet werden. In einer Konfiguration können Sie beispielsweise 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 unterschiedliche Dienste können denselben Gossip-Kanal nutzen, ohne sich gegenseitig zu stören, solange die ServiceId Guid (wie in der jeweiligen Konfiguration angegeben) eindeutig ist.