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