Oracle® Fusion Middleware

Oracle WebLogic Serverドメイン構成の理解

12c (12.2.1.1.0)

E77279-02(原本部品番号:E72096-02)

2016年8月

このドキュメントでは、Oracle WebLogic Serverドメインとその構成方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解, 12c (12.2.1.1.0)

E77279-02

Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントの内容と対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- このリリースでの新機能と変更された機能

2 Oracle WebLogic Serverドメインの理解

- ドメインとは

- ドメインの構成

- ドメインの内容

- 管理サーバー

- 管理サーバーに障害が発生した場合

- 管理対象サーバーと管理対象サーバー・クラスタ

- リソースとサービス

- ドメインの制限事項

- サーバー名の制限

- 開発モードと本番モード

3 ドメイン構成ファイル

- ドメイン構成ファイルの概要

- 構成ドキュメントの編集

- 構成ファイル内のセキュリティ資格

- 構成ファイルのアーカイブ

- ドメイン・ディレクトリの内容

- domain-name

- autodeploy

- bin

- config

- config/configCache

- config/diagnostics

- config/jdbc

- config/jms

- config/lib

- config/nodemanager

- config/security

- configArchive

- console-ext

- init-info

- lib

- pending

- security

- servers

- servers/server-name

- servers/server-name/cache

- servers/server-name/cache/EJBCompilerCache

- servers/server-name/data

- servers/server-name/data/ldap

- servers/server-name/data/store

- servers/server-name/logs

- servers/server-name/logs/diagnostic_images

- servers/server-name/logs/jmsServers

- servers/server-name/security

- servers/server-name/tmp

- tmp

- サーバーのルート・ディレクトリ

- サーバー・ルート・ディレクトリの指定

- 管理サーバーのサーバー・ルート・ディレクトリ

- ノード・マネージャで起動した管理対象サーバーのサーバー・ルート・ディレクトリ

- ノード・マネージャで起動されていない管理対象サーバーのサーバー・ルート・ディレクトリ

4 構成の変更の管理

- 変更管理の概要

- サーバーの再起動が必要な変更

- 構成変更ツール

- 構成監査

- 管理コンソールでの変更管理

- 別の管理者からの構成ロックの取得

- 構成の変更管理のプロセス

- Configuration Locks

- 変更の衝突の解決

- 構成管理の状態図

- 構成の変更の制限

- 指定された並行編集セッションの使用

5 サーバー・テンプレート

- サーバー・テンプレート

- サーバー・テンプレートとは

- サーバー・テンプレートを使用する理由

- サーバー・テンプレートの使用方法

- 属性のオーバーライド

- マクロの使用方法

- サーバー・テンプレート・サンプル

はじめに

ここでは、このガイド『Oracle WebLogic Serverドメイン構成の理解』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

このドキュメントでは、Oracle WebLogic Server ドメインとその構成方法について説明します。ドメインとは、Oracle WebLogic Serverの基本的な管理単位です。1つまたは複数のOracle WebLogic Serverインスタンス(および、それに関連付けられたリソース)で構成され、1つの管理サーバーで管理されます。

次の節では、このガイド『Oracle WebLogic Serverドメイン構成の理解』の内容と構成について説明します。

- ドキュメントの内容と対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- このリリースでの新機能と変更された機能

ドキュメントの内容と対象読者

このドキュメントは主に、1つまたは複数のOracle WebLogic ServerドメインでWebベース・アプリケーションを開発またはデプロイするJava Platform, Enterprise Edition (Java EE)のシステム設計者、アプリケーション開発者、およびシステム管理者を対象としています。

このドキュメントのトピックでは、ソフトウェア・プロジェクトの設計および開発段階に関連する情報を提供します。このドキュメントでは、プロダクション段階での管理、モニター、パフォーマンス・チューニングについては扱いません。これらのトピックに関するOracle WebLogic Serverのマニュアルとリソースへのリンクについては、「関連ドキュメント」を参照してください。

このドキュメントでは、Java EE、XMLの基本概念、一般的なネットワークやアプリケーション管理の概念について理解していることを前提としています。

このドキュメントの手引き

- この章「概要とロードマップ」では、このガイドの目的、構成および内容について紹介します。

- 「Oracle WebLogic Serverドメインの理解」では、Oracle WebLogic Serverドメインについて紹介します。

- 「ドメイン構成ファイル」では、構成や、ドメインのディスク上の表現を保持するディレクトリとその内容について説明します。

- 「構成の変更の管理」では、Oracle WebLogic Serverの変更管理機能について説明します。

- 「サーバー・テンプレート」では、サーバー・テンプレートについて説明します。

関連ドキュメント

システム管理のタスクや、使用できる各種ツールの詳細は、次を参照してください。

- 『Oracle WebLogic Serverの理解』のシステム管理に関する項

- Oracle WebLogic Server Java EE管理アプリケーションの開発

- Oracle WebLogic Server MBeanリファレンス

- SNMPによるOracle WebLogic Serverのモニタリング

Oracle WebLogic Serverドメインの作成と構成に使用できるツールの詳細は、次を参照してください:

- 構成ウィザードによるWebLogicドメインの作成

- WebLogic Scripting Toolの理解

- Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発

- Oracle WebLogic Serverコマンド・リファレンス

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

サンプルとチュートリアル

このドキュメントに加えて、ドメインの構成と管理に関連するサンプル・コードが用意されています。

- WebLogic Scripting Tool (WLST)サンプルは、WLSTを使用してドメインの作成を自動化する方法を示すサンプルです。『WebLogic Scripting Toolの理解』のWLSTサンプル・スクリプトに関する項を参照してください。

- Avitek Medical Recordsサンプル・アプリケーションは、Java EEプラットフォーム全般について簡潔に例示するOracle WebLogic Serverのサンプル・アプリケーション・スイートです。このサンプル・アプリケーションを起動するには、次の場所に格納されているstartWeblogicスクリプトを呼び出します。

ORACLE_HOME/user_projects/domains/medrec

ORACLE_HOMEは、Oracle WebLogic Serverをインストールした際にOracleホームとして指定したディレクトリです。

このリリースでの新機能と変更された機能

このリリースのWebLogic Serverでは、複数の指定された並行編集セッションを使用可能です。これにより、複数の管理者が同時に構成を変更できるようになります。これは通常、複数の管理者がシステムの異なる部分で作業する場合に役に立ちます。詳細は、名前付き同時編集セッションの管理を参照してください。

このリリースで導入されたOracle WebLogic Serverの総合的な新機能リストは、「Oracle WebLogic Serverの新機能」を参照してください。

2 Oracle WebLogic Serverドメインの理解

この章では、Oracle WebLogic Server ドメインとその構成について説明します。構成には管理サーバーと、通常は管理対象サーバーが1つ以上含まれています。

この章には次の項が含まれます:

- ドメインとは

- ドメインの構成

- ドメインの内容

- ドメインの制限事項

- 開発モードと本番モード

ドメインとは

Oracle WebLogic Serverの管理ドメインは、Oracle WebLogic Serverリソースの論理的に関連したグループです。ドメインには、管理サーバーと呼ばれる特殊なOracle WebLogic Serverインスタンスが含まれます。管理サーバーでは、ドメイン内のすべてのリソースを一元的に構成および管理します。通常は、管理対象サーバーと呼ばれるOracle WebLogic Serverインスタンスも含めてドメインを構成します。Webアプリケーション、EJB、Webサービスなどのリソースは管理対象サーバーにデプロイし、管理サーバーは構成や管理の目的にのみ使用します。

ドメインの構成

単一のOracle WebLogic Serverインストールを使用して複数のドメインを作成および実行したり、複数のインストールを使用して単一のドメインを実行したりできます。図2-1を参照してください。

図2-1 Oracle WebLogic Serverインストールとドメイン

インストールされたOracle WebLogic Serverをどのようなドメインに構成するかは、ビジネス上のニーズによって異なります。システム管理者の責任範囲、アプリケーションの境界、サーバーを実行するマシンの設置場所などに応じて、複数のドメインを定義できます。また、ドメインを1つにして、すべてのOracle WebLogic Server管理アクティビティを一元化することも可能です。

特定のビジネス上のニーズやシステム管理者の慣習に応じて、次のような条件に基づいてドメインの構成を決定することができます。

- アプリケーションの論理的な区分。たとえば、ショッピング・カートのようなエンドユーザー機能専用のドメインと、バックエンドの会計アプリケーション専用のドメインを持つことができます。

- 物理的な場所。企業の所在地や支店ごとに別々のドメインを作成できます。物理的な場所ごとに、別々のOracle WebLogic Serverインストールが必要です。

