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

ベースライン プロセスのベスト プラクティスのホワイト ペーパー

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2003 年 7 月 9 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

この文書では、可用性の高いネットワークを構築するためのベースラインのコンセプトと手順を説明します。 これには、成功の評価を行うためのネットワーク ベースラインとしきい値設定に関する重要な成功要因が含まれています。 さらに、シスコのハイ アベイラビリティ サービス(HAS)チームによって明らかにされた最適な方法のガイドラインに基づき、ベースラインとしきい値プロセスおよび実装について詳細に説明します。

この文書では、ベースラインのプロセスを手順を追って実行します。 現在の Network Management System(NMS; ネットワーク管理システム)の製品によっては、このプロセスを自動化できますが、自動ツール、手動ツールのいずれを使用しても、ベースラインのプロセス自体は同じです。 これらの NMS 製品を使用する場合、ユニーク な ネットワーク 環境のためにデフォルトしきい値設定を調節して下さい。 有意義、正しいようにプロセスをインテリジェントにそれらのしきい値を選択する持っていることは重要です。

ベースライン

ベースラインとは何か

ベースラインはネットワークが設計されているようにはたらいていることを確認するためにネットワークを一定の間隔で調査するためのプロセスです。 それはある特定の時点でネットワークの健全性を詳述する一つのレポートより多くです。 ベースラインプロセスに従うことによって、次の情報を得ることができます:

  • ハードウェア および ソフトウェアの健全性の有益な情報を得て下さい

  • 現在のネットワークリソースの使用を判別して下さい

  • ネットワークアラームしきい値についての正確なデシジョンを作って下さい

  • 現在のネットワーク問題点を明らかにして下さい

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

ベースラインを検知 する別の方法は次のダイアグラムで説明されます。

/image/gif/paws/15112/65400.gif

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

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

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

  • どれだけ速くネットワーク負荷が増加しているか

  • うまくいけばどの時点で 2 つが横断することを予測して下さい

ベースラインを定期的に実行することによって、失敗がそれらのために先立って発生し、準備する時現在のステートを調べ外挿法で推定することができます。 さらに、ネットワークのアップグレードについて、予算額をいつ、どこで、どう使用するかを、情報に基づいて決定できます。

なぜベースラインなのか

ベースラインプロセスはネットワークの極めて重要なリソース 制限問題のために識別し、きちんと計画するのを助けます。 これらの問題は、コントロール プレーン リソースまたはデータ プレーン リソースとして説明できます。 コントロール プレーン リソースはデバイス内の特定のプラットフォームおよびモジュールにユニークで、いくつかの問題によってを含む影響を与えることができます:

  • データ 利用

  • 有効に なる 機能

  • ネットワーク設計

コントロール プレーン リソースはパラメータが含まれています(以下を参照):

  • CPU稼働率

  • メモリ使用

  • バッファ使用状況

データ planeリソースは型およびトラフィック量だけ影響を与えられ、リンク利用およびバックプレーン稼働率が含まれています。 重要なエリアのためのベースライニング リソース利用によって、ネットワークメルトダウン 深刻なパフォーマンス問題を、またはより悪い避ける、ことができます。

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

アプリケーションの新しいミックスが原因で、ベースライニングはコントロール プレーンおよびデータ planeリソース 利用問題を両方理解し、予防的に継続的成功を確認する変更およびアップグレードのために計画するのを助けます。

データネットワークは長年にわたりありました。 最近まで、ネットワークを稼動することは、多少のエラーも比較的許容されていました。 Voice over IP(VoIP)などの遅延の影響を受けやすいアプリケーションが急速に受け入れられるにつれて、ネットワークの稼動は、より困難になるとともに高い精度が要求されています。 より精密ですためおよびネットワーク管理者に持っていることは重要ネットワークがどのようにの動作しているかネットワークを管理するために、概念をである確かな基盤を与えるため。 そのためには、ベースラインと呼ばれるプロセスを導入する必要があります。

ベースライン目標

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

  1. ネットワークデバイスの現在のステータスを判別して下さい

  2. 標準パフォーマンス ガイドラインとそのステータスを比較して下さい

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

