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

目次

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

アップグレードの目的

サポート対象の動作設定

SCE プラットフォーム

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

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

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

サービスのダウンタイム

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

設定の消失

SCA BB クライアントおよびサービス設定

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

SCA BB Console の相互運用性

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

ユーザ定義シグニチャ

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

Subscriber Manager

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

互換性

SM で維持されないサブスクライバ クォータ

クォータ管理の互換性

API の互換性

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 を 1 つずつ含むシステムのアップグレードについて説明します。これらのコンポーネントのいずれか、または両方が不要な場合は、対応するセクションを省略できます。

SCE プラットフォーム

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

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

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

アップグレード完了前に開始されたフローは、誤って分類されることがあります。SCE ソフトウェア アップグレードが完了するか、またはスタンバイ SCE がアクティブになると、分類が次第に復元されます。この再分類が必要になるのは、フローの以前の分類判別情報が失われるためです。フローを正確に分類するにはフローの先頭を分析する必要があるため、通常、この再分類は不正確です。したがって、フローは対応する Generic または Behavioral シグニチャに従って、一般に再分類されます。再分類されたこれらのフローがすべて閉じると、ダウンタイムは終了します。

サービスのダウンタイム

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

非ハイ アベイラビリティ設定の場合、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 の相互運用性

バージョン 3.1 の Network Navigator は、バージョン 2.5 の 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 セマンティックに移植します。この場合は、SCA BB ユーザ ガイドに記載された 3.1 のデフォルト設定の説明に従って、3.1 の拡張機能を組み込むことを推奨します。

ユーザ定義シグニチャ

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

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

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

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

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

同じマシン上でバージョンの異なる 2 つの SCA BB Console または Reporter を実行することはできません。このような使用方法は回避してください。

Subscriber Manager

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

「互換性」

「LEG の設定」

「Quota Manager」

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

非ハイ アベイラビリティ構成の Subscriber Manager 設定の場合、SM アップグレード手順を実行すると、サブスクライバ プロビジョニングおよびサブスクライバ ステータス認識(LEG 通信)に関してダウンタイムが生じます。

SM に格納されたサブスクライバ クォータは、アップグレード中に失われます。詳細については、「クォータ管理の互換性」を参照してください。

ハイ アベイラビリティ構成の場合も、内部 TimesTen DB が 32 ビットから 64 ビット バージョンにアップグレードされるため、サービス ダウンタイムは発生します。

互換性

Subscriber Manager 3.1 は SCA BB 2.5 が稼働している SCE プラットフォームと連携できます。

SM ベースのクォータ API は廃止されていて、SCE Subscriber API に置き換わっています。したがって、SM 2.5 で機能するクォータ管理システムは、SM 3.1 と互換性がありません。このトピックの詳細については、「API の互換性」を参照してください。

「SM で維持されないサブスクライバ クォータ」

「クォータ管理の互換性」

「API の互換性」

SM で維持されないサブスクライバ クォータ

サブスクライバ クォータ(ステート プリザベーション)は、サブスクライバがネットワークにログインしていない期間中は、SM に保持されません。つまり、SM に残っているクォータ情報は、アップグレード プロセス中に失われます。これは、使用しているポリシーが外部クォータ ベースであるか、あるいは内部クォータ ベースであるかに関係なく、適用されます。

外部クォータ プロビジョニングを統合する場合は、適切な対策をとって、アップグレード前に外部ポリシー サーバにクォータ情報を保持し、サブスクライバ クォータ状態が失われないようにする必要があります。クォータ情報は SCE プラットフォームから定期的に、またはサブスクライバのログアウト時に報告されます。

クォータ管理の互換性

リリース 3.0 には、外部サーバで実行されるクォータ処理および内部で管理されるクォータに対応した、新しいアーキテクチャが導入されました。

この新しいアーキテクチャにより、リリース 2.5で使用されるクォータ管理方式が一部変更されました。アップグレード手順を実行する前および実行中に、この変更内容に注意し、解決しておく必要があります。

SM ベース クォータ API がダイレクト SCE API で置き換えられています。

