CA AppLogic® のインストールおよびメンテナンス › メンテナンス詳細ガイド › 管理および詳細オプション › グリッドの管理方法

グリッドの管理方法

バックボーン管理者として、グリッド上で管理タスクおよび高度な操作を実行します。 これらの操作には、サーバ情報の取得、ネットワーク ヘルスのチェック、およびグリッド障害の確認が含まれます。 BFC 管理者は、これらのタスクを定期的に実行できます。

以下の図に、通常の環境でグリッドを管理する方法を示します。

1. サーバ情報を取得および変更します。
2. サーバが多すぎる場合は、グリッドからサーバを削除します。

   たとえば、リソースが十分に利用されないので、必要なサーバの最小数を 5 から 4 に変更します。

3. グリッドの問題を検出する場合は、ネットワーク ヘルスをチェックします。
4. グリッドが失敗した場合は、以下の手順に従います。
   1. グリッド障害ログを確認します。
   2. グリッド コントローラ操作をリストアします。

サーバ情報の取得および変更

3tsrv ユーティリティは、各サーバの dom0 に存在します。 このユーティリティにアクセスできるのは、グリッド管理者のみです。 このユーティリティを使用して、サーバ情報を取得および変更し、障害解析用のログ収集などの機能を実行します。

以下の手順に従います。

1. 以下のコマンドを実行します。

   3tsrv command [ prop[=val] ]* [ --batch ][ --force ] 
   

   command

   実行するコマンドを指定します。

   prop=val

   コマンド固有の追加の引数を指定します。 val を指定しない場合、この製品は値 TRUE を持つブール値プロパティであると見なします。

   --batch

   ユーティリティがスクリプトから実行され、長いエラー メッセージを表示しないことを指定します。 この変数は、UDL 形式の出力も表示します。

   --force

   指定した操作を強制的に実行します。

2. サポートされている以下のコマンドを考慮します。

   info

   詳細なサーバ情報を取得します。

   set

   サーバ情報を設定します。

   reboot

   サーバを再起動します。

   shutdown

   サーバをシャットダウンします。

   applogic activate

   サーバ上の製品をアクティブにします。

   applogic deactivate

   サーバ上の製品を非アクティブにします。

   applogic start

   サーバ上の製品を起動します。

   applogic stop

   サーバ上の製品を停止します。

   diskchk enable

   サーバ上のディスク障害検出を有効にします。

   diskchk disable

   サーバ上のディスク障害検出を無効にします。

   bd list

   サーバ上で製品によって使用されるアクティブなブロック デバイスをリストします。

   sd get

   サーバ データ ファイルのコンテンツを表示します。

   sd set

   サーバ データ ファイルを更新します。

   logs collect

   サーバ ログおよび情報を収集します。

   help

   ユーティリティのヘルプを表示します。

   たとえば、サーバに関する詳細情報を表示します。

   以下のコマンドを実行します。

   3tsrv info [ --batch ]
   

グリッドからのサーバの削除

［グリッド プロパティ］ページの［サーバ アクション］を使用して、グリッドからサーバを削除できます。

最小数と目標数に対して等しい値を指定した場合は、最小サーバ値を減分する必要がある場合があります。 たとえば、グリッドに、最小/目標/最大値が 5/5/5 に設定された 5 つのサーバがあります。 svr5 が十分に利用されないので、最小値を 4 に設定します。

注： 最小サーバ値が目標値未満である場合、最初に最小値を調節する必要はありません。 たとえば、最小/目標/最大値に対して 5/7/7 を指定した場合、最小値を調節せずに 2 つのサーバを削除できます。

以下の手順に従います。

1. BFC UI から、［グリッド プロパティ］ページの［Xen］または［VMware］タブを開きます。
2. 最小値として 4 を入力します。
3. グリッド シェルを開きます。
4. 以下のコマンドを実行します。

   3t srv disable srv<n>
   

   n

   グリッドから削除するサーバ番号。

   注： 手順 5d で［強制的に削除］チェック ボックスをオンにした場合、この手順の実行は任意となります。

