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

キャパシティと性能の管理:: ベスト プラクティスのホワイト ペーパー

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


目次

CPU

概要

大規模な企業やサービス プロバイダーのネットワークでは、ネットワークのハイアベイラビリティはミッションクリティカルな要件です。 予定外のダウンタイム、専門知識の不足、不十分なツール、複雑なテクノロジー、ビジネスの統合、競争の激化する市場など、ネットワーク管理者がより高いアベイラビリティを提供する上で直面する問題は増加しています。 キャパシティとパフォーマンスを管理することは、ネットワーク管理者が新しいビジネス目標と、ネットワークの一貫したアベイラビリティとパフォーマンスを実現する手助けとなります。

このドキュメントでは、次のトピックについて検証します。

  • ネットワークにおけるリスクと潜在的なキャパシティ問題を含む、一般的なキャパシティとパフォーマンスの問題。

  • what-if 分析、ベースライニング、トレンディング、例外管理、および QoS 管理を含む、キャパシティおよびパフォーマンス管理のベスト プラクティス。

  • キャパシティ 計画で使用される一般的なテクニック、ツール、MIB 変数、およびしきい値を含む、キャパシティ計画の戦略を作成する方法。

キャパシティおよびパフォーマンス管理の概要

キャパシティ計画とは、ビジネスクリティカルなアプリケーションにパフォーマンスやアベイラビリティの影響を与えないために、必要なネットワーク リソースを決定するプロセスです。 パフォーマンス管理とは、ネットワーク サービスの応答時間、一貫性、および個々のサービスやサービス全体の品質を管理する方法です。

注:通常、パフォーマンスの問題はキャパシティに関連します。 帯域幅によっては、データはネットワーク経由で伝送される前にキューで待機する必要がありますので、アプリケーションはより時間がかかるようになります。 音声アプリケーションでは、遅延やジッタなどの問題は直接音声コールの品質に影響します。

ほとんどの組織はすでに何らかのキャパシティ関連情報を収集しており、問題を解決し、変更を計画し、新しいキャパシティとパフォーマンスの機能を実装するための作業を一貫して行っています。 しかし、組織は日常的にはトレンディングや what-if 分析を行っていません。 what-if 分析は、ネットワーク変更の影響を判別するプロセスです。 トレンディングは、ネットワークのキャパシティおよびパフォーマンス問題の一貫したベースライン適用を実施して、将来的なアップグレード要件を知るためにベースラインをレビューしてネットワークの傾向を知るプロセスです。 キャパシティおよびパフォーマンス管理には、ユーザが報告する前に問題を識別して解決する例外管理と、ネットワーク管理者が個々のサービス パフォーマンスの問題を識別し、管理し、計画する QoS 管理も含める必要があります。 次の図は、キャパシティおよびパフォーマンス管理のプロセスを示しています。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/20769-process.gif

キャパシティおよびパフォーマンス管理には制約もあり、通常、これは CPU とメモリに関連するものです。 問題の原因が潜在する可能性があるエリアを次に示します。

  • CPU

  • バックプレーンまたは I/O

  • メモリとバッファ

  • インターフェイスとパイプのサイズ

  • キューイング、遅延、およびジッタ

  • 速度と距離

  • アプリケーション特性

キャパシティ計画とパフォーマンス管理の資料には、いわゆる「データ プレーン」と「コントロール プレーン」についても記述されているものがあります。 データ プレーンは単純に、ネットワークを通過するデータに関連するキャパシティとパフォーマンスの問題であるのに対し、コントロール プレーンは、データ プレーンの適切な機能を維持するのに必要なリソースを意味します。 コントロール プレーンの機能には、ルーティング、スパニング ツリー、インターフェイスのキープアライブ、およびデバイスの SNMP 管理などの、サービスのオーバーヘッドが含まれます。 このようなコントロール プレーン要件としては、ネットワークを通過するトラフィックと同様、CPU、メモリ、バッファリング、キューイング、および帯域幅が使用されます。 コントロール プレーン要件の多くは、システムの全体的な機能にも不可欠です。 それらが必要とするリソースを持たなければ、ネットワークは失敗します。

