10gリリース3（10.1.3.1.0）
B31834-01
 目次 |
 索引 |
| Oracle Application Server 管理者ガイド 10gリリース3（10.1.3.1.0） B31834-01 |
|
Oracle Application Serverをインストールすると、Oracle Enterprise Manager 10g Application Server Controlおよびその関連プロセスが自動的に起動します。起動後は、すぐにApplication Server Controlコンソールを使用してアプリケーション・サーバーのコンポーネントを管理できます。
Application Server Controlの制御および構成もできます。たとえば、Application Server Controlの起動と停止、Application Server Controlコンソールのパスワード変更、Application Server Controlのセキュリティ構成などができます。
この付録では、Application Server Controlの管理と構成の方法について説明します。この付録の項目は次のとおりです。
10gリリース3（10.1.3.1.0）では、Application Server Controlは標準のJ2EEアプリケーションとしてデプロイされます。Application Server Controlアプリケーション（ascontrol）は、作成するすべてのOC4Jインスタンスに自動的にデプロイされます。
そのため、第3.3.1項「opmnctlを使用したコンポーネントの起動と停止」の手順を使用して、コマンドラインからascontrolアプリケーションを起動および停止することができます。
アクティブなascontrolアプリケーションはApplication Server Controlコンソールからも停止および再起動できますが、このリリースでデプロイされる他のJ2EEアプリケーションと異なり、ascontrolアプリケーションのApplication Server Controlコンソールからの起動および停止には次のような制限が伴います。
ascontrolアプリケーションを起動、停止または再起動することはできません。ascontrolアプリケーションを停止すると、Application Server Controlコンソールを表示したり、使用したりできなくなります。
ascontrolアプリケーションを起動、停止または再起動できます。ただし、アクティブなascontrolアプリケーションを停止することによる影響を警告するメッセージが表示されます。アクティブなascontrolアプリケーションとは、Oracle Application Server環境の管理に現在使用されているApplication Server Controlです。アクティブなascontrolアプリケーションを停止すると、そのアプリケーションを起動するまで、Application Server Controlコンソールを使用できなくなります。
Application Server Controlコンソールを使用して2つ目のascontrolアプリケーションを起動することはできません。起動しようとすると、Application Server Controlにアクティブなascontrolアプリケーションがすでに実行中であることを示すエラー・メッセージが表示されます。
アクティブなascontrolアプリケーションのデプロイに使用されるOC4Jインスタンスは、管理OC4Jインスタンスと呼ばれます。管理OC4Jインスタンス以外のOC4Jインスタンスは、リモートOC4Jインスタンスと呼ばれます。ほとんどの場合、リモートOC4Jインスタンスでascontrolを起動する必要はありません。
ただし、リモートOC4Jインスタンスでascontrolアプリケーションを実行しなければならない場合もあります。詳細は、Application Server Controlのオンライン・ヘルプのリモート・ログ・ファイルを表示する場合のascontrolの起動に関する項を参照してください。
Application Server ControlコンソールのURLに移動することによって、Application Server Controlが起動されていることを確認できます。
http://hostname.domain:port/em
たとえば、次のように指定します。
http://mgmthost.acme.com:7777/em
Application Server Controlコンソールのポート番号を探すには、次のコマンドを使用してHTTP_Serverの番号を確認します。
(UNIX) ORACLE_HOME/opmn/bin/opmnctl status -l (Windows) ORACLE_HOME¥opmn¥bin¥opmnctl status -l
Application Server Controlを使用するには、Application Server Controlの管理者アカウントが必要です。環境を管理するときの権限は、Application Server Controlコンソールにログインするときに使用するユーザー・アカウントとパスワードによって決まります。
Oracle Application Serverをインストールすると、デフォルトのスーパー管理者アカウントが作成されます。これはoc4jadminというアカウントで、このアカウントのパスワードは、Oracle Application Serverのインストール時に設定します。このoc4jadminアカウントは、Application Server Controlコンソールへの初回ログイン時に使用できます。その後、管理ユーザー・アカウントを追加作成して、日常の管理タスクに使用できます。
管理者自身の管理アカウントのパスワードは、Application Server Controlコンソールへのログイン時に使用するユーザー・アカウントに関係なく、いつでも変更できます。ただし、oc4jadminパスワードを変更する際は、特別な注意事項があります。
次の各項で詳細を説明します。
自身の管理者アカウントを変更する手順は次のとおりです。
「パスワード」ページが表示されます。このページの「ユーザー」フィールドに、変更するアカウントが表示されます。oc4jadminユーザー・アカウントを変更する場合の詳細は、第A.2.3項を参照してください。
セキュリティを強化するために、新しいパスワードには次のような制限があります。
これらは、Application Server ControlおよびOracle Universal Installerによる制限であり、OC4Jのsystem-jazn.xmlファイルや、アプリケーションベースのセキュリティ構成ファイルによる制限ではありません。
次回ログインするときには、この新しいパスワードを使用する必要があります。
Oracle Application Server環境では、デフォルトのoc4jadmin管理ユーザー・アカウントは2つの異なる用途に使用されます。それぞれの用途について、次の項で説明します。
Oracle Application Serverのインストール時に、oc4jadminアカウントのパスワードを定義する必要があります。このoc4jadminアカウントは、Application Server Controlへの初回ログイン時に使用できます。
oc4jadminユーザー・アカウントには、自動的に一連の管理ロールが割り当てられます。これにより、このアカウントでログインしたユーザーは、OC4Jインスタンスのあらゆる側面を管理および構成できます。しかし、このoc4jadminアカウントを日常の管理タスクには使用しないでください。日常の管理タスクに使用する管理アカウントは、別途追加作成します。
oc4jadminアカウントは、Application Server Controlへの初回ログイン・アカウントとしての用途のほかに、Application Server Controlソフトウェアでの管理タスクの実行にも使用されます。特に、OC4Jインスタンスで構成タスクを実行する場合、Application Server Controlはoc4jadminユーザー・アカウントとパスワードを使用してインスタンスに接続します。このような場合のoc4jadminユーザー・アカウントとパスワードは、管理資格証明と呼ばれます。
具体的には、クラスタ・トポロジ・ページ上でOC4Jインスタンス名をクリックすると、Application Server Controlは管理資格証明を使用してOC4Jインスタンスに接続します。Application Server Controlはこれらの資格証明を使用して、ローカル管理OC4Jおよびクラスタ内のリモートOC4Jインスタンスの両方に接続します。この概念について、図A-1に説明しています。
各クラスタには管理資格証明が1組のみ存在します。デフォルトでは、管理OC4J（図A-1のOracleホーム1）用に定義したoc4jadminアカウントとパスワードが、クラスタの管理資格証明として保存されています。
そのため、クラスタ内の各OC4Jインスタンスにoc4jadminユーザー・アカウントが存在する必要があり、そのoc4jadminアカウントのパスワードは管理OC4Jに定義されたパスワードと同じである必要があります。そうしないと、クラスタに定義した管理資格証明は機能せず、Application Server ControlはOC4Jインスタンスに接続できなくなります。
後でoc4jadminアカウントのパスワードを変更することはできますが、Oracle Application Serverインスタンスのクラスタを管理する場合は、oc4jadminパスワードを変更する際に注意が必要です。
管理OC4Jインスタンスのoc4jadminパスワードを変更する手順は、自身の管理者パスワードを変更する手順と同じです。oc4jadminユーザー名とパスワードを使用してログインし、「設定」をクリックします。
ただし、oc4jadminパスワードを変更すると、Application Server Controlコンソールから実行する一部の操作に影響が生じる可能性があります。これは、oc4jadminのユーザー名とパスワードがクラスタ・トポロジの管理資格証明として使用されているためです。詳細は、第A.2.2.2項を参照してください。
Application Server Controlコンソールの任意のページで「設定」をクリックしてoc4jadminパスワードを変更した場合は、管理OC4Jインスタンスのoc4jadminアカウントのパスワードのみが変更されます。
「設定」リンクからのパスワード変更は、リモートOC4Jインスタンスで使用されているoc4jadminパスワードには適用されません。リモートOC4Jインスタンスとは、アクティブなApplication Server Controlをホストしていないクラスタ・トポロジ内のOC4Jインスタンスです。
そのため、Application Server Controlコンソールの「設定」リンクを使用して、リモートOC4Jインスタンスで定義したものと異なるようにoc4jadminパスワードを変更すると、「クラスタ・トポロジ」ページからこれらのインスタンスにナビゲートできなくなります。管理資格証明が無効になったOC4Jインスタンスのホーム・ページを表示しようとすると、Enterprise Managerによって次のようなエラー・メッセージが表示されます。
Unable to make a connection to OC4J instance instance_name on Application Server application_server_name. A common cause for this failure is an authentication error. The administrator password for each OC4J instance in the Cluster must be the same as the administrator password for the OC4J instance on which Application Server Control is running.
この問題を解決するには、リモートOC4Jインスタンスの管理資格証明を、管理OC4Jの管理資格証明と一致するように変更する必要があります。
クラスタ・トポロジで複数のOC4Jインスタンスを管理している場合は、「クラスタ・トポロジ」ページの上部にある「設定」リンクを使用すると、ascontrolアプリケーションをホストする管理OC4Jのパスワードを変更できます。
一方、クラスタ・トポロジのリモートOC4Jインスタンスのoc4jadminパスワードを変更するには、次の手順を実行する必要があります。
この手順では、次のことを前提としています。
oc4jadminアカウントが、クラスタの管理資格証明として使用されているものとします。
oc4jadminパスワードは、現時点では管理OC4JインスタンスとリモートOC4Jインスタンスで同じものとします。それらが異なる場合、Application Server Controlを使用してリモートのoc4jadminパスワードを変更することはできません。その場合は、第A.2.5項で説明している手順を実行します。
Application Server Controlを使用してリモートOC4Jインスタンスのoc4jadminパスワードを変更するには、次の手順を実行します。
アクティブなascontrolアプリケーションをホストする管理OC4Jではなく、必ずリモートOC4Jインスタンスを選択してください。
選択したリモート・インスタンスのOC4Jホーム・ページが表示されます。
3など）をクリックします。選択したセキュリティ・プロバイダに定義されているユーザーが一覧表示されます。
oc4jadminユーザー・アカウントを変更します。
oc4jadminアカウントのパスワードを変更し、「適用」をクリックします。
Application Server Controlを使用せずにリモート・アカウントのoc4jadminパスワードを変更するには、次の手順を実行します。
ORACLE_HOME/j2ee/oc4j_instance_name/config/system-jazn-data.xml
system-jazn-data.xmlファイルを開き、oc4jadminユーザーの次のエントリを探します。
<user> <name>oc4jadmin</name> <display-name>OC4J Administrator</display-name> <guid>41A2E560C96711DABFD08D3BF8B780C4</guid> <description>OC4J Administrator</description> <credentials>{903}4nlfYYDwaqMJipVbGXuS2ce8egfwBPqp</credentials> </user>
たとえば、次のように指定します。
<credentials>!abcdefg1234</credentials>
この例のabcdefg1234の部分を、実際に使用するパスワードに置き換えます。
感嘆符（!）を使用することにより、パスワードはこの構成ファイル内で暗号化されます。
system-jazn-data.xmlファイルを終了します。
たとえば、次のOracle Process Manager and Notification Server（OPMN）コマンドを使用して、Oracle Application Serverインスタンスを停止した後に起動します。
ORACLE_HOME/opmn/bin/opmnctl stopall ORACLE_HOME/opmn/bin/opmnctl startall
Application Server Controlコンソールを保護するには、次の2種類の通信リンクを保護する必要があります。
セキュリティを有効にすると、トレードオフが発生します。つまり、セキュリティの強化には、SSLの使用や、より高い処理能力とより多くのメモリーが必要となります。したがって、セキュリティ対策は、環境に応じて必要な部分に施すことをお薦めします。
次の各項では、Application Server Controlアプリケーションのセキュリティを構成する方法について説明します。
デフォルトでは、Application Server Controlのユーザー資格証明は、企業ネットワークまたはインターネットを介して、ブラウザからWebサーバーにクリア・テキストとして送信されます。そのため、セキュリティ攻撃を受けやすくなります。
ブラウザ・クライアントと、Application Server ControlをホストするWebサーバーとの間の通信を保護するには、Application Server Controlのユーザー資格証明を含め、Application Server Controlの通信をすべて暗号化する必要があります。
セキュアな構成では、ブラウザ・クライアントはHTTPS経由で管理OC4Jインスタンスに直接接続し、Application Server Controlコンソールにアクセスします。この構成は、OC4Jのスタンドアロン・インストール環境とOracle Application Server環境の両方に推奨されます。
次の手順では、HTTPSを使用してApplication Server Controlコンソール・クライアントを処理するための管理OC4Jインスタンスの構成方法を説明します。
管理OC4JインスタンスのキーストアおよびSSL証明書を作成するには、次の手順を実行します。
keytool実行可能ファイルを使用して、RSA秘密鍵と公開鍵のペアが含まれるキーストアを作成します。これにより、OC4Jがブラウザ・クライアントとのセキュアなHTTP通信に使用できるSSL証明書が作成されます。keytool実行可能ファイルは、ORACLE_HOME/jdk/binディレクトリにあります。次のコマンドを使用します。
keytool -genkey -keyalg "RSA" -keystore keystore -storepass passwd -validity days
keyパスワードの入力を求められたら、別のパスワードを入力せずに、[Enter]を押します。keyパスワードは、生成した鍵ペアの秘密鍵の保護に使用されます。SSLを正しく機能させるには、キーストアと同じパスワードを使用する必要があります。
デフォルトのセキュアでないWebサイトからascontrol Webアプリケーションのバインドを解除するには、次の手順を実行します。
ascontrol）のWebモジュールがバインドされているWebサイトの構成ファイルを編集します。デフォルトでは、このファイルは次の場所にあります。
(UNIX) ORACLE_HOME/j2ee/Admin_OC4J_instance_name/config/default-web-site.xml (Windows) ORACLE_HOME¥j2ee¥Admin_OC4J_instance_name¥config¥default-web-site.xml
ascontrolアプリケーションをバインドしている<web-app>要素を削除します。たとえば、次の行を削除します。
<web-app application="ascontrol" name="ascontrol" root="/em" load-on-startup="true" ohs-routing="true" />
Application Server Control（ascontrol）アプリケーションに新しいWebサイトを作成します。これには、HTTPSを使用する管理OC4Jインスタンスに新しい構成ファイルを作成します。次の手順に従います。
ORACLE_HOME/j2ee/Admin_OC4J_instance_name/configディレクトリにある既存の*-web-site.xmlファイルをコピーして、新しいWebサイトを作成します。たとえば、default-web-site.xmlをascontrol-web-site.xmlにコピーします。
ascontrol-web-site.xmlファイルの<web-site>要素に、次の変更を行います。
display-name属性を変更して、Webサイトの表示名をASControl Secure HTTP Web Siteに変更します。
protocol属性をhttpに、secure属性をtrueに設定します。
port属性に新しいポート番号を設定します。たとえば、portを1156に設定します。
<ssl-config>要素と、必要なkeystoreおよびkeystore-passwordプロパティを追加して、前述の作業で作成したキーストアが参照されるようにします。
<access-log>要素のpath属性を、新しいWebサイトのアクセス・ログを保存する新しいログ・ファイルを指すように変更します。
ascontrolのWebモジュールをこのWebサイトにバインドします。
次の例は、ascontrol Webアプリケーション専用のWebサイトを定義する、ascontrol-web-site.xmlという名前のWebサイト構成ファイルの抜粋です。
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/web-site-10_ 0.xsd" port="1156" protocol="http" secure="true" display-name="ASControl Secure HTTP Web Site"" schema-major-version="10" schema-minor-version="0" > <default-web-app application="ascontrol" name="ascontrol" root="/ " /> <access-log path="../log/ascontrol-web-access.log" split="day" /> <ssl-config keystore="private/OracleAS_2/jdk/bin/mykeystore" keystore-password="welcome"/> </web-site>
keystore属性の値は、絶対パスまたは*-web-site.xmlファイルの位置からの相対パスです。
この例の場合、Application Server Controlコンソールのユーザーは、次のURLにアクセスすることで、このコンソールにアクセスします。
https://hostname:1156
管理OC4Jインスタンスに新しいWebサイトを登録します。
ORACLE_HOME /j2ee/Admin_OC4J_instance_name/configディレクトリで、server.xmlファイルを探します。
<application-server>要素に、新しいascontrol-web-site.xmlファイルを指す<web-site>要素を追加します（path属性は、絶対パスまたはserver.xmlファイルの位置からの相対パスです）。たとえば、次のように指定します。
<web-site path="./ascontrol-web-site.xml" />
(UNIX) ORACLE_HOME/opmn/conf/opmn.xml (Windows) ORACLE_HOME¥opmn¥conf¥opmn.xml
管理OC4Jの<ias-component>要素（ias-component IDはOC4J、process-type IDは管理OC4J名と同じ）を探します。管理OC4Jセクションに、新しいWebサイトの新しい<port>要素を追加します。たとえば、次のように指定します。
<ias-instance id="yellow.stadm21.ora.com" name="yellow.stadm21.ora.com"> . . . <ias-component id="OC4J"> <process-type id="home" module-id="OC4J" status="enabled"> . . . <port id="default-web-site" range="8989" protocol="http"/> <port id="secure-web-site" range="1156" protocol="https"/> <port id="rmi" range="12401-12500"/> <port id="jms" range="12601-12700"/> <process-set id="default_group" numprocs="1"/> . . . </process-type> </ias-component>
この例では、Oracle Application Serverインスタンスの名前がyellow.stadm21.ora.com、管理OC4Jインスタンスの名前がhomeになっています。
Oracle Application Server環境で、新しいopmn.xmlファイルでOPMNを再構成します。これには、opmn.xmlファイルをリロードし、管理OC4Jインスタンスを起動します。次のコマンドを使用します。
ORACLE_HOME/opmn/bin/opmnctl reload ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J
ORACLE_HOME¥opmn¥bin¥opmnctl reload ORACLE_HOME¥opmn¥bin¥opmnctl startproc ias-component=OC4J
環境によっては、Oracle Application Serverのコンポーネント間の通信を保護したほうがよい場合があります。それぞれの通信リンクは互いに依存していないため、保護するリンクと保護しないリンクを柔軟に決めることができます。次の方法を使用できます。
oc4jadminパスワードも暗号化します）。
リモートOC4Jインスタンスとは、Application Server Controlによってリモート管理されるOC4Jインスタンスです。リモートOC4Jインスタンスは、管理OC4Jインスタンスと同じOracleホーム、別のOracleホーム、同じホストまたは異なるホストに配置されている可能性があります。
次の各項では、これらの手順について説明します。
Oracle Application Server環境では、Application Server Controlを使用して管理OC4Jインスタンス以外のOC4Jインスタンスを管理する場合、Remote Method Invocation（RMI）プロトコルによってリモートOC4JインスタンスとのJMX接続が確立されます。Application Server Controlは、リモートOC4JへのJMX接続を確立する際に、リモートOC4Jのoc4jadminユーザー資格証明を送信することで、自身を認証します。デフォルトでは、この通信はクリア・テキスト形式で行われます。
管理OC4JインスタンスとリモートOC4Jインスタンス間の通信を保護するには、セキュアなRemote Method Invocation（ORMIS）プロトコルを使用します。
次の手順では、管理OC4Jインスタンス、およびApplication Server Controlで管理する各OC4Jインスタンスに対して、RMISを有効にするために実行する作業を示します。
この手順が必要なのは、Oracle Universal InstallerとOracle Application Serverインストール手順を使用してインストールされた管理対象のOracle Application Server環境のみです。
管理OC4Jインスタンスと、Application Server Controlコンソールで管理する各リモートOC4Jインスタンスに、セキュアなRMIポートを構成します。
keytool実行可能ファイルを使用して、RSA秘密鍵と公開鍵のペアが含まれるキーストアを作成します。これにより、OC4Jがブラウザ・クライアントとのセキュアなHTTP通信に使用できるSSL証明書が作成されます。keytool実行可能ファイルは、ORACLE_HOME/jdk/binディレクトリにあります。次のコマンドを使用します。
keytool -genkey -keyalg "RSA" -keystore keystore -storepass passwd -validity days
keyパスワードの入力を求められたら、別のパスワードを入力せずに、[Enter]を押します。keyパスワードは、生成した鍵ペアの秘密鍵の保護に使用されます。SSLを正しく機能させるには、キーストアと同じパスワードを使用する必要があります。
rmi.xml構成ファイルを探します。このファイルは、通常、次の場所にありますが、OC4Jインスタンスのserver.xmlファイルで<rmi-config>要素の値をチェックすることにより場所を確認できます。
(UNIX) ORACLE_HOME/j2ee/instance_name/config/rmi.xml (Windows) ORACLE_HOME¥j2ee¥instance_name¥config¥rmi.xml
rmi.xmlファイルを開き、<ssl-config>要素をファイルに追加します。
<ssl-config>要素を使用して、ステップ1で作成したキーストアのパスとキーストアのパスワードを指定します。たとえば、次のように指定します。
<ssl-config keystore="path_to_keystore" keystore-password="keystore_pwd" />
<rmi-server>要素のssl-port属性を使用して、SSLリスナー・ポートを指定します。たとえば、次のように指定します。
<rmi-server ... port="23791" ssl-port="23943" ... >
各リモートOC4JインスタンスのSSL証明書を管理OC4Jインスタンスに配布する必要があります。これには、各リモートOC4Jインスタンスに、管理OC4Jのキーストアで信頼されている証明局によって署名されたSSL証明書を使用させるか、または各リモートOC4JインスタンスのSSL証明書を管理OC4Jのキーストアにインポートします。
各リモートOC4JインスタンスのSSL証明書を管理OC4Jのキーストアにインポートするには、各リモートOC4Jインスタンスで次の手順を実行します。
keytoolコマンドを使用して、RSA公開鍵が含まれるOC4JのSSL証明書をエクスポートします。これにより、管理OC4Jからアクセス可能なファイルに証明書が配置されます。
keytool -export -file cert_file_name -keystore keystore_file_name
keytool -import -file cert_file_name -keystore keystore_file_name
環境内のOC4Jインスタンスをホストする各Oracle Application Serverインスタンスで、次の手順を実行します。
(UNIX) ORACLE_HOME/opmn/conf/opmn.xml (Windows) ORACLE_HOME¥opmn¥conf¥opmn.xml
opmn.xmlファイルを開き、このファイルに定義されているOC4Jインスタンスごとに、RMISプロトコル用の新しい<port>要素を追加します。
<port id="rmis" range="12701-12800"/>
(UNIX) ORACLE_HOME/opmn/conf/opmn.xml (Windows) ORACLE_HOME¥opmn¥conf¥opmn.xml
<ias-component>要素（ias-component IDはOC4J、process-type IDは管理OC4J名と同じ）を探します。opmn.xmlファイルの、管理OC4Jに対するjava-optionsの開始パラメータに、次のプロパティを追加します。
oracle.oc4j.jmx.internal.connection.protocol
Application Server Controlは、このプロパティを使用して、リモートOC4Jインスタンスとの通信にセキュアなRMIプロトコルを使用するタイミングを決定します。
表A-1に、環境に適用するセキュリティ・レベルに応じてこのプロパティに指定できる値を示します。
次の例は、RMISプロパティがRMISに設定された管理OC4Jの、<ias-component>要素の一般的な構成を示しています。
<ias-component id="OC4J"> <process-type id="home" module-id="OC4J" status="enabled"> <module-data> <category id="start-parameters"> <data id="java-options" value="-server -Doracle.oc4j.jmx.internal.connection.protocol=RMIS -Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false"/> </category> </module-data> </process-type> </ias-component>
この例では、管理OC4Jの名前がhomeになっています。
すべてのOC4Jインスタンスとアプリケーションの管理において、セキュアな接続を維持する場合は、管理対象の各OC4Jインスタンスのrmi.xmlファイルに、<ssl-config>要素を追加する必要があります。そうしないと、管理OC4Jインスタンスのopmn.xmlファイルに設定されている接続プロトコル・プロパティの値によっては、Application Server ControlからOC4Jインスタンスへの管理接続ができないか、セキュアでないRMIプロトコルが使用されます。
詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』のOC4JでのORMISの有効化に関する項を参照してください。
環境にクラスタ・トポロジが使用されている場合は、信頼できるOracle Application Serverインスタンスのみがクラスタのメンバーとなるように、クラスタを保護する必要があります。そうしないと、悪意のあるOracle Application Serverインスタンスがクラスタのメンバーとなり、「クラスタ・トポロジ」ページのクラスタ・コンポーネントのプロセスが制御される可能性があります。
次の各項で詳細を説明します。
インストール時に、OPMNは、デフォルトのSSL証明書が含まれるデフォルトのWalletを使用するように構成されます。デフォルトのWalletは、各Oracle Application ServerのOracleホームにある次のディレクトリに保存されます。
(UNIX) ORACLE_HOME/opmn/conf/ssl.wlt/default (Windows) ORACLE_HOME¥opmn¥conf¥ssl.wlt¥default
OPMNを効果的に保護するには、このデフォルトのWalletを有効な一意の証明書が含まれる新しいWalletに置き換える必要があります。この作業は、クラスタの各Oracle Application Serverインスタンスで実行する必要があります。
また、OPMNのWalletと証明書を構成する場合は、相互認証（サーバーとクライアント認証モードともいう）を使用する必要があります。
相互認証モードでは、OPMNクライアントとOPMNサーバーは両方とも、接続を行う前にX.509証明書を使用して相互に認証します。まず、クライアントが証明書を検証してサーバーを認証します。それに応答し、サーバーも、信頼性を立証するための証明書を送信するようクライアントに要求します。
クラスタ内の各OPMNでデフォルトのWalletを置き換えず、クラスタのすべてのインスタンスで相互認証を使用する場合、デフォルトのWalletおよび証明書を使用しているOracle Application Serverインスタンスはいずれもクラスタのメンバーになることができます。クラスタのメンバーとなったら、そのインスタンスのApplication Server Controlで、「クラスタ・トポロジ」ページからクラスタのコンポーネントを起動および停止することが可能になります。
クラスタ内のOracle Application Serverインスタンス間のOPMN接続を最も簡単に保護するには、新しいWalletを作成し、それをクラスタ内の各Oracle Application Serverインスタンスに配布します。
次の例では、自己署名（ルート）証明書を使用してOracle Application Serverクラスタを保護します。より複雑な環境や本番環境では、認証局から取得した証明書を使用できます。
次の例で、自己署名証明書を使用した相互認証の設定方法を学習します。
orapkiユーティリティを使用して、クラスタ・トポロジの最初のOracle Application Serverインスタンスに新しいWalletと新しい自己署名（ルート）証明書を作成します。opmn.xml）で、<ssl>要素が新しく作成したWalletを指すように変更します。たとえば、次のように指定します。
<ssl enabled="true" wallet-file="$ORACLE_HOME/opmn/conf/ssl.wlt/new_wallet" wallet-password="welcome2"/>
opmn.xmlファイルを更新します。
UNIXの場合:
ORACLE_HOME/opmn/bin/opmnctl stopall ORACLE_HOME/opmn/bin/opmnctl startall
Windowsの場合:
ORACLE_HOME¥opmn¥bin¥opmnctl stopall ORACLE_HOME¥opmn¥bin¥opmnctl startall
このページの「メンバー」セクションに、クラスタ内の各Oracle Application Serverインスタンスが表示されている必要があります。
OPMNおよびセキュリティの詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。
Application Server Controlには独自のログ・ファイルのセットが用意されており、これらは構成ファイルを変更することで構成できます。ロギングの構成方法は、Oracle Diagnostic Logging（ODL）を有効にするかどうかによって異なります。
次の各項で詳細を説明します。
デフォルトでは、Application Server Controlで生成されるログ・ファイルは、テキスト形式で保存されます。ただし、Oracle Diagnostic Logging（ODL）形式でログ・ファイルを保存するように、Application Server Controlを構成できます。
Application Server Controlのログ・ファイルに対してODLを有効にすると、ロギング情報および診断情報がXML形式で保存され、それぞれのログ・メッセージがODL規格に準拠するようにフォーマットされます。
デフォルトでは、アプリケーション・サーバーのホーム・ディレクトリにある次のログ・ファイルに、Application Server Controlによって情報およびエラー・メッセージが記録されます。
(UNIX) ORACLE_HOME/j2ee/home/log/ascontrol.log (Windows) ORACLE_HOME¥j2ee¥home¥log¥ascontrol.log
第A.4.1.1項の手順を実行した後、Application Server Controlでは、前述のファイルではなく次のファイルにログ情報およびエラー・メッセージが記録されます。このファイルのデータは、ODL規格に従ってフォーマットされます。
(UNIX) ORACLE_HOME/sysman/log/log.xml (Windows) ORACLE_HOME¥sysman¥log¥log.xml
詳細は、次の項を参照してください。
ODLをサポートするようにApplication Server Controlを構成する手順は次のとおりです。
(UNIX) ORACLE_HOME/j2ee/home/applications/ascontrol/ascontrol/WEB-INF/config (Windows) ORACLE_HOME¥j2ee¥home¥applications¥ascontrol¥ascontrol¥WEB-INF¥config
configディレクトリにある次の構成ファイルを編集します。
ascontrollogging.properties
例A-1に、emiasconsolelogging.propertiesファイル内にある、Application Server Controlのログ・ファイルに対してODLを有効にするプロパティを示します。
ascontrollogging.propertiesファイルを保存して閉じます。
# To support the ODL log appender, replace the lines above # with the following and restart EM. The resulting ODL log files # will be read by the Log Loader and written to the Log Repository. # # log4j.appender.emiaslogAppender=oracle.core.ojdl.log4j.OracleAppender # log4j.appender.emiaslogAppender.ComponentId=EM # log4j.appender.emiaslogAppender.LogDirectory=/private/shiphomes/m21_infra/sysman/log # log4j.appender.emiaslogAppender.MaxSize=20000000 # log4j.appender.emiaslogAppender.MaxSegmentSize=5000000
表A-2は、emiasconsolelogging.propertiesファイルで使用できるOracle Diagnostic Logging（ODL）ロギング・プロパティとその説明です。
ODLを有効にすることによって作成されるlog.xmlファイルのサイズは、情報が書き込まれるに従って大きくなっていきます。このファイルは、表A-2で説明したMaxSegmentSizeプロパティに指定された最大サイズに達するように設計されています。ファイルが事前定義済の最大サイズに達すると、Application Server Controlでは、ロギング情報およびトレース情報が新しいファイル名に変更（またはロール）され、新しいログ・ファイルまたはトレース・ファイルへの記録が開始されます。このプロセスにより、ログ・ファイルのサイズが過大になることはなくなります。
重要なログ情報にアクセスできるようにするため、Application Server Controlでは、ログ・ファイルおよびそのロールオーバー・ファイルが、例A-1で示したMaxSizeプロパティに指定された最大ディスク領域に達するまで、log.xmlファイルをロールオーバーします。ログ・ファイルおよびそのロールオーバー・ファイルがこの上限値に達すると、Application Server Controlでは、一番古いロールオーバー・ファイルが削除されます。
その結果、ログ・ディレクトリに複数のログ・ファイルが存在することもよくあります。次の例は、現在ログ・ディレクトリ内にあるApplication Server Controlの3つのロールオーバー・ファイルおよびログ・ファイルを示しています。
log.xml log1.xml log2.xml log3.xml
ODLが無効である場合も、ascontrollogging.propertiesファイルを変更することで、Application Server Controlのロギング・プロパティを構成できます。
(UNIX) ORACLE_HOME/j2ee/home/applications/ascontrol/ascontrol/WEB-INF/config/ (Windows) ORACLE_HOME¥j2ee¥home¥applications¥ascontrol¥ascontrol¥WEB-INF¥config¥
configディレクトリにある次の構成ファイルを編集します。
ascontrollogging.properties
ascontrollogging.propertiesファイルを保存して閉じます。
アプリケーション・エラーやパフォーマンスの問題の診断を支援するために、Enterprise ManagerにはApplication Server ControlコンソールからOC4Jログ・ファイルを検索するメカニズムが用意されています。
現在のOracle Application Serverインスタンスに関連するすべてのOC4Jインスタンスのログ・ファイルだけでなく、インスタンスにデプロイされたアプリケーションに関連するログ・ファイルも検索できます。
|
関連項目
|
Application Server Controlコンソールの「ログの検索」ページで一連の検索基準を入力すると、Enterprise Managerによって、その基準に一致するログ・ファイル・エントリのリストが返されます。デフォルトでは、詳細情報にブラウズまたはフィルタ可能なログ・ファイル・エントリが最大で5,000個返されます。
ログ・ファイル検索時に5,000個を超えるエントリを取得したり、返されるエントリが5,000個未満になるように検索を制限するには、次の手順を実行します。
emiaslogviewer.xml構成ファイルを開きます。これは、管理OC4JのOracleホーム内の次のディレクトリにあります。
(UNIX) ORACLE_HOME/j2ee/home/applications/ascontrol/ascontrol/WEB-INF/config (Windows) ORACLE_HOME¥j2ee¥home¥applications¥ascontrol¥ascontrol¥WEB-INF¥config
emiaslogviewer.xmlファイル内の次の要素を変更します。
<LogViewerConfig maxEntries="5000">
次の項では、Enterprise Managerをアクセシビリティ・モードで実行することの利点、およびアクセシビリティ・モードを有効にするための手順について説明します。
Enterprise Managerでは、一部のユーザー操作のレスポンスを向上させるユーザー・インタフェース開発テクノロジを利用しています。たとえば、表中の新しいレコード・セットへ移動するとき、Enterprise ManagerではHTMLページ全体の再表示が行われません。
ただし、このパフォーマンス強化テクノロジは、一般にスクリーン・リーダーではサポートされません。アクセシビリティ・モードを有効にしている場合は、この機能を無効にします。それにより、Enterprise ManagerのHTMLページは、身体に障害のあるユーザーにもアクセスしやすくなります。
Enterprise Managerでは、パフォーマンス・データの表示にグラフが使用されます。グラフによるデータ表示は、ほとんどのユーザーにとっては利用価値があり、トレンドを明確にして、パフォーマンス・メトリックの最大値および最小値が特定しやすくなります。
しかし、グラフに表示される情報をスクリーン・リーダーで読み取って伝達することはできません。この問題を解消するため、各パフォーマンス・グラフをすべてテキストで表示するようにEnterprise Managerを構成できます。アクセシビリティ・モードを有効にすると、Enterprise Managerでは、各グラフの小さなアイコンが表示され、テキスト表示へのドリルダウン・リンクとして使用できるようになります。
アクセシビリティ・モードを有効にした場合に各グラフの下に表示されるアイコンの例を図A-2に示します。
uix-config.xml構成ファイルを変更するには、次の手順を実行します。
uix-config.xml構成ファイルを検索します。
(UNIX) ORACLE_HOME/j2ee/home/applications/ascontrol/WEB-INF (Windows) ORACLE_HOME¥j2ee¥home¥applications¥ascontrol¥WEB-INF
uix-config.xmlファイルを開き、次のエントリを検索します。
<!-- An alternate configuration that disables accessibility features --> <default-configuration> <accessibility-mode>inaccessible</accessibility-mode> </default-configuration>
accessibility-modeプロパティの値を、inaccessibleからaccessibleに変更します。
次の各項では、アクティブなApplication Server Controlの管理および構成について詳細に学習します。
デフォルトでは、Oracle Application Server 10gリリース3（10.1.3.1.0）クラスタの各OC4Jインスタンスには、ascontrolアプリケーションが含まれます。これはApplication Server Controlのインスタンスを表します。
ただし、クラスタ内ではascontrolアプリケーションを1つのみ稼動させる必要があります。このアプリケーションの他のインスタンスは、停止または無効にする必要があります。新しいOC4Jインスタンスを作成すると、そのインスタンスにはOC4Jインスタンスにデプロイされるascontrolアプリケーションが含まれます。ただしデフォルトでは、OC4Jインスタンスの特性を定義するserver.xml構成ファイル内の設定により、OC4Jインスタンスの起動時にascontrolアプリケーションは自動的に起動されません。
Application Server Controlコンソールにログインすると、常に1つのascontrolアプリケーションのみがクラスタの管理に使用されます。そのascontrolアプリケーションを、アクティブなApplication Server Controlと呼びます。
アクティブなApplication Server Controlを特定するには、「クラスタ・トポロジ」ページにナビゲートして、「すべてを開く」をクリックし、クラスタのすべてのコンポーネントを表示してから、アクティブなApplication Server Controlアイコンで示されるascontrolアプリケーションを探します。
アクティブなApplication Server ControlをホストするOC4Jインスタンスは、管理OC4Jと呼ばれます。
表A-4に、アクティブなApplication Server Controlを管理する際に考慮する必要がある一連のベスト・プラクティスのガイドラインを示します。
| 推奨事項 | 説明 | 詳細情報の参照先 |
|---|---|---|
|
OC4Jインスタンスを1つ選択し、管理OC4Jとして使用します。 |
このインスタンスをデプロイ済アプリケーションのホストに使用しないでください。このインスタンスはApplication Server Controlのホスト専用とし、アプリケーションのデプロイには別途OC4Jインスタンスを作成します。
Java SSOを使用している場合は、管理OC4Jを使用してアクティブな |
|
|
管理OC4Jインスタンスにデプロイされていない |
アクティブなApplication Server Controlのみ稼動させておく必要があります。 |
|
|
Application Server Controlを分離して、独自のWebサイトやURLを使用します。 |
Oracle Application Server管理者のみがApplication Server Controlコンソールにアクセスする必要があるので、コンソールのアクセスに個別のURLとポート番号を使用することは適切です。 |
第A.6.5項「HTTPを介した管理OC4Jへの直接アクセス」 第A.6.6項「同じOC4Jインスタンス内の別のWebサイトへのApplication Server Controlの公開」 |
クラスタ・トポロジ内で複数のascontrolアプリケーションが稼動している場合、「クラスタ・トポロジ」ページの上部に次の警告メッセージが表示されます。
You have more than one instance of the Application Server Control application running in this cluster. This is not a recommended configuration and could lead to unexpected problems. Please stop the additional instances of Application Server Control or disable routing to these instances.
この問題は、たとえば複数のOracle Application Serverインスタンスを別々にインストールし、それらを後から1つのクラスタ・トポロジにまとめた場合などに発生します。クラスタのメンバーになる前の各Oracle Application Serverインスタンスには、インスタンスの管理に使用する個別のApplication Server Controlがあります。複数のインスタンスを1つのクラスタにまとめた後、クラスタ全体を管理するために必要となるApplication Server Controlは1つだけです。
この問題を解決するには、次の手順を実行します。
ascontrolアプリケーションを選択します。
この操作により、選択された非アクティブなascontrolアプリケーションが停止されます。さらにクラスタ内の非アクティブなascontrolを停止すると、Application Server Controlでは自動的に次の処理が実行されます。
server.xmlファイルを変更します。具体的には、そのアプリケーションのstartパラメータをfalseに設定します。
ohs-routingパラメータをfalseに設定します。
その結果、後で非アクティブなascontrolアプリケーションを起動する必要が発生した場合（たとえば、そのOracle Application Serverインスタンスをクラスタから分離して個別に管理する場合など）、その構成設定を元の値に再設定する必要があります。
詳細は、第A.6.4項「新しいアクティブなApplication Server Controlの特定と構成」を参照してください。
状況に応じて、ascontrolアプリケーションの異なるインスタンスをアクティブなApplication Server Controlとして特定する必要がある場合があります。たとえば、専用の管理OC4Jインスタンスを使用していない場合、個別のホストの個別のOC4Jインスタンスでascontrolアプリケーションが稼動するように環境を再構成できます。
同様に、新しいOracle Application Serverインスタンスをインストールして、インストール時にそれを管理OC4Jとして特定しなかった場合、ascontrolアプリケーションを稼動せずに終了することも可能です。その場合は、いずれかのascontrolアプリケーションを起動して、それをアクティブなApplication Server Controlとして特定する必要があります。
いずれのケースも、次の手順を実行します。
ascontrolアプリケーションがデプロイされているコンピュータにログインします。
server.xmlファイルを開きます。UNIXの場合:
ORACLE_HOME/j2ee/oc4j_instance_name/config/server.xml
Windowsの場合:
ORACLE_HOME¥j2ee¥oc4j_instance_name¥config¥server.xml
この例では、oc4j_instance_nameはascontrolアプリケーションがデプロイされているOC4Jインスタンスの名前を示します。
ascontrolアプリケーションのstart引数がtrueに設定されていることを確認します。これにより、OC4Jインスタンスの再起動時に必ずこのアプリケーションが自動的に起動されるようになります。
<application name="ascontrol" path="../../oc4j_instance_name/applications/ascontrol.ear" parent="system" start="true" />
ascontrolアプリケーションのその他すべてのインスタンスは、start引数がfalseに設定されていることを確認します。これにより、選択されたアプリケーションのインスタンスは、OC4Jインスタンスの再起動時に自動的に起動されなくなります。
server.xmlファイルを閉じます。
default-web-site.xmlファイルを開きます。これは、server.xmlファイルと同じディレクトリに格納されています。
ascontrolアプリケーションのweb-app要素のohs-routing属性をtrueに変更します。
<web-app application="ascontrol" name="ascontrol" load-on-startup="true" root="/em" ohs-routing="true" />
ascontrolアプリケーションのその他すべてのインスタンスは、ohs-routing属性がfalseに設定されていることを確認します。これにより、Oracle HTTP ServerでHTTPリクエストがascontrolアプリケーションの非アクティブなインスタンスにルーティングされなくなります。
default-web-site.xmlファイルを閉じます。
server.xmlおよびdefault-web-site.xmlファイルを構成した後、次の手順を実行します。
ascontrolアプリケーションのデプロイに使用されるインスタンス以外の、すべてのOC4Jインスタンスを停止して再起動します。 現在アクティブなascontrolアプリケーションは、緑色のひし形アイコンで示されます。
ascontrolアプリケーションをホストする管理OC4Jインスタンスを再起動します。現在アクティブなascontrolアプリケーションを再起動すると、Application Server Controlコンソールをログアウトすることになります。
ascontrolアプリケーションのURLを使用して、Application Server Controlコンソールにログインします。たとえば、次のように指定します。
http://new_admin_oc4j_hostname:port/em
専用の管理OC4Jインスタンスを使用するメリットの1つに、管理OC4Jで独自のHTTPリスナーを使用するように容易に構成できる点が挙げられます。
たとえば、現在Oracle HTTP Serverを使用して管理OC4Jにアクセスしている場合は、このインスタンスで組込みOC4J HTTPリスナーを使用するように再構成できます。これにより、Oracle HTTP Serverを経由せずに、HTTPプロトコルを使用して管理OC4Jに直接アクセスできるようになります。
ここで、Oracle Application Server管理者は個別のURLとポート番号を使用してApplication Server Controlコンソールにアクセスできます。一方、他のOC4Jインスタンスにデプロイしたアプリケーションには、アプリケーション・ユーザーはそのままOracle HTTP Serverを使用してアクセスできます。
Application Server Controlコンソールへのアクセス保護を強化するために、管理OC4Jを別のホストに配置して、そこからクラスタ・トポロジのコンポーネントを管理することもできます。図A-3はその構成例を示しています。
OC4JインスタンスでフロントエンドのOracle HTTP Serverのかわりに独自のHTTP URLを使用するように構成するには、OC4JインスタンスのプロトコルをAJPからHTTPに変更して、HTTPポートを指定します。手順は次のとおりです。
管理OC4JインスタンスがOracle HTTP Serverと同じホスト上に存在する場合は、Oracle HTTP Serverで使用されるポートとは異なるポートまたはポート範囲を使用してください。
管理OC4Jを再起動すると、次のURLを使用してApplication Server Controlコンソールにアクセスできるようになります。
http://admin_oc4j_hostname:port/em/
専用の管理OC4Jを使用しない場合は、管理者がOracle HTTP Serverを経由せずに個別のHTTPポートを使用して直接Application Server Controlコンソールにアクセスするように、OC4Jインスタンスを構成することもできます。
このケースでは、OC4Jインスタンスに別のWebサイトを構成して、そのWebサイトに既存のApplication Server Controlのバインディングを移行します。その後、そのWebサイトを認識するようにOPMNを構成します。既存のWebサイト（通常、default-web-site）は、デプロイ済アプリケーションのホストにそのまま使用できます。一方、Oracle Application Server管理者は新しいWebサイトとポートを使用してApplication Server Controlコンソールにアクセスします。
次の手順を実行して、Application Server Controlを独自のOC4J Webサイトに移行します。
ORACLE_HOME/j2ee/home/config/default-web-site.xmlファイルを、ORACLE_HOME/j2ee/home/config/ascontrol-web-site.xml（または任意のファイル名）にコピーします。
ascontrol-web-site.xmlファイルを編集して、既存のWebアプリケーションのバインディングをすべて削除します。Application Server Controlコンソール・アプリケーションの<default-web-app>エントリおよび<web-app>エントリ（次の例の太字部分）のみ残します。これにより、ascontrolアプリケーションがWebサイトのルート・コンテキスト/emにマップされます。<web-site>要素にprotocol="http"およびport="1810"が指定されており、display-nameが一意の名前になっていることを確認してください。
<?xml version = '1.0' standalone = 'yes'?> <web-site protocol="http" port="1810" display-name="OC4J 10g (10.1.3) ASControl Web Site" <default-web-app application="default" name="defaultWebApp" root="/j2ee" /> <web-app application="ascontrol" name="ascontrol" root="/em" /> <!-- Access Log, where requests are logged to --> <access-log path="../log/default-web-access.log"/> <!-- Uncomment this if you want to use ODL logging capabilities <odl-access-log path="../log/default-web-access" max-file-size="1000" max-directory-size="10000"/> --> <web-app application="bc4j" name="webapp" root="/webapp" load-on-startup="false"/> </web-site>
access-log pathを、ascontrolのWebサイト用として一意のログ・ファイルを指定するように変更します。
ORACLE_HOME/j2ee/home/config/server.xmlを編集して、次の例の太字部分のように、ascontrol-web-site.xmlファイルを指定する新しい<web-site>要素を追加します。
<application-server ...> ... <web-site default="true" path="./default-web-site.xml" /> <web-site default="false" path="./ascontrol-web-site.xml" />... </application-server>
ORACLE_HOME/j2ee/home/config/default-web-site.xmlを編集して、ascontrolアプリケーションのweb-appバインディングを削除するか、コメントアウトします。
<web-site protocol="http" port="1810" display-name="OC4J 10g (10.1.3) ASControl Web Site" ... <!-- <web-app application="ascontrol" name="ascontrol" root="/em" / --> </web-site>
ascontrol Webサイトのポート設定を認識できるよう、OPMN構成を新しいascontrol Webサイトで更新します。ORACLE_HOME/opmn/binから、次のコマンドを発行します。
opmnctl config port update ias-component=OC4J process-type=home portid=ascontrol-web-site protocol="http" range=1810-1820
ORACLE_HOME/opmn/binから次のコマンドを発行して、サーバーを再起動します。
opmnctl stopall opmnctl startall
これで、Application Server ControlはAppHost1:1810/emでアクセスできるようになり、Oracle HTTP Serverから分離されました。ただし、デフォルトのアプリケーションと、デフォルトのアプリケーションの子としてデプロイされている他のアプリケーションは、そのままOracle HTTP Serverを使用します。
|
 Copyright © 2002, 2006, Oracle. All Rights Reserved. |
|