アベイラビリティ : ハイ アベイラビリティ

ベースライン プロセス: ベスト プラクティス White Paper

2003 年 7 月 9 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 4 日) | フィードバック

目次

概要
ベースライン
     ベースラインを使用する理由
     ベースラインの概要
     ベースラインの目標
コア ベースラインのフローチャート
ベースラインの手順
     ステップ 1: ハードウェア、ソフトウェア、および構成インベントリをコンパイルする
     ステップ 2: SNMP MIB がルータでサポートされていることを確認する
     ステップ 3: ルータから特定の SNMP MIB オブジェクトへポーリングと記録を行う
     ステップ 4: データを分析してしきい値を決定する
     ステップ 5: 特定した直接的な問題を修正する
     ステップ 6: しきい値モニタリングをテストする
     ステップ 7: SNMP または RMON を使用してしきい値モニタリングを実装する
追加 MIB
     ルータ MIB
     Catalyst スイッチ MIB
     シリアル リンク MIB
RMON アラームとイベント設定コマンド
     アラーム
     イベント
RMON アラームとイベントの実装
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、可用性の高いネットワークを構築するためのベースラインのコンセプトと手順を説明します。 目的を達成するための、ネットワークのベースラインおよびしきい値を決める重要な要素についての説明も含まれます。 また、シスコの High Availability Services(HAS)チームが認める最適な方法のガイドラインに基づく、ベースラインとしきい値のプロセスと実装に関する重要な詳細情報も提供します。

この文書では、ベースラインのプロセスを手順を追って実行します。 現在の Network Management System(NMS; ネットワーク管理システム)の製品によっては、このプロセスを自動化できますが、自動ツール、手動ツールのいずれを使用しても、ベースラインのプロセス自体は同じです。 これらの NMS 製品を使用する場合は、個別のネットワーク環境に適するようにデフォルトのしきい値設定を調整する必要があります。 有効で正確なしきい値を、プロセスに選択することが重要です。

ベースライン

ベースラインを使用する理由

ベースライン プロセスによって、ネットワーク内のリソース制限に関する重大な問題を認識して、適切に対処できます。 これらの問題は、コントロール プレーン リソースまたはデータ プレーン リソースとして説明できます。 コントロール プレーン リソースは、装置内の特定のプラットフォームやモジュールに対して一意であり、次の事項をはじめとする多数の問題の影響を受けやすくなっています。

  • データの使用

  • イネーブルにしている機能

  • ネットワーク設計

コントロール プレーン リソースには、次のようなパラメータが含まれます。

  • CPU 利用率

  • メモリの利用率

  • バッファの利用率

データ プレーン リソースは、トラフィックのタイプと数量の影響しか受けず、リンクの利用率とバックプレーンの利用率を含みます。 重要なエリアのリソース利用率にベースラインを導入すると、深刻なパフォーマンスの問題や、さらに悪い、ネットワークの崩壊などを回避できます。

音声やビデオなどの遅延の影響を受けやすいアプリケーションの導入により、ベースラインはより重要になっています。 一般的な Transmission Control Protocol/Internet Protocol(TCP/IP)アプリケーションは、一定の遅延を許容できます。 一方、音声とビデオのアプリケーションの場合は、User Datagram Protocol(UDP)に基づいており、再転送やネットワークの輻輳を許容しません。

アプリケーションが混在する環境では、ベースラインは、コントロール プレーンおよびデータ プレーンの両リソースに関する利用率の問題を理解するために役立ちます。これによって、正常な状態を維持できるように、変更やアップグレードを事前に計画できます。

データ ネットワークは、長年使用されてきました。 最近まで、ネットワークを稼動することは、多少のエラーも比較的許容されていました。 Voice over IP(VoIP)などの遅延の影響を受けやすいアプリケーションが急速に受け入れられるにつれて、ネットワークの稼動は、より困難になるとともに高い精度が要求されています。 ネットワーク管理者が安定した基礎に基づいてより正確にネットワークを管理するためには、ネットワークの稼動方法に関する情報を把握することが重要です。 そのためには、ベースラインと呼ばれるプロセスを導入する必要があります。

ベースラインの概要

ベースラインとは、定期的な間隔でネットワークを調査して、ネットワークが設計どおりに稼動していることを確認するプロセスです。 その時点でのネットワークの状態を詳細に記述した、単なるレポートではありません。 ベースラインのプロセスに従うと、次の情報を入手できます。

  • ハードウェアとソフトウェアの状態に関する貴重な情報を入手できる。

  • ネットワーク リソースの現在の利用率を確認できる。

  • ネットワークのアラームしきい値を正確に決定できる。

  • 現在のネットワーク問題を認識できる。

  • 将来の問題を予測できる。

ベースラインを確認する別の方法を次の図で説明します。

65400.gif

ネットワークのブレーク ポイントを示す赤いラインは、ネットワークがブレークするポイントを示します。このポイントは、ハードウェアおよびソフトウェアの動作方法に関する情報に基づいて決まります。 ネットワーク負荷を意味する緑のラインは、新しいアプリケーションの追加やその他の要因により、ネットワークの負荷が自然に増えていく状態を示します。

ベースラインの目標は、次の事項を確認することです。

  • ネットワークが緑のラインのどの位置にいるのか。

  • ネットワーク負荷の増加速度はどのくらいか。

  • 可能な場合、2 つのラインがちょうど交差するポイントを予測する。

