第 7 章 障害追跡

どのようなソフトウェアでも起こりうることですが、時として N1 Provisioning Server ソフトウェアや Infrastructure Fabric (I-Fabric) に問題が発生する場合があります。 この章では、このような問題の特定と解決に役立つ情報を提供します。 この章では、発生しうる問題、考えられる原因、および問題に対する実践的な解決法を説明します。 障害追跡に役立つ、表とフローチャートが用意されています。 この章の主な内容は次のとおりです。

• 「障害のあるファームデバイスの処理」

• 「障害のあるコントロールプレーンサーバーの処理」

• 「コントロールプレーン上の障害のあるソフトウェアの処理」

• 「N1 Provisioning Server の問題の診断 」

• 「メッセージログファイルの形式 」

• 「要求キューの管理 」

• 「停止した要求の処理 」

• 「ファーム操作の障害追跡 」

• 「イメージの問題の障害追跡 」

• 「監視の問題の障害追跡 」

• 「Control Center の問題の障害追跡 」

I-Fabric 内でのリソースプールサーバーのフェイルオーバーは自動化されているため、新しいデバイスのフェイルオーバーと起動の後では、ユーザーが手動で実行しなければならない作業はほとんどありません。 フェイルオーバーの後に実行しなければならないすべての作業は、この章の特定の I-Fabric デバイスを専門に扱う節で説明されています。

デバッグレベル

デバッグの詳細の優先度に応じて、tspr.properties 構成ファイルてデバッグレベルを設定できます。 デバッグレベルが高ければ、ユーザーに提供されるログの情報は多くなります。 デバッグレベルは 9 に設定することをお勧めします。 デバッグ情報は tspr.debug.log ファイルで確認できます。 デバッグレベルを 9 に設定した場合の tspr.properties ファイルの例を次に示します。tspr.properties ファイル内のすべてのエントリは、次の形式である必要があります。

package name.class name.attribute=value

com.terraspring.core.sys.GridOS.debuglevel=9

障害のあるファームデバイスの処理

N1 Provisioning Server ソフトウェアは、ファーム内の全デバイスの可用性を積極的かつ自動的に監視して、論理サーバーファームデバイスの自動フェイルオーバーを実現します。 この監視を有効にするための特別な構成は必要ありません。 あるデバイスが使用不能であることをソフトウェアが検出した場合は、その物理デバイスを未使用デバイスのプールの同一デバイスと交換するため、ソフトウェアは必要な手順を自動的に実行します。 障害のある物理デバイスの交換では、障害のあるデバイスの役割を新しいデバイスが継承できるように、システムは構成を複製し、ストレージを新しいデバイスに論理的に再接続します。

障害が検出されると、システムは N1 Provisioning Server のキューイングメカニズムにフェイルオーバー「ジョブ」要求を発行して、フェイルオーバープロセスを開始します。 すべてのファームの起動とファームの更新の要求を処理するためにも、この同じキューイングメカニズムが使用されます。 現在の一連のタスクとそのステータスを表示するには、request -l コマンドを実行します。

監視システムがデバイス障害を検出する際のフェイルオーバー動作を指定する、次の 2 つのオプションがあります。

• 自動フェイルオーバーは、キューで replacefaileddevice 要求を発行し自動的に処理する N1 Provisioning Server から構成されます。 ユーザーの操作は必要ありません。

• 手動フェイルオーバーは、障害のあるデバイスを交換するための要求キューに、ブロックされた要求として replacefaileddevice 要求を発行する N1 Provisioning Server から構成されます。 要求を処理し、デバイスを交換するためには、要求をブロック解除する必要があります。 このためには、コマンド request -u request-ID を実行します。

ブロックされたフェイルオーバー要求は、(Control Center を介して行われるファーム更新要求を含む) そのファームに対するそれ以降のすべての要求をブロックします。 フェイルオーバー要求がブロック解除されるか削除されるまで、システムはそのファームに対するすべての変更を処理しません。

自動オプションを使用すると、要求がシステムの要求キューに入った時点で直ちにフェイルオーバーが処理されます。 手動オプションを使用すると、フェイルオーバー要求はシステムの要求キューでブロックされます。 その結果、ユーザーが要求をブロック解除してフェイルオーバーを許可するか、要求を削除してフェイルオーバーを中止するまで、ブロックされたフェイルオーバー要求と、障害のあるデバイスのファームに対するそれ以降のすべての要求は処理されません。