- サイズ。ドメインをより効率的に管理したり、別々のシステム管理者が管理したりできるように、ドメインを小さな単位で構成することができます。一方、1つのドメインや少数のドメインにした方が、構成の一貫性を保ちやすくなります。

単一のサーバー・インスタンスから構成される単純なドメインを作成できます。この単一のインスタンスは管理サーバーとして動作し、開発中のアプリケーションをホストします。Oracle WebLogic Serverと一緒にインストールできるwl_serverドメインはこのタイプのサンプル・ドメインです。

ドメインの内容

図2-2に、管理サーバー、3つのスタンドアロンの管理対象サーバー、3つの管理対象サーバーを含むクラスタで構成されたプロダクション環境を示します。

図2-2 ドメインの内容

ドメインの範囲と目的は多種多様ですが、ほとんどのOracle WebLogic Serverドメインには、この節で説明するコンポーネントが含まれます。

管理サーバー

管理サーバーは、ドメイン全体の構成の一元的な制御エンティティとして動作します。ドメインの構成ドキュメントを管理し、構成ドキュメントでの変更を管理対象サーバーに配布します。また、ドメイン内のすべてのリソースを一元的に監視するための場所として使用することもできます。

管理サーバーと相互作用するには、『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIの概要に関する項にリストされている管理ツールのいずれかを使用します。ドメイン構成の変更の詳細は、『Oracle WebLogic Serverの理解』のシステム管理に関する項を参照してください。

各Oracle WebLogic Serverドメインには、管理サーバーとして機能する1つのサーバー・インスタンスが必要です。

管理サーバーの詳細およびOracle WebLogic ServerのJMX管理システムにおける管理サーバーの役割については、『Oracle WebLogic Serverの理解』のシステム管理に関する項を参照してください。

管理サーバーに障害が発生した場合

管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。ただし、ドメインの構成は変更できなくなります。ホスト・マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバーに障害が発生した場合、同じマシン上の他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。

管理対象のサーバー・インスタンスが(クラスタリングされているかいないかには関係なく)動作しているときにドメインの管理サーバーが使用できなくなっても、その管理対象サーバーは処理を続けます。そして、定期的に管理サーバーへの再接続を試行します。ドメインにクラスタリングされたサーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。

管理サーバーが動作していない場合でも管理対象サーバーを起動できます。その場合、管理対象サーバーは、起動時の構成としてドメインの構成ファイルのローカル・コピーを使用し、その後で、管理サーバーに定期的に接続しようとします。接続したら、構成の状態を管理サーバーのものと同期させます。

管理サーバーを実行せずに管理対象サーバーを起動する方法については、『Oracle WebLogic Serverサーバーの起動と停止の管理』の管理対象サーバーの独立モードに関する項を参照してください。管理サーバーを再起動する方法については、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバー障害の回避とサーバー障害からの回復に関する項を参照してください。

管理対象サーバーと管理対象サーバー・クラスタ

管理対象サーバーは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービス、およびそれらに関連付けられたリソースをホストします。また、パフォーマンスを最適化するため、ドメインの構成ドキュメントの読取り専用のコピーを保持します。管理対象サーバーを起動すると、その構成ドキュメントを管理サーバーに保持されているドキュメントと同期させるため、そのドメインの管理サーバーに接続します。

アプリケーションのパフォーマンス、スループット、または高可用性を向上させる必要のあるプロダクション環境では、複数の管理対象サーバーがクラスタとして動作するように構成できます。クラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のOracle WebLogic Serverインスタンスで構成されます。クラスタ内では、ほとんどのリソースとサービスが(単一の管理対象サーバーではなく)各管理対象サーバーに同じようにデプロイされています。1つのドメインには、クラスタとして構成されていない複数の管理対象サーバーだけでなく、複数のOracle WebLogic Serverクラスタを含めることができます。クラスタリングされた管理対象サーバーとクラスタリングされていない管理対象サーバーの主な違いは、フェイルオーバーとロード・バランシングのサポートです。これらの機能は、管理対象サーバーのクラスタでしか利用できません。Oracle WebLogic Serverクラスタのメリットと機能の詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverのクラスタリングの理解に関する項を参照してください。

リソースとサービス

ドメインには、管理サーバーと管理対象サーバーだけでなく、管理対象サーバーやデプロイされたアプリケーションで必要となるリソースとサービスも含まれます。

管理対象サーバーでは、以下のリソースを使用できます。

- マシン定義 - 特定の物理的なハードウェアを識別します。マシン定義によって、コンピュータとそのコンピュータがホストする管理対象サーバーが関連付けられます。ノード・マネージャは、障害の発生した管理対象サーバーを再起動する際に、この情報を使用します。また、クラスタリングされた管理対象サーバーは、レプリケートされたセッション・データを格納する最適な場所を選択する際に、この情報を使用します。ノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。

- ネットワーク・チャネル - 管理対象サーバーがクライアントとの通信に使用するデフォルトのポート、プロトコル、およびプロトコル設定を定義します。ネットワーク・チャネルを作成したら、ドメイン内の任意の数の管理対象サーバーとクラスタに割り当てることができます。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

- 仮想ホスト - Oracle WebLogic Serverインスタンス(サーバー)またはクラスタが応答するホスト名のセットを定義します。仮想ホスト機能を使用する場合、DNSを使用して、サーバーまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を指定します。また、各仮想ホストでどのWebアプリケーションを処理するかについても指定します。

アプリケーションでは、以下のリソースおよびサービスを使用できます。

- セキュリティ・プロバイダ - 認証や認可など、セキュリティの特定の側面を処理するモジュール・コンポーネントです。

- リソース・アダプタ - エンタープライズ情報システム(EIS)に固有のシステム・ライブラリで、EISへの接続性を提供します。

- 診断およびモニター・サービス。

- JDBCデータ・ソース - アプリケーションからデータベースへの接続を可能にします。

- メール・セッション。

- XMLパーサーおよびトランスフォーマ・ファクトリのXMLエンティティ・キャッシュおよびレジストリ。

- メッセージング・サービス(JMSサーバー、ストア・アンド・フォワード・サービスなど)。

- 永続ストア - データ(永続JMSメッセージなど)を格納する物理リポジトリです。具体的には、JDBC対応のデータベースまたはディスク・ベースのファイルのどちらかです。

- 起動クラス - システム全体のカスタム・サービスをアプリケーションに提供するために作成するJavaプログラムです。

- ワーク・マネージャ - ユーザーが定義したルールに基づいて、アプリケーションが実行する作業の優先順位を決定し、実行時の実際のパフォーマンスを監視します。Oracle WebLogic Serverドメイン全体のワーク・マネージャを作成したり、特定のアプリケーション・コンポーネントのワーク・マネージャを作成したりできます。

- ワーク・コンテキスト - アプリケーションからリモート・コンテキストに、プロパティをリモート呼出しに含めずに渡すことを可能にします。

ドメインの制限事項

ドメイン構成を設計する際には、次の制限事項に注意してください。

- 各ドメインには、管理アクティビティを実行するための固有の管理サーバーが必要です。WebLogic Server管理コンソールを使用して管理やモニターの作業を行うときに、複数のドメインを切り替えることができますが、その場合は、別々の管理サーバーに接続します。

- クラスタ内のすべての管理対象サーバーは、同じドメインに存在しなければなりません。クラスタを複数のドメインに分割することはできません。

- ドメイン内のすべての管理対象サーバーで、同じバージョンのOracle WebLogic Serverソフトウェアを実行する必要があります。管理サーバーで実行するソフトウェアは、ドメイン内の管理対象サーバーと同じバージョンでも、それ以降のパッチ・セットでもかまいません。

- サーバー・インスタンスはドメインと同じ名前にはできません。

複数のドメインを作成した場合、各ドメインは、そのドメイン専用のデータベース・スキーマを参照する必要があります。構成したリソースまたはサブシステムをドメイン間で共有することはできません。たとえば、あるドメインでJDBCデータ・ソースを作成した場合、別のドメインの管理対象サーバーまたはクラスタでその接続プールを使用することはできません。かわりに、2番目のドメインで同様のデータ・ソースを作成する必要があります。また、2つ以上のシステム・リソースに同じ名前を付けることはできません。

サーバー名の制限

サーバー・インスタンスに名前を付ける場合、次の制限および考慮事項に注意してください。

- サーバー・インスタンスには、英数字からなる名前を使用します。有効なサーバー名には、空白や次の文字を含めることはできません。

- カンマ(,)

- 等価 (=)

- コロン(:)

- アスタリスク(*)

- パーセント(%)

- 疑問符(?)

- スラッシュ(/)

- アンダースコア (_)

- ハイフン(-)

- ピリオド ()

