Oracle Blogs 日本語のまとめ: [SOA] Installing the Latest & Greatest

以前のエントリでは、VirtualBoxのOracle Linux 6にDatabase 11gR2をインストールしました。今回は、この同じ仮想環境にSOA Suiteをインストールします。64Bit Linuxの環境なので、JVMも64Bit、WebLogicはgeneric installerを使います。インストールするのは以下のソフトウェアです。

JDK 1.7
JDK 1.6
JRockit 1.6
WebLogic 10.3.5
OSB 11.1.1.5
SOA Suite 11.1.1.5

そして、Repository Creation Utility（以下、RCU）を実行してデータベース中にスキーマを作成します。

OSへの追加作業
RCUを流す上で、以下のパッケージをインストールする必要があります。

libXext.i686
libXtst.i686

yumで追加しておきましょう。

yum install libXext.i686 libXtst.i686

SOAリポジトリの作成
パッケージを追加してから、RCUを実行してDatabase 11gR2にリポジトリを作成します。RCUは実行しているクライアントはチェックしませんので、ターゲットのデータベースが動作検証済みであれば問題なく実行できます。

Javaのインストール
64Bit環境のため、WebLogicにバンドルされる32Bit JVMは使いたくないので、JVMをインストールするところから始めます。
JVMをインストールするまでに、JVMのインストール先でもあるMiddleware_Homeディレクトリを作成します。データベースインストール時に、ORACLE_BASEは "/home/oracle/app/oracle"、ORACLE_HOMEは "$ORACLE_BASE/product/11.2.0/db" に割り当てられています。今回は同じORACLE_BASEを使うことにし、MW_HOMEとして "$ORACLE_BASE/product/FMW" を割り当てました。
その後、ディレクトリを移り、HotSpot JVM(JDK6)、JRockit JVM(JDK6)、JDK7をインストールしました。将来のアップグレードが容易になるよう、JVMにシンボリックリンクを張りました。

ln –s jrockit-jdk1.6.0_24-R28.1.3-4.0.1 jrockit-jdk1.6
ln -s jdk1.7.0 jdk1.7
ln -s jdk1.6.0_25 jdk1.6

シンボリックリンクを使うと、JDKの最新バージョンをインストールしてリンクを更新することにより、新しいJDKを使って起動することができるようになります。

WebLogicのインストール
JVMをインストールしてようやくWebLogicのインストール準備ができました。今回は64Bit JVMを使っているので、jarファイルとして提供されているgeneric installerを使います。JVM利用リストに先ほどの3個のJVMを登録し、HotSpot JVM (JDK6) をデフォルト使用することにしました。WebLogicはJVMを識別し、実ディレクトリに到達するシンボリックリンクをフォローします。JDK 7はSun JDKではなくOracleとして認識されました。通常ベンダーがOracleの場合、WebLogicはJRockit JVMと認識しますが、JRockitはHotSpotと異なるパラメータをとるため、これは後々問題になるでしょう。
WebLogic Serverをインストール後、 $MW_HOME/wlserver_10.3/common/bin/commEnv.sh を編集して、実ディレクトリではなくシンボリックリンクを参照するようにしました。これは将来のJVMのアップグレードを容易にするためです。

JAVA_HOME="/home/oracle/app/oracle/product/FMW/jdk1.6"

OSBのインストール
OSBもSOA SuiteもOracle Universal Installerを使いプラットフォームやOSパラメータ、インストール先のシステムパッケージの確認をします。ただ、OELはOSプラットフォームのリストに含まれていないため、インストーラは事前チェックで失敗してしまいます。データベースインストーラでは、GUIからチェックに失敗するものを無視するように選択できましたが、OSBはそれができませんので、次の2つのオプションを考えます。
事前チェックを無視する
新しいチェックを追加する
どちらを選択しても、OSBのインストールは進みます。デザイナ32bit向けのみのため、インストールしませんでした。サーバVMではなくクライアント機にデザイナをインストールするつもりです。

