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

高可用性ネットワーキング用 Cisco IOS 管理: ベスト プラクティス ホワイト ペーパー

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


目次


概要

展開し、維持信頼できる Cisco IOS か。 ソフトウェアは更新された Cisco および顧客 重視がノンストップ アベイラビリティを実現するように要求する今日のビジネス 極めて重要なネットワーク 環境の優先順位です。 シスコとしてソフトウェアの品質保証に重点的に取り組む必要がある一方で、ネットワーク設計グループおよびサポート グループでは、Cisco IOS ソフトウェア管理のベスト プラクティスにも重点を置く必要があります。 目標は、より高いアベイラビリティと効率的なソフトウェア管理の実現です。 そのために、ソフトウェア管理のベスト プラクティスの共有、学習、および実装を組み合せた方法を採用しています。

この資料は企業およびサービスプロバイダーの顧客両方向けに改良された ソフトウェア 信頼性、簡素化されたネットワークコンプレキシティおよび増大したネットワークアベイラビリティの促進を助ける Cisco IOS 経営 慣行の有効な操作上フレームワークを提供したものです。 また、このフレームワークによって、ソフトウェア管理のテストや検証における、シスコのリリース工程とシスコ カスタマー ベースのそれぞれの責任範囲および重複部分が明確化されるため、ソフトウェア管理の効率性を改善するためにも役立ちます。

Cisco IOS ベスト プラクティスの概要

次の表に、Cisco IOS ベスト プラクティスの概要を示します。 これらの表は、定義されているベスト プラクティスの管理の概要、最新の Cisco IOS 管理方法を確認するギャップ分析チェックリスト、または Cisco IOS 管理に付随したプロセスを作成するフレームワークとして使用できます。

これらの表では、Cisco IOS 管理における 4 つのライフサイクル コンポーネントを定義しています。 各表は戦略からサマリ識別されたライフサイクル エリアのためのツール開始し。 戦略およびツールの後で概略は定義されたライフサイクル エリアにだけ適用する特定の最良 の 方法です。

計画 - Cisco IOS の管理フレームワークの構築—どんなプロセスが潜在的なイメージをテストし、検証するのに使用されるかアップグレードするか組織がアップグレー ソフトウェアにいつ、どこに判別するのを助けるのに必要とされる Cisco IOS 管理の最初 の フェーズであり。

最良 の 方法 詳細(Outcall Billing Detail)
Cisco IOS の計画における戦略とツール Cisco IOS 管理 計画との開始は現在の推奨事項の正直なアセスメント、達成可能な目標の開発、およびプロジェクト 計画から始まります。
ソフトウェア バージョン トラックの定義 ソフトウェア の 一貫性がどこに維持することができるか識別します。 ソフトウェア トラックはユニークな地理学、プラットフォーム、モジュール、または機能要件によって他のエリアから区別される個有ソフトウェア バージョンのグループ化と定義することができます。
アップグレード サイクルとその定義 アップグレード サイクルの定義は、ソフトウェアおよび変更管理における基本的な品質手順として定義でき、ソフトウェアのアップグレード サイクルの開始時期を判断するために使用されます。
認証 プロセス 認証 プロセス ステップはトラック識別、アップグレード の サイクル 定義、候補 管理、/検証テスト、および少なくとも試験 生産 使用を含む必要があります。

設計- IOSバージョンの選択および検証— Cisco IOSバージョンを選択し、検証するための明示されているプロセスを不成功なアップグレードの試みおよび無計画なソフトの欠陥による予期せぬダウンタイムを短縮するために組織を助けます持っていることは。

最良 の 方法 詳細(Outcall Billing Detail)
Cisco IOS の選択および検証における戦略とツール 新しい Cisco IOS バージョンを選択し、テストし、検証するためのプロセスを定義して下さい。 これには、実稼動ネットワークを模倣したネットワークのテスト ラボも含まれます。
候補 管理 候補 管理は特定のハードウェアおよびイネーブルになった機能セットのためのソフトウェアバージョン要件および潜在的リスクの識別です。
テストと検証 テストと検証は、ソフトウェア管理およびハイ アベイラビリティ ネットワーキングの重要な側面です。 適切なラボ テストを実行すると、生産のダウンタイムが大幅に削減され、ネットワーク サポート担当者のトレーニングに役立ち、ネットワーク実装プロセスの簡素化にも役立ちます。

実装-速く、正常な Cisco IOS 配備—明示されているインプリメンテーション プロセスは組織が新しい Cisco IOS バージョンを展開するように迅速かつ正常にします。

最良 の 方法 詳細(Outcall Billing Detail)
Cisco IOS の配備における戦略とツール Cisco IOS の配備における基本的な戦略は、アップグレード ツールと明確な実装プロセスを使用して、試験プロセスおよび迅速な配備を通して、最終的な認証を行うことです。
試験プロセス より安全に最小に するためにキャプチャへの潜在的な公開をどの残りの生産性 に 影響する 問題でも、ソフトウェア パイロット推奨され。 個々の試験計画ごとに、試験の選択、試験の期間、および測定方法を検討する必要があります。
実装 パイロット フェーズの完了の後で、Cisco IOS 実施段階は開始される必要があります。 実装フェーズには、スロースタート、最終認証、アップグレードの準備、アップグレードの自動化、および最終検証などの、ソフトウェア アップグレードの成功および効率性を確認するためのいくつかの手順が含まれます。

オペレーション-高可用性の Cisco IOS 実装管理します— Cisco IOS オペレーションにおける最良 の 方法はソフトウェア バージョン制御、Cisco IOS Syslog管理、問題管理、設定標準化およびアベイラビリティ管理が含まれています。

最良 の 方法 詳細(Outcall Billing Detail)
Cisco IOS の運用における戦略とツール Cisco IOS の運用における最初の戦略は、環境をできるだけ簡素化し、設定と Cisco IOS のバージョンのばらつきをなくすことです。 2 番目の戦略は、ネットワークの不具合を識別し、迅速に解決する能力です。
ソフトウェア バージョン管理 ソフトウェア バージョン管理は、標準化されたソフトウェア バージョンだけを実装して、ネットワークを監視するプロセスです。このプロセスでは、ソフトウェアを検証し、バージョンに準拠しないソフトウェアを変更する場合もあります。
予防的な Syslog 管理 Syslog の収集、監視、および分析は、その他の手段では識別が困難または不可能な、Cisco IOS に特有のより多くのネットワーク問題を解決するために推奨される、障害管理プロセスです。
問題管理 問題識別、情報収集およびよく分析されたソリューション パスを定義する詳しい問題管理プロセス。 このデータは、根本的な原因を判断するために使用できます。
設定標準化 コンフィギュレーション標準は企業全体のグローバルコンフィギュレーションの整合性に終って同様なデバイスおよびサービスを渡る標準グローバル 設定 パラメータを作成し、維持することの推奨事項を表します。
アベイラビリティ管理 アベイラビリティ管理は質の向上 メトリックとしてネットワークアベイラビリティを使用して質の向上のプロセスです。

ソフトウェア ライフサイクル管理プロセスの概要

Cisco IOSソフトウェア ライフサイクル管理は計画、設計、実装および高信頼 ソフトウェア 実装および高可用性のネットワーキングのために推奨される操作上プロセスのセットと定義されます。 Cisco IOS ソフトウェアのライフサイクル管理には、ネットワーク内の Cisco IOS バージョンを選択、検証、および保守するプロセスが含まれます。

Cisco IOS ソフトウェアのライフサイクル管理の目標は、実稼動下でソフトウェアの不具合またはソフトウェア関連の変更やアップグレードの障害が確認される可能性を低減し、ネットワーク アベイラビリティを高めることです。 この文書内で定義するベスト プラクティスは、シスコの多くのお客様および Cisco アドバンスト サービス チームの実際の経験に基づいて、同様の不具合および変更障害を減らすために公開されてきました。 ソフトウェア ライフサイクル管理を導入すると、初期費用が増加する可能性があります。ただし、停止回数がより少なく、配備とサポートのメカニズムがより簡素化されているために、全体的な所有コストは減少します。

計画 - Cisco IOS の管理フレームワークの構築

計画は、Cisco IOS の管理における最初のフェーズであり、ソフトウェア アップグレードの時期、アップグレードする場所、およびイメージのテストと検証に使用するプロセスを判断するために必要とされます。

最良 の 方法は内部 ソフトウェア 認証 プロセスソフトウェア バージョン トラック定義がアップグレード の サイクルおよび定義および作成含まれています。

Cisco IOS の計画における戦略とツール

現在の推奨事項の正直なアセスメント、達成可能な目標の開発、およびプロジェクト 計画から Cisco IOS 管理 計画を始めて下さい。 この文書内のベスト プラクティスとお客様の組織内のプロセスを比較して、自己評価を実行する必要があります。 基本的な質問は次を含む必要があります:

  • 組織にそれはソフトウェア テスト/検証が含まれているソフトウェア 認証 プロセスがありますか。

  • 組織にネットワークで動作する一定限度の Cisco IOSバージョンとの Cisco IOSソフトウェア規格がありますか。

  • 判別する問題が Cisco IOSソフトウェアを組織にいつアップグレードするかありますか。

  • 組織に新しい Cisco IOS ソフトウェアを両方効率的かつ効果的に展開する問題がありますか。

  • 組織に配備の後で不稼動時間のコストに大きく影響する Cisco IOS 安定性の問題がありますか。

アセスメントの後で、組織は Cisco IOSソフトウェア 管理のための目標を定義し始める必要があります。 技術、実装、および運用のそれぞれのアーキテクチャを計画するグループから、職能上の枠を越えてマネージャまたはリーダーのどちらか(あるいはその両方)を集めて、Cisco IOS の目標およびプロセス改善プロジェクトの定義を開始します。 最初の会議の目的は、全体的な目標、役割、および責任を決定し、アクション項目を割り当て、プロジェクトの初期スケジュールを定義することです。 また、ソフトウェア 管理 の 利点を判別するために重要な成功の要因およびメトリックを定義して下さい。 可能性のあるメトリックには、次のようなものがあります。

  • ソフトウェアの問題に起因するアベイラビリティ

  • ソフトウェアのアップグレードにかかるコスト

  • アップグレードに必要な時間

  • 実働環境で稼動しているソフトウェア バージョンの数

  • ソフトウェアのアップグレード変更における成功と失敗の比率

計画する全面的な Cisco IOS 管理フレームワークに加えていくつかの組織はまた毎月または 3 ケ月ごとに発生するために進行中のソフトウェア 企画 会議を定義します。 これらの会議の目的は、現状のソフトウェア配備を確認し、任意の新規ソフトウェア要件の計画を開始することです。 計画には、現在のソフトウェア管理プロセスの再確認や変更が含まれる場合と、ソフトウェア管理の別のフェーズにおける役割および責任の定義だけが含まれる場合があります。

計画フェーズで使用するツールは、ソフトウェア インベントリ管理ツールだけで構成されています。 この領域で使用する主要なツールは、CiscoWorks 2000 Resource Manager Essentials(RME)Inventory Manager です。 CiscoWorks2000 RME Inventory Manager を使用すると、Web ベースのレポート ツールによって、Cisco ルータおよびスイッチのバージョン管理が大幅に簡素化されます。この Web ベースのレポート ツールでは、ソフトウェア バージョン、デバイスのプラットフォーム、メモリ サイズ、およびデバイス名に基づいて、Cisco IOS のデバイスが報告およびソートされます。

ソフトウェア バージョン トラックの定義

Cisco IOS ソフトウェア管理計画の最初のベスト プラクティスでは、ソフトウェアの一貫性をどこで維持できるかを特定します。 ソフトウェア トラックはユニークな地理学、プラットフォーム、モジュール、または機能要件によって他のエリアから区別される個有ソフトウェア バージョンのグループ化と定義されます。 理想的なのは、1 つのネットワークで 1 つのソフトウェア バージョンだけが実行されている状態です。 その場合、ソフトウェア管理に関連するコストが大幅に削減され、一貫性があり、簡単に管理できる環境が実現できます。 ただし、現実はほとんどの組織が特定地域内の機能、プラットフォーム、移行およびアベイラビリティ問題が理由でネットワークの複数のバージョンを実行する必要があることです。 多くの場合、同じバージョンは異質プラットフォームで動作しません。 それ以外の場合、組織は必要条件をすべてサポートするために 1 つのバージョンを待つ場合がありません。 テストと検証、認証、およびアップグレード要件を検討し、そのネットワークで使用するソフトウェア トラック数をできるだけ減らすことが目標です。 多くの場合、組織は/検証、認証およびアップグレード コスト テストを全面的に下げるわずかにより多くのトラックがあるかもしれません。

各ソフトウェア トラックを区別する最初の基準は、プラットフォームのサポートです。 通常、LAN スイッチ、WAN スイッチ、コア ルータ、およびエッジ ルータには、それぞれ個別のソフトウェア トラックがあります。 また、特にこの要件がネットワーク内でローカライズ可能な場合には、data-link switching(DLSw; データリンク スイッチング)、Quality of Service(QoS)、または IP テレフォニーなどの特定の機能またはサービスのために、他のソフトウェア トラックが必要になる場合もあります。