サーバーには実際には障害が発生しておらず、使用不能になっていただけである場合は、自動フェイルオーバーは多くのリソースを消費する可能性があります。 この場合、不必要なデバイス交換が行われる可能性があります。

フェイルオーバーメカニズムの動作を構成するには、/etc/opt/terraspring/tspr.properties ファイルのプロパティを変更します。

com.terraspring.cs.services.DeviceStatus.blockReqFailedDevice プロパティが false に設定されている場合、検出されたすべてのデバイス障害は、ブロックされたフェイルオーバー要求にはなりません。 このプロパティが true に設定されている場合は、検出されたすべてのデバイス障害はブロックされたフェイルオーバー要求になります。 このプロパティはデフォルトで true に設定されています。これが推奨設定です。

ファームデバイス障害の障害追跡

ファームデバイスの障害が検出されると、そのファームを管理する N1 Provisioning Server のセグメントマネージャに対して、監視ソフトウェアはデバイスの DOWN イベントを送信します。

監視ソフトウェアがデバイスの DOWN イベントを送信する対象は、アクティブなファームのみです。

セグメントマネージャが監視ソフトウェアから DOWN イベントを受信すると、セグメントマネージャは次の処理を実行します。

1. ブロックされた replacePhysicalDevices 要求が、そのデバイスを所有するファームのファームマネージャに送信されます。

2. 操作の警告を通知するため、クリティカルエラーメッセージがログファイルに記録されます。 セグメントマネージャにより生成されるクリティカルメッセージには、障害の発生したデバイス名とそれに対応するファーム ID が含まれます。

ファームデバイス障害を処理する

クリティカルなファームデバイス障害のメッセージを受け取ったら、コントロールプレーンサーバーで次の手続きを実行します。

自動フェイルオーバーのプロパティが true に設定されている場合は、処置は必要ありません。

手順

1. 次のように入力して、ファームの現在の要求を表示します。

   request -lf farm ID

2. リストを確認し、ファームのセグメントマネージャにより生成された、ブロックされた replacePhysicalDevices 要求の requestID を取得します。

   状態が QUEUED_BLOCKED と表示されている場所で、replacePhysicalDevice 要求により requestID を特定できます。 replacePhysicalDevices 要求の 2 番目の引数で、障害のあるデバイスの ID が指定されています。

3. 実際に物理デバイスに障害が発生していて、見かけだけのエラーではないことを確認します。 詳細については、「障害のあるコントロールプレーンサーバーの処理」を参照してください。 一時的なネットワーク障害が、見かけだけのエラーの原因になることがあります。

   • デバイスに障害が発生していない場合、またはデバイスを交換しない場合は、request -d request ID と入力して要求を削除します。

   • 障害のあるデバイスが 1 つのみである場合は、 request -u request-ID と入力して replacePhysicalDevices 要求をブロック解除し、デバイスの交換を開始します。

   • 複数のデバイスに障害がある場合は、多くの replacePhysicalDevices 要求が表示されます。

     1. 障害のある各デバイスのデバイス ID を特定します。

     2. 交換する全デバイスのデバイス ID を使用して、replacedevice コマンドを実行します。

        replacedevice farm-ID failed-device-ID failed-device-ID failed-device-ID

        以下に例を示します。

        replacedevice 5 19001 37001 2003

4. 障害のあるデバイスを交換した後、次のように入力して replacePhysicalDevices 要求を削除します。

   request -d request-ID

障害のあるコントロールプレーンサーバーの処理

コントロールプレーンサーバーに障害が発生した場合、サーバーの交換の詳細については、サーバーのドキュメントを参照してください。 コントロールプレーンデータベース (CPDB) 上の Oracle データベースが破損した場合、解決方法については http://sun.com/service/contacting/index.html を参照してください。

復元しなければならないファイルについては、第 5 章「コンポーネントのバックアップと復元 」を参照してください。 Control Center ソフトウェアや N1 Provisioning Server ソフトウェアなど、コントロールプレーンで動作するソフトウェアの再インストール方法の詳細については、『N1 Provisioning Server 3.1, Blades Edition インストールガイド』を参照してください。

コントロールプレーン上の障害のあるソフトウェアの処理

この節では、コントロールプレーン上のソフトウェアプロセスの障害追跡の方法について説明します。

監視マネージャのフェイルオーバー