- サーバー・インスタンスごとに一意の名前を使用します。ドメイン内では、サーバー・インスタンス、マシン、クラスタ、JDBC接続プール、仮想ホストおよびその他のリソース・タイプを含むすべての構成オブジェクトが一意の名前である必要があり、ドメイン内で同じ名前を使用することはできません。

- サーバー名は、識別用にのみ使用します。サーバー名は、サーバー・インスタンスにデプロイされるアプリケーションのURLの一部として使用されることはありません。サーバー名は管理コンソールまたはFusion Middleware Controlに表示されます。WebLogic Serverコマンドライン・ユーティリティを使用する場合、サーバー・インスタンスを識別するためにサーバー名を使用します。

- サーバー・インスタンスの作成後、サーバー名を変更することはできません。新しい名前を使用するには、サーバー・インスタンスのクローンを作成し、そのクローンに新しい名前を付けます。

開発モードと本番モード

WebLogicドメインを構成して、開発モードまたは本番モードのいずれかで実行できます。セキュリティおよびロギングに関するデフォルトの設定は、ドメイン・モードにより決定されます。開発モードでは、セキュリティ構成が比較的緩和されます。起動IDファイルを使用して管理サーバーを起動するか、autodeployディレクトリを使用してアプリケーションをデプロイできます。本番モードでは、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要になるなど、セキュリティ構成がより厳しくなっています。

本番モードのデフォルト設定と、ドメイン・モードのデフォルト設定の間には、次のような相違もあります。

- 実行キュー内のスレッド数

- ログ設定(ログ・ローテーション中に保存されるファイルの最大数、ログ・ローテーションをトリガーするログ・ファイルの最少サイズ、起動時にログをローテーションするかどうかなど)

- サーバーのライフサイクル操作のタイムアウトのデフォルト

- SNMPセキュリティ・レベル

- サーブレット再ロードのチェック間隔

開発および本番モードのデフォルト・チューニング値の詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の開発モードと本番モードのデフォルト・チューニング値に関する項を参照してください。

ドメイン・モードは、ドメイン作成時に構成した後、いつでも変更できます。構成ウィザードを使用したドメイン・モードの選択方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードに関する項を参照してください。

WebLogic Server管理コンソールを使用した開発モードから本番モードへのドメインの変更方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。(WebLogic Serverでは、本番モードから開発モードへのドメインの変更もサポートしています)。

注意:

本番モードでは、Webサービス・テスト・クライアントを有効にしないことをお薦めします。Webサービス・テスト・クライアントの詳細は、『Webサービスの管理』のWebサービス・テスト・クライアントの使用に関する項を参照してください。

本番モードに変更したら、本番ドメインのセキュリティを高めるために、次のことを行うことをお薦めします。

1. ドメイン起動スクリプトを変更し、-Xverifyフラグの値をnoneからallに変更します。この変更によって、バイトコードの検証が有効化されます。バイトコードの検証の詳細は、『Java Security Overview』(http://docs.oracle.com/javase/7/docs/technotes/guides/security/overview/jsoverview.html)の「Java Language Security and Bytecode Verification」を参照してください。

2. ドメイン内の管理サーバーおよび各管理対象サーバーを再起動します。各サーバー・インスタンスを再起動するためのコマンドに、-Dweblogic.system.RemoveBootIdentity=true引数を含めます。これにより、起動IDファイルが削除されます。起動IDファイルは、構成を本番モードに変更した後の最初の再起動時にのみ、削除する必要があります。次の方法のいずれかを使用できます。

- 個別のコマンド・シェルを開き、各サーバー・インスタンスのweblogic.Server起動コマンドにこの引数を含めます。

- JAVA_OPTIONS変数を定義し、-Dweblogic.system.RemoveBootIdentity=trueを含めた後、サーバーの起動スクリプトを呼び出します。

注意:

ドメインを開発モードから本番モードに変更した場合、次のようになります。

- ドメイン起動スクリプト(および-Xverifyフラグの値)は変わりません。

- boot.propertiesファイルは引き続き使用されます。

3 ドメイン構成ファイル

この章では、Oracle WebLogic Server でドメインの構成の保存に使用される、XMLドキュメントのドメイン構成ファイルについて説明します。

この章には次の項が含まれます:

- ドメイン構成ファイルの概要

- ドメイン・ディレクトリの内容

- サーバーのルート・ディレクトリ

ドメイン構成ファイルの概要

各ドメインの構成は、ドメインの構成ディレクトリに格納されているXMLドキュメントに記述されます。実行時には、ドメイン内の各Oracle WebLogic Serverインスタンスが、このドキュメントに記述された構成のインメモリー表現を作成します。

注意:

ドメイン・ディレクトリでは、作成後に構成の変更がなくても、ドメインの適切な動作のために書込み権限と読取り権限が必要です。これは、WebLogic Serverが固有の内部デプロイメントを実行し、サーバーの再起動時に構成ファイルが書きなおされる可能性があるためです。

ドメインの中心的な構成ファイルはDOMAIN_NAME/config/config.xmlです。このファイルには、ドメインの名前と、ドメイン内の各サーバー・インスタンス、クラスタ、リソース、およびサービスの構成が指定されています。ファイルには、DOMAIN_NAME/configディレクトリのサブディレクトリに格納されている追加のXMLファイルへの参照も含まれています。これらの含まれるファイルは、Oracle WebLogic Serverの主要なサブシステムを記述するために使用されます。

Oracle WebLogic Serverのデフォルト値のほとんどは、パフォーマンスを最適化するため、ドメインの構成ファイルには保持されていません。そのため、状況によっては、XML要素が構成ファイルに記述されていない場合もあります。たとえば、ドメインがアクティブな間にドメインのデフォルトのロギング重大度を変更したことがない場合、config.xmlファイルにはドメインのロギングを構成するXML要素は含まれていません。

さらにパフォーマンスを最適化するため、各管理対象サーバーはドメインの構成ファイルのコピーを保持しています。このコピーは読取り専用で、変更管理プロセスの一部としてのみ更新できます(「構成の変更の管理」を参照)。

構成ドキュメントの編集

ドメインの構成ドキュメントは、ほとんどの状況ではテキスト・エディタなどの非Oracleツールでは編集しないようにしてください。かわりに、WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)や、『Oracle WebLogic Serverの理解』のシステム管理に関する項で説明されているいずれかのツールを使用してください。

ただし、Oracle WebLogic Serverの構成ドキュメントはスキーマに準拠したXMLファイルであるため、XSLTまたはXMLパーサー(Apache Xerces、JDOMなど)を使用して編集することも可能です。作成したスクリプトは徹底的にテストし、変更を行う前に必ず各構成ファイルのバックアップ・コピーを作成するようにしてください。

ドメインの構成ドキュメントを定義するスキーマは、次の場所に格納されています。

- http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd

- http://xmlns.oracle.com/weblogic/security/1.0/security.xsd

- http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd

- WL_HOME/server/lib/schema内のJARファイル。WL_HOMEはOracle WebLogic Serverのインストール・ディレクトリです。このディレクトリ内では:

- domain.xsdドキュメントは、パス名META-INF/schemas/schema-0.xsdのweblogic-domain-binding.jarで表現されます。

- security.xsdドキュメントは、パス名META-INF/schemas/schema-1.xsdのweblogic-domain-binding.jarで表現されます。

- weblogic-diagnostics.xsdドキュメントは、パス名META-INF/schemas/schema-0.xsdのdiagnostics-binding.jarで表現されます。

警告:

実行中のドメインの構成ファイルは編集しないでください。Oracle WebLogic Serverでは、構成ファイルを定期的に書き換えているため、変更した内容は消失します。プラットフォームによっては、Oracle WebLogic Serverの障害の原因となる可能性もあります。

構成ファイル内のセキュリティ資格

ドメイン・セキュリティと組込みLDAPサーバーのセキュリティ資格は、暗号化された状態でconfig.xmlファイルに格納されます。config.xmlファイルをテキスト・エディタなどの非Oracleツールで作成した場合は、セキュリティ資格を見つけて暗号化し、作成済のconfig.xmlファイルに、暗号化した資格をコピーする必要があります。

Oracle WebLogic Serverの暗号化ユーティリティの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「encrypt」を参照してください。資格を暗号化したら、config.xmlファイル内の要素(例3-1)に、暗号化された値を指定します。

例3-1 暗号化された資格の構成

<security-configuration>
<credential-encrypted>{3DES}encypted-value-here</credential-encrypted>
</security-configuration>
<embedded-ldap>
<credential-encrypted>{3DES}encypted-value-here</credential-encrypted>
</embedded-ldap>

構成ファイルのアーカイブ