5. 以下の手順を実行します。
   1. BFC UI から、［グリッド プロパティ］ページの［サーバ］タブを選択します。
   2. 削除するサーバを選択し、［サーバ アクション］ドロップダウン リストから［削除］をクリックします。
   3. 別のグリッドがサーバを選択しないようにする場合は、［隔離］オプションを有効にします。
   4. CA AppLogic® で無効になっていないサーバを削除するには、［強制的に削除］オプションを選択します。

ネットワーク ヘルスのチェック

3tnetha ユーティリティを使用すると、ネットワークおよびスイッチ関連のさまざまなチェックのスクリプトを作成できます。 この製品は、その定期的なヘルス チェックの一環として 3tnetha スクリプトを定期的に呼び出します。

以下の手順に従います。

1. コントローラ上の以下のディレクトリ内に、スクリプトを配置します。

   /var/applogic/scripts
   

   このスクリプトはデフォルトで、正常終了以外の処理は何もしません。

2. 以下のように、スクリプトの出力を確認します。
   • 環境に問題がない場合、スクリプトは終了コード 0 で完了します。
   • スクリプトが問題を検出した場合、スクリプトは終了コード 1 で異常終了します。 出力は、その問題について説明するエラー メッセージを STDOUT に表示します。 3tnetha が終了コード 1 で異常終了した場合は、グリッド ダッシュボード上にメッセージが表示されます。

     以下の例では、ダッシュボード メッセージのサンプル形式を示します。

     グリッドのネットワークで問題が検出されました： 3tnetha からの標準出力。 テクニカル サポートにお問い合わせください。 
     

   • スクリプトが 1 より大きい終了コードで異常終了した場合は、ネットワーク状態を判断できませんでした。 この場合、問題を示す一般的なダッシュボード メッセージが表示されます。

グリッド障害ログの確認

グリッドの動作に基づいて、障害をトラブルシューティングできます。 予期しないグリッド障害を CA サポートに報告してください。 ただし、バグ レポートをサブミットする前に、リリース ノートを確認して問題が不明であることを確認してください。

以下の手順に従います。

1. 以下のグリッド動作のいずれかが発生するかどうかを確認します。
   • オペレータがグリッドの再起動コマンドを発行していないにもかかわらず、明白な理由なしにグリッドが再起動する（この障害は、グリッドのダッシュボード上でレポートされます）。
   • いずれかのグリッド サーバがクラッシュするか、または反応しなくなる。

     注： この製品では、この動作はグリッドのダッシュボード上でレポートできます。

   • 製品 GUI がロックされ、応答しなくなる。
   • いずれかのデフォルトの製品標準アプライアンスが、以下のいずれかの理由で失敗する。
     • 起動しない
     • クラッシュする
     • 応答しなくなる

     注： この製品では、この動作はグリッドのダッシュボード上でレポートできます。

   • CLI コマンドが明白な理由なしにハングアップまたは失敗する。

   この例では、問題を既知の問題として確認できません。 バグ レポートをファイルすることに決めます。

   バックアップを含め、グリッドからすべてのログを収集します。 たとえば、xxxx.1、xxxx.2 など。

   グリッドおよびサーバのログは、管理者アクセス権を必要とします。 これらのログを CA サポートに送信します。

   注： 各サーバで 3tsrv ユーティリティを使用して、サーバ固有のログおよび情報を収集できます。

2. 以下のディレクトリからグリッド コントローラ ログを収集します。
   • /var/log/messages
   • /var/log/applogic
   • /var/log/3tshell
   • /var/log/secure

• 以下のディレクトリからサーバ ログを収集します。
  • /var/log/messages/
  • /var/log/applogic
  • /var/log/xen/
  • /var/log/secure
• 以下のディレクトリからアプライアンス ログ（アプライアンスの障害時のみ）を収集します。
  • /var/log/messages/
  • /var/log/applogic
  • /var/log/secure
