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

パフォーマンス管理:: ベスト プラクティスのホワイト ペーパー

2016 年 10 月 28 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 10 月 4 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

パフォーマンス管理には、ネットワーク サービスの応答時間の最適化および個々のネットワーク サービスやネットワーク サービス全体の一貫性と品質の管理があります。 最も重要なサービスは、ユーザやアプリケーションの応答時間を測定する必要性です。 ほとんどのユーザにとって、応答時間がパフォーマンスにおける重要な成功要因となります。 この要素により、お客様のユーザとアプリケーション管理者の両者が、ネットワークの成功を認識できます。

背景説明

容量計画はビジネス必須アプリケーションのパフォーマンスかアベイラビリティインパクトを防ぐために未来のネットワークリソースのための必要条件を判別するプロセスです。 容量計画のエリアでは、ネットワークベースライン(CPU、メモリ、バッファ、イン/アウト オクテット、等)は応答時間に影響を与える場合があります。 そのため、パフォーマンスの問題は、キャパシティに関連していることが多いことに注意してください。 ネットワークでは、これはネットワークによって送信することができる前に一般的にキューで待つ必要があるデータおよび帯域幅です。 音声アプリケーションでは、この待機時間はほぼ確実にユーザへの影響があります。これは、遅延やジッタなどの要素が音声コールの品質に影響を与えるためです。

パフォーマンス管理を複雑にするもう一つの大きな問題は高いネットワークアベイラビリティが両方のためにミッションクリティカル大きい企業およびサービスプロバイダー ネットワークであるがこと、傾向(頻繁に不慮)より高いコストを賭けて短期経済的なゲインを長い目で見れば追求することですです。 各予算 サイクルの間にパフォーマンスとファースト実装間のバランスを見つけるために、ネットワーク管理者およびプロジェクト 実現人員は努力します。 更に、ネットワーク管理者は専門知識の狭いマーケット ウィンドウ、複雑な技術、ビジネス統合、競合する市場、不定期ダウンタイム、欠如、および頻繁に不充分なツールに会うために急速な製品開発を含むチャレンジに直面します。

これらの問題の観点から、ネットワーク管理のフレームワークにパフォーマンスはどのように適合するでしょうか。 理想的なネットワーク管理システムの主たる機能はネットワークの運用 ケイパビリティを最適化することです。 ネットワーク管理のための最終目的としてこれを受け入れれば、そしてネットワーク管理のフォーカスはピーク パフォーマンスでネットワークオペレーションを保存することです。

理想的なネットワーク管理システムはこれらのプリンシパル オペレーションが含まれています:

  • 切迫したパフォーマンスの低下をオペレータに知らせます。

  • パフォーマンスの低下か失敗が起こるとき容易な代替ルーティングおよび回避策を提供します。

  • ツールをパフォーマンスの低下または失敗の原因を正確に示すために提供します。

  • ネットワーク弾力性およびサバイバビリティのための本電話機としてサーブ。

  • リアルタイムのパフォーマンスを伝えます。

理想 システムのためのこの定義に基づいて、パフォーマンス管理はネットワーク管理に必要になります。 これらのパフォーマンスマネージメント上の問題は重要です:

  • ユーザのパフォーマンス

  • アプリケーションのパフォーマンス

  • キャパシティ計画

  • 予防的な障害管理

低い値の音声およびビデオのような新規アプリケーションの、パフォーマンスが成功へキー変数であること、そして注意することは重要堅実 な パーフォーマンスを実現できなければサービス考慮され、失敗しますです。 それ以外の場合、ユーザは生産性およびユーザ の 満足度を低下させる断続的なアプリケーション タイムアウトの可変パフォーマンスで単に被害を受けます。

この資料はパフォーマンス管理のための成功のための重要な要因、主要業績評価指標およびハイレベルプロセス マップを含む最も重要なパフォーマンスマネージメント上の問題を詳述します。 またアベイラビリティ、応答時間、正確さ、利用および容量計画の概念を論議し、パフォーマンス管理および理想的なネットワーク管理システム内の予防的な障害分析のロールの短い検討を含まれています。

重要な成功要因

重要な成功要因では、ベスト プラクティスを実装するための要件が明確にされます。 成功のための重要な要因として修飾するために、プロセスがかプロシージャはアベイラビリティを改善するプロシージャの不在はアベイラビリティを減少させる必要があります。 さらに、成功のための重要な要因は組織が成功のエクステントを確認できるように測定可能であるはずです。

詳細な情報についてはパフォーマンスマネージメントインジケータを参照して下さい。

これらはパフォーマンス管理のための成功のための重要な要因です:

  • ネットワークとアプリケーションのデータの両方に対するベースラインを収集する。

  • 使用しているネットワークやアプリケーションに対して what-if 分析を行う。

  • キャパシティの問題に対して例外報告を行う。

  • 提示されているかまたは潜在的なあらゆるネットワーク管理サービスに対するネットワーク管理のオーバーヘッドを判断する。

  • キャパシティ情報を分析する。

  • ネットワークとアプリケーション両方に対するキャパシティ情報や、ベースラインおよび例外を定期的にレビューする。

  • アップグレードか対処的 な、長期基礎の容量の問題を処理するために手順セットアップを調整することを持って下さい。

パフォーマンス管理のインジケータ

パフォーマンス インジケータは、重要な成功要因を測定するための仕組みを提供します。 パフォーマンス計画に対するパフォーマンス インジケータには、次のものがあります。

  • ネットワーク管理のビジネス目標を文書化する。 これはネットワーク管理を運用するための公式なコンセプト、あるいは必要な機能や目標に関する非公式な要件となることがあります。

  • 詳細な測定可能サービス レベル目標を設定する。

  • これらの協定がどのようにの一定時間にわたり応じられるか成功か失敗を示すグラフかグラフを Service Level Agreements のドキュメントに与えて下さい。

  • 変数がトラップのためにように各変数に対して使用されるトリガー、およびトレンド分析使用されるかどうか、ベースラインのための変数のリストを、ポーリング間隔のような、可能性のある トリガーしきい値負われる集めて下さいネットワーク管理 オーバーヘッド。

  • 定期的に会議を開き、ベースラインとトレンドの分析をレビューします。

  • what-if 分析の方法論を文書化します。 これには、適用できる場合はモデリングと検証が含まれます。

  • しきい値があるときネットワークリソースを高めるのに使用される方法論のドキュメントを超過して下さい、開発して下さい。 文書化する項目には、WAN の帯域幅を増やすために必要なタイム ラインやコスト テーブルがあります。

パフォーマンス管理のプロセス フロー