構成ファイルのバックアップ・コピーを作成するようにOracle WebLogic Serverを構成できます。そうすることで、構成の変更を元に戻す必要がある場合や、万一構成ファイルが破損した場合に、回復しやすくなります。管理サーバーは起動時に、構成ファイルを含むconfig-booted.jarというJARファイルを保存します。構成ファイルを変更すると、古いファイルはドメイン・ディレクトリの下のconfigArchiveディレクトリ内で、連続番号の付いた名前のJARファイル(config-1.jarなど)に保存されます。

構成ファイルのアーカイブについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの構成ファイルのアーカイブ化に関する項を参照してください。WLSTを使用してバックアップ・コピーが作成されるように構成する場合は、例3-2に示すように、DomainMBeanのConfigBackupEnabled属性をtrueに設定し、保持する構成アーカイブ・ファイルの数をArchiveConfigurationCount属性に指定します。

例3-2 アーカイブ・ファイルの構成

connect()
edit()
startEdit()
cmo.setArchiveConfigurationCount(5)
cmo.setConfigBackupEnabled(true)
activate()

ドメイン・ディレクトリの内容

デフォルトで、Oracle WebLogic Serverは、Oracle Middleware ORACLE_HOME/user_projects/domainsディレクトリの下にドメイン・ディレクトリを作成します。この節では、ドメイン・ディレクトリとサブフォルダの内容について説明します。なお以下では、ユーザーがドメイン作成時に定義する名前を、domain-name、deployment-name、server-nameのように表記します。

ドメイン・ディレクトリには、ドメイン内の個別のアプリケーションによって作成されたファイルやディレクトリが格納される場合もあります。

ドメインをまだ作成していない場合は、既存のドメイン・ディレクトリの例を参照できます。この例は、ORACLE_HOME/user_projects/domains/wl_serverにあります。ORACLE_HOMEは、Oracle WebLogic Serverをインストールする際に指定したOracleホーム・ディレクトリです。

domain-name

このディレクトリの名前はドメインの名前です。

autodeploy

このディレクトリは、開発サーバーでアプリケーションを素早くデプロイする方法を提供します。Oracle WebLogic Serverインスタンスが開発モードで実行中の場合、このディレクトリに配置したアプリケーションまたはモジュールはWebLogic Serverインスタンスによって自動的にデプロイされます。

このディレクトリに配置するファイルは、次のようなJava EEアプリケーションです。

- EARファイル

- WAR、EJB JAR、RAR、またはCARアーカイブ・モジュール

- アプリケーションまたはモジュールの展開されたアーカイブ・ディレクトリ

bin

このディレクトリには、ドメインの管理サーバーと管理対象サーバーの起動および停止処理に使用されるスクリプトが含まれています。通常、これらのスクリプトは、UNIX用に.shファイルが、Windows用に.cmdファイルが用意されています。binディレクトリは、データベース管理システム、フルテキスト検索エンジン・プロセスなどを起動および停止するスクリプトなどのドメイン全体を対象とする他のスクリプトをオプションで含むことができます。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。

config

このディレクトリには、ドメインの現在の構成とデプロイメントの状態が含まれています。中心的なドメイン構成ファイルのconfig.xmlはこのディレクトリに格納されます。

config/configCache

ドメインの構成ドキュメントへの変更を検証する際に、パフォーマンスの最適化に使用するデータが格納されます。これらはOracle WebLogic Serverの内部データであるため、バックアップする必要はありません。

config/diagnostics

このディレクトリには、WebLogic診断フレームワークのインストゥルメンテーションのシステム・モジュールがあります。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

config/jdbc

このディレクトリには、JDBCのシステム・モジュール、つまり、(JSR-88とは異なり)JMXから直接構成できる、グローバルなJDBCモジュールが含まれます。詳細は、Oracle WebLogic Serverのデータベース接続に関する説明を参照してください。

config/jms

このディレクトリには、JMSのシステム・モジュール、つまり、(JSR-88とは異なり)JMXから直接構成できる、グローバルなJMSモジュールが含まれます。詳細は、Oracle WebLogic Serverのメッセージングに関する説明を参照してください。

config/lib

このディレクトリは、現在のリリースのOracle WebLogic Serverでは使用されていません。

config/nodemanager

このディレクトリには、ノード・マネージャとの接続に関する情報が保持されます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの構成ファイルとログ・ファイルに関する項を参照してください。

config/security

このディレクトリには、セキュリティ・フレームワークのシステム・モジュールが含まれます。ドメインの現在のレルムにある、セキュリティ・プロバイダの各種類ごとに1つの、セキュリティ・プロバイダの構成拡張が格納されます。詳細は、『Oracle WebLogic Serverセキュリティの理解』を参照してください。

configArchive

このディレクトリには、ドメインの構成の状態を保存したJARファイルのセットが格納されます。構成の保留中の変更内容がアクティブ化される直前に、config.xmlファイルと他の関連する構成ファイルから成るドメインの既存の構成の状態が、config.jar#1、config.jar#2のような名前のバージョン付きのJARファイルに保存されます。

保存するバージョン付きJARファイルの最大数は、DomainMBeanのarchiveConfigurationCount属性で指定します。この最大数に達すると、新しいアーカイブが作成される前に、最も古い変換アーカイブが削除されます。

console-ext

このディレクトリには、WebLogic Server管理コンソールの拡張が格納されています。これらによって、Oracle WebLogic Serverにインストールされているファイルを修正することなく、WebLogic Server管理コンソールのコンテンツを追加または置換したり、ロゴ、スタイル、色を変更したりできます。たとえば、カスタマイズされたアプリケーション・モニター機能や管理機能を備えたコンテンツを追加できます。

init-info

このディレクトリには、WebLogicドメインのプロビジョニングに使用されるファイルがあります。このディレクトリのファイルは変更しないでください。

lib

このディレクトリに配置されているJARファイルは、ドメイン内のWebLogic Serverインスタンスで実行しているすべてのJava EEアプリケーションで(別のシステム・レベル・クラス・ローダー内で)使用できるようになります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のドメイン/libディレクトリへのJARの追加に関する項を参照してください。

pending

このディレクトリには、要求されてまだアクティブ化されていない構成の変更を表すドメイン構成ファイルが格納されます。構成の変更がアクティブ化されると、構成ファイルはこのディレクトリから削除されます。詳細は、構成の変更の管理を参照してください。

security

このディレクトリには、ドメイン内のどのOracle WebLogic Serverインスタンスの場合でも、以下のセキュリティ関連のファイルが格納されます。

- SerializedSystemIni.dat

また、ドメインの管理サーバーだけで必要になる、以下のセキュリティ関連ファイルも格納されます。

- DefaultAuthorizerInit.ldift

- DefaultAuthenticatorInit.ldift

- DefaultRoleMapperInit.ldift

- XACMLRoleMapperInit.ldift

詳細は、『Oracle WebLogic Serverセキュリティの理解』を参照してください。

servers

このディレクトリには、ドメイン内の各Oracle WebLogic Serverインスタンスごとに1つのサブディレクトリが含まれます。サブディレクトリには、各サーバー・インスタンスに固有のデータが格納されます。

サーバーの命名規則の詳細は、サーバー名の制限に関する項を参照してください。

servers/server-name

このディレクトリは、ディレクトリと同じ名前のOracle WebLogic Serverインスタンスのサーバー・ディレクトリです。

servers/server-name/cache

このディレクトリには、キャッシュされたデータを格納するディレクトリとファイルがあります。「キャッシュされた」というのは、データが他のデータのコピーであり、場合によっては処理済の形式(コンパイル済、変換済、または再フォーマット済)のコピーであることを意味します。

servers/server-name/cache/EJBCompilerCache

このディレクトリはコンパイル済EJB用のキャッシュです。

servers/server-name/data

このディレクトリには、一時的なキャッシュや履歴情報とは対照的に、Oracle WebLogic Serverインスタンスの実行に使用される、永続的なサーバーごとの状態(セキュリティの状態を除く)を保持するファイルが格納されます。このディレクトリのファイルは、Oracle WebLogic Serverインスタンスの起動、停止、クラッシュ、再起動、新しいバージョンへのアップグレードなどの際に保持する必要のある、重要な情報です。

servers/server-name/data/ldap

このディレクトリには組込みLDAPデータベースがあります。Oracle WebLogic Serverインスタンスの実行時のセキュリティの状態はこのディレクトリに永続化されます。

servers/server-name/data/store

このディレクトリにはWebLogic永続ストアが格納されます。各永続ストアごとに、永続ストアを表すファイルを格納するサブディレクトリがあります。サブディレクトリの名前は永続ストアの名前です。通常、defaultという名前のストアが1つあります。

servers/server-name/logs

