Cisco Service Control SCA BB 3.0 から SCA BB 3.1 へのアップグレード ガイド
アップグレードの目的および制約事項
アップグレードの目的および制約事項
発行日;2012/01/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 175KB) | フィードバック

目次

アップグレードの目的および制約事項

アップグレードの目的

サポート対象の動作設定

SCE プラットフォーム

アップグレード手順の制約事項

LIC の再焼き付けによるリンク ダウンタイム

アップグレード完了前に開始されたフローの分類ミス

サービス ダウンタイム

集約された未報告データの消失

設定の消失

SCA BB クライアントとサービス設定

アップグレード手順の制約事項

SCA BB Console の相互運用性

サービス設定のアップグレード

ユーザ定義のシグニチャ

Reporter および DB の相互運用性

2 つの SCA BB Console または Reporter の実行

Subscriber Manager

アップグレード手順の制約事項

LEG の設定

Quota Manager

Collection Manager

アップグレード手順の制約事項

設定

ロールバックの手順

アップグレードの目的および制約事項

ここでは、アップグレード手順の目的を、処理中に各コンポーネントで見込まれる制約事項と比較します。

「アップグレードの目的」

「サポート対象の動作設定」

「SCE プラットフォーム」

「SCA BB クライアントとサービス設定」

「Subscriber Manager」

「Collection Manager」

「ロールバックの手順」

アップグレードの目的

一般に、アップグレード手順は、ソリューション全体で次の内容を目的としています。

設定が消失しないこと

データが消失しないこと

ネットワーク ダウンタイムが発生しないこと

サービス ダウンタイムが最少になるか、まったく発生しないこと

安全なロールバック

アップグレードのモジュール化

同等な機能

アップグレードの検証

これらの目的の一部は、インターフェイスの互換性を維持することによって達成されます。たとえば、CSV ファイル、RDR、DB スキーム、および CLI(コマンドライン インターフェイス)は互換性を維持します。プログラミング可能なインターフェイスは、スタティック C リンキングに対してバイナリの互換性またはインターフェイスの互換性を維持します。

すべての要件が、ソリューションの各観点に一致するとは限りません。これらの目的に対する制約事項は、次のセクションおよび関連するコンポーネントのマニュアルで言及します。

サポート対象の動作設定

SCA BB 3.1 ソリューションは、次のコンポーネントのバージョンの組み合わせをサポートしています。

SCOS 3.1

アプリケーション ― SCA BB 3.1(SCE プラットフォームおよび SCMS-SM にインストールするための PQI)

SCMS-SM 3.1(SM が構成に必要な場合)

SCMS-CM 3.1 または 3.0(CM が構成に必要な場合)

このマニュアルでは、SM および CM を含むシステムのアップグレードを取り扱います。これらのコンポーネントのいずれか、または両方が必要ない場合は、該当するセクションを省略できます。

SCE プラットフォーム

LIC の再焼き付けによるリンク ダウンタイム

3.0.0 からアップグレードする場合にのみ、SCE プラットフォームのアップグレード時にリンク ダウンタイムが発生します(LIC チップ ファームウェアが再焼き付けされます)。予想されるダウンタイムは、システムの自動ネゴシエーションの設定によって異なり、最大で 1 分になります。

アップグレード完了前に開始されたフローの分類ミス

アップグレードが完了する前に開始されたフローの分類は、誤っている可能性があります。SCE ソフトウェアのアップグレードが完了したとき、またはスタンバイ SCE がアクティブになったときには、分類が次第に復元されます。この再分類が必要なのは、フローの以前の分類判別情報が失われるためです。正確な分類はフローの最初の分析によって決まるので、再分類は誤っている場合が多くなります。そのため、対応する Generic または Behavioral シグニチャに応じて、通常、フローが再分類されます。このダウンタイムは、再分類されたこれらのすべてのフローが閉じたときに終了します。

サービス ダウンタイム

サービス ダウンタイムは、非ハイ アベイラビリティ設定およびハイ アベイラビリティ設定での SCE プラットフォームのアップグレード時に発生します。

非ハイ アベイラビリティ設定では、SCE プラットフォームは、アップグレード時にトラフィックの分類、レポート、および制御を実行しません。これらの機能は、アップグレードの完了後に復元されます(アップグレードが完了する前に開始されたトラフィック フローが誤って分類されるため、復元は段階的なものです)。詳細については、「アップグレード完了前に開始されたフローの分類ミス」を参照してください。

ハイ アベイラビリティ設定では、カスケード接続された SCE プラットフォームがアップグレード時に代替として機能するためサービス ダウンタイムは発生しません。ただし、アップグレードが完了する前に開始されたトラフィック フローが誤って分類されるために SCE プラットフォームを切り替えるときの段階的なサービスの構築の場合を除きます。詳細については、「アップグレード完了前に開始されたフローの分類ミス」を参照してください。

