PureApplication System 仮想パターン構築の極意: 第 1 回 カスタム・ワークロード標準

仮想アプリケーションの DB を柔軟に構成する

当シリーズでは、PureApplication System の仮想パターン(仮想アプリケーション・パターンと仮想システム・パターン)を構築する上で、役に立つノウハウやベストプラクティスをご紹介します。今回は、仮想アプリケーション上の DB を柔軟に構成するための機能であるカスタム・ワークロード標準について、その定義方法と利用方法をご紹介します。

2012年 8月 06日: 各シェルのパラメーターの記述を修正、更新しました。また、post_start_inst.sh のスクリプト記述例を追加しました。

2012年 12月12日: PureApplication System 1.0.2 の画面を反映しました。また、スクリプト説明を追加しました。

宮田 裕樹, 日本アイ・ビー・エム, ソフトウェア事業, ISV&デベロッパー事業推進

宮田 裕樹の肖像写真宮田 裕樹
日本アイ・ビー・エム ソフトウェア事業 ISV&デベロッパー事業推進に所属。WebSphere および PureApplication System のテクニカル・スペシャリスト。12 年以上にわたって、多くのお客様に対する WebSphere テクニカル・サポートを行った経験を持つ。昨年より、ISV アプリケーションを PureApplication System に実装する Ready for PureSystems プロジェクトをリードしている。



2012年 12月 12日 (初版 2012年 7月 19日)

仮想アプリケーションでの DB 構築

PureApplication System は、仮想パターン構築/管理用アプライアンスである IBM Workload Deployer の機能を PureSystems Manager として内蔵しており、この機能を利用して仮想パターンの構築とクラウドへのデプロイを行います。PureSystems Manager がサポートする仮想パターンには仮想アプリケーション・パターンと仮想システム・パターンがありますが、仮想アプリケーション・パターンの方が構築がより容易であり、開発・運用における効率性がより高い仮想パターンになります。ところが、以前の IBM Workload Deployer (3.1.0.0 以前) では、仮想アプリケーションの DB 構築を行う際に厳しい制約があり、どのようなアプリケーションでも仮想アプリケーション・パターンで構築できるというわけではありませんでした。たとえば、仮想アプリケーション・パターンで構築できる DB は、DB2 CREATE DATABASE のオプションがデフォルトに限られ、表作成から初期データのロードまでは単一の SQL ファイルで提供する必要がありました。したがって、次のような DB を構築する際は、仮想アプリケーション・パターンではなく、仮想システム・パターンとして作成する必要がありました。

  • DB2 CREATE DATABASE のオプション(テリトリー、コード・セット、照合シーケンス、ページ・サイズなど)の指定が必要な場合
  • ページ・サイズを拡張した表スペース、バッファー・プールの作成が必要な場合
  • 初期データのロードに DB2MOVE などを利用して別のデータ・ファイルが必要な場合
  • その他の特別なチューニングが必要な場合

特に、日本で利用される通常のアプリケーションの場合、コード・セット、テリトリーは必須であり、ページ・サイズを拡張した表スペース、バッファー・プールも必要とされていることから、ほとんどがこの制約に引っかかりました。

PureApplication System では、改良された PureSystems Manager が搭載され、上記のような DB についても仮想アプリケーション・パターンの DB (あるいは、データベース・パターン(DBaaS))として柔軟に作成することができるようになりました。これを可能にする機能が、カスタム・ワークロード標準です。以下、その構成方法について説明します。


カスタム・ワークロード標準のシェルの作成

カスタム・ワークロード標準の構成では、先ず、表 1 に示したシェルを各フォルダー内に作成し、zip ファイルにパッケージングする必要があります。各シェルは、インスタンス・オーナーである db2inst1 によって、表 1 の番号順に実行されます。シェルの中で、create_db フォルダーの create_db.sh のみが必須であり、その他のシェルはオプションになります。

表 1. カスタム・ワークロード標準用のシェル
No.フォルダー名シェル名説明
1tune_insttune_inst.shDB2 インスタンス作成直後に実行
インスタンスのチューニングを記述
2create_dbcreate_db.shDB 作成時に実行(必須)
DB 作成コマンドを記述
3tune_dbtune_db.shDB 作成直後に実行
DB のチューニングを記述
4init_dbinit_db.shDB のチューニング後に実行
表/VIEW/INDEX などの作成コマンドおよび、データのインサート、ロード、インポートなどを記述
5post_start_instpost_start_inst.shDB2 インスタンスを開始直後に毎回実行
必要なプロセスの起動コマンドなどを記述

以下、各シェルの記述方法について説明します。

tune_inst.sh

DB2 インスタンスの作成直後に実行されるシェルで、主にインスタンスのチューニング・コマンド(DB2 UPDATE DBM CFG など)を記述します。(リスト 1)

パラメーターは、以下のものが取得可能です。

第 1 引数: インスタンス名

ただし、このインスタンス名は db2inst1 が使用され、変更することはできません。

[スクリプト説明]
2 行目: パラメーターの読み込み
6-7 行目: 必要なインスタンスのチューニング・コマンドを記述