CPU

CPU は通常、どのようなネットワーク デバイス上でもコントロール プレーンとデータ プレーンの両方で使用されます。 キャパシティおよびパフォーマンス管理では、デバイスとネットワークが機能するのに十分な CPU を常に確保する必要があります。 1 つのデバイス上のリソースが不適切なだけでネットワーク全体に影響を及ぼす可能性があり、CPU が不十分なためにネットワークが機能しなくなることもよくあります。 また、処理をメイン CPU に依存しないハードウェア スイッチングの装備がない場合は、CPU が不十分だと、データは処理を待つ必要があるために遅延が増加する可能性があります。

バックプレーンまたは I/O

バックプレーンまたは I/O とは、1 つのデバイスが処理できるトラフィックの総量を指し、通常バス サイズやバックプレーン能力といった用語で表されます。 バックプレーンが不十分だと、一般的にパケットのドロップが発生し、再送信が発生してトラフィックが増加する可能性があります。

メモリ

メモリは、データ プレーンとコントロール プレーンの要件を持つもう 1 つのリソースです。 メモリは、ルーティング テーブル、ARP テーブル、その他のデータ構造などの情報に必要です。 デバイスのメモリが使い果たされると、デバイスの一部の動作が失敗する可能性があります。 状況によっては、その操作がコントロール プレーン プロセスやデータ プレーン プロセスに影響する場合があります。 コントロール プレーン プロセスが失敗すると、ネットワーク全体の品質が低下する可能性があります。 たとえば、ルーティング コンバージェンスに余分なメモリが必要な場合にこの状況が発生します。

インターフェイスとパイプのサイズ

インターフェイスとパイプのサイズは、1 つの接続上で同時に送信できるデータ量を指します。 これは、接続の速度と誤って言及されることが多いですが、データは実際には 1 つのデバイスから別のデバイスへ異なった速度で移動するわけではありません。 シリコン速度とハードウェア能力は、メディアに基づいて利用可能な帯域幅を特定するのに役立ちます。 さらに、ソフトウェアのメカニズムによって、サービスに割り当てられている特定の帯域幅に合わせてデータを「抑制」できます。 これは通常、1.54 kpbs から 155 Mbps 以上の固有の速度能力を持つフレームリレーや ATM のサービス プロバイダー ネットワークで見られます。 帯域幅制限がある場合、データは送信キューにキューイングされます。 送信キューはキュー内のデータに優先順位をつける異なるソフトウェアメカニズムがあるかもしれません; ただし、キューにデータがあるとき、それはデータにインターフェイスを転送できる前に既存のデータを待つ必要があります。

キューイング、遅延、およびジッタ

キューイング、遅延、およびジッタもパフォーマンスに影響します。 様々な方法で送信キューを調整することにより、パフォーマンスに影響を与えることが可能です。 たとえば、キューが大きければ、データは長時間待つことになります。 キューが小さければ、データはドロップされます。 これはテール ドロップと呼ばれ、データは再送信されるので、TCP アプリケーションでは許容されています。 しかし、キューのドロップや深刻なキュー遅延により音声とビデオのパフォーマンスが悪化するため、帯域幅やパイプ サイズには特に注意が必要です。 キュー遅延はまたインプットキューとデバイスが十分なリソースをすぐにパケットを転送する備えない場合発生する場合があります。 これは、CPU、メモリ、またはバッファが原因になる場合があります。

遅延とは、パケットが受信されてから転送されるまでの通常の処理時間を表します。 正常な現代データ スイッチにおよびルータにリソース制約なしで極端に低い レイテンシーが(< 1ms)通常の状態であります。 アナログ音声パケットを変換して圧縮する Digital Signal Processors(DSP; デジタル信号プロセッサ)を備えた最近のデバイスでは、もう少し時間がかかり、20 ミリ秒にまでなる場合があります。

ジッタとは、音声とビデオを含むストリーミング アプリケーションにおけるパケット間の格差を表します。 パケット間の時間格差が異なり、パケットが異なったタイミングで到着すると、ジッタは高くなり音声品質は低下します。 ジッタは主にキュー遅延の要因となります。