監視マネージャに障害が発生した場合は、/opt/terraspring/sbin/mmd start コマンドを実行して、監視マネージャの再起動を試みます。 監視マネージャが再起動しない場合、監視マネージャを再インストールし、最新バックアップを復元する方法の詳細については、『N1 Provisioning Server 3.1, Blades Edition インストールガイド』を参照してください。

Control Center の障害

Control Center に障害が発生した場合は、/opt/terraspring/sunone/bin/appserv start コマンドを実行して、Control Center の再起動を試みます。 Control Center が再起動しない場合、Control Center ソフトウェアを再インストールし、最新バックアップを復元する方法の詳細については、『N1 Provisioning Server 3.1, Blades Edition インストールガイド』を参照してください。

N1 Provisioning Server の問題の診断

ほぼすべてのファーム操作は、非同期で実行されます。つまり、N1 Provisioning Server に対して要求 (メッセージ) がキューイングされ、要求を受け取った順序で N1 Provisioning Server は要求を処理します。 N1 Provisioning Server でのすべての保留状態および実行中の要求を表示するには、request コマンドを使用します。

ファーム操作の実行時に発生したすべてのクリティカルエラーは、監視システムを介して監視マネージャにより報告されます。 また、クリティカルメッセージは、N1 Provisioning Server の /var/adm/messages ファイルにも記録されます。 クリティカルエラーは、現在のファーム操作を終了させ、ファームをエラー状態に移行させます。 ファームがエラー状態である場合は、エラーが手動でクリアされるまで、キュー内の要求は処理できません。 エラーの原因である問題を解決した後、停止していた操作を再開できるように、ファームのエラー状態をリセットする必要があります。

/var/adm/messages ファイルだけでなく、ファイル /var/adm/tspr.debug にはさまざまなデバッグメッセージが記録されます。 このファイルの情報量は、/etc/opt/terraspring/tspr.properties ファイルで設定されているデバッグレベルによって決まります。 デフォルトのデバッグレベルは 9 です。クリティカルエラーが発生した場合、エラー原因の判定には、/var/adm/tspr.debug ファイルにある追加情報が役立ちます。

N1 Provisioning Server に関する問題を診断するには、図 7–1 の手順に従ってください。

図 7–1 N1 Provisioning Server の問題の診断

メッセージログファイルの形式

/var/adm/messages ファイルおよび /var/adm/tspr.debug ファイルに記録されるすべてのメッセージは、標準フォーマットです。 次に典型的なメッセージの例を示します。

Nov 12 17:22:57 sp3 java[23033]: [ID 398540 user.info] TSPR [sev=crit] [fmid=1211] [MSG6718] FM Activate: Ready timeout expired.

実行時にエラーまたは例外が発生した場合、例外の説明とともに、メッセージの一部として例外の名前が記録されます。

要求キューの管理

Control Center または farm コマンドを使用して開始されたファーム操作は、セグメントマネージャに対してキューイングされます。 セグメントマネージャにより、要求が処理され、実際に作業を行うファンドマネージャに対して要求がディスパッチされます。 問題を調査する際には、要求がファームマネージャへの途中で停止していないことを確認します。

セグメントマネージャの tspr.debug ファイルで処理中である要求に関連するクリティカルエラーまたはクリティカルメッセージが存在しない場合は、要求キューを調べて要求が処理されていることを確認します。

request コマンドは、要求キューの表示に使用します。

• N1 Provisioning Server の現在のすべての要求を表示するには、コマンド request -l を実行します。

• ファームに関する現在のすべての要求を表示するには、コマンド request -lf farm-ID を実行します。

• ファームに関する完了済みの要求をすべて表示するには、コマンド request -lcf farm-ID を実行します。

• ファームに関するすべての要求を表示するには、コマンド request -laf farm-ID を実行します。

request コマンドの詳細については、request のマニュアルページを参照してください。

要求がまだキュー内に QUEUED 状態で存在する場合は、その要求はまだ処理されていません。 ファームに対してこの要求よりも順位が先である要求が他に存在しない場合、要求キューが停止している場合があります。 次の節では、この問題の解決方法を説明します。

停止した要求の処理

要求が予定されていたサーバーによって処理されず、キュー内で放置状態になっている場合があります。 この節では、この問題の診断と解決の方法を説明します。

ブロックされた要求の確認