ログアウトしたサブスクライバのクォータ プリザベーション(ステート プリザベーションともいう)は、SM で使用できません。

これらの変更により、SCE プラットフォームと統合された既存のクォータ管理システムが変更されます。アップグレード手順の実行中は特に注意してください。

API の互換性

SM ベースの QP API は廃止されていて、SCE Subscriber API に置き換わっています。古い API を使用する外部コンポーネントは、新しい API に移行する必要があります。

新しい API の主要機能は、次のとおりです。

SM を経由しないで、直接、SCE プラットフォームに接続します。

クォータ割り当て処理およびクォータ状態通知にアクセスできるようにします。RDR リスナーを実装する必要はありません。

SM ベース QP API と異なり、SCE Subscriber API では、すべての処理で SCE プラットフォームにアクティブなサブスクライバがいることが前提となります。

サブスクライバの存在 -- クォータ処理を正常に実行するには、API が呼び出される特定の SCE 上に、サブスクライバが存在している必要があります。サブスクライバがアクティブでない場合、SM はクォータ処理のプロキシを行いません。

セッション間クォータの非永続性 -- サブスクライバのログアウト イベントが発生すると、残存クォータがポリシー サーバにフラッシュされるため、次にサブスクライバがログインするときに再プロビジョニングする必要があります。サブスクライバ セッション間で、クォータは SM に保持されません。

この段階で、新しい API は Java でのみ提供されています。C/C++ では提供されていません。

詳細については、『 Cisco SCMS SCE Subscriber API Programmer's Guide 』を参照してください。

LEG の設定

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

Quota Manager

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

Collection Manager

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

「互換性」

「データ マイグレーション」

「設定」

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

CM を 2.5 から 3.1 にアップグレードする場合は、アップグレード スクリプトを使用できません。この場合は、3.1 CM のクリーン インストールを実行する必要があります。

クリーン インストール期間中は、3.1 にアップグレードしているマシンにダウンタイムが生じます。データ収集のダウンタイムを回避するには、(バンドル版の構成または非バンドル版の構成で)代替の Collection Manager を使用してください。

SCE プラットフォームでは、代替 Collection Manager に RDR を送信することができます。

互換性

Collection Manager 3.1 が連携できるのは、SCA BB 3.0 または 3.1 が稼働している SCE プラットフォームのみです。SCA BB 2.5 が稼働している SCE プラットフォームを段階的にアップグレードしている間にレポートを継続するには(CM のアップグレード後にリリース 2.5 からデータを収集するには)、2 つの独立した Collection Manager を使用する必要があります(リリース 2.5 が稼働している CM と、SCA BB 3.1 が稼働している CM)。

データ マイグレーション

「データベースの移行」

「その他のデータの移行」

データベースの移行

CM マシンでバンドル版のデータベースが稼働している場合は、付属のスクリプトを使用して、必要に応じてアップグレードすることができます。アップグレード後に収集されたデータは一連の新しいテーブルに保存され、2.5 リリース データは別のテーブルに保持されます。古いテーブルにアクセスするには、変更された一連の SCA Reporter テンプレートを使用します。これらのテンプレートを変更するためのスクリプトが用意されています。

非バンドル版の場合は、シスコが提供する新しいテーブル構造に基づく新しいフォーマットにデータを移行することができます。この移行を行うかどうかは、必要性に応じて、およびご使用のデータベース構造や使用可能なデータベース マシンに応じて判断します。

その他のデータの移行

CM には、次に示すその他の情報が保持されることもあります。

集約されたサブスクライバ使用率レコード(CSV)

未加工の RDR ファイル(CSV)

RAG Adapter 出力(CSV、DB)

ほとんどの出力形式で、データを統合する必要はありません。データ統合が必要な出力形式がある場合は、シスコ社にお問い合わせください。

設定

CM 設定(.conf および xml ファイル)は、アップグレード プロセス中にデフォルト値にリセットされます。アップグレード後も既存設定を保持するには、設定をバックアップし、アップグレード後に復元する必要があります。

ロールバック手順

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

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


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