これらのステップはパフォーマンス管理にハイレベルプロセスフローを提供します:

  1. オペレーションに関するネットワーク管理上のコンセプトを開発して下さい

    1. 要件を定義して下さい: サービス、スケーラビリティ、アベイラビリティの目標

    2. アベイラビリティおよびネットワーク管理目標を定義して下さい

    3. パフォーマンスSLA およびメトリックを定義して下さい

    4. SLA を定義して下さい

  2. パフォーマンスを測定して下さい

    1. ネットワークベースラインデータを収集して下さい

    2. アベイラビリティの測定

    3. 応答時間を測定して下さい

    4. 正確さを測定して下さい

    5. 利用を測定して下さい

    6. キャパシティ計画

  3. 予防的な障害分析を行って下さい

    1. 予防的なフォルトマネジメントのためにしきい値を使用して下さい

    2. ネットワーク管理の実装

    3. ネットワークの運用メトリック

オペレーションに関するネットワーク管理上のコンセプトを開発して下さい

ネットワークのための詳しいパフォーマンスおよびキャパシティ変数を定義する前に、組織内のネットワーク管理のためのオペレーションの全面的な概念を検知 して下さい。 この全面的な概念を定義するとき、あなたでネットワーク望まれる機能の精密 な 定義を構築できるビジネス基礎を提供します。 ネットワーク管理のためのオペレーショナルコンセプトを開発し損う場合絶えず顧客 需要が原因で移す目標または目標の欠如に導く場合があります。

通常は、ネットワーク管理プログラムのシステム定義フェーズの最初のステップとして、ネットワーク管理の運用コンセプトを確立します。 目的はオーバーオール望ましいシステム 特性を操作上の観点から記述することです。 この資料の使用はネットワークオペレーション、エンジニアリング、設計、他のビジネスユニットおよびエンドユーザの全面的なビジネス(nonquantitative)目標を調整することです。 このドキュメントの焦点は、ネットワーク管理と運用についての長期的な運用計画アクティビティを構築することです。 それはまた Service Level Agreements のようなすべてのそれに続く定義 ドキュメントの開発に指導を、提供します。 定義のこの初期セットは特定のネットワーク上の問題の管理に、全面的な組織にとってのおよびなるコストとの関係で重要性を強調するそれらの項目に明らかに同様に管理されるには余りに厳密に焦点を合わせることができませんが。 目標には次のものがあります。

  • ネットワーク インフラストラクチャを効率的に使用するために不可欠な特性を識別する。

  • ネットワークをサポートするサービスやアプリケーションを識別する。

  • エンドツーエンドのサービス管理を開始する。

  • サービス全体を向上させるパフォーマンス ベースのメトリックを開始する。

  • パフォーマンス管理情報を収集し、配布する。

  • ユーザからのフィードバックでネットワークの戦略的な評価を行う。

別の言い方をすれば、ネットワーク管理の運用コンセプトでは、組織全体の目標や、その目標を達成するための方針に焦点を当てることが必要です。 主な構成要素としては、任務の高度なレベルでの定義、任務の目的、システムの目標、組織の関与、および全体の運用方針があります。

ネットワーク管理者として、ユーザの頻繁に矛盾したパフォーマンスの期待を統一する位置にあります。 たとえば、ネットワークのための第一の必要条件が 1 位置からの別のものへの大きいファイルの転送なら、高い スループットおよびインタラクティブユーザの応答時間のより少しに焦点を合わせたいと思います。 いろいろな問題を検討しなかったらパフォーマンスの意見を制限しないように気を付けて下さい。 たとえば、ネットワークをテストする時、使用するロード レベルの外観。 よくあることですが、負荷が非常に小さなパケットに基ずいていながら、スループットは非常に大きなパケットに基づいていることがあります。 これらの性能試験のどちらかは確実 な映像を非常に生成 するかもしれませんネットワークトラフィックロードに基づいて、テストはパフォーマンスの実物写真を示さないかもしれません。 可能な限り ネットワークパフォーマンスを同様に多くの可能性のある負荷状態および文書化されています パフォーマンス調査して下さい。

また、多くのネットワーク管理組織において、デバイスの障害を技術者に通知するために、効率的なアラーム技術が使用されています。しかし、エンドツーエンドのアプリケーションのパフォーマンスを評価するプロセスを定義および実装することは、これよりも遥かに困難です。 従って、Network Operations Center (NOC)はダウンされたルータかスイッチにすぐに応答できるがネットワークパフォーマンスおよび影響ユーザ認識の下を掘るかもしれないネットワークの状態はその認識が否定的になるまで容易に見過ごされている行くかもしれません。 しかし難しいとはいえ、この 2 番目のプロセスは、ビジネス組織とネットワーク管理の双方に非常に大きな利点をもたらします。

最終的にはネットワークパフォーマンスの非現実的な期待を作成しないように、して下さい。 非現実的な期待は通常ネットワーキングプロトコルまたはアプリケーションの詳細を誤解するとき作成されます。 ネットワーク障害が原因でパフォーマンスが悪いのではなく、アプリケーションの設計が悪いことが原因になる場合もよくあります。 文書化する唯一の方法およびアプリケ− ションパフォーマンス メジャーはアプリケーションのインストール前のネットワークパフォーマンスのベースラインを持つことです。

要件を定義して下さい: サービス、スケーラビリティおよびアベイラビリティ オブジェクティブ

パフォーマンス管理、連続的な容量計画およびネットワーク設計の第一歩は要件やサービスを定義することです。 このステップはアプリケーション、基本的なトラフィックフロー、ユーザおよびサイト数を理解する、および要求されたネットワーク サービスことを必要とします。 この情報を最初に使用するのは、組織の目標に対するアプリケーションの重要性を判断するときです。 また、これらの情報は、論理設計での使用に関するナレッジ ベースを作成し、帯域幅、インターフェイス、接続性、設定、および物理デバイスなどの要件を理解する上で役立ちます。 この最初のステップによって、ネットワーク設計者がネットワークのモデルを作成できるようになります。

ネットワークエンジニアが将来 の 拡張必要条件を満たす作成し、提言された構想がネットワークの増加か拡張によるリソース制約を経験しないようにして下さいネットワークを設計するのを助けるためにソリューションスケーラビリティの目標を。 リソースの制約には次のものがあります。

  • 全体のトラフィック

  • 規模

  • ルートの数

  • バーチャル サーキットの数

  • ネイバーの数

  • ブロードキャスト ドメイン

  • デバイスのスループット

  • メディアのキャパシティ

ネットワークの設計者は、必要な設計寿命、予測される拡張範囲またはサイト(設計寿命を通じての予測が必要)、新規ユーザの数、および予測されるトラフィック量または変化について決定する必要があります。 この計画は提案された解決策が設計の写し出されたライフにわたる発展の必要条件を満足させるようにするのを助けます。