Option 1 – 事前チェックを無視する
インストーラ起動時に -ignoreSysPrereqs をつけることで、事前チェックを無視することができます。

./runInstaller –ignoreSysPrereqs

これは簡単で早くできるという点で有利ですが、本当に必要なものがわからずに、インストールに失敗する可能性があります。そのときはOption 2を試してください。

Option 2 – OEL用に新しいチェックを作成する
事前チェックはインストールメディアの “Disk1/stage/prereq/linux64/refhost.xml” に記載されています。<CERTIFIED-SYSTEMS>の中に<OPERATING-SYSTEM>タグを新しく追加しますが、今回はRed Hat 5.4のタグをコピーし、"<VERSION>"の"VALUE"属性を"6.0"に、"<PACKAGE>"要素の"i386""ARCHITECTURE"属性を"i686"に変更しました。

<OPERATING_SYSTEM>
<VERSION VALUE="6.0"/>
<ARCHITECTURE VALUE="x86"/>
<NAME VALUE="Linux"/>
<VENDOR VALUE="redhat"/>
<GLIBC ATLEAST="2.5-12">
</GLIBC>
<PACKAGES>
<PACKAGE NAME="binutils" VERSION="2.17.50.0.6" />
<PACKAGE NAME="compat-libstdc++-33" VERSION="3.2.3" ARCHITECTURE="x86_64" />
<PACKAGE NAME="compat-libstdc++-33" VERSION="3.2.3" ARCHITECTURE="i686" />
<PACKAGE NAME="elfutils-libelf" VERSION="0.125" />
<PACKAGE NAME="elfutils-libelf-devel" VERSION="0.125" />
<PACKAGE NAME="gcc" VERSION="4.1.1" />
<PACKAGE NAME="gcc-c++" VERSION="4.1.1" />
<PACKAGE NAME="glibc" VERSION="2.5-12" ARCHITECTURE="x86_64" />
<PACKAGE NAME="glibc" VERSION="2.5-12" ARCHITECTURE="i686" />
<PACKAGE NAME="glibc-common" VERSION="2.5" />
<PACKAGE NAME="glibc-devel" VERSION="2.5" ARCHITECTURE="x86_64" />
<PACKAGE NAME="glibc-devel" VERSION="2.5-12" ARCHITECTURE="i686" />
<PACKAGE NAME="libaio" VERSION="0.3.106" ARCHITECTURE="x86_64" />
<PACKAGE NAME="libaio" VERSION="0.3.106" ARCHITECTURE="i686" />
<PACKAGE NAME="libaio-devel" VERSION="0.3.106" />
<PACKAGE NAME="libgcc" VERSION="4.1.1" ARCHITECTURE="x86_64" />
<PACKAGE NAME="libgcc" VERSION="4.1.1" ARCHITECTURE="i686" />
<PACKAGE NAME="libstdc++" VERSION="4.1.1" ARCHITECTURE="x86_64" />
<PACKAGE NAME="libstdc++" VERSION="4.1.1" ARCHITECTURE="i686" />
<PACKAGE NAME="libstdc++-devel" VERSION="4.1.1" />
<PACKAGE NAME="make" VERSION="3.81" />
<PACKAGE NAME="sysstat" VERSION="7.0.0" />
</PACKAGES>
<KERNEL>

<PROPERTY NAME="VERSION" VALUE="2.6.18"/>
<PROPERTY NAME="hardnofiles" VALUE="4096"/>
<PROPERTY NAME="softnofiles" VALUE="4096"/>
</KERNEL>
</OPERATING_SYSTEM>

こうすると、インストーラを通常通り実行できます。事前チェックを正しく検証してくれるので、自信を持ってセットアップできるでしょう。

