CA Spectrum - 10.3.2 - Japanese - Japan

管理されたネットワーク ヘルス

内容
casp1032jp
内容
ネットワーク ヘルスはビジネス サービスに影響し、ビジネス サービスのネットワーク ヘルスを監視する 
CA Spectrum
 に影響することもあります。ビジネス サービスのヘルスへの注目が増すと、ビジネスへの影響が明らかでない慢性的なネットワーク ヘルスの問題が見落とされることがあります。ビジネス サービスを監視し、ネットワーク層までの障害を解決するには、インフラストラクチャ管理戦略で絶え間ない変化を監視して対応する必要があります。慢性的なネットワーク ヘルスの問題により、変更の量が増え、結果として 
CA Spectrum
 の処理が桁違いに増加する可能性があります。  
コア ルータ上の単一のリンクが 1 分間に何回もダウンして復帰する、"フラッピング" と呼ばれる状態を想像してください。この場合、
CA Spectrum
 はリンクダウンおよびリンクアップ トラップを受信します。また、リンクがフラップするたびにインターフェースのステータスをポーリングします。さらに、このようなリンクのフラッピングにより、その背後にあるネットワーク内の多くのデバイスとの接続が一時的に失われる可能性があります。結果として、
CA Spectrum
 がこのネットワークのデバイスの状態を特定するための処理を行うことで、ポーリングおよび障害分離のオーバーヘッドが増加します。ただし、
CA Spectrum
 のキャパシティに関しては、この単一のケースは問題ではありません。
しかし、複数のコア ルータとスイッチのそれぞれに "フラッピング" インターフェースがある、別のシナリオを想像してみてください。この例における、何千ものリンクダウン/リンクアップ トラップ、その後のポーリング、および障害分離のオーバーヘッドの影響により、
CA Spectrum
 で持続的に高い作業負荷が発生する可能性があります。作業負荷の増加には、何万ものアラームが絶えず生成されてクリアされていることも理由に挙げられます。
通常は、また前記の 2 つのケースでは、ネットワーク ヘルスの問題を特定して解決するためのイベントおよびアラームに関するデータが
CA Spectrum
 によって提供されます。
CA Spectrum
 オペレータは、ネットワーク ヘルスの問題に注意を払い、問題解決の手順を実行するか、または 
CA Spectrum
 を調整して影響を軽減する必要があります。前の例では、フラッピング インターフェースの問題を解決することが解決策です。
CA Spectrum
 と管理対象デバイスの間の接続の信頼性が一般に低い場合、またはデバイスの応答が遅い場合は、ポーリング タイムアウトのしきい値および再試行のしきい値を確認します。これを行わないと、ポーリングの失敗により多くの誤警告が発生し、障害分離のオーバーヘッドが増加する場合があります。
最後に、
CA Spectrum
 コンポーネント（
SpectroSERVER
 および OneClick サーバ）の間の接続は、重要な注意点です。基本的なサーバ間通信からクロス サーバ検索までのすべてが、ネットワーク接続に依存します。そのため、サーバ間の信頼性の高い通信が 
CA Spectrum
 のパフォーマンスにとって重要です。
Spectrum Report Manager
 （SRM）
これまでに提供してきたアドバイスのほとんどでは、
CA Spectrum
 展開の主なリアルタイムの側面に重点が置かれています。多くのカスタマは、履歴データ収集、分析、およびレポート作成についても 
Spectrum Report Manager
 に依存するようになっています。Report Manager には、接続されているすべての
SpectroSERVER
 からのデータをアーカイブする個別のデータベースが含まれています。そのため、システムのディスク容量およびディスク I/O パフォーマンスに特に注意を払ってください。格納されているデータの量、不要なデータをフィルタする機会、およびレポートのサイズによっては、チューニングが必要になることがあります。
ベスト プラクティスの推奨事項は、イベント履歴の格納に必要な合計データベース サイズを決定してから、そのディスク パーティションに 2 倍の領域を割り当てて、一時的な領域要件に対応することです。トピック「Spectrum Report Manager サイジング ガイダンス」では、ディスク容量要件の計算に役立つアドバイスと数式を提供します。
Spectrum Report Manager
 のパフォーマンスとキャパシティに関する以下の考慮事項も重要です。
  • Report Manager のパフォーマンスに対してデータおよびシステム リソースのボリュームを考慮します。小さいボリュームからレポートを実行すると、レポートの生成が失敗する可能性が最小になります（特に、イベントおよびアラーム レポートの場合）。データのボリュームを小さくすると、データベース クエリのレスポンス時間が短くなります。
  • 結果セットが大きい場合、または大量のデータの並べ替えやグループ化が行われる場合は、データベースはディスクに結果を書き込みます。このアクティビティは Report Manager のパフォーマンスに影響します。
  • イベント レポートを生成しないで大量のイベントを生成する環境の場合は、イベント テーブルを定期的にパージすることを考えます。このテーブルをパージすると、レポートを作成する DB システムのスペースが節約されます。
  • 特定のイベント セットに対してイベント レポートを生成する場合は、必要のないイベント タイプをパージすることを考えます。または、選択したイベント タイプでアラーム、アセット、可用性、またはその他のレポートを生成する必要がない場合には、レポート データベースに到達する前にこれらのイベントをフィルタリングすることを考えます。 詳細については、「Report Manager のインストール」を参照してください。
  • ご使用の環境でレポートには含まれないモデルの大量のイベントを生成する場合、レポート データベースからのこれらのイベントをフィルタ リングすることを検討してください。 「Report Manager のインストール」に詳細が示されています。
  • レポート自体の一部のフィルタ リング メカニズムにより、パフォーマンスの問題が発生する場合があります。 この件についてはまだ調査中ですが、レポートで使用した場合、アラームおよびイベント フィルタにより、パフォーマンスが低下するという事例証拠があります。 可能な場合は、使用の制限を試みてください。
  • CA サポートには、
    Spectrum Report Manager
     がレポート機能に対して使用する CA Business Intelligence （CABI）コンポーネントに関するベスト プラクティスの推奨事項がいくつかあります。これらの考慮事項は、CABI を使用するすべての CA 製品に適用されます。詳細については、CA サポートまでお問い合わせください。
