Cisco Broadband Access Center インストレーション ガイド Release 4.0
Broadband Access Center の アップグレード
Broadband Access Center のアップグレード
発行日;2012/02/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 995KB) | フィードバック

目次

Broadband Access Center のアップグレード

始める前に

RDU のアップグレード

DPE のアップグレード

Network Registrar 拡張のアップグレード

KDC のアップグレード

RDU データベースの移行

データベースの保全性の確認

RDU 移行のワークフロー

migrateDb.sh ツールの使用

RAM ディスクを使用した移行

移行用の RAM ディスクの作成

移行用の RAM ディスク ボリュームの使用

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 台のサーバを移行できます。


注意 4.0 にアップグレードする前に、このリリースでサポートされているライセンス ファイルを取得していることを確認してください。アップグレードを実行すると、インストール プログラムは既存のライセンス キーをすべて削除します。その後、管理者ユーザ インターフェイスを使用して、4.0 でサポートされているライセンス ファイルをインストールします。ライセンス ファイルの取得とインストールの詳細については、『Release Notes for the Cisco Broadband Access Center 4.0』を参照してください。

表5-1 は、各 BAC コンポーネントに必要なアップグレード作業を要約しています。

 

表5-1 BAC 4.0 へのアップグレード

バージョン
RDU
DPE
Network Registrar 拡張ポイント
KDC

BACC 2.6.2.7


) RDU データベースの移行が必要です。


pkgadd を実行します。最後に、移行ツールを実行するように要求されます。

pkgadd を実行して DPE をアップグレードします。

pkgadd を実行して Network Registrar 拡張をアップグレードします。

pkgadd を実行して KDC をアップグレードします。

2.6.2.7 から 4.0 にアップグレードするときに、次のディレクトリの新しいインストール先を入力する必要があります。