もう一つの基準は信頼性です。 多くの組織はエッジの方のより新しい進んだ機能実行することを、かハードウェアサポートを、提供している間ネットワークコアおよびデータセンタの方のほとんどの高信頼 ソフトウェアを試みます。 その一方で、多くの場合、コアやデータ センターは、スケーラビリティや帯域幅の機能を最も必要とする環境です。 異なる WAN ルータ プラットフォームを持つ大規模なディストリビューション サイトなど、特定のプラットフォーム用に他のトラックが必要になる場合もあります。 次の表は、大規模な企業組織用のソフトウェア トラック定義の例です。

Track エリア ハードウェアプラットフォーム 機能 Cisco IOSバージョン 認証ステータス
1 LAN コア切り替え 6500 QoS 12.1E(A8) テスト
2 LANアクセス スイッチ 2924XL 2948XL Unidirectional Link Detection Protocol(UDLD; 単方向リンク検出プロトコル)、Spanning Tree Protocol(STP; スパニング ツリー プロトコル) 12.0(5.2)XU 証明された 3/1/01
3 LAN ディストリビューション/アクセス 5500 6509 Supervisor 3 5.4(4) 証明された 7/1/01
4 ディストリビューションスイッチ ルートスイッチモジュール(RSM) RSM Open Shortest Path First(OSPF)ルーティング 12.0(11) 証明された 3/4/02
5 WAN ヘッドエンド ディストリビューション 7505 7507 7204 7206 OSPF フレーム リレー 12.0(11) 証明された 11/1/01
6 WAN アクセス 2600 OSPF フレーム リレー 12.1(8) 証明された 6/1/01
7 IBM 接続 3600 Synchronous Data Link Control(SDLC; 同期データリンク制御)ヘッドエンド 11.3(8)T1 証明された 11/1/00

トラックの割り当ても、時間の経過とともに変化します。 多くの場合、機能かハードウェアサポートはより多くのメインライン ソフトウェア バージョンに統合かもしれ同時に移行するように異なるトラックが結局します。 トラックの定義が終了すると、定義されている他のプロセスを使用して、新しいバージョンの一貫性や検証の段階へと進むことができます。 トラック定義もまた、継続した取り組みです。 いつでも新しい 機能は、サービス、ハードウェア、またはモジュール 要件は識別されます、新しいトラック考察する必要があります。

トラックのプロセスを開始する際には、トラック要件を新たに定義することから始めるか、既存のネットワークに対する安定化のプロジェクトから始める必要があります。 組織はまた現在のトラック定義を可能にすることができる既存のソフトウェア バージョンとのいくつかの確認可能な共通性があるかもしれません。 ほとんどの場合顧客は十分なネットワーク 安定性がある場合、確認されたバージョンへの急速な移行が必要となりません。 通常は、ネットワーク アーキテクチャ グループ、または技術グループが、トラック定義プロセスの責任を負います。 場合によっては、1 人のユーザーはトラック定義を担当するかもしれません。 それ以外の場合、プロジェクト先行は個々 の プロジェクトに基づいてソフトウェア開発必要条件および新しいトラック定義に責任があります。 またです新しいトラックが必要となったかどうか、または確認するためにトラック定義を毎季に検討することが得策古いトラックが強化を必要とするか、またはアップグレードすれば。

厳密なバージョン管理によってソフトウェア トラックの確認および保守を行っている組織は、ネットワーク内で稼動するソフトウェア バージョン数を削減することに成功しています。 その結果、一般的に、ソフトウェアの安定性が向上し、ネットワークの全体的な信頼性が実現します。

アップグレード サイクルとその定義

アップグレード サイクルの定義は、ソフトウェアおよび変更管理における基本的な品質手順として定義され、ソフトウェアのアップグレード サイクルの開始時期を判断するために使用されます。 アップグレード サイクル定義を使用すると、ソフトウェアのアップグレード サイクルを適切に計画し、必要なリソースを割り当てることができます。 アップグレード サイクル定義を使用しないと、多くの場合、現在の安定したバージョンに対して機能要件が発生することによって、ソフトウェアの信頼性に関する問題が増加します。 別の公開は本番使用方法が必要となる前に厳密に新しい バージョンをテストし、検証する機会を失う組織である可能性があります。

この推奨事項の重要な側面はソフトウェア プランニングプロセスが開始する必要があるかどの程度までと識別して。 これはソフトウェア側の問題の一流原因が適当な 注意なしで本番の機能、サービス、またはソフトウェア 管理 の 考慮事項無しでハードウェア互換性をつけている、または新しい Cisco IOS へバージョンをアップグレードすることがですというファクト原因。 別の問題はアップグレードしていません。 正常なソフトウェア の サイクルおよび必要条件の無視によって、多くの顧客はいくつかの異なるメジャーリリースを通してソフトウェアをアップグレードする難しい仕事に直面します。 このような問題の原因は、イメージ サイズ、デフォルト動作の変更、Command Level Interpreter(CLI; コマンド レベル インタープリタ)の変更、およびプロトコルの変更です。

Cisco はこの用紙で定義されたように始められる最良 の 方法に基づいて新しい主要な機能が、サービス、またはハードウェアサポートが必要となる時はいつでも明示されているアップグレード の サイクルを、推奨します。 正確なテスト要件と検証要件を判断するために、認証およびテストと検証の程度を(リスクに基づいて)分析する必要があります。 地理的な場所、論理的な場所(コア、ディストリビューション、またはアクセス レイヤ)、または影響されることが予想される人数やお客様の数によって、リスク分析を実行できます。 主要な機能かハードウェア互換性が現在のバージョンで含まれている場合、いくつかの合理化された アップグレード サイクル プロセスはまた開始する必要があります。 機能が比較的マイナーである場合、リスクを考慮し、次にどのプロセスが開始する必要があるか決定して下さい。 さらに、ソフトウェアは 2 年またはより少しで組織が比較的新しくとどまること、そしてアップグレード プロセスが余りに扱いにくくないことの確認を助けるためにアップグレードする必要があります。

顧客はまたバグ修正が End of Life (EoL)ステータスを渡した一連 の ソフトウェアに行われないというファクトを考慮する必要があります。 多くの環境では、テストと検証のプロセスをほとんどまたはまったく行わずに新しく機能を追加し、その結果ダウンタイムが発生しても、容認されたり、場合によっては歓迎されたりしています。そのため、ビジネス要件に関しても考慮する必要があります。 顧客はまた時テスト要件を考えるとより新しいデータと Ciscoリリース オペレーションで収集されたと考える必要があります。 バグおよび根本的な原因の分析は大部分の不具合 根本的な原因が影響を与えられたソフトウェア エリアの内でコードする開発者の結果だったことを示しました。 つまり、特定の機能またはモジュールをネットワーク内の既存リリースに追加する場合、その機能またはモジュールに関連した不具合が発生する可能性はありますが、新しい機能、ハードウェア、またはモジュールが他の領域に影響を与える可能性は非常に低いということです。 このデータに従えば、既存のリリースでサポートされている新しい機能またはモジュールを追加する場合、新しいサービスまたは機能だけを他の有効なサービスと組み合せてテストすることで、テスト要件を低くすることが可能になります。 ネットワーク内でいくつかの深刻な不具合が検出されたためにソフトウェアをアップグレードする場合にも、このデータを検討する必要があります。

次の表に、ハイ アベイラビリティを実現している主な企業組織における推奨アップグレード要件を示します。

ソフトウェア管理におけるトリガ ソフトウェアのライフサイクル要件
新しいネットワークサービス。 たとえば、新しい ATMバックボーンか新しい VPN サービス。 新しい 機能(他と共にイネーブルになったサービス)テスト、何作業 分析 コラプスト トポロジ テストを含むソフトウェアライフサイクル 検証をおよびアプリケ− ションプロファイル テスト完了して下さい。
新しいネットワーク機能はソフトウェア リリースでサポートされません。 例は QoS およびマルチプロトコル ラベル スイッチング(MPLS)が含まれています。 他と共に、テストする新しい 機能を含むソフトウェアライフサイクル 検証を有効に された サービス、コラプスト トポロジ テスト、何作業 分析およびアプリケ− ションプロファイル テスト完了して下さい。
新しい主要な機能かハードウエアモジュール 現在のバージョンのその存在。 たとえば、GigE 新しいモジュール、マルチキャスト サポート、または DLSW を追加します。 候補管理プロセス。 リリース要件に基づいた、完全な検証。 または、候補管理によって現在のリリースが使用可能だと確認された場合には、限定的なテストと検証。
マイナーな機能付加。 たとえば、アクセスコントロールのための TACACS デバイス。 候補 管理と機能のリスクに基づいて考えて下さい。 リスクに基づく新しい 機能をテストするか、または実践する Consider。
2 年間ソフトウェアが実稼動している場合、または四半期ごとのソフトウェアの確認。 現在の支えられるリリースを識別する完全なライフサイクル管理に関する候補 管理およびビジネス の 意志決定。

緊急 の アップグレード

場合によっては、組織は極めて重大なバグによる必要アップグレー ソフトウェアに直面します。 このような場合、緊急アップグレードの方法論が用意されていないと、問題の発生につながる可能性もあります。 ソフトウェア アップグレードが管理されておらず、ライフサイクル管理を行わずにソフトウェアをアップグレードしてしまうような場合から、ネットワーク デバイスがクラッシュし続けているにもかかわらず、候補となっているリリースの認証とテストが完了してないためにアップグレードが行われない状況まで、ソフトウェアに関する問題は多岐に渡ります。 Cisco は限定的なテストおよびパイロットがネットワークのより少ないビジネス 重要なエリアで実行されたこれらの状況のための緊急 の アップグレード プロセスを推奨します。

破局的なエラーが明白な回避策無しで発生すればおよび問題が関連するソフトの欠陥なら Cisco は Ciscoサポートが十分にかどうか問題を隔離し、確認するために実行されたまたはいつ修正が利用できることを推奨します。 修正が使用可能な場合には、限られたダウンタイム内で問題を修正できるかどうかを迅速に判断するために、緊急アップグレード サイクルの適用をお勧めします。 ほとんどの場合、組織はコードのサポート対象バージョンを実行して、問題修正はソフトウェアの既存の暫定バージョンで利用できます。

潜在的な緊急アップグレードを、お客様の組織で準備することもできます。 準備には、サポートされている Cisco IOS リリースへの移行と、認証されているバージョンと同じ Cisco IOS トレインに含まれる、候補を差し替えるためのバージョンの特定または開発が含まれます。 ソフトウェアがサポートされているということは重要です。それは、シスコの開発が、そのソフトウェア トレインへの不具合修正を継続していることを意味するためです。 ネットワークの支援ソフトウェアの維持によって、組織はより詳しなおよび安定コード ベースによる検証時間を減らします。 通常、候補が差し替えられるのは、同じ Cisco IOS トレインに含まれる、機能やハードウェア サポートが追加されていない新しい暫定ソフトウェア イメージです。 候補置換 戦略は組織が特定の一連 の ソフトウェアの早めに採用する人フェーズにある場合特に重要です。

認証 プロセス

認証 プロセスは検証されたソフトウェアが組織の実稼働環境で一貫して展開されるようにするのを助けます。 認証 プロセス ステップはトラック識別、アップグレード の サイクル 定義、候補 管理、/検証テスト、および試験 生産 使用を含む必要があります。 しかし簡単な認証 プロセスはまだ一貫したソフトウェアバージョンが識別されたトラックの内で展開されるようにするのを助けます。

認証プロセスを開始するには、アーキテクチャ、技術または配備、および運用の各グループから、認証プロセスの設計管理を行う担当者を集めます。 このグループはまず、認証プロセスの継続的な成功を実現するために、ビジネス目標およびリソースの能力を検討する必要があります。 次に、トラック管理、ライフ・サイクル アップグレードの定義、/検証テスト、およびパイロットを含む認証 プロセスの主要な手順に対する個人またはグループの全面的な責任を割り当てて下さい。 これらのエリアのそれぞれは組織の内で定義され、承認され、形式的に伝える必要があります。

また認証 プロセスの毎フェーズに品質または承認のためのガイドラインを含んで下さい。 これは、品質ゲート プロセスと呼ばれることがあります。プロセスが次の手順に進む前に、特定の品質基準を満たす必要があるためです。 このプロセスは、認証プロセスが効果的であり、リソースを割り当てる価値があること確認するために役立ちます。 一般に問題が 1 エリアの品質とあるとき、プロセスは努力を 1 ステップ押し戻します。

ソフトウェアの品質または予想外の動作により、候補であるソフトウェアが、定義されている認証基準を満たさない場合があります。 環境に影響を与える問題が発見された場合には、今後の暫定リリースを認証するための、より簡素化されたプロセスを用意する必要があります。 これは、変更された内容や解決された不具合を組織が理解できる場合には、リソース要件の軽減に役立ち、一般的に効果があります。 それは最初の候補における問題に直面し、より遅い暫時 Cisco IOS リリースを証明することは組織にしては珍しくないです。 また、問題があったために限定的な認証を行うか注意事項を発行しておいて、その後、新しい暫定リリースが検証された際に、完全に認証されたリリースにアップグレードする場合もあります。 次のフローチャートは、基本的な認証プロセスであり、品質ゲート(各ブロックに続く確認)が含まれています。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-1.gif

設計- Cisco IOSバージョンの選択および検証

Cisco IOSバージョンを選択し、検証するための明示されている方法論を不成功なアップグレードの試みおよび無計画なソフトの欠陥による予期せぬダウンタイムを短縮するために組織を助けます持っていることは。