リスト 1. tune_inst.sh スクリプト記述例
01  #!/bin/sh
02  inst_name=$1
03  echo "========== tune_inst.sh start =========="
04  echo “inst_name: “ ${inst_name}
05  ## インスタンスのチューニング
06  db2 "UPDATE DBM CFG USING JAVA_HEAP_SZ 1024 DEFERRED"
07  db2 "UPDATE DBM CFG USING MAXAGENTS 5"
08  echo "========== tune_inst.sh end =========="

create_db.sh

DB 作成時に実行されるシェルで、DB 作成コマンド(DB2 CREATE DATABASE)を記述します。ここで、DB2 CREATE DATABASE のオプションを自由に付加して作成することが可能です。(リスト 2)

パラメーターは、順に以下のものが取得可能です。

第 1 引数: インスタンス名
第 2 引数: DB 名

[スクリプト説明]
2 -3 行目: パラメーターの読み込み
5 行目: オプション指定によるデータベースの作成
6-10行目: エラー処理

リスト 2. create_db.sh スクリプト記述例
01  #!/bin/sh
02  inst_name=$1
03  db_name=$2
04  echo "========== create_db.sh start =========="
05  db2 "CREATE DATABASE $db_name USING CODESET UTF-8 TERRITORY JP COLLATE USING IDENTITY
 PAGESIZE 32 K"
06  rc=$?
07  if [ ${rc} -ne 0 ] then
08    echo "Failed to create DB"
09    exit ${rc}
10  fi
11  echo "========== create_db.sh end =========="

tune_db.sh

DB 作成後に実行されるシェルで、バッファー・プールの作成、表スペースの作成や DB チューニング・コマンド(DB2 UPDATE DB CFG)などを記述します。また、アプリケーション・ユーザーに特別な権限を与える必要がある場合はここに DB2 GRANT を記述します。(リスト 3)

パラメーターは、順に以下のものが取得可能です。

第 1 引数: インスタンス名
第 2 引数: DB 名
第 3 引数: アプリケーション・ユーザー名
第 4 引数: アプリケーション・ユーザー・パスワード
第 5 引数: アプリケーション DB 管理者名
第 6 引数: アプリケーション DB 管理者パスワード

ここで、アプリケーション・ユーザー名は appuser、アプリケーション DB 管理者名は appdba が使用され、変更することはできません。

[スクリプト説明]
2 -7 行目: パラメーターの読み込み
11 行目: バッファー・プールの作成
13-15 行目: 表スペースの作成
17-18 行目: DB チューニング (DB2 UPDATE DB CFG)
20 行目: 必要な場合、ユーザーへの権限付与を記述
21-22 行目: DB 接続の切断

リスト 3. tune_db.sh スクリプト記述例
01  #!/bin/sh
02  inst_name=$1
03  db_name=$2
04  app_user=$3
05  app_password=$4
06  appdba=$5
07  appdba_password=$6
08  echo "========== tune_db.sh start =========="
09  db2 "connect to $db_name"
10  ## バッファー・プール作成例
11  db2 "CREATE BUFFERPOOL ADD_SYSB1 IMMEDIATE SIZE 250 PAGESIZE 16K"
12  ## 表スペース作成例
13  db2 "CREATE SYSTEM TEMPORARY TABLESPACE ADD_SYSTMP1 PAGESIZE 16K \
14    MANAGED BY SYSTEM USING ('xxxsys00') EXTENTSIZE 16 OVERHEAD 10.5 \
15    PREFETCHSIZE 16 TRANSFERRATE 0.14 BUFFERPOOL ADD_SYSB1"
16  ## DBチューニング例
17  db2 "UPDATE DB CFG USING LOGFILSIZ 5000 DEFERRED"
18  db2 "UPDATE DB CFG USING APPLHEAPSZ 512 DEFERRED"
19  ## DBユーザーへの権限付与の必要があればここに記述
20  #db2 "GRANT DBADM ON DATABASE TO USER $app_user"
21  db2 "connect reset"
22  db2 "terminate"
23  echo "========== tune_db.sh end =========="

init_db.sh

DB チューニング後に実行されるシェルで、表、VIEW、INDEX などの作成を行います。また、データの INSERT、LOAD あるいは DB2MOVE コマンドによるインポートなどを記述します。(リスト 4) 必要な DDL ファイルは同じ init_db フォルダーに配置します。また、LOAD や DB2MOVE を利用する際、必要なデータ・ファイル(ixf、xml、lob など)も同様に init_db フォルダーに配置します。

注意点としては、アプリケーションではアプリケーション・ユーザーでアクセスされるため、ここでもアプリケーション・ユーザーで CONNECT して、表作成などを行っておく必要がある、ということが挙げられます。前述の通り、アプリケーション・ユーザー名は appuser が固定的に使用されるため、DB2MOVE などを利用して表をインポートする場合にも、そのスキーマ名が appuser となるように注意する必要があります。

パラメーターは、順に以下のものが取得可能です。

第 1 引数: インスタンス名
第 2 引数: DB 名
第 3 引数: アプリケーション・ユーザー名
第 4 引数: アプリケーション・ユーザー・パスワード
第 5 引数: アプリケーション DB 管理者名
第 6 引数: アプリケーション DB 管理者パスワード