ホーム ディレクトリ( BPR_HOME

データ ディレクトリ( BPR_DATA

データベース ログ ディレクトリ( BPR_DBLOG


) アップグレードが完了しても、自動的にプロセス ウォッチドッグ(bprAgent)が再起動されるわけではありません。まず、既存のデータベースを移行する必要があります。


BAC オンライン アップグレード手順では、指定されている次の順序でコンポーネントをアップグレードする必要があります。この順序でアップグレードを実行しないと、プロビジョニング中にエラーが発生します。

1. 「始める前に」

2. 「RDU のアップグレード」

3. 「DPE のアップグレード」

4. 「Network Registrar 拡張のアップグレード」

5. 「KDC のアップグレード」

始める前に

BAC コンポーネントをアップグレードする前に、RDU データベース ファイルをバックアップします。

RDU データベースをバックアップするには、 BPR_HOME/rdu/bin ディレクトリで backupDb.sh スクリプトを実行します。

次の例を参考にしてください。

# backupDb.sh /var/backup
 

/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 ディレクトリにあるファイルをアーカイブすることを推奨します。

RDU をアップグレードするには、次の手順を実行します。


ステップ 1 オペレーション サポート システムから RDU へのアクセスをディセーブルにします。

ステップ 2 backupDb.sh ツールを使用して、既存の RDU データベースをバックアップします。詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。

次の例を参考にしてください。

# /opt/CSCObpr/rdu/bin/backupDb.sh -nosubdir /disk1/backup
 

-nosubdir :サブディレクトリの自動作成をディセーブルにする。このオプションを指定しなかった場合、サブディレクトリが作成され、コンソールに表示されます。

/disk1/backup :データベース バックアップ ファイルの場所を指定する。

ステップ 3 BPR_DATA ディレクトリにある history.log ファイルをチェックして、データベースがバックアップされたかどうかを確認します。

ステップ 4 recoverDb.sh ツールを使用して、バックアップしたデータベースを一貫性のある状態に復元します。詳細については、『 Cisco Broadband Access Center Administrator Guide 4.0 』を参照してください。

次の例を参考にしてください。

# /opt/CSCObpr/rdu/bin/recoverDb.sh /disk1/backup
 

/disk1/backup には、データベース バックアップ ファイルの場所を指定します。

ステップ 5 バックアップ済みのデータベースを安全な場所にコピーします。

ステップ 6 既存の BAC バージョンを実行しているオペレーティング システム(OS)が 4.0 リリースの要件を満たしていない場合は、OS をアップグレードします。

ステップ 7 4.0 バージョンをインストールします。

次の例を参考にしてください。

# pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac
 

次のディレクトリの場所を入力するように要求されます。

ホーム ディレクトリ( BPR_HOME

データベース ディレクトリ( BPR_DATA

データベース ログ ディレクトリ( 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 コマンドを実行します。

次のような出力が表示されます。この出力は、簡潔にするため、不要な部分を削除しています。

Processing package instance <CSCObac> from </var/CSCObac.pkg>
 
Cisco BAC product
(sparc) 4.0
CSCObpr
 
Welcome to the Cisco Broadband Access Center for (BAC) installation program. This installation program installs BAC on your system.
 
 
Press Enter to Continue or q to Quit:
 
Upgrading BAC from 2.6.2.7 to 4.0. Are you sure? [n]: y
 
Stopping BAC Process Watchdog...
 
...
 
File installation completed.
...
 
Installation of <CSCObac> was successful.
 

ステップ 2 バージョン情報が BAC リリース 4.0 を示すかどうかを確認するには、次のように入力します。

# pkgparam CSCObac VERSION
 

ステップ 3 手作業で DPE プロセスを再起動し、アップグレード プロセスを完了する必要があります。

たとえば、コマンドラインが次のコマンドを実行します。

# /etc/init.d/bprAgent start 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 を示すかどうかを確認するには、次のように入力します。

# pkgparam CSCObac VERSION
 

ステップ 4 BPR_HOME/lib ディレクトリに移動します。アップグレードが成功した場合は、ディレクトリの内容が DPE アップグレードのインストール済みファイル リストのように表示され、libbprextensions-2x.so ファイルが追加されています。

ステップ 5 アップグレード プロセスが成功したことをもう一度確認する必要がある場合は、 CNR_HOME/extensions/dhcp/dex ディレクトリに移動し、次のファイルが表示されることを確認します。

-rwxr-xr-x 1 root bin 60904 Oct 29 2003 libdexextension.so
-rwxr-xr-x 1 root other 1530628 Jul 22 12:43 libbprextensions-2x.so
-rwxr-xr-x 1 root other 1560748 Aug 11 12:49 libbprextensions.so
 

インストールするコンポーネントによって、この手順で示されるディレクトリの内容は、上記の出力例とは異なる場合があります。


 

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 を示すかどうかを確認するには、次のように入力します。

# pkgparam CSCObac VERSION
 


 

RDU データベースの移行

RDU データベース移行スクリプトを使用すると、RDU データベースを BACC 2.6.2.7 から BAC 4.0 に移行できます。

移行作業は、次の 2 つのフェーズからなります。

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 』を参照してください。

移行時に、データベース内のプロビジョニング グループのデバイス数に基づいて、デバイス カウンタが再計算されます。新しいカウンタが新しいデータベースに記録され、ライセンシングに使用されます。

RDU 拡張の移行

データベースの移行時に、カスタム拡張は 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 を使用した保全性の確認はできません。


次の例を参考にして入力してください。

# /opt/CSCObpr/rdu/internal/db/bin/verifyDb.sh -dbdir /disk1/backup
 

このパス名は、移行前の BAC インストール バージョン専用のものです。

移行後、移行したデータベースで verifyDb.sh ツールを実行します。

次の例を参考にして入力してください。

# /opt/CSCObac/rdu/internal/db/bin/verifyDb.sh -dbdir /disk2/target
 

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 ディレクトリにある。

 

表5-2 RDU 移行のワークフロー

作業
参照先

ステップ 1

2 つのディスク パーティションを選択します。1 つは移行したデータベース用で、もう 1 つはデータベース トランザクション ログを一時的に格納するディレクトリ用です。


) パフォーマンス上の理由から、上記のディスクは高速 I/O システム(バッテリバックアップ付きの書き込みキャッシュを備えた RAID アレイや RAM ディスクなど)に設定することを推奨します。RAM ディスクを使用した移行の詳細については、「RAM ディスクを使用した移行」を参照してください。


この手順の例で使用しているパーティションは、次のとおりです。

ボリューム /disk2/target :移行したデータベースの書き込みに使用する。

移行したデータベースには、元のデータベース(バックアップ ディレクトリにある bpr.db ファイル)のサイズの 120 パーセント以上のディスク領域を確保する必要があります。

ボリューム /disk3/target :一時保管ディレクトリとして使用する。

一時保管ディスクには、2 GB 以上の空き領域が必要です。ただしパフォーマンス上の理由から、このディレクトリは、バックアップ データベースやデータベースのインストール先のディクスとは別のディスクに配置することを推奨します。

Solaris のマニュアル

ステップ 2

バックアップしたデータベースで migrateDb.sh ツールを実行します。 migrateDb.sh スクリプトは、 BPR_HOME/migration ディレクトリにあります。
このツールでサポートされているすべての引数の説明については、「migrateDb.sh ツールの使用」を参照してください。

次の例を参考にしてください。

# /opt/CSCObac/migration/migrateDb.sh -dbdir /disk1/backup -targetdbdir /disk2/target -targetdblogdir /disk3/target &> /var/run/migration-console.log &
 

-dbdir :移行するデータベース バックアップの場所を指定します。この例では、 /disk1/backup になります。

-targetdbdir :移行したデータベースを格納する場所を指定します。この例では、 /disk2/target になります。このディレクトリは移行時に自動的に作成されるもので、移行スクリプトの実行前に存在していてはいけません。

-targetdblogdir :一時移行トランザクション ログ ファイルの場所を指定します。この例では、 /disk3/target になります。このディレクトリは移行時に自動的に作成されるもので、移行スクリプトの実行前に存在していてはいけません。


) 新しいデータベース ログ ファイルがこのディレクトリに作成され、後で移行時に自動的に破壊されます。移行が完了すると、必要なすべてのファイルがこのディレクトリから /disk2/target に自動的にコピーされます。移行後、このディレクトリを削除できます。


Cisco Broadband Access Center Administrator Guide 4.0

ステップ 3

migration.log ファイルを使用して、移行の進行状況を観察します。

次の例を参考にしてください。

# tail -f /disk2/target/migration.log

Solaris のマニュアル

ステップ 4

migration.log ファイルを使用して、移行が完了したかどうかを確認します。警告や注意が表示されている場合は、 grep コマンドライン ツールを使用します。

次の例を参考にしてください。

# tail /disk2/target/migration.log
...
Tue Oct 16 15:36:20 EDT 2007: Phase 1 of RDU database migration to BAC 4.0 completed with 1 warning(s) and 2 notice(s).
 
# cat migration.log | grep "WARNING"
 
Tue Oct 16 15:57:23 EDT 2007: WARNING: Duplicate Class of Service name [cg814wg_chn_n05] detected for [CableHomeWanMan] technology. Class of Service object was renamed to [CableHomeWanMan_cg814wg_chn_n05].
 
# cat migration.log | grep "NOTICE"
 
Tue Oct 16 19:06:23 EDT 2007: NOTICE: A deprecated property [/dhcp/client-policy/response/boot-file] was found on object with oid [2882304375712137210]. Property will be declared as custom property.
 

ヒント migration.log ファイルの終わりに表示されるデバイス統計情報も役に立ちます。

Solaris のマニュアル

ステップ 5

移行したデータベースを 4.0 RDU の該当するディレクトリに復元します。このプロセスでは、移行したデータベースが RDU BPR_DATA ディレクトリと BPR_DBLOG ディレクトリにコピーされます。

次の例を参考にしてください。

# /opt/CSCObac/rdu/bin/restoreDb.sh /disk2/target
 

) 移行プロセスが完了したら、/disk2/target ディレクトリと /disk3/target ディレクトリの内容を削除できます。


Cisco Broadband Access Center Administrator Guide 4.0

ステップ 6

BAC ウォッチドッグ プロセス コマンドラインから RDU プロセスを開始し、初期化の成功を示すメッセージが rdu.log ファイル内にあるかどうか探します。

次の例を参考にしてください。

# /etc/init.d/bprAgent start rdu
 

Cisco Broadband Access Center Administrator Guide 4.0

ステップ 7

移行の第 2 フェーズが開始しているかどうかを確認します。

たとえば、 rdu.log に次のようなメッセージが表示されます。

bac-test.example.com: 2007 10 17 02:36:28 EDT: %BAC-RDU-6-0695: [Starting Phase 2 of RDU db migration].
 

Solaris のマニュアル

ステップ 8

移行の進行状況を観察します。

たとえば、 rdu.log に次のようなメッセージが表示されます。

bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Progress report for selection process...].
 
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Selection process stats: Read a total of 400000 DOCSISModem device records].
 
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Selection process stats: Read a total of 400000 device records].
 
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695: [Selection process stats: Ran selection on 398228 eligible devices].
 