このディレクトリにはログと診断情報が保持されます。この情報は事実上、履歴情報です。サーバーの処理に不可欠なものではなく、(少なくとも、Oracle WebLogic Serverインスタンスが停止している間に)削除しても、通常の処理には影響を与えません。ただし、この情報はデバッグや監査の目的には非常に役立つものなので、特に理由がない場合は削除しないでください。

servers/server-name/logs/diagnostic_images

このディレクトリには、WebLogic診断フレームワークのサーバー・イメージ・キャプチャ・コンポーネントによって作成される情報が格納されます。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

servers/server-name/logs/jmsServers

このディレクトリには、Oracle WebLogic Serverインスタンス内の各JMSサーバーごとに1つのサブディレクトリが含まれます。各サブディレクトリには、そのJMSサーバーのログが保存されます。サブディレクトリの名前はJMSサーバーの名前です。

servers/server-name/security

このディレクトリには、Oracle WebLogic Serverインスタンスごとに内容が異なる場合のある、セキュリティ関連のファイルが格納されます。boot.propertiesファイルはここに置かれるファイルの例です。このファイルの内容はサーバーごとに異なるからです。このディレクトリには、SSLキーに関連するファイルも格納されます。

servers/server-name/tmp

このディレクトリには、サーバー・インスタンスの実行中に作成される一時ディレクトリおよびファイルが格納されます。たとえば、JMSページング・ディレクトリは、他の場所を指定しない限り、自動的にここに作成されます。このディレクトリのファイルは、サーバーの実行中はそのままにしておく必要がありますが、サーバー・インスタンスを停止しているときは、自由に削除できます。

tmp

このディレクトリには、変更管理プロセスで使用される一時ファイルが保存されます。このディレクトリのファイルは変更しないでください。

サーバーのルート・ディレクトリ

Oracle WebLogic Serverのすべてのインスタンスは、ルート・ディレクトリを使用して、ドメインの構成ファイルの作業用コピーを格納したり、実行時データを格納したり、サーバーの構成内での相対パス名のコンテキストを提供したりします。管理サーバーの場合は、常にドメイン・ディレクトリがルート・ディレクトリとして使用されます。管理対象サーバーの場合は、ドメイン・ディレクトリも使用できますが、ユーザーが定義した他のどのディレクトリでも使用できます。

たとえば、管理サーバーをホストするコンピュータとファイル・システムを共有していない管理対象サーバーを起動した場合は、その管理対象サーバーによって独自のルート・ディレクトリが作成されます。サーバーは、ドメイン・ディレクトリのデータをこのルート・ディレクトリにコピーし、実行時データをこのディレクトリに書き込みます。

注意:

ドメイン・ディレクトリの外にあるディレクトリに管理対象サーバー・インスタンスを作成するには、-managed=trueオプションを指定したpackコマンド、または構成ウィザードを使用することをお薦めします。ただし、ドメイン・ディレクトリの外の空のディレクトリに手動で管理対象サーバーを作成する場合は、最初にsecurityディレクトリおよびその内容を、管理サーバー・ディレクトリからその管理対象サーバー・ディレクトリにコピーする必要があります。

サーバー・インスタンスごとにサーバー・ルート・ディレクトリのパスと名前を指定できます。1つのコンピュータ上にホストされる複数のサーバー・インスタンスで共通のサーバー・ルート・ディレクトリを指定することも、サーバーごとに異なるサーバー・ルート・ディレクトリを指定することもできます。ドメインには、1つまたは複数のサーバー・ルート・ディレクトリが存在できます。

サーバー・ルート・ディレクトリの指定

サーバー・ルート・ディレクトリのパスは、以下のいずれかの手段で指定できます。

- コマンド行からOracle WebLogic Serverインスタンスを起動する場合は、-Dweblogic.RootDirectory=pathオプションを使用します。たとえば、次のコマンドはOracle WebLogic Serverインスタンスを起動し、サーバーのルート・ディレクトリとしてc:\MyServerRootDirectoryを使用します。

java -Dweblogic.RootDirectory=c:\MyServerRootDirectory weblogic.Server

- ノード・マネージャを使用してOracle WebLogic Serverインスタンスを起動する場合は、WebLogic Server管理コンソールの「環境」→「サーバー」→「server_name」→「構成」→「サーバーの起動」ページの「ルート・ディレクトリ」属性で、サーバー・ルート・ディレクトリを指定できます。

上記の手段でサーバー・ルート・ディレクトリを指定しない場合、サーバー・ルート・ディレクトリのパスと名前は、サーバー・インスタンスが管理対象サーバーと管理サーバーのどちらであるか、サーバー・インスタンスの起動にノード・マネージャを使用するかどうかによって異なります。以降の節で、それらのバリエーションについて説明します。

管理サーバーのサーバー・ルート・ディレクトリ

管理サーバーは、サーバー・ルート・ディレクトリを、ドメインの構成データ(config.xmlなど)とセキュリティ・リソース(デフォルトの組込みLDAPサーバーなど)のリポジトリとして使用します。

管理サーバーのルート・ディレクトリの判別は以下の手順で行われます。

- サーバーの起動コマンドに-Dweblogic.RootDirectory=pathオプションが含まれている場合は、pathの値がサーバー・ルート・ディレクトリになります。

- -Dweblogic.RootDirectory=pathが指定されていない場合は、作業ディレクトリがサーバー・ルート・ディレクトリになります。

config.xmlファイルが見つからない場合は、新たにディレクトリを作成するかどうかを尋ねるメッセージが表示されます。この方法では、新しいドメインを作成できます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド行を使用したドメインの作成に関する項を参照してください。

ノード・マネージャで起動した管理対象サーバーのサーバー・ルート・ディレクトリ

ノード・マネージャを使用して管理対象サーバーを起動した場合、ルート・ディレクトリはノード・マネージャ・プロセスをホストするコンピュータ上に置かれます。サーバーのルート・ディレクトリの位置を判断するために、Oracle WebLogic Serverは以下を行います。

- WebLogic Server管理コンソールの「環境」→「サーバー」→「server-name」→「構成」→「サーバーの起動」ページでルート・ディレクトリを指定した場合、指定したディレクトリがサーバー・ルート・ディレクトリになります。

- WebLogic Server管理コンソールでルート・ディレクトリを指定していない場合、サーバー・ルート・ディレクトリは次のようになります。

ORACLE_HOME\user_projects\domains\domain-name\servers\managed-server-name

ORACLE_HOMEは、ノード・マネージャのホスト・コンピュータでのOracle WebLogic Serverのインストール・ディレクトリです。

ノード・マネージャで起動されていない管理対象サーバーのサーバー・ルート・ディレクトリ

ノード・マネージャを使用せず、java weblogic.Serverコマンドまたはそのコマンドを呼び出すスクリプトを使用して管理対象サーバーを起動した場合、Oracle WebLogic Serverは次のようにルート・ディレクトリを判断します。

- サーバーの起動コマンドに-Dweblogic.RootDirectory=pathオプションが含まれている場合は、pathの値がサーバー・ルート・ディレクトリになります。

- -Dweblogic.RootDirectory=pathが指定されていない場合は、作業(カレント)ディレクトリがルート・ディレクトリになります。たとえば、c:\config\MyManagedServerからweblogic.Serverコマンドを実行した場合は、c:\config\MyManagedServerがルート・ディレクトリになります。

Oracle WebLogic Serverソフトウェアがアップグレードされてもドメイン構成とアプリケーションを簡単に維持できるようにするには、サーバー・ルート・ディレクトリをOracle WebLogic Serverソフトウェアのインストール・ディレクトリとは別のディレクトリにします。

4 構成の変更の管理

この章では、構成の変更をドメイン内で安全確実に適用する手段である、Oracle WebLogic Server の変更管理プロセスについて説明します。このプロセスでは、インメモリーの変更を編集可能な構成MBeanを使用して行うことができます。

この章には次の項が含まれます:

- 変更管理の概要

- 管理コンソールでの変更管理

- 構成の変更管理のプロセス

- 構成管理の状態図

- 構成の変更の制限

- 指定された並行編集セッションの使用

変更管理の概要

各ドメインの構成は、ドメインの構成ディレクトリに格納されているXMLドキュメントに記述されます。実行時には、ドメイン内の各Oracle WebLogic Serverインスタンスが、このドキュメントに記述された構成のインメモリー表現を作成します。ドメインの構成のインメモリー表現とは、構成MBeanと呼ばれる読取り専用の管理対象Bean (MBean)のセットです。

管理サーバーは、読取り専用の構成MBeanに加え、編集可能な複数の構成MBeanも保持します(図4-2を参照)。これらの構成MBeanを編集するには、『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIの概要に関する項にリストされている管理ツールのいずれかを使用してロックを取得します。

