次の方法で共有


マルチクラスター通信

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

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

クラスター識別子

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

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

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

クラスター ゲートウェイ

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

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

ゴシップ

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

Content。 ゴシップには、次の情報の一部またはすべてが含まれています。

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

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

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

ゴシップ チャネル

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

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

Azure テーブルベースのゴシップ チャネル

Azure テーブルに基づくゴシップ チャネルは既に実装されています。 構成では、Azure アカウントに使用される標準の接続文字列が指定されます。 たとえば、構成では、次のように個別の Azure ストレージ アカウント usa および europe を持つ 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=...")
        });
    })

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