問題タブ [orleans]

Microsoft Orleans の「Grains」でイベントを SignalR バスに配置する作業を行っています。これを行うサンプル プロジェクトがあり、以下の SignalR 統合にリンクしています。

このサンプルは、Azure の Web ロールと Worker ロールのメタデータを使用して、すべての Web ロールを列挙し、それぞれに明示的にメッセージを発行しているように見えます。SignalR のバックプレーンが Azure Web ロールで適切に構成されている場合、これは必要ではないように思えます。1 つの HubConnection/HubProxy で実行する必要があります。そうですか？

実際、以下にリンクされているファイルをよく見ると、Hub 自体に奇妙なロジックがいくつか見られるので、サンプルが初歩的なバックプレーンとして機能するかどうか疑問に思います。

SignalR の経験が豊富な人がこれを明確にしてくれることを願っています。

SignalR 統合の例: https://orleans.codeplex.com/SourceControl/latest#src/samples/GPSTracker/GPSTracker.GrainImplementation/PushNotifierGrain.cs

私は最近 Orleans プロジェクトに紹介され、現在いくつかの読書と概念実証を行っています。

私が遭遇したほとんどすべての記事とチュートリアルが現在は機能しないという事実に加えて (主に API の変更による)、Orleans SDK のインストールも必要です。ライブラリ、ドキュメント、プロジェクト テンプレートなどが含まれています。

私はそれを「難しい方法」で行うことにし、標準のプロジェクト テンプレート (コンソール アプリケーションとクラス ライブラリ) と NuGet を使用することにしました。Orleans プロジェクト テンプレート ( ) の定型コードの助けを借りてOrleansHostWrapper。

どうすればいいのかわからなかったことが 1 つあります。Grainファクトリ/プロキシを生成しています。Silo を実行すると、次のメッセージが表示されます。

インターフェイスの生成されたファクトリ タイプが見つかりません

誰でもこれを手伝ってもらえますか？Orleans SDK をインストールせずにファクトリを生成する別の方法はありますか?

Azure Service Fabric は、すべてのデータが RAM 内に収まり、永続性がバッキング ストアとして使用されるシナリオに重点を置いているようです。Reliable Services は、ログに記録された情報が RAM に書き込まれるログチェックポイント システムを使用する Reliable Collections に情報を格納するように設計されています。一方、Reliable Actors の場合、既定のアクター状態プロバイダーは "Service Fabric プラットフォームによって提供される分散型の Key-Value ストア" です。これは、同じ制限が適用されることを示しているようです。

ただし、"ホット データ" には Service Fabric を使用し、"コールド データ" を何らかの形式の永続的なストレージに書き込みたい場合があります。この移行を処理するためのベスト プラクティスは何ですか?

Orleans では、Azure テーブルなどの永続ストアを使用して、これが自動的に処理されるようです。しかし、Service Fabric と Reliable Collections の主な設計目的は、外部サービスを必要としないようにして、データの局所性を高めることであるようです。現在のドキュメントでは、障害復旧と分析のためにデータを何らかの永続的なストアに移動する可能性を想定していますが、永続性に支えられたインメモリ アクターとより永続的な形式のストレージの間でデータをやり取りする可能性については説明していません。 .

考えられる答えは、Service Fabric が既にこれを行っているということです。おそらく、Reliable Dictionary には、永続性に裏打ちされたメモリ内ストレージと永続ストレージを切り替えるためのメカニズムが組み込まれています。

あるいは、答えは、自分で管理しなければならないということかもしれません。1 つのアプローチは、アクターがどの程度「ホット」であるかを追跡し、必要に応じて永続ストアを切り替えることです。しかし、これはアクター モデルの利点の 1 つであるアクターの自動割り当てと割り当て解除を犠牲にします。同様に、定期的に Reliable Dictionary からアイテムを削除し、それを他の永続ストアに追加してから、再度追加することもできます。繰り返しになりますが、これには、いつ移行を行うのが理にかなっているかについての知識が必要です。

いくつかの例がこれを具体化するのに役立つかもしれません:

(1) 多くの異なる「部屋」を持つマルチプレイヤー ゲームを実装しているとします。すべてのルームを一度にメモリに格納する必要はありませんが、それらをメモリに移動し、プレイヤーがルームに参加したらバックアップとしてローカル永続性を使用する必要があります。

(2) データベースの一部として追加専用の B ツリーを実装するとします。各 B ツリー ノードをステートフルなアクターにしたくなるでしょう。ホット B ツリーをメモリに残しておきたいのですが、もちろんインデックス全体をメモリに残すことはできません。これは、DocumentDB などで既に実装されているコア シナリオのようですが、ドキュメントからは、これを行う方法が明確ではありません。

私が見つけた関連する質問はこちらです。しかし、その質問は、Azure Service Fabric と外部サービスをいつ使用するかということに焦点を当てています。私の質問は、それらの間で移行する必要があるかどうか、または Azure Service Fabric がここで必要なすべての機能を既に備えているかどうかです。

Orleans では、PlacementStrategy はどのように機能しますか? RandomPlacement、PreferLocalPlacement、ActivationCountBasedPlacement、StatelessWorkerPlacement など、PlacementStrategy の実装がいくつかあることがわかります。

これらの使用方法から実装方法まで、いくつか質問がありますか? 呼び出しが Prefer-Local と RandomPlacement であることを指定するにはどうすればよいですか?

コードを調べていますが、これらの配置戦略に基づいて、ある実行パスと別の実行パスを選択するコードが見つかりません。それはどこで起こりますか？

分散コンピューティング フレームワークとしての実現可能性について、Microsoft Orleansをテストしています。うまくいくようですが、特定のサイロでアクティブな穀物の最大数を設定するにはどうすればよいのでしょうか?

私のグレインは純粋に CPU バウンドではなく、いくつかの IO およびその他の関連タスクを実行します。暴走させると、膨大な数のインスタンスがスピンアップし、全体が動かなくなるのではないかと心配しています。

このようなサイロ構成は可能ですか?