定期的にベースラインを実行することで、現在の状態を確認し、さらに障害がいつ発生するかを推定して、前もって対策を取ることができます。 さらに、ネットワークのアップグレードについて、予算額をいつ、どこで、どう使用するかを、情報に基づいて決定できます。

ベースラインの目標

ベースラインの目標は、次の事項を実行することです。

  1. ネットワーク装置の現在の状況を確認する。

  2. その状況を標準的なパフォーマンスのガイドラインと比較する。

  3. ネットワーク装置の状況がガイドラインを超えたら、警告するようにしきい値を設定する。

データ容量が大きく、しかもそのデータの分析にも時間がかかるため、ベースラインの範囲をまず限定して、プロセスを学習しやすくします。 ネットワークのコア部分から開始するのが、最も合理的で、通常、最も有益です。 ネットワークのこの部分は、通常、最も小さく、しかも最高の安定性が求められるためです。

簡単に説明できるように、この文書では、1 つの重要な Simple Network Management Protocol Management Information Base(SNMP MIB; 簡易ネットワーク管理プロトコル管理情報ベース)、cpmCPUTotal5min にベースラインを実行する方法を説明します。 cpmCPUTotal5min は、Cisco ルータの central processing unit(CPU)の平均的な崩壊が 5 分であることを示す、コントロール プレーンのパフォーマンス インジケータです。 このベースラインは、Cisco 7000 シリーズのルータで実行します。

プロセスを学習し終えたら、大規模な SNMP データベース内の任意のデータに適用できます。次のような SNMP データベースは、ほとんどの Cisco 装置に用意されています。

  • Integrated Services Digital Network(ISDN)の使用状況

  • Asynchronous Transfer Mode(ATM)のセル廃棄

  • 空いているシステム メモリ

コア ベースラインのフローチャート

次のフローチャートでは、コア ベースライン プロセスの基本的なステップを示しています。 これらのステップを実行するときに使える製品やツールも用意されていますが、柔軟性や使いやすさの点で差があります。 ベースラインに NMS ツールを使用する予定でも、ベースラインのプロセスを学習し、ネットワークの実際の動作を理解することはよい練習になります。 ほとんどのツールは本質的には同じことをするため、このプロセスにより、いくつかの NMS ツールの動作方法に関する疑問が解決する場合があります。

65402.gif

ベースラインの手順

ステップ 1: ハードウェア、ソフトウェア、および構成インベントリをコンパイルする

さまざまな理由から、ハードウェア、ソフトウェア、および構成のインベントリをコンパイルすることは重要です。 最初に、Cisco SNMP MIB は現在実行している Cisco IOS リリースに固有な場合があります。 MIB オブジェクトによっては、新しいものと交換されたり、また完全に破棄されます。 データ収集後には、ハードウェアのインベントリが最も重要です。これは、最初のベースライン実行後に、Cisco 装置上の CPU のタイプ、メモリ容量などに基づいてしきい値を設定する場合が多いためです。 構成インベントリも、現在の構成を確認する意味で重要です。 ベースラインを実行してバッファの調整などを行ってから、装置の構成を変更する場合もあります。

Cisco ネットワークの場合、ベースラインのステップ 1 の部分を最も効率的に実行するには、CiscoWorks2000 Resource Manager Essentials(Essentials)を使用します。 Essentials がネットワークに正確にインストールされていれば、そのデータベース内にある全装置の現在のインベントリが含まれているので、 問題の有無を確認するには、そのインベントリを参照するだけで済みます。

次の表は、Essentials からエクスポートされた Cisco Router Class ソフトウェアのインベントリ レポートを Microsoft Excel で編集した例です。 このインベントリから、12.0x と 12.1x の Cisco IOS リリースに存在する SNMP MIB データと Object Identifier(OID; オブジェクト識別子)を使用する必要があることに注意してください。

装置名

ルータのタイプ

バージョン

ソフトウェアのバージョン

field-2500a.embu-mlab.cisco.com

Cisco 2511

M

12.1(1)

qdm-7200.embu-mlab.cisco.com

Cisco 7204

B

12.1(1)E

voip-3640.embu-mlab.cisco.com

Cisco 3640

0x00

12.0(3c)

wan-1700a.embu-mlab.cisco.com

Cisco 1720

0x101

12.1(4)

wan-2500a.embu-mlab.cisco.com

Cisco 2514

L

12.0(1)

wan-3600a.embu-mlab.cisco.com

Cisco 3640

0x00

12.1(3)

wan-7200a.embu-mlab.cisco.com

Cisco 7204

B

12.1(1)E

172.16.71.80

Cisco 7204

B

12.0(5T)

Essentials がネットワークにインストールされていない場合は、UNIX ワークステーションから UNIX コマンドライン ツール snmpwalk を使用して、IOS バージョンを確認できます。 これを次の例で示します。 このコマンドの機能がわからない場合は、UNIX のプロンプトで man snmpwalk とタイプすると、詳細が表示されます。 どの MIB OID をベースラインにするかを選択する場合、IOS バージョンが重要になります。これは MIB オブジェクトが IOS に依存しているためです。 また、ルータのタイプを確認しておくと、後で、CPU、バッファなどにしきい値を設定するときに役立つことに留意してください。