設計フェーズには、候補管理およびテストと検証が含まれます。 候補 管理は定義されたソフトウェア トラックのための特定のバージョンを確認するのに使用されるプロセスです。 テストと検証は、認証プロセスの一部であり、それらのソフトウェア バージョンが、必要なトラック内で正常に動作することを確認します。 テストと検証は、コラプスト トポロジのラボ環境、および実稼働環境に類似した設定のラボ環境で実行する必要があります。

Cisco IOS の選択および検証における戦略とツール

各組織は Cisco IOSバージョンを選択するためのプロセスから開始するネットワークのために標準 Cisco IOSバージョンを選択し、検証するためのプロセスがあるはずです。 アーキテクチャ、エンジニアリングおよびオペレーションからのクロス機能チームは候補管理プロセスを定義し、文書化する必要があります。 承認されたプロセスは、適切な実行グループに引き渡す必要があります。 識別されると同時に候補情報とアップデートすることができる標準候補 管理 テンプレートが作成されることがまた推奨されます。

すべての組織が容易に実稼働環境をまねることができる洗練されたラボ 環境がありません。 組織によっては、ビジネスに大きな影響を与えずに、ネットワーク内で新しいバージョンを試験するための費用や能力が不足しているために、ラボ テストを行っていません。 ただし、高可用性の組織は推奨されますラボを実稼働 ネットワークを構築しまねる、新しい Cisco IOS バージョンのための高いテスト カバレッジを確認するためにテストを/検証プロセス開発するように。 組織は約ラボを構築するために 6 か月を認める必要があります。 この時間の間に特定のテスト 計画およびプロセスを作成するためにラボが完全な利点に使用されるようにする、組織ははたらく必要があります。 Cisco IOS に関しては、これは各必須 ソフトウェア トラックのための特定の Cisco IOS テスト計画の作成を意味します。 新製品やソフトウェアの導入を目的としたラボはあまり使用されていないため、これらのプロセスは、より大規模な組織で重要になります。

次のセクションでは、Cisco IOS の選択および検証に使用する、候補管理のツール、およびテストと検証のツールについて簡単に説明します。

候補 管理ツール

注: 次に示すツールの多くを使用するには、登録ユーザであり、ログインしている必要があります。

  • リリース ノート—リリースのハードウェア、モジュールおよび機能サポートに関する情報を提供します。 採用する可能性のあるリリースに、必要なハードウェアとソフトウェアのサポートがすべて存在することを確認したり、デフォルト動作の違いやアップグレード要件などの移行に関する問題を理解するために、候補管理の作業中にリリース ノートを確認する必要があります。

テストと検証のツール

テストと検証のツールを使用して、新しいハードウェア、ソフトウェア、およびアプリケーションなどのネットワーク ソリューションをテストおよび検証します。

  • トラフィックジェネレータ—特定のプロトコルを利用するあらゆる特定のリンクを渡る比率を模倣するのに使用されるマルチプロトコル トラフィック ストリームおよび未加工パケットレートを生成して下さい。 ユーザは、送信元、宛先 MAC、およびソケット番号を指定できます。これらの値は、指定した手順で増加するか、スタティック(固定)、またはランダムに増加するように設定できます。 トラフィック ジェネレータでは、次のプロトコルのパケットが生成できます。

    • IP

    • Internetwork Packet Exchange(IPX)

    • DECnet

    • Apple

    • Xerox Network Systems(XNS)

    • Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)

    • インターネット グループ管理プロトコル(IGMP)

    • コネクションレス型ネットワーク サービス (CLNS)

    • User Datagram Protocol(UDP; ユーザ データグラム プロトコル)

    • Virtual Integrated Network Service(VINES)

    • データ・リンク パケット

    ツールは Agilent および Spirent 通信leavingcisco.com から利用できますleavingcisco.com

  • パケットカウンタ/キャプチャ/デコーダ(スニファー) —顧客を選択式にパケット パケットおよびデータ・リンク層をキャプチャ し、まったくデコードすることを許可します。 このツールには、ユーザがフィルタを指定できる機能が用意されているため、指定したプロトコルのデータだけをキャプチャすることができます。 フィルターは特定IPアドレス、ポート番号または MAC アドレスと一致するパケットのキャプチャを規定 するために割り当てをユーザ促進します。 ツールは、Sniffer Technologies から入手可能です。leavingcisco.com

  • ネットワーク シミュレーター/エミュレーター—顧客を実稼働 ネットワーク必要条件に基づいて特定のルータのルーティング テーブルを、読み込むことを許可します。 IP の Routing Information Protocol(RIP; ルーティング情報プロトコル)、OSPF、Intermediate System-to-Intermediate System(IS-IS)、Interior Gateway Routing Protocol(IGRP)、Enhanced IGRP(EIGRP)、および Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)のルータの生成がサポートされます。 ツールは PacketStorm 通信および Spirent 通信から利用できます。

  • セッション エミュレーター—スライディング ウインドウ マルチプロトコル トラフィック ストリームを生成し、受信側デバイスの方のテスト ネットワークを渡るマルチプロトコル トラフィック ストリームを送信 することができてであって下さい。 受信デバイスは、送信元に向けて、パケットをエコーバックします。 送信されたパケット、受信されたパケット、シーケンス違反のパケット、およびエラー パケットの数が、送信元デバイスで検証されます。 このツールでは Transmission Control Protocol(TCP; 伝送制御プロトコル)のウィンドウ パラメータを定義する柔軟性も提供されるため、クライアント/サーバ間のトラフィック セッションが、ラボ ネットワーク内で厳密に模倣できます。 ツールは、Empirix から入手可能です。leavingcisco.com

  • 大規模 ネットワーク エミュレーター—より大きい環境のスケーラビリティのテストで助けて下さい。 これらのツールでは、より厳密に実稼働環境を模倣するために、管理タイプのトラフィックを作成し、ラボ トポロジに容易に取り込むことができます。 機能はルート注入器、プロトコル相手およびレイヤ2 プロトコルが相手含まれています。 ツールは Agilent および Spirent 通信leavingcisco.com から利用できますleavingcisco.com

  • WAN シミュレーター—帯域幅および遅延が可能性としては問題であるエンタープライズ アプリケーション トラフィックをテストするための理想。 これらのツールでは、遅延および帯域幅の予想されるアプリケーションをローカルでテストし、WAN 上でアプリケーションがどう機能するかを確認できます。 多くの場合、これらのツールは、企業組織内でのアプリケーション開発およびアプリケーション プロファイルのテストタイプとして使用されます。 Spirent 通信の Adtech、部分leavingcisco.com および Shunra はleavingcisco.com WAN シミュレーション ツールを提供します。

候補 管理

候補 管理は特定のハードウェアおよびイネーブルになった機能セットのためのソフトウェアバージョン要件および潜在的リスクの識別のプロセスです。 組織がきちんとリリースをことを実践する前にソフトウェア要件、リリース ノート、ソフトの欠陥および潜在的リスクを研究する 4 から 8 時間を過ごすことを推奨します。 候補管理の基本的な概要は、次のとおりです。

  • Cisco Connection Online (CCO)ツールでソフトウェア候補を識別して下さい。

  • ソフトウェアの完成度についてのリスク分析、新機能、またはコード サポート。

  • ライフ・サイクル全体の既知のソフトウェアバグ、問題および必要条件を識別し、トラッキングして下さい。

  • 選択したイメージのデフォルトの設定動作を確認して下さい。

  • maintain キャンセルし、潜在的な候補変更のための候補をロールフォワード処理します。

  • Bug Scrub。

  • Cisco 高度 な サービス サービス支援。

ソフトウェア候補を識別することは Cisco 本番および一連 の ソフトウェアの増加する数とより複雑になりました。 CCO に今 Cisco IOS Upgrade Planner、ソフトウェア 検索ツール、ソフトウェア ハードウェア 互換性 マトリックスおよび潜在的なリリース候補を識別するために組織を助けることができる Product Upgrade Tool を含む複数のツールがあります。 これらのツールは http://www.cisco.com/cisco/software/navigator.html で見つけることができます。

次に、潜在的な候補 ソフトウェアのリスクを分析して下さい。 これはソフトウェアがリリース候補の潜在的リスクと成熟度曲線および配備のための必要条件を重量を量ることに現在常駐する知識のプロセスです。 たとえば、組織が重要な高可用性の環境に Early Deployment (ED) ソフトウェアを入れたければ正常な認証のための関連するリスクおよびリソース要求は考慮する必要があります。 組織は少なくとも成功を確認するために高いリスク状況のためのソフトウェア 管理 の リソースを追加する必要があります。 逆に、組織のニーズを満たす General Deployment(GD; 一般導入)バージョンが利用できる場合には、必要なソフトウェア管理リソースは少なくなります。

リリース候補と潜在的なリスクを特定した後は、認証を妨げる可能性のある致命的な不具合が存在しているかどうかを判断するために、バグスクラブを実行します。 Cisco の不具合監視、Bug Navigator および不具合 監視エージェントは潜在的な問題を明らかにするのを助けることができ、ソフトウェアライフサイクル全体潜在的なセキュリティまたは問題問題を識別するのに使用する必要があります。

新しいソフトウェア候補はまた潜在的なデフォルトの設定動作のために検討する必要があります。 デフォルトの設定動作の確認は、新しいソフトウェア イメージのリリース ノートを確認し、指定したプラットフォーム上にロードされたイメージとの設定の違いを確認することによって行えます。 候補 管理はまた選択されたバージョンがプロセスのある時点で認証条件を満たさない場合キャンセルしますバージョンか go-to バージョン 識別をの含むことができます。 規定 されたトラックのための機能に関するバグの視聴によって組織は認証のための潜在的な候補を維持できます。

Cisco 高度 な サービスはまた候補 管理のための優秀なツールです。 このグループを通して、さまざまな垂直市場環境における、数多くの業界エキスパート達による開発プロセスやコラボレーションをより深く理解することができます。 通常、Cisco サポートでは、優れたバグスクラブや候補管理の方法を提供しています。これは、専門家のレベルが高く、さまざまな組織で稼動しているソフトウェア バージョンに対する知識が豊富であるためです。

テストと検証

テストと検証は、管理のベスト プラクティスおよびハイ アベイラビリティ ネットワーキングの全体における重要な側面です。 適切なラボ テストを実行すると、生産のダウンタイムが大幅に削減され、ネットワーク サポート担当者のトレーニングに役立ち、ネットワーク実装プロセスの簡素化にも役立ちます。 ただし、効果的にテストを行うためには、適切なラボ環境を構築して維持し、正しいテストの実行に必要なリソースを確保し、推奨されるテスト方法(測定データの収集も含む)を使用するために、それぞれに必要なリソースを割り当てる必要があります。 これらのリソースが割り当てられていない場合、テストと検証のプロセスは、期待通りの結果にならない可能性があります。

ほとんどの企業組織に推奨されるテスト ラボ 環境がありません。 従って、多くの組織はソリューションを不正確に展開しましたり、ネットワーク 変更 の 障害を、または直面されてラボ 環境で接続されていないできたソフトウェア側の問題に経験しました。 いくつかの環境では、これは不稼動時間のコストが洗練されたラボ 環境のコストを相殺しないので、受諾可能です。 多くの組織ではしかし、ダウンタイムは容認することができません。 そのような場合には、実稼動ネットワークの品質を改善するために、推奨されるテスト ラボ、テスト タイプ、およびテスト方法論の開発を強くお勧めします。

テスト ラボとその環境

ラボは、机、作業台、テスト装置、および機器キャビネットや棚を置くための十分な空間を持つ、隔離された場所である必要があります。 ほとんどの大きい組織は実稼働環境をまねる機器の 4 つから 10 のラックの間で必要とします。 テストを行っている環境を維持するために、物理的なセキュリティを設置することをお勧めします。 物理的なセキュリティを設置すると、ハードウェアの借り入れ、トレーニング、またはリハーサルの実施など、そのラボにおける他の優先事項によってラボ テストが中断されることが回避できます。 論理的なセキュリティはまた偽ルーティングがラボの終了から実稼働 ネットワークか望ましくないトラフィックを入力することを防ぐために推奨されます。 論理的なセキュリティは、ルーティング フィルタ、およびラボ ゲートウェイ ルータ上の拡張アクセス リストによって実現できます。 実稼働 ネットワークへの接続は実稼働環境からのラボ ネットワークにソフトウェアダウンロードおよびアクセスのために有用です。

すべてのテスト計画において、ラボ トポロジが実稼動環境を模倣できる必要があります。 ハードウェア、ネットワーク トポロジ、および機能設定を再現することをお勧めします。 当然、実際のトポロジーを再生することはほぼ不可能ですが、することができる何が本番デバイス間のネットワーク階層および相互対話を再生することです。 特に、複数デバイス間におけるプロトコルや機能のインタラクションは重要です。 テスト トポロジによっては、ソフトウェア テスト要件によって異なるものもあります。 たとえば、WAN エッジで使用する Cisco IOS のテストでは、LAN タイプのデバイスやテストは必要なく、WAN エッジ ルータと WAN ディストリビューション ルータだけが必要になります。 実稼動環境を複製はせずに、ソフトウェアの機能を模倣するのが重要な点です。 場合によっては、ツールがプロトコル 隣接カウントおよびルーティング テーブルのような大規模 な 動作をまねるのに使用することができます。

いくつかのテスト タイプでは、実稼働環境の模倣やテスト データの収集能力を改善するためにもツールが使用されます。 実稼動の模倣に役立つツールには、トラフィック コレクタ、トラフィック ジェネレータ、および WAN シミュレーション デバイスなどがあります。 SmartBits は、ネットワーク トラフィックを収集してリプレイすることが可能なデバイス、または大規模なトラフィックを生成することが可能なデバイスの好例です。 組織はまたデータの収集を助けることができるプロトコル アナライザのようなデバイスから寄与するかもしれません。