速度と距離

速度と距離もネットワーク パフォーマンスの要素です。 データ ネットワークは、光速に基づく一貫したデータ転送速度を持ちます。 これは、およそ 100 マイル/ミリ秒です。 ある組織でクライアント サーバ アプリケーションが国際的に稼働している場合、対応するパケット転送遅延を予測できます。 アプリケーションがネットワーク パフォーマンスに合わせて最適化されていない場合、速度と距離はアプリケーションのパフォーマンスにとって重要な要素となる場合もあります。

アプリケーション特性

アプリケーション特性は、キャパシティとパフォーマンスの要因としては最も影響が小さいエリアです。 ウィンドウ サイズが小さいなどの問題、アプリケーションのキープアライブ、およびネットワーク経由で送信されるデータ量と必要要件の関係は、多くの環境、特に WAN におけるアプリケーションのパフォーマンスに影響する可能性があります。

キャパシティおよびパフォーマンス管理のベスト プラクティス

このセクションでは、キャパシティおよびパフォーマンス管理の主な 5 つのベスト プラクティスについて詳細に説明します。

サービスレベル管理

サービス レベル管理では、他に必要なキャパシティおよびパフォーマンス管理プロセスを定義し、規制します。 ネットワーク管理者は、キャパシティ計画が必要であることを理解していますが、予算と人員の制約が完全なソリューションの妨げとなっています。 サービス レベル管理は、成果物を定義し、その成果物に結びつくサービスに対して双方向の責任を与えることでリソースの問題を軽減する、実証された手法です。 これは 2 つの方法で実現できます。

  • ユーザとネットワーク組織の間で、キャパシティおよびパフォーマンス管理を含むサービスに対してサービス レベル契約を作成する。 サービスには、レポートと、サービス品質を維持するための推奨事項が含まれます。 ただし、ユーザではサービスと必要なアップグレードのための予算の準備が必要です。

  • ネットワーク組織では、キャパシティおよびパフォーマンス管理のサービスを定義し、そのサービスとアップグレードにケースバイケースでの予算割当てを試みる。

いずれのイベントにおいても、ネットワーク組織はキャパシティ計画およびパフォーマンス管理のサービスを定義することから始める必要があります。それには、現時点でどのようなサービスを提供できるか、また将来的に何を計画するかが含まれます。 完全なサービスには、ネットワーク変更とアプリケーション変更のための what-if 分析、定義されたパフォーマンス変数のベースライニングとトレンディング、定義されたキャパシティおよびパフォーマンス変数の例外管理、およびQoS 管理が含まれます。

ネットワークとアプリケーションの what-if 分析

計画された変更がどのような結果をもたらすかを判断するため、ネットワークとアプリケーションの what-if 分析を行います。 what-if 分析をしなければ、組織は変更に対する成功およびネットワーク全体のアベイラビリティに対して、重大なリスクを負うことになります。 多くの場合、ネットワークの変更によって崩壊的な輻輳が起こり、長時間におよぶ実稼働時のダウン タイムを招く結果となっています。 さらに、驚くべき数のアプリケーション導入が失敗し、他のユーザとアプリケーションへの影響を招いています。 このような失敗は多くのネットワーク組織で続いていますが、これらはわずかなツールといくつかの追加的な計画手順で完全に防止できます。

通常、品質の what-if 分析を行うには、いくつかの新しいプロセスが必要です。 最初の手順は、すべての変更のリスク レベルを確認し、よりリスクの高い変更にはより詳細な what-if 分析を要求することです。 リスク レベルは、すべての変更の提出に必要なフィールドとなる場合があります。 リスク レベルのより高い変更には、その変更に定義された what-if 分析が必要です。 ネットワークの what-if 分析では、ネットワーク変更がネットワーク使用率とネットワークのコントロール プレーン リソース問題に与える影響を特定します。 アプリケーションの what-if 分析では、プロジェクト アプリケーションの成功、帯域幅要件、およびネットワーク リソース問題を特定します。 次の表は、リスク レベルの割り当てと、対応するテスト要件の例です。