データを分析するために奪取 する 時間数および多量のデータが原因でプロセスを理解すること最初にベースラインのスコープをもっと簡単にするために制限しなければなりません。 ネットワークのコア部分から開始するのが、最も合理的で、通常、最も有益です。 ネットワークのこの部分は、通常、最も小さく、しかも最高の安定性が求められるためです。

どのようにベースライン 1 非常に重要な簡易ネットワーク管理プロトコル 管理情報ベース(SNMP MIB)かに簡潔にするために、この資料に説明されています: cpmCPUTotal5min. cpmCPUTotal5min は Ciscoルータの中央処理装置 (CPU)の 5 分腐食平均で、コントロール プレーン パフォーマンスインジケータです。 このベースラインは、Cisco 7000 シリーズのルータで実行します。

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

  • Integrated Services Digital Network (ISDN) 使用方法

  • 非同期転送モード (ATM) セル消失

  • フリーシステム メモリ

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

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

/image/gif/paws/15112/65402.gif

ベースライン手順

ステップ 1: ハードウェア、ソフトウェアおよびコンフィギュレーション目録をコンパイルして下さい

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

Cisco ネットワークの場合、ベースラインのステップ 1 の部分を最も効率的に実行するには、CiscoWorks2000 Resource Manager Essentials(Essentials)を使用します。 このソフトウェアがネットワークに正しくインストールされている場合、概要はデータベースのすべてのデバイスの現在の目録があるはずです。 問題の有無を確認するには、そのインベントリを参照するだけで済みます。

次の表は、Essentials からエクスポートされた Cisco Router Class ソフトウェアのインベントリ レポートを Microsoft Excel で編集した例です。 このコンポーネントから、SNMP MIB データを使用しなければなり、オブジェクト識別子(OID)が 12.0x および 12.1x Cisco IOS リリースで見つけたことに注意して下さい。

Device Name ルータのタイプ Version [Software Version]
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)

概要がネットワークにインストールされていない場合、IOSバージョンを見つけるのに UNIXワークステーションからの UNIX コマンド・ライン ツール snmpwalk を使用できます。 これを次の例で示します。 このコマンドがどのように動作するか確実ではない場合、詳細については 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 テーブル一部を示します。 この例は cpmCPUTotal5minMIB のための OID が .1.3.6.1.4.1.9.9.109.1.1.1.1.5 であることを示したものです。

注: 「追加することを忘れないで下さい」。 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 をポーリングする 1 つの方法に、HP OpenView Network Node Manager(NNM)、または CiscoWorks Windows などの NMS プラットフォームから MIB ウォーカを使用し、チェックする OID を入力する方法があります。

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

/image/gif/paws/15112/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

両方の例では、MIB はそのポーリングサイクルのために CPU が 0 パーセント稼働率を平均したことを意味する 0 という値を戻しました。 正しいデータと応答するためにデバイスを得る問題がある場合デバイスを ping し、Telnet を通ってデバイスにアクセスすることを試みて下さい。 それでも問題がある場合、SNMP 設定および SNMP コミュニティストリングをチェックして下さい。 問題を解決するには、別の MIB または IOS の他のバージョンを探す必要がある場合があります。

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

MIB オブジェクトをポーリングして、その出力結果を記録する方法がいくつかあります。 通常の製品、シェアウェア 製品、スクリプトおよびベンダー ツールは利用できます。 すべてのフロント・エンド ツールは SNMP を得ます情報を得るためにプロセスを使用します。 主に、構成の柔軟性とデータをデータベースに記録する方法が異なります。 再度、これらのさまざまなメソッドがどのようにはたらくか見るプロセッサ MIB の外観。

確認するので OID はルータでサポートされますそれをポーリングするために、どの位の割りでおよびそれを記録する方法を決定する必要があります。 Cisco は CPU MIB が 5 分 間隔でポーリングされることを推奨します。 より低い間隔はネットワークまたはデバイスのロードを増加し、MIB 値はとにかく 5分平均であるので頻繁にそれを平均された値よりポーリングすることは役立ちません。 ネットワークの少なくとも 2 つの週間景気循環を分析できるようにベースラインのポーリングが少なくとも 2週間の期間を過すことがまた通常推奨されます。

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

/image/gif/paws/15112/Baseline_Fig5.gif

