IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  Information Management  >

テープ装置と一緒に! データマイグレーション機能

連載: IBM DB2 Content Managerの活用方法

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません


レベル: 初級

簗 敏之, 情報マネージメント技術/ 大和ソフトウェア開発研究所 , IBM

2006年 11月 17日

IBM Tivoli Storage Manager(TSM)を活用して、参照頻度の少ないコンテンツをLTO装置などの後方ストレージにアーカイブする機能は、階層記憶管理(HSM)と呼ばれています。コンプライアンスなどで削除が容易にできない場合に有効な機能であり、それについて解説します。

はじめに

IBM DB2 Content Manager バージョン 8 (以下、 Content Manager と略す)はデジタル化されたコンテンツの保管や管理をするための製品です。サーバーコンピュータにコンテンツを保管しますが、保管する領域には必ず、限りがあります。つまり、どんなに大規模なシステムでも放っておけばいつかは保管領域が満杯になってしまいます。

そのときが近づいてから「さあ、どうしよう。」と考えるのは設計者としては賢明とは言えません。保管領域が満杯になったときのことをあらかじめ想定した上でシステムを構築するべきです。

通常は、次の2つの方法を考えるのが一般的です。

  1. 保管領域を増やす。
  2. 不要なデータを消す。

ただし、1 は金銭的にも物理的にもなかなか実現が難しい場合がほとんどです。2 を選択したいところですが、法的に保管を義務付けられているコンテンツもあり、簡単に不要であるとは言い切れないデータも多くあります。そこで、次のことを検討します。

  1. 必要なデータは、保管期限を設けて、期限を過ぎたデータを強制的に別なストレージ装置に移動する。
  2. 不要となるデータは、保管期限を設けて、期限を過ぎたデータを強制的に削除する。

この 3 と 4 の機能を自動的に行う機能が、Content Managerの拡張機能のひとつである データマイグレーション機能 です。なお、 3 でいうところの別なストレージ装置とは安価で大容量の記憶装置、通常は テープ装置 のことです。

例を挙げると、保険会社の契約書関連を保管するコンテンツ管理システムなどが当てはまるでしょう。契約書は法的に一定期間の保管が義務付けられている場合もあり、たとえディスクが満杯になったからといっても不用意にデータを削除するわけにはいきません。しかし、古い契約書のほとんどは頻繁にアクセスされることはまずありません。そういったデータのために高価で高速なディスク装置の容量を確保しておくのはもったいない使い方です。そのような場合は、 3 や 4 の組み合わせによって保管されているデータの管理が必要になるわけです。

ここでは、 IBM Tivoli Storage Managerを使ったデータマイグレーション機能 に着目してご説明します。IBM Tivoli Storage Managerは記憶装置、特にテープ装置のデータ管理に大変優れている製品です。




上に戻る


Content Manager データマイグレーションの概念

例えば、「ある種の契約書は3年間の保管義務があり、登録してから半年経過したデータは自動的にテープ装置に移動して、その後2年半(計3年)経過したら自動的に削除される。」というようなシステムを構築することを考えてみましょう。

まずは、IBM DB2 Content Manager V8のデータ保存の仕組みから復習しましょう。

Content Managerは通常、「 ライブラリー・サーバー 」と「 リソース・マネージャ

」という2つのサーバーにコンテンツを分けて保管します。(1台のサーバーにすることも可能です。) その概念を示したのが下図です。データのアップロード(=インポート)を例としてシステム構造とアクセスやデータの流れについて示しています。


Content Manager V8 構成図
Content Manager V8 構成図

上図の右側の2台のサーバーがContent Managerサーバー(ライブラリー・サーバー、リソース・マネージャ)です。左側のサーバーがContent Managerクライアントです。このサーバーは、本当のクライアントコンピュータから見れば、アプリケーションサーバーという位置付けになります。