編集可能な構成MBeanのロックを保持している間は、インメモリーの変更を保存できます。保存した変更は、管理サーバーによってドメイン・ディレクトリ内の保留中の構成ドキュメントに書き込まれます。Oracle WebLogic Serverインスタンスは、それらの変更がアクティブ化されるまで変更を消費しません。

変更をアクティブ化すると、ドメイン内の各サーバーが、その変更を適用できるかどうかを判断します。すべてのサーバーが変更を適用できる場合は、ドメインの構成ドキュメントのコピーが更新されます。その後、構成MBeanの作業用コピーが更新されて変更が完了します(図4-3を参照)。

Oracle WebLogic Serverの変更管理プロセスは、ドメインおよびサーバーの構成データの変更に対して適用されます。セキュリティまたはアプリケーション・データには適用されません。

サーバーの再起動が必要な変更

構成の変更には、実行中に有効にできるものもありますが、影響を受けるサーバーを再起動しないと有効にならないものもあります。サーバーを再起動せずに有効にできる構成の変更を「動的な」変更と呼び、サーバーの再起動が必要な構成の変更を「動的でない」変更と呼ぶことがあります。WebLogic Server管理コンソールでは、変更の有効化にサーバーの再起動が必要な属性には次のアイコンが付いています。

動的な構成属性の編集内容は、アクティブ化されると有効になります。その際、影響を受けるサーバーやシステム・リソースの再起動は不要です。動的でない構成属性の編集内容は、影響を受けるサーバーやシステム・リソースを再起動しないと有効にはなりません。

動的でない構成設定を編集した場合、動的な構成設定に対する編集内容は再起動するまでは有効になりません。つまり、動的な属性と動的でない属性の編集を一度に行った場合、編集内容の一部分だけがアクティブ化されることはありません。

構成変更ツール

『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIの概要に関する項で説明しているように、様々なOracle WebLogic Serverツールを使用して構成を変更できます。

- WebLogic Server管理コンソール

- WebLogic Scripting Tool

- JMX API

どのツールを使用して構成を変更しても、Oracle WebLogic Serverは基本的には同じように変更プロセスを処理します。

JMXと構成MBeanによる構成の変更方法の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。WLSTによる構成の変更の詳細は、『WebLogic Scripting Toolの理解』の既存ドメインの構成に関する項を参照してください。

構成監査

WebLogic監査プロバイダまたは他の監査セキュリティ・プロバイダを使用して、Oracle WebLogic Server構成の変更に関する監査情報を記録できます。『Oracle WebLogic Serverセキュリティの管理』の構成監査の有効化に関する項を参照してください。

管理コンソールでの変更管理

WebLogic Server 管理コンソールでは、構成の変更管理プロセスを「チェンジ・センター」ペインに一元化しています。

図4-1 チェンジ・センター

WebLogic Server管理コンソールを使用して構成を変更する場合は、まず、チェンジ・センターで「ロックして編集」ボタンをクリックする必要があります。「ロックして編集」をクリックすると、ドメイン(編集ツリー)内のすべてのサーバーの編集可能な構成MBeanのセットをまとめてロックすることになります。

注意:

ドメイン構成ロック機能は、プロダクション・ドメインでは常に有効になっています。開発ドメインでは有効にしたり無効にしたりできます。また、新しい開発ドメインを作成するときは、デフォルトで無効になっています。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン構成ロックの有効化と無効化に関する項を参照してください。

WebLogic Server管理コンソールを使用して構成を変更したら、該当するページで「保存」をクリックします。この操作を行っても、変更はすぐに有効にはなりません。かわりに、「保存」をクリックすると、変更内容が編集ツリーと、DOMAIN_NAME/pending/config.xmlファイルおよび関連する構成ファイルに保存されます。変更は、「チェンジ・センター」の「変更のアクティブ化」をクリックしたときに有効になります。構成の変更は、この時にドメイン内の各サーバーに配信されます。各サーバーに変更が適用可能な場合、その変更内容は有効になります。(ただし、サーバーの再起動が必要な変更もあります。)変更を受け入れないサーバーがあった場合は、ドメイン内のすべてのサーバーからすべての変更がロールバックされます。変更は保留状態になり、その状態の変更を編集して問題を解決するか、元の状態に戻すかのどちらかを選択できます。

開発ドメインの場合、WebLogic Server管理コンソールには、自動アクティブ化モデルがあります。「変更のアクティブ化」をクリックするかわりに、保存時に変更が自動的にアクティブ化されます。これは開発ドメインのデフォルトの動作で、本番ドメインで有効化できません。「ロックを自動取得して変更をアクティブ化」コンソール・プリファレンス・オプションの選択を解除して、この動作を無効化できます。

別の管理者からの構成ロックの取得

WebLogic Server管理コンソールでは、管理者は別の管理者から構成ロックを取得し、構成変更を行った後、これらの変更を保存できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの別の管理者からの構成ロックの取得に関する項を参照してください。ロックの取得元の管理者は、ロックを再取得するか、現在の管理者が変更を発行してロックを解除しないかぎり、いかなる追加変更もできなくなります。

ロックの取得元の管理者が、WebLogic Server管理コンソールを使用して変更を行っていた場合は、現在の管理者が保留中の変更をすべて継承します。他の管理者が構成の変更にWLSTなどの別の方法を使用している場合は、現在の管理者がロックを取得する際にこれらの変更が失われる可能性があります。

構成の変更管理のプロセス

構成の変更は、どのJMXツール(WebLogic Server管理コンソール、WLSTまたはJMX API)を使用する場合でも、基本的に同じように行われます。以下の手順では、ドメインの管理サーバーを起動するところから、プロセスを詳細に説明します。

1. 管理サーバーは起動時に、ドメインの構成ファイル(config.xmlファイルと、config.xmlファイルによって参照される補助構成ファイルなど)を読み込み、そのデータを使用して、次のMBeanツリーをメモリー内でインスタンス化します。

- 管理サーバー上にあるリソースの現在の構成を含む構成MBeanの読取り専用のツリー。

- ドメイン内のすべてのサーバーのすべての構成MBeanの編集可能なツリー。

注意:

管理サーバーは、実行時MBeanツリーとDomainRuntime MBeanツリーもインスタンス化しますが、これらは構成の管理には使用されません。

2. 構成の変更を始めるには、次の手順に従います。

a. 現在の構成でロックを取得します。

b. 任意のツール(WebLogic Server管理コンソール、WLST、JMX APIなど)を使用して、必要な変更を行います。

c. WebLogic Server管理コンソールの「保存」 ボタン、WLST saveコマンド、またはConfigurationManagerMBeanのsave操作を使用して、config.xmlファイルの保留中バージョンに変更を保存します。

3. 構成マネージャ・サービスは、編集MBeanツリーのすべてのデータを、pendingという名前のディレクトリで、別の構成ファイルのセットとして保存します。図4-2を参照してください。
pendingディレクトリはドメインのルート・ディレクトリのすぐ下にあります。たとえば、ドメインの名前がmydomainである場合、保留中のconfig.xmlファイルのデフォルトのパス名はmydomain/pending/config.xmlになります。

図4-2 管理サーバーの保留中のconfig.xmlファイル

4. さらに変更を行うか、行った変更を取り消します。

5. 変更が済んだら、WebLogic Server管理コンソールのチェンジ・センターにある「変更のアクティブ化」ボタン、WLST activateコマンド、またはConfigurationManagerMBeanのactivate操作を使用して、変更内容をドメイン内でアクティブ化します。
変更をアクティブ化すると、次のことが行われます(図4-3を参照)。

a. 構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスで、サーバーのルート・ディレクトリ内のconfigディレクトリに、保留中の構成ファイルをコピーします。

管理対象サーバーが管理サーバーとルート・ディレクトリを共有している場合、ConfigurationManagerMBeanは保留中の構成ファイルをコピーしません。つまり、管理対象サーバーは管理サーバーのconfigディレクトリを使用します。

b. 各サーバー・インスタンスは、現在の構成と保留中の構成を比較します。

c. 各サーバー内のサブシステムは、新しい構成を使用できるかどうかを表明します。
いずれかのサブシステムが変更を使用できないと表明した場合、アクティブ化プロセス全体がロールバックされ、ConfigurationManagerMBeanは例外を送出します。変更内容を修正して変更のアクティブ化を再試行するか、または、ロックを解放できます。ロックを解放した場合、編集用の構成MBeanツリーと保留中の構成ファイルは、読取り専用の構成MBeanツリーと構成ファイルの状態に戻ります。

d. すべてのサーバーのすべてのサブシステムで変更内容を使用できる場合、構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスにある読取り専用の構成ファイルを、保留中の構成ファイルで置き換えます。