リスク レベル 定義 変更計画における推奨事項
1
  • 新しい製品、ソフトウェア、トポロジ、または機能の導入により、多数のユーザ(500 人以上)やビジネス クリティカルなサービスに影響する可能性が高い。
  • 変更には、予想されるネットワーク ダウンタイムを含む。
  • 新しいソリューションをラボで検証する。 ラボ検証には、ドキュメント化されたソリューションのテストと検証、および既存のインフラストラクチャへの影響を示す what-if 分析が含まれる。 ソリューションの試験運用を推奨。 新しいソリューションには、操作サポート マニュアルの完成が必要。
  • Cisco NSA 設計レビューの実施。
  • バックアウト計画の作成。
  • 導入計画の作成。
  • 変更プロセスの作成。
2
  • トラフィックやユーザの大幅な増加、バックボーンの変更、またはルーティングの変更により、多数のユーザ(500 人以上)やビジネス クリティカル サービスに影響する可能性が高い。
  • 変更にはある程度のダウンタイムが必要な場合がある。
  • 既存の環境への影響を特定するための what-if 分析の実施(ラボ環境で実行)。
  • ルーティング変更における機能のテストとレビュー。
  • バックアウト計画の作成。
  • 主なルーティング変更やバックボーン変更の設計レビューの実施。
  • 導入計画の作成。
  • 変更プロセスの作成。
3
  • 変則的な変更により、小規模のユーザまたはビジネス サービスに影響する可能性が中程度ある。
  • 新しい製品、ソフトウェア、トポロジ、機能や新規ユーザの追加、トラフィックの増加、または変則的なトポロジを含む。
  • 変更にはある程度のダウンタイムが必要な場合がある。
  • 新しいソリューションの技術分析の実施(場合によってラボ検証が必要)。
  • 導入計画の作成。
  • 変更プロセスの作成。
4
  • サービスやユーザへの影響の可能性が低い。
  • 建物またはルータ上のサーバ スイッチやハブなど、標準テンプレートのネットワーク モジュールの新規追加を含む。
  • 新しい WAN サイトの起動や、実証されている Access サービスの追加を含む。
  • リスク レベル 3 の変更はすべて、実稼働環境で技術的に実証済み。
  • 変更にはある程度のダウンタイムが必要な場合がある。
  • 導入計画の作成。
  • 変更プロセスの作成。
5
  • ユーザやサービスへの影響がない。
  • ネットワークへの個々のユーザの追加と、パスワード、バナー、SNMP、またはその他の標準的な設定パラメータなど、標準的な設定変更を含む。
  • ダウンタイムがない。
  • 変更プロセスはオプション。

what-if 分析を必要とするエリアを定義したら、次にサービスを定義できます。

ネットワークの what-if 分析は、モデリング ツールや実稼働環境を模したラボを使用して行うことができます。 モデリング ツールは、アプリケーションでのデバイスのリソース問題の理解の程度によって制限されますが、ほとんどのネットワーク変更は新しいデバイスであるため、アプリケーションでは変更の影響が理解されていない可能性があります。 最良の方法は、実稼働ネットワークを表したものをラボ内に構築し、トラフィック ジェネレータを使用して、負荷をかけた状態で必要なソフトウェア、機能、ハードウェア、または構成をテストすることです。 実稼働ネットワークからラボへルート(または他の制御情報)を漏出させることによってもラボ環境は強化されます。 SNMP、ブロードキャスト、マルチキャスト、暗号化、または圧縮トラフィックなど異なったトラフィック タイプで、追加のリソース要件をテストします。 このような様々な手法を駆使して、ルート収束、リンク フラッピング、およびデバイスの再起動など、想定される負荷状況でデバイスのリソース要件を分析します。 リソース使用率の問題には、CPU、メモリ、バックプレーン使用率、バッファ、およびキューイングなど通常のキャパシティ リソースのエリアが含まれます。

