Load Balancer の正常性プローブLoad Balancer health probes

Azure Load Balancer で負荷分散規則を使用する場合は、Load Balancer でバックエンド エンドポイントの状態を検出できるように、正常性プローブを指定する必要があります。When using load-balancing rules with Azure Load Balancer, you need to specify a health probes to allow Load Balancer to detect the backend endpoint status. 正常性プローブの構成とプローブの応答によって、新しいフローを受信するバックエンド プール インスタンスが決まります。The configuration of the health probe and probe responses determine which backend pool instances will receive new flows. 正常性プローブを使用して、バックエンド エンドポイント上のアプリケーションの障害を検出することができます。You can use health probes to detect the failure of an application on a backend endpoint. さらに、正常性プローブに対するカスタム応答を生成し、フロー制御用の正常性プローブを使用して、負荷または計画的ダウンタイムを管理できます。You can also generate a custom response to a health probe and use the health probe for flow control to manage load or planned downtime. 正常性プローブが失敗した場合、Load Balancer は、それぞれの異常なインスタンスへの新しいフローの送信を停止します。When a health probe fails, Load Balancer will stop sending new flows to the respective unhealthy instance.

正常性プローブでは、複数のプロトコルがサポートされます。Health probes support multiple protocols. 特定の正常性プローブ プロトコルを利用できるどうかは、Load Balancer SKU によって異なります。The availability of a specific health probe protocol varies by Load Balancer SKU. さらに、次の表で示すように、サービスの動作も Load Balancer SKU によって異なります。Additionally, the behavior of the service varies by Load Balancer SKU as shown in this table:

Standard SKUStandard SKU Basic SKUBasic SKU
プローブの種類Probe types TCP、HTTP、HTTPSTCP, HTTP, HTTPS TCP、HTTPTCP, HTTP
プローブのダウン動作Probe down behavior すべてのプローブがダウンすると、すべての TCP フローは続行します。All probes down, all TCP flows continue. すべてのプローブがダウンすると、すべての TCP フローは終了します。All probes down, all TCP flows expire.

重要

後で示す信頼できるサービスを作成するための重要な設計ガイダンスを含め、このドキュメント全体を確認してください。Review this document in its entirety, including important design guidance below to create a reliable service.

重要

Load Balancer の正常性プローブは IP アドレス 168.63.129.16 から送信されます。プローブによってお客様のインスタンスがアップとしてマークされるには、これがブロックされていない必要があります。Load Balancer health probes originate from the IP address 168.63.129.16 and must not be blocked for probes to mark up your instance. 詳しくは、「プローブのソース IP アドレス」をご覧ください。Review probe source IP address for details.

プローブの構成Probe configuration

正常性プローブの構成は、次の要素から成っています。Health probe configuration consists out of the following elements:

  • 個々のプローブの間隔の時間Duration of the interval between individual probes
  • プローブが別の状態に遷移する前に調べる必要があるプローブ応答の数Number of probe responses which have to be observed before the probe transitions to a different state
  • プローブのプロトコルProtocol of the probe
  • プローブのポートPort of the probe
  • HTTP(S) プローブの使用時に HTTP GET に対して使用する HTTP パスHTTP path to use for HTTP GET when using HTTP(S) probes

アプリケーションの信号、信号の検出、プラットフォームの対応の概要Understanding application signal, detection of the signal, and reaction of the platform

プローブ応答の数は次の両方に適用されますThe number of probe responses applies to both

  • インスタンスをアップとしてマークできる成功プローブの数。the number of successful probes that allow an instance to be marked as up, and
  • インスタンスがダウンとしてマークされる失敗プローブの数。the number of failed probes that cause an instance to be marked as down.

指定されたタイムアウトの値と間隔の値によって、インスタンスがアップとダウンのどちらとしてマークされるかが決まります。The timeout and interval values specified determine whether an instance will be marked as up or down. 間隔の時間とプローブ応答の数を掛けて、プローブ応答を検出する必要がある期間が決まります。The duration of the interval multiplied by the number of probe responses determines the duration during which the probe responses have to be detected. そして、サービスは必要なプローブが達成された後で反応します。And the service will react after the required probes have been achieved.