e. 各サーバー・インスタンスは、各Beanと読取り専用の構成MBeanツリーを、新しい構成ファイルの変更内容に従って更新します。サーバーの再起動が必要な変更が1つまたは複数ある場合、この処理はサーバーの再起動時に行われます。

f. 保留中の構成ファイルは、pendingディレクトリから削除されます。

注意:

変更のアクティブ化が完了する(ステップ5.f)前に管理サーバーがクラッシュした場合、ステップ5.aで保存された保留中の構成ファイルは、再起動時に管理サーバーで回復されます。ログ・ファイルでは、このプロセスはconfig recoveryと表示されます。

6. ロックを保持してさらに変更を行うことも、他のユーザーが構成を更新できるようにロックを解放することもできます。タイムアウト期間を構成して、構成マネージャ・サービスにロックを解放させることができます。

図4-3 管理対象サーバーでの変更のアクティブ化

構成ロック

WebLogic Server管理コンソール、WLST、管理APIのどれを使用する場合でも、編集セッションを開始するときに、構成MBeanの編集ツリー上でロックを取得します。

構成の変更をロックしただけでは、同じ管理者ユーザー・アカウントによる構成の編集の衝突を防ぐことはできません。たとえば、WebLogic Server管理コンソールを使用して構成変更ロックを取得し、同じユーザー・アカウントでWebLogic Scripting Toolを使用する場合、WebLogic Server管理コンソールで開いたものと同じ編集セッションにアクセスして、Scripting Toolでの変更からロックアウトされることはありません。管理を行う各スタッフに別々の管理者ユーザー・アカウントを持たせることで、このような状況が発生するリスクを減らすことができます。それでも、同じユーザー・アカウントを使用する同じスクリプトの複数のインスタンスがある場合は、同様の問題が起きる可能性があります。

このような状況のリスクをさらに減らすために、「排他的な」構成変更ロックを取得することができます。排他的な構成ロックを取得した場合、それ以降に同じ所有者が編集セッションの開始を試行すると、その試行は、編集セッションのロックが解放されるまで待機させられます。WLSTを使用して排他的な構成ロックを取得するには、startEditコマンドで排他的引数としてtrueを使用します。

wls:/mydomain/edit> startEdit(60000, 120000, true)

管理APIを使用して排他的な構成ロックを取得するには、ConfigurationMBean.startEdit操作の排他的パラメータでtrueを使用します。

Object [] startEdit(60000, 120000, true)

次のいずれかに該当する場合は、互換性MBeanサーバーを使用してドメイン構成を変更することはできません。

- 既存の編集セッションがあります。

- 以前の編集セッションの、保留中の変更が保存されていますが、まだアクティブ化されていません。

変更の衝突の解決

複数の変更をアクティブ化せずに保存しているときに、一部の変更によって前の変更が無効になるような場合、構成マネージャ・サービスは、変更を保存する前に、手動で無効の部分を解決するように要求します。

構成管理の状態図

構成マネージャ・サービスでは、図4-4に示した一連の状態をたどります。

図4-4 構成管理の状態図

構成の変更の制限

ドメインを読取り専用に設定することで、構成の変更からブロックすることができます。それには、WLSTまたは管理APIを使用して、JMXMBean構成MBeanのEditMBeanServerEnabled属性をfalseに設定します。

ドメインを読取り専用に設定すると、WebLogic Server管理コンソール、WLSTオンラインまたは管理APIを使用してその構成を変更できなくなります。ドメインを再び編集可能にするには、config.xmlファイルをテキスト・エディタで直接編集するか、WLSTオフラインを使用した後で、影響を受けるサーバーを再起動します。

また、ドメインの構成に対する適切なアクセス制御を確立して、適切なセキュリティ・ロールを持つユーザーのみにアクセスを制限してください。WebLogic監査プロバイダまたは他の監査セキュリティ・プロバイダを使用して、Oracle WebLogic Server構成の変更に関する監査情報を記録することもできます。『Oracle WebLogic Serverセキュリティの管理』の構成監査の有効化に関する項を参照してください。

指定された並行編集セッションの使用

このリリースより前は、WebLogic Serverは、一度に1つのアクティブな構成編集セッションのみをサポートしていました。システム管理者は、グローバルな編集をロックし、変更を加えた後、それをアクティブ化していました。同時に他の管理者が変更を加えることはできませんでした。しかし、このリリースでは、WebLogic Serverは複数の指定された並行編集セッションを使用可能です。これにより、複数の管理者が同時に構成を変更できるようになります。これは通常、複数の管理者がシステムの別々の部分で作業する場合に有用です。また、構成コマンドをシリアルに実行することでシステムの構成に時間がかかる場合、1人の管理者が指定された複数の編集セッションを開くことができます。これは、構成編集セッションを並行して実行することで、時間を節約できます。

マルチテナント環境では、複数の管理者が並行して構成を変更する必要があります。マルチテナントWebLogicドメインには複数のパーティションがあり、それぞれに固有の管理者がいます。パーティション管理者は、他のパーティションの管理者やWebLogicのシステム管理者に影響を与えることなく、自分のパーティションに対する構成変更およびそこにデプロイされているリソースを変更できる必要があります。複数の、指定された並行編集セッションはパーティションごとの1つ以上の構成編集セッションに加えて、グローバル構成編集セッションをサポートします。

詳細は、『WebLogic Server MTの使用』の、名前付き同時編集セッションの管理に関する項を参照してください。

5 サーバー・テンプレート

サーバー・テンプレート

この章では、サーバー・テンプレートの概要と、WebLogic Serverでのサーバー・テンプレートの作成、構成および使用方法について説明します。

この章には次の項が含まれます:

- サーバー・テンプレートとは

- サーバー・テンプレートを使用する理由

- サーバー・テンプレートの使用方法

- サーバー・テンプレート・サンプル

サーバー・テンプレートとは

サーバー・テンプレートには、一連のサーバー・インスタンスに適用でき、テンプレート構成を継承する、共通のデフォルト以外の設定および属性が含まれています。サーバー・インスタンス定義のサーバー・テンプレートのオーバーライドによって、一意の属性を必要とするサーバー・インスタンスにサーバー固有の値を定義できます。実行時に、ドメインでは、サーバー・テンプレートで構成されている属性とサーバー固有のすべてのオーバーライドがマージされ、すべてのサーバー・インスタンスにすべての属性が定義されるようになります。

例5-1は、サーバー・テンプレートを使用するサンプルのconfig.xmlファイルを示しています。この例では、共通の構成は<server-template>要素で定義されています。個々のサーバー定義はサーバー固有の属性(name、listen-port)を設定し、追加の構成のベースとなるサーバー・テンプレート(my-cluster-server-template)を指定します。

例5-1 サーバー・テンプレートを使用するサンプルconfig.xmlファイル

<server>
<name>my-server-1</name>
<listen-port>7010</listen-port>
<server-template>my-cluster-server-template</server-template>
</server>

<server>
<name>my-server-2</name>
<listen-port>7020</listen-port>
<server-template>my-cluster-server-template</server-template>
</server>

<server-template>
<name>my-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<cluster>my-cluster</cluster>
<restart-max>10</restart-max>
<reverse-dns-allowed>true</reverse-dns-allowed>
<startup-timeout>600</startup-timeout>
</server-template>

サーバー・テンプレートを使用する理由

サーバー・テンプレートによって、集中化された場所でのサーバー・インスタンスのグループの構成を簡単に管理できます。サーバー・テンプレートに共通の構成属性を定義し、他のサーバー・インスタンスにテンプレートを適用できます。それぞれを手動で構成する必要はありません。サーバー固有の属性を定義する必要がある場合、個別のサーバー・レベルでサーバー・テンプレートを簡単にオーバーライドできます。

すべてのサーバー・インスタンスにわたる属性を更新する必要がある場合、サーバー・テンプレートでその値を変更するのみで、新しい値は、そのサーバー・テンプレートを使用するすべてのサーバー・インスタンスで有効になります。ドメイン内のすべてのサーバーを更新するためにWLSTスクリプトを記述する必要はありません。

サーバー・テンプレートは、パフォーマンスおよび起動時間の点でも役立ちます。各サーバー・インスタンス定義で同じ属性を設定するかわりに、サーバー・テンプレートで共通属性を一度定義すると、config.xmlファイルのサイズを小さくできます。

サーバー・テンプレートは、動的クラスタの作成にも使用します。詳細は、『Oracle WebLogic Serverのクラスタの管理』の動的クラスタに関する項を参照してください。

サーバー・テンプレートの使用方法