新しいアプリケーションでも、アプリケーションの成功と帯域幅要件を判定するための what-if 分析を行う必要があります。 通常この分析は、距離による影響を知るためプロトコル アナライザと WAN 遅延シミュレータを使用してラボ環境で行います。 必要なものは、PC、ハブ、WAN 遅延デバイス、および実稼働ネットワークに接続されたラボ ルータだけです。 テスト ルータに一般的なトラフィック シェーピングやレート制限を行ってトラフィックを抑制することで、ラボで帯域幅のシミュレーションを行うことができます。 ネットワーク管理者は、アプリケーション グループとともに作業することで、LAN と WAN 両方の環境でのアプリケーションの帯域幅要件、ウィンドウ設定の問題、および潜在的なパフォーマンス問題を理解できます。

ビジネス アプリケーションを展開する前には必ず what-if 分析を行います。 what-if 分析を行わないと、アプリケーション グループではネットワークのパフォーマンスの低さが問題となります。 変更管理プロセスを通じて、新規展開のためのアプリケーション用の what-if 分析を要求できれば、展開の失敗を回避し、クライアントサーバとバッチの両方の要件での帯域幅消費量の突然の増加について、より良く理解することができます。

ベースライニングとトレンディング

ベースライニングとトレンディングを行うことで、ネットワーク管理者は、キャパシティの問題が原因でネットワークのダウンタイムやパフォーマンス問題が発生する前に、ネットワークのアップグレードを計画し、完了することができます。 連続した期間でリソース使用率を比較するか、時間経過に伴った情報をデータベースから抽出すれば、計画者は過去 1 時間、1 日、1 週間、 1 ヶ月、および 1 年間の リソース使用率のパラメータを表示できます。 どちらの場合も、毎週、隔週、あるいは毎月、誰かが情報をレビューする必要があります。 ベースライニングとトレンディングにおける問題は、大規模なネットワークの場合、大量に情報をレビューする必要があることです。

この問題は、いくつかの方法で解決できます。

  • 十分なキャパシティと、キャパシティが問題とならないような LAN 環境へのスイッチングを構築します。

  • トレンド情報をグループに分類し、重要な WAN サイトやデータ センターの LAN など、ネットワークのハイアベイラビリティなエリアや重要なエリアに焦点を絞ります。

  • レポート メカニズムを使用して、特定のしきい値を超えるエリアを強調し、特別な注意を払うように設定します。 アベイラビリティの重要なエリアを最初に実装すれば、レビューを必要とする情報の量を大幅に削減できます。

上記のすべての方法を使用しても、情報を定期的にレビューする必要はあります。 ベースライニングとトレンディングは予防的な措置であり、組織に事後対処的なサポートのリソースしかない場合は、個人がレポートを読むことはありません。

多くのネットワーク管理ソリューションは、キャパシティ リソースの変数に関する情報とグラフを提供します。 残念ながら、ほとんどの個人は既存の問題にだけリアクティブ型サポートのためのこれらのツールを使用します; これはベースライニングおよび向く無効にします。 シスコのネットワークにおいてキャパシティのトレンド情報を提供する 2 つの有効なツールは、Concord Network Health 製品と、INS EnterprisePRO 製品です。 多くの場合、ネットワーク組織ではキャパシティ情報の収集に単純なスクリプト言語を実行しています。 次に、スクリプトで収集したリンク使用率、CPU 使用率、および ping パフォーマンスのレポート例をいくつか紹介します。 そのほかトレンディングを行うことが重要なリソース変数には、メモリ、キュー項目数、ブロードキャスト量、バッファ、フレームリレー輻輳通知、およびバックプレーン使用率があります。 リンク使用率および CPU 使用率の情報については、次の表を参照してください。

リンク使用率

リソース アドレス セグメント 平均使用率(%) ピーク時使用率(%)
JTKR01S2 10.2.6.1 128 kbps 66.3 97.6
JYKR01S0 10.2.6.2 128 kbps 66.3 97.8
FMCR18S4/4 10.2.5.1 384 Kbps 51.3 109.7
PACR01S3/1 10.2.5.2 384 Kbps 51.1 98.4

CPU 使用率