[スクリプト説明]
2 -7 行目: パラメーターの読み込み
10 行目: アプリケーション・ユーザー (appuser) で DB に接続
12 行目: DB 構築用 DDL の実行
14 行目: DB2MOVE による表のインポート
15 行目: DB への変更のコミット
16-17 行目: DB 接続の切断

リスト 4. init_db.sh スクリプト記述例
01  #!/bin/sh
02  inst_name=$1
03  db_name=$2
04  app_user=$3
05  app_password=$4
06  appdba=$5
07  appdba_password=$6
08  echo "========== init_db.sh start =========="
09  ## アプリケーション・ユーザーでDBに接続
10  db2 "CONNECT TO ${db_name} USER ${app_user} USING ${app_password}"
11  ## DB構築用DDLの実行
12  db2 +p -s -v -f xxx.ddl
13  # 初期データをdb2moveでまとめてロードする場合(インポート用各種ファイルをパッケージングしておく)
14  db2move ${db_name} import -io insert
15  db2 commit work
16  db2 connect reset
17  db2 terminate
18  echo "========== init_db.sh end =========="

post_start_inst.sh

DB2 インスタンスの開始直後に呼び出されるシェルで、インスタンス開始の度に毎回実行されます。例えば、DB2 インスタンス開始の度に起動の必要なプロセス(例:DB2 Text Search) などの起動コマンドを記述します。(リスト 5)

パラメーターは、順に以下のものが取得可能です。

第 1 引数: インスタンス名
第 2 引数: DB 名

[スクリプト説明]
2-3 行目: パラメーターの読み込み
6-8 行目: DB2 Text Search の起動
9-13 行目: エラー処理

リスト 5. post_start_inst.sh スクリプト記述例
01  #!/bin/sh
02  inst_name=$1
03  db_name=$2
04  echo "========== post_start_inst.sh start =========="
05  ## DB2 Text Search を起動
06  db2ts "ENABLE DATABASE FOR TEXT CONNECT TO ${db_name}"
07  /home/db2inst1/sqllib/db2tss/bin/startup.sh
08  db2ts "START FOR TEXT"
09  rc=$?
10  if [[ ${rc} -ne 0 ]] ; then
11     echo "Failed to post start the database."
12     exit ${rc}
13  fi
14  echo "========== post_start_inst.sh end =========="

カスタム・ワークロード標準用 zip ファイルの作成

シェルを作成したら、すべてのフォルダーをひとつの zip ファイルにパッケージングします。図 1 は 5 つのシェル・スクリプトが入ったフォルダーを zip したものです。

図 1. カスタム・ワークロード標準 zip ファイル
カスタム・ワークロード標準 zip ファイル

カスタム・ワークロード標準 zip ファイルの登録

PureApplication System のメニューから カタログ→データベース・ワークロード標準 を選択します。新規アイコンをクリックすると、図 2 のような画面が表示されるので、作成した zip ファイルをアップロードし、新規カスタム・ワークロード標準(図では、Sample CWS)を登録します。

図 2. カスタム・ワークロード標準の登録
カスタム・ワークロード標準の登録

カスタム・ワークロード標準の利用

仮想アプリケーション・ビルダーのキャンバスに DB コンポーネントをドロップすると、右側のプロパティー・フレームにソース・セクションが表示されます。デフォルトでは、“デフォルト・データベース・ワークロード標準を適用”が選択されているので、これを“データベース・ワークロード標準を適用”に変更します。

図 3. DB コンポーネントのソース・プロパティー
DB コンポーネントのソース・プロパティー

図 3 に示すように、定義されているカスタム・ワークロード標準の一覧が表示されるので、さきほど登録した Sample CWS を選択します。後は通常通り、仮想アプリケーション・パターンを完成させ、デプロイすれば、定義どおりの DB が構成されます。

データベース・パターン(DBaaS)で DB をデプロイする場合もほぼ同等の操作でカスタム・ワークロード標準を利用することができます。PureApplication System のメニューから、パターン→データベース・パターン と選択します。新規アイコンをクリックすると図 4 のような画面が表示されるので、ソース・フィールドを“データベース・ワークロード標準を適用”に変更し、利用したいカスタム・ワークロード標準を選択します。これを保存してデプロイすれば、定義どおりの DBaaS が構成されます。

図 4. データベース・パターン(DBaaS)の定義画面
データベース・パターン(DBaaS)の定義画面

まとめ

この記事では、PureApplication System における柔軟な DB 構成方法として、カスタム・ワークロード標準をご紹介しました。カスタム・ワークロード標準を利用することによって、今まで、仮想システム・パターンでしか構築できなかった DB を持つアプリケーションも、仮想アプリケーション・パターンで構築することが可能となりました。この記事で説明した手順にしたがって、仮想アプリケーション・パターンの構築にぜひチャレンジしてください。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Information Management, WebSphere
ArticleID=825553
ArticleTitle=PureApplication System 仮想パターン構築の極意: 第 1 回 カスタム・ワークロード標準
publish-date=12122012