ラボにはまた、ある程度の管理も必要です。 多くのより大きい組織にラボ ネットワークを管理するための責任があるフルタイム ラボ マネージャがあります。 他の組織では、既存のアーキテクチャ チームおよび技術チームが、ラボ検証を担当します。 ラボ管理 責任は発注実験装置がおよびアセット トラッキング、ケーブル接続、ラボ ルールおよび方向、ラボ スケジューリング、ラボ ドキュメント定義する、物理的 な 空間管理 プログラム設定トポロジ の 例、実験室試験、および可能性によって識別される問題を管理することを行う書き込みテスト 計画含まれています。

テスト タイプ

実行可能なテストには、多くの異なるタイプがあります。 多数のコンフィギュレーションですべてをテストできるテスト 計画および完全なテスト ラボを構築して前に組織はテクニカル マーケティング、および Cisco 設計テストのテスト、インテントの異なる型を理解する、はず、または顧客擁護がまたはべきであるか、かどうかいくつかのさまざまなテストに責任がある可能性があります。 顧客 テスト 計画は一般により露出されたテストの種類をカバーします。 次の表は、さまざまなテスト タイプ、テストを実行する時期、および各テストに対する責任の所在を理解するために役立ちます。

、組織の特定の機能セットの適切なテスト下記の、テストのトポロジーおよびアプリケーション の 組合せは普通最も貴重です。 Cisco がトポロジー、ハードウェアおよび設定された特性の特定の組み合せの組織のアプリケ− ションプロファイルをテストできないどんなに Cisco がフル フィーチャおよび回帰 試験を行うことを確認することは重要です。 実際、それは実行不可能機能、ハードウェア、モジュールおよびトポロジー 置換の全域をテストするためにです。 さらに、Cisco はサードパーティ機器とのインターオペラビリティをテストできません。 Cisco は組織が環境で見つけられるハードウェア、モジュール、機能およびトポロジーの精密な組み合せをテストすることを推奨します。 このテストは、パフォーマンス、相互運用性、停止、および焼き込みなどのサポート テストタイプとともに、組織の実稼動環境を再現するコラプスト トポロジを備えたラボ内で実行する必要があります。

テスト テストの概要 テストの責任者
機能および機能性 基本的な Cisco IOS機能および Ciscoハードウェア モジュールがアドバタイズされるように機能したかどうか確認します。 機能またはモジュール 機能性、また機能は設定 オプション テストする必要があります。 設定削除および付加はテストする必要があります。 基本的な運転休止のテストおよびバーンイン テストは含まれています。 Ciscoデバイス テスト
リグレッション 機能かモジュールが他のモジュールおよび機能と共に機能したかどうか、そして Cisco IOSバージョンが定義された機能に関連して他の Cisco IOSバージョンと共に機能すれば確認します。 バーンインおよび停止テストが含まれています。 Cisco 回帰 試験
基本的なデバイスパフォーマンス 機能またはモジュールの基本的なパフォーマンスを Cisco IOS機能かハードウエアモジュールがロードの下で最小限の要件を満たしたかどうか確認するために判別します。 Ciscoデバイス テスト
トポロジ、機能、ハードウェアの組み合わせ 機能およびモジュールが特定のトポロジーおよびモジュール/機能/ハードウェア の 組合せで予想通り機能したかどうか確認します。 このテストには、プロトコルの検証、機能の検証、show コマンドの検証、焼き込みテスト、および停止テストを含める必要があります。 Cisco は Enterprise Solutions Engineering (ESE)およびネットワーク ソリューション統合 テスト エンジニアリング(NSITE)のようなラボの規格によってアドバタイズされるトポロジーをテストします。 高可用性の顧客は特に早めに採用する人 ソフトウェアおよび標準外トポロジーを用いる機能/モジュール/トポロジー組み合わせを要求に応じてテストする必要があります。
停止(What-if) 特定の機能/モジュール/トポロジー 環境および潜在的な機能性影響で行われるかもしれない動作かよくある停止型が含まれています。 停止テストには、カード スワッピング、リンク フラップ、デバイス障害、リンク障害、およびカード障害が含まれます。 Cisco は基本的な運転休止のテストに責任があります。 顧客は個々の環境のスケーラビリティに関する停止 パフォーマンス上の問題に最終的な責任があります。 停止テストは、可能な限り、お客様のラボ環境内で実行する必要があります。
(何) NetworkPerformance 特定の機能/ハードウェア/トポロジー 組み合せに関連してデバイス ロードを調査します。 対象となるのは、設定されているトラフィック タイプとプロトコル、隣接デバイス、ルート数、およびその他の機能におけるリソース要件に関連した、CPU、メモリ、バッファ使用率、およびリンク使用率などの、デバイス容量およびパフォーマンスです。 このテストは、大規模な環境におけるスケーラビリティを確認するのに役立ちます。 顧客はデバイス ロードおよびスケーラビリティに最終的な責任があります。 ロードおよびスケーラビリティの懸案事項は頻繁に Cisco販売か高度 な サービスによって上げられ、頻繁に Customer Proof-of-Concept Labs (CPOC)のような Cisco ラボとテストされます。
バグ修正 バグ修正が識別された問題を修理するようにします。 Cisco は不具合が固定であることを確認するためにバグ修正をテストします。 顧客はまたことである固定経験した、そしてように不具合はモジュールまたは機能の他のどの側面も壊さない不具合するためにテストする必要があります。 メンテナンスリリースはレグレッション テスト済みですが、暫定リリースは通常ありません。
ネットワーク管理 簡易ネットワーク管理プロトコル(SNMP) マネージメント能力、SNMP MIB 可変正確さ、トラップ サポートおよび Syslog サポートを調査します。 Cisco は基本的な SNMP 機能、機能性および MIB 変数正確さをテストする役割があります。 顧客はネットワーク 管理 の 結果を検証する必要があり、新 技術配備のマネージメント 戦略および方法論に最終的な責任があります。
大規模なネットワーク エミュレーション 大規模なネットワーク エミュレーションは Agilent のルータ シミュレーターおよび Spirent のテスト ツール スイートのようなツールをより大きい環境を再現するのに使用します。 エミュレーションには、プロトコルの隣接ルータ、フレームリレーによる Permanent Virtual Circuit(PVC; 相手先固定接続)の数、ルーティング テーブルのサイズ、キャッシュ エントリなどが含まれます。また、デフォルトではラボ内に存在しないが、実稼動環境では通常必要とされる、その他のリソースが含まれる場合もあります。 Ciscoカスタマーは一般に本番にあるルーティングプロトコル隣接の数を/隣接関係および関連するルーティングテーブルサイズおよび他のリソース含むかもしれない、ネットワーク環境を再生するネットワークシミュレーション テストの側面を担当します。
相互運用性 サードパーティ ネットワーク機器への接続性に関するすべての側面をテストします。特に、プロトコルまたはシグナリング相互運用性が必要な場合、このテストを行います。 Ciscoカスタマーは一般に インターオペラビリティテストのすべての側面を担当します。
バーンイン ルータリソースを一定時間にわたり調査します。 バーンイン テストは一般的に デバイスがメモリ、CPU およびバッファを含むリソース利用に調査を用いるロードの下であるように一定時間にわたり要求します。 Cisco は基本的なバーンイン テストを行います。 顧客 テストはユニークなトポロジー、デバイスおよび機能の組合せに関連して推奨されます。

テストの方法論

テストの内容が理解できたら、次に、テスト プロセスのための方法論に進む必要があります。 ベスト プラクティスのテスト方法論の目的は、合意されたテストが包括的であり、適切に文書化され、容易に再現可能であり、実稼動において発生する可能性のある潜在的な問題の検出に有用であることの確認です。 ドキュメントおよび作り直す Lab Scenario は以降のバージョンをテストするために特に重要ですまたはテストのためにバグ修正はラボ 環境で見つけました。 テスト方法論の手順は、次のとおりです。 いくつかのテスト手順は、同時に実行することも可能です。

  1. テストの下で実稼働環境を再現するテスト トポロジーを作成して下さい。 WAN エッジ テスト環境は LAN テストは推奨環境を表すことができるより多くのデバイスを含むかもしれないが少数のコア ルータだけおよび 1 つのエッジルータを含むことができます。

  2. 実稼働環境を再現する機能を設定して下さい。 ラボ デバイスの設定は、想定する実稼動デバイスのハードウェアおよびソフトウェアの設定と厳密に一致する必要があります。

  3. テスト計画を記述して、テストおよび目標を定義し、トポロジを文書化し、機能テストを定義します。 テストには、基本的なプロトコルの検証、show コマンドの検証、停止テスト、および焼き込みテストを含める必要があります。 テスト 計画内の特定のテストの例は次 の テーブルにあります。

  4. ルーティング機能およびプロトコル機能を検証します。 資料かベースラインによって期待される表示コマンド結果。 プロトコルには、ATM、フレームリレー、Cisco Discovery Protocol(CDP)、イーサネット、スパニング ツリーなどのレイヤ 2 プロトコルと、IP、IPX、およびマルチキャストなどのレイヤ 3 プロトコルの両方を含める必要があります。

  5. 機能の機能性を検証します。 資料かベースラインによって期待される表示コマンド結果。 機能は認証、許可、アカウンティング(AAA)のようなグローバル 設定 コマンドおよび重要 な 機能を含むかもしれません。

  6. 実稼動環境内で予想される負荷をシミュレートします。 ロード シミュレーションはトラフィック 収集装置/ジェネレーターによってすることができます。 すべてのパケット損失を調査し、CPU、メモリ、バッファ使用率、およびインターフェイス統計情報などの、予想されるネットワーク デバイス使用率(可変)を検証します。 資料かベースラインは表示コマンド結果を期待しました。

  7. 負荷を受けているデバイスおよびソフトウェアの、処理または回避が予想される状況での停止テストを実行します。 たとえば、カード取り外し、リンクフラッピング、ルートフラッピングおよびブロードキャスト ストーム。 正しい SNMPトラップがネットワークの内で利用される機能に基づいて生成されているようにして下さい。

  8. テストが反復可能であるはずであるようにテスト結果およびデバイス測定単位を文書化して下さい。

テスト名 Hot Standby Router Protocol (HSRP) フェールオーバー
テストの設定要件 プライマリゲートウェイ インターフェイスにロードを適用して下さい。 ユーザ ステーション側からゲートウェイに向かうトラフィックを約 20 % にして、ユーザ ステーション側に向かう着信トラフィックを約 60 % にする必要があります。 また、より高いロードにトラフィックを増加して下さい。
テスト手順 show コマンドによって STP および HSRP を監視して下さい。 情報が収集された後プライマリゲートウェイ インターフェイス の 接続は失敗し、次に接続を回復 します。
期待される測定単位 フェールオーバーの間の CPU。 フェールオーバーの前、途中、および後の、プライマリ ゲートウェイおよびセカンダリ ゲートウェイのインターフェイス。 フェールオーバーの前、途中、および後の HSRP。
予想される結果 プライマリ ゲートウェイは、2 秒以内に他のルータ ゲートウェイにフェールオーバーします。 show コマンドの結果に、変更が正しく反映されます。 プライマリゲートウェイへのフェールオーバーは接続が復元するとき発生します。
実結果  
Pass または Fail  
パスを実現させるために必要な修正  

デバイス測定単位

テスト段階の間に、デバイスが正しく作動していることを確認するために次の測定単位を遂行し、文書化して下さい:

  • Memory usage

  • CPU 負荷

  • バッファ使用状況

  • インターフェイス統計情報

  • ルート テーブル

  • 特定のデバッグ

測定する情報は、実施しているテストによってそれぞれ異なります。 そのテストで取り組んでいる問題によっては、これ以外にも測定の必要な情報が存在する場合もあります。

各アプリケーションに関してはテストされている、パラメータ手段はそこに確認する特定のアプリケーションの不利なパフォーマンス影響ではないです。 この測定は、パフォーマンスのベースラインを使用して、配備前と配備後のパフォーマンスを比較して行います。 アプリケーション測定単位テスト用の例は下記のものを含んでいます:

  • ネットワークにログインするまでの平均時間。

  • ファイルのグループを Network File System(NFS; ネットワーク ファイル システム)にコピーするために必要な平均時間。

  • アプリケーションを起動し、最初の画面でプロンプトを表示するまでの平均時間。

  • その他のアプリケーション固有のパラメータ。

実装-速く、正常な Cisco IOS 配備

明示されているインプリメンテーション プロセスは組織が効率的に新しい Cisco IOS バージョンを展開するようにします。

実装フェーズには、試験プロセスおよび実装プロセスが含まれます。 試験プロセスでは、そのバージョンの Cisco IOS が実装先の環境で正常に動作することを確認し、実装プロセスでは、大規模な Cisco IOS の配備を迅速に、失敗なく行えます。

Cisco IOS の配備における戦略とツール

Cisco IOS の配備における戦略は、アップグレード ツールと明確な実装プロセスを使用して、試験プロセスおよび迅速な配備を通して、最終的な認証を行うことです。