リソース ポーリング アドレス 平均使用率(%) ピーク時使用率(%)
FSTR01 10.28.142.1 60.4 80
NERT06 10.170.2.1 47 86
NORR01 10.73.200.1 47 99
RTCR01 10.49.136.1 42 98

リンク使用率

リソース アドレス AvResT (mS) 09-09-98 AvResT (mS) 09-09-98 AvResT (mS) 09-09-98 AvResT (mS) 10-01-98
AADR01 10.190.56.1 469.1 852.4 461.1 873.2
ABNR01 10.190.52.1 486.1 869.2 489.5 880.2
APRR01 10.190.54.1 490.7 883.4 485.2 892.5
ASAR01 10.196.170.1 619.6 912.3 613.5 902.2
ASRR01 10.196.178.1 667.7 976.4 655.5 948.6
ASYR01S         503.4
AZWRT01 10.177.32.1 460.1   444.7  
BEJR01 10.195.18.1 1023.7 1064.6 1184 1021.9

例外管理

例外管理は、キャパシティとパフォーマンスの問題を識別し、解決するための有用な手法です。 その概念は、問題を即座に調査し解決するため、キャパシティとパフォーマンスのしきい値違反の通知を受け取るというものです。 たとえば、ネットワーク管理者はルータ上の CPU 使用率が高いというアラームを受け取る場合があります。 すると、ネットワーク管理者はルータにログインし、CPU がなぜそれほど高い値を示すのかを特定できます。 そして CPU 使用率を削減する修復設定を行ったり、特に問題の原因となるトラフィックがビジネスクリティカルでない場合は、そのトラフィックを阻止するアクセスリストを作成したりできます。

より重要な問題の例外管理は、ルータ上で RMON 設定コマンドを使用したり、Netsys サービス レベル マネージャと SNMP、RMON、または Netflow のデータを組み合わせるなど、より高度なツールを使用することで、簡単に設定できます。 ほとんどのネットワーク管理ツールには、しきい値を設定して違反のアラームを出す機能が備わっています。 例外管理プロセスの重要な側面は、ほぼリアルタイムで問題の通知を行うことです。 そうでなければ、通知を受信したことに誰かが気づく前に問題が消えてしまう可能性があります。 組織に一貫したモニタリング機能がある場合は、これを NOC で行うことができます。 そうでない場合は、ポケットベルでの通知を推奨します。

次の設定例は、常にレビューできるログファイルに、ルータ CPU の上昇および下降しきい値の通知を送るものです。 重要なリンク使用率のしきい値違反や、他の SNMP しきい値に、類似した RMON コマンドを設定できます。

rmon event 1 trap CPUtrap description
  "CPU Util >75%"rmon event 2 trap CPUtrap description
  "CPU Util <75%"rmon event 3 trap CPUtrap description
  "CPU Util >90%"rmon event 4 trap CPUtrap description
  "CPU Util <90%"rmon alarm 75 lsystem.56.0 10 absolute rising-threshold
  75 1 falling-threshold 75 2rmon alarm 90 lsystem.56.0 10 absolute rising-threshold
  90 3 falling-threshold 90 4

QoS 管理

QoS 管理では、ネットワーク内に特定のトラフィック クラスを作成し、監視します。 特定のアプリケーション グループ(トラフィック クラス内に定義されるもの)では、トラフィックはより均一なパフォーマンスを示します。 トラフィック シェーピングのパラメータは、特定のトラフィック クラスに対してトラフィック シェーピングを行い、プライオリティ設定の柔軟性が大幅に増します。 これらの機能には、Committed Access Rate(CAR; 専用アクセス レート)、Weighted Random Early Detection(WRED; 重み付けランダム早期検出)、および Class Based Weighted Fair Queuing(CBWFQ; クラス ベース重み付け均等化キューイング)などが含まれます。 通常、トラフィック クラスは、よりビジネス クリティカルなアプリケーションや音声など特定のアプリケーションの要件に対して、パフォーマンス SLA に基づいて作成されます。 重要でない、またはビジネスに直結しないトラフィックも、プライオリティの高いアプリケーションとサービスに影響しないように制御されます。