nsahpov6% snmpwalk -v1 -c private 172.16.71.80 system
  system.sysDescr.0 : DISPLAY STRING- (ascii): Cisco Internetwork Operating System Software
  IOS (tm) 7200 Software (C7200-JS-M), Version 12.0(5)T, RELEASE SOFTWARE (fc1)
  Copyright (c) 1986-2001 by cisco Systems, Inc.
  Compiled Fri 23-Jul-2001 23:02 by kpma
  system.sysObjectID.0 : OBJECT IDENTIFIER:
  .iso.org.dod.internet.private.enterprises.cisco.ciscoProducts.cisco7204
  

ステップ 2: SNMP MIB がルータでサポートされていることを確認する

これで、ベースラインのためにポーリングする装置のインベントリが用意できたので、ポーリングする OID を選択し始めることができます。 必要なデータが実際にある場所を事前に確認できれば、ストレスも大幅に減ります。 cpmCPUTotal5min MIB オブジェクトは、CISCO-PROCESS-MIB にあります。

ポーリングする OID を探すには、Cisco の CCO ウェブ サイトにある変換テーブルが必要です。 Web ブラウザからこの Web サイトにアクセスするには、Cisco MIB ページにアクセスして、OID のリンクをクリックします。

FTP サーバからこの Web サイトにアクセスするには、ftp://ftp.cisco.com/pub/mibs/oid/ とタイプします。 このサイトから、デコードされ、OID 番号によってソートされた特定の MIB をダウンロードできます。

次の例に、CISCO-PROCESS-MIB.oid テーブル一部を示します。 この例は、cpmCPUTotal5min MIB の OID が .1.3.6.1.4.1.9.9.109.1.1.1.1.5 であることを示しています。

注:OID の先頭に「.」を付けることを忘れないでください。そうしないと、その OID に対してポーリングを実行しようとする際にエラーが発生します。  また、OID をインスタンスにするには、OID の最後に「.1」を追加する必要があります。 これによって、探している OID のインスタンスが装置に伝えられます。 ルータに複数の CPU が搭載されている場合などは、OID に特定のデータ タイプのインスタンスが複数、含まれる場合があります。

ftp://ftp.cisco.com/pub/mibs/oid/CISCO-PROCESS-MIB.oid
  ### THIS FILE WAS GENERATED BY MIB2SCHEMA
  "org" "1.3"
  "dod" "1.3.6"
  "internet" "1.3.6.1"
  "directory" "1.3.6.1.1"
  "mgmt" "1.3.6.1.2"
  "experimental" "1.3.6.1.3"
  "private" "1.3.6.1.4"
  "enterprises" "1.3.6.1.4.1"
  "cisco" "1.3.6.1.4.1.9"
  "ciscoMgmt" "1.3.6.1.4.1.9.9"
  "ciscoProcessMIB" "1.3.6.1.4.1.9.9.109"
  "ciscoProcessMIBObjects" "1.3.6.1.4.1.9.9.109.1"
  "ciscoProcessMIBNotifications" "1.3.6.1.4.1.9.9.109.2"
  "ciscoProcessMIBConformance" "1.3.6.1.4.1.9.9.109.3"
  "cpmCPU" "1.3.6.1.4.1.9.9.109.1.1"
  "cpmProcess" "1.3.6.1.4.1.9.9.109.1.2"
  "cpmCPUTotalTable" "1.3.6.1.4.1.9.9.109.1.1.1"
  "cpmCPUTotalEntry" "1.3.6.1.4.1.9.9.109.1.1.1.1"
  "cpmCPUTotalIndex" "1.3.6.1.4.1.9.9.109.1.1.1.1.1"
  "cpmCPUTotalPhysicalIndex" "1.3.6.1.4.1.9.9.109.1.1.1.1.2"
  "cpmCPUTotal5sec" "1.3.6.1.4.1.9.9.109.1.1.1.1.3"
  "cpmCPUTotal1min" "1.3.6.1.4.1.9.9.109.1.1.1.1.4"
  "cpmCPUTotal5min" "1.3.6.1.4.1.9.9.109.1.1.1.1.5"
  

MIB OID が使用可能であり、動作していることを確認するために、MIB OID をポーリングする 場合は 2 つの一般的な方法があります。 時間を無駄にしないように、MIB OID のポーリングは、大量のデータ収集を開始する前に実行します。存在しないデータをポーリングしても、データベースに何も得られないからです。 MIB OID をポーリングする 1 つの方法に、HP OpenView Network Node Manager(NNM)、または CiscoWorks Windows などの NMS プラットフォームから MIB ウォーカを使用し、チェックする OID を入力する方法があります。

次に、HP OpenView SNMP MIB ウォーカの例を示します。

Baseline_Fig3.gif

MIB OID を簡単にポーリングする別の方法は、次の例に示すように、UNIX コマンド snmpwalk を使用することです。

nsahpov6% cd /opt/OV/bin
  nsahpov6% snmpwalk -v1 -c private 172.16.71.80 .1.3.6.1.4.1.9.9.109.1.1.1.1.5.1
  cisco.ciscoMgmt.ciscoProcessMIB.ciscoProcessMIBObjects.cpmCPU.cpmCPUTotalTable.cpmCPUTotalEntry.cpmCPUTotal5min.1 : Gauge32: 0
  