ネットワーク 試験プロセスを開始する前に、多くの組織は一般の試験ガイドラインを構築します。 試験ガイドラインには、成功の基準、試験場所の条件、試験の文書化、試験所有者の条件、ユーザ通知の要件、および予想される試験期間など、すべての試験で想定される内容が含まれている必要があります。 エンジニアリング、実装およびオペレーションからのクロス機能チームは全面的な試験ガイドラインおよび試験プロセスの構築に普通関連します。 試験プロセスが作成されると、個々の実装グループが、指定されたベスト プラクティス方式を使用して正しく試験を実施できるようになります。

新しいソフトウェア バージョンの配備および最終認証が承認されると、次に、Cisco IOS のアップグレード計画の開始が必要になります。 アップグレードの計画は、プラットフォーム、メモリ、フラッシュ、および設定などの、新しいソフトウェア イメージの要件を特定することから開始します。 通常、新しいソフトウェア イメージの要件は、Cisco IOS の管理ライフサイクルの候補管理フェーズに、アーキテクチャ グループと技術グループによって定義されます。 必要な要件が特定されたら、実装グループが各デバイスを検証し、必要に応じてそれらのデバイスをアップグレードします。 CiscoWorks2000 Software Image Manager(SWIM)モジュールを使用して、デバイス インベントリに対する Cisco IOS の要件を検証し、検証の手順を実行することもできます。 すべてのデバイスが検証された場合か、ソフトウェア イメージが適切に新しい標準にアップグレードされた場合(あるいは、その両方が実行された場合)に、実装グループは、CiscoWorks2000 SWIM モジュールをソフトウェア配備のツールとして使用して、スロースタートの実装プロセスを開始できます。

新しいイメージを何度も正しく配備した後は、CiscoWorks SWIM を使用して、迅速に配備を行えるようになります。

Cisco IOS 資材 管理

CiscoWorks2000 Resource Manager Essentials(RME) のインベントリ マネージャを使用すると、Web ベースのレポート ツールによって、Cisco ルータおよびスイッチのバージョン管理が大幅に簡素化されます。この Web ベースのレポート ツールでは、ソフトウェア バージョン、デバイスのプラットフォーム、およびデバイス名に基づいて、Cisco IOS のデバイスが報告およびソートされます。

Cisco IOS SWIM

CiscoWorks2000 SWIM はアップグレード プロセスの失策の多い複雑な状況の簡素化で助けることができます。 CCO への組み込みリンクは Cisco IOS にソフトウェアパッチについての Cisco 関連テクニカルノートを強調表示するネットワークで展開されるオンライン情報および Catalyst ソフトウェアを関連させます。 新しい計画ツールは提案されたソフトウェア イメージ更新をサポートするためにハードウェア アップグレード(ブート ROM、フラッシュ RAM)が必要なときシステム要件を見つけ、通知を送信 します。

アップデートが始められる前に、新しいイメージの前提条件はターゲット スイッチかルータのコンポーネント データに対して更新成功の確認を助けるように検証されます。 複数のデバイスがアップデートされる場合、SWIM によってダウンロード タスクの同期が取られ、ユーザは作業の進行を監視できます。 予定された作業は承認プロセスを通して管理され、各アップグレード タスクの開始前にマネージャによって技術者の作業が承認されます。 RME 3.3 には Cisco IGX、BPX、および MGX プラットフォームのソフトウェア アップグレードを分析する機能が含まれているため、ソフトウェア アップグレードの影響を判断するために必要な時間が大幅に簡素化され、短縮されます。

試験プロセス

より安全に最小に するためにキャプチャへの潜在的な公開をどの残りの生産性 に 影響する 問題でも、ソフトウェア パイロット推奨され。 新しいテクノロジーを配備する際は一般的に試験が重要ですが、配備するソフトウェアが新しいサービス、機能、またはハードウェアにリンクされる場合には、よりクリティカルな試験が必要とされます。 個々の試験計画ごとに、試験の選択、試験の期間、および測定方法を検討する必要があります。 試験の選択とは、試験を実行する時期と場所を特定するプロセスです。 試験の測定とは、試験の成功および失敗、または潜在的な問題を特定するために、必要なデータを収集するプロセスです。

試験を完了する時期と場所は、試験の選択によって特定されます。 パイロットは影響が低い エリアの 1 つのデバイスから開始し、より影響の大きい エリアの多数のデバイスに伸びるかもしれません。 影響を軽減することが可能な試験を選択するための、いくつかの検討事項を次に示します。

  • 冗長性による単一 の デバイス影響に弾力性のあるネットワークのエリアにインストールされる。

  • 可能性のある本番影響を取扱うことができる選択されたデバイスの背後にあるユーザの最小数とのネットワークのエリア。

  • アーキテクチャ行に沿うパイロットを分ける Consider。 たとえば、ネットワークのアクセス、ディストリビューション、および/またはコアレイヤでそれを実践して下さい。

この試験の期間は、デバイスの機能を十分にテストおよび評価するために必要な時間に基づいて決定する必要があります。 試験の期間には、焼き込み試験と、通常のトラフィック負荷におけるネットワークの試験の両方の時間を含む必要があります。 また、試験の期間は、コードのアップグレード手順と、その Cisco IOS が稼動しているネットワーク領域によっても異なります。 Cisco IOS が新しいメジャーリリースである場合、より長い試験 期間は好まれます。 逆に、そのアップグレードが新機能を少ししか含まないメンテナンス リリースである場合には、短い試験期間で対応できます。

パイロット フェーズの間に初期 テストとして結果を同じような方法で監視し、文書化することは重要です。 この中には、ユーザ サーベイ、試験データの収集、問題の収集、および失敗と成功の基準を含めることができます。 ユーザーはトラッキングに直接的な責任があるはずで、パイロットに関連するユーザおよびサービスが試験結果に満足することすべての問題を確認する監察試験進行状況は識別され。 ほとんどの組織はパイロットか実稼働環境で正常である場合リリースを証明します。 この手順は、一部の環境では重大な障害となります。測定方法や成功の基準が特定または文書化されていない状態で、成功したと認識される場合があるためです。

実装

パイロット フェーズ以降に実稼働 ネットワークの内で、Cisco IOS 実施段階始まります完了されました。 実装フェーズには、実装のスロースタート、最終認証、アップグレードの準備、アップグレードの自動化、および最終検証など、ソフトウェア アップグレードの成功と実装の効率性を確認するためのいくつかの手順が含まれます。

実装 スロー スタートはゆっくりイメージに最終認証およびフル・スケール変換の前に実稼働環境への完全な公開があることを確認するために最近テストされたリリースを設定することのプロセスです。 1 日めは 1 台のデバイスだけをアップグレードし、翌日に 2 台のデバイスをアップグレード、その翌日にはおそらくもう数台へと増やしてゆく組織もあります。 実稼動環境に約 10 台のデバイスが配置されている組織では、特定の Cisco IOS バージョンが最終的に承認されるまでに 1 〜 2 週間かかる場合もあります。 最終認証を行う段階では、そのバージョンは、より高い信頼性を持ち、より迅速に配備できるようになります。

必要条件は満たされるようにするために遅い開始する プロセスがブートストラップ、DRAM およびフラッシュするのための最小 の Cisco IOS 規格のデバイス目録および行列を使用して、アップグレードのために識別されるすべてのデバイス検討され、検証する必要があった後。 このデータは、社内ツール、サードパーティ SNMP ツール、または CiscoWorks2000 RME を使用して取得することができます。 CiscoWorks2000 SWIM では、実装の前にこれらの変数が確認または調査されます。 ただし、実装の間に期待できることを認知していることが常に得策試みますです。

百以上の同じようなデバイスがアップグレードのためにスケジュールされる場合、自動化された 方式が利用されることが強く推奨されます。 オートメーションはアップグレード効率を改善し、SWIM の有無にかかわらず 1000 のデバイスの内部 の アップグレードに基づいて大きい配備の間にデバイス の アップグレード成功のパーセントを、改善するために示されていました。 Cisco は CiscoWorks 2000 SWIM がアップグレードの間に実行された 確認のある程度による大きい配備のために使用されることを推奨します。 問題が検出された場合には、SWIM を使用して Cisco IOS を前のバージョンに戻すこともできます。 SWIM はアップグレード作業を作成およびスケジューリングすることによって機能し、それぞれの作業はデバイス、望ましいアップグレード イメージ、および作業のランタイムによって設定されます。 各ジョブは 12 のまたはより少ないデバイス の アップグレードが含まれているはずで 12 までのジョブは同時に動作できます。 SWIM では、アップグレードの後に、Cisco IOS のアップグレードされたバージョンが正常に稼動しているかどうかも検証されます。 各デバイス の アップグレードのためのおよそ 20 分を認めることを推奨します(を含む確認)。 この計算に従えば、組織は 1 時間当たり 36 台のデバイスをアップグレードできます。 Cisco はまた潜在的な問題公開を減らすために最大百のデバイスが 1 夕方あたりにアップグレードされることを推奨します。

自動化された アップグレードに従がって成功を確認するために、検証はする必要があります。 CiscoWorks2000 SWIM ツールでは、成功をより確実に検証するために、アップグレードの後にカスタマイズされたスクリプトを実行できます。 ここでの検証には、ルータに適切な数のルートが含まれていることの検証、論理インターフェイスと物理インターフェイスがアップ状態でアクティブであることの確認、またはデバイスがアクセス可能であることの検証などがあります。 次のサンプル チェックリストを使用すると、Cisco IOS の配備の成功を完全に検証できます。

  • デバイスはきちんとリロードしましたか。

  • ネットワーク管理システム (NMS)によって ping 可能 な、到達可能 デバイスはプラットフォームですか。

  • 期待されたインターフェイスはデバイスおよびアクティブにアップしますか。

  • デバイスに正しいルーティング プロトコル 隣接関係がありますか。

  • ルーティング テーブルは読み込まれますか。

  • デバイス 通過は正しくトラフィックですか。

運用 - ハイ アベイラビリティ Cisco IOS の実装の管理

Cisco IOS 環境の高可用性の最良 の 方法 オペレーションはネットワークコンプレキシティを簡素化し、問題解決時間を短縮し、ネットワークアベイラビリティの改善を助けます。 Cisco IOS 管理の運用のセクションには、Cisco IOS を管理するための戦略、ツール、およびベスト プラクティスの方法論が含まれます。

Cisco IOS オペレーションにおける最良 の 方法はソフトウェア バージョン制御、Cisco IOS Syslog管理、問題管理、設定標準化およびアベイラビリティ管理が含まれています。 ソフトウェア バージョン管理とは、特定されたソフトウェア トラック内におけるソフトウェアの一貫性を追跡、検証、および改善するプロセスです。 Cisco IOS Syslog管理は Cisco IOS によって生成される高優先順位 Syslog メッセージに予防的にモニタリングおよび機能のプロセスです。 問題管理とは、ソフトウェアに関連する問題が将来的に発生することを防ぐために、そのような問題に関する重要な情報を迅速かつ効果的に収集する方法です。 設定標準化は本番で運動する試験されていないコードのための可能性を減らし、ネットワークプロトコルを標準化し、動作を特色にするためにコンフィギュレーションの標準化のプロセスです。 アベイラビリティ管理はメトリック、機能強化目標および機能強化プロジェクトに基づくアベイラビリティの改善のプロセスです。

Cisco IOS の運用における戦略とツール

多くの品質 戦略およびツールは Cisco IOS 環境の管理を助けるためにあります。 Cisco IOS の運用における最初の主要な戦略は、環境をできるだけ簡素化し、設定と Cisco IOS のバージョンのばらつきをできるだけ減らすことです。 Cisco IOS 認証は既にコンフィギュレーションの矛盾がもう一つの重要 な 地域であるどんなに、説明されてしまいました。 設定の標準の作成に対しては、アーキテクチャ グループまたは技術グループが担当します。 次に、Cisco IOS のバージョン管理および設定の標準と管理を通して、実装と運用のグループが、これらの標準を設定および保守します。

Cisco IOS の運用における 2 番目の戦略は、ネットワークの不具合を識別し、迅速に解決する能力です。 ネットワーク上の問題は操作グループによってユーザがそれらを呼出す前に一般に明らかにする必要があります。 また発見された問題は、ネットワーク環境に対してそれ以上の影響や変更が発生する前に、できるだけ迅速に解決する必要があります。 少数はこのエリアのキー最良の方法問題管理および Cisco IOS Syslog管理です。 Cisco IOSソフトウェア クラッシュの診断をすぐに助けるべきツールは Cisco アウトプットインタープリタです。

3 番目の戦略は、一貫性のある改善です。 この戦略のプライマリ プロセスは、品質ベースのアベイラビリティ改善プログラムを強化することです。 すべての問題の根本的な原因の分析の、Cisco IOS 関連 問題を含んで実行によって、組織はテスト カバレッジを改善し、問題解決時間を短縮し、停止影響を除去するか、または減らすプロセスを改善できます。 また、組織内で共通する問題を調査し、それらの問題をより迅速に解決するためのプロセスを構築することも可能です。

Cisco IOS の運用には、ソフトウェア バージョン管理のインベントリ管理(CiscoWorks2000 RME)、Syslog メッセージを管理する Syslog 管理、およびデバイス設定の一貫性を管理するデバイス設定マネージャが含まれます。

Syslog 管理

Syslog メッセージは、デバイスから収集サーバに対して送信されるメッセージです。 これらのメッセージは、エラー(たとえば、リンクが使用不可能など)である場合と、情報を知らせるメッセージ(たとえば、デバイス上の端末を設定するためにログインしているユーザがいるなど)である場合があります。