ソリューションスケーラビリティを調査しないとき、主要で対処的 な 設計変更を設定させますかもしれません。 この設計変更は追加階層、メディア アップグレード、またはハードウェア アップグレードを含むことができます。 主要なハードウェア購入のためのかなりはっきりした予算 サイクルに頼る組織では、これらの変更は全面的な成功へ主要な抑制剤である場合もあります。 アベイラビリティの点では、ネットワークは入手不能および対処的 な 手段の期間を引き起こす予想外リソース制限を経験できます。

相互運用性と相互運用性テストは、新規ソリューションの導入を成功させるうえで非常に重要です。 相互運用性の意味には、異なるハードウェア ベンダーだけでなく、ネットワークの実装中または実装後に接続しなければならない、異なるトポロジまたはソリューションが含まれます。 相互運用性の問題には、プロトコル スタックからルーティングに至るハードウェア シグナリングや、トランスポートの問題などがあります。 相互運用性の問題は、ネットワーク ソリューションの移行前、移行中、移行後に発生する可能性があります。 相互運用性計画には、異なるデバイス間の接続性や、移行中に発生する可能性のあるトポロジの問題を含める必要があります。

ソリューションの比較はその他 の 解決策 要件推奨事項に関連して異なる可能な設計を比較する推奨事項です。 この推奨事項はソリューションが特定の環境のための最適検索であること、そして個人的なバイアスが設計過程を駆動しないようにするのを助けます。 比較はコスト、復元力、アベイラビリティ、リスク、インターオペラビリティ、管理性、スケーラビリティおよびパフォーマンスのような異なるファクタを含むことができます。 これらの要素はすべて、設計が実装された後、ネットワーク全体のアベイラビリティに大きな影響を及ぼします。 また、メディア、階層、冗長性、ルーティング プロトコル、および同様の機能の能力についても比較できます。 ソリューションの比較を要約するために X 軸のファクタおよび Y軸ヘルプの潜在的解決能力で図を作成して下さい。 また、ラボ環境でソリューションを詳細に比較すれば、さまざまな比較要素について新規ソリューションと新機能を客観的に調査できます。

ネットワーク管理の運用コンセプトの一環として、ネットワークとサポートされているサービスの目標を、すべてのユーザが理解できるように定義することは不可欠です。 運用コンセプトの文書化後のアクティビティは、このドキュメントの品質に大きく影響されます。

これらは標準パフォーマンス目標です:

  • 応答時間

  • 使用率

  • スループット

  • キャパシティ(最大スループット比率)

これらの測定単位が簡単な LAN のためにとるに足らないかもしれません間、スイッチド キャンパス ネットワークかマルチベンダ エンタープライズ ネットワークで非常に困難である場合もあります。 作戦計画の考え抜かれた概念を使用するとき、パフォーマンス目標のそれぞれは測定可能な方法で定義されます。 たとえば、アプリケーション「x」に対する応答時間を、業務時間内のピーク時で 500 ミリ秒以下とします。 これは変数、方法それを測定するおよびネットワーク 管理 アプリケーションが焦点を合わせる必要がある日の期間を識別するために情報を定義します。

アベイラビリティおよびネットワーク管理目標を定義して下さい

アベイラビリティの目標では、ネットワーク サービスについてのサービス レベルまたはサービス レベルの要件を定義します。 これは満たします終わりアベイラビリティ要求をソリューションの確認を助けます。 特定の組織に対して異なるサービス クラスを定義し、アベイラビリティ要件に対応する各クラスのネットワーク要件を詳述します。 ネットワークの個別の領域はまたアベイラビリティの異なるレベルを必要とするかもしれません。 高可用性の目標は冗長性の増加を要し、手順をサポートするかもしれません。 特定のネットワークサービスのためのアベイラビリティ オブジェクティブを定義し、アベイラビリティを測定するとき、ネットワーク組織は写し出された SLA を実現させるために必要となるコンポーネントおよびサービス レベルを理解する場合があります。

全面的なネットワーク管理が管理機能に欠けていないようにするためにマネージャビリティ目標を定義して下さい。 マネージャビリティ目標を設定 するために、組織のためのサポート プロセスおよび関連するネットワーク管理用ツールを理解して下さい。 マネージャビリティ目標は潜在的な違いまたは新しい必要条件への参照と現在のサポートおよびツールモデルに合う新しいソリューション ナレッジをどのようにの含む必要があります。 これは新しいソリューションを配備の成功に優先するサポートし、ターゲット アベイラビリティの会う機能がのでネットワークアベイラビリティに重要です。

管理性の目標においては、想定されるネットワークのサポートに必要となるすべての重要な MIB またはネットワーク ツールに関する情報、新しいネットワーク サービスのサポートに必要なトレーニング、新しいサービスや他のサポート要件のための要員計画モデルを明確にする必要があります。 この情報が導入の前に明確になっておらず、新しいネットワーク設計をサポートするために割り当てるリソースが足りず、全体のアベイラビリティを満たせないこともよくあります。

パフォーマンスSLA およびメトリックを定義して下さい

パフォーマンスの SLA とメトリックは、新しいネットワーク ソリューションのパフォーマンスを定義および測定して、パフォーマンス要件を満たすのに役立ちます。 提案された解決策のパフォーマンスはパフォーマンスの監視ツールまたは提案されたネットワークインフラストラクチャを渡る単純なping と測定されるかもしれません。 パフォーマンス SLA には、予想されるトラフィック量の平均、トラフィック量のピーク、平均応答時間、および許容される最大の応答時間を含める必要があります。 この後、この情報はソリューションの検証セクションで使用され、最終的にはネットワークに必要なパフォーマンスとアベイラビリティの決定に役立ちます。

SLA を定義して下さい

ネットワーク設計の重要な側面はユーザまたは顧客向けのサービスを定義するときあります。 企業はこれらをサービス レベル契約と呼び、サービス プロバイダーはサービス レベル管理と呼びます。 サービス レベル 管理は一般的に問題の作業を開始するために各 tierサポート レベルの拡大が、時間を計る含まれ優先順位に基づいて近くのターゲットに時間を計ります前にエスカレーションパスおよび時間のような問題のタイプおよび重大度およびヘルプ デスク責任のための定義が。 他の重要な要因はサービスが容量計画、予防的なフォルトマネジメント、管理変更 通知、しきい値、アップグレード 基準およびハードウェア置換のエリアで提供されるものです。