この 2 つの例では、MIB は 0 の値を戻しており、このポーリング サイクルの間、CPU の利用率が平均して 0 % であったことを意味します。 装置が正確なデータを戻さないトラブルがある場合は、装置に PING を実行したり Telnet を使用して装置にアクセスします。 それでもまだ問題が解決しない場合、SNMP の構成と SNMP のコミュニティ ストリングをチェックします。 問題を解決するには、別の MIB または IOS の他のバージョンを探す必要がある場合があります。

ステップ 3: ルータから特定の SNMP MIB オブジェクトへポーリングと記録を行う

MIB オブジェクトをポーリングして、その出力結果を記録する方法がいくつかあります。 市販の製品、シェアウェア製品、スクリプト、およびベンダーのツールを利用できます。 すべてのフロントエンド ツールは、SNMP の get プロセスを使用して情報を取得します。 主に、構成の柔軟性とデータをデータベースに記録する方法が異なります。 もう一度、プロセッサ MIB を参照して、各種の方法がどう動作するかを確認してください。

OID がルータでサポートされることがわかったので、OID をポーリングする頻度およびその記録方法を決める必要があります。 シスコでは、5 分間隔で CPU MIB をポーリングすることをお勧めしています。 時間の間隔が短くなると、ネットワークまたは装置に対する負荷が増します。どちらにしても、MIB の平均的なポーリング間隔は 5 分なので、平均値以上にポーリングしても意味がありません。 また、一般的に推奨されるベースライン ポーリングの実行期間は、少なくとも 2 週間なので、ネットワーク上の最低 2 週間のビジネス サイクルを分析できます。

次の画面では、HP OpenView Network Node Manager version 6.1 によって MIB オブジェクトを追加する方法を示しています。 メイン画面から Options > Data Collection & Thresholds の順に選択します。

Baseline_Fig5.gif

次に Edit > Add > MIB Objects の順に選択します。

Baseline_Fig6.gif

メニューから、OID 文字列を追加して Apply をクリックします。 これで、HP OpenView プラットフォームに MIB オブジェクトが入力されたので、ポーリングすることができます。

Baseline_Fig7.gif

次に、この OID について、ポーリングするルータを HP OpenView に指示する必要があります。

Data Collection メニューから、Edit > Add > MIB Collections の順に選択します。

Baseline_Fig8.gif

Source フィールドには、ポーリングするルータの DNS 名または IP アドレスを入力します。

Set Collection Mode リストから Store, No Thresholds を選択します。

ポーリング間隔を、5m(5 分間隔)に設定します。

Apply をクリックします。

Baseline_Fig9.gif

変更を有効にするには、File > Save の順に選択する必要があります。

データ収集が適切に設定されたことを確認するには、ルータの collection summary 行を強調表示し、Actions > Test SNMP の順に選択します。 この結果、コミュニティ ストリングが正確であるかどうか、および OID の全インスタンスがポーリング対象となっているかどうかをチェックできます。

Baseline_Fig10.gif

Close をクリックし、データ収集を 1 週間実行します。 1 週間が終わったら、データを取り出して分析します。

データを分析しやすくするには、ASCII ファイルにデータをダンプして、Microsoft Excel などの表計算ツールにインポートします。 HP OpenView NNM を使用して同じことを実行する場合、コマンドライン ツール snmpColDump を使用できます。 設定した収集はそれぞれ、/var/opt/OV/share/databases/snmpCollect/ ディレクトリ内にあるファイルに書き込まれます。

次のコマンドを使用して、testfile という名前の ASCII ファイルにデータを抽出します。

snmpColDump /var/opt/OV/share/databases/snmpCollect/cpmCPUTotal5min.1 > testfile
  

注:cpmCPUTotal5min.1 は、OID のポーリング開始時に HP OpenView NNM が作成したデータベース ファイルです。 

作成されたテスト ファイルは、次の例のように表示されます。

03/01/2001 14:09:10 nsa-gw.cisco.com 1
  03/01/2001 14:14:10 nsa-gw.cisco.com 1
  03/01/2001 14:19:10 nsa-gw.cisco.com 1
  03/01/2001 14:24:10 nsa-gw.cisco.com 1
  03/01/2001 14:29:10 nsa-gw.cisco.com 1
  03/01/2001 14:34:10 nsa-gw.cisco.com 1
  03/01/2001 14:39:10 nsa-gw.cisco.com 1
  03/01/2001 14:44:10 nsa-gw.cisco.com 1
  03/01/2001 14:49:10 nsa-gw.cisco.com 1
  03/01/2001 14:54:10 nsa-gw.cisco.com 1
  03/01/2001 14:59:10 nsa-gw.cisco.com 1
  03/………

テスト ファイルの出力結果が UNIX 端末に表示されたら、File Transfer Protocol(FTP)を使用して各自の PC に転送できます。

自分のスクリプトを使用してもデータを収集できます。 そのためには、5 分ごとに CPU OID に対して snmpget コマンドを実行して、結果を .csv ファイルにダンプします。

ステップ 4: データを分析してしきい値を決定する

