7.7. アレイと負荷分散のトラブルシューティング

このセクションでは、SGD サーバーの使用時に発生する一般的な問題、およびその解決方法について説明します。

ここで説明するトラブルシューティングのトピックは次のとおりです。

7.7.1. アレイ回復のトラブルシューティング

アレイ回復使用時に発生した問題の診断や修正を行いやすくするために、次のことを行えます。

  • SGD アレイのステータス情報を表示する

  • アレイ回復のロギングを有効にする

7.7.1.1. SGD アレイのステータス情報の表示

ある SGD サーバー上で tarantella status コマンドを使用すると、そのサーバーのステータス情報が表示されます。

このセクションでは、アレイ内のプライマリサーバーが停止したときに tarantella status を使用して SGD アレイのステータス情報を表示する例をいくつか示します。「プライマリサーバーの停止」では、このようなアレイ回復のシナリオについて詳しく説明しています。

この例で使用されている元のネットワーク構成は、次のように、ドメイン example.com にある SGD サーバーの 3 つのノードのアレイです。

  • プライマリサーバー – boston

  • セカンダリサーバー – newyorkdetroit

プライマリサーバー boston が停止したときに、newyorktarantella status を実行すると、次のように、SGD アレイに接続の問題があることが示されます。

$ tarantella status
Array members (3):
 - newyork.example.com (secondary): Accepting standard connections.
 - boston.example.com (primary): NOT ACCEPTING CONNECTIONS.
 - detroit.example.com (secondary): Accepting standard connections.
...

アレイ内の各 SGD サーバーから報告されるアレイメンバーシップが一致しない場合には、tarantella status で、アレイ内のすべての SGD サーバーから見たアレイ構成が表示されます。たとえば、フェイルオーバー段階で newyorktarantella status を実行すると、次の情報が表示される可能性があります。

$ tarantella status
	Inconsistent array: the servers report different array membership.
...
boston.example.com reports an error:
 - Host is unavailable
 
newyork.example.com reports 3 members as:
 - newyork.example.com
 - boston.example.com
 - detroit.example.com
 
detroit.example.com reports 1 member as:
 - detroit.example.com

tarantella status コマンドは、アレイが修復済みの状態にあるかどうかを示します。たとえば、フェイルオーバー段階の完了後、detroit から tarantella status を実行すると、次の情報が表示される可能性があります。

$ tarantella status
Array members (2):
 - newyork.example.com (primary)
 - detroit.example.com (secondary)
...
This node is in a repaired array. Any alterations to array state will prevent recovery
of the original array.
Use the tarantella status --originalstate command to see the original array state.

--originalstate オプションを使用すると、修復前のアレイのメンバーが一覧表示されます。たとえば、アレイ内の任意のサーバーで --originalstate オプションを使用すると、次のように、元のアレイメンバーが示されます。

$ tarantella status --originalstate
Original array members (3):
 - boston.example.com (primary)
 - newyork.example.com (secondary)
 - detroit.example.com (secondary)
...

復旧段階後、tarantella status コマンドを使用して、元のアレイ配列が再作成されたことを検証できます。たとえば、newyorktarantella status を実行すると、次の情報が表示される可能性があります。

$ tarantella status
Array members (3):
 - newyork.example.com (secondary): Accepting standard connections.
 - boston.example.com (primary): Accepting standard connections.
 - detroit.example.com (secondary): Accepting standard connections.
...

7.7.1.2. アレイ回復のロギングの有効化

アレイ回復のロギングを有効にするには、Administration Console の「グローバル設定」 → 「監視」タブの「ログフィルタ」フィールドに、次のログフィルタを追加します。