このシステムで、例として、「クライアントの"契約書001.xls"(1.5MB)というファイルをサーバーにインポートする」というケースを考えます。次の順序でアクセスやデータの動きが行われます。

  1. クライアントがアプリケーションサーバーのContent Managerクライアントアプリケーションにアクセスする。
  2. Content Managerクライアントアプリケーションがライブラリー・サーバーにアクセスする。
  3. ライブラリー・サーバー・データベースにファイル名や日付などの属性情報や管理情報などが書き込まれる。(データベースに1レコード追加される。)
  4. リソース・マネージャのトークン(=アクセス許可証)と位置情報をライブラリー・サーバーから取得して、それを元にリソース・マネージャにアクセスする。
  5. リソース・マネージャ・データベースにコピーされるファイルの位置情報やサイズなどが書き込まれる。(データベースに1レコード追加される。)
  6. リソース・マネージャのコンテンツ保管域に"契約書001.xls"がコピーされる。このときファイル名は管理IDに変換される。ファイルの圧縮などはされないのでファイルサイズは1.5MBのまま。
  7. ここまですべてエラーなく終了すればライブラリー・サーバー・データベースおよびリソース・マネージャ・データベースの情報がコミット(=書き換えの確定)される。

このように、ファイル"契約書001.xls"の情報はライブラリー・サーバーとリソース・マネージャの両方に分かれて入ります。ファイルがインポートされることによって使用容量が拡大するのは次の3箇所です。

  • ライブラリー・サーバー・データベース
  • リソース・マネージャ・データベース
  • リソース・マネージャのコンテンツ保管域

その中でも実際のファイルサイズに依存して 使用容量が大きくなるのはリソース・マネージャのコンテンツ保管域 です。上図で示される右下のファイルシステムのところです。ここに大容量のディスク装置が必要になります。

ただし、ディスク装置の容量サイズは無限ではありません。

さあ、次に、このディスク装置が満杯にならないように運用できるようなシステムを構築してみます。データマイグレーション機能を持つContent Managerのコンテンツ管理システム構成図とそのデータの動きを示したのが下図です。


データマイグレーション概念図
データマイグレーション概念図

上図の右側に位置するのがコンテンツ移動先となるサーバーです。図の例では3台のテープ装置とそれを管理するサーバーコンピュータから構成されています。テープ装置の管理ソフトウェアには、 IBM Tivoli Storage Manager(TSM)サーバー を使用します。

リソース・マネージャ側には IBM Tivoli Storage Manager(TSM)クライアント

が必要です。それから、リソース・マネージャの設定で「保管されたファイルは、半年後にTivoli Storage Managerのテープ装置に移動する」という設定を行います。この設定は「システム管理クライアント」と呼ばれるContent Manager付属の専用プログラムから行います。そして、項目タイプの作成時に「コンテンツの保管期限を3年に設定」しておきます。

それでは、データの流れを見てみましょう。

リソース・マネージャに保管された個々のコンテンツにはそれぞれテープ装置への移動日が設定されています。この例では登録されてから半年後です。この情報はリソース・マネージャ・データベースに保存されています。

移動日になったコンテンツはテープ装置へ自動的に移動されます。この動作を行うのがContent Managerのリソース・マネージャ・マイグレーション・ユーティリティ(RMMigratorControl)です。コピーではないのでコンテンツ保管域にあったオリジナルのファイルは削除されます。ライブラリー・サーバー・データベースやリソース・マネージャ・データベースの情報は移動しません。リソース・マネージャ・マイグレーション・ユーティリティのことをRMマイグレーターといいます。

テープ装置へ移動された後もユーザーはそのコンテンツに自由にアクセスできます。しかし、テープ装置なのでアクセス速度は速くありません。頻繁にアクセスされるコンテンツはリソース・マネージャの一時保存領域に読み出しておいて、そこへアクセスさせるという機能もあります。これを行うのがリソース・マネージャ・ステージング・ユーティリティ(RMStagerControl)です。一時保存領域のことをステージ領域といいます。リソース・マネージャ・ステージング・ユーティリティのことをRMステージャーといいます。

一方、個々のコンテンツには削除予定日が設定されています。この例では登録されてから3年後です。この情報はライブラリー・サーバー・データベースに保存されています。

