LB は、一定期間内にインスタンスの正常性をプローブすることを知っています。また、最近 LB がカスタム プローブをサポートするように更新されたことも知っています。私が知っている限りでは、200 (OK) 以外のコードを受信したときに LB が行う唯一のアクションは、LB へのトラフィックの転送を停止することです。インスタンスがプローブに応答しないことに気付いたときに、ロード バランサーが回復アクションを実行する方法はありますか? 回復アクションとは、問題のあるインスタンスを再起動するか、さらにアクションを実行できるサービスに通知することを意味します。
2 に答える
カスタムロードバランサープローブの目的は、インスタンスが正常であるか、ロードバランサーからのリクエストを受信する準備ができているかどうかを判断するためのカスタムロジックが含まれていることです。@astaykovがすでに説明しているように、修正措置を講じるのはロードバランサーの仕事ではなく、ファブリックコントローラー次第です。ただし、ファブリックコントローラは、認識していることのみを監視します。起動タスクで実行可能ファイルを起動していて、このプロセスがオフラインのときはいつでもインスタンスを再起動したい場合があります(たとえば、ノードプロセスを考えてみてください)。
このプロセスがオフラインの場合、カスタムロードバランサプローブはステータス500を返し、再起動しようとする可能性があります。その間、ロードバランサーはリクエストをその特定のインスタンスに転送しません。プローブでは、プロセスの再起動を試みることもできます。これが数回後に失敗した場合は、自分で再起動を要求できます(クリーンな方法で)。
是正措置を講じることは、LB ジョブの一部ではありません。LB ジョブは、その名前が示すとおりで、インスタンス間でトラフィックのバランスを取ります。ドキュメントをもう少し深く読むと、
ゲスト エージェントが繰り返し HTTP 200 OK で応答しない場合、Azure ロード バランサーはインスタンスを応答なしとしてマークし、そのインスタンスへのトラフィックの送信を停止します。
ポイントは、障害のあるインスタンスが「無応答」に設定されることです。そして今、インスタンスを管理するのは Windows Azure ファブリック コントローラーの仕事です。それらのステータスをチェックし、何か問題がある場合は、是正措置を講じます。