トラフィック クラスの作成には、ネットワーク使用率、特定のアプリケーション要件、およびビジネス アプリケーションのプライオリティの基本的な理解が必要です。 アプリケーション要件には、パケット サイズ、タイムアウト問題、ジッタ要件、バースト要件、バッチ要件、および全般的なパフォーマンス問題の知識が含まれます。 この知識によって、ネットワーク管理者は多様な LAN/WAN トポロジにわたって、より一貫したアプリケーション パフォーマンスを提供するトラフィック シェーピングの計画と構成を作成できます。

たとえば、ある組織では 2 つの主要なサイト間に 10 メガビットの ATM 接続があります。 リンクは巨大ファイルの転送によって時おり輻輳を起こし、オンライン取引処理のパフォーマンス低下と、劣悪または使用不可能な音声品質の原因となっています。

この組織では、4 つの異なるトラフィック クラスを設定します。 音声には最も高いプライオリティが与えられており、想定トラフィック量レートを超過したバーストが起こった場合でも、そのプライオリティは維持されます。 重要なアプリケーションのクラスには、次に高いプライオリティが与えられていますが、想定された音声帯域幅要件よりも小さい総リンク サイズを超過するバーストは許可されていません。 このクラスは、バーストした場合ドロップされます。 ファイル転送トラフィックにはさらに低いプライオリティが与えられており、その他のトラフィックはその中間に置かれています。

組織ではここで、このリンクに QoS 管理を実行して、各クラスでどのくらいのトラフィックが流れているかを特定し、各クラス内のパフォーマンスを測定する必要があります。 組織がこれに失敗すると、一部のクラスに枯渇が起こったり、特定のクラスのパフォーマンス SLA が満たされなかったりする場合があります。

QoS 設定の管理は、ツールがないため、現在でも難しい作業です。 1 つの方法は、シスコの Internet Performance Manager(IPM)を使用して、各トラフィック クラスに分類されるリンクに異なったトラフィックを送信することです。 これにより、各クラスのパフォーマンスを監視でき、IPM が問題のエリアを正確に特定するため、トレンディング、リアルタイム分析、およびホップバイホップ分析を提供します。 その他の方法は、インターフェイスの統計に基づいて各トラフィック クラス内のキューイングとドロップされたパケットを調べるといった、より手動的な方法に依然として頼っています。 組織によっては、このデータを SNMP 経由で収集したり、ベースラインとトレンディングのためにデータベースで解析できる場合もあります。 ネットワーク全体に特定のトラフィック タイプを送信することで、特定のサービスやアプリケーションのパフォーマンスを算出するツールも、市場にはいくつかあります。

キャパシティ情報の収集と報告

キャパシティ情報の収集と報告は、キャパシティ管理で推奨される 3 つのエリアに関連付ける必要があります。

  • ネットワーク変更とその変更が環境に与える影響に焦点を置く、what-if 分析

  • ベースライニングとトレンディング

  • 例外管理

上の各エリアでの情報収集計画を作成します。 ネットワークやアプリケーションの what-if 分析では、ネットワーク環境を模して、デバイスのコントロール プレーンやデータ プレーンの潜在的なリソース問題に関連する変更の影響を理解するためのツールが必要です。 ベースライニングとトレンディングでは、現在のリソース使用率を示すデバイスとリンクのスナップショットが必要です。 そして、潜在的なアップグレード要件を知るため、時間の経過に伴ったデータのレビューを行います。 これにより、ネットワーク管理者はキャパシティやパフォーマンスの問題が発生する前にアップグレードを適切に計画できます。 実際に問題が発生した場合は、例外管理でネットワーク管理者に警告を発し、ネットワークを調整したり問題を修正できるようにする必要があります。

このプロセスは、次のステップに分けられます。

  1. 要件の確定。

  2. プロセスの定義。

  3. キャパシティ エリアの定義。

  4. キャパシティ変数の定義。

  5. データの解釈。

要件の確定

