IBM PureApplication System は、2つの仮想パターンをサポートしています。仮想アプリケーション・パターンと仮想システム・パターンです。
- 仮想アプリケーション・パターン (VAP) はワークロード・レベルの仮想パターンで、アプリケーション・プラットフォーム・エクスパティーズ (専門的知見) まですべてを含んでいます
- 仮想システム・パターン (VSP) はテクノロジー・レベルの仮想パターンで、ミドルウェアのエクスパティーズまでが含まれています
この記事では、それぞれのパターン開発におけるベスト・プラクティスをご紹介します。いずれも実際のビジネス・アプリケーションの実装段階で会得した実用的なものです。
ここでご紹介する仮想アプリケーション・パターンにおけるプラクティスは以下です。
- クラス・ローダー順序/ポリシーの変更
パターン開発者が、VAP アプリケーションのクラス・ローダー順序およびポリシーの変更を容易にできるようにします。 (クラス・ローダー・ポリシーがアプリケーション毎のクラス・ローダーの制御をします)
- FTP サーバーへの put/get および、一般サーバーへのアクセス
パターン開発者が、VAP アプリケーションの外部にある FTP サーバーへのアクセスを可能にします。この手法は、 外部の HTTP サーバー、RSS サーバーなどその他の一般サーバーにも当てはまります
エンタープライズ・アプリケーションがクラス・ローダー順序や WAR クラス・ローダー・ポリシーの変更を必要とする場合、EAR を導入後、WAS 管理コンソールから設定変更を行うのが通常です。たとえば、アプリケーションのクラスを先にロードしたい場合、クラス・ローダー順序を “最初にローカル・クラス・ローダーをロードしたクラス (親は最後)” に設定します。
図 1. WAS 管理コンソール
しかし、VAP の場合はデプロイされた VM に変更を加えることは許可されないため、それを行うことができません。その代わり、Virtual Application Builder で設定可能な JVM ポリシーによってクラス・ローダー順序を下記方法で構成します。
図 2. Virtual Application Builder におけるクラス・ローダー順序
- Virtual Application Builder において、エンタープライズ・アプリケーションに JVM ポリシーを追加します
- 「クラス・ローダー順序」には PARENT_FIRST もしくは PARENT_LAST のいずれか、 「WAR クラス・ローダー・ポリシー」には MULTIPLE もしくは SINGLE のいずれかを、それぞれ選択します
FTP サーバーへの put/get および、一般サーバーへのアクセス
VAP のアプリケーションから FTP サーバーに接続し、ファイルの put/get を行いたい場合、FTP サーバーを VAP のコネクト・アウトとして定義しておく必要があります。
その場合、Virtual Application Builder にて、FTP サーバーのポート 20 と 21 について、その他のコンポーネントのコネクト・アウトとして定義し、アプリケーション・コンポーンネントとリンクしておきます。ただし、注意点として、アプリケーションからは FTP サーバーへの接続ポート番号を固定するために、パッシブ・モードではなく、アクティブ・モードで FTP 接続する必要があります。VAP のアプリケーションから、RSS サーバーや HTTP サーバーなどの一般サーバーを参照する場合も同様にコネクト・アウトを定義し、ターゲットの IP アドレスとポート番号を指定しておく必要があります。
図 3. Virtual Application Builder におけるコネクト・アウト定義
ここで述べる、仮想システム・パターンにおけるプラクティスは以下です。
- wsadmin スクリプトによる VSP デプロイ
一般的に wsadmin スクリプトはスクラッチから作成するのは難しいですが、この記載をヒントにすれば、パターン開発者は VSP で使用する wsadmin スクリプトを容易に作成できます
- VSP のインポート/エクスポート
コマンド・ライン・インターフェースを使い、スクリプト・パッケージとアドオンをリストアし、マイグレーション・パターンをコピーします。同時に、DBCS (double-byte character set) 環境におけるエラー回避策を紹介します
- VM のタイムゾーン設定変更
デフォルトの UTC を使用したくない場合に参照ください
- DB2 のファイル・システム・サイズ増加
デフォルトより大きいファイル・システムを必要とする場合に参照ください
- 既存データベースからの表/データ移行
手入力や専用ツールによりデータベースが構築されていてデータベース作成およびデータロード用のスクリプト化が難しい場合、データベース環境全体の移行用スクリプトを作成します
- テスト済みの DB2 ドライバー利用
すでにご自身のアプリケーションで動作しているドライバーを使用するのが、VSP パッケージにとっても一番良いです
VSP デプロイ時に必要なスクリプト・パッケージ内に wsadmin の jython スクリプト・ファイル (*.jy) があります。WebSphrere Application Server の管理コンソールの操作からスクリプトを自動生成するコマンド支援機能を利用すると効率的に jython スクリプトを作成することができます。
データソース作成スクリプト
データソース・スクリプトは以下の方法で作成します。
- 仮想マシンのインスタンス生成時に VNC および WebSphere のリンクが同時に作成されます。
- (仮想システム・インスタンスで「仮想マシン」セクションの展開)
- 1. の WebSphere リンクをクリックし、ユーザー名 virtuser / 設定したパスワードでログインします
- 以下、データソースの構成時を例にして説明します。WAS 管理コンソールが起動するので、左側のメニューから、「リソース」→「JDBC」→「データ・ソース」の順に選択します
- 新規作成を選択し、データ・ソースの作成ステップ 1 からステップ 5 までを実施します
- 終了ボタンを押下後、右側に表示される「コマンド支援 最後のアクションの管理スクリプトを表示 」をクリックします
図 5. コマンド支援
- 「管理スクリプト・コマンド」画面に表示されたスクリプト(AdminTask, AdminConfig 等)をコピーします
図 6. スクリプト・コピー
- CreateDatasource.zip 内の CreateDatasource.jy ファイル内の該当箇所を 6. でコピーしたスクリプトを参考にして記述します (セル名やノード名などの固定値は変数に置き換えておく必要があります)
EAR 導入スクリプト
データソース作成用スクリプト構築方法を上記で学びました。同様に Enterprise Archive ファイル導入用スクリプトを作成します。
- データソース作成時と同様、仮想マシンのインスタンス生成時に VNC および WebSphere のリンクが同時に作成されます (仮想システム・インスタンスで「仮想マシン」セクションの展開)
- 1. の WebSphere リンクをクリックし、ユーザー名 virtuser および 設定したパスワードでログインします
- WAS 管理コンソールが起動するので、左側のメニューから、「アプリケーション」→「新規アプリケーション」→「新規エンタープライズ・アプリケーション」の順に選択します
- EAR のパスを入力します
- ファースト・パスもしくは詳細のいずれかを選択します。ファースト・パスを選択した場合は、画面に表示されるステップ 1 からステップ 3 までを実行します。(ステップ 1: インストール・オプションの選択/ステップ 2:モジュールをサーバーにマップ/ステップ 3: 要約)
- 終了ボタンを押下後、右側に表示される「コマンド支援 最後のアクションの管理スクリプトを表示」をクリックします
- 「管理スクリプト・コマンド」画面に表示されたスクリプト(AdminTask, AdminConfig 等)をコピーします
- installApp.zip 内の installApp.jy ファイル内の該当箇所を 7. でコピーしたスクリプトを参考にして記述します (セル名やノード名などの固定値は変数に置き換えておく必要があります)
VAP ではエクスポート/インポートがアイコン 1 度ずつのクリックで可能ですが、VSP ではスクリプト・パッケージとアドオンを手動でアップロードした上で、移行するパターンを pure コマンドによって選択し新環境にコピーします。
事前準備:
- IBM PureApplication System ようこそ画面左上から「コマンド行ツールのダウンロード」によりダウンロードし、<WORKING_DIRECTORY>に展開します (約 8MB)
図 7. コマンド・ライン・ツールのダウンロード
※ PureApplication System 1.0.1 では以下の設定は不要となりました。
- <WORKING_DIRECTORY>\deployer.cli\lib\3.1.0.0-20111118232331 (バージョンによってディレクトリー名は異なります) に移動し、registry ファイルを編集し、下記 2 行のコメントを外し、コードセットの編集を行います
図 8.DBCS 環境設定
エクスポート:
- スクリプト・パッケージ (アドオンがある場合はそれも) を、ダウンロード機能を使用し保管します
- <WORKING_DIRECTORY>\pure.cli\bin に移動して、pure コマンドを発行します
pure -h host_IP_address -u user_name -p password -f ..\samples\patternToPython.py -f xxx_vsp.py
図 9. コピー対象パターン選択
- 今回コピーする対象のパターンの番号を上記画面から選択し、VSP 用の python スクリプト (xxx_vsp.py(名称は任意)) を作成(Export)します
インポート:
- インポート環境において、同じ名前でスクリプト・パッケージ (アドオンがある場合はそれも) を作成し、2.a でダウンロードしたスクリプト・パッケージ (およびアドオン) を、アップロードします。リフレッシュ・ボタンを押して、パラメーターが正しくセットされることを確認してください
- 2.でエクスポートした VSP のパターン(xxx_vsp.py)を、pure コマンドにより、新環境にインポートします
pure -h host_IP_address -u user_name -p password -f xxx_vsp.py
注意) すでに同じパターン名が存在している場合は、それを削除してから実施します
- 上記でインポートした VSP をクラウドにデプロイし、デプロイ完了後、動作確認を実施します
デプロイされる VM のタイムゾーンはデフォルトでは UTC となっています。VSP では、これを変更するためにスクリプト内で記述をする必要があります。(VAP では、必ずデフォルトの UTC となり変更できません。2012/07 現在)
データベース側では、タイムゾーンを JST (Japan Standard Time)に切り替えるには、データベース作成用のスクリプト内で次のように記述します。
図 10. DB2 側でのタイムゾーン変更
図 10 のコード部分
#!/bin/sh DB2="/opt/ibm/db2/V9.7/bin/db2“ su db2inst1 <<_EOF #タイムゾーンの切り替え echo -e "\nexport TZ=JST-9" >> ~/.bashrc export TZ=JST-9 # DB2 を再起動する $DB2 +p "STOP DATABASE MANAGER FORCE" $DB2 +p "START DATABASE MANAGER" # DB の作成~データのロードを行う処理を記述する _EOF |
WebSphere Application Server 側でタイムゾーンを JST に切り替えるには、WAS 側で最初に実行されるスクリプト内で次のように記述します
図 11. WebSphere Application Server 側でのタイムゾーン変更
図 11 のコード部分
#!/bin/sh # TimeZone を JST で動作するように設定する(デフォルトでは UTC) su virtuser <<_EOF echo -e "\nexport TZ=JST-9" >> ~/.bashrc _EOF export TZ=JST-9 # 環境変数(TZ)を引き継いで WAS を再起動 if [ $PROFILE_TYPE == "dmgr" ] ; then su virtuser $WAS_PROFILE_ROOT/bin/stopManager.sh su virtuser $WAS_PROFILE_ROOT/bin/startManager.sh elif [ $PROFILE_TYPE == "default" ] ; then su virtuser $WAS_PROFILE_ROOT/bin/stopServer.sh server1 su virtuser $WAS_PROFILE_ROOT/bin/startServer.sh server1 fi |
VSP の DB2 環境で大規模なデータ移行が必要な場合 (目安として 20-30GB 以上)、デフォルトのファイル・システムでは容量不足である場合があります。その場合、アドオンによりディスク追加を行い、該当のファイル・システムを増やす事で対応します。
- PureApplication System のワークロード・コンソールで「カタログ」→「アドオン」を選択します
- 今回は ディスクの追加のため、Default add disk を選択します。右側の環境:パラメーターを確認します
- VSP DB2 のトポロジーにアドオンから Default add disk を配置すると同時に、DISK_SIZE_GB = 10 を、追加したいファイル・システムの容量に変更し、ファイル・システム・タイプやマウント・ポイント(任意)をあわせて指定します。
- 図 12 を参考に追加のスクリプト・パッケージ (図中の test_adddisk) を作成し、アプリケーションの DB2 作成用スクリプト・パッケージ (図中の Create DB2 database test) の直前に実施します。
図12. ファイル・システムのアンマウント および トポロジー配置
図 12 のコード部分#!/bin/sh umount /tmp/defaultadddisk/ (上記手順 3. で指定したマウント・ポイント) (sde1 にマウント済み) su - db2inst1 –c “db2stop” umount /db2fs mount /dev/sde1 /db2fs chmod -cvR 777 /db2fs su - db2inst1 –c “db2start”
上記のスクリプトを実装した上でデプロイすることで、DB2 VSP インスタンスにおいて、/db2fs ファイル・システムを増加した容量で使用できます。 (df コマンドで確認できます)
手入力あるいはツールによってセットアップされているなどの理由でデータベース作成およびデータロード用のスクリプトを作成することが難しい場合、セットアップ済みのデータベース環境をそのまま移行するスクリプトを作成することができます。
db2 backup を利用する方法
- セットアップ済み既存 DB からバックアップをとります。
db2 backup db DB_name to backup_file_name compress
- バックアップ・ファイルからリストアするスクリプトを作成し、バックアップ・ファイルとともにパッケージ化します。
db2 restore db DB_name from backup_file_name
注意) この方法では、バックアップ・ファイルをパッケージ化するため、スクリプト・パッケージが肥大化する傾向があります。また、この方法はプラットフォームに依存しており、例えばエンディアンの異なる IA Linux (リトル・エンディアン) と AIX (ビッグ・エンディアン) の間では互換性がありません。このような問題を回避するためには、次に示す db2move を利用します。
db2move を利用する方法
- 既存 DB から DDL を取得します
db2look -d DB_name -a -e -l -x -f -td % -o DDL_file_name
- 既存 DB からデータを取得します
db2move DB_name export -sn schema_name
- 生成列がある場合は、生成列を含む表を export します
db2 export to table_name.ixf of ixf messages table_name.msg select * from table_name
- 下記のようなスクリプトを作成します
図 13. db2move 使用法
図 13 のコード部分#!/bin/sh #初期設定 DB2="/opt/ibm/db2/V9.7/bin/db2“ DB2MOVE="/opt/ibm/db2/V9.7/bin/db2move“ touch ログ・ファイル名 touch ログ・ファイル名_2 chmod 777 *.* chmod 777 /tmp/スクリプト・パッケージ名 su db2inst1 <<_EOF_ #DB の作成 $DB2 +p “create db DB 名 using codeset utf-8 territory JP \ collate using identity pagesize 32 K” #DDL の実行 $DB2 +p -td% -vf DDL ファイル名 -z ログ・ファイル名 #外部キー制約がある場合、外部キー制約を外す $DB2 +p “connect to DB 名” $DB2 +p “alter table 表名 drop constraint 外部キー制約名” #データの import $DB2MOVE DB 名 import -io insert #生成列を含む表がある場合、その表を削除 $DB2 +p “drop table 表名” #生成列を含む表がある場合、その表を create/import $DB2 +p “import from 表名.ixf of ixf modified by identityignore \ messages 表名_im.msg create into 表名” #外部キー制約または、生成列を含む表がある場合、DDL を再実行 # 生成列がある場合、生成列を含む表を create/import # 外部キー制約がある場合、外部キー制約を再設定 $DB2 +p -td% -vf DDL ファイル名 -z ログ・ファイル名_2 _EOF_
- 1~3 で取得した各種ファイルとスクリプトをパッケージ化し、スクリプト・パッケージを作成します
DB2 ドライバーは、PureApplication System が提供するものよりも、すでにアプリケーションでテスト済みのものを使いたい場合があります。VSP では、利用したい DB2 ドライバーをパッケージングすることにより、置換して利用することが可能です。
- テスト済みの DB2 ドライバー (db2jars.zip) をスクリプト・パッケージに含めます
- DB2 ドライバー導入用のスクリプトの中で、以下の処理を記述します
# db2jar.zip をコピーしドライバー・ファイルを /opt/db2 directory に展開 chmod 777 /tmp/スクリプト・パッケージ名/db2jars.zip mkdir /opt/db2 chown virtuser:users /opt/db2 cp $PWD/db2jars.zip /opt/db2 sudo -u virtuser unzip -d /opt/db2 $PWD/db2jars.zip
- データソース作成用の wsadmin スクリプト内でクラスパスとして、展開した DB2 ドライバーを設定し、JDBC プロバイダーを作成します。(サンプル・コード参照)
- non-XA データソース 作成用サンプル・コード:
AdminTask.createJDBCProvider('[-scope Cell=' + cellName + ' -databaseType DB2 -providerType "DB2 Universal JDBC Driver Provider" -implementationType "Connection pool data source" -name "DB2 Universal JDBC Driver Provider" -description "One-phase commit DB2 JCC provider" -classpath [/opt/db2/db2jcc.jar /opt/db2/db2jcc_license_cu.jar]]' - XA データソース 作成用サンプル・コード:
AdminTask.createJDBCProvider('[-scope Cell=' + cellName + ' -databaseType DB2 -providerType "DB2 Universal JDBC Driver Provider" -implementationType "XA data source" -name "DB2 Universal JDBC Driver Provider (XA)" -description "DB2 Universal JDBC Driver Provider (XA)" -classpath [/opt/db2/db2jcc.jar /opt/db2/db2jcc_license_cu.jar]]'
- non-XA データソース 作成用サンプル・コード:
ここまでご紹介した VAP/VSP 開発手法が、皆さんがクラウド環境上で仮想パターンを構成しデプロイし、ビジネス用途で実装する際のベスト・プラクティスとして、お役に立てば幸いです。