- このマニュアルについて
- Broadband Access Center for Cable の概要
- Broadband Access Center for Cable システム アーキテクチャ
- 設定のワークフローとチェックリスト
- DOCSIS 設定
- PacketCable 音声設定
- CableHome の設定
- データベース管理
- 管理者のユーザ インターフェイスにつ いて
- Broadband Access Center for Cable 管理者のユーザ インターフェイスの使 用方法
- Broadband Access Center for Cable の設定
- サンプル ユーザ インターフェイスの 設定および使用方法
- Broadband Access Center for Cable がサポートするツールと高度な概念
- アラートとエラー メッセージ
- PacketCable DHCP オプションと BACC プロパティのマッピング
- Broadband Access Center for Cable のアプリケーション プログラミング インターフェイスの使用例
- 用語集
- 索引
Cisco Broadband Access Center for Cable アドミニストレータ ガイド Release 2.7
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月30日
章のタイトル： データベース管理
データベース管理
この章では、RDU データベースの管理および保守について説明します。RDU データベースは、Broadband Access Center for Cable（BACC）の中央データベースです。他のデータベースと同様に、管理者がデータベースのバックアップ手順と回復手順を理解し、熟知していることが必要です。
障害復元力について
RDU データベースでは、アプリケーション障害、システム障害、停電のような予測できない問題などが原因で発生するデータベースの破損を防止するために、 先行書き込みロギング と呼ばれる手法を使用しています。
先行書き込みロギングでは、データベース ファイルに変更を書き込む前に、すべてのデータベース変更の記述をログ ファイルに書き込みます。これによって、システム障害の原因になった可能性がある不適切なデータベース書き込みを修復できます。
RDU サーバでは、起動されるたびに自動回復が実行されます。この回復処理時に、データとデータベース ファイルとの同期をとるために、ログ ファイルが使用されます。ログには書き込まれたものの、データベースには書き込まれていなかったデータベース変更は、この自動回復の処理中にデータベースに書き込まれます。
このようにして、先行書き込みロギングによって、RDU サーバの再起動時にデータベースが自動的に修復されるので、RDU サーバの障害時にデータベースが破損しないことが実質的に保証されます。
先行書き込みロギングが正しく機能するには、次の条件が必要です。
•
ファイル システムおよび物理ストレージが、要求時にデータを確実に物理ストレージ内にフ
ラッシュするように設定されている必要があります。たとえば、書き込みキャッシュが RAM だけで構成されたストレージ システムは、システム障害中にデータが失われるので、適切ではありません。ただし、ディスクアレイの書き込みキャッシュがバッテリー バックアップされていて、システム障害時にもデータが失われないことが保証されている場合は正しく機能します。
• ファイル システムは、RDU データベースのブロック サイズに合せて、ブロック サイズが 8192 バイトに設定されている必要があります。Solaris では、通常、明示的に調整しないかぎり、このブロック サイズがデフォルトで設定されます。
データベース ファイル
RDU データベースでは、ファイルが格納されたパーティションをマウントしたファイル システムを使用して、データがバイナリ ファイルに保存されます。システム障害発生後の回復時間が長くならないようにファイル システムを選択し、設定することがきわめて重要です。
データベース ファイルは RDU の動作にとってきわめて重要です。したがって、誤って削除するなどの手作業による操作が行われないように、データベース ファイルを保護するための特別な予防措置を講じる必要があります。これらの重要ファイルを保護するための標準的なシステム管理方法に従ってください。たとえば、これらのファイルには、root ユーザだけがアクセス可能なアクセス権を与える必要があります。また、運用中のシステムには root ユーザではなく、root ユーザよりも権限の低いユーザとしてログインし、sudo コマンドを使用して root 特権が必要なタスクを実行することも、有効な方法です。
（注） バックアップ、復元、および回復の各ツールを使用して、それぞれの作業をデータベースで行います。Broadband Provisioning Registrar（BPR）の旧リリースでは、特定のツールを使用しないでこれらの作業の一部を直接行うことが可能でした。ツールを使用しないでこれらの作業を行うことは避けてください。これらのツールの詳細については、「バックアップと回復」を参照してください。
データベース ストレージ ファイル
RDU サーバは、データベース ディレクトリにある bpr.db というファイルに自身のデータベースを格納します。このディレクトリは <BACC_DATA>/rdu/db ディレクトリにあり、コンポーネントのインストール時に BACC_DATA パラメータを指定することで設定します。データベースの移動の詳細については、「データベースの場所の変更」を参照してください。
（注） 通常、データベース ファイルはランダムにアクセスされます。したがって、最高のデータベース パフォーマンスを得るためには、シーク時間が最も速く、回転アクセス レイテンシが最も小さいディスクを選択する必要があります。
データベースのトランザクション ログ ファイル
RDU サーバでは、データベースのトランザクション ログは 10 MB のファイルに保存され、そのファイルはデータベースのログ ディレクトリに保存されます。このディレクトリは、BACC_DBLOG パラメータを指定することでインストール時に設定します。ログ ディレクトリは、
<BACC_DBLOG>/rdu/dblog ディレクトリにあります。トランザクション ログの新しいディレクトリへの移動の詳細については、「データベースの場所の変更」を参照してください。
データベースのログ ファイルの名前には、最初に log.00000001、次に log.00000002 というように連番が付けられます。
（注） トランザクション ログが保存されるディスクは、通常、シーケンシャルにアクセスされるので、
データはログ ファイルの最後に追加されます。最高のデータベース パフォーマンスを達成するには、このアクセス パターンを効率的に処理できるディスクを選択する必要があります。
自動ログ管理
データベースのトランザクション ログ ファイルは、トランザクション データのデータベースへの書き込みが完了するまで、そのデータを保存しておくために使用されます。その後、トランザクション ログ データは冗長になりますが、RDU サーバのデータベースはトランザクション ログ ファイルを自動的に管理するので、ファイルが自動的にシステムから削除されます。通常の状況では、データベースのトランザクション ログ ディレクトリ内にあるログ ファイルの数は数個以内にする必要があります。時間の経過とともに古いトランザクション ログはなくなり、新しいトランザクション ログが作成されます。
（注） データベースのトランザクション ログは、データベースにとって不可欠です。トランザクション ログ ファイルを手動で削除すると、データベースが破損することがあります。
各種データベース ファイル
データベース ディレクトリには、他にもデータベースの動作に不可欠なファイルが保存されています。これらのファイルは、bpr.db ファイルとともに <BACC_DATA>/rdu/db ディレクトリにあり、データベース バックアップの一環としてコピーされます。
• DB_VERSION：データベースの物理的および論理的なバージョンを識別するためのもので、RDU によって内部で使用されます。
• history.log：ログ ファイルの自動的な削除、バックアップ、回復、復元処理などの不可欠なデータベース管理タスクに関するロギング動作のために使用されます。このログ ファイルは、管理者に有用な履歴情報を提供するだけでなく、RDU のデータベース処理にとっても非常に重要です。
ディスク容量の要件
完全に実装されたデータベースのサイズは、多くの要素で決まります。重要な要素は、RDU によって管理されるデバイス オブジェクトの数と、各オブジェクト上に保存されているカスタム プロパティの数です。各パーティション上で必要なディスク容量の概算値は、次のとおりです。
• BACC_DATA（デバイス オブジェクトごとに約 3 ～ 5 KB）
disk_monitor.sh コマンドを使用すると、使用可能なディスク容量を監視したり、管理者に警告したりできます。詳細については、「利用可能なディスク領域を監視するための disk_monitor.sh ツールの使用方法」を参照してください。
ディスク容量不足の対処方法
RDU サーバでディスク容量が不足すると、syslog ファシリティを通じて syslog アラートが生成され、RDU ログが記録されます。その後、RDU サーバは自動的に再起動を試みます。RDU サーバが再起動を試みたときにディスク容量不足のエラーが再び発生し、もう一度再起動が試みられる場合があります。
RDU サーバは、空きディスク容量が使用可能になるまで、繰り返し再起動しようとします。空き容量がなくなっているディスク上である程度のディスク領域を解放すると、次の再起動で RDU が正常に起動します。
データベースのサイズが増大して現在のディスク パーティションの容量を超えた場合、そのデータベースを新しいディスクまたはパーティションに移動する必要があります。この操作を行う方法については、「データベースの場所の変更」を参照してください。
（注） ディスク容量の使用率を監視して障害を防止するのが望ましい方法です。詳細については、「利用可能なディスク領域を監視するための disk_monitor.sh ツールの使用方法」を参照してください。
バックアップと回復
RDU サーバは、サーバを停止したり、サーバの活動を一時停止したりしなくても実行できる、効率性の高いバックアップ処理をサポートしています。データベースのバックアップおよび回復は、次の手順から構成されます。
• バックアップ：稼働中のサーバから RDU データベースのスナップショットをとります。
• 回復：データベース スナップショットを再利用するための準備をします。
• 復元：回復したデータベース スナップショットを RDU サーバにコピーします。
これらの手順のそれぞれに自動ツールが用意されています。これらのツールは対話モードまたはサイレント モードで使用できますが、これらのツールを使用するには root 特権が必要です。
データベースのバックアップ
バックアップとは、データベース ファイルをバックアップ ディレクトリにコピーする処理です。そのときに、これらのファイルを圧縮し、テープやその他のアーカイブに保存することができます。
RDU データベースのバックアップは、サーバのアクティビティを中断しないでファイルをコピーするだけなので、非常に効率的です。ただし、RDU データベース ディスクにアクセスするため、バックアップを行うと RDU のパフォーマンスが低下する場合があります。その逆の場合もあります。バックアップ中に発生した RDU のアクティビティにより、バックアップのパフォーマンスが低下します。そのため、バックアップは、RDU の使用率の低い時間帯に行う必要があります。
バックアップのパフォーマンスは、同時に実行されているシステム アクティビティ以外に、基礎となっているディスクおよびファイル システムのパフォーマンスからも影響を受けます。基本的にバックアップ速度は、データベース ファイルをコピー元からコピー先へコピーする速度と同じです。
<BACC_DATA>/rdu/bin ディレクトリにある backupDb.sh コマンドを使用して、データベースのバックアップを行います。
• このコマンドを使用するには、バックアップ ファイルを保存するバックアップ先ディレクトリを指定する必要があります。このディレクトリは、現在のデータベース ファイル サイズの 120% に相当する使用可能ディスク容量があるディスクまたはパーティション上に存在する必要があります。
• 次の例で説明するように、このコマンドは、ユーザが指定したディレクトリの下に、タイムスタンプ付きのサブディレクトリを自動的に作成し、そこにバックアップを保存します。
例
• /var/backup ：データベースのバックアップ ディレクトリを指定します。
この例では、バックアップするすべてのデータベース ファイルは /var/backup/rdu-backup- 09252002-130345 というディレクトリにストアされます。最下位のサブディレクトリ（rdu-backup- 09252002-130345）は自動的に作成され、現在のタイムスタンプが付けられます。
（注） タイムスタンプ付きのサブディレクトリの形式は、rdu-backup-MMddyyyy-HHmmss が使用されます。この例では、サブディレクトリは rdu-backup-04272003-175430 になります。これは、そのディレクトリに 2003 年 4 月 27 日午後 5 時 54 分 30 秒に開始したバックアップが保存されていることを意味しています。
また、backupDb.sh コマンドは、自動的に経過を画面にレポートし、その動作を履歴ログに記録します。
（注） backupDb.sh コマンドを使用するときに、-help オプションを使用すると、使用状況情報を取得できます。また、必要であれば、-nosubdir という別のオプション フラグを使用して、サブディレクトリの自動作成をディセーブルにできます。
データベースの回復
データベースの回復とは、データベースを一貫性のある状態に戻す処理です。バックアップは稼働中の RDU 上で行われるので、データベースはコピー中に変更される場合があります。ただし、データベースのログ ファイルによって、データベースを一貫性のある状態に戻せることが保証されています。
回復は、データベースのスナップショットに対して行われます。つまり、このタスクは、稼働中の RDU サーバ上のデータベースには作用しません。回復タスクは、バックアップの直後か、または、データベースを RDU サーバに復元する前に実行できます。
（注） シスコでは、バックアップを行うたびに、その直後に回復を行うことを推奨しています。この方法をとると、緊急時にバックアップしたデータベースをより速やかに復元できます。
データベースの回復に要する時間は、バックアップの一環としてコピーするデータベースのログ ファイルの数によって決まり、したがって、バックアップの実行時の RDU のアクティビティ レベルによって決まります。バックアップの実行時に RDU が同時に実行している活動の数が多いほど、バックアップの一環としてコピーする必要があるトランザクション ログ ファイルの数が多くなり、回復に要する時間が長くなります。一般に、データベースの回復の所要時間は、トランザクション ログ ファイル当たり 10 ～ 60 秒です。
<BACC_DATA>/rdu/bin ディレクトリにある recoverDb.sh コマンドを使用して、データベースのスナップショットの回復を行います。このコマンドを使用するときは、バックアップの場所を指定する必要があります。このディレクトリでは、回復も行われます。
例
この例では、/var/backup/rdu-backup-04272003-130345 ディレクトリにあるスナップショットを一貫性のある状態に回復します。回復処理の経過は画面に表示され、そのアクティビティはスナップショット ディレクトリにある history.log ファイルに記録されます。
（注） recoverDb.sh コマンドを使用するときに、-help オプションを使用して、使用状況情報を取得できます。
データベースの復元
データベースの復元とは、あらかじめ回復したデータベースのスナップショットを、RDU サーバによって使用されるデータベース上の場所にコピーする処理です。復元できるのは、あらかじめ回復しておいたデータベースだけです。
データベースの復元とは現行の RDU データベースの交換を意味するので、最初に古いデータベースを適切に削除し、アーカイブすることが非常に重要になります。
（注） 置換中にデータベースの削除を絶対に行わないでください。古いデータベースのコピーを残しておくと、将来のシステム診断が簡単になる場合があります。
<BACC_DATA>/rdu/bin ディレクトリにある restoreDb.sh コマンドを使用して、現行の RDU データベースを別のデータベースと置換します。このコマンドを使用するときは、入力ディレクトリを指定する必要があります。このディレクトリには、RDU サーバに復元するデータベースの、回復したバックアップ スナップショットが含まれている必要があります。
（注） restoreDb.sh ユーティリティを実行する前に、RDU サーバを停止する必要があります。
例
restoreDb.sh ユーティリティの実行例を次に示します。
この例では、/var/backup/rdu-backup-042752003-130345 ディレクトリにあるデータベースが RDU サーバに復元されます。
（注） restoreDb.sh コマンドを使用するときに、-help オプションを使用すると、使用状況情報を取得できます。
復元処理の完了後は、RDU を再起動する必要があります。RDU ログ ファイルには、起動が成功したことを示すメッセージが書き込まれます。
データベースの場所の変更
あるパーティションまたはディスクから、同じシステム上の別のパーティションまたはディスクにデータベースを移動することができます。管理上の理由で、この処理が必要になる場合があります。この処理を行うには、RDU サーバおよび BPR エージェントを停止する必要があります。
データベースの場所を変更する処理では、1 つまたは 2 つのシステム パラメータを変更し、該当のファイルを新しい場所にコピーします。次のパラメータの一方または両方を調整できます。
• BACC_DATA：このパラメータは、インストール時に最初に設定され、データベース、およびログや設定ファイルなどその他多くの重要なファイルが保存されるディレクトリを示しています。
• BACC_DBLOG：このパラメータは、インストール時に最初に設定され、データベースのトランザクション ログ ファイルが保存されるディレクトリを示しています。
上記のパラメータの値は、<BACC_DATA>/bpr_definitions.sh というファイルに記録されます。このファイルを変更した場合、システム上で実行されているすべての BACC コンポーネントを再起動する必要があります。
データベースおよびトランザクション ファイルの場所を変更するには、次の手順に従います。
ステップ 1 /etc/init.d/bprAgent stop コマンドを実行して BACC エージェントを停止します。
ステップ 2 <BACC_DATA>/bpr_definitions.sh ファイルのバックアップ コピーを作成します。
ステップ 3 このファイルを編集して、BACC_DATA パラメータおよび BACC_DBLOG パラメータの一方または両方を新しいディレクトリに変更します。
ステップ 5 BACC_DATA ディレクトリと BACC_DBLOG ディレクトリの一方または両方の元のディレクトリ構造および内容を、新しい場所にコピーまたは移動します。コピーを行う場合は、すべてのファイルおよびディレクトリのアクセス権が維持されるようにしてください。
ステップ 6 / etc/init.d/bprAgent start コマンドを実行して、BACC エージェントおよびすべての BACC コンポーネントを起動します。
ステップ 7 該当のログ ファイルを監視して、すべてのコンポーネントが正常に起動したことを確認します。
RDU データベースの移行
RDU データベースの移行に関する情報は、すべて『Cisco Broadband Access Center for Cable Installation Guide』に記載されています。
フィードバック