次の方法で共有

マルチクラスター通信

ネットワークを構成して、 Orleans サイロが世界中のどこにあるかに関係なく、TCP/IP 経由で他の Orleans サイロに接続できるようにする必要があります。 これを実現する方法は、サイロをデプロイする方法と場所によって異なるため、 Orleansの範囲外です。

たとえば、Azure では、VNet を使用してリージョン内の複数のデプロイを接続し、ゲートウェイを使用して異なるリージョン間で VNet を接続できます。

クラスター識別子

各クラスターには、独自の一意のクラスター ID があります。 グローバル構成でクラスター ID を指定する必要があります。

クラスター ID を空にすることはできず、コンマを含めることもできません。 また、Azure Table Storage を使用する場合、クラスター ID に行キー (/、、#、?) に対して禁止されている文字を含めることはできません。

クラスター ID は頻繁に送信され、一部のログ ビュー プロバイダーによってストレージに格納される可能性があるため、クラスター ID には非常に短い文字列を使用することをお勧めします。

クラスター ゲートウェイ

各クラスターは、クラスター ゲートウェイとして機能するアクティブなサイロのサブセットを自動的に指定 します。 クラスター ゲートウェイは、IP アドレスを他のクラスターに直接アドバタイズするため、"最初の連絡先" として機能します。 既定では、 Orleans は最大 10 個のサイロ (または MaxMultiClusterGatewaysとして構成された数) をクラスター ゲートウェイとして指定します。

異なるクラスター内のサイロ間の通信は、必ずしもゲートウェイを通過するとは 限りません 。 サイロは、(クラスターに関係なく) グレイン アクティブ化の場所を学習してキャッシュすると、ターゲット サイロがクラスター ゲートウェイではない場合でも、そのサイロに直接メッセージを送信します。

ゴシップ

Gossip は、クラスターが構成と状態情報を共有するためのメカニズムです。 名前が示すように、ゴシップは分散型で双方向です。各サイロは他のサイロ (同じクラスターと他のクラスターの両方) と直接通信し、双方向で情報を交換します。

コンテンツ: Gossip には、次の情報の一部またはすべてが含まれています。

  • 現在のタイムスタンプ付き マルチクラスター構成。
  • クラスター ゲートウェイに関する情報を含むディクショナリ。 キーはサイロ アドレスであり、値には (1) タイムスタンプ、(2) クラスター ID、および (3) 状態 (アクティブまたは非アクティブ) が含まれます。

高速で低速な伝達: ゲートウェイの状態が変更されたとき、またはオペレーターが新しい構成を挿入すると、このゴシップ情報はすぐにすべてのサイロ、クラスター、およびゴシップ チャネルに送信されます。 これはすぐに発生しますが、信頼できません。 何らかの理由でメッセージが消失した場合（レース、壊れたソケット、サイロの障害など）、定期的なバックグラウンドゴシップによって情報が広がり続け、より遅いペースで広がります。 すべての情報は最終的にあらゆる場所に伝達され、メッセージの損失や失敗に対する回復性が高くなります。

すべてのゴシップ データにタイムスタンプが付けられます。 これにより、メッセージの相対的なタイミングに関係なく、新しい情報が古い情報に置き換えられます。 たとえば、新しいマルチクラスター構成では古いものが置き換えられ、ゲートウェイに関する新しい情報は、そのゲートウェイに関する古い情報に置き換えられます。 ゴシップ データの表現の詳細については、 MultiClusterData クラスを参照してください。 これには、タイムスタンプを使用して競合を解決する、gossip データを組み合わせた Merge メソッドがあります。

ゴシップ チャンネル

サイロが最初に開始されたとき、または障害が発生した後に再起動する場合は、 ゴシップをブートストラップする方法が必要です。 これは、サイロ構成で構成できるゴシップ チャネルの役割です。 起動時に、サイロはゴシップ チャネルからすべての情報を取得します。 スタートアップ後、サイロは情報を共有し続けます。これは30秒ごとに（またはBackgroundGossipIntervalで設定された間隔で）行われます。 毎回、すべてのクラスター ゲートウェイとゴシップ チャネルからランダムに選択されたパートナーとゴシップ情報が同期されます。

  • 厳密には必須ではありませんが、可用性を向上するために、常に少なくとも 2 つのゴシップ チャネルを個別のリージョンに構成することをお勧めします。
  • ゴシップ チャネルとの通信の待機時間は重要ではありません。
  • 複数の異なるサービスは、(それぞれの構成で指定された) ServiceIdGuid が異なる限り、干渉なしで同じゴシップ チャネルを使用できます。
  • すべてのサイロが同じゴシップ チャネルを使用するという厳密な要件はありません。開始時にサイロが最初に "ゴシップ コミュニティ" に接続できるように、チャネルで十分である限りです。 ただし、ゴシップ チャネルがサイロの構成の一部ではなく、そのサイロがゲートウェイである場合、そのチャネルに状態の更新はプッシュされません (高速伝達)。 そのため、これらの更新が定期的なバックグラウンド ゴシップ (低速伝達) を介してチャネルに到達するまでに時間がかかる場合があります。

Azure Table に基づくゴシップチャネル

Azure Tables に基づくゴシップ チャネルを実装しました。 この構成では、Azure アカウントに使用される標準の接続文字列を指定します。 たとえば、構成では、次のように、 usa と europe 別の Azure ストレージ アカウントを持つ 2 つのゴシップ チャネルを指定できます。

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

複数の異なるサービスは、それぞれの構成で指定された ServiceIdGuid が異なる限り、干渉なしで同じゴシップ チャネルを使用できます。