server/failover/*:failover%%PID%%.log
server/failover/*:failover%%PID%%.jsl

SGD ログフィルタの構成および使用の詳細については、「ログフィルタを使用した SGD サーバーのトラブルシューティング」を参照してください。

7.7.2. 時刻同期の問題に関するトラブルシューティング

アレイ内の SGD サーバーの時間が同期していない場合は、問題が発生する可能性があります。可能な場合は、NTP ソフトウェアまたは rdate コマンドを使用して、すべての SGD ホストの時間を確実に同期させてください。

アレイの時間同期の問題を示すには、プライマリ SGD サーバー上で tarantella status コマンドを実行します。次の例は、セカンダリサーバー newyork.example.com の時刻の同期がずれいてることを示しています。

$ tarantella status
Array members (3):
 - boston.example.com (primary): Accepting standard connections.
 - newyork.example.com (secondary): Accepting standard connections.
 - detroit.example.com (secondary): Accepting standard connections.
 
WARNING: The clocks on the array nodes are not synchronized.
The following array members disagree with the primary:
 - newyork.example.com

時間の同期がずれている場合は、Administration Console の「Secure Global Desktop サーバー」タブで警告メッセージも表示されます。

アレイ内の各 SGD サーバーの時間設定を表示するには、次のように、tarantella status--byserver オプションを使用します。

$ tarantella status --byserver
 
boston.example.com:
 - Array member (primary): Accepting standard connections.
 ...
 - Current time reported: Wed Apr 28 09:36:16 BST 2010
 
newyork.example.com:
 - Array member (secondary): Accepting standard connections.
 ...
 - Current time reported: Wed Apr 28 09:38:02 BST 2010
 
detroit.example.com:
 - Array member (secondary): Accepting standard connections.
 ...
 - Current time reported: Wed Apr 28 09:36:16 BST 2010
 
WARNING: The clocks on the array nodes are not synchronized.

7.7.3. Advanced Load Management に関するトラブルシューティング

アプリケーションの負荷分散を「最小 CPU 使用量」方式および「最大空きメモリー」方式で行うときに問題が発生する場合には、問題の理解に役立つ情報を次の場所から入手できます。

  • SGD サーバーのログファイル

    Administration Console の「グローバル設定」 → 「監視」タブで、「ログフィルタ」フィールドに次のフィルタを追加します。

    server/tier3loadbalancing/*:t3loadbal%%PID%%.log
    server/tier3loadbalancing/*:t3loadbal%%PID%%.jsl

    アプリケーションを実行するアプリケーションサーバーがどのように決定されたか、およびそのアプリケーションサーバーから送信されるデータに関する詳細な情報を入手できます。

    SGD ログフィルタの構成および使用の詳細については、「ログフィルタを使用した SGD サーバーのトラブルシューティング」を参照してください。

  • SGD 拡張モジュールのログ

    UNIX または Linux プラットフォームのアプリケーションサーバーの場合、これらは /opt/tta_tem/var/log/tier3loadprobePID_error.log ファイルにあります。

    Windows アプリケーションサーバーの場合は、イベント ビューアに表示されます。

  • 負荷分散サービス接続 CGI (Common Gateway Interface) プログラム

    https://applicationserver:3579?get&ttalbinfo という URL にアクセスします。

これらの情報を使用して、次の一般的な問題をトラブルシューティングできます。

7.7.3.1. 負荷分散サービスが動作しない

負荷分散サービスが動作していないと考えられる場合は、次の点を確認してください。

Questions

  • 7.7.3.1.1: SGD 拡張モジュールがインストールされていて、動作していますか。

  • 7.7.3.1.2: プライマリ SGD サーバーは動作していますか。

  • 7.7.3.1.3: ファイアウォールが負荷分散サービスをブロックしていませんか。

  • 7.7.3.1.4: ログファイルにはどのようなログが記録されていますか。

Questions and Answers

7.7.3.1.1: SGD 拡張モジュールがインストールされていて、動作していますか。

Microsoft Windows アプリケーションサーバーの場合は、「コントロール パネル」 → 「管理ツール」 → 「サービス」を使用して、「Tarantella Load Balancing Service」が表示され開始されていることを確認します。

UNIX および Linux プラットフォームのアプリケーションサーバーの場合は、次のコマンドをスーパーユーザー (root) として実行して、負荷分散プロセスが稼働していることを確認します。

# /opt/tta_tem/bin/tem status

7.7.3.1.2: プライマリ SGD サーバーは動作していますか。

アプリケーションサーバー上の負荷分散サービスは、負荷情報をプライマリ SGD サーバーに送信します。プライマリを使用できない場合、SGD ではアプリケーションサーバーの負荷分散方式として「最少アプリケーションセッション数」が使用されます。

7.7.3.1.3: ファイアウォールが負荷分散サービスをブロックしていませんか。

負荷分散サービスが機能するには、ファイアウォールで次の接続を許可する必要があります。

  • SGD サーバーとアプリケーションサーバー間の TCP 接続 (ポート 3579)。

  • アプリケーションサーバーと SGD サーバー間の UDP 接続 (ポート 3579)。

注記

これらの接続では、認証は必要ありません。

7.7.3.1.4: ログファイルにはどのようなログが記録されていますか。

ログファイルで詳細情報を確認します。詳細については、「Advanced Load Management に関するトラブルシューティング」 を参照してください。

7.7.3.2. SGD がアプリケーションサーバーの負荷分散プロパティーファイルを無視する

アプリケーションサーバーの負荷分散プロパティーファイルを作成したあとで、プライマリ SGD サーバーをウォームリスタートする必要があります。次のコマンドをスーパーユーザー (root) として実行してください。

# tarantella restart sgd --warm

SGD サーバーにログインしているユーザーがいないこと、および SGD サーバー上で実行されているアプリケーションセッション (中断されているアプリケーションセッションを含む) が存在しないことを確認してください。

7.7.3.3. あるアプリケーションサーバーが 1 度も選択されない

アプリケーションを実行するサーバーとして、アプリケーションサーバーの 1 つが一度も選択されない場合は、次の点を確認してください。

Questions

  • 7.7.3.3.1: そのアプリケーションサーバーで負荷分散サービスが実行されていますか。

  • 7.7.3.3.2: そのアプリケーションサーバーを使用してアプリケーションを実行できますか。

  • 7.7.3.3.3: ログファイルにはどのようなログが記録されていますか。

Questions and Answers

7.7.3.3.1: そのアプリケーションサーバーで負荷分散サービスが実行されていますか。

「負荷分散サービスが動作しない」を参照してください。

7.7.3.3.2: そのアプリケーションサーバーを使用してアプリケーションを実行できますか。

Administration Console でアプリケーションサーバーオブジェクトを確認します。アプリケーションサーバーオブジェクトの「一般」タブの「アプリケーション起動」チェックボックスが選択されていることを確認します。

アプリケーションサーバーが稼働していることを確認します。

7.7.3.3.3: ログファイルにはどのようなログが記録されていますか。

ログファイルで詳細情報を確認します。詳細については、「Advanced Load Management に関するトラブルシューティング」 を参照してください。

7.7.3.4. あるアプリケーションサーバーが常に選択される

アプリケーションを実行するサーバーとして、アプリケーションサーバーの 1 つが負荷に関係なく常に選択される場合は、次の点を確認してください。

Questions

  • 7.7.3.4.1: アプリケーションを実行するために複数のアプリケーションサーバーが設定されていますか。

  • 7.7.3.4.2: ほかのアプリケーションサーバーをアプリケーションの実行に使用できますか。

  • 7.7.3.4.3: 適切な負荷分散方式が選択されていますか。

  • 7.7.3.4.4: サーバーアフィニティーを使用していますか。

  • 7.7.3.4.5: そのアプリケーションサーバーで負荷分散サービスが実行されていますか。

  • 7.7.3.4.6: ログファイルにはどのようなログが記録されていますか。

Questions and Answers

7.7.3.4.1: アプリケーションを実行するために複数のアプリケーションサーバーが設定されていますか。

アプリケーションオブジェクトの「ホストしているアプリケーションサーバー」タブを確認します。

7.7.3.4.2: ほかのアプリケーションサーバーをアプリケーションの実行に使用できますか。

Administration Console でアプリケーションサーバーオブジェクトを確認します。「一般」タブの「アプリケーション起動」チェックボックスが選択されていることを確認します。

すべてのアプリケーションサーバーが稼働していることを確認します。

7.7.3.4.3: 適切な負荷分散方式が選択されていますか。

Administration Console で、アプリケーションオブジェクトの「パフォーマンス」タブか、「グローバル設定」 → 「パフォーマンス」タブで、負荷分散方式として「最大空きメモリー」または「最小 CPU 使用量」のいずれかが選択されていることを確認します。

7.7.3.4.4: サーバーアフィニティーを使用していますか。

サーバーアフィニティーとは、ユーザーが最後に起動したアプリケーションと同じアプリケーションサーバー上で、SGD がアプリケーションを起動しようとすることです。サーバーアフィニティーは、デフォルトで有効になっています。「サーバーアフィニティー」 を参照してください。

7.7.3.4.5: そのアプリケーションサーバーで負荷分散サービスが実行されていますか。

「負荷分散サービスが動作しない」を参照してください。

7.7.3.4.6: ログファイルにはどのようなログが記録されていますか。

ログファイルで詳細情報を確認します。詳細については、「Advanced Load Management に関するトラブルシューティング」 を参照してください。

7.7.3.5. 同一のアプリケーションサーバーが 2 つ存在するが、一方が実行するアプリケーションの数が他方よりも多い

サーバー負荷係数値がどちらのサーバーも同じであることを確認します。「アプリケーションサーバーの相対的な処理能力」を参照してください。

7.7.3.6. SGD サーバーのログファイルに ID が不明の更新が着信したことが表示される

SGD サーバーのログファイルに、次のテキストを含む情報メッセージが表示されることがあります。

Got an update for unknown id from machine applicationserver

このメッセージは無視してもかまいません。このメッセージは、プライマリ SGD サーバーが再起動するときにのみ生成されます。

7.7.4. SGD が大量のネットワーク帯域幅を使いすぎる

SGD が大量のネットワーク帯域幅を使用している場合は、ユーザープロファイルの「帯域幅の制限」属性を変更して、ユーザーが使用可能な最大帯域幅を減らします。

注記

使用できる帯域幅を減らすと、アプリケーションの使い勝手に影響する場合があります。

Administration Console で、「ユーザープロファイル」タブに移動し、設定するユーザープロファイルオブジェクトを選択します。「パフォーマンス」タブに移動し、「帯域幅の制限」リストから値を選択します。

または、次のコマンドを実行します。

$ tarantella object edit --name obj --bandwidth bandwidth

使用可能な帯域幅は次のとおりです。

Administration Console

コマンド行

2400 bps

2400

4800 bps

4800

9600 bps

9600

14.4 Kbps

14400

19.2 Kbps

19200

28.8 Kbps

28800

33.6 Kbps

33600

38.8 Kbps

38800

57.6 Kbps

57600

64 Kbps

64000

128 Kbps

128000

256 Kbps

256000

512 Kbps

512000

768 Kbps

768000

1 MBps

1000000

1.5 MBps

1500000

10 MBps

10000000

なし

0

注記

デフォルトは「None」です。これは、帯域幅の使用に制限がないことを意味します。

7.7.5. ファイアウォール越えモード時にユーザーが SGD サーバーに接続できない

ファイアウォール越えモード時にユーザーが SGD サーバーに接続できない場合は、通常、SGD サーバーが SGD Web サーバーより前に起動したことが原因です。

ファイアウォール越えモードの場合、SGD サーバーはポート 443 で待機して、すべての Web 接続を localhost ポート 443 (127.0.0.1:443) 上で待機するよう構成されている SGD Web サーバーに転送します。

SGD サーバーが SGD Web サーバーより前に起動した場合、SGD サーバーは使用可能なすべてのインタフェースへのバインドを実行するため、SGD サーバーはすべての Web 接続を自分自身に転送して無限ループに陥ります。

1 つの解決策は、SGD Web サーバーを常に SGD サーバーより前に起動することです。tarantella start コマンドを使用する場合、SGD サーバーと Web サーバーは常に正しい順序で起動されます。

別の解決策は、localhost インタフェースへのバインドを実行しないように SGD を構成することです。これを実行するには、次のコマンドを使用します。

$ tarantella config edit \
--tarantella-config-server-bindaddresses-external "!127.0.0.1"
注記

一部のシェルでは、!127 が置換される可能性があるため、二重引用符 "!127.0.0.1" は使用できません。代わりに、一重引用符 '!127.0.0.1' を使用してください。

SGD がバインドするインタフェースを正確に指定する場合にも、このコマンドを使用できます。この場合は、DNS 名または IP アドレスのコンマ区切りのリストを入力します。

ファイアウォール越えモードでの SGD の実行に関する詳細については、「ファイアウォール越え」を参照してください。

7.7.6. ユーザーが自分のセッションを再配置できない

ユーザーが SGD サーバーからログアウトせずに別の SGD サーバーにログインする場合、通常、ユーザーのセッションが新規サーバーに再配置されます。これは、「セッションの移動」または「セッションの乗っ取り」と呼ばれることがあります。

アレイ内のすべての SGD サーバーの時間が同期されていない場合、ユーザーセッションの再配置が成功しないことがあります。

SGD は、ユーザーセッション上のタイムスタンプを使って、どれが新しいかを判断します。新しい方のユーザーセッションが現在の Webtop セッションと見なされます。時刻が同期されていないと、タイムスタンプは、誤った情報を与える場合があります。

時刻の同期は重要であるため、Network Time Protocol (NTP) ソフトウェアを使って時刻を同期します。あるいは、rdate コマンドを使用します。

SGD のユーザーセッションの詳細については、「ユーザーセッションとアプリケーションセッション」を参照してください。