セグメントマネージャを起動してもキュー上のすべての要求が処理されているわけではない場合、一部の要求がブロックされている場合があります。 ブロックされた要求は、処理の前に手動で操作する必要があります。 ブロックされた要求の確認が完了すれば、要求をブロック解除して処理するか、要求を削除することができます。 ブロックされた要求は、request -u request-ID コマンドを実行してブロック解除するか、request -d request-ID コマンドを実行して削除します。

ブロックされた要求をクリアした後は、キュー内の要求は受け取られた順序で処理されます。

ファームキューハンドラがアクティブであることの確認

要求はブロックされているのではなく、キューイングされた状態で、ファームマネージャがまだ要求を処理していないだけである場合があります。 この場合は、ファームに ping を発行します。 ファームに ping コマンドを実行して、要求を処理するファームマネージャのキューハンドラを起動します。 このコマンドは、特にエラー状態であるファームに関する要求に適用します。 次のコマンドを実行して、ファームに ping を発行し、要求キューハンドラを起動します。

farm -p farm-ID

ファームがエラー状態であった (つまり、直前の操作がエラーで終了した) 場合、次のコマンドでエラーをリセットしてキューを移動します。

farm -pf farm-ID

障害のある電源およびスイッチ操作の要求の管理

障害のある電源またはスイッチ操作の要求を調べるには、ExpectTimedOut メッセージの tspr.debug ログを確認します。 電源操作の要求には、powerUp、 ispowerUp、および powerDown 操作が含まれます。 スイッチ操作の要求には、addPort、removeVlan、および removeAll 操作が含まれます。

N1 Provisioning Server がデバイスがアクセスできない場合、または N1 Provisioning Server がデバイスから予期せぬ出力を受け取った場合は、障害が発生する可能性があります。 障害が発生した場合は、次の項目を確認します。

1. デバイスの IP アドレスが正しく設定され、N1 Provisioning Server からそのデバイスへの接続が存在することを確認します。

2. N1 Provisioning Server から device -lv device-ID コマンドを実行して、このデバイスのすべてのログイン名とパスワードが正しいことを確認します。

3. ファームウェアがサポートされているバージョンであり、デフォルト設定に対して加えられたすべての変更が許容されているものであることを確認します。

さらにデバッグを行って問題を解決する必要がある場合は、次のプロパティで expect ログを有効にします。

• com.terraspring.drivers.util.expect.Expect.print=true

• com.terraspring.drivers.util.expect.Expect.output=log-name-path

tail -f log-name-path コマンドを実行して要求を再実行し、操作を表示します。

ファーム操作の障害追跡

次の表に、ファーム操作と関連する N1 Provisioning Server の障害追跡の問題を示します。 このリストはすべてを網羅してるわけではありません。 メッセージログファイルは、問題がファーム操作に関連しているかどうかを示しています。

ファームのエラーステータスコード

各ファームには、ファームが現在異常な状態であるかどうかを示す、ファームと関連付けられたエラーステータスコードがあります。

• エラーステータスコードが 0 であれば、正常な状態を表します。

• エラーステータスコードが 1000 であれば、ファームマネージャが要求を処理中であることを意味します。

• 0 または 1000 以外のエラーステータスコードは、ファームにエラーが発生していることを意味します。

要求の処理中、移行処理が正しく完了するたびにファームの内部状態は変化します。 ファームがある内部状態から別の内部状態に移行できないと、ファームの内部状態は変化せず、そのファームはエラー状態に設定されます。 エラーステータスコードの値は、失敗した内部状態の値です。

たとえば、ファームが状態 ALLOCATED (20) から状態 WIRED (30) への移行に失敗した場合、ファームの内部状態は ALLOCATED (20) のままで、ファームのエラーステータスコードは 30 に設定され、WIRED の状態に失敗したことを表します。 コードが 30 に設定される直前、コードは 1000 になり、要求が実行中であることを示します。

ファームのエラーが発生するたびに、システムログファイル /var/adm/messages ではクリティカルエラーメッセージが生成されます。

エラー状態が変化し、エラーステータスコードが 0 にクリアされるまで、ファームマネージャは追加のファーム要求を処理しません。

イメージの問題の障害追跡

次の表に、イメージが含まれるシナリオの障害追跡の説明を示します。 このリストはすべてを網羅してるわけではありません。 メッセージログファイルは、問題がイメージに関連しているかどうかを示しています。

イメージサーバーの問題追跡