データの収集も終わったので、分析を開始できます。 この段階のベースラインでは、しきい値を設定します。しきい値を設定することで、パフォーマンスや障害を正確に測定でき、しかもしきい値のモニタリングをオンにしておくと、アラームが発生し過ぎません。 最も簡単な設定方法の 1 つは、データを Microsoft Excel などの表計算にインポートしてから、散布図にプロットする方法です。 この方法を使用すると、特定のしきい値についてある装置を監視している場合に、その装置が例外アラートを生成する回数を簡単に確認できます。 ベースラインを実行せずに、しきい値を設定することはお勧めできません。その結果、装置のしきい値が設定値を超えるとアラートが大量に生成される恐れがあるからです。

テスト ファイルを Excel スプレッドシートにインポートするには、Excel を起動して、File > Open の順に選択し、データ ファイルを選択します。

Baseline_Fig11.gif

次に、ファイルのインポート中に、Excel アプリケーションから確認を求められます。

完了すると、インポートされたファイルは次の画面のように表示されます。

Baseline_Fig13.gif

散布図を使用すると、各種のしきい値設定がネットワークでどう動作するかを簡単に表示できます。

散布図を作成するには、インポートしたファイルの列 C を強調表示させ、グラフ ウィザード アイコンをクリックします。 次に、Chart Wizard のステップに従って、散布図を作成します。

次に示すように、グラフ ウィザードのステップ 1 で、Standard Types タブを選択し、XY (Scatter) チャート タイプを選択します。 次に Next をクリックします。

Baseline_Fig14.gif

次に示すように、グラフ ウィザードのステップ 2 で、Data Range タブを選択し、データ範囲を選択した後、Columns オプションを選択します。 Next をクリックします。

Baseline_Fig15.gif

次に示すように、グラフ ウィザードのステップ 3 で、チャート タイトル、および X 軸と Y 軸の値を入力して、Next をクリックします。

Baseline_Fig16.gif

Chart Wizard のステップ 4 では、散布図を新しいページに配置するか、または既存のページにオブジェクトとして含めるかを選択します。

Finish をクリックして、目的の場所にチャートを保存します。

「What if」 分析

これで、散布図を使用して分析できます。 しかし、分析を行う前に、次の質問について検討する必要があります。

  • ベンダーが推奨する MIB 変数のしきい値は何か(この例では、シスコがベンダー)。

    一般的に、シスコでは、コア ルータの CPU 平均利用率が 60 % を超えないことを推奨しています。 シスコが 60 % を選択したのは、ルータにトラブルが発生したり、ネットワークに障害が起こった場合に、ルータに多少のオーバーヘッドが必要だからです。 シスコでは、ルーティング プロトコルが再計算や再コンバージなどを行う必要がある場合に、コア ルータにおよそ 40 % の CPU オーバーヘッドが必要と推測しています。 このパーセント値は、使用しているプロトコル、およびネットワークのトポロジや安定性によっても変わってきます。

  • しきい値の設定に 60 % を使用したらどうなるか。

    散布図の 60 の値で横に線を引くと、CPU 利用率が 60 % を超えるデータ ポイントがまったくないことがわかります。 そのため、NMS 端末でしきい値を 60 に設定すると、ポーリングの間、しきい値のアラートが発生しません。 60 % は、このルータにとって許容できる値です。 しかし、散布図を見ると、データ ポイントのいくつかは 60 の近くにあることがわかります。ルータのしきい値が 60 % に近づいていることが事前にわかれば、CPU が 60 % に達したときの対処法を事前に計画できる利点があります。

  • しきい値を 50 % に設定したらどうなるか。

    このルータは、今回のポーリング サイクルの間に、50 % の利用率に 4 回、達して、そのたびにしきい値アラームを生成したことが推測できます。 異なるしきい値を設定したらどうなるかを確認するためにルータ グループを表示させる場合、このプロセスの重要度が増します。 たとえば「コア ネットワーク全体にしきい値 50 % を設定したらどうなるか」などです。 しきい値を 1 つだけ選択することが難しいことがわかります。

「What If」分析で使用する CPU のしきい値

Baseline_Fig17.gif

しきい値を容易に設定する方法として、レディ、セット、ゴーのしきい値方法があります。 この方法論では、連続して 3 つのしきい値を使用します。

  • レディ(Ready) - 将来どのデバイスが注意を必要とする可能性が高いかを予測するために設定したしきい値

  • セット(Set)- 初期インジケータとして使用するしきい値。このしきい値によって、修理、再設定、またはアップグレードの計画を開始するように警告されます。

  • ゴー(Go)- お客様やベンダーが障害条件と考え、その障害を修正するために何らかの処置を必要とするしきい値。この例ではそのしきい値は 60 % です。

次の表では、レディ、セット、ゴーの戦略について示しています。

しきい値

アクション

結果

45 %

詳細に調査する。

アクション プランのオプションを表示する。

50 %

アクション プランを計画する。

アクション プランのステップを表示する。

60 %

アクション プランを実行する。

ルータではしきい値の超過がなくなった。 レディ モードに戻る。

レディ、セット、ゴー方法論により、前述したオリジナルのベースライン チャートが変わります。 次の図は、変更後のベースライン チャートを示しています。 チャートに他の交点がある場合、以前よりも計画と対応に時間をかけてください。

65401.gif