Solaris のマニュアル

ステップ 9

移行の第 2 フェーズが完了したかどうかを確認します。

たとえば、 rdu.log に次のようなメッセージが表示されます。

bac-test.example.com: 2007 10 17 03:28:58 EDT: %BAC-RDU-6-0695: [Completed Phase 2 of RDU db migration].
 
bac-test.example.com: 2007 10 17 03:28:58 EDT: %BAC-RDU-6-0695: [RDU db migration has been finalized].
 

また、 BPR_DATA/rdu/DB_VERSION ファイルでデータベース バージョンが 4.0 と表示されているかどうかも確認します。

Cisco Broadband Access Center Administrator Guide 4.0


) 移行しても、DPE 同期で使用されるデバイス レコード リビジョン番号は保持されます。このため、RDU データベースをアップグレードしても DPE の再設定は起動されず、特定の DPE をアップグレードするまでは、少なくとも破損することはありません。


ステップ 10

管理者ユーザ インターフェイスにログインして、RDU の動作を確認します。 Servers > RDU から、RDU のバージョンとデバイス数の統計情報を確認できます。

Cisco Broadband Access Center Administrator Guide 4.0

migrateDb.sh ツールの使用

表5-3 は、 migrateDb.sh ツールで使用可能な引数を説明しています。

 

