Azure Webサイトでトラフィックマネージャの変更が検出されない

Question

私は、一部のデータにWCFサービスを使用するAzure Webサイト（website.mycompany.com）を持っています。 WCFサービスは、フェールオーバー処理のための2つのサービスインスタンスを持つ「優先モード」で動作するAzureトラフィックマネージャ（service.mycompany.com）の背後にあります。プライオリティモードでは、プライマリはデータが利用できない限り、常にデータを処理します。使用できない場合は、2番目のインスタンスが応答します。

最近、service.mycompany.comのプライマリエンドポイントがオフラインだった例がいくつかありました。 service.mycompany.comを指し示す「パートナーシップ」については、スイッチを検出してすべて正常だった。しかし最近、私たち自身のサイト（website.mycompany.com）はトラフィックマネージャのスイッチを検出せず、サービスが応答しないためにウェブサイトにエラーがあります。

これらのインスタンスのフェールオーバーエンドポイントはアップしていますが、これまではAzureのWebサイトでスイッチが検出されましたが、最近ではこの問題が発生しています。誰も同じような問題を経験しましたか？ Azure WebサイトでTTLを検出するのに役立つようにDNSを変更する必要はありますか？

Answer 1

誰も同じような問題が発生しましたか？

交通管理者がすぐに別のエンドポイントに切り替えることはできませんか？

1. キャッシュの期間が「生存時間」によって決定される（TTL：

   トラフィックマネージャは、DNSレベルで動作しますが、ここではトラフィックマネージャはすぐに切り替えることができない理由があります）各DNSレコードのプロパティです。値を短くすると、キャッシュの有効期限が短くなり、Traffic Managerネームサーバーへのラウンドトリップが増えます。 値が大きいほど、障害が発生したエンドポイントからのトラフィックを遠ざけるのに時間がかかることを意味します。

2. トラフィックマネージャエンドポイントモニタが応答時間に影響します。晴天の交通管理者の詳細については、linkを参照してください。
   次のタイムラインは、監視プロセスの詳細な説明です。

3. また、トラフィックマネージャのプロファイルは、Windowsのnslookupとipconfigを使用して確認できます。トラフィックマネージャの設定をどのようにするかについては、linkを参照してください。

ところで、トラフィックマネージャはDNSレベルで動作するため、既存のエンドポイントへの接続に影響を与えることはできません。エンドポイント間でトラフィックを誘導する場合（変更されたプロファイル設定、またはフェールオーバーまたはフェールバックのいずれか）、Traffic Managerは新しい接続を使用可能なエンドポイントに指示します。ただし、他のエンドポイントは、それらのセッションが終了するまで、既存の接続を介してトラフィックを引き続き受信する可能性があります。 トラフィックが既存の接続から消費されるようにするには、各エンドポイントで使用されるセッションの期間を制限する必要があります。

Answer 2

私は答えがhereであることを指摘します。状況はまったく同じではありませんが、同じ解決策があるようです。要約すると、適切に閉じられていないダウンサービスへの接続が残っている可能性が高いことがわかります。この接続はTTLとは無関係で、TTLはDNSキャッシュのみを処理するため、トラフィックマネージャは完全にバイパスされます。