このセクションでは、SGD サーバーの使用時に発生する一般的な問題、およびその解決方法について説明します。
ここで説明するトラブルシューティングのトピックは次のとおりです。
アレイ回復使用時に発生した問題の診断や修正を行いやすくするために、次のことを行えます。
SGD アレイのステータス情報を表示する
アレイ回復のロギングを有効にする
ある SGD サーバー上で tarantella status コマンドを使用すると、そのサーバーのステータス情報が表示されます。
このセクションでは、アレイ内のプライマリサーバーが停止したときに tarantella status を使用して SGD アレイのステータス情報を表示する例をいくつか示します。「プライマリサーバーの停止」では、このようなアレイ回復のシナリオについて詳しく説明しています。
この例で使用されている元のネットワーク構成は、次のように、ドメイン example.com
にある SGD サーバーの 3 つのノードのアレイです。
プライマリサーバー – boston
セカンダリサーバー – newyork
、detroit
プライマリサーバー boston
が停止したときに、newyork
で tarantella 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 サーバーから見たアレイ構成が表示されます。たとえば、フェイルオーバー段階で newyork
で tarantella 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 コマンドを使用して、元のアレイ配列が再作成されたことを検証できます。たとえば、newyork
で tarantella 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. ...
アレイ回復のロギングを有効にするには、Administration Console の「グローバル設定」 → 「監視」タブの「ログフィルタ」フィールドに、次のログフィルタを追加します。
server/failover/*:failover%%PID%%.log server/failover/*:failover%%PID%%.jsl
SGD ログフィルタの構成および使用の詳細については、「ログフィルタを使用した SGD サーバーのトラブルシューティング」を参照してください。
アレイ内の 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.
アプリケーションの負荷分散を「最小 CPU 使用量」方式および「最大空きメモリー」方式で行うときに問題が発生する場合には、問題の理解に役立つ情報を次の場所から入手できます。
SGD サーバーのログファイル
Administration Console の「グローバル設定」 → 「監視」タブで、「ログフィルタ」フィールドに次のフィルタを追加します。
server/tier3loadbalancing/*:t3loadbal%%PID%%.log server/tier3loadbalancing/*:t3loadbal%%PID%%.jsl
アプリケーションを実行するアプリケーションサーバーがどのように決定されたか、およびそのアプリケーションサーバーから送信されるデータに関する詳細な情報を入手できます。
SGD ログフィルタの構成および使用の詳細については、「ログフィルタを使用した SGD サーバーのトラブルシューティング」を参照してください。
SGD 拡張モジュールのログ
UNIX または Linux プラットフォームのアプリケーションサーバーの場合、これらは /opt/tta_tem/var/log/tier3loadprobe
ファイルにあります。
PID
_error.log
Windows アプリケーションサーバーの場合は、イベント ビューアに表示されます。
負荷分散サービス接続 CGI (Common Gateway Interface) プログラム
https://
という URL にアクセスします。
applicationserver
:3579?get&ttalbinfo
これらの情報を使用して、次の一般的な問題をトラブルシューティングできます。
負荷分散サービスが動作していないと考えられる場合は、次の点を確認してください。
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 に関するトラブルシューティング」 を参照してください。
アプリケーションサーバーの負荷分散プロパティーファイルを作成したあとで、プライマリ SGD サーバーをウォームリスタートする必要があります。次のコマンドをスーパーユーザー (root) として実行してください。
# tarantella restart sgd --warm
SGD サーバーにログインしているユーザーがいないこと、および SGD サーバー上で実行されているアプリケーションセッション (中断されているアプリケーションセッションを含む) が存在しないことを確認してください。
アプリケーションを実行するサーバーとして、アプリケーションサーバーの 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 に関するトラブルシューティング」 を参照してください。
アプリケーションを実行するサーバーとして、アプリケーションサーバーの 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 に関するトラブルシューティング」 を参照してください。
サーバー負荷係数値がどちらのサーバーも同じであることを確認します。「アプリケーションサーバーの相対的な処理能力」を参照してください。
SGD が大量のネットワーク帯域幅を使用している場合は、ユーザープロファイルの「帯域幅の制限」属性を変更して、ユーザーが使用可能な最大帯域幅を減らします。
使用できる帯域幅を減らすと、アプリケーションの使い勝手に影響する場合があります。
Administration Console で、「ユーザープロファイル」タブに移動し、設定するユーザープロファイルオブジェクトを選択します。「パフォーマンス」タブに移動し、「帯域幅の制限」リストから値を選択します。
または、次のコマンドを実行します。
$ tarantella object edit --nameobj
--bandwidthbandwidth
使用可能な帯域幅は次のとおりです。
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」です。これは、帯域幅の使用に制限がないことを意味します。
ファイアウォール越えモード時にユーザーが 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 の実行に関する詳細については、「ファイアウォール越え」を参照してください。
ユーザーが SGD サーバーからログアウトせずに別の SGD サーバーにログインする場合、通常、ユーザーのセッションが新規サーバーに再配置されます。これは、「セッションの移動」または「セッションの乗っ取り」と呼ばれることがあります。
アレイ内のすべての SGD サーバーの時間が同期されていない場合、ユーザーセッションの再配置が成功しないことがあります。
SGD は、ユーザーセッション上のタイムスタンプを使って、どれが新しいかを判断します。新しい方のユーザーセッションが現在の Webtop セッションと見なされます。時刻が同期されていないと、タイムスタンプは、誤った情報を与える場合があります。
時刻の同期は重要であるため、Network Time Protocol (NTP) ソフトウェアを使って時刻を同期します。あるいは、rdate コマンドを使用します。
SGD のユーザーセッションの詳細については、「ユーザーセッションとアプリケーションセッション」を参照してください。