表5-3 migrateDb.sh ツールの引数

引数
説明
必須
オプション
デフォルト

-dbdir dir

移行するデータベースのバックアップの場所を指定します。

P

なし

-dblogdir dir

移行するデータベースのログの場所を指定します。

P

-dbdir オプションで指定されるディレクトリ

-targetdbdir dir

移行したデータベースを配置する場所を指定します。

P

なし

-targetdblogdir dir

移行するデータベース トランザクション ログ ファイルを移行中に一時的に格納する場所を指定します。

P

なし

-cachesize value

メモリ キャッシュのサイズを MB 単位で指定します。

このパラメータはオプションです。このパラメータを使用する場合、100 MB の制限を超えないようにする必要があります。ただし、migrateDb.sh スクリプトの -Xmx 変数の値を、キャッシュ サイズの増加分の 2 倍に相当する分だけ減少させた場合はこの限りではありません。たとえば、キャッシュ サイズを 200 MB に設定する場合は、 -Xmx の値を次のように減少させる必要があります。

(200-100)*2 = 200 MB

P

100 MB

-cmtsv value

サービスを選択するときに使用する CMTS DOCSIS のバージョンを指定します。CMTS とケーブル モデムでサポートされている最低バージョンに基づいて、サービスを選択します。ケーブル モデムでサポートされている DOCSIS のバージョンは、
dhcp-client-identifier
オプションの値によって決まります。設定可能な値は次のとおりです。

1.0

1.1

2.0

P

1.1

-help

ツールを使用することを指定します。

P

なし

次の項で説明するように、複数の引数を使用して、プロミスキャス デバイス用のサービス クラスと DHCP 基準を指定できます。これらの引数はオプションで、ここで説明しているように、デフォルトのオブジェクトがデータベース内に存在していることが条件です。これらのオブジェクトは、移行の第 1 フェーズで、プロミスキャス アクセス権を付与されたデバイス用のサービスの選択に使用されます。

移行の第 2 フェーズでは、RDU データベース内にあるポリシーに従って、各デバイス用の標準選択プロセスが実行されます。何らかの不一致への対処は、データベース内の設定を優先して行われます。ただし、不一致が少ないほど、移行プロセスの効率がよくなります。


ヒント 同じタイプのデバイスが異なるプロミスキャス ポリシー オブジェクトを使用している場合、これらのポリシー オブジェクトを正確に指定するのは難しいこともありますが、最も使用頻度の高いオブジェクトを指定すると、移行の効率が向上します。

-pcospc value

プロミスキャス コンピュータで最も使用頻度の高いサービス クラスの名前を指定します。

P

unprovisioned-computer

-pcosmta value

プロミスキャス MTA で最も使用頻度の高いサービス クラスの名前を指定します。

P

unprovisioned-packet-cable-mta

-pcoschwd value

プロミスキャス CableHome WAN-Data デバイスで最も使用頻度の高いサービス クラスの名前を指定します。

P

unprovisioned-cablehome-wan-data

-pcoschwm value

プロミスキャス CableHome WAN-MAN デバイスで最も使用頻度の高いサービス クラスの名前を指定します。

P

unprovisioned-cablehome-wan-man

-pcoscpe value

プロミスキャス カスタム CPE で最も使用頻度の高いサービス クラスの名前を指定します。

P

unprovisioned-customcpe