ここで注意していただきたいのは、削除予定日になったコンテンツは自動的には削除されない、という点です。なぜなら、この削除という行為は自動で行われると間違って重要なデータを失う可能性があり非常に危険だからです。Content Managerでは自動削除はあえておこなわずに、代わりに各コンテンツの削除予定日を返すAPI (getExpirationDate)を用意してあります。このAPIを利用してシステム構築者(Content Managerクライアントアプリケーションの開発者)がコンテンツの削除を行うプログラムをアプリケーションに実装しておくのです。大抵はなんらかの警告を出して責任者の了解を得てからコンテンツの削除をさせるようにします。

なお、アプリケーションからの削除命令はライブラリー・サーバー・データベース内の該当コンテンツに削除フラグを立てるだけで、リソース・マネージャのコンテンツ保管域やテープ装置にある実際のコンテンツファイルの削除は行いません。コンテンツファイルを削除するのはRMマイグレーターです。つまり、Content Managerではコンテンツの削除という行為もデータマイグレーションの一種と考えます。このRMマイグレーターは、アプリケーションからの命令による動作とは非同期で動いているので削除フラグが立ってから該当コンテンツファイルが実際に削除されるまでには時間差があります。もし、RMマイグレーターが起動していなければコンテンツファイルは削除されません。

このようなコンテンツ管理システムを構築しておけば、リソース・マネージャのコンテンツ保管域のディスクは約半年分のデータが保存できる容量があれば満杯になることはありません。以上が、Content Managerのデータマイグレーション機能です。




上に戻る


Content Manager データマイグレーションの設定

データマイグレーション機能の設定は、Content Manager V8の導入がすべて完了した後に行います。

設定は単純ではありません。添付のガイドに従って進めてください。ただし、ここでは上図の例のように複数のマシンに分散させてサーバー構成するのではなく、すべてが1台のマシン上に構成されているケースについて説明しています。こちらの方が設定そのものについては理解しやすいためです。これ以外にもさまざまな構成が可能ですが、ここでは省略します。

なお、添付のガイドでは移動期限は「1日」、削除期限は「2日」に設定してあります。データマイグレーション機能の簡易確認の目的でそのようにしてありますが、この期限設定は実環境に合わせて適宜変更してください。

項目 IBM DB2 Content Manager V8 データマイグレーション設定ガイド
ファイル CMマイグレーション設定 (1.76MB)
Adobe ®   Reader ®   が必要
備考 IBM DB2 Content Manager V8 データマイグレーション設定ガイドこのガイドによる設定はあくまで一例です。この例でのサーバー構成は次の3つのサーバーが1台のマシン上にまとめて構成されるケースです。
  • ライブラリー・サーバー
  • リソース・マネージャ
  • Tivoli Storage Managerサーバー



上に戻る


運用における注意点

データマイグレーション機能を用いる場合の運用にはいくつかの注意点があります。主なものを以下に列挙します。

番号注意事項
1 データマイグレーションの設定がされている場合、コンテンツ保管域が満杯になる(=使用容量が設定のしきい値を超える)場合は、たとえ移動日になっていなくても一部のコンテンツは強制的に移動されます。その場合は移動日が最も近いコンテンツの中から自動的に選ばれたものが移動します。これを防ぐためには、リソース・マネージャのコンテンツ保管域の容量はなるべく余裕を持って設定してください。上の例では、半年間に登録されるファイルの総サイズの見積もりの1.2倍から1.5倍が目安です。
2 データマイグレーション機能を用いる場合は、以下のユーティリティを起動させてください。
  • ライブラリー・サーバー・モニター (リソース・マネージャの監視をします。)
  • リソース・マネージャ・マイグレーター (コンテンツファイルの移動や削除を行います。)
  • リソース・マネージャ・ステージャー (ステージ領域へのコンテンツファイルの読み出しを行います。)
  • リソース・マネージャ・パージャー (ステージ領域のコンテンツファイルの削除を行います。)
