NSX Advanced Load Balancer には、仮想サービスのクライアント トラフィックのログ記録中に健全性モニターが含まれません。このトピックでは、アクティブ健全性モニターで受信した結果を確認する方法について説明します。

GUI の使用

GUI でサーバの状態を確認するいくつかの方法を次に示します。

  • 停止(赤)サーバ アイコンの上にマウスを置きます。

  • [プール] > [サーバ] ページに移動し、健全性モニターの表の [失敗したモニタ] をクリックして結果を展開します。

  • 仮想サーバおよびプール レコードの状態の変更と理由のイベントを確認します。

詳細については、『VMware NSX Advanced Load Balancer モニタリングおよび運用性ガイド』の「サーバが停止とマークされる理由」セクションを参照してください。

CLI および API の使用

CLI および API から、プール内の各サーバの広範な健全性モニター情報を表示できます。次の例は、省略形のビューを示しています。

show pool [poolname] server hmonstat
+---------------------------------+----------------------------------------+
| Field                           | Value                                  |
+---------------------------------+----------------------------------------+
| server_hm_stat[1]               |                                        |
|   server_name                   | 10.90.15.61:8000                       |
|   oper_status                   |                                        |
|     state                       | OPER_UP                                |
|   shm_runtime[1]                |                                        |
|     health_monitor_name         | healthmonitor-1                        |
|     health_monitor_type         | HEALTH_MONITOR_TCP                     |
|     last_transition_timestamp_3 | Tue May 24 20:42:51 2016 ms            |
|     last_transition_timestamp_2 | Tue May 24 20:42:38 2016 ms            |
|     last_transition_timestamp_1 | Tue May 24 20:37:10 2016 ms            |
|     rise_count                  | 255                                    |
|     fall_count                  | 0                                      |
|     total_checks                | 1414                                   |
|     total_failed_checks         | 5                                      |
|     total_count[1]              |                                        |
|       type                      | CONNECTION_TIMEOUT                     |
|       count                     | 5                                      |
|     avg_response_time           | 1                                      |
|     recent_response_time        | 1                                      |
|     min_response_time           | 1                                      |
|     max_response_time           | 1999                                   |
|     port                        | 8000                                   |
|     curr_failed_checks          | 1                                      |
|   ip_addr                       | 10.90.15.61                            |
|   port                          | 8000                                   |
+---------------------------------+----------------------------------------+

パケット キャプチャの使用

デフォルトでは、パケット キャプチャの実行時に、NSX Advanced Load Balancer には健全性モニター トラフィックは含まれません。ただし、次のフラグを使用して、CLI を使用してこれを変更できます。

debug_vs_hm_include

キャプチャに健全性モニター パケットを含めます。

debug_vs_hm_none

このデフォルトは、キャプチャから健全性モニター パケットを省略します。

debug_vs_hm_only

健全性モニター パケットのみをキャプチャします。

詳細については、『VMware NSX Advanced Load Balancer モニタリングおよび運用性ガイド』の「パケット キャプチャ」セクションを参照してください。

手動テストの使用

pingcurl、または類似の Linux CLI アクセス ユーティリティを手動で送信して、サーバの応答を検証できます。

詳細については、「手動でのサーバ健全性の検証」を参照してください。

モニターに関する一般的な問題

サーバ応答の結果が目的の応答であっても、NSX Advanced Load Balancer が引き続きサーバを DOWN としてマークしている場合は、これらの一般的な問題を確認できます。

モニターの一般的な問題

モニターの一般的な問題は次のとおりです。

  • システムはサーバから返されたコンテンツを検査し、大文字と小文字を区別してモニターのサーバ応答データと比較します。

  • ほとんどのモニターは、サーバ応答内で最大 2k まで検査します。これには、ヘッダーとコンテンツの両方が含まれます。応答内で必要な結果がさらに得られる場合、サーバは DOWN とマークされます。

  • IP アドレスの重複は、健全性チェックが断続的に失敗する原因となる最も一般的な問題の 1 つです。