Spectrum Report Manager
 サイジング ガイダンス
以下の数式を使用して、ユーザが指定した期間レポート データベースをサポートするのに必要なディスク空き領域を概算できます。
必要な総ディスク容量（GB 単位）は次のようになります。
((# of devices) * (avg # of events per device per day) * (# of days of storage desired) * (avg size of event in KB)) / 1048576
  • デバイスの数
    環境固有の値です。この値を指定するときは、将来の増大を考慮に入れます。
  • 1 日の 1 デバイス当たりの平均イベント数
    （1）1 日の間に生成されて、（2）単一のデバイス モデルの作成と関連付けられる、イベントの総数を表します。この合計には、関連するアプリケーション、ポート、およびインターフェースの各モデルに起因するイベントがすべてを含まれます。この値を最も簡単に概算するには、1 日の間に 1 つの 
    SpectroSERVER
     で生成されたイベントの総数を調べます。その総数を、その
    SpectroSERVER
     でモデリングされたデバイスの数で割ります。
  • 必要な保管日数
    環境固有の値です。
  • KB 単位でのイベントの平均サイズ
    単一のイベントがレポート データベースで最終的に消費するディスク空き領域の概算値です。この値の単位は KB です。
  • 1048576
    前の式の積をこの値で割って、GB 単位の測定値を取得します。
デバイスの数および必要な保存日数についてはおそらくユーザごとに考えがあります。その場合、計算に必要な変数は 2 つだけです。
  • 1 日のデバイス当たりの平均イベント数
    環境固有の値です。特定の日に生成されるイベントの平均数を調べるには、DDMDB でクエリを実行します。
    CA Spectrum
     の新規ユーザの場合、または平均イベント数の決定方法がわからない場合は、妥当なデフォルト値を使用します。1 日当たり、1 デバイスごとに 300 のイベントの場合、500 のデバイスでは 1 日当たり 150,000 イベントになります。手始めとしてのデフォルト値の目安は 300 です。
    デバイス 1 つ当たりで生成される日単位の平均イベント数を概算するには、まず、毎日生成されるイベント数を把握する必要があります。以下のクエリでは、過去 10 日の間に発生したイベントの合計数を返します。
    SELECT date(from_unixtime(utime)) as x, count(*) as cnt
    FROM event GROUP BY x
    ORDER BY x DESC LIMIT 10;
    以下のクエリでは、日数と最もビジーな 10 日の間に発生したイベント数を返します。
    SELECT date(from_unixtime(utime)) as x, count(*) as cnt
    FROM event GROUP BY x
    ORDER BY cnt DESC LIMIT 10;
    これらのクエリの結果を使用して、合理的なイベント数を求めます。イベント数がわかれば、その値を、そのサーバでモデリングされたデバイスの総数で割ります。結果は 1 日当たり、1 デバイス当たりの平均イベント数です。
  • レポート データベースのイベントの平均サイズ（KB）
    平均的なイベントと対応するレコードを格納する適切な容量としては、1 KB をお勧めします。ほとんどのイベントに大量のデータが含まれている場合、この値は明らかに上昇します。また、イベントのタイプはデータ サイズに影響します。アラーム イベントは、複数のレポート テーブル レコードに変換されます。NCM イベントは、単一のテーブル（イベント）に影響するだけです。ただし、動作を一般化することが目的ならば、1 KB は適切な値であると思われます。
サイジング ガイダンスの例
必要な記憶容量の計算の例を以下に示します。
例 A
 - 環境には 600 のデバイスが含まれ、4 年（1460 日）間データを保存する必要があります。
注
： デバイス当たりのイベント生成数はわからないので、デフォルトの 300 を使用します。
格納する必要がある総データ量（GB）：
(600 * 300 * 1460 * 1) / 1,048,576 = 
262,800,000 / 1,048,576 =
250 GB
  • 例 B
     - 3 つのサーバに 1900 のデバイスがあり、2 年（730 日）間データを保存する必要があります。デバイス 1 つ当たりのイベント数を 1 日当たり平均 400 と見なします。
    注
    ： この例では、3 つのサーバがあるという事実を無視します。
    格納する必要がある総データ量（GB）：
    (1900 * 400 * 730 * 1) / 1,048,576 =
554,800,000 / 1,048,576 =
530 GB

Content feedback and comments