問題タブ [azure-service-fabric]

Azure で Docker ベースのアプリケーション サービスをスケーリングする最良の方法は何ですか。AWS では、コンテナ サービスを使用できることを知っています。現在、Azure で Cloud Service を使用しているため、簡単にスケーリングできます。クラウドサービスより良さそうなService Fabricもあります。しかし、docker を使用する場合、それらを複数の VM にスケーリングするにはどうすればよいでしょうか?

簡単な例を見てみましょう。1,000,000 人のユーザーを持つサービスがあり、各ユーザーにはいくつかのプロファイル情報があります。アクターを使用して、このプロファイル情報に対する CRUD 操作を管理したいと考えています。

Project Orleansでは、ユーザーごとに 1 つのグレインがあり、同じアクター タイプ (使用された場合にのみ作成される) の 1,000,000 の仮想グレインがあり、各グレインは、その中に格納されている単一のユーザーのプロファイル情報を管理します。州。ユーザーが増えるにつれて、グレインの数も増えます。

Service Fabricでは、ドキュメントを正しく解釈すると、動作が少し異なります。すべてのユーザーに対する CRUD 操作を管理するステートフルなアクター タイプを用意し、スケーラビリティのためにアクターをパーティション分割して、各パーティションにユーザー データのサブセットに対する責任を与えます。パーティション オプションを考えると、Project Orleans と同じようにきめ細かく実装する明確な方法がわかりません。

Project Orleans のアプローチがとても気に入っています。アクターは 1 人のユーザーのデータを処理しているだけであり、スケーラビリティは明らかです (ユーザーが多いほど粒度が高くなります)。メモリ モデルも単純です。単一のアクターが少量の状態でオンデマンドでハイドレートされます。

Service Fabric の実装はもう少し複雑になるようです。各アクターは一連のユーザーを処理します。スケーラビリティのために、作成するパーティションの数を事前に決定する必要があります。これは後で変更できないためです。メモリ モデルに関しては、各アクターが管理するデータの量は、ユーザーの数が増えるにつれて増加します。

私の質問は次のとおりです。Service Fabric のアクターは Project Orleans よりも単純に粗粒度であるという私の理解は正しいですか?

アップデート

答えてくれてありがとう。私の間違いは、パーティションには、パーティション内のすべてのアクター ID の状態を格納および管理する単一のアクター インスタンスが含まれていると考えていたことです。これは完全に間違っています。Michiel は、パーティションには複数のアクター インスタンス (アクター ID ごとに 1 つ) が含まれていると指摘しています。したがって、アクターは Project Orleans と同じ方法で実装できます。これは今でははるかに理にかなっています、ありがとう。

Service-Fabric のステートフル サービスで次のメソッドを使用しています。サービスにはパーティションがあります。この平和なコードから FabricNotReadableException が発生することがあります。

これは、パーティションがダウンしており、移動中であることを意味しますか? その中で、セカンダリ パーティションにヒットしますか? 場合によっては発生している FabricNotPrimaryException もあるためです。

MSDN リンク ( https://msdn.microsoft.com/en-us/library/azure/system.fabric.fabricnotreadableexception.aspx ) を見ました。しかし、何が

パーティションが読み取りを受け入れることができない場合にスローされる例外を表します。

平均？パーティションが読み取りを受け入れられないのはなぜですか?

私はStatefulServiceメソッドを持っています。メソッドの最初の引数は、アクタの 1 つに対応するインターフェイス タイプを受け入れます。アクターは を使用してサービス メソッドを呼び出し、最初の引数としてServiceProxy渡します。thisこれにより、ファイルがコンパイルされます。署名が一致します。

ただし、実行すると、予期しないタイプの IMyActorType が に認識されていないというエラーが表示されDataContractSerializerます。このメッセージの意味はわかっています。ServiceProxy扱いませんかActorReferences？私はActorProxy作品を知っています。を使用して、あるアクターを別のアクターに渡すことができActorProxyます。

それとも、私の設定に問題があるのStatefulServiceでしょうか? 私のServiceReplicaListenerセットアップで何か？

StatefulServiceメソッドのメソッドシグネチャを に変更することで、この問題を回避しましたActorReference。それは問題なくシリアライズされ、反対側で解凍できます。ただし、適切なタイピングが必要です。

非ファブリック アプリまたはサービスからステートフル HTTP/WebApi サービスを呼び出せるようにしたいと考えています。ステートフル サービスに公開された URL を使用することもできますが、パーティション エンドポイントを解決することで、別のプライマリへのフェールオーバーを利用したいと考えています。

最初にデスクトップ コンソール アプリでテストしようとしましたが、InvokeWithRetryAsync 内で通信 Lambda 関数を実行できませんでした。

これは行き止まりですか (非ファブリック アプリはステートフル サービスを解決できません)、それとも非ファブリック アプリからエンドポイントを解決する別の方法がありますか。それ以外の場合は、"仲介者" ステートレス サービス (Wordcount Webservice など) でリクエストをラップする可能性があります。

クラスターで実行されているサービスと通信しているときに、ProtocolExceptions が発生しています。メッセージと InnerException メッセージ:

このサービスはローカルの開発クラスターで実行されており、サービスと正常に通信した後に例外がスローされます。

通信に使用するコードは次のとおりです。

再試行ロジックがあります (試行間の遅延が増加します)。しかし、この呼び出しは決して成功しません。そのため、サービスが障害状態にあり、回復できないようです。

アップデート

ログには次のエラーも表示されます。

2015 年 12 月 14 日更新

この ProtocolException がスローされた場合、再試行は役に立ちません。何時間も待った後でも、まだ失敗します。

エンドポイントアドレスをログに記録します

解決されたエンドポイントは次のようになります

このエンドポイントは、Service Fabric Explorer によって報告されるものと同じです。

表示されたログから、このサービスは機能しているように見えます (別の API メソッドを介して到達可能です) が、この特定の呼び出しは決して成功しません。

ステートフル アクターは、一定時間 (デフォルトで 60 分) アイドル状態になると非アクティブになることを学びました。これにより、それらのアクターをホストしていたノードから RAM (および CPU) が解放されます。ただし、再度アクティブ化する必要がある場合に備えて、それらの状態はクラスター内に残ります。

いくつかのカスタム基準に基づいてそれらの一部を永久に削除するために、非アクティブ化されたアクター (状態が持続している) を何らかの方法で列挙することが可能かどうか疑問に思っています。

これの目的は、クラスター内のディスク領域を解放することです。これにより、一部のアクターが再びアクティブ化されることはありません (アクティブ化された場合、それらのアクターはまったく新しいものであるかのように動作します)。

副次的な利点として、「一度アクティブ化されたが非アクティブ化された可能性がある」アクターのリストを取得できる場合、そのようなリストを手動で維持する必要はありません。