このプロセスの場合、注意はネットワーク内の例外だけに向けられており、他の装置には向けられていないことに注意してください。 しきい値を超えない限り、装置は正常であると見なされるためです。

これらのステップを最初から取り入れていれば、ネットワークを正常に維持するために十分に準備できます。 このタイプの計画を実行することは、予算を計画する上でも有効です。 トップ 5 のゴー ルータ、中間のセット ルータと、下位のレディ ルータが判明している場合、そのルータの種類と、アクション プランのオプションに基づいて、アップグレードに必要な予算がどれ位かかるかが簡単に計画できます。 同じ戦略を Wide-Area Network(WAN)やその他の MIB OID にも使用できます。

ステップ 5: 特定した直接的な問題を修正する

ステップ 5 は、ベースライン プロセスの中でも簡単な部分の 1 つです。 どのデバイスがゴーしきい値を超えたかを特定できれば、そのデバイスをしきい値以下に戻すアクション プランを作成します。

利用できるオプションについて、Cisco's Technical Assistance Center(TAC)までご相談いただくか、システム エンジニアにお問い合せください。 しきい値を下げることに費用がかかるとは考えないでください。 CPU の問題によっては、設定を変更してすべてのプロセスを効率的な方法で確実に実行すれば、解決できます。 たとえば、Access Control List(ACL; アクセス コントロール リスト)によっては、パケットがルータを通過するときのパスにより、ルータの CPU を非常に高速に実行できます。 また、場合によっては、NetFlow スイッチングを実行すると、パケット交換のパスを変更し、CPU に与える ACL の影響を減らすことができます。 問題の内容を問わず、このステップでは全ルータのしきい値を設定値以下に戻すことが必要です。これにより、しきい値アラームが発生し過ぎて NMS 端末がフラッディングするリスクを負わずに、後でしきい値を設定できます。

ステップ 6: しきい値モニタリングをテストする

このステップでは、プロダクション ネットワークで使用するツールにより、ラボでしきい値をテストします。 しきい値をモニタリングするには、一般的に、2 つの方法があります。 自分のネットワークに最適な方法を選択する必要があります。

  • SNMP プラットフォームまたはその他の SNMP モニタリング ツールによって、ポーリングと比較を行う方法

    この方法では、トラフィックをポーリングするのにネットワークの帯域幅をより多く使用し、SNMP プラットフォームでのポーリング サイクルにも時間がかかります。

  • ルータの Remote Monitoring(RMON; リモート モニタリング)アラームおよびイベントの設定によって、しきい値が超過した場合だけアラートが送られる方法

    この方法を使用すると、ネットワーク帯域幅の使用状況は減りますが、ルータでのメモリと CPU の利用率が増えます。

SNMP によるしきい値の設定

HP OpenView NNM を使用して SNMP 方法を設定するには、初期ポーリングを設定した場合と同じように、Options > Data Collection & Thresholds の順に選択します。 ただし今回は、収集メニューで Store, No Thresholds を選択する代わりに、Store, Check Thresholds を選択します。 しきい値を設定し終えたら、複数の PING や複数の SNMP ウォークを送信することで、ルータの CPU 利用率を上げることができます。 意図的に CPU の利用率がしきい値を超えるようにできない場合は、しきい値を下げる必要がある場合もあります。 どんな場合でも、しきい値のメカニズムが機能していることを確認する必要があります。

この方法の使用に関する制限の 1 つは、複数のしきい値を同時に設定できないことです。 3 つの異なるしきい値を同時に設定するには、3 つの SNMP プラットフォームが必要になります。 Concord Network Health leavingcisco.comTrinagy TREND leavingcisco.comなどのツールを使用すると、同じ OID インスタンスに対して複数のしきい値が使用できます。

システムが同時に 1 つのしきい値しか処理できない場合、レディ、セット、ゴー戦略の連続的な使用を検討する必要がある場合があります。 つまり、継続的にレディしきい値に達する場合、調査を開始して、そのデバイスのセット レベルまでしきい値を上げるということです。 継続的にセット レベルに達する場合は、アクション プランを策定し、そのデバイスのゴー レベルにまでしきい値を上げます。 さらに、ゴーのしきい値に頻繁に達しているときは、アクション プランを実行します。 この方法は、同時に 3 つのしきい値を設定する方法と同じように動作しますが、 SNMP プラットフォームのしきい値の設定を変更するのに少し余分に時間がかかります。

RMON アラームとイベントによるしきい値の設定

RMON アラームとイベントの設定を使用すると、ルータ自体が複数のしきい値を監視できます。 ルータはしきい値が超過している状態を検知すると、SNMP プラットフォームに SNMP トラップを送信します。 トラップを転送するためには、各自のルータ設定に SNMP トラップ受信装置を設定する必要があります。 アラームとイベントとの間には相互関係があります。 アラームは、特定のしきい値について OID をチェックします。 しきい値に達すると、アラーム プロセスはすぐに、SNMP トラップ メッセージの送信か RMON ログ エントリの作成のいずれか、または両方を行うイベント プロセスを始動します。 このコマンドの詳細については、「RMON アラームとイベント設定コマンド」のセクションを参照してください。

次のルータ設定コマンドを実行すると、ルータは 300 秒ごとに cpmCPUTotal5min を監視します。 CPU が 60 % を超過すると、イベント 1 が始動され、CPU が 40 % に戻るとイベント 2 が始動されます。 両方の場合とも、SNMP トラップ メッセージは、コミュニティ プライベート ストリングによって NMS 端末に送られます。