• 以下のコンテナおよび BFC のログを収集します。

  ContainerX_python.log.Y

  BFC が発行するあらゆるグリッド コマンドの出力が含まれています。 また、このログには、BFC が実行する、ユーザが認識できるアクションの出力も含まれています。 このログを、トラブルシューティングに最も役立つログとして扱うことをお勧めします。

  BFCLog.X

  検出に関する問題を診断する場合に有用なデータが含まれています。 CA テクニカル サポートはこのログをプライマリとして使用します。

  bfc_setup.log

  BFC インストールの出力が含まれています。

  /var/log/messages folder

  DHCP リクエストに関するデータが含まれています。 このログは、サーバを検出したときに表示できます。 サーバの電源がオンになったが、その dhcp がこのログに表示されない場合、PXE に関してサーバが適切に設定されていない可能性があります。

  /var/bfcadmin/inventory

  サーバのインベントリ ファイルが含まれており、検出/インベントリの問題を診断するのに役立ちます。

  /var/bfcadmin/deployer

  サーバがグリッドに展開されたときに作成されたログが含まれています。 サーバがグリッドに追加されるときに失敗した場合、これらのファイルが役立つ可能性があります。

1. グリッド（dom0）内の各サーバに関する以下の情報を収集します。
   • lspci
   • lspci -n
   • lspci -v
   • lsmod
   • cat /proc/cpuinfo
   • cat /proc/meminfo
   • dmidecode
   • サーバ上のすべての物理ディスクに対する smartctl -a

グリッド コントローラ操作のリストア

グリッド コントローラ サーバが失敗した場合、この製品はグリッド コントローラの復旧問題を検出します。 これらの問題により、グリッド コントローラをアクセス不可能になる可能性があります。

以下の手順に従います。

1. 1 つ以上のグリッド コントローラ サーバがダウンしているためにグリッドにコントローラ HA がない場合は、以下を考慮します。
   • ダッシュボードは、グリッドにコントローラ HA がないことをユーザに通知します。 X/Y のコントローラ サーバがダウンしています。 コントローラ HA をリストアするには、以下のコントローラ サーバの Z 個をオンラインに戻します。サーバのリスト
   • サーバをオンラインに戻すか、または新しいサーバをグリッドに追加します。 サービス プロバイダにお問い合わせください。
2. HA グリッド コントローラを適切に設定しなかった場合は、以下を考慮します。
   • ダッシュボードは、グリッドがコントローラ HA 用に設定されていないことをユーザに通知します。 セカンダリ コントローラ サーバを割り当てます。割り当てない場合、グリッドはグリッド コントローラ サーバ障害から復旧できません。 グリッド上でコントローラ HA を有効にするには、実行中のいずれかのサーバをセカンダリ コントローラ サーバとして割り当てます。
   • セカンダリ グリッド コントローラ（バックアップ グリッド コントローラ）として割り当てられたサーバがありません。 ただちにサービス プロバイダにお問い合わせください。
   • この製品は、グリッド障害やアプリケーション ダウンタイムを発生させる可能性がある以下の不適切なグリッド設定を検出します。
3. 単一サーバ グリッドに HA 機能がない場合は、以下を考慮します。
   • ダッシュボードは、グリッドが単一サーバ グリッドであるため、アプリケーション HA が使用できないことをユーザに通知します。
   • ほとんどの HA 機能は、少なくとも 2 つのサーバを必要とします。 このドキュメントで説明している HA 機能を利用するには、サービス プロバイダに問い合わせて、少なくとももう 1 つのサーバをグリッドに追加します。
4. グリッドに対して適切な量のコントローラ メモリ、コントローラ CPU、またはサーバ メモリを設定しなかった場合は、以下を考慮します。
   • ダッシュボードは、グリッド リソースが適切に設定されないことをユーザに通知します。 この問題により、グリッドのパフォーマンスが低下したり、グリッドが不安定になる可能性があります。 グリッド上でグリッド リソース（コントローラ メモリ、コントローラ CPU、サーバ メモリ）を更新するか、またはテクニカル サポートにお問い合わせください。
   • ただちにサービス プロバイダにお問い合わせください。 適切な量のリソースを使用するには、グリッドを再設定します。再設定しない場合、グリッドの状態が不安定になり、実行中のアプリケーションの稼働時間に影響を与える可能性があります。

グリッドの管理を正常に実行しました。