サーバー・テンプレートは、WebLogic Scripting Tool (WLST)またはWebLogic Server管理コンソールを使用して作成します。例5-2でWLSTの使用方法を示します。WebLogic Server管理コンソールの使用方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・テンプレートの作成に関する項を参照してください。サーバー・テンプレートを構成するには、『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIの概要に関する項にリストされている管理ツールのいずれかを使用します。

必要に応じて、サーバー固有の属性を定義するか、個別のサーバー定義でサーバー・テンプレートの値を直接オーバーライドできます。たとえば、いくつかのサーバー固有の属性(Notes、ConsensusProcessIdentifier、InterfaceAddressなど)は、個別のサーバー・レベルで定義したほうが便利です。

属性のオーバーライド

サーバー・テンプレートには、プリミティブ・データ型、シングルトン要素、構成要素からなる配列など、様々な種類の属性が含まれています。サーバー・テンプレートの値をオーバーライドするには、個別のサーバー定義で属性を定義します。

WebLogic Serverは、次のオーバーライド階層に基づいて、どの属性値を使用するのかを決定します。

- 個別のサーバー構成とサーバー・テンプレートのいずれでも属性を定義しない場合は、デフォルトの値が使用されます。

- サーバー・テンプレートで属性を定義する場合は、そのサーバー・テンプレートによってデフォルトの値がオーバーライドされます。サーバー・テンプレート値が使用されます。

- 個別のサーバー構成で属性を定義する場合は、そのサーバー構成によってサーバー・テンプレートの値およびデフォルトの値がオーバーライドされます。個別のサーバー構成の値が使用されます。

注意:

個別のサーバー構成で値をオーバーライドすると、この値が常にサーバー・テンプレートの値より優先されます。オーバーライドされた値を削除してサーバー・テンプレートの値を使用するには、unSet属性コマンドを使用します。

実行時に、ドメインは、サーバー・テンプレートで定義されている属性と個別のサーバー定義をマージし、目的の構成を戻します。

サーバー・インスタンスはサーバー・テンプレートの属性をオーバーライドできますが、属性のタイプごとにオーバーライドが異なります。プリミティブ・データ型の場合、サーバー構成の値によってサーバー・テンプレートの値がオーバーライドされます。たとえば、サーバー・テンプレートがリスニング・ポートを7101に定義しているが、サーバー構成で明示的なリスニング・ポート値を設定する場合、サーバー・インスタンスの値がサーバー・テンプレートのリスニング・ポート値をオーバーライドします。

サーバー・インスタンスは、子のシングルトン要素内に含まれている属性の値もオーバーライドします。たとえば、サーバー・テンプレートが共通ルート・ディレクトリ値を<server-start>子要素で定義しているが、サーバー構成で<server-start>要素に明示的なルート・ディレクトリ値を設定する場合、サーバー・インスタンスがサーバー・テンプレートのルート・ディレクトリ値をオーバーライドします。

子配列構成要素の場合、サーバー・インスタンスは、配列内の子要素内の個別の子要素や属性をオーバーライドすることはできません。サーバー構成は、構成要素の配列全体のみをオーバーライドできます。たとえば、サーバー・テンプレートでNetworkAccessPoint要素の配列が定義されており、サーバー・インスタンス構成でNetworkAccessPointsの配列が定義されている場合、サーバー・インスタンスNetworkAccessPointsが、サーバー・テンプレートの値をオーバーライドします。

次の例は、サーバー・インスタンスのNetworkAccessPointsを、WLSTを使用してオーバーライドする例を示しており、インライン・コメントを含んでいます。

#
#A server template named Cluster Template defines a NetworkAccessPoint named
#AccessPoint-1. The server instance s1 references Cluster Template as its
#template. A ls() command on s1 shows the following:
#

wls:/mydomain/edit/Servers/s1/NetworkAccessPoints !> ls

drw- AccessPoint-1

#
#Server instance s1 then defines a NetworkAccessPoint at the server instance
#level.
#

wls:/mydomain/edit/Servers/s1 !>
cmo.createNetworkAccessPoint("AccessPoint-2")

#
#This results in an override of the NetworkAccessPoints from the Cluster Template.
#AccessPoint-1 is no longer present in s1 and only AccessPoint-2 is defined in s1.
#

wls:/mydomain/edit/Servers/s1/NetworkAccessPoints !> ls

drw- AccessPoint-2

マクロの使用方法

サーバー・テンプレートは、共通属性を含んでおり、テンプレートから構成を継承する各サーバー・インスタンスに同じ値を提供します。場合によっては、属性に対して標準値を定義したいが、その値は各サーバー・インスタンスでわずかに異なるようにする必要が生じることがあります。各サーバー・インスタンスでサーバー固有の属性値を定義できますが、属性が1つのパターンに従っている場合はマクロを使用できる可能性があります。

サーバー・テンプレート内のどの文字列属性に対してもマクロを定義できます。マクロは大文字小文字を区別し、整数値または他の構成要素の参照には使用できません。サーバー・テンプレートで使用可能な有効なマクロは次のとおりです。

- ${id}: 動的に作成されたサーバーのインスタンスID。このIDは1から始まります。

- ${serverName}: この要素が属するサーバー名。

- ${clusterName}: この要素が属するクラスタ名。この要素がクラスタに属していない場合、空の文字列が代入されます。

- ${domainName}: この要素が属するドメイン名。

- ${system-property-name}: これが、前述の事前定義済マクロ名ではない場合、システム・プロパティとして評価され、その値が返されます。システム・プロパティが存在しない場合は、空の文字列が代入されます。

サーバー・テンプレート・サンプル

例5-2は、WLSTを使用して同じサーバー・テンプレートを使用する2つのサーバー・インスタンスを作成する例を示しています。この例には、インライン・コメントと次の作業の実行方法が示されています。

1. サーバー・テンプレートを作成して、my-cluster-server-templateという名前を付けます。

2. my-cluster-server-templateのすべての共通属性を設定します。

3. サーバー・インスタンスmy-server1およびmy-server2を作成し、各インスタンスにmy-cluster-server-templateを割り当てます。

4. サーバー固有の属性を設定します。

例5-2 WLSTによるサーバー・テンプレートの使用

#
# This example demonstrates the WLST commands needed to create a server template
# (my-cluster-server-template) and server instances (my-server-1, my-server-2)
# that use the server template. The creation of the cluster (my-cluster) and
# machines (PrimaryMachine, SecondaryMachine) are not included in this example;
# they must be created before running this script. To keep this example
# simple, error handling was omitted.
#
connect()
edit()
startEdit()
#
# Create the server template and set the common attributes that are used in all
# servers. Attributes such as Accept Backlog, Auto Restart, etc. are the same
# across all cluster members.
#
serverTemplate=cmo.createServerTemplate("my-cluster-server-template")
serverTemplate.setAcceptBacklog(2000)
serverTemplate.setAutoRestart(true)
serverTemplate.setRestartMax(10)
serverTemplate.setReverseDNSAllowed(true)
serverTemplate.setStagingMode("external_stage")
serverTemplate.setStartupTimeout(600)
myCluster=cmo.lookupCluster("my-cluster")
serverTemplate.setCluster(myCluster)
#
# Create the individual server instances, set the server specific attributes, and
# set the template so the server uses the common attributes from the template.
# Attributes such as cluster weight, listen port, and machine are server-specific
# so they are not included in the server template.
#
server1=cmo.createServer("my-server-1")
server1.setClusterWeight(70)
server1.setListenPort(7010)
primary=cmo.lookupMachine("PrimaryMachine")
server1.setMachine(primary)
server1.setServerTemplate(serverTemplate)
#
server2=cmo.createServer("my-server-2")
server2.setClusterWeight(90)
server2.setListenPort(7020)
secondary=cmo.lookupMachine("SecondaryMachine")
server2.setMachine(secondary)
server2.setServerTemplate(serverTemplate)
#
# activate the changes
#
activate()

この結果得られるconfig.xmlファイルは次のようになります。

<server>
<name>my-server-1</name>
<cluster-weight>70</cluster-weight>
<listen-port>7010</listen-port>
<machine>PrimaryMachine</machine>
<server-template>my-cluster-server-template</server-template>
</server>

<server>
<name>my-server-2</name>
<cluster-weight>90</cluster-weight>
<listen-port>7020</listen-port>
<machine>SecondaryMachine</machine>
<server-template>my-cluster-server-template</server-template>
</server>

<server-template>
<name>my-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<auto-restart>true</auto-restart>
<cluster>my-cluster</cluster>
<restart-max>10</restart-max>
<reverse-dns-allowed>true</reverse-dns-allowed>
<staging-mode>external_stage</staging-mode>
<startup-timeout>600</startup-timeout>
</server-template>

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。