集約された未報告データの消失

SCE プラットフォームのアップグレード時、収集システムに未報告の SCE プラットフォームが保有しているサブスクライバ クォータおよび使用状況の情報が失われます。システム データのエクスポート頻度に応じて(あらゆる RDR の間隔を通じて設定可能)、このような情報の量を最小限に抑えられます。

これは、ハイ アベイラビリティ構成においても同様です。

設定の消失

カテゴリに対する RDR タグの非デフォルトの割り当ては、アップグレード時に失われます。デフォルトのマッピングは、アップグレード後に復元されます。非デフォルトの割り当てが行われた場合、アップグレード後に手動で再設定する必要があります。

SCA BB クライアントとサービス設定

Service Configuration Editor、SM GUI、および Reporter を内蔵した SCA BB Console は、下位互換性がなく、3.1 システム コンポーネント(SCE プラットフォーム、CM、SM)とのみ連動します。

SCA BB Console の相互運用性

Network Navigator のバージョン 3.1 は、サービス設定をバージョン 3.0 の SCE プラットフォームに適用できません。ただし、Network Navigator 3.1 は SCE を 3.1 にアップグレードしてから、サービス設定を適用することが可能です。

サービス設定のアップグレード

アップグレードされたシステムに適用する前に、古いサービス設定ファイルを SCA BB 3.1 に順応させる必要があります。次の 2 つの方法のいずれかで実装できます。

SCA BB 3.1 の Service Configuration Editor を使用してサービス設定を再実装します。

SCA BB 3.1 Service Configuration Editor で開いて、古いコンフィギュレーションを SCA BB 3.1 セマンティックに移植します。この場合、デフォルトの 3.1 設定の SCA BB ユーザ ガイドの説明に従って、3.1 の拡張機能の組み合わせを許可することを推奨します。

ユーザ定義のシグニチャ

Signature Editor に DSS を作成し、プロトコル パックをインストールする場合、次の一般的な手順を実行して、DSS をプロトコル パックのシグニチャにマージする必要があります。

プロトコル パックから DSS を抽出します。

DSS を開き、プロトコル パックの DSS を Signature Editor にインポートして、重複したシグニチャ ID がないことを確認します。

マージした DSS を保存します。

Reporter および DB の相互運用性

3.0 に同じレポートが存在する場合は、3.1 の Reporter と Reporter Template を使用して、3.0 データベースからレポートを作成できます。ただし 3.1 で初めてのレポートは、3.0 データベースに接続する際に作成できません。

2 つの SCA BB Console または Reporter の実行

同じマシン上で異なるバージョンの 2 つの SCA BB Console または Reporter を実行することはサポートされていないので、実行しないでください。

Subscriber Manager

「アップグレード手順の制約事項」

「LEG の設定」

「Quota Manager」

アップグレード手順の制約事項

非ハイ アベイラビリティ構成の Subscriber Manager では、SM アップグレード手順によって、サブスクライバ プロビジョニングおよびサブスクライバ ステータス認識(LEG 通信)のダウンタイムが発生します。

LEG の設定

SM LEG の設定は、アップグレード時に失われます。関連するリファレンス ガイドの SM LEG のアップグレード手順に従ってください。

Quota Manager

Quota Manager(QM)がクラスタとして配置されていない場合、サービス ダウンタイムが発生します。これは、SM アップグレード時に発生するサービス ダウンタイムと同じです。

Collection Manager

「アップグレード手順の制約事項」

「設定」

アップグレード手順の制約事項

Collection Manager のアップグレードは、アップグレードされたマシンに対して処理中にダウンタイムを課します。データ収集のダウンタイムを避けるために、バンドル版の構成または非バンドル版の構成に対して、代替 Collection Manager を使用できます。

SCE プラットフォームでは、代替 Collection Manager への RDR の送信がサポートされています。

設定

3.0.5 または 3.0.6 から 3.1 に CM をアップグレードする場合、CM サーバ(PRPC ユーザ ファイル、prpc.usr)のユーザ設定が削除されます。アップグレードが完了したら、ユーザを再定義する必要があります。

ロールバックの手順

アップグレード プロセスが失敗した場合、またはサービスに障害が発生した場合に、ソフトウェアのロールバックが必要になることがあります。ソフトウェアのロールバックでは、以前のリリースにダウングレードして、ネットワークへの損害を軽減させる必要があります。

一般に、自動ダウングレード スクリプトはソリューション コンポーネントで使用できません。ダウングレードをイネーブルにするには、アップグレードする前に古いコンフィギュレーションをバックアップしておく必要があります。ダウングレードするには、各コンポーネントに対して旧リリースのクリーン インストレーションが必要です。


) SCE をダウングレードする場合、「PQI uninstall file」コマンドを使用して、最初に SCA BB PQI をアンインストールする必要があります。このコマンドを実行するには、新しい PQI ファイルが必要です。