組織がサービス レベルを前もって定義しないとき、後日識別されるリソース要求を改善するか、または得ることは困難になります。 またネットワークのかサポートを助けるために追加するべきどんなリソースを理解することも困難になります。 多くの場合、これらのリソースは問題が検出される後やっと適用します。

パフォーマンス メジャーの

パフォーマンスの管理は、異なるパフォーマンス領域の設定および測定を組み入れた包括的な用語です。 このセクションはパフォーマンス管理のこの 6 つの概念を記述します:

収集する ネットワークベースラインデータ

ほとんどの企業のイントラネットでは、十分な帯域幅が用意されています。 ただし、十分なデータなしで、悪いアプリケ− ションパフォーマンスへのコントリビューターとしてネットワーク輻輳を除外できないかもしれません。 輻輳やエラーが発生していることの手がかりの 1 つは、パフォーマンスの低下が断続的にあるいは時間帯によって起きていないかどうかを調べることです。 この条件の例はパフォーマンスが夕方遅く十分な、しかし朝におよび仕事時間のピークの間に非常に遅いときあります。

ネットワーク管理の運用コンセプトを定義し、必要な実装データを定義した後は、このデータを時間をかけて収集することが必要です。 このタイプの収集作業は、ネットワークのベースラインの基盤となります。

新しいソリューションのために設定 される予期を測定するために新しいソリューション(アプリケーションか IOS 変更)配備前に現在のネットワークのベースラインをおよび後配備実行しました。 このベースラインはソリューションがパフォーマンスおよびアベイラビリティ オブジェクティブおよび基準キャパシティを満足させたかどうか確認を助けます。 典型的なルータ/スイッチ ベースラインレポートは CPU、メモリ、緩衝域管理、リンク/メディア利用およびスループットに関する容量の問題が含まれています。 また含むかもしれないオペレーションの概念の定義された目標に基づいてベースラインデータには他の型があります。 たとえば、アベイラビリティベースラインはネットワーク環境の高められた安定性/アベイラビリティを示します。 ソリューション要件を確認するために古く、新しい環境間のベースライン比較を行って下さい。

もう一つの専門にされたベースラインはアプリケーション ネットワークの要求を向くとき貴重のアプリケーションベースラインです。 この情報は、アップグレード サイクルにおいて課金や予算編成の目的に使用することもできます。 アプリケーション別の望ましいサービスやサービス品質などに関連するアプリケーションのアベイラビリティの分野でも、アプリケーションのベースラインが重要になることがあります。 アプリケーションのベースライン情報は、時間帯ごとにアプリケーションによって使用される帯域幅で主に構成されています。 一部のネットワーク管理アプリケーションでは、アプリケーションのパフォーマンスをベースラインとすることができます。 トラフィックタイプの内訳は(Telnet か FTP)計画のためにまた重要です。 組織によっては、より重要なリソースが制限されたネットワークの領域を重要な指標として監視します。 ネットワーク管理者はネットワークを割り当てるか、計画するか、または調整するためにこの情報を使用できます。 ネットワークを調整するとき、Quality of Service を修正するか、またはネットワークサービスまたはアプリケーションのためのパラメータを並べるかもしれません。

アベイラビリティの測定

ネットワーク管理者が使用する主要なメトリックの 1 つにアベイラビリティがあります。 アベイラビリティとは、ユーザがネットワーク システムまたはアプリケーションを使用できる時間の指標です。 ネットワークの観点から見ると、アベイラビリティはネットワーク上の個々のコンポーネントの信頼性を表します。

たとえば、アベイラビリティを測定するために、管理対象装置から収集される統計情報のヘルプ デスク への 問い合わせを調整するかもしれません。 しかし、アベイラビリティ ツールでは、障害のすべての理由を判断することはできません。

ネットワーク冗長性はアベイラビリティを測定するとき考慮するべきもう一つのファクタです。 冗長性がない場合、全体的なネットワークに障害が生じるというよりも、サービスの低下を示します。 結果はより遅い破棄された パケットによる応答時間およびデータ損失であるかもしれません。 それは利用および応答時間のようなパーフォーマンス測定の他のエリアでまた可能性のある結果現れますです。

最終的には SLA に対して渡せば、予定された機能停止を考慮に入れる必要があります。 これらの停止は移動、 追加および変更、運転 休止、またはほしいと思わない報告されてかもしれない他のイベントの結果である可能性があります。 これはだけでなく、難しい仕事で、しかしまた手動タスクであるかもしれません。

応答時間メジャーの

ネットワークの応答時間とは、トラフィックが 2 つのポイント間を移動するのに必要な時間のことです。 見通される標準より遅い応答時間はベースライン比較またはそれしきい値を超過しましたり、輻輳かネットワーク障害を示すかもしれません。

応答時間はカスタマーネットワーク 使用の最もよいメジャーで、ネットワークの効果を正確に測るのを助けることができます。 応答が低下したことの原因が何であっても、トラフィックが遅延すればユーザはストレスを感じます。 流通網では、多くのファクタは応答時間に、影響を与えます(以下を参照):

  • ネットワークの輻輳

  • 宛先への望ましいルートが得られない(あるいはルートがまったくない)

  • 動力不足のネットワークデバイス

  • ブロードキャスト ストームなどのネットワーク障害

  • ノイズまたは CRC エラー

QoS関連キューイングを用いるネットワークでは、応答時間測定はトラフィックの正しい型がネットワークによって予想通り移動したかどうか確認して重要です。 たとえば、IP ネットワーク上の音声トラフィックを設定するとき、音声パケットは良好な音声の質を維持するために時間通りにおよび一定のレートで渡す必要があります。 ユーザに現われると同時にトラフィックの応答時間を測定するために音声トラフィックとして分類されるトラフィックを生成できます。

アプリケ− ションサーバとネットワーク管理者間の戦いの解決を助けるために応答時間を測定できます。 アプリケーションやサーバの速度が低下したときには、ネットワーク管理者が責任を感じることがよくあります。 ネットワーク管理者はネットワークが問題ではないと証明する必要があります。 応答時間データ 収集は証明するか、またはネットワークがアプリケーション トラブルのソースであると反証するために明白な手段(方法)を提供します。

可能であればいつでも、ユーザが受け取る応答時間を計測する必要があります。 ユーザは時間として彼らが画面 表示までのボタンを『Enter』 を押すか、またはクリックするとき応答をからの感知します。 この経過時間には、各ネットワーク デバイス、ユーザのワークステーション、および宛先サーバのトラフィックを処理するために必要な時間が含まれます。

残念ながら、測定単位はこのレベルでツールのユーザおよび欠如の数がほぼ不可能な原因です。 ユーザ および サーバ レスポンス時間を組み込むとき更に、それは未来のネットワーク拡大またはトラブルシューティング ネットワーク上の問題を判別するとき少し値を提供します。