Syslog 管理のツールでは、ルータやスイッチが受信した Syslog メッセージの記録および追跡が行われます。 一部のツールには、重要なメッセージを見つけにくくする不要なメッセージを削除するためのフィルタが用意されています。 Syslog ツールでは、受信メッセージに関するレポーティングも可能です。 レポートは、期間、デバイス、メッセージ タイプ、またはメッセージ優先順位ごとに表示できます。

Cisco IOS 管理のための最も普及した Syslog ツールは CiscoWorks2000 RME Syslog マネージャです。 他のツールは利用できま Netal からの SL4NT、シェアウェア プログラムおよびleavingcisco.com OpenSystems からの Private I が含まれています。

CiscoWorks デバイスコンフィギュレーション マネージャ

CiscoWorks2000 Device Configuration Manager では、アクティブなアーカイブが維持されており、複数の Cisco ルータおよびスイッチ全体における設定変更を簡単に更新する方法も提供されています。 Device Configuration Manager は、設定変更の行われるネットワークを監視し、変更が検出された場合にアーカイブを更新し、変更についての情報を Change Audit Service に記録します。 WEB ベース ユーザインターフェイスはアーカイブを特定の設定 属性を捜し、違いの容易な識別のために 2 つのコンフィギュレーション ファイルのコンテンツを比較することを可能にします。

Cisco アウトプットインタープリタ

Cisco Output Interpreter は、ソフトウェアによる強制クラッシュを診断するために使用するツールです。 このツールを使用すると、Cisco Technical Assistance Center(TAC)に連絡することなく、ソフトウェアの不具合を特定できます。または、ソフトウェア強制クラッシュが発生した場合に、TAC へ伝えるプライマリ情報を収集することもできます。 このツールでは、少なくとも、必要な情報が収集できるため、問題を効率的に解決するために役立ちます。

ソフトウェア バージョン管理

ソフトウェア バージョン管理は、標準化されたソフトウェア バージョンだけを実装して、ネットワークを監視するプロセスです。このプロセスでは、ソフトウェアを検証し、バージョンに準拠しないソフトウェアを変更する場合もあります。 一般に、ソフトウェア バージョン制御は認証 プロセスおよび規格制御を使用して堪能です。 多くの組織は中央 Webサーバのバージョン規格を公開します。 さらにどんなバージョンが規格準拠ではない場合バージョンをアップデートするために動作しているか検討するために、実装担当者はトレインし。 一部の組織では品質ゲート プロセスを用意して、監査による二次的な検証を行い、実装期間中に標準が準拠されていることを確認しています。

オペレーションの間に、特にネットワークおよびオペレーション担当者が大きければネットワークの標準外バージョンを見ることは珍しくないです。 原因としては、教育を受けていない新しい担当者がいる、boot コマンドが誤って設定されている、または確認されていない実装がある、などが考えられます。 定期的に Cisco IOSバージョンによってすべてのデバイスをソートできる CiscoWorks 2000 RME のようなツールを使用してソフトウェア バージョン 規格を検証することが常に得策です。 非標準のバージョンが確認されると即座にフラグが付けられ、そのバージョンを標準のバージョンに移行するために、「Trouble Ticket」または「Change Ticket」が開始されます。

予防的な Syslog 管理

Syslog の収集、監視、および分析は、その他の手段では識別が困難または不可能な、Cisco IOS に特有のより多くのネットワーク問題を解決するために推奨される、障害管理プロセスです。 Syslog 収集、モニタリングおよび多くのエラーを予防的に識別し、解決することによって問題解決時間を短縮する分析 ヘルプはユーザによってより多くの深刻なネットワーク上の問題がベテランである前に、または報告されます。 SNMP で多数の MIB 変数をポーリングする方法と比較して、Syslog では、さまざまな種類の問題をより効果的に収集することもできます。 Syslog の収集、監視、および分析は、Cisco IOS を適切に設定し、CiscoWorks2000 RME などの Syslog 相関ツールまたは Syslog イベント管理のいずれか(あるいはその両方)を使用して行います。 Syslog イベント管理は、収集された、重要なメッセージに対応する Syslog データを解析し、次にリアルタイムの通知および解決のためのアラートまたはトラップをイベント マネージャに転送することによって実行されます。

Syslog を監視するには、Syslog データを解析および報告するために、NMS ツールまたはスクリプトが必要です。 これには、日付または期間、デバイス、Syslog メッセージ タイプ、またはメッセージ頻度によって Syslog メッセージをソートする機能が含まれます。 大規模なネットワークでは Syslog データを解析し、イベント 管理システムにアラートか通知かオペレーションおよび技術者発信するために、ツールかスクリプトは設定されるかもしれません。 多様な Syslog データのためのアラートが使用されない場合、組織は毎日高優先順位 Syslog データを少なくとも検討し、潜在的な問題のための障害報告票を作成する必要があります。 予防的に正常なモニタリングによって定期的なレビュー見られないかもしれない差し迫った問題を示唆しないかもしれない状況を検知するために歴史的 Syslog データの分析が実行された必要があるネットワーク上の問題を検出する サービスに影響 するようになる前に問題の示す値を提供するかもしれ、が。

問題管理

多くの顧客は問題管理のプロセスの欠如による追加ダウンタイムを経験します。 追加ダウンタイムは行われる場合がありまネットワーク管理者がすぐに試みるとき時間を問題識別、情報収集およびよく分析されたソリューション パスに費やしますよりもむしろサービスに影響を与えたコマンドまたはコンフィギュレーション変更の組み合せを利用する問題を解決することを。 このエリアの観測 された 挙動はデバイスをリロードするか、または問題および根本的な原因を調査する前の IP ルーティング テーブルのクリアが含まれています。 場合によっては、これは最初のレベルのサポート 問題解決という目的が理由で発生します。 ソフトウェアに関連する問題が発生した場合は、どの問題においても、接続またはサービスの復旧前に根本原因分析に必要な情報を迅速に収集することを目標とする必要があります。

問題管理プロセスはより大きい環境で推奨されます。 このプロセスには、デフォルトの問題に関するある程度の説明、および tier 2 へ問題を報告する前に、show コマンドを使用して適切な情報を収集することが含まれます。 最初 tierサポートは決してルーティングをクリアするか、またはデバイスをリロードすることをべきではありません。 好ましいのは、tier 1 のサポートで情報をすばやく収集し、tier 2 へ報告することです。 従って問題識別か問題の説明にちょうど更にいくつかの分を最初に使うことによって、根本的 な ディスカバリははるかに本当らしく、回避策、ラボ識別およびバグ レポートを許可します。 2 番めのレベルのサポートは、問題の診断または不具合レポートをまとめるためにシスコが必要とする情報の種類をよく理解している必要があります。 必要な情報には、メモリ ダンプ、ルーティング情報の出力、およびデバイスの show コマンド出力などがあります。

設定標準化

グローバル な デバイスコンフィギュレーション規格は企業全体のグローバルコンフィギュレーションの整合性に終って同様なデバイスおよびサービスを渡る標準グローバル 設定 パラメータの維持の推奨事項を表します。 グローバル 設定 コマンドは全体のデバイスとない個別のポート、プロトコル、またはインターフェイスに適用するコマンドです。 グローバル 設定 コマンドは一般に デバイスアクセス、汎用デバイス 動作およびデバイスセキュリティに影響を与えます。 Cisco IOS ではこれにはサービス コマンド、Ip コマンド、VTY コマンド、コンソールポート コマンド、logging コマンド、AAA/TACACS+ コマンド、Snmp コマンドおよびバナー コマンドが含まれています。 またグローバル な デバイスコンフィギュレーション規格で重要管理者がデバイスのドメイン ネーム システム(DNS)名に基づいてデバイス、デバイスの種類およびデバイス 位置を識別することを許可する適切なデバイス 命名規則はです。 グローバルコンフィギュレーションの整合性はネットワークコンプレキシティを簡素化し、ネットワーク サポート可能性を高めるのを助けるのでネットワーク環境の全面的なサポート可能性および信頼性にとって重要です。 多くの場合、サポートに関する問題は、設定が標準化されておらず、デバイスの動作、SNMP アクセス、および一般的なデバイス セキュリティが不適切、または一貫していないことが原因です。

グローバル な デバイスコンフィギュレーション規格を維持することは同じようなネットワークデバイスのためのグローバル 設定 パラメータを作成し、維持する操作グループか内部エンジニアリングによって普通達成されます。 それはまたそれらがすべての最近提供されたデバイスに最初にダウンロードすることができるように TFTP ディレクトリのグローバルコンフィギュレーション コンフィギュレーション・ファイルのコピーを提供する好ましい習慣です。 また有用 Web アクセス可能なファイルはです各コンフィギュレーションパラメータの説明を標準設定ファイルに与える。 また、デバイスのグローバル設定を定期的に行って設定の一貫性を確認したり、デバイスが適切なグローバル設定標準を満たしていることを定期的に確認したりしている組織もあります。 プロトコルおよびインターフェイスの設定の標準とは、インターフェイスおよびプロトコルの設定の標準を保守する方法を意味します。

プロトコルおよびインターフェイス設定の一貫性が実現されると、ネットワークの複雑さが軽減し、デバイスとプロトコルが予想通りに動作するようになり、ネットワークのサポート性が強化されるため、ネットワーク アベイラビリティが改善されます。 プロトコルまたはインターフェイス設定の一貫性が実現されていない場合、予想外のデバイス動作、トラフィック ルーティングの問題、接続性に関する問題の増加、およびサポートの応答時間の遅延などが発生する可能性があります。 インターフェイスコンフィギュレーション規格は CDP インターフェイス 記述子、キャッシング設定および他のプロトコル対応規格を含む必要があります。 プロトコル固有の設定標準には、次のようなものがあります。

  • IP ルーティング 設定

  • DLSW 設定

  • アクセスリスト設定

  • ATM 設定

  • フレームリレー 設定

  • スパニングツリーの設定

  • VLAN の割り当ておよび設定

  • Virtual Trunking Protocol (VTP)

  • HSRP

注: 持っていることは可能性のある設定されるものがによってネットワークの内で他のプロトコル対応コンフィギュレーション標準をです。

IP 規格の例は下記のものを含むかもしれません:

  • サブネットのサイズ

  • 使用される IPアドレス空間

  • 使用されているルーティング プロトコル

  • ルーティング プロトコルの設定

プロトコルおよびインターフェイスコンフィギュレーション規格を維持することは普通ネットワーク エンジニアリングおよび実装グループの責任です。 技術グループは、標準の特定、テスト、検証、および文書化を担当します。 次に、実装グループが、技術文書や設定テンプレートを使用して新しいサービスを提供します。 技術グループは、一貫性を確認するために、必要とされる標準のすべての側面に関して文書を作成する必要があります。 コンフィギュレーションテンプレートはまたコンフィギュレーション標準の実施を助けるために作成する必要があります。 運用グループも、標準に関する教育を受けて、非標準の設定を識別できるようになる必要があります。 コンフィギュレーションの矛盾はテスト、検証および認証フェーズの大きい支援です。 実際、標準化されたコンフィギュレーションテンプレートなしで、十分に大規模なネットワークのために Cisco IOSバージョンをテストするか、検証するか、または適度に証明することはほぼ不可能です。

アベイラビリティ管理

アベイラビリティ管理は質の向上 メトリックとしてネットワークアベイラビリティを使用して質の向上のプロセスです。 多くの組織は今アベイラビリティおよび停止型を測定しています。 停止のタイプには、ハードウェア、ソフトウェア、リンクまたはキャリア、電源または環境、設計、あるいはユーザ エラーまたはプロセスなどがあります。 停止を識別し、リカバリに続く根本的な原因の分析を行うことによって、組織はアベイラビリティを改善するためにメソッドを識別できます。 ハイ アベイラビリティを実現させたほとんどすべてのネットワークに質の向上 プロセスがあります。

付録 A - Cisco IOSの概要 リリース

Cisco IOS ソフトウェア リリースの戦略は、正常なソフトウェア開発、品質保証、および短期間での市場投入という、お客様のネットワークの成功に欠かせない原則に基づいて構築されています。

リリースのプロセスは、次に説明する 4 つのリリース カテゴリを中心として定義されます。

  • Early Deployment リリース(ED)

  • メジャーリリース

  • 限定配備リリース(LD)

  • ジェネラル デプロイメント リリース(GD)

Cisco は個々のリリースについての情報が、ターゲット市場、マイグレーション パス、新しい 機能説明、等ある IOSロードマップを作成し、維持します。

次の図は、Cisco IOS ソフトウェア リリースのライフサイクルを示しています。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-2.gif

ED リリース

Cisco IOS ED リリースは市場に新しい開発を持って来る手段です。 EDリリースの各メンテナンスリビジョンはプロトコルおよび Cisco IOSインフラストラクチャに新しい 機能のバグ修正、また一組、新しいプラットフォームサポートおよび全体的な機能拡張がだけでなく、含まれています。 2 年への各自、ED リリースの機能およびプラットフォームは次のメインライン Cisco IOS リリースに移植されます。