イメージサーバーは、イメージを管理します。 イメージサーバーにはスタンドアロンのネットワークファイルサーバー (NFS) を使用可能で、またコントロールプレーンサーバー上で動作させることもできます。 詳細については、第 3 章「ソフトウェアイメージの管理 」を参照してください。

ギガビット Ethernet のサポート

イメージに Solaris オペレーティング環境用のギガビット Ethernet サポートが必要である場合は、システムがブートするたびに適切なドライバが読み込まれることを確認します。 次のコマンドを実行することで、管理対象のインタフェースのリストを初期化できます。

devfsadm
ifconfig -a plumb
ifconfig -a | grep flags | cut -d: -f1 | grep -v lo0> /etc/opt/terraspring/managed_interfaces

続いて、N1 Provisioning Server ソフトウェアでは管理しないインタフェースをコメントアウトすることで、/etc/opt/terraspring/managed_interfaces の内容を編集します。

ギガビット Ethernet カードに割り当てられるインスタンスは、常に 0 である必要があります。 たとえば、ce0, skge 0, alt0 となります。

監視の問題の障害追跡

この節では、一部の一般的な監視の問題を説明します。 問題を診断する方法と、可能な修正処置を紹介します。 監視の概念の解説については、第 4 章「監視とメッセージ」を参照してください。

最も一般的な問題には次のものがあります。

• 1 つまたは複数のリソースプールサーバーから UP メッセージが受信されない。

• Control Center の「Element Monitor」ウィンドウで、モニターに色が表示されない。

• UP メッセージが送信されたにもかかわらず、ファームが起動しない。

• 頻繁に UP メッセージと DOWN メッセージが受信される。

これらの問題の多くには、相互に関連する根本原因があります。 最も多い原因には次のものがあります。

• ネットワーク、DNS、または DHCP の問題。

• コントロールプレーンサーバーで監視プロセスが動作していない。

• リソースプールサーバーでエージェントプロセスが動作していない。

この節では、これらの症状の診断方法を説明します。 「監視に関する修正処置 」では、これらの問題を解決するための修正処置が説明されています。

1 つまたは複数のサーバーから UP メッセージが受信されない

次の条件が存在するかどうかを確認することで、コントロールプレーンサーバー上で UP メッセージの問題を確認できます。

• /var/adm/tspr.debug ファイルでは、メッセージは次のような形式になっています。

  "Still waiting for 1 device(s) in 2879974 ms"

• 次の例にあるように、ファームの起動では ERROR 50 が示されています。

  FARM_ID FARM_NAME CUSTOMER STATE ISTATE ERROR 123 Farm_Name Customer NEW DISPATCHED 50

次の図に、この問題の診断と解決に必要な手順を示します。

図 7–2 監視の問題の解決

上記の図は、次の一連の障害追跡を表しています。

1. ネットワーク、DNS、または DHCP の問題を確認します。 この方法の詳細については、「ネットワーク、DNS、または DHCP の問題 」を参照してください。

2. 監視プロセスがコントロールプレーンサーバー上で動作中であることを確認します。 詳細については、「監視プロセスがコントロールプレーン上で動作していない 」を参照してください。 この節の指示に従ってプロセスを再起動します。

3. エージェントプロセスがリソースプールサーバー上で動作中であることを確認します。 詳細については、「エージェントプロセスがリソースプールサーバー上で動作していない 」を参照してください。 エージェントプロセスが動作中でない場合は、この節の指示に従ってエージェントプロセスを再起動します。

Control Center の「Element Monitor」ウィンドウで、モニターに色が表示されない

ファーム固有のモニターが Control Center に表示されない場合があります。 この状態の原因としては、次のいずれかの問題が考えられます。

• サーバーでエージェントプロセスが動作していない。

• gw-mon-vip と Control Center サーバーソフトウェアの IP アドレスとのマッピングが、コントロールプレーンサーバーの /etc/hosts ファイルで設定されていない。

• Control Center 上のリスナーが動作していない。 この状態を確認する方法の詳細については、「コントロールプレーンサーバーから Control Center へのメッセージが機能していない 」を参照してください。

図 7–2 に、上記のエラー状態を診断および解決するために従うべき一連の手順を示します。 これらの問題の解決方法の詳細については、「コントロールプレーンサーバーから Control Center へのメッセージが機能していない 」を参照してください。

ファームが起動しない

監視システムにより UP メッセージが送信された場合であっても、セグメントマネージャが動作していない場合があります。 この場合、セグメントマネージャを再起動します。 この手順の詳細については、「ブロックされた要求の確認」を参照してください。