パッシブ

重大なエラーが発生すると、パッシブ モニターがトリガされ、仮想サービスのログが自動的に生成されます。[サーバ] ページにドリルダウンすると、パッシブ モニターの表示が 100% 未満になる場合があります。仮想サービス ログを表示するには、該当するサーバをフィルタリングします。次に、[ログ分析] サイドバーの [重大度] タイルをクリックします。

次の CLI を使用して、時間の経過とともに障害が発生し、増加しているかどうかを確認できます。

    : > show pool p1 detail            | grep suspect
    |   lb_fail_suspect_state             | 0 

Ping

サーバやファイアウォールなどの一部のデバイスでは、ICMP メッセージの頻度が制限され、メッセージがサイレントに破棄されることがあります。このような場合は、[送信間隔] オプションの頻度を下げる必要があります。

HTTP

送信文字列内の正確な要求ヘッダーをサーバに送信する必要があります。たとえば、Host ヘッダーにスペースが含まれていると、IIS で問題が発生する可能性があります(Host: Avi Server など)。HTTP モニターは、有効な要求をエミュレートするためにいくつかのヘッダーを追加します。これらの追加ヘッダーを省略するには、[クライアント要求データ] フィールドで定義されている送信文字列を明示的に使用する TCP モニターを使用します。TCP を使用している場合は、キャリッジ リターン ライン フィードの \r\n 文字を追加してください。

NSX Advanced Load Balancer は要求の各行の最後に \r\n を含みます。HTTP 1.0 では、最後の行の後に 2 つ目の \r\n を含める必要があります。次の行が含まれます。

[Health monitor send string]\r\n
User-Agent: avi/1.0\r\n
Host: [Avi inserted server name]\r\n
Accept: */*\r\n\r\n

HTTP/S の場合、NSX Advanced Load Balancer では結果が表示されず、リテラルに検査されます。たとえば、サーバは 302 リダイレクトを NSX Advanced Load Balancer に戻すことができますが、これには server is good は含まれません。ブラウザがリダイレクトに従い、正しい内容でページを表示します。コンテンツの URI エンコードによって、HTTP/S 応答が失敗する場合もあります。

外部

より低い権限を持つ hmuser ユーザーを使用して、外部健全性モニターを実行できます。サービス エンジンに接続し、hmuser を使用して su - hmuser <-- login のように root としてログインできます。

root@test-se2:~# su - hmuser
    hmuser@10-10-25-28:~$ pwd
    /run/hmuser

UDP 健全性モニター

受信文字列なしで構成された UDP 健全性モニターは、ICMP 到達不能メッセージを使用してエラーを検出します。ICMP メッセージが表示されないと、サーバが「稼動中」とマークされます。サーバの数が多い環境では、ICMP メッセージの数が多く、UDP 健全性モニターが誤って「稼動中」とマークすることがあります。

上記の状況を解決し、サーバまたは仮想サービスの停止をマークするには、ICMP レート制限の構成を調整します。

ICMP 到達不能レート リミッタが原因で大規模なケースで ICMP 到達不能メッセージがドロップされた場合、次のコマンドを使用してこの問題の発生を確認できます。

show serviceengine  [se-name] flowtablestat | grep icmp_rx_rl

 |   icmp_rx_rl_cfg_pps            | 100                        |
 |   icmp_rx_rl_confirming         | 30                         |
 |   icmp_rx_rl_drops              | 0                          |

ICMP レート制限を構成するには、次のコマンドを実行します。

 [admin:controller]: configure serviceengineproperties
 [admin:controller]: seproperties:se_runtime_properties
 [admin:controller]: seproperties:se_runtime_properties  se_rate_limiters
 [admin:controller]: seproperties:se_runtime_properties:se_rate_limiters : icmp_rl 100