ED リリースには 4 つのタイプがあり、それぞれリリース モデルとライフ サイクル マイルストーンがわずかに異なります。 ED リリースは、次のように分類できます。

  • Consolidated Technology Early Deployment (CTED) リリース—新しい Cisco IOS リリースモデルは強化された一連のEDリリース、別名 Cisco IOS に新しい 機能、新しいハードウェアプラットフォームおよび他の機能拡張をもたらすのに「T」トレインを、使用します。 これらは、社内の Business Unit(BU)および Line Of Business(LOB)の定義の枠を超えているため、統合テクノロジーと呼ばれます。 統合技術リリースの例は Cisco IOS 11.3T、12.0T および 12.1T です。

  • Specific Technology Early Deployment (STED) リリース— STEDリリースに CTED リリースとして同じような機能提供特性があります但し例外としては特定のテクノロジーを目標とするか、またはシアターを販売します。 STED は常に特定のプラットフォーム向けにリリースされ、完全に Cisco BU の監督下にあります。 STED リリースは、メジャー リリース バージョンに付加された 2 文字によって識別されます。 STEDリリースの例は Cisco IOS 11.3NA、11.3MA、11.3WA および 12.0DA です。

  • Specific Market Early Deployment (SMED) リリース— Cisco IOS SMED はそれらが特定のバーティカル マーケット セグメント(ISP、企業、金融機関、Telcom 会社、等)を目標とするというファクトによって STED から区別されます。 SMED には、目的の垂直市場で使用される特定プラットフォームだけを対象した、特定のテクノロジー機能要件が含まれます。 SMED は、目的の垂直市場に関連する特定のプラットフォーム専用に構築されますが、CTED は、より広範なテクノロジー要件に基づいて、複数のプラットフォーム用に構築されます。この点で、SMED は CTED と異なります。 Cisco IOS SMED リリースはメジャーリリースバージョンに追加 される 1 つの英字によって識別されます(CTED と同様に)。 SMED の例は Cisco IOS 12.0S および 12.1E です。

  • 短命の Early Deployment リリース、別名 X は(XED) — Cisco IOS XED リリースもたらします新しいハードウェアおよびテクノロジーをリリースしますマーケットに。 ソフトウェア メンテナンス リビジョンや定期的なソフトウェア暫定リビジョンは提供されません。 問題が CTED の統合前に XED で検出される場合、ソフトウェアの再ビルドは始められ、数は名前に追加 されます。 たとえば、Cisco IOS Release 12.0(2)XB1 および 12.0(2)XB2 は 12.0(2)XB 改造の例です。

メジャーリリース

メジャーリリースは Cisco IOSソフトウェア 製品のための主な導入手段です。 メジャー リリースは Cisco IOS 技術部門によって管理されており、機能、プラットフォーム、機能性、テクノロジー、および以前の ED リリース以降に増設されたホストが統合されています。 Cisco IOS メジャー リリースはより大きい安定性および品質を追求します。 その理由で、メジャーリリースは機能の追加かプラットフォームを受け入れません。 各メンテナンスリビジョンはバグ修正だけを提供します。 たとえば、Cisco IOS ソフトウェア リリース 12.1 および 12.2 はメジャーリリースです。

メジャーリリースにレグレッション テスト済み、最新バグ修正を統合し、新しいプラットフォームか機能をサポートしないメンテナンスリリースと呼ばれるスケジューリングされたメンテナンスアップデートがあります。 メジャーリリースとそのメンテナンス レベルは、メジャー リリースのリリース番号によって識別されます。 Cisco IOS ソフトウェア リリース 12.0(7)では、12.0 はメジャーリリースの番号であり、7 つはメンテナンス レベルです。 完全なリリース番号は 12.0(7) です。 Cisco IOS ソフトウェア リリース 12.1 (3) の場合も同様に、12.1 がメジャー リリースで、12.1(3) は 3 番目のメンテナンス リリースです。

Limited Deployment (LD) リリース

LD は主要なリリースのための FCS と General Deployment 間の Cisco IOS 成熟度のフェーズです。 それらが決して GD 認証を達成しないので限定配備フェーズだけにライブ Cisco IOS ED リリース。

General Deployment (GD) リリース

リリースライフサイクルの間ある時点で、Cisco は GD 認証の準備ができるメジャーリリースが宣言します。 GD の状態になれるのは、メジャー リリースだけです。 あるリリースについて、シスコが次の条件を満たしていると判断したときに、メジャー リリースが GD 認証のマイルストーンに到達します。

  • さまざまなネットワークで、市場に幅広く公開されていること。

  • 安定性傾向および不具合傾向のメトリックによって認定されていること。

  • お客様の満足度調査によって認定されていること。

  • 顧客の正規化傾向のリダクションは前の 4 つのメンテナンスリリース上のリリースの問題を検出しました。

TAC エンジニア、Advanced Engineering Services (AES)エンジニア、システム 試験エンジニアリング、および Cisco IOS 設計で構成される顧客擁護 GD 認証 クロス機能チームはリリースの各目立った欠陥を評価するために形成されます。 GD 認証の最終的な承認は、このチームによって与えられます。 リリースが GD ステータスを獲得すると、そのリリースに続くリビジョンもすべて GD になります。 その結果、一度リリースは宣言された GD です; それは自動的に制限付きメンテナンス フェーズに入ります。 このフェーズでは、大幅なコードの手直しをともなう不具合修正などのコードの技術的な修正は、プログラム マネージャによって厳密に制限され、管理されます。 そうすることで、Cisco IOS ソフトウェアの GD 認証されたバージョンに、不具合が入り込むことを防ぎます。 GD になるのは、特定のメンテナンス バージョンです。 そのリリースの後続のメンテナンス アップデートも GD リリースになります。 たとえば、Cisco IOS ソフトウェア リリース 12.0 は 12.0(8) で GD 認証を取得しました。 したがって、Cisco IOS ソフトウェア リリース 12.0(9)、12.0(10) なども、GD リリースです。

実験か診断イメージ

実験か診断イメージは時々エンジニアリング スペシャルと重要なソフトウェア上の問題が識別されたらだけ言われ、生成されます。 これらのイメージは、通常のリリース プロセスには含まれません。 このカテゴリのイメージはバグ修正を診断をテストするか、助けるように設計されている顧客特定のビルドまたは即時修正を提供するために問題の、です。 即時修正はそれが次の中間かメンテナンスリリースを待つオプションのとき提供されるかもしれません。 実験か診断イメージはあらゆるリリースタイプのメンテナンスまたは暫定バージョンを含むあらゆる支援ソフトウェア ベースで構築されるかもしれません。 正式な名前付け変換は存在 しませんが、多くの場合開発者はベースイメージ名前に頭文字、Exp. (実験のために)、または追加ディジットを追加します。 これらのイメージは、シスコの開発との関連の中で一時的にサポートされるだけです。Cisco TAC および Cisco IOS のリリース工程では、シンボル テーブルやベース イメージ履歴などの、サポート文書が管理されないためです。 これらのイメージには、シスコの社内テストが適用されません。

リリースのライフサイクル マイルストーン

ある時点で、GD リリースは最新のネットワーキング 技術とより新しいリリースと取替えられます。 したがって、次の 3 つの主要なマイルストーンを使用して、リリースを停止するプロセスが確立されています。

  • の終わり販売(EOS) —メジャーリリースに関しては、EOS 日付は First Commercial Shipment (FCS)日付以降の 3 年です。 これによって、新しいシステムのためにリリースの購入が可能な最終の日付が設定されます。 EOS リリースのメンテナンス アップグレードは、引き続き Cisco Connection Online(CCO)からダウンロードして入手可能です。

  • End Of Engineering (EOE) — EOE リリースは GD リリースのための最後のメンテナンスリリースでした、一般的に約 3 か月に後 EOS リリース続きます。 顧客は Cisco TAC からテクニカル サポートを受け取り続けることができましたり、また CCO から EOE リリースをダウンロードします。 EOS リリース予定日の 1 年前に、EOS および EOE がリリースされることと、それぞれのリリース日を公表する製品速報が発表されます。 現時点で、顧客は最新のネットワーキング 技術を利用するために Cisco IOSソフトウェアのアップグレードを調査し始める必要があります。

  • End of Life (EoL) —リリースライフサイクルの端に、Cisco IOS ソフトウェア リリースのためのすべてのサポートはもはや EOL 日付のダウンロードのために利用可能終わり。 一般に、EOL 日付は EOE 日付以降の 5 年です。 EOL 製品速報はおよそ 1 年実際の EOL 日付以前に送達されます。

Cisco IOSバージョン 命名規則

Cisco IOS イメージの命名規則によって、リリースされているすべてのイメージの完全なプロファイルが提供されます。 名前には、常にメジャー リリースの ID とメンテナンス リリースの ID が含まれます。 その他に、トレインを示す文字、リビルドを示す文字(メンテナンス リリースの場合)、BU 固有の機能番号、および BU 固有の機能番号のリビルド ID も名前に含まれる場合があります。 書式の説明を、次に示します。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-a.gif

命名規則 セクション 説明
x.y 「分かれる 2 つの別々の(1-2 の)ディジット識別の組み合せ」。 それはメジャーリリース値を識別します。 この値は、Cisco IOS のマーケティングによって決定されます。 例: 12.1
z x.y のメンテナンス リリースを示す、1 〜 3 個の数字。 これは 8 週間ごとに発生します。 ベータ版は 0、FCS は 1、および最初のメンテナンス リリースは 2 です。 例: 12.1(2)
p x.y(z)のリビルドを示す 1 文字のアルファベット。 最初のリビルドが小文字の「a」、次が「b」、その後も同様です。 例: 12.1(2a)
A 1 〜 3 文字のアルファベットは、リリース トレインを示し、CTED、STED、および X の各リリースでは必須です。 それはまたファミリー製品かプラットフォームを識別します。 CTED リリースおよび STED リリースでは、2 文字が使用されます。 最初の文字は技術を示し、2 番目の文字は差別化のために使用されます。 次に、例を示します。
A = Access Server/Dial technology (example:11.3AA)
B = Broadband (example:12.2B)
D = xDSL technology (example:12.2DA)
E = Enterprise feature set (example:12.1E)
H = SDH/SONET technology (example:11.3HA)
N = Voice, Multimedia, Conference (example:11.3NA)
M = Mobile (example:12.2MB)
S = Service Provider (example:12.0S)
T = Consolidated Technology (example:12.0T)
W = ATM/LAN Switching/Layer 3 (example:12.0W5)
リリースネームの最初の位置の「X」は CTED 「T」トレインに基づいて一時的リリースを識別します。 たとえば、XA、XB、XC、等。 「X」かリリースネームの第 2 位置の「Y」は基づいてか、またはに加入する一時的なEDリリースを STEDリリース識別します。 たとえば、11.3NX (11.3NA に基づく)、11.3WX (11.3WA に基づく)、等。
o 特定のリリース値のリビルドを示す、オプションの 1 桁または 2 桁の数字。 ブランクを残しま改造を表しません。 1 から開始し、次に 2、その後も同様です。 例: 12.1(2)T1、12.1(2)XE2
u BU 固有のリリースの機能を示す、1 桁または 2 桁の数字。 この値は、BU のマーケティング チームによって決定されます。 例: 11.3(6)WA4、12.0(1)W5
v BU 固有のコードのメンテナンス リリースを示す、1 〜 2 桁の数字。 ベータ版は 0、FCS は 1、および最初のメンテナンス リリースは 2 です。 例: 11.3(6)WA4(9), 12.0(1)W5(6)
p 特定の技術リリースのリビルドを示す 1 文字のアルファベット。 最初のリビルドが小文字の「a」、次が「b」、その後も同様です。 例: 11.3(6)WA4(9a) は 11.3(6)WA4(9) のリビルドとなります。

次のグラフでは、Cisco IOS 命名規則のそれぞれのセクションにラベルを付けてあります。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-b.gif

付録 B - Cisco IOS 信頼性

Cisco IOS 信頼性は Cisco が絶えず改良するように努力するエリアです。 顧客を論議する前に最良 の 方法を、Cisco 内部 IOS 品質の知識方向づけ、信頼性 努力は必要です。 これらのセクションは、Cisco IOS ソフトウェアの品質に対するシスコの最近の取り組みについての概要と、ソフトウェアの信頼性に関連してお客様に必要な前提を説明することを主な目的としています。

Cisco IOS 品質 プログラム

Cisco に GEM Great Engineering Methodology (GEM)と呼ばれる明示されている IOS 開発プロセスがあります。 このプロセスのライフサイクルは、次の 3 つのフェーズで構成されます。

  • 戦略と計画

  • 実行

  • 配備

ライフサイクル内の一般のエリアは機能紹介プライオリティ設定、開発、テストプロセス、ソフトウェア紹介フェーズ、提供された最初顧客(FCS)、GD および支えるエンジニアリングが含まれています。 Cisco はまた国際 標準化 機構 (ISO)、Telcordia (以前のベルコア)、IEEE およびカーネギー・メロン ソフトウエア 工学協会のような組織からのいくつかのソフトウェアの品質 最良 の ガイドラインに従います。 これらのガイドラインは Cisco の GEM プロセスに統合されます。 Ciscoソフトウェア 開発プロセスは ISO 9001 です(1994)証明される。

Cisco IOS ソフトウェア品質改善の主要なプロセスは、お客様主導のプロセスです。このプロセスによって、シスコはお客様のご意見を伺い、目標とメトリックを定義し、ベスト プラクティスを実装し、結果を監視します。 ソフトウェアの品質を改善することに努力しているクロス組織チームはこのプロセスを駆動します。 Cisco IOS 質の向上 プロセスのダイアグラムは下記のように示されています:

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-3.gif

