問題タブ [appfabric]

2つのホストでAppFabricクラスターを実行する際に問題が発生しました。1つのホストでのみ機能することを確認しました（つまり、Webアプリをナビゲートするとキャッシュアイテム数が増加します）が、2番目のホストをクラスターに参加させようとすると、次の例外が発生します。

ここで、289851-cache2は2番目のホストの名前です。

例外としてアクセス許可を確認するという例外がありましたが、キャッシュ接続アカウントを自分のドメインアカウントに変更し、すべての場所へのアクセスを許可しました-アカウントは両方のAppFabricホストマシンの管理者であり、ネットワーク共有へのフルアクセス権があり、AppFabricを実行します管理者としてのPowerShell。しかし、Start-CacheClusterを実行した後、最初のホストのステータスはUPになり、2番目のホストのステータスは無期限にSTARTINGになります。タスクマネージャーやコントロールパネルのサービスを介してもプロセスを停止、開始、または強制終了できないため、他のことを行うにはマシンを再起動する必要があります。

WindowsServerAppFabricSetup_x64_6.0がインストールされたWindowsServer2008 64ビット（Windows Server 2008 R2が必要だと思うので6.1ではありません）を実行しており、構成はネットワーク共有に保存されています。

ホスト1のDistributedCacheAgent.config：

ホスト2のDistributedCacheAgent.config：

前もって感謝します。

Microsoft.ApplicationServer.Caching 名前空間は、appfabric サーバーのキャッシュなしでサポートされますか?

Web アプリケーションで Micrsoft AppFabric キャッシュ サーバーを使用しており、Windows 7 サーバーを使用してホストされています。Microsoft.ApplicationServer.CachingWeb アプリケーションで名前空間を使用しています。ウィンドウ2003サーバーで使用されているappfabicサーバーを使用していないとしたら、この状況です。この Microsoft.ApplicationServer.Caching 名前空間は、appfabric サーバーのキャッシュなしでどのようにサポートされますか?...以前のバージョンのサーバーをサポートするオプションはありますか?

Asp.NetMVC2で構築しているWebサイトのセッション状態プロバイダーとしてAppFabricを設定しています。TempDataはセッションに保存されるため、これを行うとAppFabricもTempDataのストレージプロバイダーになりますか？

ASP.Net MVC2アプリのセッション状態プロバイダーとしてAppFabricを使用していますが、ローカルキャッシュも使用したいと考えています。configSectionsノードの直後のweb.configに次のエントリがあります。

また、system.webノードの子としてweb.configに次のエントリがあります。

残念ながら、セッションに何かを追加してからAppFabric Powershellで次の2つのコマンドを実行すると、セッションデータに追加したものはすべて存在しなくなり、ローカルキャッシュを使用していないと思われます。

また、次のコードを使用してAppFabricでオブジェクトをキャッシュしようとしました。また、CacheClusterを開始および停止した後、一度キャッシュされたオブジェクトはキャッシュされなくなりました。

ただし、次のコードを使用してAppFabricをインスタンス化すると、web.configエントリに依存するのではなく、ローカルキャッシュを使用するように明示的に指示します。

何が間違っているのですか、ローカルキャッシュを使用するようにAppFabricに指示するときにweb.configエントリが機能しないのはなぜですか？AppFabricをセッション状態プロバイダーとして使用できますか？また、ローカルキャッシュを使用できますか？

現在、AppFabricサーバーでWCFサービスを実行しています。アプリケーションは、カスタム構成セクションを取得するためにweb.configファイルを動的にロードする必要があります。

私の開発マシンでは、次のように構成をロードできます。

しかし、テストマシン（AppFabricサーバー）で例外が発生し、実際にWebアプリケーションが実行されているサイトである3番目のパラメーターを指定する必要があるようです。

だから私はそれをハードコーディングしようとしました、そしてそれはうまくいきました。とにかくこれは受け入れられないので、将来どのサイトでサービスを実行するかわからないため、WebConfigurationManagerにサイトを動的に提供する必要があります。誰かがそれを達成する方法を知っていますか？

ありがとう。

AppFabricモニタリングを機能させようとしていますが、ここで立ち往生しています。イベントはASStagingTableに挿入されていますが、ASWcfEventsTableに伝播されません。ASImportEventsspを手動で実行した場合に実行されます。

WindowsServer2008R2でSQLServer2008WorksationEditionを使用しています。AppFabricイベントコレクションサービスが実行されており（ただし、ステージングテーブルにレコードがない場合は、SQL Serverエージェントが実行されていると思います）、実行されていることを確認しました。データベースを作成したとき（AppFabric構成中に）、SQLサーバー認証を使用してログインし、使用する接続文字列は同じクレデンシャルです。私は何かを逃しましたか？