応答時間の計測には、ネットワーク デバイスやサーバを使用できます。 また、ICMP などのツールを使用してトランザクションを計測することもできますが、上位のレイヤが処理しているときにシステムに生じる遅延は考慮されません。 このアプローチはネットワークパフォーマンス ナレッジの問題を解決します。

単純な視点で、応答時間を測定するためにネットワーク管理ステーションからのネットワークのキーポイントに ping への応答を、サービスプロバイダー接続のメインフレーム インターフェイス、エンドポイント、またはキー ユーザ IP アドレスのような時間を計ることができます。 この方式における問題はそれ正確に反映しませんマシンと宛先 の マシン間の応答時間のユーザ認識をです。 それは情報を単に収集し、ネットワーク管理ステーション観点からの応答時間を報告します。 また、この方法では、ネットワーク全体のホップごとの応答時間の問題を覆い隠してしまいます。

サーバセントリックポーリングへの代替はメジャーのために模倣したい送信元および宛先に近い方の努力を配ることです。 分散型ネットワーク管理ポーラーを使用し、Cisco IOS Service Assurance Agent(SAA; サービス保証エージェント)機能を実装します。 ルータおよびサーバのようなデスティネーションデバイスまたは別のルータ間の応答時間を測定することをルータの SAA が可能にすることができます。 またトラフィックをそれが模倣するトラフィックと同じようにおよび誘導転送されるために強制する TCP または UDP ポートを規定できます。

マルチサービス ネットワークの音声、ビデオおよびデータの統合によって、顧客はネットワークの QoS プライオリティ設定を設定します。 簡単な ICMP または UDP 測定単位は正確に異なるアプリケーションが異なる優先順位を受け取るので応答時間を反映しません。 また、Tagスイッチングと、トラフィック ルーティングは特定のパケットに含まれているアプリケ− ションタイプに基づいて変わるかもしれません。 従って各ルータがどのようにのそれを処理し、異なるかもしれませんか、より少なく効率的なルーティングを受け取る ICMP Ping は異なる優先順位を受け取るかもしれません。

この場合、応答時間を測定する唯一の方法は、特定のアプリケーションや対象とするテクノロジーに類似したトラフィックを生成することです。 これによって、ネットワーク デバイスが、実際のトラフィックに対して行う処理と同様の方法でこのトラフィックを処理するようになります。 SAA のまたはサードパーティアプリケーションを意識したプローブの使用によるこのレベルを達成できるかもしれません。

正確さメジャーの

精度とは、エラーが発生していないインターフェイス トラフィックの指標であり、一定時間内での全体のパケットの比率に対する成功率を比較するパーセンテージで表すことができます。 最初に、エラー率を測定する必要があります。 たとえば、100 パケットごとにエラーが 2 つ発生した場合、エラー率は 2 % となり、精度率は 98 % となります。

以前のネットワーク技術では、特に大規模ネットワークの場合には、ある程度のエラーは受容されていました。 ただし、高速ネットワークおよび現代 WAN サービスと、伝達はかなりより正確であり、実際の問題がなければエラー発生率はゼロに密接です。 一般的なインターフェイスのエラーには、次のような原因があります。

  • 仕様外の配線

  • 電気的な干渉

  • ハードウェアまたはソフトウェアの障害

詳しい調査を開始するには、低い精度率を使用します。 特定のインターフェイスが問題を示し、エラーが受諾可能であることを決定することを検出するかもしれません。 この場合は、このインターフェイスに対する精度のしきい値を調整して、受容できないエラー率を反映させるようにします。 受け入れられないエラー発生率はより早いベースラインで報告されるかもしれません。

この表に説明がある変数は正確さおよびエラー発生率数式で使用されます:

表記 説明
ΔifInErrors 集まる 2 つのポールサイクル間の差分(か違い) snmp ifInErrors 反対します、エラーと着信パケットの数を表す。
ΔifInUcastPkts 集まる 2 つのポールサイクル間の差分は snmp ifInUcastPkts 反対します、受信 ユニキャスト パケットの数を表す。
ΔifInNUcastPkts 集まる 2 つのポールサイクル間の差分は snmp ifInNUcastPkts 反対します、受信非ユニキャスト パケットの数を表す(マルチキャストおよびブロードキャスト)。

エラー率を計算する式は、通常はパーセンテージで表現します。

エラー発生率 = (ΔifInErrors) *100

--------------------------------------------------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts)

エラー率や精度の式では、発信エラーは対象とされていないことに注意してください。 これは、デバイスがエラーを含むパケットを故意にネットワーク上に送信することは決してなく、発信インターフェイスのエラー率が増加することは考えられないためです。 したがって、着信トラフィックとエラーだけが、インターフェイスのエラーと精度を測定する対象となります。

精度を計算する式では、100 からエラー率を減算します(この式ではパーセンテージを使用します)。

正確さ = 100 - (ΔifInErrors) *100

-----------------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts)

これらの式は、MIB II インターフェイス(RFC 2233)の Generic カウンタでのエラーと精度が反映されます。 結果は、送信された全体のパケット数とエラーを比較したパーセンテージで表されます。 生じるエラー発生率は 100 から引かれます、精度を生成 する。 100 % の精度率は、完全であることを意味します。

MIB II の変数はカウンタに保存されるため、2 つのポール サイクルを使用して、この 2 つの値の差を計算します(そのため、この式でデルタが使用されています)。

利用メジャーの

使用率は、特定のリソースの一定時間内の使用度を測定します。 この測定値はリソースの使用量を最大運用可能キャパシティに比較したもので、パーセンテージで表されます。 使用率の測定値から、ネットワーク全体の輻輳(または発生する可能性のある輻輳)の状態を判断できます。 また十分に利用されていないリソースを識別できます。

利用はネットワーク パイプ(リンク)がどのように十分にあるか判別するプリンシパル手段です。 ネットワークシステム資源が消費されるエクステントを確認するために CPU、インターフェイス、キューイングおよび他のシステムに関係したキャパシティ測定単位を測定して下さい。

使用率が高いことは、必ずしも悪いことではありません。 低い利用は予想外場所のトラフィックフローを示すかもしれません。 行が過剰使用されるようになると同時に、効果は重要になることができます。 過度の使用はインターフェイスを渡るために並べられるより多くのトラフィックがあるとよりそれ処理できる発生します。 リソースの使用率の突然の増加は、障害を示している可能性があります。