レディ、セット、ゴーの方法を使用するには、次の設定文をすべて使用します

rmon event 1 trap private description "cpu hit60%" owner jharp
  rmon event 2 trap private description "cpu recovered" owner jharp
  rmon alarm 10 cpmCPUTotalTable.1.5.1 300 absolute rising 60 1 falling 40 2 owner jharp
  rmon event 3 trap private description "cpu hit50%" owner jharp
  rmon event 4 trap private description "cpu recovered" owner jharp
  rmon alarm 20 cpmCPUTotalTable.1.5.1 300 absolute rising 50 3 falling 40 4 owner jharp
  rmon event 5 trap private description "cpu hit 45%" owner jharp
  rmon event 6 trap private description "cpu recovered" owner jharp
  rmon alarm 30 cpmCPUTotalTable.1.5.1 300 absolute rising 45 5 falling 40 6 owner jharp
  

次の例では、上記ステートメントによって設定された show rmon alarm コマンドの出力を示します。

zack#sh rmon alarm
  Alarm 10 is active, owned by jharp
   Monitors cpmCPUTotalTable.1.5.1 every 300 second(s)
   Taking absolute samples, last value was 0
   Rising threshold is 60, assigned to event
  1
   Falling threshold is 40, assigned to event
  2
   On startup enable rising or falling alarm
  Alarm 20 is active, owned by jharp
   Monitors cpmCPUTotalTable.1.5.1 every 300 second(s)
   Taking absolute samples, last value was 0
   Rising threshold is 50, assigned to event
  3
   Falling threshold is 40, assigned to event
  4
   On startup enable rising or falling alarm
  Alarm 30 is active, owned by jharp
   Monitors cpmCPUTotalTable.1.5.1 every 300 second(s)
   Taking absolute samples, last value was 0
   Rising threshold is 45, assigned to event
  5
   Falling threshold is 40, assigned to event
  6
   On startup enable rising or falling alarm

次の例では、show rmon event コマンドの出力を示します。

zack#sh rmon event
  Event 1 is active, owned by jharp
   Description is cpu hit60%
   Event firing causes trap to community
  private, last fired 00:00:00
  Event 2 is active, owned by jharp
   Description is cpu recovered
   Event firing causes trap to community
  private, last fired 02:40:29
  Event 3 is active, owned by jharp
   Description is cpu hit50%
   Event firing causes trap to community
  private, last fired 00:00:00
  Event 4 is active, owned by jharp
   Description is cpu recovered
   Event firing causes trap to community
  private, last fired 00:00:00
  Event 5 is active, owned by jharp
   Description is cpu hit 45%
   Event firing causes trap to community
  private, last fired 00:00:00
  Event 6 is active, owned by jharp
   Description is cpu recovered
   Event firing causes trap to community
  private, last fired 02:45:47

この両方の方法を試して、どちらの方法が自分の環境に最適であるかを確認します。 両方の方法を組み合わせて順調に動作する場合もあります。 いずれの場合でも、ラボ環境でテストを実施して、すべてが正常に動作することを確認する必要があります。 ラボでのテスト終了後に、限定的に配置した小グループのルータを使用して、各自のオペレーション センターにアラートを送信するプロセスをテストします。

この場合は、しきい値を下げてプロセスをテストする必要があります。 実働しているルータ上で人為的に CPU 稼働率を上げることは推奨しません。 また、アラートがオペレーション センターの NMS 端末に着信すると、装置がしきい値を超過したときに確実に通知される報告ポリシーが存在することを確認する必要があります。 この設定は、Cisco IOS バージョン 12.1(7)を使用して、ラボで試験を行いました。 問題が発生した場合、IOS バージョンにバグあるかどうかを、シスコの技術部またはシステム エンジニアに確認する必要があります。

ステップ 7: SNMP または RMON を使用してしきい値モニタリングを実装する

ラボ、または限定された実装の中で、しきい値モニタリングのテストが完全に終わったら、コア ネットワーク全体にしきい値を設定する準備ができています。 これで、バッファ、空いているメモリ、Cyclic Redundancy Check(CRC; サイクリック冗長性検査)エラー、ATM のセル損失などをはじめとする、ネットワーク内にある他の重要な MIB 変数について、このベースライン プロセスを体系的に実行できます。

RMON アラームおよびイベントの設定を使用する場合は、NMS 端末からのポーリングを停止できます。 この結果、NMS サーバ上の負荷が減り、ネットワーク上のポーリング データ量も低減します。 このプロセスを体系的に実行して、ネットワークの重要な指標とすることで、ネットワーク装置自体が RMON アラームおよびイベントによって自らを監視するレベルに簡単に到達できます。

追加 MIB

このプロセスを学習し終えた段階で、他の MIB にベースラインを実行して監視する必要がある場合があります。 次のサブセクションで、いくつかの役に立つ OID の簡単なリストと説明を示します。

ルータ MIB

