Cisco Broadband Access Center インストレーション ガイド Release 4.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2012年3月1日
章のタイトル： Broadband Access Center の アップグレード
Broadband Access Center のアップグレード
この章では、Cisco Broadband Access Center for Cable（BACC）2.6.2.7 インストレーションを Cisco Broadband Access Center（BAC）4.0 にアップグレードする方法について説明します。BACC 2.6.2.7 より前の BAC リリースをインストールしている場合は、まずシステムを BACC 2.6.2.7 にアップグレードしてから、この章のアップグレード手順を実行します。
この BAC リリースではオンライン移行がサポートされています。このオンライン移行を使用すると、BAC 展開を中断することなく、一度に 1 台のサーバを移行できます。
表5-1 は、各 BAC コンポーネントに必要なアップグレード作業を要約しています。
|
|
|
|
|
|
|---|---|---|---|---|
|
2.6.2.7 から 4.0 にアップグレードするときに、次のディレクトリの新しいインストール先を入力する必要があります。
–
データベース ログ ディレクトリ（ BPR_DBLOG ）
（注） アップグレードが完了しても、自動的にプロセス ウォッチドッグ（bprAgent）が再起動されるわけではありません。まず、既存のデータベースを移行する必要があります。
BAC オンライン アップグレード手順では、指定されている次の順序でコンポーネントをアップグレードする必要があります。この順序でアップグレードを実行しないと、プロビジョニング中にエラーが発生します。
1. 「始める前に」
始める前に
BAC コンポーネントをアップグレードする前に、RDU データベース ファイルをバックアップします。
RDU データベースをバックアップするには、 BPR_HOME/rdu/bin ディレクトリで backupDb.sh スクリプトを実行します。
/var/backup には、データベース バックアップ ディレクトリを指定します。
この例では、すべてのバックアップ データベース ファイルは、
/var/backup/rdu-backup-20071116-031028 という名前のディレクトリに保存されます。最後のサブディレクトリ（ rdu-backup-20070316-111028 ）は自動的に作成され、現在のタイムスタンプが付加されます。
（注） タイムスタンプ付きのサブディレクトリ形式は rdu-backup-yyyyMMdd-HHmmss です。この例では、このサブディレクトリは rdu-backup-20071116-031028 です。これは、2007 年 11 月 16 日午前 3:10:28 に開始されたバックアップがこのディレクトリに格納されていることを表しています。
backupDb.sh ツールの使用方法の詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。
RDU のアップグレード
RDU のアップグレードを始める前に、 BPR_HOME/rdu/conf ディレクトリにあるファイルをアーカイブすることを推奨します。
ステップ 1 オペレーション サポート システムから RDU へのアクセスをディセーブルにします。
ステップ 2 backupDb.sh ツールを使用して、既存の RDU データベースをバックアップします。詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。
• -nosubdir ：サブディレクトリの自動作成をディセーブルにする。このオプションを指定しなかった場合、サブディレクトリが作成され、コンソールに表示されます。
• /disk1/backup ：データベース バックアップ ファイルの場所を指定する。
ステップ 3 BPR_DATA ディレクトリにある history.log ファイルをチェックして、データベースがバックアップされたかどうかを確認します。
ステップ 4 recoverDb.sh ツールを使用して、バックアップしたデータベースを一貫性のある状態に復元します。詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。
/disk1/backup には、データベース バックアップ ファイルの場所を指定します。
ステップ 5 バックアップ済みのデータベースを安全な場所にコピーします。
ステップ 6 既存の BAC バージョンを実行しているオペレーティング システム（OS）が 4.0 リリースの要件を満たしていない場合は、OS をアップグレードします。
• データベース ログ ディレクトリ（ BPR_DBLOG ）
その後、必要なライブラリとプロパティ ファイルをアップグレードしますが、RDU データベースはそのままにしておきます。インストールが完了したら、RDU データベースを移行するように要求されます。
ステップ 8 インストールが完了したら、「RDU データベースの移行」で説明している手順を実行して、RDU データベースを移行します。
DPE のアップグレード
DPE のアップグレードを始める前に、 BPR_HOME/dpe/conf ディレクトリにあるファイルをアーカイブすることを推奨します。
インストール済みの DPE を BACC 2.6.2.7 から BAC 4.0 にアップグレードするには、次の手順を実行します。
ステップ 1 pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac コマンドを実行します。
次のような出力が表示されます。この出力は、簡潔にするため、不要な部分を削除しています。
ステップ 2 バージョン情報が BAC リリース 4.0 を示すかどうかを確認するには、次のように入力します。
ステップ 3 手作業で DPE プロセスを再起動し、アップグレード プロセスを完了する必要があります。
Network Registrar 拡張のアップグレード
Cisco Network Registrar 拡張をアップグレードする前に、 BPR_HOME/cnr_ep/conf ディレクトリにあるファイルをアーカイブすることを推奨します。
Network Registrar 拡張を BACC 2.6.2.7 から BAC 4.0 にアップグレードするには、次の手順を実行します。
ステップ 1 pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac コマンドを実行します。
ステップ 2 要求されたら、Network Registrar Server Agent を停止します。
アップグレード スクリプトにより、アップグレードされた拡張ポイント ファイルが必要なディレクトリに自動的にコピーされます。コピーが完了すると、Network Registrar Server Agent を再起動するように要求されます。
ステップ 3 出力情報が BAC リリース 4.0 を示すかどうかを確認するには、次のように入力します。
ステップ 4 BPR_HOME/lib ディレクトリに移動します。アップグレードが成功した場合は、ディレクトリの内容が DPE アップグレードのインストール済みファイル リストのように表示され、libbprextensions-2x.so ファイルが追加されています。
ステップ 5 アップグレード プロセスが成功したことをもう一度確認する必要がある場合は、 CNR_HOME/extensions/dhcp/dex ディレクトリに移動し、次のファイルが表示されることを確認します。
インストールするコンポーネントによって、この手順で示されるディレクトリの内容は、上記の出力例とは異なる場合があります。
KDC のアップグレード
（注） BAC 4.0 の KDC には、新しいライセンスが必要です。BAC プロセス ウォッチドッグを起動する前に、適切なライセンスと証明書がインストールされていることを確認します。
KDC を BACC 2.6.2 から BAC 4.0 にアップグレードするには、次の手順を実行します。
ステップ 1 pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac コマンドを実行します。
ステップ 2 手作業で BAC プロセス ウォッチドッグを起動し、アップグレード プロセスを完了します。
ステップ 3 出力情報が BAC リリース 4.0 を示すかどうかを確認するには、次のように入力します。
RDU データベースの移行
RDU データベース移行スクリプトを使用すると、RDU データベースを BACC 2.6.2.7 から BAC 4.0 に移行できます。
1. フェーズ 1：このフェーズは、BAC がインストールされ、 migrateDb.sh ツールによって実行された後に実行されます。
2. フェーズ 2：このフェーズは、移行の第 1 フェーズが完了した後、初めて RDU を起動したときに実行されます。
移行スクリプト（ migrateDb.sh ）は、BAC 4.0 インストール プログラム（ pkgadd ）の実行時に自動的にインストールされます。移行は、元のデータベースを読み込み、これを新しいデータベースに書き込むことによって行われます。このため、新しく作成されるデータベースを格納するための追加のディスク領域を割り当てる必要があります。
移行の第 1 フェーズは移行ログ ファイルに記録されます。このファイルは、移行されたデータベース ディレクトリに格納されます。 migration.log ファイルは移行するデータベースのバージョンを識別し、ステータス メッセージを移行プロセスに提供します。
（注） 移行により、データベース内に保存されている未処理のジョブ（Configuration Regeneration Service（CRS）ジョブの実行が完了していなかったり、保留になったりしている信頼性の高いバッチなど）は削除されます。
移行したデータベースで 4.0 RDU を使用し、前のバージョンの Solaris DPE や Network Registrar サーバを動作させ、段階的にオンライン移行することができます。
移行しても、DPE 同期で使用されるデバイス レコード リビジョン番号は保持されます。このため、RDU データベースをアップグレードしても DPE の再設定は起動されず、特定の DPE をアップグレードするまでは、少なくとも破損することはありません。
（注） この BAC リリースでは、オプション 43 とそのサブオプションにより、マルチベンダーがサポートされています。このオプションを使用すると、前のリリースで使用していたテンプレートを修正し、BAC 4.0 で使用されているテンプレート文法と互換がとれるようにすることができます。
大型の BAC RDU データベースではサイズが数ギガバイトになることもあり、移行に長時間を要する場合があります。データベースの移行に要する時間は、ハードウェアによって大きく異なります。高速ディスクを使用すると、時間も大幅に短縮されます。
移行では、断片化可能なデータベースは自動的に圧縮されます。しかし、この BAC リリースでは、デバイスごとに追加データが格納されます。移行後、データベースのサイズは 10 パーセントも増加すると予想されます。
この移行プロセスは、速度とデータベースの圧縮に応じて最適化されます。このため、移行には大量のプロセス ヒープ サイズ（メモリ）が必要になります。たとえば、700 万デバイスのデータベースの移行には、約 1,024 MB のプロセス ヒープ サイズが必要です。移行プロセスは 4 GB のヒープ空間に制限されているため、事実上、移行はサイズが約 2,500 ～ 3,000 万デバイスのデータベースに制限されています。
migrateDb.sh スクリプトの -Xmx パラメータによって、移行用の最大プロセス ヒープ サイズが決まります。このパラメータのデフォルト値は 3,072 MB で、2,000 万デバイス データベースの移行の場合はこのサイズで十分です。ご使用の環境に合わせて、この値を微調整する必要があります。たとえば、メモリが比較的小さいローエンド システムで実行している小型のデータベースを移行する場合は、最大ヒープ サイズの設定値をデフォルト値より小さくできます。サポートされている最大サイズを超えるデータベースの場合は、この設定値を大きくする必要があります。
ヒープ サイズのパラメータを変更するには、 migrateDb.sh スクリプト内にある -Xmx パラメータの値を編集します。
このリリースでは、ライセンシング方式が大きく変更されました。前のバージョンの BAC のライセンス キーを使用して、BAC 4.0 を使用しているネットワークにプロビジョニングすることはできません。既存のすべてのライセンス キーは、データベースの移行時に削除されます。BAC ライセンシングを設定するには、ライセンス要求プロセスによってライセンス ファイルを取得し、管理者ユーザ インターフェイスを使用してこれらをインストールする必要があります。詳細については、『 Release Notes for Broadband Access Center 4.0 』を参照してください。
移行時に、データベース内のプロビジョニング グループのデバイス数に基づいて、デバイス カウンタが再計算されます。新しいカウンタが新しいデータベースに記録され、ライセンシングに使用されます。
データベースの移行時に、カスタム拡張は 4.0 デフォルトにリセットされます。4.0 環境で動作するように、カスタム拡張をアップデートする必要があります。移行後にカスタム拡張が必要になった場合は、管理者ユーザ インターフェイスを使用してカスタム拡張を追加する必要があります。詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。
この BAC リリースは、サービス クラスとノードに対してテクノロジー間で重複した名前はサポートしていません。データベースの移行時に重複した名前が検出された場合は、自動的に次の形式で名前変更されます。
• サービス クラス：{ Technology_Name }_{ Original_ClassOfService_Name }
• ノード：{ Node_Type }_{ Node_Name }
たとえば、コンピュータと DOCSIS モデムに対して gold サービス クラスが検出された場合、コンピュータのサービス クラスの場合は Computer_gold に、DOCSIS モデムのサービス クラスの場合は DOCSISModem_gold に名前変更されます。該当する警告がコンソールと移行ログに発行され、特定のサービス クラスの値を含むすべてのプロパティが自動的に更新されます。
データベースの保全性の確認
RDU のダウンタイム中に、本番システムではなくステージング（本番ではない）システムで移行プロセスのリハーサルを行うことを推奨します。大型データベースの場合、保全性の確認には長時間を要するため、次の手順は本番の移行に適用できない可能性もあります。
• 移行の前に、バックアップ スナップショットで verifyDb.sh ツール を実行します。
（注） 移行前にデータベースの保全性を確認するには、対応するバージョンのデータベースの BAC インストールから verifyDb.sh ツールを実行します。移行していないデータベースに対しては、BAC 4.0 バージョンの verifyDb.sh を使用した保全性の確認はできません。
このパス名は、移行前の BAC インストール バージョン専用のものです。
• 移行後、移行したデータベースで verifyDb.sh ツールを実行します。
verifyDb.sh ツールの詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。
RDU 移行のワークフロー
RDU データベースの移行は、次の 2 つのフェーズからなります。
1. フェーズ 1：このフェーズは、 migrateDb.sh ツールによるインストールの後に実行されます。
2. フェーズ 2：このフェーズは、移行の第 1 フェーズが完了した後、初めて RDU を起動したときに実行されます。
表5-2 で説明している移行プロセスでは、次のことが前提になっています。
• BAC はデフォルトのホーム ディレクトリ（ /opt/CSCObac ）にインストールされている。
• 前のバージョンの RDU データベースのバックアップは、 /disk1/backup ディレクトリにある。
|
|
|
|
|---|---|---|
2 つのディスク パーティションを選択します。1 つは移行したデータベース用で、もう 1 つはデータベース トランザクション ログを一時的に格納するディレクトリ用です。
（注） パフォーマンス上の理由から、上記のディスクは高速 I/O システム（バッテリバックアップ付きの書き込みキャッシュを備えた RAID アレイや RAM ディスクなど）に設定することを推奨します。RAM ディスクを使用した移行の詳細については、「RAM ディスクを使用した移行」を参照してください。 この手順の例で使用しているパーティションは、次のとおりです。 • 移行したデータベースには、元のデータベース（バックアップ ディレクトリにある bpr.db ファイル）のサイズの 120 パーセント以上のディスク領域を確保する必要があります。 • 一時保管ディスクには、2 GB 以上の空き領域が必要です。ただしパフォーマンス上の理由から、このディレクトリは、バックアップ データベースやデータベースのインストール先のディクスとは別のディスクに配置することを推奨します。 |
||
バックアップしたデータベースで migrateDb.sh ツールを実行します。 migrateDb.sh スクリプトは、 BPR_HOME/migration ディレクトリにあります。 • • •
（注） 新しいデータベース ログ ファイルがこのディレクトリに作成され、後で移行時に自動的に破壊されます。移行が完了すると、必要なすべてのファイルがこのディレクトリから /disk2/target に自動的にコピーされます。移行後、このディレクトリを削除できます。 |
||
migration.log ファイルを使用して、移行の進行状況を観察します。 |
||
migration.log ファイルを使用して、移行が完了したかどうかを確認します。警告や注意が表示されている場合は、 grep コマンドライン ツールを使用します。 
|
||
移行したデータベースを 4.0 RDU の該当するディレクトリに復元します。このプロセスでは、移行したデータベースが RDU BPR_DATA ディレクトリと BPR_DBLOG ディレクトリにコピーされます。
（注） 移行プロセスが完了したら、/disk2/target ディレクトリと /disk3/target ディレクトリの内容を削除できます。 |
||
BAC ウォッチドッグ プロセス コマンドラインから RDU プロセスを開始し、初期化の成功を示すメッセージが rdu.log ファイル内にあるかどうか探します。 |
||
| たとえば、 rdu.log に次のようなメッセージが表示されます。 |
||
| たとえば、 rdu.log に次のようなメッセージが表示されます。 |
||
| たとえば、 rdu.log に次のようなメッセージが表示されます。 また、 BPR_DATA/rdu/DB_VERSION ファイルでデータベース バージョンが 4.0 と表示されているかどうかも確認します。 |
||
|
（注） 移行しても、DPE 同期で使用されるデバイス レコード リビジョン番号は保持されます。このため、RDU データベースをアップグレードしても DPE の再設定は起動されず、特定の DPE をアップグレードするまでは、少なくとも破損することはありません。 |
||
管理者ユーザ インターフェイスにログインして、RDU の動作を確認します。 Servers > RDU から、RDU のバージョンとデバイス数の統計情報を確認できます。 |
||
migrateDb.sh ツールの使用
表5-3 は、 migrateDb.sh ツールで使用可能な引数を説明しています。
RAM ディスクを使用した移行
RAM ディスクとは Solaris の機能で、RAM の一部をディスク ボリュームとしてマウントできるようにするものです。そのようなボリューム上でのディスク I/O 動作は非常に高速で、十分なメモリを備えているシステム上で大型データベースを使用している場合に役立ちます。
この項で説明する手順はオプションです。この項では、通常のディスク（バッテリバックアップ付きの書き込みキャッシュを備えた高速 RAID アレイなど）の代わりに、異なる RAM ディスクを作成および使用してデータベースを移行する方法について説明します。
移行用の RAM ディスクの作成
次の手順では、移行用の 3 つのボリュームを作成します。元のデータベースのサイズは 9 GB とします。データベースの必要性や使用可能なメモリに応じて、ボリューム サイズを調整してください。
次の手順を実行して、移行に使用する 3 つの RAM ディスクを作成します。
• /ram-disk2 ：移行するデータベース ディレクトリの格納用
• /ram-disk3 ：一時移行トランザクション ログの格納用
ステップ 1 /etc/system ファイル内の RAM ディスクに十分なメモリが割り当てられていることを確認します。この値は、システム上の合計 RAM のパーセンテージになります。64 GB RAM の場合、この設定では 32 GB が RAM ディスクに割り当てられます。
（注） OS I/O バッファ キャッシュに割り当てられるメモリ量を決める segmap_percent パラメータも設定する場合は、両方の設定に対して十分なメモリがあることを確認し、OS 動作用に一部の空き領域を残しておきます。
ステップ 4 各ボリュームに新しいファイル システムを作成します。
ステップ 6 マウント ポイントとそれらのサイズを確認します。
移行用の RAM ディスク ボリュームの使用
移行用に作成した RAM ディスク ボリュームを使用するには、次の手順を実行します。
ステップ 1 データベースのバックアップを /ram-disk1 にコピーします。
ステップ 2 表5-2 で説明している手順に従って、移行の第 1 フェーズを実行します。この表のステップ 2 で説明しているコマンドの代わりに、ここで説明しているコマンドを必ず使用してください。
-targetdbdir /ram-disk2/target -targetdblogdir /ram-disk3/target
&> /var/run/migration-console.log &
ステップ 3 移行の第 2 フェーズが RAM ディスクのデータベースで実行されたことを確認するには、次の手順を実行します。
a. データベース ディレクトリおよびデータベース ログ ディレクトリ（それぞれ BPR_DATA 変数および BPR_DBLOG 変数で定義される）が RAM ディスク上のボリュームを指し示すように、4.0 RDU をインストールします。
b. 移行の第 2 フェーズが完了したら、BAC プロセス ウォッチドッグのコマンドラインから /etc/init.d/bprAgent stop コマンドを実行して、BAC プロセス ウォッチドッグを停止します。
c. 次のコマンドを使用して、データベースをバックアップします。
BPR_HOME /rdu/bin/backupDb.sh -nosubdir /ram-disk X /migrated-db/
– BPR_HOME ：ホーム ディレクトリ（デフォルトは /opt/CSCObac ）を指定する。
– X ：データベースの移行先の RAM ディスクを指定する。
d. ホーム ディレクトリ（デフォルトは /opt/CSCObac ）にある bpr_definitions.sh ファイルを編集し、 BPR_DATA の場所と BPR_DBLOG の場所を、永続ストレージ ドライブ上にある新しいディレクトリに変更します。
e. データベースを新しい RDU の場所に復元します。 recoverDb.sh スクリプトと restoreDb.sh スクリプトを、それぞれ次のコマンドを使用して実行します。
BPR_HOME /rdu/bin/recoverDb.sh
BPR_HOME にはホーム ディレクトリ（デフォルトは /opt/CSCObac ）を指定する。
BPR_HOME /rdu/bin/restoreDb.sh /ram-disk X /migrated-db/
– BPR_HOME ：ホーム ディレクトリ（デフォルトは /opt/CSCObac ）を指定する。
– X ：データベースの移行先の RAM ディスクを指定する。
これらのスクリプトの使用方法の詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。
f. /etc/init.d/bprAgent start コマンドを実行して、プロセス ウォッチドッグを起動します。
フィードバック