それから Edit > Add > MIB Objects の順に選択 して下さい。

Baseline_Fig6.gif

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

/image/gif/paws/15112/Baseline_Fig7.gif

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

Data Collection メニューから、Edit > Add > MIB Collections の順に選択 して下さい。

Baseline_Fig8.gif

Source フィールドでは、ポーリングされるべきルータの Domain Naming System (DNS)名前か IP アドレスを入力して下さい。

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

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

[Apply] をクリックします。

Baseline_Fig9.gif

変更が影響を奪取 することができるように File > Save の順に選択 して下さい。

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

Baseline_Fig10.gif

『Close』 をクリック し、収集が 1 週間動作するようにして下さい。 週間期間の終わりに、分析のデータを抽出して下さい。

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

次のコマンドでテストファイルと呼ばれる 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 の順に選択 し。

/image/gif/paws/15112/Baseline_Fig11.gif

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

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

/image/gif/paws/15112/Baseline_Fig13.gif

散布図はさまざまなしきい値設定がネットワークでどのように動作するかにより簡単に視覚化します可能にします。

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

下記に示されているようにチャート ウィザード ステップ 1 では、Standard Types タブを選択し、X-Y (散布図)グラフの種類を選択して下さい。 次に [Next] をクリックします。

Baseline_Fig14.gif

下記に示されているようにチャート ウィザード ステップ 2 では、Data Range タブを選択し、データ範囲および Columns オプションを選択して下さい。 [Next] をクリックします。

Baseline_Fig15.gif

下記に示されているようにチャート ウィザード ステップ 3 では、グラフのタイトルおよび X および Y軸値を入力し、次に『Next』 をクリック して下さい。

/image/gif/paws/15112/Baseline_Fig16.gif

チャート ウィザード ステップ 4 では、New ページのまたは既存のページのオブジェクトとして分散図がほしいと思うかどうか選択して下さい。

目的の場所に図を置くために『Finish』 をクリック して下さい。

「What if」 分析

これで、散布図を使用して分析できます。 ただし、続行する前に、次の質問をする必要があります:

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

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

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

    60 で散布図を渡る行を水平に引出す場合、データ点のどれも 60 ...パーセントのCPU 使用率を超過しないことがわかります。 そのため、NMS 端末でしきい値を 60 に設定すると、ポーリングの間、しきい値のアラートが発生しません。 パーセントとしての 60 はこのルータのために受諾可能です。 ただしいくつかのデータ点が 60 に密接であること、散布図の表記。 ルータが 60%しきい値に近づいている従って CPU は 60%するべきことのための計画を持つためにそのポイントに達するときアプローチしていることを事前に確認することができるとき知っていることは素晴らしく。

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

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

」分析何 CPU しきい値「

Baseline_Fig17.gif

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

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

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

  • 行って下さい—および/またはベンダーがである障害状態信じるおよびそれを修理する操作を必要としますしきい値は; この例でそれは 60%です

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

しきい値 Action 結果
45 % 更に調査して下さい アクションプランのためのオプションのリスト
50 % アクションプランを作り出して下さい アクションプランのステップのリスト
60 % 実装する アクションプラン ルータではしきい値の超過がなくなった。 準備ができたモードに戻る

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

65401.gif

このプロセスで、注意がネットワークの例外に焦点を合わせ、その他のデバイスにかかわっていないことに注意して下さい。 デバイスがしきい値の下にある限り、うまくあることが仮定されます。

これらのステップを最初から考えてもらう場合ネットワークを健全保存するために十分に用意されたです。 このタイプの計画を実行することは、予算を計画する上でも有効です。 最初 5 によってが行く何がルータを、中間一定ルータ知り、一番下準備 が できた ルータがあれば、どのようなルータに基づいてアップグレードあり、ものアクションプラン オプションがであるかどの位予算を計画のためにで必要とするか容易にできます。 同じ戦略を Wide-Area Network(WAN)やその他の MIB OID にも使用できます。

ステップ 5: 修正によって明らかにされる差し迫った問題

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