通常、私は、Webアプリケーションでホストするのに適していないタスクを管理するためのWindowsサービスの作成を検討します。これらのタイプのタスクは通常、長時間実行されるプロセスまたはスケジュールされたタスクです。これは通常、これらのタイプのタスクの主要なアプローチですが、Global.asaxによって公開されたApplication_Startイベントで多数のスレッドを開始することにより、Webアプリケーションでこれらの種類のバックグラウンドプロセスを実行する方法を検討しました。このアプローチの問題は、IISワーカープロセスが停止すると、バックグラウンドスレッドも強制終了されることです（事実上、次の要求が受信されるまで「Windowsサービス」は停止されます）。

ASP .NET 4.0は、この問題の解決策を提供します。これで、Scott Guによるこのブログ投稿で説明されているように、StartModeを「AlwaysRunning」に設定できます。この投稿のコメントのどこかで、新しい機能によってワーカープロセスが常に実行されていることが保証されるため、IISでWindowsサービスタイプのタスクをホストする可能性について誰かが質問します。スコットは、それがシナリオを確実にサポートすると述べました。これに加えて、最近のAppFabricの導入は、Microsoft自体がWebアプリケーションでWCFおよびWFサービスをホストおよび監視するための単純なフックを提供していることを意味します。

これは、WebアプリをサポートするためにWindowsサービスを作成していた私たちにとって何を意味しますか？このモデルを採用する必要がありますか？落とし穴は何ですか？私の知る限り、Webアプリケーションで「Windowsサービス」プロセスをホストすることには多くの利点がありますが、最も便利なのは展開のしやすさです。さらに、実行時に何が起こっているかについての情報を提供する、サービスへの単純なユーザーインターフェイスの開発を実際に開始できます。

このルートを使用する必要がある場合、顧客向けのWebアプリケーションで「Windowsサービス」タイプの機能をホストすることはないと思います。私はおそらく、長時間実行/スケジュールされたタスクプロセスをホストする新しいWebアプリケーションプロジェクトを開発するでしょう（Windowsサービスのコンテキストで行うのと同じように）。これにはいくつかの理由があると思います。

1. セキュリティ。実行中のバックグラウンドプロセスに関する情報を表示するUIには、異なるセキュリティモデルが存在する場合があります。このUIを運用チーム以外の誰にも公開したくありません。また、Webアプリケーションは、昇格された一連のアクセス許可を持つ別のユーザーとして実行される場合があります。
2. メンテナンス。フロントエンドWebサイトの使用に影響を与えることなく、バックグラウンドプロセスをホストするアプリケーションに変更を展開できると便利です。
3. パフォーマンス。アプリケーションをメインサイトから分離してユーザー要求を処理することは、バックグラウンドスレッドが着信要求キューを処理するIISの機能を低下させないことを意味します。さらに、必要に応じて、バックグラウンドタスクを処理するアプリケーションを別のサーバーにデプロイできます。

このアプローチについてのあなたの考えと、私がWindowsサービスに固執するべきかどうかを聞いて本当に興味があります。私はこの新しいアプローチを試してみたいと思っています。

AppFabric内のキャッシュクラスターの標準構成セットの構築に取り組んでいます。私の目標は、新しい環境をロードするときに繰り返し可能なキャッシュ設定構成を用意することです（したがって、サーバー名、ホストの数、およびその他の環境要因が異なります）。

私の最初のパスは、Export-CacheClusterConfigから利用可能なXMLを利用し、<hosts>セクションでサーバー名とサイズ属性を変更することでしたが、他にこれらの値に自動的に登録されるものがわかりません（たとえば、hostIdパラメーター）。 。

私が検討した次のアプローチは、PowerShellスクリプトで、渡された正しいパラメーターを使用してさまざまなキャッシュを単純に構築し、デプロイ後の手順として実行することです。

他に、繰り返し可能なAppFabricキャッシュクラスターの展開の経験がある人はいますか？

問題：クラスのインスタンスをキャッシュしてすぐにキャッシュから戻すと、オブジェクトは元に戻ります（nullではありません）が、そのすべてのプロパティ/フィールドがnullまたはデフォルトです。

そのため、オブジェクトの構造が問題であり、AppFabricが何らかの理由でオブジェクトを適切にシリアル化していないのではないかと思います。

ただし、次のシリアル化メソッドを使用すると、シリアル化前のすべてのプロパティ/フィールドを含むオブジェクトが返されます。

オブジェクトがバイナリフォーマッタを使用して適切にシリアル化および逆シリアル化する方法と、キャッシングを介してまったく同じことを行わない方法はありますか？

誰かがこれに遭遇したことがありますか、または誰かが一般的に何に注意すべきかについての提案やヒントがありますか？