インターフェイスが輻輳し始めると、ネットワーク デバイスはパケットをキューに入れるか、廃棄せざるをえません。 ルータがフルキューでパケットを蓄えるように試みる場合パケットは廃棄されます。 破棄された パケットはトラフィックがファースト インターフェイスからより遅いインターフェイスへの転送されるとき生じます。 これは数式で u が利用である、および Q は平均キュー項目数(仮定されるランダム トラフィック)ですところ Q = u/示されます(1-u)。 したがって、リンク上での使用率のレベルが高いと、平均的なキューの深さも深くなり、パケットのサイズが分かっていれば、遅延を予測できます。 ネットワーク レポート関連のベンダーの中には、より小さな帯域幅を指定して、WAN のコストを削減するように示唆するものもあります。 ただし、レイテンシー影響は 95% 利用で WAN リンクを実行すると現われます。 なお、ネットワークが VoIP に移行されるので、ネットワーク管理者はおよそ 50% 利用でポリシーおよび実行 WAN リンクを変更する必要があるかもしれません。

パケットが廃棄されるとき、ハイレイヤプロトコルはパケットの再送信を強制するかもしれません。 複数のパケットが廃棄される場合、余分な リトライ トラフィックは生じる場合があります。 反作用のこの型は行の下のデバイスのバックアップという結果に更に終る場合があります。 この問題を解決するために、異なる程度のしきい値を設定 するかもしれません。

ネットワーク使用率の測定のうち最も一般的なものは、インターフェイスの使用率です。 測定する接続が半二重または全二重方式であるかどうか基づいてこの表に説明がある数式を使用して下さい:

表記 説明
ΔifInOctets 集まる 2 つのポールサイクル間の差分(か違い) snmp ifInOctets 反対します、受信 トラフィックのオクテットの数を表す。
ΔifOutOctets 集まる 2 つのポールサイクル間の差分は snmp ifOutOctets 送信 トラフィックのオクテットの数を表すかどれが反対します。
ifSpeed snmp ifSpeed オブジェクトで報告されるインターフェイスのスピード。 ifSpeed が正確に WANインターフェイスの速度を反映しないかもしれませんことに注目して下さい。

共有LAN接続は送信する前に主にコンテンション検知がことをデバイス リッスン必要とするので半二重でありがちです。 WAN 接続は接続がポイント ツー ポイントであるので一般的に全二重方式です; デバイスは両方とも送信でき、確認するので同時に受け取ることはそこに接続を共有するたった 1 つのその他のデバイスです。

MIB II の変数はカウンタに保存されるため、2 つのポール サイクルを使用して、この 2 つの値の差を計算します(そのため、この式でデルタが使用されています)。

半二重 メディアに関しては、インターフェイス 利用のためにこの数式を使用して下さい:

(ΔifInOctets + ΔifOutOctets) * 8 * 100

----------------------------------------------------

(Δの秒数) * ifSpeed

全二重メディアに関しては、利用計算はより複雑です。 たとえば、全二重 T-1 シリアル接続では、回線速度は 1.544 Mbps です。 これは、T-1 インターフェイスでは送受信の両方を 1.544 Mbps で行うことができ、全体としての帯域幅は 3.088 Mbps になることを意味します。

全二重接続のためのインターフェイス 帯域幅を計算するとき、のより大きいの奪取 するおよび値を使用でき、稼働率を生成しますこの数式:

最大値(ΔifInOctets、(ΔifOutOctets) * 8 * 100

-----------------------------------------

(Δの秒数) * ifSpeed

しかし、この方式では、小さい値の方向の使用率が隠されており、結果の精度はやや低くなります。 より多くの正確な方法はインプット利用率およびアウトプット利用率を、別々に測定することです(以下を参照):

インプット利用率 = ΔifInOctets *8 * 100

--------------------------------------------------------------------------

(Δの秒数) * ifSpeed

および

アウトプット利用率 = ΔifOutOctets *8 * 100

------------------------------------

(Δの秒数) * ifSpeed

これらの数式が幾分簡単である間、特別なプロトコルとのオーバーヘッド準を考慮に入れません。 より精密な数式は各プロトコルの特徴を処理するためにあります。 たとえば、RFC 1757 ではイーサネットの使用率についての式が定義されており、パケット オーバーヘッドが考慮されています。 ただし、高可用性のチームはここに示される一般の数式が LAN および WANインターフェイス両方を渡ってほとんどの場合確実に使用することができることが分りました。

キャパシティ計画

先に示されるように、容量計画はビジネス必須アプリケーションのパフォーマンスかアベイラビリティインパクトを防ぐために本当らしい未来のネットワークリソース要件を判別するプロセスです。 容量 および 性能管理を参照して下さい: このトピックに関する詳細な情報詳細については最良 の 方法 白書

予防的な障害分析を行って下さい

予防的な障害分析は、パフォーマンス管理に不可欠な要素です。 予防的な障害分析では、パフォーマンス管理用に収集されたものと同じタイプのデータを使用できます。 しかし、予防的な障害管理とパフォーマンス管理では、このデータを取得するタイミングと使用方法が異なります。

予防的な障害管理は、理想的なネットワーク管理システムが設定した目標に到達するための方法です。 パフォーマンス管理へのリレーションシップは使用するデータ 変数およびベースラインによってあります。 予防的なフォルトマネジメントはカスタマイズされたイベントを、イベント 相関 エンジン、札をつけるトラブル統合ベースラインデータの統計 分析は接続するために、理想的で、有効なネットワーク管理システムのパフォーマンスおよび管理変更非難します。

パフォーマンスデータ ポーリングが普通 10、15、また更に 30 分毎に達成されるところで、障害状態の認識は大いにより短いタイムインターバルである必要があります。 予防的な障害管理の 1 つの方法は、RMON アラームとイベント グループを使用することです。 外部デバイスからポーリングされないデバイス上にしきい値を設定することで、しきい値をさらに短くすることができます。 もう一つの方式はマネージャのマネージャでデータの集約のローカル レベルでポーリングを有効に する分散管理 システムの使用によって、この資料でカバーされない、あります。

予防的なフォルトマネジメントのためにしきい値を使用して下さい

スレッシュホールドの設定はしきい値が引き起こされるとき特定のデータ ストリームの対象のポイントを定義し、イベントを生成するプロセスです。 ネットワークのパフォーマンスに関するデータを使用して、しきい値を設定します。

しきい値には異なるタイプがいくつかありますが、データのタイプごとに適したしきい値があります。 しきい値は数値的なデータにだけ適用可能なため、元のデータは離散数値に変換されます。 オブジェクトのための可能性のある 文字列すべてを知らなくても、まだ「興味深い」ストリングを列挙し、設定値に他のストリングをすべて割り当てることができます。

数値データの 2 つのクラスのためのしきい値の 2 つのクラスがあります: 連続的、離散。 連続的なしきい値は、SNMP カウンタやゲージに記録される連続的あるいは時系列的なデータに適用します。 離散しきい値は、列挙型のオブジェクトや離散的な数値データに適用します。 ブール値オブジェクトは 2 つの値の列挙値です: 本当か偽。 離散データは、イベント データとも呼ばれます。これはイベントによってある値から別の値への移行が行われるためです。

連続的なしきい値は、時系列のオブジェクトの値が指定したしきい値を越えたときにイベントをトリガーします。 オブジェクト値はしきい値の上に上がるか、またはそれの下で下ります。 また、上昇および下降しきい値を別々に設定することもできます。 この技術はヒステリシス メカニズムと呼ばれ、このデータのクラスから生成されるイベントの数を減らすのに役立ちます。 ヒステリシス メカニズムは、急速に変化する時系列データのしきい値から生成されるイベントの量を減らします。 このメカニズムは、時系列データのあらゆるしきい値の手法と合わせて使用できます。

イベントの量は、オブジェクトの値を追跡するために生成されるアラームを使用して減らすことができます。 このアラームには、上昇しきい値と下降しきい値を割り当てます。 アラームは、データの値が上昇しきい値を上回ったときにだけトリガーされます。 しきい値をいったん越えると、上昇アラームは下降しきい値を下回るまで再度生成されることはありません。 そして同じメカニズムは上昇しきい値が再度超えるまで下降しきい値の生成を防ぎます。 このメカニズムがイベント量を大幅に減らすことができた、確認するために必要な情報をかどうかエラー存在除去しません。

時系列のデータは、カウンタまたはゲージとして表されます。カウンタの場合は、新しいデータのポイントがそれまでのデータのポイントの合計に追加されます。ゲージの場合は、時間間隔内の比率としてデータが表現されます。 各データタイプに適当な連続的な閾値の 2 つの異なる形式があります: 絶対連続的なしきい値および相対的で連続的な閾値。 絶対値による連続的しきい値はゲージに対して、相対値による連続的しきい値はカウンタに対して使用します。

ネットワークの閾値を判別するために、これらのステップを完了して下さい:

  1. オブジェクトを選択します。

  2. デバイスとインターフェイスを選択します。

  3. 各オブジェクトの閾値を判別するか、または反対して下さい/インターフェイスの種類。

  4. 各しきい値によって生成されるイベントの重大度を決定します。

かなりの量の作業がどのオブジェクトかで判別するために必要となります(およびどのデバイスおよびインターフェイスのために)使用するべきどんなしきい値を。 幸いにもパフォーマンスデータのベースラインを集めたら、かなりのその作業を既に終了してしまいました。 また、NSA およびサービス(HAS)高可用性のプログラムはセット オブジェクト助け、範囲を作成する推奨事項を伝えることができます。 しかし、この推奨事項を使用している特定のネットワークに合わせる必要があります。

ネットワークに関するパフォーマンス データを収集済みであるときには、HAS プログラムからインターフェイスをカテゴリ別にグループ化することが推奨されます。 これは各デバイスに対するよりもむしろ各カテゴリのメディアタイプのためのしきい値を判別し、そのデバイスで反対する必要があるかもしれませんので設定しきい値を簡素化します。 たとえば、イーサネット ネットワークと FDDI ネットワークに別々のしきい値を設定するとします。 一般的には、イーサネット セグメントを共有するよりも、FDDI ネットワークを 100 % に近い使用率で実行した方がよいと考えられています。 しかし、全二重方式のイーサネットでは、コリジョンが生じないため、100 % に近い使用率で実行できます。 決して衝突を見るべきではないので全二重リンクのために低い衝突のためのしきい値を非常に設定 したいと思うかもしれません。

また、インターフェイスの重要性および、しきい値のタイプのカテゴリや重要度の組み合わせを考慮することもできます。 これらの要素を使用してイベントに優先順位を設定し、その結果、イベントの重要性とネットワークの運用スタッフからの注目度を設定します。

ネットワークデバイスおよびインターフェイスのグループ化し、分類は誇張することができません。 グループ化とカテゴリ化が可能になればなるほど、ネットワーク管理プラットフォームに対してしきい値のイベントを統合できるようになります。 この情報に対しては、ベースラインを基本的なリソースとして使用します。 容量 および 性能管理を参照して下さい: 詳細については最良 の 方法 白書

ネットワーク管理の実装

組織ではネットワーク管理システムを実装して、定義したしきい値を検出し、指定した時間内の値をレポートする必要があります。 RMON ネットワーク管理システムを使用すると、しきい値のメッセージを日常的なレビュー、あるいは完全なデータベース ソリューション用にログ ファイルに蓄積できます。これを使用して、あるパラメータについてのしきい値の例外を検索することができます。 情報はネットワークオペレーション担当者およびマネージャに手数料ベースで利用可能であるはずです。 ネットワーク管理の実装には、ソフトウェアやハードウェアのクラッシュまたはトレースバック、インターフェイスの信頼性、CPU、リンクの使用率、キューまたはバッファの失敗、ブロードキャストの量、キャリアの移行、インターフェイスのリセットなどを検出する機能を持たせる必要があります。

ネットワークの運用メトリック

予防的な障害管理の最後の部分は、パフォーマンス管理と重複しますが、ネットワークの運用メトリックです。 これらのメトリックは障害管理 プロセス機能強化に貴重 な データを提供します。 少なくとも、これらのメトリックには、ある時間内に発生したすべての問題を分類したものを含める必要があります。 この分類には、次のような情報が含まれている必要があります。

  • 呼優先度によって発生する問題の数

  • 各優先度におけるクローズまでの最小、最大、平均時間

  • 問題のタイプごとの分類(ハードウェア、ソフトウェア クラッシュ、設定、電源、ユーザによるエラー)

  • 各問題のタイプがクローズするまでの時間の内訳

  • アベイラビリティ グループまたは SLA ごとのアベイラビリティ

  • どのくらいの頻度で SLA 要件に適合、または適合しないか

ヘルプ デスクでは、多くの場合、メトリックやレポートを作成できる機能を備えたレポーティング システムが備えられています。 このデータを収集するもう一つの手段(方法)はアベイラビリティ モニタリング ツールの使用です。 全体のメトリックは、月単位をベースとして入手できるようにします。 説明に基づくプロセス改良は抜けていたサービス レベル 契約必要条件を改善するためまたはある特定の問題のタイプがどのように処理されるか改善するために設定されるであるはずです。

パフォーマンス管理のインジケータ

パフォーマンス指標は、重要な成功要因を測定するための仕組みを提供します。

ネットワーク管理業務目標を文書化して下さい

このドキュメントはネットワーク管理を運用するための公式なコンセプト、あるいは必要な機能や目標に関する非公式な声明となることがあります。 ただし、資料はそれらが成功を測定すると同時にネットワーク管理者を助ける必要があります。

この資料は組織のネットワーク マネージメント 戦略で、ネットワークオペレーション、エンジニアリング、設計、他のビジネスユニットおよびエンドユーザの全面的なビジネス(nonquantitative)目標を調整する必要があります。 この点に注目することにより、組織におけるネットワーク管理と運用についての長期のアクティビティ計画を行えるようになります。これには、予算編成のプロセスも含まれます。 ツールの獲得および SLA のようなネットワーク管理目標を、達成することを必要な統合パスにまた指導を提供します。

この戦略的な資料は特定のネットワーク上の問題の管理に、全面的な組織にとって重要な予算上問題が含まれているそれらの項目に余りに厳密に焦点を合わせることができませんが。 次に、例を示します。

  • 到達可能な目標を備えた包括的な計画を明確にする。

  • 各ビジネス サービスを/アプリケーションを識別して下さいネットワークサポートを必要とする。

  • サービスの測定に必要なパフォーマンス ベースのメトリックを明確にする。

  • パフォーマンス メトリック データの収集や配布を計画する。

  • ネットワークの評価やユーザのフィードバックに必要なサポートを明確にする。

  • 測定可能なサービス レベルの目標を詳細に定め、文書化する。

Service Level Agreements を文書化して下さい

SLA を正しく文書化するには、サービス レベル目標のメトリックを完全に定義する必要があります。 このドキュメントは、ユーザが評価を行う際に使用できるようにします。 これによってフィードバックのループができ、ネットワーク管理の組織がサービス契約のレベルを維持するために必要な変数を測定し続けることができます。

SLA は「生きている」ドキュメントといえます。これはビジネス環境とネットワークは本質的に変化し続けるものであるためです。 今日どんな作業 SLA を測定することは明日廃止になるかもしれませんか。 彼らが設けるときだけその情報のユーザおよび行為からのフィードバックループがネットワークオペレーション 組織によって必要な高可用性の数を維持できます。

ベースラインのための変数のリストを作成して下さい

このリストは変数がトラップのためにと同時に各変数に対して使用されるトリガー、およびトレンド分析使用されるかどうか、ポーリング間隔のような項目が、可能性のある トリガーしきい値負われる含まれていますネットワーク管理 オーバーヘッド。

これらの変数は、前述したサービス レベルの目標に必要なメトリックに限定されるものではありません。 少くとも、それらはこれらの変数を含む必要があります: ルータの動作状態、スイッチ健全性、ルーティング情報、テクノロジー別データ、利用および遅延。 これらの変数は定期的に集められ、データベースで保存されます。 その後、このデータに対してレポートを作成します。 これらのレポートはこれらの方法でネットワーク管理 オペレーションおよび計画担当者を助けることができます:

  • 事後対処的な問題を履歴データベースを使用して迅速に解決する。

  • パフォーマンス レポートやキャパシティ計画はこのタイプのデータを必要とする。

  • このレポートに照らし合わせてサービス レベルの目標を測定する。

ベースラインおよび傾向分析を検討して下さい

ネットワーク管理の担当者は、定期的にミーティングを開催して、具体的なレポートを検討する必要があります。 このミーティングにより、新たなフィードバックを行うほか、ネットワーク上の潜在的な問題に対する予防的なアプローチを行うことができます。

これらのミーティングには、運用と計画の両方の担当者が加わる必要があります。 計画担当者にとっては、ベースラインやトレンドを示すデータを運用面から分析した結果を入手する機会となります。 また、このミーティングによって、運用スタッフが計画分析のための「メンバーの一員」となります。

これらのミーティングに加えるもう 1 つの項目は、サービス レベルの目標です。 目標しきい値がアプローチされると同時に、ネットワーク管理要員は目標が抜けていることを防ぐために処置をとり、場合によっては、このデータは部分的な予算上位置調整として使用することができます。 データは適切な手段が奪取 されない場合サービスレベル目標がどこに破られることを行くか示すことができます。 また、これらの目標はビジネス サービスとアプリケーションによって明確にされているため、財政基盤に対する正当化を容易に行うことができます。

このようなレビューを 2 週間ごとに行って、さらに徹底的な分析のためのミーティングを 6 週間から 12 週間に 1 度行います。 これらのミーティングにより、短期および長期にわたる問題を解決できるようになります。

起こり得る問題の分析の方法論を文書化して下さい

what-if 分析には、ソリューションのモデリングと検証が含まれます。 ネットワーク(Cisco IOS リリースの新規アプリケーションか変更)に新しいソリューションを追加する前に、代替のいくつかを文書化して下さい。

この分析のためのドキュメントには、主な疑問点、方法論、データ セット、設定ファイルなどが含まれます。 要点は what-if 分析が誰か他の人が資料で提供される情報と作り直せるはずである実験であることです。

ネットワークパフォーマンスを向上するために使用される方法論を文書化して下さい

このドキュメントは追加 WAN 帯域幅をおよび増加をリンクの特定の種類のための帯域幅助けるコストテーブルが含まれています。 この情報は組織がどの位時間および通貨帯域幅を増加するために要するか実現するのを助けます。 公式な文書化を行うことにより、パフォーマンスとキャパシティの専門家が、パフォーマンスが向上した方法とタイミングを特定でき、さらにこの成果にかかったタイム ラインやコストを特定できるようになります。

定期的に最新に残ることを確認するために年四回実績 審査の一部分としてこのドキュメントを、多分参照して下さい。

要約

理想的なネットワーク管理システムの目標を達成するための唯一の方法は、パフォーマンス管理のためのコンポーネントを積極的にシステムに組み込んでいくことです。 この目標はしきい値が超過されたしきい値のとき通知のシステムに結ばれるアベイラビリティおよび応答時間メトリックの使用を含む必要があります。 また、キャパシティ計画のためのベースラインの使用も組み込む必要があります。これはプロビジョニングと例外レポートのための発見的なモデルとリンクします。 さらに、組み込み型のモデリングまたはシミュレーション エンジンを含める場合もあります。これによってモデルをリアル タイムで更新し、ソフトウェア シミュレーションによって計画とトラブルシューティングの両方のレベルを提供します。

このシステムの多くが決して実現できない不可能な理想のようであるかもしれません間、コンポーネントのそれぞれは今日現在利用できます。 さらに、これらのコンポーネントを統合するためのツールも、MicroMuse のようなプログラムがすでに存在しています。 それが現実的な今日であるのでこの理想の方にはたらき続ける必要があります。


関連情報


Document ID: 15115