この動作について、例を使用してさらに説明します。We can illustrate the behavior further with an example. プローブ応答の数を 2 に、間隔を 5 秒に設定した場合、10 秒以内に 2 回のプローブ失敗が観察される必要があります。If you have set the number of probe responses to 2 and the interval to 5 seconds, this means 2 probe failures must be observed within a 10 second interval. アプリケーションの状態が変化することがある場合、プローブが送信される時刻が同期されないので、次の 2 つのシナリオで検出する時間を制限できます。Because the time at which a probe is sent is not synchronized when your application may change state, we can bound the time to detect by two scenarios:

  1. 最初のプローブが到着する直前に、アプリケーションが失敗プローブ応答の生成を始めた場合、これらのイベントの検出には、10 秒 (2 x 5 秒間隔) に、アプリケーションが障害の通知を始めてから最初のプローブが到着するまでの時間を加えた時間がかかります。If your application starts producing a failing probe response just before the first probe arrives, the detection of these events will take 10 seconds (2 x 5 second intervals) plus the duration of the the application starting to signal a failure to when the the first probe arrives. この検出には、10 秒より少し長い時間がかかると想定できます。You can assume this detection to take slightly over 10 seconds.
  2. 最初のプローブが到着した直後に、アプリケーションが失敗プローブ応答の生成を始めた場合、これらのイベントの検出は、次のプローブが到着 (および失敗) するまでの時間に、さらに 10 秒 (2 x 5 秒間隔) を加えた時間が経過するまで始まりません。If your application starts producing a failing probe response just after the first probe arrives, the detection of these events will not begin until the next probe arrives (and fails) plus another 10 seconds (2 x 5 second intervals). この検出には、15 秒弱の時間がかかると想定できます。You can assume this detection to take just under 15 seconds.

この例では、検出が発生した後、プラットフォームがこの変化に対応するにはわずかな時間がかかります。For this example, once detection has occurred, the platform will then take a small amount of time to react to this change. これは以下に依存します。This means a depending on

  1. アプリケーションの状態変化が始まったときwhen the application begins changing state and
  2. この変化が検出され、必要な条件 (指定された間隔で送信されたプローブの数) を満たしたときwhen this change is detected and met the required criteria (number of probes sent at the specified interval) and
  3. プラットフォーム全体に検出が伝達されたときwhen the detection has been communicated across the platform

失敗したプローブに対する反応は、アプリケーションからの信号の変化に対応するために、最低で 10 秒強、最大で 15 秒よりわずかに長い時間がかかることが想定できます。you can assume the reaction to a failing probe will take between a minimum of just over 10 seconds and a maximum of slightly over 15 seconds to react to a change in the signal from the application. どのような処理が行われているかを示すためにこの例を提供しましたが、この例で示した大まかなガイダンスよりさらに正確な時間を予測することは不可能です。This example is provided to illustrate what is taking place, however, it is not possible to forecast an exact duration beyond the above rough guidance illustrated in this example.

プローブの種類Probe types

正常性プローブによって使用されるプロトコルは、次のいずれかに構成できます。The protocol used by the health probe can be configured to one of the following:

使用可能なプロトコルは、使用されている Load Balancer SKU によって異なります。The available protocols depend on the Load Balancer SKU used:

TCPTCP HTTPHTTP HTTPSHTTPS
Standard SKUStandard SKU
Basic SKUBasic SKU

TCP プローブTCP probe

TCP プローブは、定義済みのポートに 3 ウェイ オープン TCP ハンドシェイクを実行して、接続を開始します。TCP probes initiate a connection by performing a three-way open TCP handshake with the defined port. TCP プローブでは、4 ウェイ クローズ TCP ハンドシェイクによって接続が終了します。TCP probes terminate a connection with a four-way close TCP handshake.

最小のプローブ間隔は 5 秒で、異常な応答の最小数は 2 です。The minimum probe interval is 5 seconds and the minimum number of unhealthy responses is 2. すべての間隔の合計期間が 120 秒を超えることはできません。The total duration of all intervals cannot exceed 120 seconds.

