Oracle Application Server 10g（9.0.4）の
クローニング
オラクル・ホワイト・ペーパー
2004 年 5 月
Oracle Application Server 10g（9.0.4）のクローニング
1. 概要 ... 3
2. サポートされるインストレーション・タイプ ... 3
2.1 クローニングの制約 ... 4
2.2 特定のコンポーネントの設定 ... 5
3. クローニング・プロセス ... 6
3.1 クローニング前のフェーズ ... 7
3.2 クローニング・フェーズ ... 7
3.3 クローニング後のフェーズ ... 7
4. クローニングの手順 ... 9
4.1 コマンドラインの使用 ... 9
4.2 Oracle Enterprise Manager 10g Grid Control の使用 ... 10
5. クローニング・プロセスのカスタマイズ ... 11
5.1 カスタム・ポートの割当て ... 12
5.2 インスタンス名の変更 ... 12
5.3 カスタム・データの更新 ... 13
6. 使用例: クローニングを使用したクラスタの拡張 ... 16
7. 結論 ... 17
8. 詳細情報 ... 17
Oracle Application Server 10g（9.0.4）のクローニング
1. 概要
このホワイト・ペーパーでは、Oracle Application Server 10g（9.0.4）のクローニン グについて説明します。クローニングとは、構成を保持した状態で別の場所へ既 存の Oracle Application Server インスタンスをコピーするプロセスです。次のよう な場合にクローニングが有効です。
• 本番、テスト、または開発用のインスタンスのコピーを作成する場合。 クローニングによって、すべてのパッチが適用された新しいインスタン スを 1 つのステップで作成できます。これは、Oracle Application Server のインストール、構成、パッチの適用を個別に行う通常のインストレー ション・プロセスとはまったく異なる方法です。 • インスタンスおよびそのインスタンスがホストするアプリケーションを 迅速に配置する場合 • パッチを適用したホームの「ゴールド」イメージを準備して多数のホス トに配置する場合 クローン・インスタンスは、ソース・インスタンスと同様に動作します。たとえ ば、クローン・インスタンスに対して、Oracle Universal Installer（OUI）を使用し て削除またはパッチを適用できます。また、クローン・インスタンスを別のクロ ーニング処理のソースとしても使用できます。
2. サポートされるインストレーション・タイプ
Oracle Application Server 10g（9.0.4）では、インフラストラクチャに関連付けられ ていない J2EE と Web Cache の中間層をクローニングできますが、Portal および Wireless の中間層または Business Intelligence および Forms の中間層はクローニン グできません。インフラストラクチャのクローニングもできません。
クローニング・プロセスは、ソース Oracle ホームからすべてのファイルをクロー ン先の Oracle ホームへコピーすることで機能します。したがって、ソース Oracle ホーム・ディレクトリ構造の外部にあるソース・インスタンスで使用されるファ イルは、クローン先には移動しません。
ファイルのコピー後に、一連のスクリプトを使用して主要な構成ファイルの情報 を更新します。たとえば、httpd.conf と webcache.xml ファイル内ののホスト名およ び Oracle ホームに対するすべての参照は新しい値に更新されます。 ソース・インスタンスに配置されたアプリケーションは、ソース Oracle ホームの ディレクトリ構造内にあればクローン先のインスタンスへすべて移動して自動的 に配置されます。
2.1 クローニングの制約
Oracle Application Server 10g（9.0.4）のインスタンスのクローニングには、次の制 約があります。
1. 次のインストレーション・タイプはクローニングできません。 • Portal および Wireless の中間層
• Business Intelligence および Forms の中間層
• インフラストラクチャ、つまり Identity Management または Metadata Repository • Developer Kits 2. クローニングするインスタンスがクラスタの一部である場合、クローニ ング前にそのインスタンスをクラスタから切り離す必要があります。 3. クローン・インスタンスは、ソース・インスタンスと同じインスタンス 名になります。これは、ソース・インスタンスとクローン・インスタン スが同じクラスタまたはファームの一部にできないことを意味します。 ただしクローニング後は、必要に応じてクローン・インスタンスのイン スタンス名を手動で変更できます。詳細は 6.2 のセクションを参照してく ださい。 4. 次のコンポーネントに対してユーザーが行ったカスタマイズは保持され ません。これらのコンポーネントのステータスは、デフォルトのステー タスにリセットされます。 a. LogLoader b. Jserv c. BC4J d. ポート・トンネリング e. UIX f. XDK 5. クローニングでは、ソース Oracle ホームの従属関係（ロード可能なモジ ュールやアプリケーション固有のライブラリなど）を、クローン Oracle ホームへすべて継承するわけではありません。これは、ソース Oracle ホ ーム全体をクローン Oracle ホームへコピーすることによって、クローニ ング・プロセスが機能するためです。ソース Oracle ホームの外部ファイ ルは、自動的にはコピーされません。そのため、ソース Oracle ホームの 外部ファイルを参照するアプリケーションは、クローン Oracle ホームで は正しく機能しません。
6. ホームの外部ファイルまたはアプリケーションに対してシンボリック・ リンクを作成した場合、アプリケーションが正しく機能するように、ク ローン Oracle ホームでリンクを手動で再作成する必要があります。
2.2 特定のコンポーネントの設定
このセクションでは、クローン Oracle ホームの特定のコンポーネントに対する影 響について説明します。Oracle HTTP Server
次のファイルの構成情報はすべて更新されます。 • ORACLE_HOME/Apache/Apache/conf/httpd.conf • ORACLE_HOME /Apache/Apache/conf/oracle_apache.conf • ORACLE_HOME /Apache/Apache/conf/mod_oc4j.conf • ORACLE_HOME /Apache/modplsql/conf/dads.conf • ORACLE_HOME /Apache/modplsql/conf/plsql.conf • ORACLE_HOME /Apache/modplsql/conf/cache.conf • ORACLE_HOME /Apache/oradav/conf/moddav.conf クローニング・スクリプトは、ソース・インスタンスの設定を保持し、新しい環 境パラメータでこれらのファイルを更新します。 クローニングでは、クローニングで認識されるファイル、つまりオリジナル・イ ンストレーションの一部であるファイルのみが更新されます。特に、クローニン グでは、httpd.conf の「include」構成ファイル（oracle_apache.conf、dads.conf、plsql.conf、 olap.conf、moddav.conf など、ユーザーによってインクルード・リストに追加され たファイル）は更新されません。ただし、クローニングで更新するファイルのリ ストに、これらのファイルの明示的な追加はできます。カスタム・ファイルの更 新方法の詳細は、5.3 のセクションを参照してください。 クローニングでは、httpd.conf のすべての VirtualHost ディレクティブが保持され、 これらのディレクティブ内のソース Oracle ホームに対するすべての参照は置換さ れます。ただしクローニングでは、仮想ホストがリスニングしている IP アドレス またはポート番号は変更されません。これらの値はクローン先の環境で有効では ないため、ユーザーには次のいずれかの処理が必要となります。 • クローニングと同時に更新されるよう、これらの変更をクローニング・ スクリプトに登録します。 • クローニング後に、httpd.conf を手動で更新します。Oracle Components for Java（OC4J）
クローン Oracle ホームでは、ソース Oracle ホームの次の OC4J コンポーネントが 保持されます。
• インストールされたデフォルトの OC4J インスタンスはすべて保持され ます。
• ユーザーが作成したカスタム OC4J インスタンス、およびそのインスタン スに配置されたアプリケーションは保持されます。ただし、これらアプ リケーション従属関係の中で、Oracle ホーム内にない外部ファイルはクロ ーン Oracle ホームにはコピーされずに失われます。
• デフォルトおよびカスタムの OC4J インスタンスは、クローン Oracle ホー ムの Oracle Enterprise Manager 10g Application Server Control を介して使用 および管理できます。また、OPMN でこれらの OC4J インスタンスも管理 できます。 • data-sources.xml のデータ・ソース情報は保持されます。 • jms.xml、java2.policy、jazn.xml、jazn-data.xml、global-web-application.xml、 および application.xml のユーザー構成は保持されます。 カスタム OC4J インスタンスの環境固有の情報を含むファイルは、クローニング 時に更新されるようにユーザーが手動で登録する必要があります。このようなフ ァイルには、oc4j.properties があります。詳細は 5.3 のセクションを参照してくだ さい。
Web Cache
webcache.xml および internal.xml の設定は保持されます。Oracle ホームの場所、ホ スト名、インスタンス名、およびポート番号のみが、新しい環境を反映して更新 されます。
クローン Oracle ホームで Web Cache クラスタを使用する場合は、必要に応じたク ラスタの再構成が必要です。クローン Oracle ホームでは、クラスタ内の他のノー ドへの参照がそのまま含まれますが、他のノード自体は新しいインスタンスを認 識しません。クローン・インスタンスをクラスタに追加するか、またはクローニ ング完了後にクラスタの削除が必要です。
Oracle Enterprise Manager 10g Application Server Control
Oracle Enterprise Manager 10g Application Server Control は、ソースで管理されてい たインスタンスと同じインスタンスを管理できます。また、emd.properties および emd-website. xml ファイルを保持すると、ソース・インスタンスの SSL 設定も保持 されます。つまり、ソースの Application Server Control が HTTPS 用に構成されて いる場合は、クローニングした Application Server Control も同様に構成されます。
3. クローニング・プロセス
クローニング・プロセスでは、OUI のクローニング機能を利用します。クローニ ングの処理は、クローニング・パッチに含まれるスクリプトおよびアドオンによ って行われます。
クローニングはコマンドラインからまたは Oracle Enterprise Manager 10g Grid Control が提供するグラフィカル・インタフェースで実行することもできます。
コマンドラインからのクローニングには、スクリプトの clone.pl の実行が必要です。 これは、クローニング操作のすべてを自動的に実行する Perl スクリプトで、必要 に応じて他の様々なユーティリティと OUI をコールします。このスクリプトは、
OUI のクローニング機能を利用します。clone.pl スクリプトが呼び出された場合は、 次の 3 つのフェーズが行われます。 1. クローニング前のフェーズ 2. クローニング・フェーズ 3. クローニング後のフェーズ それぞれのフェーズについては、後述のセクションで詳しく説明します。clone.pl スクリプトは 3 つのフェーズをすべて自動的に処理します。そのため、手動によ るフェーズは必要ありません。次に、これらのフェーズの概要を説明します。
3.1 クローニング前のフェーズ
クローニング前のフェーズでは、クローニングを確実にするための必要な準備を します。次に、clone.pl によってこのフェーズで実行されるいくつかのタスクを説 明します。 1. クローニング前のステップの実行に OUI を呼び出します。これによって、 ターゲット・インベントリに、Oracle ホーム・コンポーネント以外でクロ ーニングに必要なすべてのものが確実に用意されます。 2. ORACLE_HOME/config/ias.properties ファイルからインスタンス名を取得 します。この情報はクローニング・フェーズで OUI を呼び出す場合に必 要です。ias.properties ファイルの次に示す変数からインスタンス名を取得 します。 IASname=<instance_name>.<host_name>. 実行するタスクの正確なリストは、プラットフォームによって多少異なります。3.2 クローニング・フェーズ
clone.pl はこのフェーズで、OUI ホーム・クローニングの実行に必要な引数を使用 して、OUI をクローン・モードで呼び出します。これによって、インスタンス化 された既存のファイルのバックアップ作成後、すべてのファイルの再インスタン ス化、環境変数の設定、リンクの更新などが行われます。つまり、インストール 時に実行されたファイル・コピー以外のすべてのアクションが再実行されます。3.3 クローニング後のフェーズ
Oracle Application Server 10g（9.0.4）では、クローン時にインストール後の Configuration Assistant は再実行されません。そのため、Configuration Assistant によ る更新が必要なインスタンス固有のいくつかの構成ファイルは、OUI のクローニ ング・セッションの終了時にも更新されません。その代わりに、Oracle では一連 の「ポスト・クローニング・スクリプト」でこれらのファイルを更新し、クロー ン Oracle ホームを使用できます。 次に、このスクリプトによって実行されるクローニング後のステップについて説 明します。 1. 新しい Oracle ホームを DCM に設定します。
2. 構成ファイルを更新します。このステップでは、クローニング・フェー ズで OUI によって再インスタンス化された多数の構成ファイルがバック アップからリストアされます。これらのファイルは、必要に応じて新し い環境を反映した値に更新されます。たとえば、ファイルがソース Oracle ホームを参照する場合は、クローン Oracle ホームを参照するように更新 されます。 3. クローン Oracle ホームの chgiphost ユーティリティをコールして、クロー ン Oracle ホームのホスト名と IP アドレスの情報を変更します。chgiphost のコール前に、chgiphost をサイレント・モードで呼び出すために必要な 入力情報を収集する必要があります。必要な入力情報は次のとおりです。 • ソースのホスト名 • ソースの IP アドレス • クローン先のホスト名 • クローン先の IP アドレス
4. chgiphost を正常に実行後、OPMN コマンドを使用して Application Server Control（emctl start iasconsole）およびサービス（opmnctl startall）を開始 します。これらのステップは、クローニング処理が成功したことの確認 に必要となります。
クローニング後のフェーズで更新されるファイル
クローニング後のフェーズで、重要ないくつかの構成ファイルがバックアップか らリストアされ更新されます。一般的なファイルの変更は、ホスト名、Oracle ホ ーム、およびポート番号などの環境固有の変数を新しい値に更新します。 更新される主なファイルを次に示しますが、完全なリストではありません。 • ORACLE_HOME/config/ias.properties • ORACLE_HOME/sysman/emd/targets.xml • ORACLE_HOME/sysman/config/dcmPlugins.xml • ORACLE_HOME/sysman/j2ee/application-deployments/em/emd/orion-web.xm l • ORACLE_HOME /Apache/Apache/conf/mod_oc4j.conf • ORACLE_HOME/opmn/conf/opmn.xml • ORACLE_HOME/Apache/Apache/conf/httpd.conf • ORACLE_HOME /Apache/oradav/conf/moddav.conf • ORACLE_HOME /Apache/modplsql/conf/plsql.conf • ORACLE_HOME /Apache/modplsql/conf/cache.conf • ORACLE_HOME /Apache/Apache/conf/oracle_apache.conf4. クローニングの手順
クローニングには、次の 2 つの方法があります。 • コマンドラインを使用する
• Oracle Enterprise Manager 10g Grid Control を使用する このセクションでは、これらの詳しいステップを説明します。
4.1 コマンドラインの使用
コマンドラインから Oracle Application Server 10g（9.0.4）J2EE および Web Cache の中間層をクローンする手順は次のとおりです。
1. ソース Oracle ホームを 1 つにまとめ tar で圧縮します。ここでは、ディレ クトリ内のファイルのタイム・スタンプを保持する圧縮方法を使用して ください。
cd <Source_Oracle_Home>
tar cf - * | gzip > oracleas.tar.gz
2. 圧縮した Oracle ホームを、ソース・マシンからクローン先マシンへコピ ーします。 3. クローニング・パッチをクローン先のマシンの任意のディレクトリに unzip（解凍）します。クローニング・パッチには、ClonerStage.9.0.4.0.0.zip と Readme.txt が含まれています。 4. ClonerStage_9.0.4.0.0.zip ファイルを、任意のディレクトリへ unzip（解凍） します。 5. 圧縮された Oracle ホームを、クローン先の新しい Oracle ホームのディレ クトリへ解凍します。 mkdir –p <Destination_Oracle_Home> gunzip < <Dir_containing_tar>/oracleas.tar.gz | tar xf - 注意: ソース・マシンとクローン先マシンの tar および gzip/gunzip のバージョ ンは同じ必要があります。異なったバージョンの場合、アーカイブを unzip（解 凍）する時に問題が発生します。 6. 次の例に示すように、2 つのパラメータを渡して clone.pl スクリプト （ClonerStage の最上位のディレクトリにある）を実行します。Oracle イン ベントリ・ファイルを含むディレクトリに対する書込み権限を持つ必要 があります。 <Oracle_Home>/bin/perl clone.pl ORACLE_HOME=<Oracle_Home> ORACLE_HOME_NAME=<Oracle_ Home_Name> ここで ORACLE_HOME はクローン先の新しい Oracle ホームの絶対パスを表 し、ORACLE_HOME_NAME は、新しい Oracle ホームの名前を表します。
注意: UNIX で Perl スクリプトの実行前に、PERL5LIB 環境変数に対して次の ように Perl ディレクトリのパスを設定する必要があります。
setenv PERL5LIB <Oracle_Home>/perl/lib/5.6.1:
<Oracle_Home>/perl/lib/site_perl/5.6.1
clone.pl スクリプトの実行終了後、クローン・インスタンスの構成はソース・イン スタンスの構成と同じになります。Oracle Enterprise Manager 10g Application Server Control と OPMN は、OC4J_Custom インスタンスも含め、クローン・インスタン スのすべてのプロセスを開始および停止できます。配置されたすべてのアプリケ ーションは、参照可能で予想どおりに実行できます。
ログ・ファイルの場所
クローニング・スクリプトは複数のツールを呼び出しますが、これらのツールは 個別にログ・ファイルを生成します。ただし、診断を目的としたログ・ファイル は OUI により生成されます。これらのファイルは次のとおりです。clone.pl スクリ プトの実行終了後、これらのログ・ファイルからクローニング・プロセスの詳し い情報を取得できます。 • <OUI_Central_inventory>/logs/cloneActions<timestamp>.log−このファイル は、クローニングの OUI パートで発生したアクションの詳細なログを含 みます。 • <OUI_Central_inventory>/logs/oraInstall<timestamp>.err−このファイルは、 OUI の実行中に発生したエラーの情報を含みます。 • <OUI_Central_inventory>/logs/oraInstall<timestamp>.out−このファイルは、 OUI で生成された様々なメッセージを含みます。4.2 Oracle Enterprise Manager 10g Grid Control の使用
Grid Control を使用して Oracle Application Server 10g（9.0.4）J2EE および Web Cache の中間層をクローンする手順は次のとおりです。 1. クローニング・パッチの README.txt ファイルの指示に従いパッチを適 用します。 2. 次のステップに従って、Grid Control からクローニング・ウィザードを起 動します。 a. Grid Control にログオンします。 b. 「デプロイ」タブをクリックします。 c. 「クローン Oracle ホーム」リンクをクリックします。 3. ウィザードの指示に従います。 注意: Grid Control では、クローニングを実行するジョブを生成します。ウィ ザードの最後のステップで「終了」をクリックすると、ジョブ・ページへの リンクが示されます。ジョブ・ページでは、クローニングのステータスを監 視して、実行中のステップのログを参照できます。
4.3 クローニング後の作業
コマンドラインまたは Grid Control からのクローニング後に、root ユーザーとして 構成スクリプト（ORACLE_HOME/root.sh）を手動で実行する必要があります。ク ローン Oracle ホームの root.sh ファイルはクローニング中に更新され、環境固有の 変数が適切にセットされています。
1. クローニング直後には、クローン・インスタンスは起動された状態です。 すべてのプロセスを終了します。
% <ORACLE_HOME>/bin/emctl stop iasconsole
% <ORACLE_HOME>/opmn/bin/opmnctl stopall
注意: Grid Control からのクローニングでは、クローニング直後には Application Server Control は起動されません（Bug 3610468）。
2. root ユーザーとして、root.sh を実行します。
% su
Password:
# <ORACLE_HOME>/root.sh
3. クローン・インスタンスを起動をします。
% <ORACLE_HOME>/bin/emctl start iasconsole
% <ORACLE_HOME>/opmn/bin/opmnctl startall これでクローニングは完了です。
5. クローニング・プロセスのカスタマイズ
多くの場合、クローニングはデフォルトのクローニング・プロセスで十分ですが、 手動の構成ステップでクローニング・プロセスのいくつかの部分をカスタマイズ できます。次のような場合はカスタマイズが便利です。 • カスタム・ポートの割当て • インスタンス名の変更 • カスタム・データの更新 後述のセクションでは、これらの場合について詳しく説明します。注意: Grid Control を使用したクローニングの場合、構成ファイルは zip されたディ レクトリ内にあるため、構成ファイルを直接編集できません。かわりに、次のス テップでクローニング・プロセスをカスタマイズします。
1. クローニング・パッチの README.txt を参照して、パッチを適用します。
2. パッチを適用したディレクトリ（<Grid Control OH>/sysman/clonerStage/
ias/p<id>）にある ClonerStage_9.0.4.0.0.zip ファイルを、一時ディレクトリ へ解凍します。
3. セクション 5.1 から 5.3 での説明のように、クローニング・プロセスのカ スタマイズに必要な構成ファイルを編集します。
4. 編集したファイルを含むディレクトリを、ClonerStage_9.0.4.0.0.zip ファイ ルに zip しなおします。 5. パッチを適用したディレクトリにある ClonerStage_9.0.4.0.0.zip ファイル を、更新された構成ファイルを含む新しいバージョンの ClonerStage9.0.4.0.0.zip ファイルで置き換えます。
5.1 カスタム・ポートの割当て
デフォルトでは、クローニング・スクリプトは空ポートを自動的に割り当て、 portlist.ini ファイルに記載します。クローニングの際にデフォルト・ポートを割り 当てるアルゴリズムは、Oracle Application Server のインストールで使用するアル ゴリズムと同じです。新しい Oracle Application Server インスタンスのインストールでは、staticports.ini ファイルにポートを記載して使用するポートを指定できます。このファイルは、 OUI をコールするときにパラメータ値として渡されます。ポートの割当て方法、 および staticports.ini ファイルの使用の詳細は『Oracle Application Server 10gインス
タレーション・ガイド』を参照してください。
Oracle Application Server インスタンスをクローニングする場合は、OUI を直接コ ールしません。従って、コマンドラインで staticports.ini ファイルを指定したカス タム・ポートの割当てはできません。ただし、構成ファイルの cs.properties 内で staticports.ini ファイルの場所を指定することで、ポート情報を間接的に OUI に渡 すことができます。このファイルは、クローニング・スクリプトを含む最上位デ ィレクトリの conf サブディレクトリにあります。 クローニングでのカスタム・ポートの割当てを次に示します。
1. 『Oracle Application Server 10gインスタレーション・ガイド』で説明され ているように、staticports.ini ファイルにポート番号を記載します。 2. conf/cs.properties ファイルに次の行を追加し、staticports.ini ファイルの場 所を指定します。 clone_command_line = oracle.iappserver.iapptop:s_staticPorts= <staticports.ini_location> staticports.ini ファイルに記載したポート番号はクローニング時に読み込まれ、その 記述に対応して OUI はポート番号を割り当てます。 注意: 通常、コマンドラインで指定する他の OUI パラメータも、同様の方法です べて指定できます。たとえば、Oracle インベントリ・ファイルに対するデフォル ト以外の場所を指定には、cs.properties ファイルに次の行を追加します。 clone_command_line= -invptrloc /private/oracle/oraInst.loc
5.2 インスタンス名の変更
デフォルトではクローン・インスタンスは、ソース・インスタンスと同じインス タンス名になります。ただし、クローン・インスタンス名は手動で変更できます。
これは、Oracle Application Server クラスタに対してソース・インスタンスとクロ ーン・インスタンスを追加する場合などに便利です。 クローニング終了後に、クローン・インスタンスのインスタンス名を変更する手 順を次に示します。
ソースでの処理
1. DCM アーカイブを作成します。./dcmctl createArchive -arch <archive_name>
2. 次に、アーカイブを JAR ファイルへエクスポートします。
./dcmctl exportArchive –arch <archive_name> –f
/exports/testConfig 3. JAR アーカイブをクローン先の Oracle ホーム・ディレクトリへコピーし ます。
クローン先での処理
1. クローン Oracle ホームから実行中のすべてのプロセスをシャットダウン します。 2. dcm.conf、ons.conf および dcm/repository ディレクトリを削除します。 3. ORACLE_HOME/dcm/config/instname ファイルを、新しいインスタンス名 で更新します。または、このファイルを削除して新しいインスタンス名 で再作成することもできます。 4. DCM デーモンを開始します。 ./dcmctl start -admin これによって、新しいインスタンス名、インスタンス ID およびリポジト リ ID が生成されます。 5. ステップ 4 で生成したインスタンス名を変更するには、次のコマンドを 使用します。 ./dcmctl setInstanceName <new_name> 6. targets.xml、opmn.xml、および ias.properties ファイル内のインスタンス名 を手動で更新します。 7. DCM リポジトリへアーカイブをインポートします。./dcmctl importArchive –arch <archive_name> –f /exports/testConfig 8. アーカイブを適用します。 ./dcmctl applyArchiveTo –src <archive_name>
5.3 カスタム・データの更新
デフォルトでのクローニング・スクリプトは、Oracle ホームの主要な構成ファイ ルを更新するため、これらの構成ファイルにはクローン先の環境の正しい情報が含まれます。デフォルトで更新される主なファイルのリストは、セクション 3.3 を参照してください。 デフォルトでは更新されないカスタム・データを更新するよう、デフォルトのク ローニング・プロセスを変更できます。クローニングで更新するファイル、およ びこれらのファイル内で更新するエントリの情報は別のファイル・セットに含ま れ、クローニング・スクリプトによって読み込まれます。これらのファイルを編 集すると、次のことが可能です。 • デフォルトではクローニングで更新されないソース Oracle ホームのファ イルに対する変更を保持します。 • クローニング時にデフォルトで更新されるファイルに対する、通常のク ローニング・プロセスでは保持されない変更を保持します。 これらの変更は、FileFixer とよばれる Java ユーティリティが行います。このユー ティリティは、正規表現のマッチングによって特定のテキスト文字列を検索し、 対象の文字列を新しい値に更新します。クローニング・スクリプトで取得できる 重要な変更、および変更を指定する構文の概要を次に示します。 • 変更が必要なホスト名が含まれるファイルのフルパス名を、次のファイ ルに追加してファイル内のホスト名を変更します。 ORACLE_HOME/chgip/config/hostname.lst. • XML 構成ファイル ClonerStage/FileFixer/fixup_script.xml.tmpl に replace タ グを追加し、あるファイルの Oracle ホームのすべての参照を古い値から 新しい値へ更新します。file_name 属性の値は、値を更新するファイルの 名前と場所を表します。たとえば次のタグは、dcmPlugins.xml ファイルの Oracle ホームの値を更新します。 <cfw:operation> <replace file_name="%NEW_HOME%/sysman/config/dcmPlugins.xml"> <cfw:replaceCommand> <cfw:pattern>(%OLD_HOME%)</cfw:pattern> <cfw:value_ref>1</cfw:value_ref> <cfw:new_value>%NEW_HOME%</cfw:new_value> </cfw:replaceCommand> </replace> </cfw:operation> • FileFixer/fixup_script.xml.tmpl に alter タグを追加し、ファイル 1 から値を 抽出してファイル 2 の値を置き換えます。たとえば、次のタグを追加す ると、クローン Oracle ホームの portlist.ini ファイルから新しい HTTP のポ ート番号が抽出され、targets.xml の古いポート番号をその新しい番号に置 き換えます。 <cfw:operation> <alter cluster="false" alter_file_name="%NEW_HOME%/sysman/emd/targets.xml" reference_file_name="%NEW_HOME%/install/portlist.ini">
<cfw:alterCommand>
<cfw:pattern>(Oracle HTTP Server port)([ ]*)(=)([ ]*)([0-9]*)</cfw:pattern> <cfw:value_ref>5</cfw:value_ref> <cfw:subst>(Property NAME="HTTPPort" VALUE=")([0-9]*)(")</cfw:subst> <cfw:subst_ref>2</cfw:subst_ref> </cfw:alterCommand> </alter> </cfw:operation>
6. 使用例: クローニングを使用したクラスタの拡張
クローニングの一般的な使用方法として Oracle Application Server クラスタのサイ ズの拡張があります。構成とアプリケーションの配置が同じである、複数の J2EE および Web Cache の中間層で構成されるクラスタを考えます。このクラスタの拡 張には、他のインスタンスと同様の構成で新しい中間層のインスタンスを作成し、 それをクラスタに追加する必要があります。この処理は、次の 2 つの制約がある ため、デフォルトのクローニング・プロセスでは対処できません。
• クラスタの一部である Oracle Application Server インスタンスはクローン できない。 • クローン・インスタンスとソース・インスタンスを同じクラスタに追加 できない。 ただし、これらの 2 つの制約は、セクション 5 で説明した手動によるカスタマイ ズで解消できます。クラスタの拡張には、次の手順に従います。 1. クラスタおよびファームからいずれかのインスタンスを切り離します。 2. このインスタンスをソース・インスタンスとして使用して、クローンを 作成します。 3. クローン・インスタンスのインスタンス名を変更します。 4. クラスタとファームに対して、ソース・インスタンスとクローン・イン スタンスを追加します。 次に、各手順について説明します。
クラスタとファームからソース・インスタンスを切り離す
ソース・インスタンスで次のコマンドを発行します。 ./dcmctl leaveCluster ./dcmctl leaveFarmソース・インスタンスをクローンして新しいインスタンスを作成する
作成には、セクション 4 で説明した標準のクローニング手順を使用します。クローン・インスタンスのインスタンス名を変更する
変更には、セクション 5.2 で説明した手順に従います。クラスタとファームに対して、ソース・インスタンスとクローン・インス
タンスを追加する
追加には、次のコマンドを発行します。 ./dcmctl joinFarm ./dcmctl joinCluster ソース・インスタンスとクローン・インスタンスの両方に対し、これらのコマン ドの実行が必要です。注意: これらのコマンドのいくつかは、Application Server Control でも実行できま す。
7. 結論
Oracle Application Server インスタンスをクローニングすると、インスタンスのイ ンストール、構成、更新、およびパッチ適用のタスクを 1 つの手順で実行できま す。この方法には、1 つの Oracle Application Server インスタンスを構成および保 守して必要に応じた回数だけ複製すれば済むという利点があります。関連する Oracle Application Server インスタンスのコレクションを短期間で作成および拡張 する場合にクローニングをお薦めします。
または Oracle が提供するクローニング・パッチを使用すると、Oracle Application Server 10g（9.0.4）のテスト、開発、または本番用のインスタンスのクローンをす ぐに作成できます。このホワイト･ペーパーでは、クローニング・プロセスの概要、 およびコマンドラインと Grid Control の両方を使用したクローニングの具体的な 方法を説明しました。クローンが作成できる Oracle Application Server のインスト レーション・タイプ、およびクローニング・プロセスの制約についても取り上げ ています。 多くの場合、デフォルトのクローニング手順で十分ですが、カスタム・ポートの 割当てを指定する、カスタム・ファイルの設定を保持する、クローン・インスタ ンスの名前を変更してクラスタに追加する、といったクローニング・プロセスの いくつかの部分もカスタマイズできます。このホワイト・ペーパーの情報で、ク ローニングを最適に利用し、Oracle Application Server インスタンスが管理できま す。
8. 詳細情報
このホワイト･ペーパーに記載したトピックの詳細情報は、次を参照してください。
• Oracle Application Server 10g Concepts • Oracle Application Server 10g Installation Guide • Oracle Application Server 10g Administrator’s Guide
Oracle Application Server 10g（9.0.4）のクローニング 2004 年 5 月
著書: Pavi Sandhu
寄稿者: Mohamed Nosseir および Nicole Haba Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com
Copyright © 2004, Oracle. All rights reserved.
この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。 オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載 されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証 または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、 契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理 的に、いかなる形式や方法によっても再生または伝送することはできません。
