トラブルシューティング
構成後に負荷分散が期待どおりに機能しない場合は、一般的なツールを使用してCitrix ADCリソースにアクセスし、問題を診断できます。
Related information
ロードバランシングのトラブルシューティングに関するリソース
最適な結果を得るには、次のリソースを使用して、Citrix ADCアプライアンスのコンテンツスイッチングに関する問題のトラブルシューティングを行います。
-
最新の ns.conf ファイル
-
関連
newnslogファイル -
可能であれば、アプライアンスおよび関連するクライアントに記録される Ethereal パケットトレース
-
ns.log ファイル
上記のリソースに加えて、次のツールもトラブルシューティングを迅速に行えます。
-
HTTP ヘッダーを表示できるブラウザアドオンツール。これは、永続性に関連する問題のトラブルシューティングに使用できます。
-
Citrix ADC トレースファイル用にカスタマイズされた Wireshark アプリケーション。
ロードバランシングの問題のトラブルシューティング
-
問題
CPU 使用率が、-m MAC オプションが有効になっている仮想サーバーにバインドされているサービスにユーザーモニターがバインドされている場合、100% に達します。
-
解像度
ユーザー以外のモニターをサービスにバインドします。
-
問題監視用のユーザースクリプトを作成しましたが、動作していません。解像度スクリプト内の引数の数を確認します。制限は 512 です。512 を超える引数を持つスクリプトは、正しく動作しない可能性があります。CLI から nsumon-debug.pl スクリプトを使用して、スクリプトをデバッグします。
-
問題多くのモニタプローブがあり、ネットワークトラフィックが不必要に増加しているようです。モニタープローブを外す方法はありますか？解像度モニタを無効にするか、set service コマンドの HealthMonitor パラメータの値を NO に設定することで、モニタプローブ接続をオフに設定できます。NO オプションを使用すると、アプライアンスは常に UP としてサービスを表示します。
-
問題私はサービスのモニターを設定しましたが、接続はまだDOWNしているサーバーに向けられています。解像度おそらく、モニタのプローブ間隔を短くする必要があります。Citrix ADCアプライアンスは、モニターがプローブを送信するまで、DOWN状態を検出しません。
-
問題モニターにバインドされたメトリックは、ローカルおよびカスタムメトリックステーブルに存在します。解像度メトリックがローカルメトリックテーブルから選択されている場合は、メトリック名にローカルプレフィックスを追加します。ただし、カスタムテーブルからメトリックスを選択した場合は、プレフィックスを追加する必要はありません。
-
問題サービスに対するモニタプローブがサービスに到達していません。解像度サービスの接続数に制限が設定されているかどうかを確認します。\[はい\] の場合、monitorSkipMaxClient パラメータを ENABLED に設定して、モニタとプローブの接続をこの制限から除外します。
-
問題私はサーバーにpingすることができますが、サービスの状態は常にDOWNとして表示されます。解像度構成されているモニタのタイプを確認します。たとえば、サーバーが SSL 用に構成されておらず、HTTPS モニターを使用する場合、サービスの状態は DOWN としてマークされます。この場合、TCP モニタを使用すると、サービスの状態を UP に変更する必要があります。
-
問題負荷モニターの重みを設定しても、サービスの状態の決定には役立ちません。解像度ロードモニタは、サービスの状態を判断できません。したがって、負荷モニタに重みを設定することは不適切です。
-
問題サービスが安定していません。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
正しいサーバーがサービスにバインドされていることを確認します。
-
サービスにバインドされているモニタのタイプを確認します。
-
モニタの障害の原因を確認します。\[サービス\] ページからサービスを開き、\[サービスの構成\] ダイアログボックスの \[Monitors\] タブで、モニタのプローブの数、障害、および最後の応答ステータスの詳細を確認できます。詳細を表示するには、構成されているモニタをクリックします。
-
カスタムモニタの場合は、TCP または ping モニタをサービスにバインドし、モニタの状態を確認します。これで問題が解決した場合は、カスタムモニタに問題があり、モニタをさらに調査する必要があります。
-
Citrix ADCアプライアンスでパケットトレースを記録し、監視プローブとサーバーの応答を確認して詳細な調査を行うことができます。
-
-
問題仮想 IP（VIP）アドレスが安定していないか、ステータスが DOWN と表示されます。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
ロードバランシング機能がライセンスされていることを確認します。
-
機能が有効になっていることを確認します。
-
適切なサービスが仮想サーバにバインドされていることを確認します。
-
VIP アドレスのステータスが DOWN と表示される場合は、管理者がサービスを有効にしていることを確認します。そうでない場合、サービスのステータスは Out-of-Service である必要があります。このような場合は、サービスを有効にし、問題が解決されたかどうかを確認する必要があります。
-
仮想サーバーにバインドされているサービスを確認し、サービスが安定していない問題に関するトラブルシューティング手順を完了します。
-
VIP アドレスが安定していない場合、仮想サーバーにバインドされているすべてのサービスが失敗する必要があります。したがって、すべてのサービスが同時に失敗しているかどうかを確認します。その場合は、Citrix ADCアプライアンスとサーバーの間にネットワークの問題があります。
-
-
問題サイトの負荷分散が不均一です。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
アプライアンスに構成されている負荷分散方式を確認します。
-
サービスに関連付けられている重みが期待どおりであることを確認します。
-
ロードバランシング方式がラウンドロビン以外の場合は、
newnslogファイルにログインしているサーバへの接続数を確認します。次のコマンドを実行して、newnslogファイル内の番号を確認できます。# nsconmsg –K <newnslog_file> -s ConLb=2 –d oldconmsg特定の仮想サーバのサービスを確認し、応答時間、オープン確立接続（OE）、要求数、永続要求、および永続レート（P）をチェックして、問題をさらにトラブルシューティングします。 -
ロードバランシング方式がラウンドロビンの場合は、前の手順で説明した永続リクエストを確認します。さらに、サービスが安定していないかどうかを確認します。そうでない場合は、サービスが不安定な問題について記載されているトラブルシューティング手順を完了します。
-
アプライアンスで永続性が構成されているかどうかを確認します。
-
安定していないサービスがあるかどうかを確認します。「はい」の場合は、「サービスが安定していない」という問題について記載されているトラブルシューティング手順を完了します。
-
-
問題サービスのステータスはDOWNと表示されます。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
SNIPアドレスが構成されているかどうかを確認します。
-
適切なモニタがサービスにバインドされていることを確認します。
-
カスタムモニタがサービスにバインドされている場合は、TCP モニタまたは ping モニタをサービスにバインドし、モニタの状態を確認します。これで問題が解決した場合は、カスタムモニタに問題があり、モニタをさらに調査する必要があります。
-
別のサブネットにあるサーバーのサービスのステータスがDOWNと表示されているかどうかを確認します。\[はい\] の場合は、\[サブネット IP\] (USNIP) で問題が解決するかどうかを確認します。これは、MIP アドレスがサーバと通信できないことが原因であるためです。
-
-
問題応答時間に問題があります。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
次のコマンドを実行して、サービスの統計情報からサーバの応答時間を確認します。
# nsconmsg –K <newnslog_file> -s ConLb=2 –d oldconmsg -
サービスが安定していないか、サービスのステータスが DOWN の問題として表示されるかを確認します。
-
-
問題サーバーの 1 つが、他の負荷分散サーバーよりも多くの要求を処理しています。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
ロードバランシング方式を確認します。ラウンドロビン方式を使用して、サーバの負荷に関係なく、クライアント要求を均等に分散します。
-
ロードバランシング設定に対してパーシステンスが有効になっているかどうかを確認します。永続性が有効になっている場合、特に永続セッションが長い場合、特定のサーバーがそのセッションを維持するためにより重い負荷がかかっている可能性があります。
-
各サービスに重みが割り当てられているかどうかを確認します。適切なウェイトを割り当てると、適切な負荷分散に役立ちます。
-
-
問題特定の負荷分散サーバーへの接続が停止します。たとえば、1 つの Outlook サーバーへのすべての接続が停止することがあります。解像度次のコンポーネントのトラブルシューティングを検討してください。
-
ロードバランシング方式を確認します。ラウンドロビンである場合は、メソッドを最小接続に変更することを検討してください。
-
モニターのタイムアウト期間を短縮することを検討してください。タイムアウト期間を短くすると、サービスをより早くDOWN（ダウン）としてマークできます。これにより、機能しているサーバにトラフィックを誘導するのに役立ちます。
-
接続が長時間停止すると、サージキューが構築される可能性があります。サーバーの負荷が急増するのを避けるために、サージキューをフラッシュすることを検討してください。
-
サーバが最大レベルで動作している場合は、パフォーマンスを向上させるために新しいサーバを追加することを検討してください。
-
-
問題負荷分散の最小接続方法が構成されている場合でも、ほとんどの接続は特定のサーバーに送信されます。解像度パーシステンスが設定されていて、タイプがソース IP であるかどうかを判断します。最小接続方式でも送信元 IP パーシステンスが設定されている場合、要求は特定のサーバに送信されます。サーバーの IP アドレスは、セッション情報を維持するために必要です。HTTP Cookie ベースの永続性を使用することを検討してください。
-
トラブルシューティングのヒントその他の問題については 、上記に記載されていない問題のトラブルシューティングを行うために、次のヒントを検討してください。
-
複数の負荷モニターが 1 つのサービスにバインドされている場合、サービスの負荷は、そのサービスにバインドされている負荷モニターのすべての値の合計になります。負荷分散を正しく動作させるには、同じ一連のモニターをすべてのサービスにバインドする必要があります。
-
サービスにバインドされた負荷監視を無効にし、サービスが仮想サーバーにバインドされている場合、仮想サーバーは負荷分散にラウンドロビン方式を使用します。
-
負荷分散方式が CUSTOMLOAD で、サービスのステータスが UP である仮想サーバーにサービスをバインドすると、仮想サーバーは負荷分散に初期ラウンドロビン方式を使用します。サービスにカスタムロードモニターがない場合、またはカスタムロードモニターの少なくとも 1 つのステータスが UP でない場合は、引き続きラウンドロビン状態になります。
-
負荷分散方式がCUSTOMLOADである仮想サーバーにバインドされているすべてのサービスでは、サービスには負荷監視がバインドされている必要があります。
-
CUSTOMLOAD ロードバランシング方式は、スタートアップラウンドロビンにも従います。
-
メトリックベースのバインディングを無効にし、これが最後のアクティブなメトリックである場合、特定の仮想サーバーはロードバランシングにラウンドロビン方式を使用します。メトリックしきい値をゼロに設定すると、メトリックが無効になります。
-
モニターにバインドされたメトリックがしきい値を超えると、その特定のサービスは負荷分散の対象にはなりません。すべてのサービスがしきい値に達した場合、仮想サーバーはロードバランシングにラウンドロビン方式を使用し、エラーメッセージ「5xx-サーバービジーエラー」が表示されます。
-
カスタムテーブルから最大 10 個のメトリックをモニターにバインドできます。
-
OIDはスカラー変数でなければなりません。
-
ロードバランシングを成功させるには、間隔をできるだけ低くする必要があります。間隔が大きい場合は、負荷値を取得する期間が長くなります。その結果、不適切な値を使用して負荷分散が行われます。
-
ユーザーはローカルテーブルを変更できません。
-