Cisco Service Control SCA BB 3.6.x へのアップグレード ガイド
目次
Cisco Service Control SCA BB 3.6.x へのアップグレード ガイド
バージョン 3.0.x または 3.1.x からバージョン 3.6.0 へのアップグレード
SCA BB Service Configuration Utility のアップグレード方法
Collection Manager をバージョン 3.6.0 にアップグレードする方法
SCA BB クライアントおよびサービス コンフィギュレーション
概要
バージョン 3.0.x または 3.1.x からバージョン 3.6.0 へのアップグレード
このマニュアルでは、Cisco Service Control ソリューションをバージョン 3.0.x または 3.1.x からバージョン 3.6.0 にアップグレードする手順について説明します。次の 4 つのコンポーネントについて別々にアップグレード手順を説明します。
•
Service Control Application for Broadband（SCA BB）
この手順では、アップグレード手順中に Service Control 構成が機能し続ける必要があるシナリオについて説明します。この場合、SCA BB 3.0 と SCA BB 3.1 が稼動している SCE プラットフォームが同時に運用されます（同じ CM サーバと SM サーバを使用します）。
この手順では、いくつかの制約事項（以前の項を参照）はありますが、（アップグレード プロセスにかかる時間が長いにしても）サービス ダウンタイムは最小限に抑えられます。
b. （任意）SCA BB Service Configuration Utility バージョン 3.6.0（ servconf ）を空のディレクトリにインストールします。
ステップ 2 「Subscriber Manager のアップグレード」 で説明される手順に従って SM（あるいは SM クラスタ）をアップグレードします。
スタンバイとして認識される SCE は、SM で スタンドアローン として設定されていたとしてもアップデートされません。
（注） SM が正しく設定されていなければ、SCE をアップデートできません。
ステップ 3 3.6.0 を稼動している新しい CM を配置します。 「Collection Manager のアップグレード」 を参照してください。
•移行フェーズ用に追加の CM およびデータベースを配置した場合（バンドル版の構成であるかどうかに関係なく、合計 2 つの CM データベース が存在する場合）、すべての SCE プラットフォーム（旧バージョンと 3.6.0 の両方）で収集が有効になります。 非バンドル版のデータベース に関してはこれを行う方法がいくつかあります。非バンドル版のデータベースを使用する場合は、DB の専門家に相談することを推奨します。
•各 CM は単一のバージョンから Raw Data Report（RDR）を収集し、個別のデータベース（バンドル版または非バンドル版）および CSV リポジトリに格納します。
ステップ 4 SCE Software Upgrade Wizard を使用して SCE プラットフォーム ソフトウェアをアップグレードします。
•アップグレードされた SCE プラットフォームの RDR が、バージョン 3.6.0 が稼動している CM に転送されることを確認してください。（収集の観点からの）サービス ダウンタイムは、実装された CM 構成（アップグレード中に単独か二重か）に応じて異なります。
この時点で、ソリューション全体のアップグレードが完了し、完全に動作する状態になります。
ステップ 5 すべての SCE プラットフォームのアップグレードが完了したら、以前のバージョンが稼動している CM を（それを使用していた場合は）削除します。
サポート対象の動作設定
SCA BB リリース 3.6.0 では、次に示すコンポーネント バージョンの組み合わせをサポートしています。
• アプリケーション：SCA BB 3.6.0（SCE プラットフォーム上にインストールするための PQI）
（注） なお、このマニュアルでは、SM および CM を 1 つずつ含むシステムのアップグレードについて説明します。これらのコンポーネントのいずれか、または両方が不要な場合は、対応する部分の説明を無視できます。
ロールバック手順
アップグレード プロセスに失敗した場合、またはサービスに障害が発生した場合、ソフトウェア ロールバックが必要になることがあります。ソフトウェア ロールバックでは、ネットワークへの損害を軽減するために、以前のリリースへのダウングレードが必要になります。
一般に、ソリューション コンポーネントには自動のダウングレード スクリプトは用意されていません。ダウングレードを可能にするには、アップグレードを行う前に元の設定をバックアップしておく必要があります。ダウングレードするには、コンポーネントごとに旧リリースをクリーン インストールする必要があります。
（注） SCE をダウングレードする場合は、PQI uninstall file コマンドを使用して、最初に SCA BB PQI をアンインストールする必要があります。このコマンドを実行するには、新しい PQI ファイルが必要です。
SCA BB のアップグレード
この章では、機能している SCA BB 3.0.x または 3.1.x 構成を SCA BB 3.6.0 にアップグレードする手順について詳細に説明します。
SCA BB のアップグレード
SCA BB のアップグレードは、次の 2 つのステップからなります。
SCA BB Service Configuration Utility のアップグレード方法
ステップ 1 SCA BB インストレーション パッケージからファイル scas_bb_util.tgz を取り出して Windows、Solaris、または Linux ワークステーションにコピーします。
ステップ 2 コピーしたファイルを新しいフォルダに展開します。
SCA BB Service Configuration Utility（ servconf ）、SCA BB Real-Time Monitoring Configuration Utility（ rtmcmd ）、関連するリアルタイム モニタリング レポート テンプレート、および SCA BB Signature Configuration Utility（ sigconf ）は、bin フォルダに配置されます。
Subscriber Manager のアップグレード
この章では、Cisco Service Control Management Suite Subscriber Manager（SCMS SM）をアップグレードする方法について説明します。
配布ファイルの内容
SCMS SM コンポーネントは、3 つの配布ファイルで提供されます。
各配布ファイルは、tar 形式のファイルとして提供されます。提供ファイルは、gzip で圧縮されており、拡張子は .tar.gz です。詳細については『 Cisco Service Control Management Suite Subscriber Manager User Guide 』の「Installing and Upgrading」の章を参照してください。
Subscriber Manager のアップグレード
Subscriber Manager は、前にインストールした SM のバージョンおよび新しいインストールにおけるフェールオーバーの要件（あるいは要件なし）に応じて、数種類のアップグレード手順に対応しています。
データ複製手順
データ複製手順では、データベース全体を特定のマシンから別のマシンに複製できます。最後に複製エージェントを起動することにより、データベースの同期を維持することが可能になります。一部のアップグレード手順では、この手順が使用されます。
この手順の詳細については、『 Cisco Service Control Management Suite Subscriber Manager User Guide 』の「Database Duplication Recovery」の項を参照してください。
VLAN マッピングによる加入者の自動アップグレード
Virtual LAN（VLAN; バーチャル LAN）マッピングは、加入者ではなく Virtual Private Network（VPN; バーチャル プライベート ネットワーク）に関係付けられました。アップグレード手順中、SM により、加入者の VLAN-ID を持つ VPN が自動的に作成され、加入者はその新しい VPN について全範囲の IP マッピングと関連付けられます。
たとえば、加入者 sub1 が VLAN-ID=15 を持つ場合、VLAN-ID=15 の VPN 15 およびマッピング 0.0.0.0/0@VLAN-ID の加入者 sub1 が作成されます。
RADIUS リスナーの自動アップグレード
アップグレード手順中、SM によって、コンフィギュレーション ファイル内の RADIUS セクションが次の規則に従って修正されます。
• radius_attribute プロパティと radius_attribute_type プロパティは新しいセクションに移動される。
• 新しいフィールド プロパティが追加され、 radius_attribute プロパティおよび radius_attribute_type プロパティと置き換わる。
• strip_type=remove_suffix プロパティは field_manipulation.<field name>=(.*)<strip_character >.* に置き換えられる。
• strip_type=remove_suffix プロパティは field_manipulation.<field name>=.*<strip_character >(.*) に置き換えられる。
• use_default プロパティとデフォルト値は mapping_table.^$=<default> に置き換えられる。
• radius_attribute_vendor_id プロパティと radius_sub_attribute プロパティは形式 radius_attribute に置き換えられる。
必要なメモリ量の設定
SM をアップグレードするための準備として、SM 上のシステム カーネル コンフィギュレーション ファイルを設定します。
TimesTen では、次のオペレーティング システムのカーネル コンフィギュレーション ファイルにおいて特定の修正を行う必要があります。
• Solaris の場合、ファイル /etc/system を修正します。
• Linux の場合、ファイル /etc/sysctl.conf を修正します。
これらの変更により、Solaris マシン上での共有メモリとセマフォのリソースをデフォルトより増やします。これらの変更に関する詳細については、 TimesTen のマニュアルを参照してください。
（注） tt-sysconf.sh スクリプトを実行すると、現在の /etc/system または /etc/sysctl.conf ファイルの設定は、「必要な変更を手動で行う方法」の手順に示されている値で上書きされます。そのため、このスクリプトを実行する前に、ファイルに設定されている内容を確認することを推奨します。現在のファイルの設定の一部またはすべてを残す必要がある場合は、そのシステム コンフィギュレーション ファイルを編集して変更を手動で行ってください。
• 必要な変更を自動で行うには、 tt-sysconf.sh スクリプトを実行します。
このスクリプト ファイルは、root ユーザが引数なしで次のように呼び出す必要があります。
（注） SM において 100,000 を超える加入者のサポートが必要な場合、コンフィギュレーション ファイルを手動で編集する必要があります。ご使用のシステムのサイジング要件は、共有メモリのサイズにだけ影響します。ご使用のシステムに対して正しい設定値を決定するには、『Cisco Service Control Management Suite Subscriber Manager User Guide』の「Installation and Upgrading」の章の表 4-6 ～ 4-9 を参照してください。
– Solaris の場合、次の行を /etc/system ファイルに追加して共有メモリ サイズを設定することにより、必要な変更を手動で行います。
set semsys:seminfo_semmni = 20
set semsys:seminfo_semmsl = 100
set semsys:seminfo_semmns = 2000
set semsys:seminfo_semmnu = 2000
set shmsys:shminfo_shmmax = 0x20000000
*---- End of settings for TimesTen
– Linux の場合、次の行を /etc/sysctl.conf ファイルに追加して共有メモリ サイズを設定することにより、必要な変更を手動で行います。
スタンドアローン構成のアップグレード方法
このアップグレード手順では、サービス ダウンタイムが発生します。
（注） スタンドアローン構成からクラスタ構成へのアップグレード手順については、「スタンドアローン構成からクラスタ構成へのアップグレード」を参照してください。
SM をアップグレードする前に、配布ファイルをロードし、そのファイルをインストール対象のマシン上またはそのマシンがマウントされているディレクトリ内に展開する必要があります。
a. 配布ファイルを Cisco.com からダウンロードします。
b. FTP を使用して配布ファイルを SM にロードします。
c. gunzip コマンドを使用して配布ファイルを解凍します。
d. tar コマンドを使用して tar ファイルを展開します。
ステップ 2 install-def-cfg ファイルを編集します。
install-def.cfg コンフィギュレーション ファイルを編集し、 PermSize パラメータと TempSize パラメータを付録 A に示された推奨値に従って設定します。詳細については、 「必要なメモリ量の設定」 を参照してください。
ステップ 3 upgrade-sm.sh スクリプトを実行します。
SM ディストリビューションでは、非クラスタ構成からアップグレードするために、以前のバージョンからのアップグレードを実施するアップグレード スクリプトを提供しています。このアップグレード手順スクリプトは、加入者データベースおよび SM 設定全体（ネットワーク要素、ドメイン、アプリケーション特有のコンポーネントなど）を維持します。
（注） Solaris の場合：Solaris 上の以前のバージョンの SM は、32 ビットまたは 64 ビットの Java Virtual Machine（JVM）およびデータベースを使用しました。現在の SM は、64 ビットの JVM およびデータベースでインストールされます。64 ビットにアップグレードするかどうかの選択はありません。
（注） Linux の場合：Linux プラットフォームは、32 ビットの JVM およびデータベースでだけ使用されます。
（注） /etc/motd ファイルが存在すると、このスクリプトを実行できません。upgrade-sm.sh スクリプトを実行する前に、このファイルを移動または削除する必要があります。
ワークステーションのシェル プロンプトから、 upgrade-sm.sh スクリプトを実行します。
ステップ 4 Proprietary Remote Procedure Call（PRPC）認証用のユーザを追加します。
SM を 3.0.5 よりも前のバージョンからアップグレードする場合、SCA BB を SM と接続するときにユーザ名とパスワードが必要になるため、PRPC 認証用のユーザを追加する必要があります。
PRPC 認証用のユーザを追加するには、 p3rpc Command-Line Utility（CLU）を使用します。たとえば次のように入力します。
カスケード SCE 構成を使用する場合、『 Cisco Service Control Management Suite Subscriber Manager User Guide 』の付録「Configuration File Options」にある「SCE.XXX」の項の説明に従って p3sm.cfg ファイルにカスケード SCE ペアを設定します。
スタンドアローン構成からクラスタ構成へのアップグレード
この項では、スタンドアローン構成からクラスタ構成へアップグレードするための基本的な手順について説明します。このアップグレード手順では、サービス ダウンタイムが発生します。
（注） この手順では、SM のダウンタイムを可能な限り短くするようになっています。そのため、加入者サービスが問題にならない場合は、新しいマシンをインストールし、新しいマシンをアップグレードする手順を代わりに使用してください。
次の手順では、SM-A は元の SM マシン、SM-B は冗長性を与えるために追加される新しい SM マシンです。
ステップ 1 Veritas Cluster Server（VCS）を両方のマシンにインストールします。
SM-B をインストールするには、『 Cisco Service Control Product Installation Guide 』の「Installing the Subscriber Manager」の項で説明される手順に従ってください。
SM-A をアップグレードするには、 「スタンドアローン構成のアップグレード方法」 で説明される手順に従ってください。
（注） このステップ以降は、アップグレード手順が完了するまでの間、加入者を処理する SM は存在しません。
ステップ 4 SM 設定を SM-A から SM-B に複製します（~pcube/sm/server/root/config フォルダからすべてのコンフィギュレーション ファイルをコピーします）。
p3sm.cfg コンフィギュレーション ファイルを手動で SM-A から SM-B にコピーし、次の CLU コマンドを使用してコンフィギュレーション ファイルをロードします。
データ複製手順については、 「データ複製手順」 を参照してください。
冗長マシンへのデータ ストア複製のための複製方式を設定します。
（注） この CLU は、両方のマシン上で、ユーザ pcube として稼動する必要があります。
a. クラスタをサポートするように、SM-A と SM-B の両方を設定します。
各マシン上で、 p3sm.cfg コンフィギュレーション ファイルを任意の標準的なテキスト エディタで開き、 [SM High Availability Setup] セクションに topology=cluster を設定します。
更新したコンフィギュレーション ファイルを次の CLU コマンドを使用してロードします。
CLU コマンド p3cluster --standby を使用します。
CLU コマンド p3cluster --active を使用します。
ステップ 7 ログインをクラスタの仮想 IP に送信するように、LEG アプリケーションを設定します。
クラスタ構成のアップグレード
この項では、クラスタ構成からクラスタ構成へアップグレードするための基本的な手順について説明します。
（注） この手順では、サービス ダウンタイムは発生しません。
クラスタ構成からアップグレードするときのアップグレード手順には、大きく分けて 3 つのステップがあります。
1. スタンバイ マシン上でアップグレード手順を実行します。
2. アップグレードした SM 上で手動のフェールオーバーを実行します。
3. フェールオーバーを実行した後にスタンバイになった SM 上でアップグレード手順を実行します。
ステップ 1 システム カーネル コンフィギュレーション ファイルを両方のマシン上で設定します。
アップグレード手順を開始する前に、両方のマシン上でシステム カーネル コンフィギュレーション ファイルを設定する必要があります。
a. システム カーネル コンフィギュレーション ファイルを スタンバイ SM 上で設定します。
設定手順については、 「必要なメモリ量の設定」 を参照してください。
c. Veritas クラスタ マネージャを使用してフェールオーバーを手動で引き起こし、スタンバイ SM がアクティブになり、アクティブ SM がスタンバイになるまで待ちます。
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを実行します。
# hagrp -switch service group name to System
d. 新しい スタンバイ SM 上でステップ a とステップ b を繰り返します。
SM をアップグレードする前に、配布ファイルをロードし、そのファイルをインストール対象のマシン上またはそのマシンがマウントされているディレクトリ内に展開する必要があります。
a. 配布ファイルを Cisco.com からダウンロードします。
b. FTP を使用して配布ファイルを SM にロードします。
c. gunzip コマンドを使用して配布ファイルを解凍します。
gunzip SM_dist_<version>_B<build number>.tar.gz
d. tar コマンドを使用して tar ファイルを展開します。
tar -xvf SM_dist_<version>_B<build number>.tar
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを使用して、VCS モニタリングを停止します。
ステップ 4 install-def.cfg ファイルを編集します。
install-def-cfg コンフィギュレーション ファイルを編集し、PermSize パラメータと TempSize パラメータを 「必要なメモリ量の設定」 に示された推奨値に従って設定します。詳細については、『 Cisco Service Control Product Installation Guide 』の「Installing the Subscriber Manager」の項を参照してください。
（注） 最初の SM マシンをアップグレードするときにだけ、次のコマンドを実行します。
a. アクティブ マシン上で、配布ファイルを展開したディレクトリに移動します。
b. スクリプト ディレクトリにある p3db --rep-pause CLU を実行します。
c. スクリプト ディレクトリにある p3db --rep-status CLU を実行し、複製が 一時停止（pause） ステートであることを確認します。
ステップ 6 cluster-upgrade.sh スクリプトを実行します。
SM では、クラスタ構成からクラスタ構成へアップグレードするために、以前のバージョンからのアップグレードを実行するアップグレード スクリプトを提供しています。このアップグレード スクリプトは、加入者データベースおよび SM 設定全体（ネットワーク要素、ドメイン、アプリケーション特有のコンポーネントなど）を維持します。
（注） Solaris の場合：Solaris 上の以前のバージョンの SM は、32 ビットまたは 64 ビットの Java Virtual Machine（JVM）およびデータベースを使用しました。SM バージョン 3.0.3 以降、SM は、64 ビットの JVM およびデータベースでインストールされます。64 ビットにアップグレードするかどうかの選択はありません。
（注） Linux の場合：Linux プラットフォームは、32 ビットの JVM およびデータベースでだけ使用されます。
スタンバイ マシンのシェル プロンプトから、 cluster-upgrade.sh スクリプトを実行します。
表 1 に、コマンド オプションの一覧を示します。
cluster-upgrade.sh を実行した後は、SM を起動しないでください。
ステップ 7 cluster-upgrade.sh スクリプトが終了するまで待ちます。
a. アクティブ マシン上で、配布ファイルを展開したディレクトリに移動します。
b. スクリプト ディレクトリにある p3db --rep-continue CLU を実行します。
c. スクリプト ディレクトリにある p3db --rep-status CLU を実行し、複製が「開始（start）」ステートであることを確認します。
（注） このコマンドは、最初のマシンをアップグレードするときにだけ、ステップ 5 を実行した場合に限り実行します。
ステップ 9 変更されたデータが複製されていることを確認します。
•アクティブな SM 上で、 p3subs CLU を使用してダミーの加入者を追加します。
（注） 2 つめの SM のアップグレード時には、最初の SM のアップグレード時に dummySub が複製によって追加されているため、それ以外の名前で加入者を追加します。
•スタンバイ SM 上で、 verify-subscriber.sh スクリプトを実行して、加入者が複製されたことを確認します。
#./verify-subscriber.sh dummySub
（注） verify-subscriber.sh スクリプトは、root ユーザとして実行する必要があります。
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを実行します。
VCS モニタリングにより、SM プロセスが初期化ステートで自動的に起動されます。
この SM をスタンバイ ステートに設定するために、 p3cluster CLU を使用します。
（注） アップグレード後の SM の起動時間は、データベース インデックスを初期化するために追加の時間がかかるため、通常よりも長くなります。
ステップ 11 Veritas クラスタ マネージャを使用してフェールオーバーを手動で引き起こし、スタンバイ SM がアクティブになり、アクティブ SM がスタンバイになるまで待ちます。
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを実行します。
hagrp CLU の詳細については、お手持ちの Veritas Cluster Server のマニュアルを参照してください。
手動のフェールオーバーを実行した後、アップグレード手順を実行しているスタンバイ SM が、アクティブ SM になります。前のアクティブ SM は、新しいスタンバイ SM になります。
ステップ 12 スタンバイ SM 上でアップグレード手順を繰り返します。
2 つめの SM をアップグレードするために、 ステップ 2 から ステップ 10 までの手順を繰り返します。
（注） 2 つめの SM をアップグレードする場合は、ステップ 5 またはステップ 8 は実行しません。
ステップ 13 データベース複製プロトコル バージョンをアップグレードします。
（注） 以下のコマンドは、admin ユーザとして実行する必要があります。これらのコマンドを両方のマシン上で実行して、データベース複製プロトコル バージョンをアップグレードします。
この操作は、両方の SM をアップグレードした後に行う必要があります。
a. スタンバイ SM の VCS モニタリングを停止します。
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを使用します。
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを実行します。
VCS モニタリングにより、SM プロセスが初期化ステートで自動的に起動されます。
d. p3cluster CLU コマンドを使用して、この SM をスタンバイ ステートに設定します。
e. Veritas クラスタ マネージャを使用してフェールオーバーを手動で引き起こし、スタンバイ SM がアクティブになり、アクティブ SM がスタンバイになるまで待ちます。
/opt/VRTSvcs/bin にある次の VCS CLU コマンドを実行します。
# hagrp -switch service group name -to System
hagrp CLU の詳細については、お手持ちの Veritas Cluster Server のマニュアルを参照してください。
f. スタンバイ SM 上でアップグレード手順を繰り返します。
SM を 3.0.5 よりも前のバージョンからアップグレードする場合、SCA BB を SM と接続するときにユーザ名とパスワードが必要になるため、PRPC 認証用のユーザを追加する必要があります。
PRPC 認証用のユーザを追加するには、 p3rpc Command-Line Utility（CLU）を使用します。たとえば次のように入力します。
カスケード SCE 構成を使用する場合、『 Cisco Service Control Management Suite Subscriber Manager User Guide 』の「Configuration File Options」にある「SCE.XXX」の項の説明に従って p3sm.cfg ファイルにカスケード SCE ペアを設定します。
両方の SM のアップグレードに成功した後、アップグレード時に複製の検証用に追加したダミーの加入者を削除します。
新しい アクティブ SM 上で、次の CLU を実行します。
Subscriber Manager のダウングレード方法
この項では、SM を以前のバージョンにダウングレードする手順について説明します。
ステップ 1 『 Cisco Service Control Management Suite Subscriber Manager User Guide 』の「Installing and Upgrading」の章にある「How to Uninstall the Subscriber Manager」の項で説明されるアンインストール手順を実行します。
ステップ 2 『 Cisco Service Control Product Installation Guide 』の「Installing the Subscriber Manager」の項で説明されるインストール手順を実行します。
（注） upgrade-sm.sh および cluster-upgrade.sh アップグレード スクリプトは、SM のダウングレードをサポートしていません。
Collection Manager のアップグレード
この章では、CM をアップグレードするための手順について説明します。
システム全体をアップグレードする場合、新しいバージョンを稼動している別の CM をインストールした後、以前のバージョンを稼動している CM を単純にアンインストールすることを推奨します。それにより、新しいバージョンへシームレスに移行できます。この場合、CM 上で実行するアップグレード手順はありません。
CM をインストールする場合は、『 Cisco Service Control Product Installation Guide 』の「Installing the Collection Manager」の項を参照してください。
Collection Manager をバージョン 3.6.0 にアップグレードする方法
ステップ 1 『 Cisco Service Control Management Suite Collection Manager Quick Start Guide 』の説明に従って CM ソフトウェアを取得します。
ステップ 2 ディストリビューション キットのルートにある install-scripts ディレクトリに移動します。
ステップ 3 scmscm ユーザで、CM サーバを停止します。
ステップ 4 root ユーザで、 install-cm.sh スクリプトを実行します。
ステップ 5 scmscm ユーザで、CM サーバを起動します。
（注） バージョン 3.0.5 または 3.0.6 からアップグレードすると、PRPC ユーザ ファイルは削除されます。CM にログインし、PRPC ユーザを定義し直す必要があります。
SCE プラットフォーム ソフトウェアのアップグレード
この章では、SCE プラットフォーム ソフトウェアをアップグレードするウィザードについて説明します。
コンソールの SCE Software Upgrade Wizard により、1 台以上の SCE プラットフォーム上でソフトウェア アップグレードを実行します。このウィザードでは、次の内容を選択できます。
始める前に
SCE プラットフォームのアップグレードを始める前に、次のことを行います。
• アップグレードするすべての SCE プラットフォームの IP アドレスを収集する（Network Navigator にすべて定義されている場合は不要です）。
• 関連する pkg ファイル、pqi ファイル、およびプロトコル パックをローカルな場所または FTP でアクセス可能な場所にダウンロードする。FTP サイトを使用する場合は、各ファイルの FTP ロケーションおよびパスが正しいことを確認してください。
– デフォルトのサービス コンフィギュレーション ：デフォルトの pqb ファイルが生成され、各 SCE プラットフォームに適用されます。
– 現在のサービス コンフィギュレーション ：アップグレードの前に現在のサービス コンフィギュレーションが取得され、アップグレード完了後に再適用されます。
SCE プラットフォーム ソフトウェアのアップグレード方法
ステップ 1 コンソールの Network Navigator で、アップグレードする SCE プラットフォームを選択します。右クリックし、メニューから [SCE Software Upgrade Wizard] を選択します（ 図 1 を参照）。
[SCE Software Upgrade Wizard] が開きます（ 図 2 を参照）。
図 2 [SCE Software Upgrade Wizard]：[SCE Software Upgrade] ウィンドウ
ステップ 2 [SCE IP Addresses] ウィンドウで、アップグレードするすべての SCE プラットフォームの IP アドレスが表示されていることを確認します。何も表示されない場合は、ウィンドウに IP アドレスを追加してください（ 図 3 を参照）。
図 3 [SCE Software Upgrade Wizard]：[SCE IP Addresses] ウィンドウ
ステップ 3 [SCE Usernames and Passwords] ウィンドウで、SCE プラットフォームにアクセスするために必要なユーザ名とパスワードを入力します。すべてのプラットフォームに同じユーザ名とパスワードを使用することも、プラットフォームごとに異なるユーザ名とパスワードを入力することもできます（ 図 4 を参照）。
図 4 [SCE Software Upgrade Wizard]：[SCE Usernames and Passwords] ウィンドウ
ステップ 4 [Connectivity Test] ウィンドウ（ 図 5 を参照）には、リスト上のすべての SCE プラットフォームに対する接続テストの結果が表示されます。このステップにより、すべての SCE プラットフォームがアップグレードのために接続できることを確認します。
図 5 [SCE Software Upgrade Wizard]：[Connectivity Test] ウィンドウ
ステップ 5 [SCE Firmware (PKG) Installation] ウィンドウ（ 図 6 を参照）で、すべての選択された SCE プラットフォームにインストールする PKG ファイルの場所を指定します。
図 6 [SCE Software Upgrade Wizard]：[SCE Firmware (PKG) Installation] ウィンドウ
ステップ 6 [SCE Application Software (PQI) Installation] ウィンドウ（ 図 7 を参照）で、選択したすべての SCE プラットフォームにインストールする pqi ファイルの場所を指定します。
図 7 [SCE Software Upgrade Wizard]：[SCE Application Software (PQI) Installation] ウィンドウ
ステップ 7 [Protocol Pack (SPQI) Update] ウィンドウ（ 図 8 を参照）で、選択したすべての SCE プラットフォームにインストールするプロトコル パックの場所を指定します。
（注） アップグレード中にインストールする Protocol Pack のバージョンは、アップグレードする Protocol Pack のバージョンと同じまたはそれ以降である必要があります。
図 8 [SCE Software Upgrade Wizard]：[Protocol Pack (SPQI) Update] ウィンドウ
ステップ 8 [Service Configuration (PQB) Update] ウィンドウ（ 図 9 を参照）で、SCE プラットフォームに適用するサービス コンフィギュレーションを選択します。
•現在のサービス コンフィギュレーション：ソフトウェア アップグレードの前に現在のサービス コンフィギュレーションが取得され、アップグレード完了後に再適用されます。
•デフォルトのサービス コンフィギュレーション：デフォルトの pqb ファイルが生成され、各 SCE プラットフォームに適用されます。
図 9 [SCE Software Upgrade Wizard]：[Service Configuration (PQB) Update] ウィンドウ
[SCE Software Upgrade] ウィンドウの [Connectivity Test] ウィンドウを開きます（ 図 10 を参照）。
（注） 1 つ以上のデバイスに対する接続を行えなかった、または、接続に何らかの問題（デバイスのバージョンが無効など）が発生した場合、デバイスの隣にエラーが表示されます。[Skip connectivity test] をクリックすると、テストを省略できます。ウィザードの最後で [Finish] をクリックすると接続が検証されます。
ステップ 10 [Summary Page] に、すべての情報がまとめて表示されます（ 図 11 を参照）。IP アドレスおよびファイルの場所がすべて正しいことを確認します。
•指定したとおりにアップグレード プロセスを開始する場合は、[Finish] をクリックします。
図 11 [SCE Software Upgrade Wizard]：[Summary Page] ウィンドウ
•指定された SCE プラットフォームの場所を、提供された IP アドレスで特定できること
•PKG ファイルまたは PQI ファイルがリモート FTP サーバに配置されている場合、その可用性を確認できること
•提供された認定証がすべての SCE プラットフォームに対して有効であること
•指定された PKG、PQI、PP および PQB のバージョンが適合すること
アップグレードしないコンポーネントがある場合（該当するファイルで [Skip] を選択した場合）、この確認のためにそれらのファイルのバージョンが SCE プラットフォームから取得されます。たとえば、PKG インストレーションのスキップを要求して PQI バージョン 3.6.0 をインストールすると、現在インストールされている PKG ファイルのバージョン情報が取得されます（これが SCOS 3.1.5 なら、エラーが報告されます）。
確認処理が完了すると、すべての問題とエラーのリストが表示されます。
アップグレード中に実行される基本的なステップは次のとおりです（すべてのコンポーネントがアップグレードされる場合）。
•現在のサービス コンフィギュレーションを SCE プラットフォームから取得する（現在のサービス コンフィギュレーションをアップグレード後に再インストールする場合だけ）。
•既存のアプリケーション ソフトウェア（PQI）をアンインストールする。
•SCE プラットフォーム ファームウェア（PKG）をアップグレードする。
•アプリケーション ソフトウェア（PQI）をインストールする。
指定した SCE プラットフォームのアップグレードは同時に実行され、SCE プラットフォームごとに別々のスレッドでアップグレード プロセスが稼動します。
ステップ 11 システムにより、アップグレードの進行状況が表示されます（ 図 12 を参照）。
[Run in Background] をクリックして、アップグレードをバックグラウンドで実行します。
図 12 [Main SCE Software Upgrade Task] ウィンドウ
アップグレードはバックグラウンドで実行されます（ 図 13 を参照）。
カスケード SCE プラットフォームのアップグレード
ハイ アベイラビリティ構成では、SCE プラットフォームの 1 つ（あるいは複数）のペアがカスケード構成でケーブル接続され、SCE プラットフォームの冗長性が実現されます。このタイプの構成では、アップグレード時に次の手順を実行する必要があります。
ステップ 1 1 台または複数台のスタンバイ SCE プラットフォームを [SCE Software Upgrade Wizard] で選択します。
ステップ 2 アップグレードが完了したら、すべてのアクティブ SCE プラットフォームで強制的に障害を発生させます。
これにより、更新された SCE プラットフォームがアクティブになり、新しいサービスの提供を開始します。
ステップ 3 [SCE Software Upgrade Wizard] を再度起動し、今度は残りの SCE プラットフォームを選択します。これらは最初にアクティブだったプラットフォームで、現在はスタンバイ SCE プラットフォームになっています。
ステップ 1 で使用したのと同じアップグレード ファイルを指定します。
この手順ではリブートが行われるので、 force failure コマンドを取り消す必要はありません。
アップグレード手順の制約事項
LIC の再焼き付けによるリンクのダウンタイム
SCE プラットフォームのアップグレード中は、リンクにダウンタイムが発生します（LIC チップ ファームウェアが再焼き付けされます）。予測されるダウンタイムは、システムの自動ネゴシエーション設定によって決まり、最大で 1 分かかることがあります。
アップグレード完了前に開始されたフローの分類ミス
アップグレード完了前に開始されたフローは、誤って分類されることがあります。SCE ソフトウェア アップグレードが完了するか、またはスタンバイ SCE がアクティブになると、分類が次第に復元されます。この再分類が必要になるのは、フローの以前の分類判別情報が失われるためです。フローを正確に分類するにはフローの先頭を分析する必要があるため、通常、この再分類は不正確です。したがって、フローは対応する Generic または Behavioral シグニチャに従って、一般に再分類されます。再分類されたこれらのフローがすべて閉じると、ダウンタイムは終了します。
サービスのダウンタイム
サービス ダウンタイムは、非ハイ アベイラビリティ構成およびハイ アベイラビリティ構成での SCE プラットフォームのアップグレード時に発生します。
• 非ハイ アベイラビリティ構成の場合、SCE プラットフォームのアップグレード中は、SCE プラットフォームによるトラフィックの分類、レポート、および制御は行われません。これらの機能は、アップグレードの完了後に回復します（アップグレードが完了する前に開始されたトラフィック フローの分類に誤りがあるため、徐々に回復します）。詳細については、 「アップグレード完了前に開始されたフローの分類ミス」 を参照してください。
• ハイ アベイラビリティ構成の場合、サービス ダウンタイムは発生しません（カスケード接続された SCE プラットフォームがアップグレード時に代わりに機能するため）。ただし、アップグレードが完了する前に開始されたトラフィック フローの分類に誤りが生じて、SCE プラットフォームの切り換え時にサービスが徐々に構築される場合は除きます。詳細については、 「アップグレード完了前に開始されたフローの分類ミス」 を参照してください。
集約された未報告データの消失
SCE プラットフォームに保持されていたサブスクライバ クォータおよび使用率情報のうち、収集システムに報告されなかったものは、SCE プラットフォームのアップグレード中に失われます。システム データのエクスポート頻度（全種類の RDR の間隔を使用して設定可能）に応じて、失われる情報量を最小限に抑えることができます。
設定の消失
RDR タグとカテゴリに関するデフォルト以外の割り当て情報は、アップグレード中に失われます。デフォルト マッピングは、アップグレード後に復元されます。デフォルト以外の割り当てを行った場合は、アップグレード後に手動で再設定する必要があります。
SCA BB クライアントおよびサービス コンフィギュレーション
SCA BB Console（サービス コンフィギュレーション エディタ、SM GUI、および Reporter を内蔵）は、下位互換性がありません。そのため、3.6.0 システム コンポーネント（SCE プラットフォーム、CM、SM）とだけ連携できます。
SCA BB Console の相互運用性
バージョン 3.6.0 の Network Navigator は、以前のバージョンの SCE プラットフォームにサービス コンフィギュレーションを適用できません。ただし、Network Navigator 3.6.0 で SCE プラットフォームを 3.6.0 にアップグレードしてから、サービス コンフィギュレーションを適用することができます。
Reporter および DB の相互運用性
3.6.0 の Reporter and Reporter Templates を使用して以前のバージョンのデータベースからレポートを作成することは、同じレポートが以前のバージョンにも存在していた場合はできます。しかし、3.6.0 で新たに追加されたレポートは、以前のバージョンのデータベースを接続しているときには作成できません。
2 つの SCA BB Console または Reporter の実行
同じマシン上でバージョンの異なる 2 つの SCA BB Console または Reporter を実行することはできません。このような使用方法は避けてください。
Subscriber Manager
非ハイ アベイラビリティの Subscriber Manager 構成の場合、SM アップグレード手順を実行すると、サブスクライバ プロビジョニングおよびサブスクライバ ステータス認識（LEG 通信）に関してダウンタイムが生じます。
Quota Manager
Quota Manager（QM）がクラスタとして配置されていない場合は、サービスにダウンタイムが生じます。これは、SM アップグレード中に発生するサービス ダウンタイムと同じです。
マニュアルの入手方法およびテクニカル サポート
マニュアルの入手方法、テクニカル サポート、その他の有用な情報について、次の URL で、毎月更新される『 What's New in Cisco Product Documentation 』を参照してください。シスコの新規および改訂版の技術マニュアルの一覧も示されています。
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
『 What's New in Cisco Product Documentation 』は RSS フィードとして購読できます。また、リーダー アプリケーションを使用してコンテンツがデスクトップに直接配信されるように設定することもできます。RSS フィードは無料のサービスです。シスコは現在、RSS バージョン 2.0 をサポートしています。
フィードバック