SOA Suiteのインストール
OSBをインストールしたら、OSBのインストール時に施した、OS周りの事前チェックに関する作業を同じようにSOA Suiteについても実施した上で、SOA Suiteをインストールします。同じリポジトリから異なるドメインを作成するできるようにするため、この時点でスナップショットをとっておきました。

開発用ドメインの作成
次にSOA Suite/OSBの開発用ドメインを作成します。ドメイン構成ウィザードにてOSBとSOA Suiteの開発者用テンプレートを選択します。これを使うと、単一サーバ（AdminServer）にSOAおよびOSBコンポーネントをインストールするため、メモリ使用量が小さくなります。ドメインを作成して管理サーバ(AdminServer)を起動してから、jconsoleを立ち上げてJVMのメモリ使用量を確認したところ、最大1.5GBのところ1.3GBでコミットしていることを確認しました。驚いたことに、PermGenは最大500MB使うようです。初期デフォルトメモリサイズは750MBで、最大値は1.5GBなので、setSOADomainEnv.shを編集してメモリ設定を変更しました。初期メモリサイズを1.5GBとし、PORT_MEM_ARGSを設定することで、最大メモリサイズを2.5GBにしました。また、初期PermGenサイズを512MBに変更し、最大PermGenサイズは750MBとしました。

PORT_MEM_ARGS=”-Xms1536m –Xmx2560m”
PORT_MEM_ARGS=”${PORT_MEM_ARGS} -XX:PermSize=512m -XX:MaxPermSize=768m"

今回、PORT_MEM_ARGSを使ったのは、64bit Linuxだったからです。32bitシステム上ならDEFAULT_MEM_ARGSを使うでしょう。
ここでVMイメージのスナップショットをとれば、必要なときに戻ることができます。

本番ドメインの作成
単一サーバによる開発ドメインを作成したら、SOA/BPMのすべての環境をもつ本番環境のドメインも欲しくなりました。BPM Suite、SOA Suite、Enterprise Manager、Service Bus、Business Activity Monitoringのテンプレートをドメイン構成ウィザードから選択します。ドメインを本番モードに指定して、これ以外はデフォルトの設定でウィザードを実行します。これにより、独立した管理対象サーバ（soa_server1、bam_server1、osb_server1）が作成されます。コンソールは管理サーバ(AdminServer)で動作します。サーバを起動する前に、boot.propertiesを変更して以下のプロパティを追加しておきます。

username=weblogic
password=welcome1

次のディレクトリをドメインのディレクトリの下に配置し、boot.propetiesファイルを各々に保存します。

<Domain_Home>/servers/AdminServer/security
<Domain_Home>/servers/soa_server1/security
<Domain_Home>/servers/bam_server1/security
<Domain_Home>/servers/osb_server1/security

管理サーバを起動します。サーバ起動中に、以下のコマンドを実行して、ノードマネージャが管理対象サーバを起動できるようにした上で、ノードマネージャを起動します。

“$MW_HOME/oracle_common./common/bin/setNMProps.sh”

ノードマネージャが起動したら、コンソールが正常に動作していることを確認できました。その際、OSBサーバがマシンに割り当てられておらず、ノードマネージャからの起動ができないことがわかったので、"osb_server1"をデフォルトの"LocalMachine"に割り当てて、管理対象サーバを起動しました。
すべて問題なく動作したことを確認した上で、マシンをシャットダウンし、VMのスナップショットをとりました。

堅牢なベース
私はいつもこういうVM構成を使っていますが、これはベースとなるソフトウェアから所望の要件にあう新しいドメインをいつでも作成できるからです。しかし、ほとんどの場合既存ドメインの一つを利用することができます。この方法はディスクをかなり圧迫しますが、複数のイメージを持つための効率的な方法だと思います。これが皆さんのお役にたつことを願っています。

原文はこちら。
http://blogs.oracle.com/reynolds/entry/installing_the_latest_greatest

Oracle Blogs 日本語のまとめ

[SOA] Installing the Latest & Greatest

0 件のコメント:

コメントを投稿