3 リソース・マネージャ・パージャー・ユーティリティ は、ステージ領域の定期的なファイルの削除を行うユーティリティです。ステージ領域中のファイルでアクセスの少ないファイルや日付の古いファイルなどを自動的に選んで、ステージ領域が一定のサイズになるように削除します。RMステージャーを使用する場合は必ず起動してください。

参考として、削除予定日を過ぎたコンテンツを削除するプログラムの例を載せます。各コンテンツの削除予定日を返すAPI(getExpirationDate)の代わりにEXPIRATION検索パラメータを使用して削除予定日を過ぎたコンテンツを取得しています。ただし、このサンプルではコンテンツの削除確認を行わずに削除しています。


<Javaの例>
                
/*BEGINPROLOGUE****************************************************************
* @copyright(disclaimer)                                                     *
* Licensed Materials - Property of IBM                                       *
* IBM DB2 Content Manager Enterprise Edition V8  (program number 5724-B19)   *
* IBM DB2 Content Manager Express Edition V8 (program number 5724-F73)       *
* IBM DB2 Content Manager for z/OS V8 (program number 5697-H60)              *
* (c ) Copyright IBM Corp. 1994, 2004. All Rights Reserved.                  *
*                                                                            *
* US Government Users Restricted Rights                                      *
* Use, duplication or disclosure restricted by GSA ADP Schedule              *
* Contract with IBM Corp.                                                    *
*                                                                            *
* DISCLAIMER OF WARRANTIES :                                                 *
*                                                                            *
* Permission is granted to copy and modify this  Sample code, and to         *
* distribute modified versions provided that both the copyright notice,      *
* and this permission notice and warranty disclaimer appear in all copies    *
* and modified versions.                                                     *
*                                                                            *
* This software is provided "AS IS."  IBM and its Suppliers and Licensors    *
* expressly disclaim all warranties, whether  EXPRESS OR IMPLIED, INCLUDING  *
* ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE  *
* OR WARRANTY OF NON-INFRINGEMENT.  IBM AND ITS SUPPLIERS AND LICENSORS      *
* SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE THAT RESULT FROM  *
* USE OR DISTRIBUTION OF THE SOFTWARE OR THE COMBINATION OF THE SOFTWARE     *
* WITH ANY OTHER CODE.  IN NO EVENT WILL IBM OR ITS SUPPLIERS  AND LICENSORS *
* BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT,   *
* SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND *
* REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR        *
* INABILITY TO USE SOFTWARE, EVEN IF IBM HAS BEEN ADVISED OF THE POSSIBILITY *
* OF SUCH DAMAGES.                                                           *
*                                                                            *
* @endCopyright                                                              *
******************************************************************************
*/

import com.ibm.mm.sdk.common.*;
import com.ibm.mm.sdk.server.*;
import java.sql.*;