頻繁に UP と Down のメッセージが受信される

N1 Provisioning Server 上でのインタフェースの設定ミスの結果として、あるサーバーに関して多数の UP と DOWN のメッセージが受信される場合があります。

clearNicInterface コマンドを実行して、コントロールプレーンサーバー上の重複する Ethernet インタフェースをクリアします。 このコマンドの使用法の詳細については、マニュアルページを参照してください。

一般的な監視の症状の診断

数多くの問題に共通する数多くの症状が存在します。 この節では、次の症状を診断する方法を説明します。

• 「ネットワーク、DNS、または DHCP の問題 」

• 「監視プロセスがコントロールプレーン上で動作していない 」

• 「エージェントプロセスがリソースプールサーバー上で動作していない 」

• 「コントロールプレーンサーバーから Control Center へのメッセージが機能していない 」

ネットワーク、DNS、または DHCP の問題

ネットワーク、DNS、または DHCP の問題に関して、次の表の項目を確認します。

場合によっては、サーバーが ping の信号を受信できても、シングルユーザーモードでは telnet を使用しても到達不能であることがあります。 この問題を解決するには、コンソールポートに接続し、マルチユーザーモードでブートします。

監視プロセスがコントロールプレーン上で動作していない

監視プロセスに関する診断を確定させた後、次のコマンドを実行します。

/usr/ucb/ps -auxww | grep MM

監視プロセスが動作中である場合は、次の例のような出力が表示されます。

USER	 PID %CPU %MEM SZ  RSS TT   S START  TIME  COMMAND
root 14540 0.2	1.14 485 620 608? S Mar 05	 18:32 /bin/../java/bin/..
/bin/sparc/native_threads/java -Dsun.net.inetaddr.ttl=0 com.
terraspring.mon.MM 
root 9529  0.1	0.1	  976 672 pts/2 S 11:49:40 0:00 grep MM

監視プロセスが動作中でない場合は、次の例のような出力が表示されます。

USER PID %CPU %MEM  SZ  RSS TT     S  START TIME     COMMAND
root 9565 0.1  0.1  976 672 pts/2  S  11:50:28  0:00 grep MM

プロセスを再起動する方法の詳細については、「コントロールプレーンサーバーでの監視プロセスの再起動 」を参照してください。

エージェントプロセスがリソースプールサーバー上で動作していない

リソースプールサーバーでエージェントプロセスが動作していない可能性があります。 次のいずれかの方法で、この状態を確認します。

• コントロールプレーンサーバーで、次のコマンドを実行します。

  /opt/terraspring/sbin/mls -a IP address of host

  このコマンドを使用するためには、サーバーの IP アドレスの情報が必要です。

• 動作中であることを確認したいエージェント存在がするサーバーで、次のコマンドを実行します。

  /usr/ucb/ps -auxww | grep tspragt

  エージェントプロセスが動作中である場合は、次の例のような出力が表示されます。

  root 7652 0.1 0.1 976 656 pts/1 S 11:37:30 0:00 grep tspragt

  root 321 0.1 0.73167213816 ? S 16:26:37 0:10 /usr/bin/../java/bin/.. /bin/sparc/native_threads/java -Dsun.net.inetaddr.ttl=0 com.terraspring.mon.client.tspragt start 10.42.14.2

  エージェントプロセスが動作中でない場合は、次の例のような出力が表示されます。

  root 7709 0.1 0.1 976 656 pts/1 S 11:39:54 0:00 grep tspragt

プロセスを再起動する方法の詳細については、「リソースプールサーバーでのエージェントプロセスの再起動 」を参照してください。

コントロールプレーンサーバーから Control Center へのメッセージが機能していない

さまざまな理由により、コントロールプレーンサーバーと Control Center 間のメッセージが機能しない場合があります。 最も一般的な理由には次のものがあります。

• gw-mon-vip と Control Center サーバーソフトウェアの IP アドレスとのマッピングが、コントロールプレーンサーバーの /etc/hosts ファイルで設定されていない。 適切なエントリが存在することを調べて、この状態を確認します。

  以下に例を示します。

  10.5.131.19 gw-mon-vip

• Control Center サーバーソフトウェア上でリスナーが動作していない。 この状態を確認するには、コントロールプレーンサーバー上で finger test@gw-mon-vip を実行します。 予測される出力の例は、次の例のようになります。

  [gw-mon-vip]

  または

  [hostname]

