デバイスの接続が切断された場合の障害分離の仕組み(IBM LPAR)

デバイスに関するネットワークの問題をトラブルシュートできるように、sp は障害分離を使用して、アラームの根本原因を絞り込みます。仮想ネットワークの場合、Virtual Host Manager はデバイスとの直接接続によって得られる情報に加え、IBM LPAR AIM を介して IBM LPAR 技術によって提供される情報を使用します。多くの場合、標準 sp 障害管理は根本原因を正確に特定することができます。ただし、特殊な状況では、仮想ネットワークの問題を分離する方法は、標準的な方法の範囲を越えます。
casp1032jp
デバイスに関するネットワークの問題をトラブルシュートできるように、
CA Spectrum
 は障害分離を使用して、アラームの根本原因を絞り込みます。仮想ネットワークの場合、Virtual Host Manager はデバイスとの直接接続によって得られる情報に加え、IBM LPAR AIM を介して IBM LPAR 技術によって提供される情報を使用します。多くの場合、標準
CA Spectrum
 障害管理は根本原因を正確に特定することができます。ただし、特殊な状況では、仮想ネットワークの問題を分離する方法は、標準的な方法の範囲を越えます。
Virtual Host Manager が根本原因を検出するために使用する障害分離のタイプは、どのデバイスがアラームを出しているか、およびデバイスが生成するイベントのタイプによって異なります。以下のシナリオでは、2 つの固有の障害管理状況、および
CA Spectrum
 が仮想ネットワークにおけるネットワークのエラーをどのように分離するかを説明します。
シナリオ 1: IBM LPAR インスタンスが実行されていない
仮想環境では、仮想管理アプリケーションは
CA Spectrum
 が標準的なデバイス監視を介して検出するよりも詳しい詳細を提供できます。たとえば、IBM LPAR 仮想化技術は、IBM LPAR が「実行中」の状態から、「開いているファームウェア」状態など別の状態にいつ遷移するかを認識します。
IBM LPAR が実行中の状態でなくなり、
CA Spectrum
 と IBM LPAR との接続が切断されたにもかかわらず、IBM LPAR マネージャのプロキシ管理が中断されていない場合、
CA Spectrum
は以下のように根本原因を確定します。
  1. CA Spectrum
     が IBM LPAR との接続を失うと、接続切断アラームが生成されます。
  2. 次のポーリング サイクル中に、IBM LPAR マネージャ モデルは、IBM LPAR インスタンスに関する情報を収集するために IBM LPAR AIM をポーリングします。IBM LPAR 技術が IBM LPAR インスタンスを管理するため、IBM LPAR によって生成されたアラームの考えられる原因に関して、独自のビューを提供できます。
  3. IBM LPAR 技術によって、IBM LPAR が非実行モードであることが検出された場合、IBM LPAR Not Running アラームが生成されます。
    注:
     このアラームは、IBM LPAR が再実行された後の最初の IBM LPAR AIM ポーリング サイクルでクリアされます。
  4. Virtual Host Manager は、
    CA Spectrum
     によって作成された、対応する IBM LPAR Not Running アラームに接続切断アラームを関連付けます。Virtual Host Manager は IBM LPAR Not Running アラームの兆候として、接続切断アラームを表示します。
シナリオ 2: IBM LPAR Host がダウンしている
CA Spectrum
 が IBM LPAR ホスト上で実行されているすべての IBM LPAR と接続を失うと、
CA Spectrum
はアップストリームのルータおよびスイッチのステータスを確認します。これらのステータスに応じて、
CA Spectrum
 は以下のように根本原因を特定します。
  • 1 つ以上の IBM LPAR インスタンスのアップストリームのデバイスがすべて使用できない -- 標準
    CA Spectrum
     障害分離テクニックにより、以下のように根本原因を確定します。
    • Device Stopped Responding to Polls アラーム -- 任意の IBM LPAR に対して少なくとも 1 台のアップストリーム接続デバイスが起動している場合、IBM LPAR ホスト上で生成されます。
    • Gateway Unreachable アラーム -- アップストリーム接続デバイスが
      すべて
      ダウンしている場合、IBM LPAR ホスト上で生成されます。
  • IBM LPAR ホストに接続されたすべての IBM LPAR インスタンスに対して、少なくとも 1 台のアップストリーム デバイスを使用できる -- 
    CA Spectrum
     は、IBM LPAR ホストが根本原因であると推定し、以下のように対応します。
    1. IBM LPAR モデルに直接接続されるすべての IBM LPAR、ポートおよび FanOut は、標準的な障害分離アラームを生成します。
    2. Virtual Host Manager は、IBM LPAR ホスト モデルに対して Physical Host Down アラームを生成します。
    3. 影響を受けるデバイス(IBM LPAR、ポートおよび FanOut など)に対して生成される障害分離関連のアラームはすべて、物理ホスト ダウン アラームに関連付けられているため、物理ホスト ダウン アラームの兆候となります。これらの兆候アラームは、「物理ホスト ダウン」アラームの[影響度]タブの[兆候]テーブルに表示されます。
      注:
       Virtual Host Manager は IBM LPAR ホスト モデルごとに「仮想障害ドメイン」を作成します。このドメインには IBM LPAR ホストおよび IBM LPAR インスタンスに加え、IBM LPAR に直接接続されているすべてのポートと FanOut が含まれます。IBM LPAR ホストが「物理ホスト ダウン」アラームを生成すると、ドメイン内の標準的な障害分離アラームはすべてそのアラームに関連付けられます。これらのアラームが兆候として関連付けられると、IBM LPAR ホスト上の「物理ホスト ダウン」アラームが根本原因であることを示します。
    4. 影響を受けるデバイスはすべて、「物理ホスト ダウン」アラームの[影響度]タブの[管理ロスの影響度]テーブルに一覧表示されます。
      注:
      抑制されたデバイスには、対応するアラームが[兆候]テーブルにありません。
Example of the Alarm Detail dialog showing a Physical Host Down alarm on the IBM LPAR Host and the alarms on all managed IBM LPARs that are impacted
1 つまたは複数の IBM LPAR インスタンスのすべてのアップストリーム デバイスがダウンしている場合、
CA Spectrum
は、障害の原因が IBM LPAR ホストにあることを確実に主張できません。そのため、
CA Spectrum
 は Physical Host Down アラームをクリアし、標準
CA Spectrum
障害分離テクニックを適用します。