品質改善のプロセスには、2002 年会計年度以降、明確で重要な目標が用意されています。 これらの目標の主要な焦点は、ソフトウェア問題をテスト サイクルの初期段階において特定することによって不具合を削減し、不具合の未処理件数を減少させ、機能の一貫性およびソフトウェア リリースの透明性を強化し、一貫した予想可能なリリース スケジュールおよび高いソフトウェア品質を提供することにあります。 これらのエリアを当たるコントロールは新しいテスト カバレッジ ツール(より弱いテスト カバレッジのエリアを識別する)、テスト是正措置 プロセス改良および Cisco IOS システムが回帰 試験機能拡張含まれています。 追加情報はこれらの問題に対処するために加えられ、すべてのプライマリ Cisco IOS ソフトウェア リリースのための管理およびクロス機能提供があります。

Cisco IOS リリース テスト

Cisco 内のソフトウエア 信頼性 品質 努力の統合部分はテストの品質、スコープおよびカバレッジです。 シスコの掲げる IOS の品質目標は次のとおりです。

  • シスコ社内で検出されているリグレッション障害を削減する。 これには、開発のより高い品質、およびスタティック/ダイナミック分析によるさらに多くの問題の特定が含まれます。

  • お客様によって発見される不具合を削減する。

  • 未解決の不具合の総数を削減する。

  • ソフトウェア リリース 明解を高め、一貫性を特色にして下さい

  • 主要リリースおよびメンテナンス リリースにおいて、リリース スケジュールと高い品質を提供する。

Cisco 内部テストは異なる問題がテストの異なるステージで識別されるプロセスとしてを捉えることができます。 全体的な目標は、適切なラボ内において、適切な種類の不具合を発見することです。 これは、いくつかの理由により重要です。 まず、最も重要な理由は、同じ範囲をカバーするテストが、その後のテスト段階には存在していない可能性があることです。 また、初期段階のテストは自動化できますが、後になるにしたがいテストの複雑さや必要な技術が増加するため、段階から段階へとテスト費用も劇的に増大します。 次の図は、Cisco IOS のテスト スペクトラムを示しています。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-4.gif

最初の段階は、ソフトウェアの開発です。 Cisco にこのエリアで最初のソフトウェアの品質の改善を助けるための複数の努力があります。 開発グループはまたコード リビューまた更に他の開発者がソフトウェアの変更か新しい 機能コードを承認するようにするために複数のコード リビューを行います。

次の段階は、ユニット テストです。 ユニット テストは、ラボを利用せずにソフトウェアのインタラクションを調べるツールを使用して行います。 DevTest は feature/functionalityテストおよび回帰 試験を含む実験室試験です。 Feature/functionalityテストはある特定の機能の機能性を検査するように設計されています。 このテストでは、設定、設定解除、および機能の仕様書で定義されている、すべての機能の組み合わせがテストされます。 リグレッション テストの目的は、機能の機能性と動作を継続的に検証することであり、自動化されたテスト機能を使用して実行されます。 このテストの主要な焦点は、多くの異なるネットワーク トポロジにおけるルーティング、スイッチング、および機能の機能性を、ping および限定的なトラフィック生成によってテストすることです。 リグレッション テストを行う際に考えられる機能、プラットフォーム、ソフトウェア バージョン、およびトポロジの組み合わせはあまりにも多いため、シスコでは、これらのうちの限られた組み合わせに対してだけリグレッション テストを実施しています。それでも、現在利用されているリグレッション テスト スクリプトは 4000 以上にのぼります。 統合テストは製品およびインターオペラビリティのより多くの広範囲の組のためのラボ テスト機能で拡張するように設計されています。 相互運用性テストが、ストレスおよび性能試験、システム 試験およびネガティブ テスト(予想外イベントをテストする)含まれるテストの拡張によってコード カバレッジをテストするまた統合テスト増加。

次のラボ フェーズでは、一般的な顧客環境を対象としたエンドツーエンドのテストが提供されます。 これらのテストは、顧客シナリオにおけるテストである Financial Test Lab(FTL)および NSITE として、上記の図に示されています。 FTL は成果重視の財政コミュニティのためのテストを提供するために構築されました。 異なる Cisco IOSの技術により多くの詳細なテストを提供する NSITE はグループです。 NSITE および FTL の各ラボでは、スケーラビリティとパフォーマンスのテスト、アップグレード性、アベイラビリティと回復力、相互互換性、およびサービサビリティなどの領域に焦点をあてています。 サービサビリティにおける重点項目は、バルク プロビジョニングの問題、イベントの管理/相関、および負荷時のトラブルシューティングです。 シスコ社内には、この他にも、さまざまな垂直市場においてこれらの領域のテストを行うためのラボが置かれています。

上記の図で最後に示されているラボは、お客様のラボです。 顧客 テストは機能の正確な組み合せ、設定、プラットフォーム、モジュールおよびトポロジーが十分にテストされたことを高可用性の環境が確認することができるように拡張 品質 努力のおよび推奨されるです。 テスト カバレッジには、特定のトポロジにおけるネットワーク スケーラビリティとパフォーマンス、特定のアプリケーション テスト、特定の設定におけるネガティブ テスト、シスコ製以外のデバイスとの相互運用性テスト、および焼き込みテストなどを含む必要があります。

ソフトウェアの MTBF

全体的な信頼性における最も一般的なメトリックの 1 つは、Mean Time Between Failure(MTBF; 平均故障間隔)です。 ソフトウエア 信頼性のための MTBF は MTBF を使用してハードウェア 信頼性のために開発された分析機能が理由で役立ちます。 ハードウェア 信頼性はいくつかの既存 の 規格を使用してより正確に判別することができます。 Cisco は Telcordia Technologies からの標準 MTBF データに基づいて部品数方式を利用します。 しかし MTBF ソフトウェアに対応した 分析方式がないし、MTBF 分析のためのフィールド 測定に頼る必要があります。

過去 3 年に関しては、Cisco は Cisco 内部 IT ネットワークのためのソフトウエア 信頼性 フィールド 測定を実行された、この作業は Cisco の内で文書化されています。 調査は Cisco IOS デバイスのソフトウェア強制クラッシュに基づいており、このデータはネットワーク管理における SNMP トラップ情報および稼働時間情報を使用して測定できます。 この調査では、特定のソフトウェア リリースに対する統計的な対数正規分布モデルを使用して、ソフトウェアの信頼性を分析しています。 ソフトウェア障害の平均修理時間(MTTR)は平均すると基づいたルータ 再始動および回復時間です。 6 分回復時間は企業環境のために使用され、15 分はより大きいインターネットサービスプロバイダー(ISP)のために使用されます。 この進行中のスタディの結果は強制されるソフトウェアを使用して測定されて唯一のダウンタイム ソースとしてクラッシュするように、または少数のメンテナンスバージョンの後でリリースされたとき会い、一定時間にわたりより高いソフトウェアが一般に良い nines アベイラビリティにことです。 この調査で確認されている潜在的な MTBF 値は、初期導入ソフトウェアにおける 5,000 時間から、一般導入ソフトウェアにおける 50,000 時間までの範囲となっています。

この調査に対する最も一般的な反論は、ソフトウェアの信頼性に関連して発生した停止時間のすべてが、ソフトウェア強制クラッシュに含まれているわけではないというものです。 このメトリックが質の向上 努力で使用される場合、ソフトウェアによって強制されるクラッシュの比率の改善を助けるかもしれませんでしたりソフトウエア 信頼性の他の重要なエリアを無視するかもしれません。 統計的な方法によってソフトウェアの信頼性を正確に予測することが困難であるために、この反論に対する答えはほとんど出ていません。 Ciscoソフトウェア ソフトウエア品質統計学者は正確なデータの設定 された確実により広い範囲の停止型を使用してソフトウェア MTBF を予測するためにより大きいサンプルが必要であることを結論を出しました。 さらに、理論的な統計 分析はソフトウェア 関連 問題を、有効に なった ネットワーク設計解決して、担当者のネットワークコンプレキシティ、専門知識機能およびソフトウェア管理プロセスのような変数が困難な原因です。

現時点で、企業作業はにより正確に予測します正確に機密データのこの型を集める問題によるフィールド 測定を用いるソフトウエア 信頼性を完了しませんでした。 また、ほとんどの顧客は着ますか。t はデータ アベイラビリティのの独自の性質によるネットワークから情報 アベイラビリティの直接集める Cisco がほしいと思います。 ただし、一部の組織では、ソフトウェアの信頼性に関するデータを収集しています。シスコは、ソフトウェアの停止に起因するアベイラビリティのメトリックの収集と、それらの停止に対する根本原因分析を推奨しています。 ソフトウェアの高い信頼性を実現している組織では、このような予防的な立場をとって、管理可能な多くの方法を通してソフトウェアの信頼性を向上しています。

ソフトウェアの信頼性における前提

顧客からのフィードバックの結果として、Cisco IOSの技術 グループによって実行された 予防的 な Cisco 高度 な サービスによって実行されたスタディおよび原因解析は、いくつかのより新しい想定団結し、ソフトウエア 信頼性の改善を助ける最良 の 方法は形成されました。 これらの前提の中核となるのは、テストの責任、ソフトウェアの完成度または開発されてからの期間、使用可能な機能、および導入されているソフトウェア バージョンの数です。

テストの責任

最初の新しい前提は、テストの責任に関するものです。 Cisco は新製品ではたらくようにするために/新しい 機能および機能性を検証する役割がありますテストする常に。 Cisco は回帰 試験にまた責任がありますソフトウェア バージョンが下位互換であることを確認するために。 ただし、Cisco は発揮顧客 の 環境ができる各潜在的な警告に対して各機能、トポロジーおよびプラットフォームを検証できません(設計特質、ロードおよびトラフィックプロファイル)。 顧客向けの高可用性の最良 の 方法は顧客によって定義される機能、設計、サービスおよびアプリケーショントラフィックを使用して実稼働 ネットワークをまねる縮小されたトポロジ の 例でテストが含まれています。

信頼性とソフトウェアの完成度

ソフトウェアの信頼性は、ソフトウェアの完成度の主要な要因です。 公開されて使用され、確認された不具合が修正されることにより、ソフトウェアの完成度は高くなります。 Ciscoリリース オペレーションはトレイン リリース アーキテクチャにソフトウェアが追加される新しい 機能なしで成熟するようにすることを行きました。 ハイ アベイラビリティを必要とする顧客は今必要とする機能とのより成長したソフトウェアを探して います。 それからソフトウェアの成熟度、新しい 機能または機能性のためのアベイラビリティ要求およびビジネスを推進するものの間で存在 するトレードオフ。 多くの組織に受諾可能な成熟度のための規格かガイドラインがあります。 特定のトレインの 5 番目の暫定リリースだけを受け入れる組織もあります。 他のために、それは第 9 または GD 認証であるかもしれません。 どの組織も最終的には、ソフトウェア完成度に対して、許容できるリスクの水準を決定する必要があります。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-5.gif

信頼性と機能および標準の量

ソフトウェアの信頼性とは、実稼働環境でどれだけのコードがテストされ、実行されるかでもあります。 異なるハードウェアプラットフォームおよびモジュールの数量が増加すると同時に、また運動する一般に ソフトの欠陥への公開を高めるコードの量は増加します。 設定されているプロトコルの量、設定の種類、およびトポロジまたは実装されている設計の種類についても同様です。 設計、設定、プロトコルおよびハードウエアモジュール ファクタはソフトの欠陥への増加されたリスクか公開におよび運動するコードの量に貢献できます。

現在、ソフトウェアのリリース工程では、ある特定の領域における利用可能なコードを全般的に制限する、特別な目的を持つソフトウェアが用意されています。 ビジネスユニットに Cisco の内で徹底的にテストされ、顧客によってより広く利用されるコンフィギュレーションおよびお勧めの設計があります。 顧客はまた試験されていないコード公開の量を下げ、全面的なソフトウエア 信頼性を改善する標準化されたモジュラ トポロジーおよび標準の設定における最良 の 方法を採用し始めました。 ハイ アベイラビリティ ネットワークの中には、テストされていないコードの利用を削減するために、厳密な標準設定のガイドライン、モジュラ トポロジの標準、およびソフトウェアのバージョン管理が用意されているものもあります。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-6.gif

信頼性と配備されているバージョンの数

ソフトウエア 信頼性のもう一つのファクタはコードのバージョンと複数のバージョンと混乱する薄い量間のインターオペラビリティです。 ソフトウェア バージョンの数量が増加すると同時に、また運動するソフトの欠陥への公開を高めるコードの量は増加します。 複数のバージョンの追加のコードが実行されると、信頼性に対するリスクは急激に増加します。 特定の機能およびプラットフォーム要件をカバーするために組織がネットワークの少なくとも一握りのバージョンを実行する必要があることが今認識されます。 それにもかかわらず、ほぼ均一のネットワーク環境において 50 以上のバージョンを実行しているような場合は、一般的にソフトウェアの問題が存在しています。バージョンの数が多すぎて、適切な分析や検証ができないためです。

ソフトウェアの信頼性を強化するために、シスコの開発は、ソフトウェア リグレッション テストも行って、異なるソフトウェア バージョン間の互換性を確認しています。 さらに、ソフトウェアコードはモジュラであり、コアモジュールはバージョンの間で一定時間にわたりかなり変更してがまずないです。 Ciscoリリース オペレーションはまた顧客に問題が検出されると同時に既知の障害とのバージョンか相互運用性 の 問題が CCO からすぐに取除かれると同時に利用可能 な ソフトウェアの量を変更しました。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/25562-ios-management-7.gif

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

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


関連情報


Document ID: 25562