利用できるオプションについて、Cisco's Technical Assistance Center(TAC)までご相談いただくか、システム エンジニアにお問い合せください。 しきい値を下げることに費用がかかるとは考えないでください。 CPU の問題によっては、設定を変更してすべてのプロセスを効率的な方法で確実に実行すれば、解決できます。 たとえば、アクセス コントロール リスト(ACL)はルータのCPU にパケットがルータを通して選択するパスが非常に高く原因で実行させますことができます。 場合によっては、パケット交換パスを変更し、CPU の ACL の影響を減らすために NetFlow スイッチングを設定できます。 問題の内容を問わず、このステップでは全ルータのしきい値を設定値以下に戻すことが必要です。これにより、しきい値アラームが発生し過ぎて 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 walk ルータの CPU稼働率を上げることができます。 意図的に CPU の利用率がしきい値を超えるようにできない場合は、しきい値を下げる必要がある場合もあります。 いずれにしても、threshold mechanism がはたらいていることを確認する必要があります。

この方法の使用に関する制限の 1 つは、複数のしきい値を同時に設定できないことです。 3 つの異なるしきい値を同時に設定するには、3 つの SNMP プラットフォームが必要になります。 コンコード社Network Health および Trinagy TRENDleavingcisco.com のようなツールはleavingcisco.com 同じ OID 例のためのマルチプルスレッシュホールドを可能にします。

システムが 1 しきい値を一度に処理ただできる場合行きますシリアル方式で準備ができたの、セット考慮する、戦略ことができます。 つまり、継続的にレディしきい値に達する場合、調査を開始して、そのデバイスのセット レベルまでしきい値を上げるということです。 継続的にセット レベルに達する場合は、アクション プランを策定し、そのデバイスのゴー レベルにまでしきい値を上げます。 さらに、ゴーのしきい値に頻繁に達しているときは、アクション プランを実行します。 この方法は、同時に 3 つのしきい値を設定する方法と同じように動作しますが、 ちょうど SNMP プラットフォーム しきい値設定を変更するより多くの時間ややかかります。

RMON alarm およびイベントを使用してしきい値の実装

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

次のルータ設定コマンドを実行すると、ルータは 300 秒ごとに cpmCPUTotal5min を監視します。 それは CPU が 40%に戻って下る場合 CPU が 60%超過すれば始動させ、イベント 2 を始動させますイベント 1 を。 いずれの場合も、SNMP トラップ メッセージはコミュニティ private ストリングが付いている 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バージョンで不具合があるかどうか見るために設計していたりまたはシステム・エンジニア Cisco とチェックする必要があります。

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

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

RMON alarm およびイベント構成を使用する場合、NMSステーションから今ポーリングすることを止めることができます。 この結果、NMS サーバ上の負荷が減り、ネットワーク上のポーリング データ量も低減します。 重要なネットワーク健全性インジケーターのためのこのプロセスを組織的に通過によって、ネットワーク設備が RMON alarm およびイベントを使用して彼ら自身を監察していることポイントに容易に来る可能性があります。

追加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

Catalystcスイッチ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

シリアルリンクMIBs

オブジェクト 説明 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]
要素 説明
数値 アラーム番号。RMON MIB のアラーム テーブル内にある alarmIndex と同一である。
可変 監視対象の MIB オブジェクト。RMON MIB のアラーム テーブルで使用される alarmVariable に変換する。
間隔 アラームが 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]
要素 説明
数値 RMON MIB の eventTable の eventIndex と同一である割り当てられたイベント番号。
log (オプション)イベントが起動し、RMON MIB の eventType を log または log-and-trap に設定するときに、RMON ログ エントリを作成する。
trap community (オプション)このトラップに使用される SNMP コミュニティ ストリング。 SNMPトラップか log-and-trap でこの行のための RMON MIB の eventType の設定を設定します。 この値は、RMON MIB の eventTable 内の eventCommunityValue と同一である。
description string (オプション)イベントの説明を示す。RMON MIB のアラーム テーブルのイベントの説明と同一である。
owner string (オプション)このイベントの所有者を示す。RMON MIB のアラーム テーブルの eventOwner と同一である。

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

RMON アラーム および イベント 実行についての詳細な情報に関しては、ネットワーク管理システム 最良 の 方法 白書の「RMON Alarm and Event Implementation」項を読んで下さい。

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

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


関連情報


Document ID: 15112