メモリ特性は、ルータの状態を判断する上で役に立ちます。 正常なルータの場合は、ほぼ必ず、作業に利用できるバッファ スペースが存在します。 ルータのバッファ スペースがなくなると、 CPU はフル活動して新しいバッファを作成し、入出力パケットのためのバッファを探さなくてはなりません。 バッファの詳細は、この文書の対象外ですので取り上げません。 しかし、一般的に、正常なルータでは、バッファのミスはほとんどまたはまったく存在しませんし、またバッファの障害や空きメモリのない状態も発生しません。

オブジェクト

説明

OID

ciscoMemoryPoolFree

管理対象装置で現在、未使用のメモリ プールのバイト数

1.3.6.1.4.1.9.9.48.1.1.1.6

ciscoMemoryPoolLargestFree

現在、未使用のメモリ プールの隣接最大バイト数

1.3.6.1.4.1.9.9.48.1.1.1.7

bufferElMiss

バッファ要素のミス数

1.3.6.1.4.1.9.2.1.12

bufferFail

バッファ割り当て失敗数

1.3.6.1.4.1.9.2.1.46

bufferNoMem

空きメモリ不足によるバッファの作成障害数

1.3.6.1.4.1.9.2.1.47

Catalyst スイッチ MIB

オブジェクト

説明

OID

cpmCPUTotal5min

最後の 5 分間に CPU がビジー状態であった合計パーセント。 このオブジェクトは、OLD-CISCO-SYSTEM-MIB の avgBusy5 オブジェクトを推奨しない。

1.3.6.1.4.1.9.9.109.1.1.1.5

cpmCPUTotal5sec

最後の 5 秒間に CPU がビジー状態であった合計パーセント。 このオブジェクトは、OLD-CISCO-SYSTEM-MIB の busyPer オブジェクトを廃棄する。

1.3.6.1.4.1.9.9.109.1.1.1.3

sysTraffic

前回のポーリング期間の帯域利用率のパーセント

1.3.6.1.4.1.9.5.1.1.8

sysTrafficPeak

最後にポート カウンタがクリアーされてから、またはシステムが起動してからのトラフィック メータの最高値

1.3.6.1.4.1.9.5.1.1.19

sysTrafficPeaktime

メータ最高値の発生後の時間(100 分の 1 秒単位)

1.3.6.1.4.1.9.5.1.1.20

portTopNUtilization

システムのポート利用率

1.3.6.1.4.1.9.5.1.20.2.1.4

portTopNBufferOverFlow

システムのポートのバッファ オーバーフロー数

1.3.6.1.4.1.9.5.1.20.2.1.10

シリアル リンク MIB

オブジェクト

説明

OID

locIfInputQueueDrops

入力キューがいっぱいのためドロップされたパケット数

1.3.6.1.4.1.9.2.2.1.1.26

locIfOutputQueueDrops

出力キューがいっぱいのためドロップされたパケット数

1.3.6.1.4.1.9.2.2.1.1.27

locIfInCRC

冗長性チェックサム エラーが発生した入力パケット数

1.3.6.1.4.1.9.2.2.1.1.12

RMON アラームとイベント設定コマンド

アラーム

RMON アラームは、次の構文によって設定できます。

  rmon alarm number variable interval {delta | absolute} rising-threshold value
 	    [event-number] falling-threshold value [event-number]
 	    [owner string]
  

要素

説明

number

アラーム番号。RMON MIB のアラーム テーブル内にある alarmIndex と同一である。

variable

監視対象の MIB オブジェクト。RMON MIB のアラーム テーブルで使用される alarmVariable に変換する。

interval

アラームが MIB 変数を監視する時間(秒単位)。RMON MIB のアラーム テーブルで使用される alarmInterval と同一である。

delta

MIB 変数間の変更をテストする。RMON MIB のアラーム テーブルの alarmSampleType に影響を与える。

absolute

各 MIB 変数を直接、テストする。RMON MIB のアラーム テーブルの alarmSampleType に影響を与える。

rising-threshold value

アラームが起動する値

event-number

(オプション)上昇しきい値または下降しきい値が、制限値を超えたときに起動するイベント番号。 この値は、RMON MIB のアラーム テーブルの alarmRisingEventIndex または the alarmFallingEventIndex と同一である。

falling-threshold value

アラームがリセットされる値

owner string

(オプション)アラームの所有者を示す。RMON MIB のアラーム テーブルの alarmOwner と同一である。

イベント

RMON イベントは、次の構文によって設定できます。

  rmon event number [log] [trap community] [description string]
 	    [owner string]
  

要素

説明

number

割り当てられたイベント番号。RMON MIB の eventTable 内にある eventIndex と同一である。

log

(オプション)イベントが起動し、RMON MIB の eventType を log または log-and-trap に設定するときに、RMON ログ エントリを作成する。

trap community

(オプション)このトラップに使用される SNMP コミュニティ ストリング。 この列について、RMON MIB の eventType を snmp-trap または log-and-trap に設定する。 この値は、RMON MIB の eventTable 内の eventCommunityValue と同一である。

description string

(オプション)イベントの説明を示す。RMON MIB のアラーム テーブルのイベントの説明と同一である。

owner string

(オプション)このイベントの所有者を示す。RMON MIB のアラーム テーブルの eventOwner と同一である。

RMON アラームとイベントの実装

RMON アラームとイベント実装の詳細については、『ネットワーク管理システムのベスト プラクティス』White Paper の「RMON アラームとイベント実装」のセクションを参照してください。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 15112