キャパシティとパフォーマンスの管理計画を作成するには、必要な情報とその情報の目的を理解する必要があります。 計画を 3 つの必要なエリアに分割します。 それぞれ、what-if 分析、ベースライニング/トレンディング、および例外管理です。 これらの各エリアで、どのリソースとツールが利用可能で何が必要かを調べます。 ツールのテクノロジーと機能は考慮しても、ツールを管理するのに必要な人材と専門知識を考慮しないために、ツールの展開に失敗する組織が多数あります。 プロセスの改善と同様に、必要な人材と専門知識も計画に含めます。 人材に含まれるのは、ネットワーク管理ステーションを管理するシステム管理者、データベース管理を行うデータベース管理者、ツールを使用し監視する訓練を受けた管理者、およびポリシー、しきい値、情報収集の要件を確定するより高いレベルのネットワーク管理者です。

プロセスの定義

ツールを正しく一貫して使用するためのプロセスも必要です。 しきい値違反があった場合にネットワーク管理者が何を行うべきか、ベースライニング、トレンディング、およびネットワークのアップグレードではどのプロセスに従うかを定義するためのプロセス改善が必要な場合もあります。 キャパシティ計画を成功させるための要件とリソースが確定したら、次に手法を検討できます。 多くの組織は、このタイプの機能を INS などのネットワーク サービス組織に委託するか、またはサービスを中核要件と考えて社内で専門知識を構築するかを選択します。

キャパシティ エリアの定義

キャパシティ計画には、キャパシティのエリアの定義も含まれます。 これらは、一般的なキャパシティ計画戦略を共有できるネットワークのエリアです。 たとえば、企業 LAN、WAN のフィールド オフィス、重要な WAN サイト、およびダイヤルイン アクセスです。 異なるエリアを定義することは、いくつかの理由で役立ちます。

  • 異なったエリアには異なるしきい値をもつ可能性がある。 たとえば、LAN の帯域幅は WAN の帯域幅よりもずっと安価なため、使用率のしきい値は低くなります。

  • 異なったエリアには、異なる MIB 変数の監視が必要な場合がある。 たとえば、フレームリレーの FECN および BECN カウンタは、フレームリレーのキャパシティ問題を理解するのに重要です。

  • ネットワークのエリアによっては、アップグレードがより困難で時間がかかる場合がある。 たとえば、国際回線のリードタイムは非常に長く、それに合わせたよりハイレベルな計画が必要な可能性があります。

キャパシティ変数の定義

次の重要なエリアは、変数の監視とアクションを必要とするしきい値の定義です。 キャパシティ変数の定義は、ネットワーク内で使用するデバイスとメディアに大きく依存します。 一般的に、CPU、メモリ、およびリンク使用率などのパラメータは重要です。 ただし、特定のテクノロジーや要件に関しては、他のエリアも重要な場合があります。 これらには、キュー項目数、パフォーマンス、フレームリレー輻輳通知、バックプレーン使用率、バッファ使用率、NetFlow 統計、ブロードキャスト量、および RMON データが含まれます。 成功を確実にするには、長期計画を念頭におきながらも、いくつかの重要なエリアだけから始めます。

データの解釈

収集したデータを理解することも、高品質なサービスを提供する上で重要です。 たとえば、多くの組織はピーク時と平均の使用率のレベルを十分に理解していません。 次の図は、5 分間の SNMP 収集間隔に基づき、キャパシティ パラメータのピークを示したものです(緑で表示)。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/20769-interpretdata.gif

レポートされた値がしきい値(赤で表示)より下であったとしても、収集間隔内にしきい値を超えるピーク(青で表示)が発生する可能性があります。 収集間隔内に、組織ではネットワークのパフォーマンスやキャパシティに影響を与えるピーク値が発生する可能性があるため、このことは重要です。 有用で過剰なオーバーヘッドを起こさない、意味のある収集間隔を選択するよう注意します。

もう 1 つの例は、平均使用率です。 従業員が 8 時から 5 時までしかオフィスにいなくても、平均使用率は 7X24 であり、情報が誤解をまねく恐れがあります。


関連情報


Document ID: 20769