次の場合、TCP プローブは失敗します。A TCP probe fails when:

  • タイムアウト期間中に、インスタンスで TCP リスナーがまったく応答しない場合。The TCP listener on the instance doesn't respond at all during the timeout period. プローブは、失敗したプローブ要求の数に基づいてダウンとしてマークされます。これらは、プローブがダウンとしてマークされる前に、応答なしになるように構成されています。A probe is marked down based on the number of failed probe requests, which were configured to go unanswered before marking down the probe.
  • プローブがインスタンスから TCP リセットを受信した場合。The probe receives a TCP reset from the instance.

次に、この種類のプローブ構成を Resource Manager テンプレートで表現する方法を示します。The following illustrates how you could express this kind of probe configuration in a Resource Manager template:

    {
      "name": "tcp",
      "properties": {
        "protocol": "Tcp",
        "port": 1234,
        "intervalInSeconds": 5,
        "numberOfProbes": 2
      },

HTTP / HTTPS プローブ HTTP / HTTPS probe

注意

HTTPS プローブは、Standard Load Balancer でのみ使用できます。HTTPS probe is only available for Standard Load Balancer.

HTTP プローブと HTTPS プローブは TCP プローブに基づいており、パスが指定された HTTP GET を発行します。HTTP and HTTPS probes build on the TCP probe and issue an HTTP GET with the specified path. これら両方のプローブは、HTTP GET に対して相対パスをサポートします。Both of these probes support relative paths for the HTTP GET. HTTPS プローブは、トランスポート層セキュリティ (TLS、旧称は SSL) ラッパーがある点を除き、HTTP プローブと同じです。HTTPS probes are the same as HTTP probes with the addition of a Transport Layer Security (TLS, formerly known as SSL) wrapper. タイムアウト期間内にインスタンスが HTTP ステータス 200 で応答すると、正常性プローブはアップとしてマークされます。The health probe is marked up when the instance responds with an HTTP status 200 within the timeout period. 既定では、構成された正常性プローブ ポートのチェックが、正常性プローブによって 15 秒ごとに試行されます。The health probe attempts to check the configured health probe port every 15 seconds by default. 最小のプローブ間隔は 5 秒です。The minimum probe interval is 5 seconds. すべての間隔の合計期間が 120 秒を超えることはできません。The total duration of all intervals cannot exceed 120 seconds.

HTTP プローブまたは HTTPS プローブは、お客様が正常性プローブを表現したい場合にも役立ちます。HTTP / HTTPS probes can also be useful if you want to express health probe. プローブ ポートがサービス自体に対するリスナーでもある場合は、ロード バランサーのローテーションからインスタンスを削除するお客様独自のロジックを実装します。implement your own logic to remove instances from load balancer rotation if the probe port is also the listener for the service itself. たとえば、CPU が 90% を超え、200 以外の HTTP ステータスが返される場合は、そのインスタンスが削除されるようにすることができます。For example, you might decide to remove an instance if it's above 90% CPU and return a non-200 HTTP status.

Cloud Services を使用し、w3wp.exe を使う Web ロールがある場合は、Web サイトの自動監視も実現します。If you use Cloud Services and have web roles that use w3wp.exe, you also achieve automatic monitoring of your website. Web サイトのコードで障害が発生すると、200 以外の状態がLoad Balancer プローブに返ります。Failures in your website code return a non-200 status to the load balancer probe.

次の場合、HTTP/HTTPS プローブは失敗します。An HTTP / HTTPS probe fails when:

  • プローブ エンドポイントが、200 以外の HTTP 応答コード (403、404、500 など) を返す場合。Probe endpoint returns an HTTP response code other than 200 (for example, 403, 404, or 500). これにより、正常性プローブはすぐにダウンとしてマークされます。This will mark down the health probe immediately.
  • 31 秒のタイムアウト期間内に、プローブ エンドポイントがまったく応答しない場合。Probe endpoint doesn't respond at all during the 31-second timeout period. プローブが停止中としてマークされる前、すべてのタイムアウト間隔の合計に達するまで、複数のプローブ要求が応答なしになる可能性があります。Multiple probe requests might go unanswered before the probe gets marked as not running and until the sum of all timeout intervals has been reached.
  • プローブ エンドポイントが TCP リセットによって接続を閉じた場合。Probe endpoint closes the connection via a TCP reset.

次に、この種類のプローブ構成を Resource Manager テンプレートで表現する方法を示します。The following illustrates how you could express this kind of probe configuration in a Resource Manager template:

    {
      "name": "http",
      "properties": {
        "protocol": "Http",
        "port": 80,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 2
      },
    {
      "name": "https",
      "properties": {
        "protocol": "Https",
        "port": 443,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 2
      },

ゲスト エージェント プローブ (クラシックのみ)Guest agent probe (Classic only)

既定では、クラウド サービス ロール (worker ロールと Web ロール) は、ゲスト エージェントを使用してプローブを監視します。Cloud service roles (worker roles and web roles) use a guest agent for probe monitoring by default. ゲスト エージェント プローブは最終手段の構成です。A guest agent probe is a last resort configuration. 常に、TCP または HTTP のプローブを使って明示的に正常性プローブを使用してください。Always use a health probe explicitly with a TCP or HTTP probe. ほとんどのアプリケーション シナリオでは、ゲスト エージェント プローブは明示的に定義されたプローブほど効果的ではありません。A guest agent probe is not as effective as explicitly defined probes for most application scenarios.

ゲスト エージェント プローブは、VM 内のゲスト エージェントのチェックです。A guest agent probe is a check of the guest agent inside the VM. その後リッスンし、インスタンスが準備完了状態になっている場合にのみ、HTTP 200 OK で応答しますIt then listens and responds with an HTTP 200 OK response only when the instance is in the Ready state. (他の状態はビジー、リサイクル中、停止中です)。(Other states are Busy, Recycling, or Stopping.)

詳しくは、正常性プローブのサービス定義ファイル (csdef) の構成に関するページまたはクラウド サービス用のパブリック ロード バランサーの作成の開始に関するページをご覧ください。For more information, see Configure the service definition file (csdef) for health probes or Get started by creating a public load balancer for cloud services.

ゲスト エージェントが HTTP 200 OK で応答できない場合、Load Balancer はそのインスタンスを応答不能としてマークします。If the guest agent fails to respond with HTTP 200 OK, the load balancer marks the instance as unresponsive. そして、そのインスタンスへのフローの送信を停止します。It then stops sending flows to that instance. Load Balancer はインスタンスのチェックを続けます。The load balancer continues to check the instance.

ゲスト エージェントが HTTP 200 で応答すると、Load Balancer はそのインスタンスへの新しいフローの送信を再開します。If the guest agent responds with an HTTP 200, the load balancer sends new flows to that instance again.

Web ロールを使う場合、Web サイト コードは通常、Azure ファブリックやゲスト エージェントでは監視されない w3wp.exe で実行されます。When you use a web role, the website code typically runs in w3wp.exe, which isn't monitored by the Azure fabric or guest agent. w3wp.exe でのエラー (たとえば、HTTP 500 の応答) は、ゲスト エージェントに報告されません。Failures in w3wp.exe (for example, HTTP 500 responses) aren't reported to the guest agent. したがって、Load Balancer はそのインスタンスをローテーションから外しません。Consequently, the load balancer doesn't take that instance out of rotation.

プローブのアップ動作Probe up behavior

次の場合、TCP、HTTP、HTTPS の正常性プローブは正常と見なされ、バックエンド エンドポイントは正常としてマークされます。TCP, HTTP, and HTTPS health probes are considered healthy and mark the backend endpoint as healthy when:

  • VM の起動後に一度正常性プローブが成功している。The health probe is successful once after the VM boots.
  • バックエンド エンドポイントを正常としてマークするのに必要な、指定された数のプローブが成功した。The specified number of probes required to mark the backend endpoint as healthy has been achieved.

正常な状態を達成したバックエンド エンドポイントは、新しいフローを受け取ることができます。Any backend endpoint which has achieved a healthy state is eligible for receiving new flows.

注意

正常性プローブが変動する場合、ロード バランサ―は、さらに長い時間待機してから、バックエンド エンドポイントを正常な状態に戻します。If the health probe fluctuates, the load balancer waits longer before it puts the backend endpoint back in the healthy state. この余分な待機時間は、ユーザーとインフラストラクチャを保護するためであり、意図的なポリシーです。This extra wait time protects the user and the infrastructure and is an intentional policy.

プローブのダウン動作Probe down behavior

TCP 接続TCP connections

新しい TCP 接続は、残りの正常なバックエンド エンドポイントに対して成功します。New TCP connections will succeed to remaining healthy backend endpoint.

バックエンド エンドポイントの正常性プローブが失敗した場合、そのバックエンド エンドポイントに対する確立済みの TCP 接続は続行されます。If a backend endpoint's health probe fails, established TCP connections to this backend endpoint continue.

バックエンド プール内のすべてのインスタンスのすべてのプローブが失敗した場合、そのバックエンド プールに新しいフローは送信されません。If all probes for all instances in a backend pool fail, no new flows will be sent to the backend pool. Standard Load Balancer は、確立済みの TCP フローが続行するのを許可します。Standard Load Balancer will permit established TCP flows to continue. Basic Load Balancer は、バックエンド プールに対するすべての既存の TCP フローを終了します。Basic Load Balancer will terminate all existing TCP flows to the backend pool.

Load Balancer はパス スルー サービスであり (TCP 接続を終了しません)、フローは常にクライアントと VM のゲスト OS およびアプリケーションとの間で行われます。Load Balancer is a pass through service (does not terminate TCP connections) and the flow is always between the client and the VM's guest OS and application. すべてのプローブがダウンしたプールでは、フローを受信して SYN-ACK で応答する正常なバックエンド エンドポイントがないため、フロントエンドが TCP 接続オープンの試行 (SYN) に応答しなくなります。A pool with all probes down will cause a frontend to not respond to TCP connection open attempts (SYN) as there is no healthy backend endpoint to receive the flow and respond with an SYN-ACK.

UDP データグラムUDP datagrams

UDP データグラムは、正常なバックエンド エンドポイントに配信されます。UDP datagrams will be delivered to healthy backend endpoints.

UDP はコネクションレスであり、UDP に追跡されるフロー状態は存在しません。UDP is connectionless and there is no flow state tracked for UDP. いずれかのバックエンド エンドポイントの正常性プローブが失敗すると、既存の UDP フローはバックエンド プール内の別の正常なインスタンスに移動できます。If any backend endpoint's health probe fails, existing UDP flows may move to another healthy instance in the backend pool.

バックエンド プール内のすべてのインスタンスのすべてのプローブが失敗した場合は、Basic および Standard の Load Balancer のすべての既存 UDP フローが終了します。If all probes for all instances in a backend pool fail, existing UDP flows will terminate for Basic and Standard Load Balancers.

プローブのソース IP アドレスProbe source IP address

Load Balancer は、その内部正常性モデルに対して分散プローブ サービスを使用します。Load Balancer uses a distributed probing service for its internal health model. VM の各ホスト上に存在するプローブ サービスは、お客様の構成に従って正常性プローブを生成するようにオンデマンドでプログラミングできます。The probing service resides on each host where VMs and can be programmed on-demand to generate health probes per the customer's configuration. 正常性プローブのトラフィックは、正常性プローブを生成するプローブ サービスとお客様の VM の間で直接やり取りされます。The health probe traffic is directly between the probing service that generates the health probe and the customer VM. Load Balancer のすべての正常性プローブは、ソースとして IP アドレス 168.63.129.16 から送信されます。All Load Balancer health probes originate from the IP address 168.63.129.16 as their source. RFC1918 空間ではない、VNet 内の IP アドレス空間を使用できます。You can use IP address space inside of a VNet that is not RFC1918 space. グローバルに予約された Microsoft 所有の IP アドレスを使用すると、お客様が VNet 内で使用する IP アドレス空間との IP アドレス競合の可能性が低くなります。Using a globally reserved, Microsoft owned IP address reduces the chance of an IP address conflict with the IP address space you use inside the VNet. この IP アドレスはすべてのリージョンにおいて同一で、変更されません。また、この IP アドレスからパケットを送信できるのは内部 Azure プラットフォーム コンポーネントだけであるため、セキュリティ リスクになりません。This IP address is the same in all regions and does not change and is not a security risk because only the internal Azure platform component can source a packet from this IP address.

AzureLoadBalancer サービス タグによって、お客様のネットワーク セキュリティ グループに含まれているこのソース IP アドレスが特定され、正常性プローブのトラフィックが既定で許可されます。The AzureLoadBalancer service tag identifies this source IP address in your network security groups and permits health probe traffic by default.

Load Balancer の正常性プローブだけでなく、次の操作でもこの IP アドレスが使用されますIn addition to Load Balancer health probes, the following operations use this IP address:

  • VM エージェントを、プラットフォームと通信して "準備完了" 状態を通知できるようにしますEnables the VM Agent to communicating with the platform to signal it is in a “Ready” state
  • カスタム DNS サーバーを定義していないお客様にフィルター処理された名前解決を提供するため、DNS 仮想サーバーとの通信を有効にします。Enables communication with the DNS virtual server to provide filtered name resolution to customers that do not define custom DNS servers. このフィルター処理により、お客様はデプロイのホスト名だけを確実に解決できます。This filtering ensures that customers can only resolve the hostnames of their deployment.
  • VM が、Azure の DHCP サービスから動的 IP アドレスを取得できるようにします。Enables the VM to obtain a dynamic IP address from the DHCP service in Azure.

設計ガイダンスDesign guidance

正常性プローブは、お客様のサービスを回復性があるものにして、そのスケーリングを可能にするために使用されます。Health probes are used to make your service resilient and allow it to scale. 誤った構成または不適切な設計パターンは、お客様のサービスの可用性とスケーラビリティに影響を及ぼす可能性があります。A misconfiguration or bad design pattern can impact the availability and scalability of your service. このドキュメント全体を確認して、このプローブ応答がダウンまたはアップとしてマークされた場合にお客様のシナリオにどのような影響があるか、また、お客様のアプリケーション シナリオの可用性に対してそれがどのように影響するかについて検討してください。Review this entire document and consider what the impact to your scenario is when this probe response is marked down or marked up, and how it impacts the availability of your application scenario.

アプリケーションの正常性モデルを設計するときは、バックエンド エンドポイント__および__提供しているアプリケーション サービスの正常性が反映される、そのインスタンス上のポートをプローブする必要があります。When you design the health model for your application, you should probe a port on a backend endpoint that reflects the health of that instance and the application service you are providing. アプリケーション ポートとプローブ ポートが同一である必要はありません。The application port and the probe port are not required to be the same. 一部のシナリオでは、プローブ ポートが、お客様のアプリケーションのサービスを提供するポートと異なることが望ましい場合もあります。In some scenarios, it may be desirable for the probe port to be different than the port your application provides service on.

場合によっては、お客様のアプリケーションの正常性を検出するためだけではなく、お客様のインスタンスが新しいフローを受信すべきかどうかを Load Balancer に直接伝えるために正常性プローブ応答を生成することが、お客様のアプリケーションの役に立つ可能性があります。Sometimes it can be useful for your application to generate a health probe response to not only detect your application health, but also signal directly to Load Balancer whether your instance should receive or not receive new flows. お客様のアプリケーションで正常性プローブの失敗によってバックプレッシャを作成してインスタンスへの新しいフローの送信を調整したり、お客様のアプリケーションのメンテナンスを準備してお客様のシナリオのドレインを開始したりするために、プローブ応答を操作できます。You can manipulate the probe response to allow your application to create backpressure and throttle delivery of new flows to an instance by failing the health probe or prepare for maintenance of your application and initiate draining your scenario. Standard Load Balancer を使用している場合、プローブのダウン信号では常に、アイドル タイムアウトまたは接続の終了まで TCP フローが継続されます。When using Standard Load Balancer, a probe down signal will always allow TCP flows to continue until idle timeout or connection closure.

UDP の負荷分散では、バックエンド エンドポイントからカスタム正常性プローブ シグナルを生成し、対応するリスナーをターゲットとする TCP、HTTP、または HTTPS の正常性プローブを使用して、UDP アプリケーションの正常性を反映する必要があります。For UDP load balancing, you should generate a custom health probe signal from the backend endpoint and use either a TCP, HTTP, or HTTPS health probe targeting the corresponding listener to reflect the health of your UDP application.

Standard Load Balancer による HA ポート負荷分散規則を使用すると、すべてのポートが負荷分散されて、1 つの正常性プローブ応答がインスタンス全体の状態を反映する必要があります。When using HA Ports load-balancing rules with Standard Load Balancer, all ports are load balanced and a single health probe response must reflect the status of the entire instance.

お客様の VNet 内にある別のインスタンスへの正常性プローブを受信するインスタンスによる正常性プローブの変換またはプロキシは行わないでください。この構成では、お客様のシナリオで障害が連鎖的に発生する可能性があります。Do not translate or proxy a health probe through the instance that receives the health probe to another instance in your VNet as this configuration can lead to cascading failures in your scenario. 次のシナリオを検討してください。スケーラビリティと冗長性をアプライアンスに提供する Load Balancer リソースのバックエンド プールに一連のサードパーティ アプライアンスがデプロイされています。また、アプライアンスの背後にある他の仮想マシンへのプロキシまたは変換がサードパーティ アプライアンスによって行われるポートをプローブするよう、正常性プローブが構成されています。Consider the following scenario: a set of third-party appliances is deployed in the backend pool of a Load Balancer resource to provide scale and redundancy for the appliances and the health probe is configured to probe a port that the third-party appliance proxies or translates to other virtual machines behind the appliance. アプライアンスの背後にある他の仮想マシンに対して要求を変換またはプロキシするために使用している同じポートをプローブすると、アプライアンスの背後にある単一の仮想マシンからのプローブ応答によって、アプライアンス自体が停止状態としてマークされます。If you probe the same port you are using to translate or proxy requests to the other virtual machines behind the appliance, any probe response from a single virtual machine behind the appliance will mark the appliance itself dead. この構成では、アプライアンスの内側にある単一のバックエンド エンドポイントによって、アプリケーションのシナリオ全体が連鎖的に失敗する可能性があります。This configuration can lead to a cascading failure of the entire application scenario as a result of a single backend endpoint behind the appliance. トリガーとなり得るのはプローブの断続的な失敗です。これが原因で、Load Balancer によって元の送信先 (アプライアンスのインスタンス) がダウンとしてマークされ、お客様のアプリケーションのシナリオ全体が無効になる可能性があります。The trigger can be an intermittent probe failure that will cause Load Balancer to mark down the original destination (the appliance instance) and in turn can disable your entire application scenario. 代わりにアプライアンス自体の正常性をプローブしてください。Probe the health of the appliance itself instead. 正常性シグナルを特定するプローブの選択はネットワーク仮想アプライアンス (NVA) のシナリオで重要な考慮事項です。このようなシナリオでは、適切な正常性シグナルについてお客様のアプリケーション ベンダーと相談する必要があります。The selection of the probe to determine the health signal is an important consideration for network virtual appliances (NVA) scenarios and you must consult your application vendor for what the appropriate health signal is for such scenarios.

お客様のファイアウォール ポリシーでプローブのソース IP を許可しない場合、正常性プローブはお客様のインスタンスに到達できないため失敗します。If you don't allow the source IP of the probe in your firewall policies, the health probe will fail as it is unable to reach your instance. さらに、正常性プローブが失敗するため、Load Balancer はインスタンスをダウンとしてマークします。In turn, Load Balancer will mark down your instance due to the health probe failure. この誤った構成は、お客様の負荷分散アプリケーションのシナリオが失敗する原因となる可能性があります。This misconfiguration can cause your load balanced application scenario to fail.

Load Balancer の正常性プローブによってお客様のインスタンスがアップとしてマークされるには、Azure のネットワーク セキュリティ グループとローカル ファイアウォールのポリシーで、この IP アドレスを許可する必要がありますFor Load Balancer's health probe to mark up your instance, you must allow this IP address in any Azure network security groups and local firewall policies. 既定では、正常性プローブのトラフィックを許可するためのサービス タグ AzureLoadBalancer がすべてのネットワーク セキュリティ グループに含まれています。By default, every network security group includes the service tag AzureLoadBalancer to permit health probe traffic.

正常性プローブの失敗をテストしたい場合、または個別のインスタンスをダウンとしてマークしたい場合は、ネットワーク セキュリティ グループを使用し、正常性プローブ (宛先ポートまたはソース IP) を明示的にブロックしてプローブの失敗をシミュレートできます。If you wish to test a health probe failure or mark down an individual instance, you can use a network security groups to explicitly block the health probe (destination port or source IP) and simulate the failure of a probe.

168.63.129.16 が含まれている Microsoft 所有の IP アドレス範囲を使用してお客様の VNet を構成しないでください。Do not configure your VNet with the Microsoft owned IP address range that contains 168.63.129.16. このような構成は正常性プローブの IP アドレスと競合して、お客様のシナリオの失敗を引き起こす可能性があります。Such configurations will collide with the IP address of the health probe and can cause your scenario to fail.

VM に複数のインターフェイスがある場合は、プローブを受信したインターフェイスでプローブに応答することを保証する必要があります。If you have multiple interfaces on your VM, you need to insure you respond to the probe on the interface you received it on. VM でインターフェイスごとにこのアドレスをソース ネットワーク アドレス変換することが必要な場合があります。You may need to source network address translate this address in the VM on a per interface basis.

TCP タイムスタンプは有効にしないでください。Do not enable TCP timestamps. TCP タイムスタンプを有効にすると、TCP パケットが VM のゲスト OS TCP スタックによってドロップされるため、正常性プローブが失敗する可能性があります。その結果 Load Balancer によって、各エンドポイントがダウンとしてマークされます。Enabling TCP timestamps can cause health probes to fail due to TCP packets being dropped by the VM's guest OS TCP stack, which results in Load Balancer marking down the respective endpoint. TCP タイムスタンプは、セキュリティで強化された VM イメージにおいて既定で定期的に有効にされるので、無効にする必要があります。TCP timestamps are routinely enabled by default on security hardened VM images and must be disabled.

監視Monitoring

公開と内部いずれの Standard Load Balancer でも、エンドポイントおよびバックエンド エンドポイントごとの正常性プローブの状態が、Azure Monitor により多次元メトリックとして公開されます。Both public and internal Standard Load Balancer expose per endpoint and backend endpoint health probe status as multi-dimensional metrics through Azure Monitor. これらのメトリックは、他の Azure サービスやパートナー アプリケーションによって消費される可能性があります。These metrics can be consumed by other Azure services or partner applications.

公開の Basic Load Balancer では、Azure Monitor ログ経由でバックエンド プールごとにまとめられた正常性プローブの状態が公開されます。Basic public Load Balancer exposes health probe status summarized per backend pool via Azure Monitor logs. Azure Monitor ログは内部の Basic Load Balancer では使用できません。Azure Monitor logs are not available for internal Basic Load Balancers. Azure Monitor ログを使って、パブリック Load Balancer のプローブの正常性状態とプローブの数を確認できます。You can use Azure Monitor logs to check on the public load balancer probe health status and probe count. ログ記録と共に Power BI または Azure Operational Insights を使用することで、Load Balancer の正常性状態の統計情報を提供することができます。Logging can be used with Power BI or Azure Operational Insights to provide statistics about load balancer health status.

制限事項Limitations

  • HTTPS プローブは、クライアント証明書との相互認証をサポートしていません。HTTPS probes do not support mutual authentication with a client certificate.
  • TCP タイムスタンプが有効な場合は正常性プローブが失敗すると想定する必要があります。You should assumehHealth probes will fail when TCP timestamps are enabled.

次の手順Next steps