Prime Network アップグレードの概要
このアップグレード手順は、既存のユーザ ディレクトリをバックアップしてから、新しい Prime Network 4.3.2 ライブラリ、ファイル、およびコードを既存のインストールに追加します。データベースへの変更は、アップグレードの一部として自動的に行われます。カスタマイズとユーザ定義情報の大部分はそのまま保持され、アップグレード後も利用できます。移行対象の一覧を 表 11-1 に示します。
Operations Reports は、インストールされている場合、アップグレード プロセス中に自動的にアップグレードされます。
Prime Network のアップグレードに必要な時間は、導入サイズとシステム パフォーマンスによって異なります。アップグレード中、システムはダウンします。アップグレードに要するおよその時間については、シスコのアカウント担当者にお問い合わせください。
表 11-1 に、Prime Network のアップグレードによって影響を受けるコンポーネントと、それらのコンポーネントが自動的にアップグレードされるかどうかを示します。自動的に更新されない場合は、実行する必要のある手動の手順を示します。
表 11-1 Prime Network のアップグレードによって影響を受けるコンポーネント
|
|
|
|
VNE AVM |
管理対象デバイスの定義が指定された avm*.xml ファイル |
はい |
— |
サードパーティ製 VNE のサポート |
シスコ以外の VNE のサポート |
いいえ |
Prime Network では、シスコ アドバンスド サービスを通じてサードパーティ製デバイスをサポートします。リリース 4.3.2 現在では、Prime Network はサードパーティ製デバイスをネイティブにはサポートしていません。このため、それらのデバイスを有効化しサポートするには、シスコ アドバンスド サービスの契約が必要になります。 |
データベース スキーマの変更 |
データベース スキーマ テーブルを追加、変更、削除して、Cisco Prime Network 4.3.2 のスキーマ定義を満たします。 |
はい |
— |
データベースのデータ保持 |
元のデータ表現を、可能な場合は Cisco Prime Network 4.3.2 の表現に移行します。 |
はい |
アップグレード後、すべてのチケットおよびイベントが利用可能になります。その他のすべてのデータ(マップ、ユーザなど)は保持され、移行されます。 |
データベース(全般) |
— |
いいえ |
移行後、同じデータベース タイプを保持する必要があります。つまり、次のアップグレードはできません。
- ゲートウェイ サーバ上にあるデータベースから、リモート サーバ上にあるデータベース(およびその逆)へのアップグレード。
- ユーザが用意したデータベースから組み込み型データベースへのアップグレード。
|
ユーザと範囲 |
— |
はい |
すべてのユーザと範囲が維持されます。 |
Northbound API のトラップ転送および SNMP |
すぐに使用できる SNMP トラップ フォワーディング メカニズムのサポート。 |
はい |
Cisco-EPM-NOTIFICATION-MIB 構造は、以前のリリースのような定数ではなく、実行中のインデックスをオブジェクト識別子(OID)サフィックスに格納します。Prime Network 3.8 で cenAlarmType コンテンツが変更されました。詳細については、シスコ アドバンスド サービスにお問い合わせください。 |
Northbound API:IMO および BQL |
情報モデル オブジェクト(IMO)に加えられた変更。 |
はい |
(注) IMO は、新機能をサポートするため、バージョン間で異なる場合があります。詳細については、シスコ アドバンスド サービスにお問い合わせください。 |
カスタマイズ:ビジネス オブジェクト |
— |
はい |
IMO の変更を確認し、そのビジネス オブジェクトと関連付けられている OID が変わっていないことを確認します。 |
カスタマイズ:ソフト プロパティ |
ソフト プロパティには後方互換性があり、アップグレード後 Prime Network 4.3.2 で利用できます。 |
はい |
— |
カスタマイズ:コマンド ビルダー |
ユーザが定義したコマンド。 |
はい |
— |
組み込み型のコマンド ビルダー スクリプト |
Prime Network 組み込み有効化スクリプト。 |
はい |
このアップグレード手順は組み込まれている変更を更新し、製品に含まれなくなったスクリプトを削除します。アップグレード後にインストールする必要のあるコマンドについては、Prime Network のアップグレード後のタスクを参照してください。 |
カスタマイズ:Drools ルール |
— |
はい |
Post.drl ルールは、アップグレード後に利用可能です。 |
カスタマイズ:crontab ファイル |
Prime Network crontab は、インストールの一部として構成されます。 |
はい(適切な場所にある場合) |
ユーザ定義 cron ジョブがある場合、それらを NETWORKHOME /local/cron/crontab.user.list に置きます。アップグレードすると、そのユーザ定義 cron ジョブは自動的に追加されます。このディレクトリに置かれていないユーザ定義 cron ジョブは削除されます。Prime Network のアップグレード後のタスクを参照してください。 |
カスタマイズ:外部起動ポイント |
外部の起動設定。 |
はい |
IMO の変更を確認し、その起動コマンドと関連付けられている OID が変わっていないことを確認します。 |
カスタマイズ:今日のメッセージ |
今日のメッセージの設定。 |
はい |
|
Registry |
— |
はい |
新しい Prime Network 4.3.2 レジストリ ファイルは、アップグレード後に自動的に利用可能になります。avm+.xml や site* などのカスタマイズ可能なレジストリ ファイルは利用可能で、自動的にアップグレードされます。 site.xml および avm*.xml に含まれるカスタマイズされたレジストリ構成を確認し、それらが Prime Network 4.3.2 に適切であるか確認します。必要に応じて、シスコのアカウント担当者にお問い合わせください。 |
pnuser _admin ユーザ |
データベース管理者のアクセス許可を持っており、他の Prime Network データベース スキーマで、統計情報の収集などのメンテナンス タスクを実行できるユーザ。 |
はい |
— |
セキュリティ:SSH キーおよび SSL キー |
Prime Network SSL キーストアとトラストストアのキー、SSH キー、およびレジストリ暗号化キー。 |
はい |
Prime Network SSL キーストアとトラストストアのキーは保持されます。これらのキーは、BQL クライアントや PTP クライアントなどの、すべての SSL ソケットによって使用されます。Prime Network SSH キー、およびレジストリ暗号化キーも保持されます。 |
Prime Network 永続性ファイル |
インベントリ、イベント、およびリンクの永続性データ。 |
はい |
すべての永続性ファイルは、アップグレード後に利用可能になります。 |
スタンバイ ユニット |
— |
はい |
スタンバイ ユニットのアップグレードは、それらのユニットがゲートウェイによって再起動された時点(アクティブ ユニットがダウンし、スタンバイ ユニットがオンラインになった時点)で完了します。 |
GUI クライアント |
— |
いいえ |
クライアントがインストールされている場合、アップグレード後にそのクライアントを再インストールする必要があります。Web Start を介してクライアントにアクセスする場合、必要な処理はありません。 |
ネットワーク サービスの有効化(NSA) |
— |
いいえ |
シスコ Prime Network 有効化機能は、Prime Network 4.3.2 では利用できなくなりました。以前のリリースで利用できた Prime Network ワークフロー機能や有効化機能は、トランザクション マネージャに置き換えられました。トランザクション マネージャの設定方法については、Transaction Manager を設定するを参照してください。トランザクション マネージャの使用方法については、『 Cisco Prime Network 4.3.2 Customization Guide』を参照してください。 |
変更および構成管理 |
ソフトウェア イメージ ファイルとデバイス構成ファイル。 |
はい |
ソフトウェアとデバイス構成の変更はすべて、アップグレードの一部として保持されます。 |
ハイ アベイラビリティの設定 |
RHCS/Oracle Active Data Guard ゲートウェイのハイ アベイラビリティのためのアップグレード。 |
いいえ |
ゲートウェイにハイ アベイラビリティが設定されている場合、Prime Network および Oracle サービスをメンテナンス モードにしてからアップグレードを実行し、アップグレード後に通常モードに戻します。 |
Operations Reports |
ユーザが定義したレポート。 |
はい |
アップグレード前に作成されたすべてのユーザ定義レポートは、アップグレード後に利用可能になります。 |
アップグレードの準備 Prime Network(アップグレード前のチェックリスト)
表 11-2 に、Prime Network 4.3.2 にアップグレードする前に実行する必要がある、アップグレード前のタスクを示します。
表 11-2 ゲートウェイのアップグレード前のタスク
|
|
|
手順 1 |
サードパーティ製デバイスを管理している場合、それらをメモしておきます。アップグレード後のサポートを有効にするには、シスコの担当者にこの情報を提供する必要があります。 |
Prime Network では、シスコ アドバンスド サービスを通じてサードパーティ製デバイスをサポートします。リリース 4.3.2 現在では、Prime Network はサードパーティ製デバイスをネイティブにはサポートしていません。このため、それらのデバイスを有効化しサポートするには、シスコ アドバンスド サービスの契約が必要になります。 |
手順 2 |
アップグレードのプロセスをよく理解し、手動での変更が必要になる可能性のある分野を確認します。 |
アップグレードによって影響を受けるコンポーネントは 表 11-1 に示されています。 |
手順 3 |
ゲートウェイに保存されたデータベースとファイルをバックアップします。 (注) ロールバックを実行する場合、このデータが必要になります。 インストール DVD から nccmjobstore.csh スクリプトを使用すると、CSV または HTML フォーマットでスケジュールされたジョブ情報を取得できます。 |
外部データベース:
- ゲートウェイにログインして、次のコマンドを NETWORKHOME/Main/scripts から実行することにより、ゲートウェイのデータをバックアップします。
- Oracle のドキュメントを使用して Oracle データベースをバックアップします。
組み込みデータベース: a. pnuser としてゲートウェイにログインします。 b. 組み込みデータベース ディレクトリに移動します。
# cd $PRIME_NETWORK_HOME/Main/scripts/embedded_db
c. バックアップ スクリプトを実行します。
上記の手順で使用されている emdbctl ユーティリティの詳細については、『 Cisco Prime Network 4.3.2 Administrator Guide 』を参照してください。 |
手順 4 |
データベース設定と推奨事項を適用します。 |
Oracle 外部データベースの準備 |
手順 5 |
サーバ マシンがシステムのハードウェア要件とソフトウェア要件に準拠していることを確認します。 |
インストール要件 ゲートウェイ:ネットワーク サイズに基づく CPU およびメモリの要件 |
手順 6 |
バックアップ ディレクトリに、 pnuser 用の空き領域が少なくとも 6000 MB あることを確認します。 |
例:df –k /backup_dir |
手順 7 |
データベースに、使用可能な RAM が少なくとも 8 GB ある(最小要件)ことを確認します。 |
データベース ストレージのサイジングに関するガイドラインについては、シスコのアカウント担当者にお問い合わせください。 |
手順 8 |
必要なポートがすべて空いていることを確認します。 |
Prime Network に必要なポート。 |
手順 9 |
すべてのデータベース セッション(TOAD、SQL など)が終了していることを確認します。 |
Prime Network によって確立されたセッション以外の TOAD セッションや SQL セッションは、閉じる必要があります。 |
手順 10 |
カスタマイズされたすべての crontab ファイルを、 NETWORKHOME /local/ cron/crontab.user.list に置きます。このディレクトリに置かれていないユーザ定義 cron ジョブは削除されます。 |
— |
手順 11 |
(外部データベースのみ)Prime Network および Oracle データベースを再起動します。 |
1. pnuser として、Prime Network を停止します。
2. oracle user として、Oracle を停止し、再起動します。
3. pnuser として、Prime Network を再起動します。
|
手順 12 |
ゲートウェイとユニットの電源が入って接続されていることを、ゲートウェイとすべてのユニット間で SSH セッションを開いて確認します。 |
__ |
手順 13 |
Oracle および Oracle リスナーが実行されていることを確認します。 |
Oracle リスナー(外部データベース)の開始 |
手順 14 |
TMP_BIG_TICKET2 テーブルがすでに作成されている場合は、そのテーブルをドロップします。 |
Prime Network 4.3.2 をアップグレードする前に、以下のクエリをデータベース(DB)で実行します。 1. Prime Network DB にログインし、次を実行します。 a. pnuser として sqlplus <PN Username>/<PN User Password>@"[<Gateway IP>]:1521/<SID>" を実行します。
Example: sqlplus pn43/Admin123#@"[10.76.80.19]:1521/mcdb"
EXECUTE IMMEDIATE 'DROP TABLE TMP_BIG_TICKET2';
|
手順 15 |
(NAT ユニットのみ)Prime Network アプリケーションを停止し、現在の crontab を削除します。 |
NAT ユニットごとに次のコマンドを入力します。 networkctl stop;
(注) この crontab を後で再起動するには、NAT ユニットの Crontab ジョブの再起動を参照してください。 |
手順 16 |
(ローカル ゲートウェイおよび地理的に離れた場所にあるゲートウェイのハイ アベイラビリティ)Red Hat がインストールされているゲートウェイとユニットに rsync 3.0.6 以降があることを確認します。 ESXi 5.5 および RHEL6.5 については、『 RHEL6.5 インストール ガイド 』を参照してください。 |
次のコマンドを使用して、ゲートウェイとユニットにインストールされている rsync のバージョンを確認します。 [root@primebgl01-lnx ~]# rpm -qa rsync rsync-3.0.6-9.el6_4.1.x86_64 [root@primebgl01-lnx ~]# |
手順 17 |
外部データベースを使用している場合は、データベースの設定を確認します。 (注) Prime Network 4.3.2 には、Oracle JVM およびパーティション分割オプションが必要です。 |
Chapter 4, “Oracle 外部データベースの準備”を参照してください。 |
Prime Network のアップグレードおよびロールバックのサポート対象バージョン
Prime Network のアップグレードおよびロールバックのサポート対象バージョンについては、次の表を参照してください。
表 11-3 Prime Network のアップグレードおよびロールバックのサポート対象バージョン
4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 から Prime Network 4.3.2 へのアップグレード(中間手順)
(注) 以下の手順に、Prime Network 4.1 と RHEL 6.4、またはそれ以前のバージョンの Prime Network と RHEL 5.5 ~ 5.8 から Prime Network 4.3.2、RHEL 6.8、6.7、または 6.5、および Oracle 12 へのアップグレードする際に従う必要のある中間手順を示します。
Prime Network 4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 から Prime Network 4.3.2 にアップグレードするには、このセクションで説明する手順を使用します。
注意
Prime Network 4.3.2 へのアップグレード中は、どのフェーズでもサービス パッチを一切適用
しないでください。アップグレードの完了後に、それらを適用します。
はじめる前に
アップグレードを開始する前に、アップグレードの準備 Prime Network(アップグレード前のチェックリスト)にある作業を実行します。
(注) HA セットアップで Prime Network をアップグレードしているときは、常にアクティブなゲートウェイとしてプライマリ ゲートウェイからアップグレードを開始する必要があります。アップグレード プロセスを開始するときは、セカンダリ ゲートウェイをアクティブなゲートウェイにすることはできません。
Prime Network ゲートウェイをアップグレードするには、次の手順を実行します。
手順 1 ゲートウェイに一時アップグレード ディレクトリを作成します。
(注) そのアップグレード ディレクトリが NETWORKHOME(デフォルトでは /export/home/pnuser)のサブディレクトリでないことを確認します。
手順 2 DVD ドライブに Disk 3: Upgrade File 1 を挿入します。
手順 3 作成した一時アップグレード ディレクトリに、次のファイルを DVD からコピーします。
- ivne-drivers.tar ファイル
- Prime_Network_upgrade ディレクトリ、およびその依存コンテンツ
手順 4 DVD ドライブに Disk 4 : Upgrade of File 2 を挿入します。
手順 5 Disk 4 の Prime_Network_upgrade ディレクトリに移動し、すべてのコンテンツをコピーします。
手順 6 コピーしたコンテンツを、作成した一時アップグレード ディレクトリ内にある Prime_network_upgrade に貼り付けます。
手順 7 Prime_Network_upgrade ディレクトリとそのコンテンツに pnuser:pngroup 所有者のアクセス許可を付与します。
chown –R pnuser:pngroup Prime_Network_upgrade
手順 8 グループ名を確認するには、pnuser として次のコマンドを実行します。 id --group --name
手順 9 pnuser として、作成した一時アップグレード ディレクトリで次の場所に移動します。
手順 10 Prime Network 4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 の新規インストールから Prime Network 4.3.2 にアップグレードしたのでない場合は、PN ユーザとして status コマンドを実行して Compliance Manager が稼働しているか確認し、そうでない場合は次のコマンドを実行します。
cmctl start
手順 11 アップグレードを開始します。
(注) アップグレード プロセスを実行するには、コンプライアンス サーバが起動しており実行中である必要があります。
(注) カスタム ポリシーをエクスポートする際に、次のメッセージが表示される場合があります。
Export failed, Do you want to continue (YES/NO)
この場合は、ユーザの要件に応じて次から選択できます。
アップグレード プロセスを停止し終了するには NO を選択します。続行するには YES を選択します。
YES を選択すると、次のメッセージが表示されます。
Warning ! All the custom policies has been wiped out, Do you want to continue (YES/NO).
アップグレード プロセスを停止し終了するには NO を選択します。アップグレード プロセス続行するには YES を選択します。
手順 12 次の表に示すとおりに必要な情報を入力します。
|
|
|
OS ルート ユーザのパスワード |
オペレーティング システムのルート パスワード |
Linux のルート パスワード ハイ アベイラビリティ環境では、セットアップに含まれる各マシンの OS ルート ユーザを入力する必要があります。 |
データベースのバックアップ完了確認 |
yes |
このプロンプトは、データベースのバックアップを最近完了したかどうかを確認するためのものです。デフォルトは yes です。 no を入力すると、アップグレード プロセスは停止し、データベースをバックアップするように要求されます。データベースのバックアップの詳細については、「アップグレード前のチェックリスト」の手順 3 を参照してください。 |
既存のインストールの tar ファイルのバックアップ先 |
directory |
少なくとも 6000 MB の空き領域を持つディレクトリを指定します。そのバックアップ ディレクトリを pnuser が利用できることを確認します。 バックアップ ディレクトリには、書き込みアクセス許可が必要です。次のコマンドを入力して、バックアップ ディレクトリに書き込みアクセス許可を追加します。 chmod 777 <directory> |
設定の監査の無効化 |
yes |
設定の監査は廃止され、コンプライアンス監査に置き換えられました。設定の監査を引き続き使用するには、 no と入力すると、[Change and Configuration Management] から使用できます。 |
ivne-drivers.tar ファイルへのパス |
フル パス名 |
手順 1 で作成した一時アップグレード場所のフル パス名を入力します。 |
Prime Network のルート パスワード |
root パスワード |
Prime Network GUI アプリケーションにログインするために使用されるルート パスワードです。 |
手順 13 アップグレードが完了すると、Prime Network が再起動します。環境の変更を有効にするために、 pnuser としてログインします。
(注) カスタム ポリシーをインポートする際、エクスポートされたカスタム ポリシーの数がゼロの場合、インポート プロセスはスキップされます。このとき、No Custom Policies to import というメッセージが表示されます。エクスポートされたカスタム ポリシーの数がゼロではなく、コンプライアンス サーバが起動している場合、インポート プロセスが開始します。コンプライアンス サーバが 30 秒以内に起動しない場合、次のメッセージがユーザに表示されます。
Failed : Run <PN_Home>/utils/independent/compliance/bin/importPolicies.sh manually
手順 14 上記のいずれかの手順が失敗した場合、次のエラー メッセージが表示されます。
Failed to execute hook-type for hook-name. See log for further details.
- Hook hook-name terminated with failure
- Please choose one of the following:
1. Abort the upgrade process
エラー メッセージの hook-type および hook-name は、失敗した手順のタイプと名前です。
a. アップグレード ログ( NETWORKHOME /Main/upgrade- timestamp.log)を確認して、失敗の原因を特定します。
b. 問題を特定して手動で修正できる場合は、修正します。それからオプション 2 を選択してそのフックを再実行します。アップグレード手順は、失敗した手順から続行されます。
c. 問題が解決できない場合は、オプション 1 を選択して、アップグレードをキャンセルします。アップグレードをキャンセルすると、Prime Network を起動できなくなります。シスコのアカウント担当者に問い合わせて、問題を修正します。その後、アップグレードを再実行します。アップグレード手順は、失敗した手順から続行されます。
(注) アップグレードを再実行しないことに決めた場合は、元の Prime Network 環境にロールバックする必要があります。これには、データベースのロールバックも必要になります。以前のバージョンへの Prime Network ロールバックを参照してください。
手順 15 ローカルのハイ アベイラビリティが構成されているゲートウェイをアップグレードした場合は、ana サービスと oracle_db サービスのメンテナンス モードを終了します。
手順 16 Web ブラウザのキャッシュをクリアします。
手順 17 Prime Network のアップグレード後のタスクに示された必要なタスクを実行します。
(注) avm ファイル(11.out)にある以前のデバイス パッケージ参照エラーを削除するには、Prime Network ユーザとして次のコマンドを実行します。networkctl restart –avm 11
Prime Network 4.3.2、RHEL 6.8、6.7、または 6.5、および Oracle 12 へのアップグレード
RHEL 6.4 と PN 4.1 から、RHEL 6.8、6.7、または 6.5 と PN 4.3.2 および Oracle 12 へのアップグレード
RHEL 6.4 と PN 4.1 から、RHEL 6.8、6.7、または 6.5 と PN 4.3.2 および Oracle 12 にアップグレードするには、以下の手順に従います。
手順 1 Disk 3 の Prime_Network_upgrade ディレクトリを作成した一時アップグレード ディレクトリにコピーして、PN 4.3.2 にアップグレードします。4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 から Prime Network 4.3.2 へのアップグレード(中間手順)を参照してください。
手順 2 Disk 3 の embedded_upgrade_12.1.zip ファイルを使用して、組み込み Oracle 12 をアップグレードします。組み込みデータベースの Oracle 12.1.0 へのアップグレードを参照してください。
手順 3 最新の Open ssl パッケージを含むインライン アップグレードを使用して、RHEL 6.4 を 6.7 または 6.5 にアップグレードします。RHEL インライン アップグレードについては、システム管理者にお問い合わせください。
手順 4 RHEL をアップグレードし終えたら、pnuser でログインし、Web サーバのステータスとコンプライアンス エンジンのステータスを確認します。
手順 5 pnuser としてログインし、 $ANA_HOME# anactl restart -avm 11 を使用して、AVM11 を再起動します。
(注) ゲートウェイにユニット サーバが接続されている場合は、上記の手順に従ってまずゲートウェイをアップグレードしてから、インライン アップグレードを使用し、最新の Open ssl パッケージでユニット サーバを RHEL バージョン 6.5 または RHEL バージョン 6.7 にアップグレードします。
RHEL 5.5 ~ 5.8 から RHEL 6.5、6.7、または 6.8 と PN 4.3.2 および Oracle 12 へのアップグレード
RHEL 5.5 ~ 5.8 から 6.5、6.7、または 6.8 へのアップグレードには、ローカルの RHEL 5.5 ~ 5.8 システム上の PN 4.3.2 へのアップグレード、データベースをバックアップして別の場所に保存することが含まれます。その後、RHEL 6.5、6.7、または 6.8 でシステムを再イメージングし、PN 4.3.2 を再インストールして、前のデータベースを保存した場所から復元する必要があります。
(注) RHEL 5.8 を使用していて、RHEL 6.5、6.7、または 6.8 に再イメージングしない場合は、RHEL 5.8 を使用して PN 4.3.2 のアップグレードを続行できます。
RHEL を、以前のバージョンの Prime Network を使用する 5.5、5.6、5.7、および 5.8 から、PN 4.3.2 と Oracle 12 を使用する RHEL 6.8、6.7、または 6.5 にアップグレードするには、次の手順に従います。
手順 1 以前のバージョンの PN をインストールした際に選択した pnuser 名とパスワード、Oracle ユーザ名とデータベース プロファイルを書き留めます。
手順 2 以前のバージョンの PN を、ディスク 3 の Prime_Network_upgrade ディレクトリを使用して、PN 4.3.2 にアップグレードします。4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 から Prime Network 4.3.2 へのアップグレード(中間手順)を参照してください。
手順 3 embedded_upgrade_12.1.zip ファイルを使用して、組み込み Oracle 12 をアップグレードします。組み込みデータベースの Oracle 12.1.0 へのアップグレードを参照してください。
手順 4 Prime ユーザとしてログインし、組み込み Oracle データベースを $ ANAHOME/Main/scripts/embedded_db# emdbctl --backup でバックアップします。ゲートウェイのデータと組み込みデータベースのバックアップ方法については、『 Cisco Prime Network 4.3.2 Administration Guide』を参照してください。
(注) ゲートウェイで Operations Reports を使用している場合、PN のデータベース バックアップを実行する前にアンインストールします。
手順 5 $ ANA_HOME/backup# にある最新のバックアップ フォルダを、ローカル サーバ(現在使用しているサーバ以外のものなど)にコピーします。
手順 6 ゲートウェイ サーバを、RHEL 6.5 または RHEL 6.7 か 6.8 に再イメージングします。ユニット サーバがゲートウェイに接続されている場合は、そのユニット サーバを RHEL 6.5 または RHEL 6.7 か 6.8 に再イメージングします。
手順 7 PN 4.3.2 ゲートウェイ、Oracle 12、およびユニット サーバをインストールします。以前のバージョンの PN にユニット ゲートウェイが設定されている場合は、以前のバージョンの PN ゲートウェイをインストールした際に選択した pnuser 名とパスワード、Oracle ユーザ名とデータベース プロファイルを使用します。
(注) リモート サーバに、以前のバージョンの PN 用の組み込み Oracle がインストールされていた場合は、同じサーバに Prime Network 4.3.2 用組み込みデータベース 12 をインストールします。
手順 8 インストールが完了したら、Prime ユーザとしてログインし、Prime Network ゲートウェイのデータと組み込みデータベースを $ ANAHOME/Main/scripts/embedded_db # emdbctl --backup でバックアップします。ゲートウェイのデータと組み込みデータベースをバックアップする方法については、『 Prime Network 4.3.2 Administrator guide 』を参照してください。
手順 9 $ANA_HOME/backup に移動し、その場所にあるバックアップ ファイル フォルダを削除します。
手順 10 ローカル マシンに既にあるバックアップ ファイル フォルダをその場所($ANA_HOME/backup)にペーストします。
手順 11 次のようにして、バックアップ ファイル ディレクトリとそのコンテンツにグループ所有者のアクセス許可を付与します。
chown - R pnuser: pngroup.
Example: chown -R pn40:ana
手順 12 Prime ユーザとしてログインし、$ ANAHOME/Main/scripts/embedded_db # emdbctl --restore コマンドを使用して、Prime Network ゲートウェイのデータと組み込みデータベースを復元します。ゲートウェイのデータと組み込みデータベースを復元する方法については、『 Prime Network 4.3.2 Administration guide 』を参照してください。
手順 13 復元プロセスが完了したら、PN の状態を確認します。
手順 14 コンプライアンス エンジンと Web サーバの両方が稼働していることを確認します。
手順 15 ユニット サーバがゲートウェイに接続されている場合は、$ ANA_HOME# anactl start コマンドを使用して、そのユニット サーバを Prime ユーザとして起動します。
手順 16 $ ANA_HOME# anactl restart コマンドを使用して、PN を Prime ユーザとして再起動します。
HA 環境での OS のアップグレードまたはダウングレード
ローカル クラスタ上の RHEL バージョンをアップグレードまたはダウングレードして、すべての VM 上の HA にインストールできます。たとえば、VM1 と VM2 はローカル クラスタにインストールし、VM3 は Geo/DR として地理的な設定を使用してローカルにインストールできます。また、VM1 はローカル クラスタにインストールし、VM3 は Geo/DR として Geo のみの設定でインストールすることもできます。VM1 はローカルまたはプライマリの VM と見なされ、VM2 は PN も Oracle サービスも実行されていないセカンダリのローカル クラスタ VM と見なされます。VM3 はスタンバイでリモートの Geo/DR と見なされます。
HA 環境での OS のアップグレード
アップグレードを実行するには、次の手順に従います。
手順 1 地理的な設定、またはすべての VM 上に RHEL 5.8 がインストールされる地理のみの設定で、ローカル クラスタ VM 上に HA をインストールします。
手順 2 ローカルおよび HA ローカル クラスタの両方の場合、一般性を失わずに Primary VM(VM1)をシャットダウンします。
手順 3 スタンバイ VM(VM3)で次のスクリプトを実行します。
(注) 実行すると、VM3 が新しいプライマリになり、VM1 と VM2 のどちらかが新しい Geo/DR になります。
手順 4 ローカル クラスタ上の RHEL を、5.8 から 6.5、6.7、または 6.8 にアップグレードします。
手順 5 次に示すように、HA インストールの VM クラスタ(VM1 または VM2)を設定します。
a. /etc/hosts ファイルを作成します。
b. /tmp および /etc/shadow 両方のアクセス許可を設定します。
c. ビルドの場所をマウントします。
d. 以下に示すように、プライマリ VM 上に一般性を失わずに 4 つの異なるディスク パーティションをもう一度マウントします。
– mount/dev/sdb1/export1/ana-home/ana
– mount/dev/sdb2/ora/opt/ora1
– mount/dev/sdb3/directio
– mount/dev/sdb4/datafiles/dbf
手順 6 一般性を失わずにプライマリ VM(VM1)にログインし、/tmp パスに移動して、RH_ha.zip を解凍します。
(注) 新しい Geo/DR VM が新しい DR になります。
手順 7 /tmp/RH_ha パスに移動して、VM1 上で次のスクリプトを実行します。
#"perl resumeFromFailOver.pl –- reinstall setup from /tmp/RH_ha on the primary VM
(注) スクリプトが失敗した場合は、以下の操作を行います。
a. /tmp/RH_ha/rf_auto_install_RH.ini ファイルに OVERRIDE_SWAP=true を追加します。
b. perl install_Prime_HA.pl-autoconf rf_auto_install_RH.in を実行します。
手順 8 そのプライマリ VM1 上で、perl resumeFromFailOver.pl --reconfigure_setup も実行します。
手順 9 スタンバイ VM(VM3)にログインし、/tmp/RH_ha パスに移動します。
手順 10 スタンバイ VM(VM3)上で、perl resumeFromFailOver.pl--setup_replicatio を実行します。
手順 11 新しいプライマリ VM(VM3)上の OS を、RHEL 6.5、6.7、または 6.8 にアップグレードする場合は、手順 2 から 10 を繰り返します。
a. VM3 をシャットダウンし、ローカル VM(VM1)上で perl primeha –fail スクリプトを実行します。
b. VM3 上の OS を、RHEL 6.5、6.7、または 6.8 にアップグレードします。
c. VM3 をセットアップし、HA をインストールします。
d. VM3 上で、perl resumeFromFailOver.pl –-reinstall_setup スクリプトと、perl resumeFromFailOver.pl --reconfigure_setup スクリプトを実行します。
e. VM1 上で、perl resumeFromFailOver.pl --setup_replicatio を実行します。
HA 環境での OS のダウングレード
ダウングレードを実行するには、次の手順に従います。
手順 1 地理的な設定、またはすべての VM 上に RHEL 5.8 がインストールされる地理のみの設定で、ローカル クラスタ VM 上に HA をインストールします。
手順 2 ローカルおよび HA クラスタ両方の場合は、一般性を失わずにプライマリ VM をシャットダウンします。
手順 3 スタンバイ VM(VM3)で次のスクリプトを実行します。
(注) 実行すると、VM3 が新しいプライマリになり、VM1 と VM2 のどちらかが新しい Geo/DR になります。
手順 4 ローカル クラスタ上の RHEL を、6.8、6.7、または 6.5 から 5.8 にダウングレードします。
手順 5 次に示すように、HA インストールの VM クラスタを設定します。
a. /etc/hosts ファイルを作成します。
b. /tmp および /etc/shadow 両方のアクセス許可を設定します。
c. ビルドの場所をマウントします。
d. 以下に示すように、プライマリ VM 上に一般性を失わずに 4 つの異なるディスク パーティションをもう一度マウントします。
– mount/dev/sdb1/export1/ana-home/ana
– mount/dev/sdb2/ora/opt/ora1
– mount/dev/sdb3/directio
– mount/dev/sdb4/datafiles/dbf
手順 6 一般性を失わずにプライマリ VM にログインし、/tmp パスに移動して、RH_ha.zip を解凍します。
(注) 新しい Geo/DR VM が新しい DR になります。
手順 7 /tmp/RH_ha パスに移動して、次のスクリプトを実行します。
#"perl resumeFromFailOver.pl –- reinstall setup from /tmp/RH_ha on the primary VM
(注) スクリプトが失敗した場合は、以下の操作を行います。
a. OVERRIDE_SWAP=true to the file /tmp/RH_ha/rf_auto_install_RH.ini を追加します。
b. perl install_Prime_HA.pl-autoconf rf_auto_install_RH.in を実行します。
手順 8 そのプライマリ VM 上で、perl resumeFromFailOver.pl --reconfigure_setup も実行します。
手順 9 スタンバイ VM にログインし、/tmp/RH_ha パスに移動します。
手順 10 スタンバイ VM 上で、perl resumeFromFailOver.pl--setup_replicatio を実行します。
手順 11 新しいプライマリ VM 上の OS を、RHEL 5.8 にダウングレードする場合は、手順 2 から 10 を繰り返します。
a. VM3 をシャットダウンし、ローカル VM(VM1)上で perl primeha –fail スクリプトを実行します。
b. VM3 上の OS を、RHEL 5.8 にダウングレードします。
c. VM3 をセットアップし、HA をインストールします。
d. VM3 上で、perl resumeFromFailOver.pl –-reinstall_setup スクリプトと、perl resumeFromFailOver.pl --reconfigure_setup スクリプトを実行します。
e. VM1 上で、perl resumeFromFailOver.pl --setup_replicatio を実行します。
Prime Network Operations Reports の 4.0 から 4.3.2 へのアップグレード
Prime Network Operations Reports を 4.0 から 4.3.2 にアップグレードする場合は、Operations Reports の次の URL を手動で [Address] フィールドに入力する必要があります。
https:// < gateway-IP >:< port-number >/ prime-network-reports
それぞれの説明は次のとおりです。
Gateway-IP:Operations Reports ポータルのゲートウェイ IP。
Port-numbe:インストール時に設定された SSL ポート番号。デフォルトの SSL ポートは 8445 です。
以前のバージョンへの Prime Network ロールバック
アップグレード中に問題が発生する場合、またはアップグレード完了後に以前のバージョンにロールバックする場合は、Prime Network 4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、または 4.0 にロールバックできます。4.3.2 から 4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 へのロールバックについては『 Cisco Prime Network 4.1 Installation Guide 』、『 Cisco Prime Network 4.2 Installation Guide 』、『 Cisco Prime Network 4.3 Installation Guide 』を参照してください。
はじめる前に
- ゲートウェイとユニットの電源が入って接続されていること、つまり、ゲートウェイとすべてのユニット間で SSH セッションを開けることを確認します。
- 管理 GUI を使用して、ゲートウェイからスタンバイ ユニットと NAT ユニットを切断します。
- networkctl status を使用して、Prime Network アプリケーションが実行されて いない ことを確認します。
- ロールバックを実行する前に、PN 統合レイヤを停止し、モニタリング プロセスを監視します。統合レイヤを停止する方法については、Chapter 10, “Prime Network 統合層のインストール”を参照してください。
Prime Network ゲートウェイを Prime Network 4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 にロールバックするには
(注) RHEL 6.4 または RHEL 5.5 ~ 5.8 を、Prime Network 4.3 と RHEL 6.7 または 6.5、および Oracle 12 にアップグレードすると、元のバージョンの Prime Network にロールバックできなくなります。
手順 1 導入環境にゲートウェイに接続されているユニットが含まれる場合は、ゲートウェイをロールバックする前にそのユニットをロールバックします。ロールバックを行うと、レジストリと Golden Source から冗長ユニットが削除されます。
手順 2 次のコマンドを使用して、すべてのユニットを設定します。
network-conf -rollback
手順 3 プロンプトで no と入力し、ユニットを起動します。
手順 4 バックアップされたデータベースを復元して、データベース サービスとリスナーを起動します。アップグレードするとデータベースのテーブル構造が変更されるので、データベースはアップグレード プロセスの一部としてバックアップされます。元のテーブル構造に復元する必要があります。
(注) ゲートウェイのハイ アベイラビリティ導入が設定されている場合、ana サービスと oracle_db サービスをメンテナンス状態に移行する必要があります。
- 外部データベースを復元する場合は、データベース管理者にお問い合わせください。
- 組み込みデータベースを復元するには、次の手順を実行します。
– pnuser としてゲートウェイにログインします。
– NETWORKHOME /Main/scripts/embedded_db ディレクトリに移動します。
# cd $PRIME_NETWORK_HOME/Main/scripts/embedded_db
– 組み込みデータベースを復元するために、次の復元スクリプトを実行します。
組み込みデータベースの復元中に表示されるプロンプトの詳細については、次を参照してください。
『Cisco Prime Network 4.3.2 Administrator Guide』
データベースを復元したら、プロンプトで no と入力し、Prime Network を起動します。
手順 5 pnuser として、一時アップグレード ディレクトリ(4.3.1、4.3、4.2.3、4.2.2、4.2.1、4.2、4.1、4.0 から Prime Network 4.3.2 へのアップグレード(中間手順)の手順 1 で作成したもの)に移動します。
手順 6 次のコマンドを入力して、アップグレード ディレクトリに移動します。
手順 7 そのゲートウェイで(のみ)、次のコマンドを入力します。
手順 8 次の表に示すとおりに必要な情報を入力して、ロールバックを実行します。
手順 9 ロールバックが完了したら、 pnuser としてログインし、環境の変化を適用します。
手順 10 ユニットを起動します。
- networkctl start ( network-conf は再実行しません)
手順 11 管理 GUI を使用して、スタンバイ ユニットと NAT ユニットをゲートウェイに再接続します。
(注) ロールバック ログは、NETWORKHOME の下の Prime_Network_upgrade フォルダに置かれます。
Prime Network 統合レイヤ(PN-IL)のアップグレード
PN IL がシステムにインストールされている場合は、次のトピックの手順を使用してアップグレードできます。
(注) PN IL がシステムにインストールされていない場合は、CLI を使用して PN-IL をインストールするの手順を使用してインストールできます。
スタンドアロン モードでの PN-IL のアップグレード
はじめる前に
pnuser として次のタスクを実行します。
- PN-IL サービスを無効化するには、ヘルス モニタを無効化します。そのようにしないと、サービスは 3 分間の遅延の後に自動的に開始されます。
$PRIMEHOME/local/scripts/il-watch-dog.sh disable
- $PRIMEHOME ディレクトリをバックアップします。
.For example,/ilUpgradeUtility.sh backup
- 次のコマンドを使用して PN-IL を停止します。
スタンドアロン PN IL をアップグレードするには、次の手順を実行します。
手順 1 PN-IL をインストールする Prime Network ゲートウェイ サーバ上に、ルート ユーザとして端末を起動します。
手順 2 DVD ドライブに Disk 3: Upgrade Files 1 を挿入します。
手順 3 mount を使用して挿入した DVD をマウントし、マウント場所に移動します。
手順 4 pnuser としてログインします。
手順 5 一時 PN-IL アップグレード ディレクトリを作成します。
mkdir -p $PRIME_NETWORK_HOME/pnilupgrade
手順 6 PN-IL アップグレード tar ファイルを、マウント場所から pnilupgrade ディレクトリにコピーします。
cp /mnt/**/Upgrade/PNIntegrationLayerUpgrade_1.0.0.0-1.9.0.tar.gz $PRIME_NETWORK_HOME/pnilupgrade
手順 7 tar ファイルをコピーしたディレクトリに移動し、PN-IL アップグレード tar を抽出します。
cd $PRIME_NETWORK_HOME/pnilupgrade
tar -zxf PNIntegrationLayerUpgrade_1.0.0.0-1.9.0.tar.gz
手順 8 抽出したファイルのディレクトリに移動します。
cd
PNIntegrationLayerUpgrade_1.0.0.0-1.9.0
手順 9 アップグレード スクリプトを実行します。
./upgradeIntegrationLayer.sh
手順 10 プロンプトで yes を入力し、アップグレード プロセスを続行します。アップグレード プロセスが完了して、ログ ファイルのディレクトリが PNIL のバージョンに基づいて変更されます。たとえば、$PRIMEHOME/upgrade/1.0.0.0-1.7.0.0/upgrade.log などの場所にログ ファイルが置かれます。
手順 11 アップグレード後に次のタスクを実行します。
a. pnuser として、ユーザ プロファイルをリロードします。
source $PRIME_NETWORK_HOME/.cshrc
b. スタンドアロン モードで PN-IL を設定します。
c. PN-IL を起動します。
$PRIMEHOME/bin/itgctl start
d. ヘルス モニタを有効化します。
$PRIMEHOME/local/scripts/il-watch-dog.sh enable
スイート モードでの PN-IL のアップグレード
Prime Network 4.3.2 を使用していた場合、システムには既に PN-IL 1.9 がインストールされています。スイート モードで PN IL 1.9 にアップグレードする手順は、スタンドアロン モードでのアップグレード手順と同じです。スタンドアロン モードでの PN-IL のアップグレードを参照してください。
Prime Network 4.0 以前のリリースを使用していた場合は、以下の手順に従って PN-IL 1.9 にアップグレードします。
手順 1 「Prime Network 統合レイヤ(PN-IL)のアップグレード」の説明に従って、スタンドアロン モードで PN-IL をアップグレードします。
手順 2 Prime Central サーバで次のタスクを実行して、PN-IL 設定データのバックアップを作成します。
a. Prime Central サーバに root としてログインします。
ssh root@Prime-Central-host-IP-address
b. Prime Central アップグレード ディレクトリを作成します。
mkdir -p $PRIMEHOME/upgrade
c. PN-IL アップグレード tar ファイル(PNIntegrationLayerUpgrade_1.0.0.0-1.9.0.tar.gz など)を、Prime Network サーバ上のアップグレード ディレクトリから、Prime Central サーバのアップグレード ディレクトリにコピーします。
d. ファイルを抽出します。
tar -zxf PNIntegrationLayerUpgrade_1.0.0.0-1.9.0.tar.gz
e. PN-IL アップグレード ユーティリティ スクリプトを実行して、$PRIMEHOME/backup にバックアップ tar ファイルを作成します。
./ilUpgradeUtility.sh backup
手順 3 Prime Network サーバで次のタスクを実行して、PN-IL 設定を復元します。
a. pnuser として、そのバックアップ tar を Prime Central アップグレード ディレクトリから Prime Network サーバにコピーします。
b. ファイルを抽出します。
tar -zxf il_backup_1.7.0.0.tar.gz
c. PN-IL ユーティリティ スクリプトを実行して、PN-IL 設定を復元します。
./ilUpgradeUtility.sh restore untar-files-directory
手順 4 『 Cisco Prime Central Quick Start Guide 』の手順に従って、Prime Central で次のタスクを実行します。
- Prime Central をアップグレードします。
- Prime Network と PN-IL を Prime Central と統合します。
手順 5 アップグレードした PN-IL を起動します。
$PRIMEHOME/bin/itgctl start
Prime Network のアップグレード後のタスク
Prime Network 4.3.2 へのアップグレードが完了したら、導入環境に適用されるアップグレード後のタスクを実行します。
リブート後にユニットが自動的に再起動されるようにする
アップグレード後に、セットアップに含まれる各ユニットで次の手順を実行する必要があります。この手順を実行しないと、リブート後にユニットが自動的に再起動しません。
手順 1 ユニットに pnuser としてログインします。
手順 2 次のようにして、ゲートウェイから rootdeploy.cmd をコピーします。
remote_copy.cmd "<Gateway_IP>:.deploy/independent/on_boot/rootdeploy.cmd" ".deploy/independent/on_boot/rootdeploy.cmd"
手順 3 ルート ユーザに切り替えます。
ルート ユーザとして、次のルート展開コマンドを実行します。
cd $PRIME_NETWORK_HOME/.deploy/independent/on_boot ;./rootdeploy.cmd
カスタマイズされた Crontab の復元
ユーザ定義 cron ジョブを NETWORKHOME /local/cron/crontab.user.list に保存してある場合、それらを復元します。このディレクトリに置かれていないユーザ定義 cron ジョブは、手動で再作成する必要があります。
NAT ユニットの Crontab ジョブの再起動
NAT ユニット上の Cron ジョブは、手動で再起動する必要があります。
手順 1 ユニットに pnuser としてログインします。
手順 2 次のようにして、ゲートウェイから upgrade_restart_crons.pl スクリプトをコピーします。
remote_copy.cmd [gw-ip]:$PRIME_NETWORK_HOME/Main/scripts/upgrade_restart_crons.pl Main/scripts
手順 3 upgrade_restart_crons.pl スクリプトを実行します。次のような出力が表示されます。
./Main/scripts/upgrade_restart_crons.pl
+ Updating the unit's cronjobs
- Writing log to ~/Main/logs/upgrade_crons.log
- Copying the files from the gateway (gateway's_ip)
- Restarting the cronjobs
+ Please wait while the unit is being updated.................................Done.
手順 4 crontab リストが空でないことを確認します。
手順 5 これでアップグレードは完了しました。status コマンドを実行し、バージョン番号を確認して、アップグレードが成功したことを確認します。
NAT を使用した Vision クライアントのデータベース エントリの修正
Prime Network Vision クライアントでネットワーク アドレス変換(NAT)を使用している場合、IP アドレスではなくホスト名が格納されるように、Prime Network レジストリのデータベース ホストを更新します。
IP アドレスではなくホスト名を既に使用している場合、この手順を繰り返す必要はありません。
手順 1 Prime Network が実行されていることを確認します。
手順 2 クライアント ワークステーションに適切なドメイン ネーム システム(DNS)のマッピングが指定されていることを確認します。
手順 3 NETWORKHOME/Main から、次のコマンドを実行します。
./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/persistency/nodes/main/Host database-server-hostname
./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/persistency/nodes/ep/Host database-server-hostname
手順 4 Prime Network を再起動するには、次のコマンドを入力します。
ポート ウォッチドッグ(AVM 保護)スクリプトの更新
Prime Network 4.3.2 をアップグレードしたら、ポート ウォッチドッグ スクリプトを /var/adm/cisco/prime-network/scripts にコピーします。ルート ユーザとして次のコマンドを入力します。
mkdir –p /var/adm/cisco/prime-network/scripts
cp NETWORKHOME/Main/scripts/port_watchdog.pl /var/adm/cisco/prime-network/scripts
cp NETWORKHOME/Main/scripts/keep_alive_port_watchdog.pl /var/adm/cisco/prime-network/scripts
chmod -R 700 /var/adm/cisco/prime-network/scripts
chown -R pnuser:network /var/adm/cisco/prime-network/scripts
デバイスとクラウド VNE 間のリンクの復元
静的リンクでデバイスに接続されたクラウド VNE が現在の導入に含まれている場合、そのクラウド VNE とデバイス間の接続がアップグレード後に失われる可能性があります。管理 GUI を使用して、リンクを削除し再作成します。
サードパーティ VNE のサポート
Prime Network では、シスコ アドバンスド サービスを通じてサードパーティ製デバイスをサポートします。リリース 4.3.2 現在では、Prime Network はサードパーティ製デバイスをネイティブにはサポートしていません。このため、それらのデバイスを有効化しサポートするには、シスコ アドバンスド サービスの契約が必要になります。
Command Builder スクリプト
Command Builder スクリプトをカスタマイズした場合(これらは削除しておく必要があります)、次のような導入では、スクリプトの更新が必要になる場合があります。
- Prime Network Northbound API(BQL など)を使用して、コマンド スクリプトを実行している場合。
- IMO または Prime Network 内部モデルへの参照が含まれる場合。
コマンド名、パラメータ、または IMO の参照が変更されているかどうかを確認します。変更されている場合は、スクリプトを更新する必要があります。次に、カスタマイズされたスクリプトを再インストールします。
最初の 24 時間の DB 統計情報の収集
pnuser _admin ユーザは、もう一方の Prime Network データベース スキーマで、統計情報の収集などのメンテナンス タスクを実行します。このユーザを作成すると、cron ジョブが 24 時間ごとに実行され、障害データベース テーブルの統計が収集されます。
ただし、最初の 24 時間に高い値が予想される場合は、初日に 2 回、つまりノイズ開始から 1 時間後と 5 時間後に統計情報の収集を強制的に実行するように手動で設定することをお勧めします。強制的に統計情報を収集するには、 pnuser として次の UNIX コマンドを入力します。
cd $PRIME_NETWORK_HOME/Main/scripts ;./call_update_ana_stats.pl >& /dev/null
高いイベント レートを処理するために Prime Network を展開する場合は、Oracle の自動メンテナンス ジョブを無効化することをお勧めします。自動メンテナンスは、Oracle のパフォーマンスに大きな影響を与えるため、イベント処理時間が長くなります。自動メンテナンス ジョブの無効化を参照してください。
PC-FM 再同期用に管理対象デバイスを手動でデータベースに追加する
Prime Network をアップグレードすると、BQL コマンドを実行して、既存のすべての管理対象デバイスの新しい MANAGED ELEMENTS テーブルで VNE 挿入操作を呼び出すことができます。
次の BQL コマンドを実行します。このコマンドには、CopyAllManagedElementsToDB という VNE 名と IP 0.0.0.0 が指定されています。
(注) PNIL を再起動する前に、必ずこの BQL コマンドを実行します。BQL を実行しても、新しい VNE は作成されず、既存の VNE すべての DB が更新され、すべての管理対象デバイスが DB に挿入されます。
<?xml version="1.0" encoding="UTF-8"?>
<management.IElementManagement type="management.IElementManagement" instance_id="0">
<ID type="Oid">{[MCNetwork][MCVM(IP=X.X.X.X)][ElementManagement(Key=CopyAllManagedElementsToDB)]}</ID>
<IP type="com.sheer.types.IPAddress">0.0.0.0</IP>
<ElementName type="String">CopyAllManagedElementsToDB</ElementName>
</management.IElementManagement>
(注) 上記の BQL の X.X.X.X は、ゲートウェイ IP アドレスに置き換えてください。
BQL の処理がそれ以上行われないようにするには、BQL の応答の一部として返される例外を呼び出す必要があります(この例外の呼び出しは、[Modelling] タブから新しい VNE を作成した際の入力値を検証するために使用される既存の方法です)。
(注) BQL を実行すると、次に示すような例外メッセージが返されます。
“<Description type="String">ERROR (5133): The VNE's name contains invalid characters. valid chars are: A-Z, a-z, 0-9, _, '@', '!', '~', '.', ' '.</Description>”
アップグレード後の BQL と他の統合の詳細については、 https://developer.cisco.com/site/prime-network/ にある「Cisco Developer Network」を参照してください。
組み込みデータベースの Oracle 12.1.0 へのアップグレード
次の場合、組み込み Oracle データベースをバージョン 12.1.0 にアップグレードする必要があります。
- Prime Network 4.1 またはそれ以前のバージョンを使用しており、これを Prime Network 4.3.2 にアップグレードする場合。
AND
- オペレーティング システムを Red Hat 6 にアップグレードする場合。
上記の条件に当てはまらない場合、Oracle 12.1.0 にアップグレードする必要はありません。アップグレード済みの Prime Network 4.3.2 は Oracle 11.2.0.3 でも動作します。
Oracle 12.1.0 にアップグレードするには、次の手順に従います。
1. 最初に、Prime Network 4.1 にアップグレードします。
2. Oracle を、以前のバージョンから Oracle 11.2.0.3 にアップグレードします。
3. オペレーティング システムをアップグレードします。
4. Prime Network 4.1 から Prime Network 4.3.2 にアップグレードします。
5. Oracle 12.1.0 にアップグレードします。
はじめる前に
- 次の Oracle インストール.zip ファイルを、Prime Network 4.3.2, Disk 6 : Database Binaries から、組み込みデータベースがインストールされるマシン(ローカル ゲートウェイ サーバかリモート サーバのいずれか)のディレクトリにコピーします。
– linuxamd64_12c_database_1of2.zip
– linuxamd64_12c_database_2of2.zip
(注) これらのデータベース ファイルは、Prime Network 4.3.2 のディスクにあります。
手順 1 ルート ユーザとして、Disk 3 の embedded_upgrade_12.1.zip ファイルを見つけ、そのファイルを組み込みデータベースがインストールされているマシン(ローカル ゲートウェイ サーバかリモート サーバのいずれか)のディレクトリにコピーします。
手順 2 ファイルを解凍します。
unzip embedded_upgrade_12.1.zip
手順 3 セットアップにクラスタが含まれる場合は、次のコマンドを使用してクラスタ構成サービス(ana および oracle_db)を停止します。
手順 4 次のコマンドを入力して、データベースのアップグレードを開始します。
# perl upgrade_embedded_oracle_12.pl
組み込みデータベースの Oracle 12.1.0 へのアップグレード例
手順 1 データベース サーバで、次の手順を実行します。
a. 次のコマンドを入力して、embedded_upgrade_12.1.zip を /tmp/upg12c に解凍します。
chmod a+x /tmp/upg12c/*.pl
b. 次の 2 つの ZIP ファイルを、/tmp/upg12c にコピーします。
– linuxamd64_12c_database_1of2.zip
– linuxamd64_12c_database_2of2.zip
c. 次のコマンドを入力して、ステージング ディレクトリを作成します。
d. 次のコマンドを入力して、Oracle 12.1.0 にアップグレードします。
# perl upgrade_embedded_oracle_12.pl
Enter the name of the OS user of the database [oracle]
Enter the staging/upgrade directory. This directory should have at least 9GB free space [/export/home/stg]
Running pre-upgrade validations
Extracting /tmp/upg12c/linuxamd64_12c_database_2of2.zip
Extracting /tmp/upg12c/linuxamd64_12c_database_1of2.zip
Diagnosing the database status
Running pre-upgrade tasks
Copying files to new Oracle home
Verifying no files needs media recovery and no backup is running
Before proceeding with the upgrade, this procedure will take a backup of the database. you may choose between
1. Offline (Cold) backup (requires database downtime) [default]
The database is about to be shutdown. Please stop PrimeNetwork and any other application using the database.
Hit the 'Enter' key when ready to continue
Stopping the database & listener
Stopping the database & listener
Upgrading the database. This step may take at least 40 minutes.
Executing post upgrade tasks.
Identifying new invalid objects
Copying PrimeNetwork scripts to new Oracle home
Restarting Oracle cronjobs
Upgrade completed successfully. Logs can be found under /opt/ora/oracle/ana_logs/upgrade
To complete the upgrade, enter the following command as the Prime Network user:
cd ~/Main/scripts/embedded_db ; emdbctl --update_oracle_home
You have new mail in /var/spool/mail/root
手順 2 次の表に示すとおりに必要な情報を入力します。
|
|
|
OS ユーザ名 |
Oracle データベース ユーザのユーザ名。 |
デフォルトは oracle です。 |
ステージング/アップグレード ディレクトリ |
アップグレードの実行元ディレクトリのパス、およびデータベース ZIP ファイルの抽出先ディレクトリのパス。 |
デフォルトは /export/home/stg です。 |
ZIP ファイルの場所 |
Oracle ZIP ファイルのコピー先ディレクトリのパス。 |
— |
データベースのバックアップ方法 |
オフライン(コールド)バックアップ、またはオンライン(ホット)バックアップ |
コールド バックアップの場合、バックアップ中にデータベースがダウンします。ホット バックアップの場合、アップグレードが開始されるまでデータベースは動作し続けます。ダウンタイムは短くなりますが、バックアップに長く時間がかかることがあります。デフォルトはコールド バックアップです。 |
手順 3 Oracle にログインし、次のコマンドを使用して組み込み Oracle を再起動します。
#lsnrctl stop
#lsnrctl start
地理的冗長性と Oracle ADG を使用した、HA セットアップでの組み込みデータベースの Oracle 12.1.0 へのアップグレード
次の場合、組み込み Oracle データベースをバージョン 12.1.0 にアップグレードする必要があります。
- Prime Network 3.9 またはそれ以前のバージョンを使用しており、これを Prime Network 4.3.2 にアップグレードする場合。
AND
- オペレーティング システムを Red Hat 6 にアップグレードする場合。
上記の条件に当てはまらない場合、Oracle 12.1.0 にアップグレードする必要はありません。アップグレード済みの Prime Network 4.3.2 は Oracle 11.2.0.3 でも動作します。
Oracle 12.1.0 にアップグレードするには、次の手順に従います。
1. 最初に、Prime Network 4.1 にアップグレードします。
2. Oracle を、以前のバージョンから Oracle 11.2.0.3 にアップグレードします。
3. オペレーティング システムをアップグレードします。
4. Prime Network 4.1 から Prime Network 4.3.2 にアップグレードします。
5. Oracle 12.1.0 にアップグレードします。
はじめる前に
- 次の Oracle installation.zip ファイルを、Prime Network 4.3.2 ディスクから、組み込みデータベースがインストールされているマシン(プライマリ ゲートウェイ サーバとスタンバイ ゲートウェイ サーバの両方)のディレクトリにコピーします。
– linuxamd64_12c_database_1of2.zi
– linuxamd64_12c_database_2of2.zip
(注) これらのデータベース ファイルは、Prime Network 4.3.2 のディスクにあります。
手順 1 プライマリ ゲートウェイ サーバとスタンバイ ゲートウェイ サーバの両方で実行されるようにするには、次の手順を実行します。
ルート ユーザとして、Disk 3 の embedded_upgrade_12.1.zip ファイルを見つけ、そのファイルを組み込みデータベースがインストールされているマシンのディレクトリにコピーします。
手順 2 プライマリ ゲートウェイ サーバとスタンバイ ゲートウェイ サーバの両方で実行されるようにするには、次の手順を実行します。
ルート ユーザとして、ファイルを解凍します。
unzip embedded_upgrade_12.1.zip
手順 3 スタンバイ ゲートウェイ サーバ上で、Oracle ソフトウェア アップグレードを実行し、データベースのアップグレードに備えてスタンバイ サーバを準備します。
アップグレード スクリプト ディレクトリに移動して、次のコマンドを入力します。
# perl standby_db_prepare_for_upgrade_12.1.pl
手順 4 プライマリ ゲートウェイ サーバ上で、次のコマンドを入力して、データベースのアップグレードを開始します。
# perl upgrade_embedded_oracle_12.pl
手順 5 次の表に示すとおりに必要な情報を入力します。
|
|
|
OS ユーザ名 |
Oracle データベース ユーザのユーザ名。 |
デフォルトは oracle です。 |
ステージング/アップグレード ディレクトリ |
アップグレード ZIP ファイルのコピー先ディレクトリのパス。 |
— |
ZIP ファイルの場所 |
Oracle ZIP ファイルのコピー先ディレクトリのパス。 |
— |
データベースのバックアップ方法 |
オフライン(コールド)バックアップ、またはオンライン(ホット)バックアップ |
コールド バックアップの場合、バックアップ中にデータベースがダウンし、ゲートウェイが停止します。ホット バックアップの場合、アップグレードが開始されるまでデータベースは動作し続けます。ダウンタイムは短くなりますが、バックアップに長く時間がかかることがあります。デフォルトはコールド バックアップです。 |
手順 6 プライマリ ゲートウェイ サーバ上で、ルート ユーザとして次のコマンドを入力し、Oracle リスナーが実行されていることを確認します。
su - oracle -c "lsnrctl status"
手順 7 スタンバイ ゲートウェイ サーバ上で、standby_post_upgrade.pl と perl./standby_db_post_upgrade12.1.pl を実行して、複製の Redo Apply を停止します。
地理的冗長性と Oracle ADG を使用した、HA セットアップでの組み込みデータベースの Oracle 12.1.0 へのアップグレード例
手順 1 Prime Network を停止します。
手順 2 データベース間の複製が動作するかどうかを確認します。
手順 3 スタンバイ データベース サーバで、次の手順を実行します。
a. 組み込み Oracle ソフトウェアを利用可能な場所に移動します。
b. 次のコマンドを入力して、embedded_upgrade_12.1.zip を /tmp/upg12c に解凍します。
chmod a+x /tmp/upg12c/*.pl
c. 2 つの ZIP ファイルを、/tmp/upg12c にコピーします。
– linuxamd64_12c_database_1of2.zip
– linuxamd64_12c_database_2of2.zip
d. 次のコマンドを入力して、ステージング ディレクトリを作成します。
e. 次のコマンドを入力して、Oracle 12.1.0 にアップグレードします。
# perl standby_db_prepare_for_upgrade_12.1.pl
- Enter the name of the OS user of the database [oracle]
- Enter the staging/upgrade directory. This directory should have at least 9GB free space [/export/home/stg]
- Running pre-upgrade validations
- Extracting /tmp/upg12c/linuxamd64_12c_database_2of2.zip
- Extracting /tmp/upg12c/linuxamd64_12c_database_1of2.zip
- Installing the software
- Copying files to new Oracle home
- Enter the name of the prime network user :pn400
- Backing up system files
- Starting the standby database in mount mode.
- Copying PrimeNetwork scripts to new Oracle home
- Restarting Oracle cronjobs
Standby database is ready for upgrade. Please run the upgrade procedure for the primary database. Logs can be found under /opt/ora/oracle/ana_logs/upgrade
手順 4 プライマリ データベース サーバで、次の手順を実行します。
a. 組み込み Oracle ソフトウェアを利用可能な場所に移動します。
b. 次のコマンドを入力して、embedded_upgrade_12.1.zip を /tmp/upg12c に解凍します。
chmod a+x /tmp/upg12c/*.pl
c. 2 つの ZIP ファイルを、/tmp/upg12c にコピーします。
– linuxamd64_12c_database_1of2.zip
– linuxamd64_12c_database_2of2.zip
d. 次のコマンドを入力して、ステージング ディレクトリを作成します。
e. 次のコマンドを入力して、Oracle 12.1.0 にアップグレードします。
# perl upgrade_embedded_oracle_12.pl
- Enter the name of the OS user of the database [oracle]
- Enter the staging/upgrade directory. This directory should have at least 9GB free space [/export/home/stg]
- Running pre-upgrade validations
- Extracting /tmp/upg12c/linuxamd64_12c_database_2of2.zip
- Extracting /tmp/upg12c/linuxamd64_12c_database_1of2.zip
- Diagnosing the database status
- Installing the software
- Running pre-upgrade tasks
- Copying files to new Oracle home
- Verifying no files needs media recovery and no backup is running
- Before proceeding with the upgrade, this procedure will take a backup of the database. you may choose between
1. Offline (Cold) backup (requires database downtime) [default]
The database is about to be shutdown. Please stop PrimeNetwork and any other application using the database.
Hit the 'Enter' key when ready to continue
- Stopping the database and listener
- Backing up the database
- Stopping the database and listener
- Backing up system files
- Upgrading the database. This step may take at least 40 minutes.
- Executing post upgrade tasks
- Upgrading timezone file
- Enter the name of the prime network user :pn400
- Running Oracle patch installation
- Identifying new invalid objects
- Copying PrimeNetwork scripts to new Oracle home
- Restarting Oracle cronjobs
Upgrade completed successfully. Logs can be found under /opt/ora/oracle/ana_logs/upgrade
To complete the upgrade, enter the following command as the Prime Network user:
cd ~/Main/scripts/embedded_db; emdbctl --update_oracle_home
You have new mail in /var/spool/mail/root.
----------------------------------------------------------------------------------------
.-= Welcome to pn-ha-p1-s5, running Cisco Prime Network gateway (v4.3.2 (build 119)) =-.
----------------------------------------------------------------------------------------
+ Checking for services integrity:
- Checking if host's time server is up and running [DOWN]
- Checking if webserver daemon is up and running [OK]
- Checking if secured connectivity daemon is up and running [OK]
- Checking Prime Network Web Server Status [DOWN]
- Checking Compliance Engine Status [DOWN]
- Detected AVM99 is down, skipping AVMs check
+ Checking for latest installed device packages:
- Cisco: PrimeNetwork-4.3.2-DP0
- Third party: No third party device package installed.
手順 5 スタンバイ データベース サーバで、次の手順を実行します。
a. 次のコマンドを入力します。
b. 次のコマンドを入力して、Oracle のバージョンをアップグレードします。
# perl standby_db_post_upgrade12.1.pl
- Enter the name of the OS user of the database [oracle]
- Setting standby DB for redo apply
- Enter the staging/upgrade directory, same one that was provided earlier [/export/home/stg]
- Enter the name of the prime network user :pn400
- Starting the STANDBY database in mount mode.
- Standby database is ready. Please verify replication.