public class SExpiredItemDeletionICM{

public static void main(String argv[]) throws DKException, Exception{

String database = "icmnlsdb"; //適切なデータベース名に書き直すこと
String userName = "icmadmin"; //適切な管理ユーザー名に書き直すこと
String password = "password"; //適切なパスワードに書き直すこと
String itemType = "NOINDEX"; //適切な項目タイプに書き直すこと

System.out.println("Server Name        = " + database);
System.out.println("User ID            = " + userName);
System.out.println("Target ItemType    = " + itemType);

try{
DKDatastoreICM dsICM = new DKDatastoreICM();  // Create new datastore object.
dsICM.connect(database,userName,password,""); // Connect to the datastore.

deleteExpiredItems(dsICM, itemType);

dsICM.disconnect();
dsICM.destroy();

} catch (DKException exc){
System.out.println("Name:        " + exc.name());
System.out.println("Message:     " + exc.getMessage());
System.out.println("Message ID:  " + exc.getErrorId());
System.out.println("Error State: " + exc.errorState());
System.out.println("Error Code:  " + exc.errorCode());
exc.printStackTrace();
throw(exc);

} catch (Exception e){
System.out.println(e);
e.printStackTrace();
throw(e);
}
} //end main

public static void deleteExpiredItems(DKDatastoreICM dsICM, String itemTypeName)
Zthrows DKException, Exception{

//ここでEXPIRATIONDATEを使ったパラメトリック検索をする
Date currentDate = new java.sql.Date(System.currentTimeMillis());
Timestamp currentTimestamp = new Timestamp(System.currentTimeMillis());
System.out.println("Today Date         = " + currentDate);
System.out.println("Current Timestamp  = " + currentTimestamp);

String queryString = "/" + itemTypeName;
queryString += "[@EXPIRATIONDATE < \"" + currentDate.toString() + "\"]";
System.out.println("XQuery             = " + queryString);

String strMax = "0";
DKNVPair parms[] = new DKNVPair[3];
parms[0] = new DKNVPair(DKConstant.DK_CM_PARM_MAX_RESULTS, strMax);
parms[1] = new DKNVPair(DKConstant.DK_CM_PARM_RETRIEVE, new Integer(DKConstant.
  DK_CM_CONTENT_IDONLY));
parms[2] = new DKNVPair(DKConstant.DK_CM_PARM_END, null);
DKResults results = (DKResults) dsICM.evaluate(queryString, DKConstant.
  DK_CM_XQPE_QL_TYPE, parms);

//上の検索でヒットしたコンテンツをすべて削除する
int i = 0;
if (results != null) {
dkIterator iter = results.createIterator();
while (iter.more()) {
DKDDO ddo = (DKDDO) iter.next();
if (ddo != null) {
String itemID = ((DKPidICM)ddo.getPidObject()).getItemId();
System.out.println("  ItemID =   " + itemID);
System.out.println("    *** 本当はここで確認のコマンドを入れる *** ");
//ddo.del(); //本番ではここのコメントアウトをはずすこと。そうしないと削除は実行されない
i++;
System.out.println("    " + i + " アイテムを削除しました  - " + currentDate);
}
}
}
System.out.println("Total hit count    = " + i);
} //end deleteExpiredItems

}//end SExpiredItemDeletionICM




上に戻る


まとめ

コンテンツ管理サーバーでは、その中のコンテンツ総量が常に変動します。コンテンツを保存するストレージ装置の容量は有限なため、コンテンツ総量をコントロールするということは非常に重要です。ストレージ装置がパンクして重要なデータが失われるようなことは絶対にあってはなりません。人間がコンテンツ量の監視をすることもできますが、複雑なシステムにおいてはコンテンツ量のコントロールを人手で行うには限界があります。

コンテンツ管理ソフトウェアのパイオニアである IBM DB2 Content Manager には長年にわたって研ぎ澄まされたさまざまな優れた拡張機能があります。その中でも データマイグレーション機能 を使えば、誰でも簡単にコンテンツ総量のコントロールを自動で行うシステムを構築できます。また、この機能を利用すれば、大容量のコンテンツを効率的に管理するシステムを構築することが可能です。

これでサーバーの構築はより完璧なものに近づくでしょう。

皆様には、ぜひ IBM DB2 Content Manager V8 とIBMサーバー関連製品をお使い頂き、優れたコンテンツ管理システムを構築して頂きたいと思います。



参考文献

  • IBM DB2 Content Manager Enterprise Edition IBM DB2 Content Manager for z/OS V8.3 システム管理ガイド (SC88-9201-07)(IBMインターネットサイトのマニュアル/Redbooks検索ページ(*1)よりダウンロードしてください。)

  • (Redbooks) DB2 Content Manager Backup/Recovery and High Availability: Strategies, Options, and Procedures(IBMインターネットサイトのマニュアル/Redbooks検索ページ(*1)よりダウンロードしてください。)

  • (*1) 上記ドキュメントは、 IBMマニュアル/Redbooks検索ページより最新版をダウンロード してご利用ください。


著者について

簗 敏之は大和ソフトウェア開発研究所のエンジニアで、Content Managementの分野におけるプロジェクトでの開発・支援業務を担当しています。




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



はいいいえわからない
 


 


54321
大変素晴らしい不充分・不完全である
 


上に戻る


    日本IBMについて プライバシー お問い合わせ