監視に関する修正処置

この節では、監視の問題解決に対して適用できる数多くの修正処置を説明します。

コントロールプレーンサーバーでの監視プロセスの再起動

監視プロセスを再起動するには、コントロールプレーンサーバーで次のコマンドを実行します。

/opt/terraspring/sbin/mmd stop

このコマンドにより、関連するすべてのプロセスが停止されます。 監視プロセスを再起動するには、次のコマンドを使用します。

/opt/terraspring/sbin/mmd start

リソースプールサーバーでのエージェントプロセスの再起動

コントロールエージェントプロセスがサーバー上で停止した場合、次のコマンドを使用してサーバーでプロセスを起動します。

/etc/init.d/N1PSagt start

プロセスが再起動したことを確認するには、コントロールプレーンサーバーから次のコマンドを実行します。

/opt/terraspring/sbin/mls -a server IP address

エージェントが動作中である場合は、次のような出力が表示されます。

FARM_ID IP_ADDRESS TYPE STATE DB_STATE SINCE 134 10.9.0.35 Server UP UP Feb 05 14:15:32

エージェントがリアルタイム (STATE) ではダウンしている場合も、データベース状態は 5 分ごとに更新されるため、エージェントはまだデータベース (DB_STATE) で UP としてマークされている場合があります。 そのため、リアルタイムではアップであっても、データベース状態ではまだダウンである場合もあります。 次のような出力が表示されます。

FARM_ID IP_ADDRESS TYPE STATE DB_STATE SINCE 134 10.9.0.35 Server DOWN UP Feb 10 14:20:33

Control Center の問題の障害追跡

Control Center の作業中に発生する主な問題は、 Control Center と CPDB 間の接続がダウンしている、または Control Center データベースでパラメータの構成が間違っているなど、CPDB の接続に関連する問題です。

発生している問題がこれら 2 つの問題のどちらであるかを判別するには、次の手順に従います。

1. ブラウザを使用して Control Center に管理者としてログインします。

2. 「configuration tools」のセクションで「I-Fabrics」を選択して、I-Fabric のリストを表示します。

3. 「I-Fabrics List」で、接続を確認する必要がある I-Fabric を選択します。

4. 「Improper Configuration of these Properties may disrupt System Operation. Proceed with Caution.」 というダイアログが表示されたら 「OK 」をクリックします。

5. 「Property Name Property Value」ダイアログで、(主フィールドで定義されている) データベースサーバーの IP アドレスとそのポートをメモします。

6. IP アドレスが表示されていない場合は、Control Center が動作する URL の hostname に telnet します。

7. 次の telnet コマンドを実行します (手順 4 で取得した IP アドレスとポートは、それぞれ 10.0.0.18 と 1521 であると仮定されています)。

   telnet 10.0.0.18 1521

   Trying 10.0.0.18...

   次のような応答が表示された場合:

   Connected to cpdb

   Escape character is "^]"

接続は正常です。 Ctrl + C キーを押して telnet セッションを取り消します。

次のような応答が表示された場合:

telnet: Unable to connect to remote host: Connection refused

IP は正常ですが、CPDB データベースサーバーは動作中ではありません (または、別のポートで動作しています)。 リスナーポートを確認する方法の詳細については、DBA に連絡するか、データベースの販売元のドキュメントを参照してください。

ping 10.0.0.18

次のような結果が表示された場合:

no answer from 10.0.0.18

Control Center とデータベースサーバーホストとの間の通信が存在しません。 このエラーの原因としては、ルーティングの問題か、ダウンしているデータベースサーバーが考えられます。

CPDB への接続

Control Center から CPDB への接続の速度が遅すぎるため、タイムアウトを引き起こす場合があります。 この状態の原因は、作業負荷が大きすぎるため速度が低下している、データベースまたはネットワークです。 接続速度が遅い場合、タイムアウトを防止するには、Control Center の「I-Fabric Properties」画面の「timeout」フィールドの値を大きくします。 デフォルトは 30 秒です。

タイムアウトの間隔を大きくする

手順

1. Control Center の「Administration」画面にログインします。

2. 「Configuration Tools」の「I-Fabrics」を選択します。

   「I-Fabrics List」と「I-Fabrics Properties」画面が表示されます。

3. 「Timeout」フィールドの値を大きくします。

   このプロパティがまだ存在しない場合は、「Add Property」ボタンをクリックして作成します。