-pdcpc value

プロミスキャス コンピュータで最も使用頻度の高い DHCP 基準の名前を指定します。

P

genericCPE

-pdcmta value

プロミスキャス MTA で最も使用頻度の高い DHCP 基準の名前を指定します。

P

genericCPE

-pdcchwd value

プロミスキャス CableHome WAN-Data デバイスで最も使用頻度の高い DHCP 基準の名前を指定します。

P

genericCPE

-pdcchwm value

プロミスキャス CableHome WAN-MAN デバイスで最も使用頻度の高い DHCP 基準の名前を指定します。

P

genericCPE

-pdccpe value

プロミスキャス カスタム CPE で最も使用頻度の高い DHCP 基準の名前を指定します。

P

genericCPE

RAM ディスクを使用した移行

RAM ディスクとは Solaris の機能で、RAM の一部をディスク ボリュームとしてマウントできるようにするものです。そのようなボリューム上でのディスク I/O 動作は非常に高速で、十分なメモリを備えているシステム上で大型データベースを使用している場合に役立ちます。

この項で説明する手順はオプションです。この項では、通常のディスク(バッテリバックアップ付きの書き込みキャッシュを備えた高速 RAID アレイなど)の代わりに、異なる RAM ディスクを作成および使用してデータベースを移行する方法について説明します。

「移行用の RAM ディスクの作成」

「移行用の RAM ディスク ボリュームの使用」

移行用の RAM ディスクの作成

次の手順では、移行用の 3 つのボリュームを作成します。元のデータベースのサイズは 9 GB とします。データベースの必要性や使用可能なメモリに応じて、ボリューム サイズを調整してください。

次の手順を実行して、移行に使用する 3 つの RAM ディスクを作成します。

/ram-disk1 :ソース データベースの格納用

/ram-disk2 :移行するデータベース ディレクトリの格納用

/ram-disk3 :一時移行トランザクション ログの格納用


ステップ 1 /etc/system ファイル内の RAM ディスクに十分なメモリが割り当てられていることを確認します。この値は、システム上の合計 RAM のパーセンテージになります。64 GB RAM の場合、この設定では 32 GB が RAM ディスクに割り当てられます。

次の例を参考にしてください。

# less /etc/system
...
set ramdisk:rd_percent_physmem=50
 

) OS I/O バッファ キャッシュに割り当てられるメモリ量を決める segmap_percent パラメータも設定する場合は、両方の設定に対して十分なメモリがあることを確認し、OS 動作用に一部の空き領域を残しておきます。


ステップ 2 システムをリブートします。

次の例を参考にしてください。

# shutdown -i6 -g0 -y
 

ステップ 3 3 つの RAM ボリュームを作成します。

次の例を参考にしてください。

# ramdiskadm -a volume1 10g
# ramdiskadm -a volume2 12g
# ramdiskadm -a volume3 2g
 

ステップ 4 各ボリュームに新しいファイル システムを作成します。

次の例を参考にしてください。

# newfs /dev/ramdisk/volume1
# newfs /dev/ramdisk/volume2
# newfs /dev/ramdisk/volume3
 

ステップ 5 ボリュームをマウントします。

次の例を参考にしてください。

# rmdir /ram-disk1
# rmdir /ram-disk2
# rmdir /ram-disk3
 
# mkdir /ram-disk1
# mkdir /ram-disk2
# mkdir /ram-disk3
 
# mount /dev/ramdisk/volume1 /ram-disk1
# mount /dev/ramdisk/volume2 /ram-disk2
# mount /dev/ramdisk/volume3 /ram-disk3
 

ステップ 6 マウント ポイントとそれらのサイズを確認します。

次の例を参考にしてください。

# df -kh
 


 

移行用の RAM ディスク ボリュームの使用

移行用に作成した RAM ディスク ボリュームを使用するには、次の手順を実行します。


ステップ 1 データベースのバックアップを /ram-disk1 にコピーします。

次の例を参考にしてください。

# mkdir /ram-disk1/backup
# cp /disk1/backup/* /ram-disk1/backup/.
 

ステップ 2 表5-2 で説明している手順に従って、移行の第 1 フェーズを実行します。この表のステップ 2 で説明しているコマンドの代わりに、ここで説明しているコマンドを必ず使用してください。

次の例を参考にしてください。

# /opt/CSCObac/migration/migrateDb.sh -dbdir /ram-disk1/backup
-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 コマンドを実行して、プロセス ウォッチドッグを起動します。