構成の変更の管理

4 構成の変更の管理

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

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

変更管理の概要

ドメイン内の構成の変更を配信するセキュアで予測可能な手段を提供するために、WebLogic Serverでは、大まかにいうとデータベース・トランザクションのような変更管理プロセスが必ず実行されます。

各ドメインの構成は、ドメインの構成ディレクトリに格納されている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管理コンソール
Fusion Middleware Control (FMWC)
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 チェンジ・センター

「図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などの別の方法を使用している場合は、現在の管理者がロックを取得する際にこれらの変更が失われる可能性があります。

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

構成の変更は、どの方法を使用する場合でも(WebLogic Server管理コンソール、FMWC、WLST、JMXまたはREST API)、基本的に同じように行われます。

以下のステップでは、ドメインの管理サーバーを起動するところから、プロセスを詳細に説明します。

ノート:

構成以外のファイルをconfigディレクトリまたはサブディレクトリに追加しないでください。構成以外のファイルにはログ(.log)ファイルおよびロック(.lck)ファイルなどがあります。管理サーバーでは、すべての管理対象サーバー・インスタンスのconfigディレクトリがレプリケートされます。構成以外のファイルをconfigディレクトリに格納すると、ドメインでパフォーマンスの問題が引き起こされる可能性があります。

管理サーバーは起動時に、ドメインの構成ファイル(config.xmlファイルと、config.xmlファイルによって参照される補助構成ファイルなど)を読み込み、そのデータを使用して、次のMBeanツリーをメモリー内でインスタンス化します。
- 管理サーバー上にあるリソースの現在の構成を含む構成MBeanの読取り専用のツリー。
- ドメイン内のすべてのサーバーのすべての構成MBeanの編集可能なツリー。
  
  ノート:
  
  管理サーバーは、実行時MBeanツリーとDomainRuntime MBeanツリーもインスタンス化しますが、これらは構成の管理には使用されません。
構成の変更を始めるには、次の手順に従います。
1. 現在の構成でロックを取得します。
2. 任意のツール(WebLogic Server管理コンソール、FMWC、WLST、JMX APIなど)を使用して、必要な変更を行います。
3. WebLogic Server管理コンソールの「保存」 ボタン、WLST saveコマンド、またはConfigurationManagerMBeanのsave操作を使用して、config.xmlファイルの保留中バージョンに変更を保存します。
構成マネージャ・サービスは、編集MBeanツリーのすべてのデータを、pendingという名前のディレクトリで、別の構成ファイルのセットとして保存します。図4-2を参照してください。

pendingディレクトリはドメインのルート・ディレクトリのすぐ下にあります。たとえば、ドメインの名前がmydomainである場合、保留中のconfig.xmlファイルのデフォルトのパス名はmydomain/pending/config.xmlになります。

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

「図4-2 管理サーバーの保留中のconfig.xmlファイル」の説明
さらに変更を行うか、行った変更を取り消します。
変更が済んだら、WebLogic Server管理コンソールのチェンジ・センターにある「変更のアクティブ化」ボタン、WLST activateコマンド、またはConfigurationManagerMBeanのactivate操作を使用して、変更内容をドメイン内でアクティブ化します。

変更をアクティブ化すると、次のことが行われます(図4-3を参照)。
1. 構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスで、サーバーのルート・ディレクトリ内のconfigディレクトリに、保留中の構成ファイルをコピーします。
  
  管理対象サーバーが管理サーバーとルート・ディレクトリを共有している場合、ConfigurationManagerMBeanは保留中の構成ファイルをコピーしません。つまり、管理対象サーバーは管理サーバーのconfigディレクトリを使用します。
2. 各サーバー・インスタンスは、現在の構成と保留中の構成を比較します。
3. 各サーバー内のサブシステムは、新しい構成を使用できるかどうかを表明します。
  
  いずれかのサブシステムが変更を使用できないと表明した場合、アクティブ化プロセス全体がロールバックされ、ConfigurationManagerMBeanは例外を送出します。変更内容を修正して変更のアクティブ化を再試行するか、または、ロックを解放できます。ロックを解放した場合、編集用の構成MBeanツリーと保留中の構成ファイルは、読取り専用の構成MBeanツリーと構成ファイルの状態に戻ります。
4. すべてのサーバーのすべてのサブシステムで変更内容を使用できる場合、構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスにある読取り専用の構成ファイルを、保留中の構成ファイルで置き換えます。
5. 各サーバー・インスタンスは、各Beanと読取り専用の構成MBeanツリーを、新しい構成ファイルの変更内容に従って更新します。サーバーの再起動が必要な変更が1つまたは複数ある場合、この処理はサーバーの再起動時に行われます。
6. 保留中の構成ファイルは、pendingディレクトリから削除されます。
  
  ノート:
  
  変更のアクティブ化が完了する(ステップ5.f)前に管理サーバーがクラッシュした場合、ステップ5.aで保存された保留中の構成ファイルは、再起動時に管理サーバーで回復されます。ログ・ファイルでは、このプロセスはconfig recoveryと表示されます。
ロックを保持してさらに変更を行うことも、他のユーザーが構成を更新できるようにロックを解放することもできます。タイムアウト期間を構成して、構成マネージャ・サービスにロックを解放させることができます。

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

「図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 構成管理の状態図

「図4-4 構成管理の状態図」の説明

構成の変更の制限

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

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

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

構成のオーバーライド

構成のオーバーライドにより、管理者はXMLファイルに含まれている構成情報を既知の場所に格納します。そこで実行中のサーバーがその構成情報を識別し、ロードして、既存の構成のアスペクトをオーバーライドします。

クラウド・プラットフォームなどにおける大きいクラスタまたは複雑な分散環境では、ネットワーク、ソフトウェアおよびスケーリングの問題により、構成プロパティの設定および削除は困難な作業です。この状況は、サーバーを管理対象サーバーの独立モード(MSI)モードで実行する必要がある場合に発生します。構成のオーバーライド(状況構成とも呼ばれます)を使用すると、サーバーのデバッグ・フラグ、タイムアウト値または診断設定などの設定を、管理サーバーを実行せずに変更できます。構成のオーバーライドは管理対象サーバーを対象にしていますが、管理サーバーにも適用できます。構成のオーバーライドを使用する場合、管理サーバーと管理対象サーバー間は同期されません。構成のオーバーライドでは、構成情報を管理対象サーバーに配布するための主な手段として、管理サーバーをバイパスします。

状況構成では、実行中のWebLogic Serverインスタンスに追加する必要がある構成変更(オーバーライド)を含むファイルを格納します。構成変更が必要以上に長い間持続しないようにするために、オーバーライドには有効期限を指定できます。または、永続的にすることも、有効期限を指定しないことも可能です。WebLogic Serverの以前のリリースでは、オーバーライドされたドメイン構成は有効期限を必要していたため、常に一時的なものでした。しかし、この制限は現在解消されています。詳細は、『Oracle WebLogic Serverドメイン構成の理解』の一時構成オーバーライドに関する項を参照してください。

次のシナリオを考えてみます。特定の環境では、様々なサイズのクラスタを考慮することが必要な場合があります。この場合、小規模、中規模または大規模なクラスタに適した構成を実現する構成のオーバーライドと組み合わされた、すべての環境を対象としたベース構成を用意できます。これにより、クラスタサイズ固有の構成から切り離された一般的な共有構成が可能になります。たとえば、特定のサーバーは大規模なクラスタ環境でのみ必要になります。小規模なクラスタ環境の場合、管理者はこれらのサーバーが存在することを必要としません。管理者は、これらのサーバーが削除された状況構成ファイルを作成します。実行時には、状況構成ファイルがロードされ、不要なサーバーは構成から削除されます。

状況構成は、次のようになります。

構成変更を実行中のシステムに適用します。格納されている構成には影響しません。
変更する値とコンテキスト情報を含むファイルでXMLフラグメントを使用します。このファイルを使用して、ドメインのconfigディレクトリのjdbc、jmsおよびdiagnosticsサブディレクトリ内に存在するシステム・リソース・ファイルまたはconfig.xmlファイルからの構成情報を更新します。
構成要素値の置換、新しい構成要素の追加、または既存の構成要素の削除が可能です。
動的属性および非動的属性を更新できます。ただし、サーバーの起動後に適用された非動的変更が変更に含まれる場合、次回のサーバーの起動時までサーバーの状況構成変更は更新されません。
構成のオーバーライドに有効期限を含めることができますが、必須ではありません。XMLファイルが削除、名前変更または有効期限切れになると、オーバーライドは元に戻されます。
状況構成ファイルが存在すること、および見つからない場合はサーバーの起動が失敗することを必須とするオプションが含まれます。
管理サーバーの関与を必要とせず、管理対象サーバーはどのような方法であってもその値を同期しません。

状況構成によって現在オーバーライドされている値が編集セッションで変更された場合、その変更は、状況構成のオーバーライドが削除されるまで有効になりません。状況構成では、適用または有効期限切れになったとき、および削除されたときに、サーバーのログにメッセージが記録されます。

状況構成ファイル、名前および場所について

状況構成ファイルは、接尾辞situational-config.xmlで終わり、デフォルトでoptconfigディレクトリに格納されるドメイン構成ファイルです。JDBC、JMSおよび診断システム・リソースの場合、これらはoptconfigのjdbc、jmsおよびdiagnosticsサブディレクトリに格納されます。

図4-5 ドメイン構成ファイル・ディレクトリのレイアウト

「図4-5 ドメイン構成ファイル・ディレクトリのレイアウト」の説明

管理者が、situational-config.xmlファイルを作成、更新および削除します。ドメインが別のシステムにある場合は、状況構成XMLファイルを各optconfigディレクトリにコピーする必要があります。

JDBC、JMSおよび診断システム・リソース・ファイルの場合、状況構成ファイル名はシステム・リソース・ファイル名と一致し、situational-config.xml接尾辞が追加される必要があります。たとえば、myqueues-jms.xmlという名前のJMSシステム・リリースは、myqueues-jms-situational-config.xmlという名前のファイルによってのみオーバーライドできます。

ファイルのデフォルトの場所のオーバーライド

システム￥プロパティweblogic.SituationalConfigPathを使用して、situational-config.xmlファイルのデフォルトのoptconfigディレクトリの場所をオーバーライドできます。

この値を設定するには、export JAVA_OPTIONS=-Dweblogic.SituationalConfigPath=<your sitconfig file path>を使用し、サーバーを起動します。

たとえば:

export JAVA_OPTIONS=-Dweblogic.SituationalConfigPath=$optconfig:$domainroot/mydir:/scratch/myoptconfig

次の置換がサポートされています。

$domainroot - ドメイン・ルート・ディレクトリ
$optconfig - optconfigのデフォルトの場所($domainroot/optconfigなど)

situational-config.xmlファイルは、定義されているoptconfigディレクトリの下にあるサーバー固有のディレクトリ内で探すことができます。たとえば、管理サーバーは、$domainroot/optconfigおよび$domainroot/optconfig/admin内で状況構成ファイルを探します。管理対象サーバーms1では、サーバーは、$domainroot/optconfigおよび$domainroot/optconfig/ms1内で状況構成ファイルを探します。

サーバー固有のシステム・リリース状況構成ファイルの場合、定義されているoptconfigディレクトリの下にあるサーバー固有のディレクトリ内のjdbc、jmsおよびdiagnosticsサブディレクトリを指定できます。

システム・プロパティは、コロン区切りのパスのリスト($optconfig:$domainroot/mydir:/scratch/myoptconfigなど)にすることができます。この例のパスの場合、サーバーは、状況構成ファイルを次の順序で探します(処理します)。

<domain root>/optconfig
<domain root>/optconfig/<servername>
<domain root>/optconfig/jms
<domain root>/optconfig/jdbc
<domain root>/optconfig/diagnostics

<domain root>/mydir/
<domain root>/mydir/<servername>
<domain root>/mydir/jms
<domain root>/mydir/jdbc
<domain root>/mydir/diagnostics

/scratch/myoptconfig
/scratch/myoptconfig/<servername>
/scratch/myoptconfig/jms
/scratch/myoptconfig/jdbc
/scratch/myoptconfig/diagnostics

ファイル形式

状況構成ファイルには、変更対象の構成の構造を参照するXMLフラグメントが含まれています。たとえば、config.xmlでこのサーバーのデバッグ構成を変更するには、次のようにします。

<domain .... >
  <name>sitconfigDomain</name>
  <server>
    <name>admin</name>
    <server-debug>
    </server-debug>
  </server>
...

状況構成XMLフラグメントは、次のようになります。

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
 xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
   <s:expiration> 2020-11-29T10:24-08:00 </s:expiration>
  <dom:name>sitconfigDomain</dom:name>
  <dom:server>
    <dom:name>admin</dom:name>
    <dom:server-debug>
      <dom:debug-jmx-core f:combine-mode="replace">true</dom:debug-jmx-core>
    </dom:server-debug>
  </dom:server>
  </dom:domain>

次の例では、パスの一部(<server-debug>)が欠落しているため、debug-jmx-coreは置換(オーバーライド)されません。

<f:domain  xmlns=.... >
   <dom:server>
     <dom:name>admin</dom:name>
      <dom:debug-jmx-core f:combine-mode="replace">true</dom:debug-jmx-core>
   </dom:server>
</f:domain>

スキーマ

状況構成XMLフラグメントには、複数のスキーマからのエントリが含まれます。situational-configスキーマは、状況構成の適用方法(有効期限など)に関する情報を提供します。残りのフラグメントには、config.xmlまたはシステム・リリース・ファイルのインメモリー・コンテンツの変更方法に関する情報が含まれています。

situational-config.xsdには、次の行が含まれています。

    <?xml version="1.0" encoding="UTF-8" ?>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
         <!-- expiration time for this file -->
        <xs:element name=“expiration” type=“xs:string”/>
    </xs:schema>

sit-domain-fragment.xsdは真のスキーマではありませんが、XMLフラグメントで参照される必要があります。次の例に示すように、値を置換(オーバーライド)するには、構文f:combine-mode="replace"を使用します。

    <?xml version='1.0' encoding='UTF-8'?>
    <f:domain 
     xmlns="http://xmlns.oracle.com/weblogic/domain" 
     xmlns:f="http://xmlns.oracle.com/weblogic/sit-domain-fragment"
     xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
       <s:expiration> 2020-07-16T19:20+01:00 </s:expiration>
       <server>
         <name>soa_server1</name>
         <max-message-size f:combine-mode="replace">30000000</max-message-size>
        <server-debug>
          <debug-jmx-core f:combine-mode="replace">true</debug-jmx-core>
        </server-debug>
       </server>
    </f:domain>

システム・リリースの状況構成フラグメントは、config.xmlのオーバーライドの状況構成ファイルと似ています。JDBC、JMSおよび診断システム・リソース・ファイルの場合、XML状況構成およびネームスペースは、システム・リソース・タイプ(JMS、JDBCまたはWLDF)に固有のものです。残りのフラグメントには、システム・リリースのインメモリー・コンテンツの変更方法に関する情報が含まれています。JMS、JDBCおよびWLDFシステム・リリースの状況構成ファイルの次の例を検討してください。

共有構成要素および有効期限ポリシーをオーバーライドするJMS状況構成ファイル:

<?xml version='1.0' encoding='UTF-8'?>
<jms:weblogic-jms
 xmlns:jms="http://xmlns.oracle.com/weblogic/weblogic-jms"
 xmlns:f="http://xmlns.oracle.com/weblogic/weblogic-jms-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
 <jms:quota jms:name="MyTemplate.Quota">
    <jms:shared f:combine-mode="replace">true</jms:shared>
 </jms:quota>
  <jms:template jms:name="MyTemplate">
    <jms:delivery-failure-params>
      <jms:expiration-policy f:combine-mode="replace">Discard</jms:expiration-policy>
    </jms:delivery-failure-params>
  </jms:template>
</jms:weblogic-jms>

ユーザー名およびパスワード・プロパティを追加するJDBCファイル:

<?xml version='1.0' encoding='UTF-8'?>
<jdbc:jdbc-data-source
 xmlns:jdbc="http://xmlns.oracle.com/weblogic/jdbc-data-source"
 xmlns:f="http://xmlns.oracle.com/weblogic/jdbc-data-source-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
 <jdbc:name>jdbcDataSource</jdbc:name>
   <jdbc:jdbc-driver-params>
     <jdbc:properties>
       <jdbc:property f:combine-mode="replace">
          <jdbc:name>user</jdbc:name>
          <jdbc:value>Jones</jdbc:value>
       </jdbc:property>
       <jdbc:property f:combine-mode="replace">
          <jdbc:name>password</name>
          <jdbc:value>password</value>
       </jdbc:property>
     </jdbc:properties>
   </jdbc:jdbc-driver-params>
</jdbc:jdbc-data-source>

インストゥルメンテーションを可能にする診断ファイル:

<?xml version='1.0' encoding='UTF-8'?>
<wldf-resource
  xmlns:wldf="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
  xmlns:f="http://xmlns.oracle.com/weblogic/weblogic-diagnostics-fragment"
  xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <wldf:instrumentation>
    <wldf:enabled f:combine-mode="replace">true</wldf:enabled>
  </wldf:instrumentation>
<wldf:wldf-resource>

構成要素を追加または削除するには、次の例に示すように、構文f:combine-mode="add"またはf:combine-mode="delete"を使用します。

次の構成ファイル・フラグメントは、両方の基本データ型(String、int、Boolean)およびネストされた要素の追加を示しています。要素は、ドメインとネストされたサーバー・レイヤーの両方で追加されます。

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
 xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <s:expiration> 2020-11-30T19:20+01:00 </s:expiration>
  <dom:name>sitconfigDomain</dom:name>
  <dom:notes f:combine-mode="add">Situational Config Domain</dom:notes>
  <dom:archive-configuration-count f:combine-mode="add">2</dom:archive-configuration-count>
  <dom:startup-class f:combine-mode="add">
    <dom:deployment-order>33</dom:deployment-order>
    <dom:name>AddedStartupClassOne</dom:name>
  </dom:startup-class>
  <dom:startup-class f:combine-mode="add">
    <dom:deployment-order>44</dom:deployment-order>
    <dom:name>AddedStartupClassTwo</dom:name>
  </dom:startup-class>
  <dom:server>
    <dom:name>admin</dom:name>
    <dom:notes f:combine-mode="add">admin server</dom:notes>
    <dom:server-debug>
      <dom:debug-jmx-core f:combine-mode="add">true</dom:debug-jmx-core>
    </dom:server-debug>
    <dom:max-message-size f:combine-mode="add">78787878</dom:max-message-size>
  </dom:server>
</dom:domain>

次の構成ファイル・フラグメントは、ドメインへの新しいサーバーの追加を示しています。

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
  xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <s:expiration> 2020-11-30T19:20+01:00 </s:expiration>
  <dom:name>sitconfigDomain</dom:name>
  <dom:server f:combine-mode="add">
    <dom:name>addedServer</dom:name>
    <dom:notes>addedServer notes</dom:notes>
    <dom:listen-port>7401</dom:listen-port>
    <dom:tgiop-enabled>false</dom:tgiop-enabled>
    <dom:network-access-point>
      <dom:name>AddedNetworkAccessPointOne</dom:name>
      <dom:listen-port>7501</dom:listen-port>
    </dom:network-access-point>
    <dom:network-access-point>
      <dom:name>AddedNetworkAccessPointTwo</dom:name>
      <dom:listen-port>7601</dom:listen-port>
    </dom:network-access-point>
  </dom:server>
</dom:domain>

次の構成ファイル・フラグメントは、両方の基本データ型(String、int、Boolean)の削除を示しています。要素は、ドメインとネストされたサーバー・レイヤーの両方で削除されます。

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
  xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <s:expiration> 2020-11-30T19:20+01:00 </s:expiration>
  <dom:name>sitconfigDomain</dom:name>
  <dom:configuration-version f:combine-mode="delete"></dom:configuration-version>
  <dom:server>
    <dom:name>MyServerOne</dom:name>
    <dom:listen-port f:combine-mode="delete"></dom:listen-port>
    <dom:network-access-point f:combine-mode="delete"></dom:network-access-point>
   </dom:server>
  <dom:server>
    <dom:name>MyServerTwo</dom:name>
    <dom:listen-port f:combine-mode="delete"></dom:listen-port>
  </dom:server>
  <dom:server>
    <dom:name>ms1</dom:name>
    <dom:accept-backlog f:combine-mode="delete"></dom:accept-backlog>
    <dom:ignore-sessions-during-shutdown f:combine-mode="delete"></dom:ignore-sessions-during-shutdown>
  </dom:server>
</dom:domain>

XMLネームスペース

次の表は、状況構成ファイルによって使用されるXMLネームスペースの要約を示します。

xmlnsタイプ	例	説明
ドメイン	`xmlns:dom="http://xmlns.oracle.com/weblogic/domain"`	ドメイン要素(`<dom:domain>`など)を識別するためにドメインの状況`config.xml`のオーバーライドに使用されます。
ドメイン・フラグメント	`xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"`	ドメイン要素内のドメイン・フラグメント要素(`f:combine-mode="replace"`など)を識別するためにドメイン`config.xml`のオーバーライドに使用されます。
状況構成	`xmlns:s="http://xmlns.oracle.com/weblogic/situational-config"`	状況構成要素(`<s:expiration-time>`など)を識別するためにドメインconfig.xmlおよびシステム・リソースのオーバーライドに使用されます。
JMS	`xmlns:jms="http://xmlns.oracle.com/weblogic/weblogic-jms"`	JMSシステム・リソース要素(`<jms:template name="JMSTemplate1">`など)の識別に使用されます。
JDBC	`xmlns:jdbc="http://xmlns.oracle.com/weblogic/jdbc-data-source"`	JDBCシステム・リソース要素(`<jdbc:jdbc-driver-params>`など)の識別に使用されます。
診断	`xmlns:wldf="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"`	WLDFシステム・リソース要素(`<wldf:watch-notification>`など)の識別に使用されます。
JMSシステム・リソース・フラグメント	`xmlns:f="http://xmlns.oracle.com/weblogic/weblogic-jms-fragment"`	JMSシステム・リソース要素内のJMSシステム・リソース・フラグメント要素(`f:combine-mode="replace"`など)を識別するためにJMSシステム・リソースのオーバーライドに使用されます。
JDBSシステム・リソース・フラグメント	`xmlns:f="http://xmlns.oracle.com/weblogic/jdbc-data-source-fragment"`	JDBCシステム・リソース要素内のJDBCシステム・リソース・フラグメント要素(`f:combine-mode="replace"`など)を識別するためにJDBCシステム・リソースのオーバーライドに使用されます。
WLDFシステム・リソース・フラグメント	`xmlns:f="http://xmlns.oracle.com/weblogic/weblogic-diagnostics-fragment"`	WLDFシステム・リソース要素内のWLDFシステム・リソース・フラグメント要素(`f:combine-mode="replace"`など)を識別するためにWLDFシステム・リソースのオーバーライドに使用されます。

ファイルの有効期限

必要に応じて、situational-config.xsdスキーマを参照して有効期限要素を設定し、XMLフラグメントに明示的な有効期限を設定できます。有効期限は、long (システム時間)またはW3C準拠の文字列です。

たとえば:

   <s:expiration> 2020-11-29T10:24-08:00 </s:expiration>
        11/29/2020 @ 10:24 am (PDT)

   <s:expiration> 2020-11-29T10:24 </s:expiration>
        11/29/2020 @ 10:24 am (local timezone)

   <s:expiration> 2020-11-29T10:24:15 </s:expiration>
        11/29/2020 @ 10:24:15 am (local timezone)

状況構成の値は、ファイルが削除されるかシステム時間が有効期限切れになるまでの間、配置されます。その後、ファイルとその値はアンロードされ、設定は以前の値に戻されます。状況構成ファイルに現在時刻よりも早いタイムアウト値が指定されている場合(ファイルが有効期限切れになっている場合)、ファイルの内容は無視されます。

有効期限なしにpermanent状況構成ファイルを有効にするには、有効期限要素を指定しないか、有効期限要素値をマイナス1 (-1)の値で指定します。

有効期限要素がない永続的状況構成ファイルの例:

<?xml version='1.0' encoding='UTF-8'?>
<domain
  xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <name>sitconfigDomain</name>
  <server>
    <name>admin</name>
    <server-debug>
      <debug-jmx-core f:combine-mode="replace">true</debug-jmx-core>
    </server-debug>
  </server>
</domain>

有効期限が-1である永続的状況構成ファイルの例:

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
  xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <s:expiration>-1</s:expiration>
  <dom:name>sitconfigDomain</dom:name>
    <dom:server>
      <dom:name>admin</dom:name>
      <dom:server-debug>
        <dom:debug-jmx-core f:combine-mode="replace">true</dom:debug-jmx-core>
      </dom:server-debug>
    </dom:server>
  </dom:domain>

状況構成のロード

状況構成ファイルは、サーバーが起動したときに終了します。状況構成は、編集構成階層ではなく実行時階層にロードされます。管理者は、実行時ツリーを参照することにより、有効な構成(ベース構成と状況構成のオーバーライド)を確認できます。構成編集ツリーには、状況構成が適用される前または状況構成が削除された後のベース値のみが表示されます。

図4-6 状況構成ファイルのロードおよび削除

「図4-6 状況構成ファイルのロードおよび削除」の説明

WLSTを使用した編集およびランタイム構成へのアクセス

条件:

ドメインNotes属性「My Domain」を持つconfig.xml
値「My New Domain」を使用してドメインNotes属性をオーバーライドする状況構成ファイル

WLSTを使用して、次のように、編集およびランタイム構成にアクセスできます。

# runtime configuration
serverConfig()
wls:/mydomain/serverConfig/> print cmo.getNotes()
My New Domain
# edit configuration
wls:/mydomain/serverConfig/> edit()
wls:/mydomain/edit/> print cmo.getNotes()
My Domain

複数のフラグメントの処理

各状況構成XMLフラグメントは、独自のsituational-config.xmlファイルに格納され、ファイルごとに1つのフラグメントのみが許可されます。複数のフラグメントが使用可能な場合は、それぞれ一意の名前が付いた複数の状況構成ファイルがあることになります。たとえば:

wildcard-situational-config.xml
example1-situational-config.xml
foobar-situational-config.xml

状況構成ファイルはその変更日に基づいてロードされ、最も古いファイルが最初にロードされて、次に後続のファイルが処理(ロード)されます。

ワイルドカードの使用

XMLフラグメントでは、ワイルドカードを使用して柔軟性を高めることで、複数のリソースで同じ構成設定セットを処理することなどが可能になります。

たとえば、クラスタ内のすべてのサーバーで同じデバッグ設定を上書きするには、次のようにします。

<f:domain 
  xmlns=.... >
    <dom:server>
     <dom:name>'*'</dom:name>
     <dom:max-message-size f:combine-mode="replace">30000000</dom:max-message-size>
      <dom:server-debug>
               <dom:debug-jmx-core f:combine-mode="replace">true</dom:debug-jmx-core>
      </dom:server-debug>
   </dom:server>
</f:domain>

1つのワイルドカード、つまり'*' (一重引用符で囲んでエスケープされたアスタリスク)のみがサポートされます。これは、あらゆる値に一致します。

ワイルドカードを使用する際には、次のルールに従ってください。

ワイルドカードは、要素でのみ使用します。
- ワイルドカードを使用すると、特定の要素がアスタリスク(*)に置換され、同じタグ・セット内にあるすべての要素と一致するようになります。
- ワイルドカードは、任意の要素と一致します。たとえば、サーバー名adminを*に変更すると、フラグメント内のadminを対象にしたすべての設定がすべてのサーバーに適用されます。たとえば: <name>’*’</name>
タグにワイルドカードを含めることはできません。次はサポートされません: <’*’>admin</’*’>

変更(オーバーライド)される要素には、ワイルドカードは使用できません。次のものはサポートされません:

               <dom:debug-jmx-core f:combine-mode='*'>'*'</dom:debug-jmx-core>
               <dom:debug-jmx-core f:combine-mode="replace">'*'</dom:debug-jmx-core>

ワイルドカードは単語全体を置換し(すべてかゼロか)、部分一致はありません。たとえば、文字列がLKSである場合、*の場合は一致しますが、L*またはLK*の場合は一致しないため、エラーが生成されます。

ワイルドカードを使用して、要素を追加または削除できます。ただし、サポートされているのはアスタリスク(*)のみであるため、追加または削除はすべてのMBeanに適用されます。たとえば、Server MBeanとともに使用する場合、このアクションによってドメイン内のすべてのサーバーが削除されます。次の例を考えてみます。

次の構成ファイル・フラグメントは、ワイルドカードを使用してドメイン内のすべてのサーバーに基本データ型およびコンテナ要素を追加する方法を示しています。

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
  xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <s:expiration> 2020-11-30T19:20+01:00 </s:expiration>
  <dom:name>sitconfigDomain</dom:name>
  <dom:server>
    <dom:name>'*'</dom:name>
    <dom:notes f:combine-mode="add">wildcard notes</dom:notes>
    <dom:server-debug>
      <dom:debug-jmx-core f:combine-mode="add">true</dom:debug-jmx-core>
    </dom:server-debug>
    <dom:cluster-weight f:combine-mode="add">49</dom:cluster-weight>
      <dom:network-access-point f:combine-mode="add">
        <dom:name>AddedNetworkAccessPoint</dom:name>
        <dom:enabled>false</dom:enabled>
        <dom:listen-port>7501</dom:listen-port>
      </dom:network-access-point>
   </dom:server>
</dom:domain>

次の構成ファイル・フラグメントは、ワイルドカードを使用してドメイン内のすべてのサーバーから基本データ型を削除する方法を示しています。

<?xml version='1.0' encoding='UTF-8'?>
<dom:domain
  xmlns:dom="http://xmlns.oracle.com/weblogic/domain"
 xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
 xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
  <s:expiration> 2020-11-30T19:20+01:00 </s:expiration>
  <dom:name>sitconfigDomain</dom:name>
  <dom:server>
    <dom:name>'*'</dom:name>
    <dom:accept-backlog f:combine-mode="delete"></dom:accept-backlog>
    <dom:server-debug>
      <dom:debug-jms-back-end f:combine-mode="delete"></dom:debug-jms-back-end>
    </dom:server-debug>
  </dom:server>
</dom:domain>

ワイルドカードのオーバーライド

ファイルの値にワイルドカードのエントリとワイルドカードではないエントリの両方がある場合、最初に一致したほうが優先されます。

たとえば:

   <dom:server> 
      <dom:name>server2</dom:name> 
       <dom:max-message-size f:combine-mode="replace">666666</dom:max-message-size>
   </dom:server>     
    <dom:server> 
       <dom:name>'*'</dom:name> 
        <dom:max-message-size f:combine-mode="replace">30000000</dom:max-message-size>
    </dom:server> 
    <dom:server> 
       <dom:name>server1</dom:name> 
        <dom:max-message-size f:combine-mode="replace">9999999</dom:max-message-size>
    </dom:server>

この例では、server2のmax-message-sizeの値は666666になりますが、server1の値は30000000になります(ファイル内で*がserver1より上にあるため)。

状況構成変更のモニター

状況構成が現在配置されているかどうかを確認するには、ServerRuntimeMBean.isInSitConfigState()メソッドを使用します。たとえば:

ServerRuntimeMBean runtimeMBean = runtimeService.getServerRuntime();
    boolean setting = runtimeMBean.isInSitConfigState();

サーバーが状況構成変更(新規、削除済または変更済のsituational-config.xmlファイル)をポーリングする頻度を制御するには、ServerMBean.setSitConfigPollInterval(int)を使用してポーリング間隔(秒単位)を構成します。

たとえば、ポーリング・レートを設定するには、次のようにします。

    DomainMBean domainMBean = domainService.getDomainConfiguration();
    ServerMBean serverMBean = domainMBean.lookupServer(adminServerName);
    serverMBean.setSitConfigPollingInterval(value);

状況構成の必要性

デフォルトでは、構成のオーバーライドを適用するかどうかは任意です。特定の状況下では、たとえば、小規模なポッド上でデフォルトの大規模なクラスタ構成を使用した起動を防止するために、構成のオーバーライドが必要な場合があります。Server MBeanのSitConfigRequired属性は、状況構成が必要かどうかを制御します。この構成属性を使用すると、オーバーライド・ファイルが適用されていないときにサーバーが起動しなくなります。デフォルトでは、サーバーは起動し、失敗しません。

/**
 * Sets whether situational config files are required. If required, then WebLogic Server will 
 * fail to boot if no situational config files are present. The default is to not require situational config files.
 * @param isRequired - true if situational config files are required, false otherwise.
 * @default false
 * @dynamic
 * @include-api for-public-api
 */
void setSitConfigRequired(boolean isRequired);
 
/**
 * Returns whether situational config files are required and WebLogic Server should fail to boot if situational config files are not present.
 * @return  true if situational config files are required, false otherwise.
 * @dynamic
 * @include-api for-public-api
 */
int isSitConfigRequired();

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

以前のリリースでは、WebLogic Serverは、一度に1つのアクティブな構成編集セッションのみをサポートしていました。システム管理者は、グローバルな編集をロックし、変更を加えた後、それをアクティブ化していました。同時に他の管理者が変更を加えることはできませんでした。しかし、WebLogic Serverでは、複数の名前付き同時編集セッションが可能になり、複数の管理者が同時に構成を変更できるようになりました。

複数の管理者がシステムの別の部分で作業する場合は、通常、同時編集セッションが便利です。また、構成コマンドをシリアルに実行することでシステムの構成に時間がかかる場合、1人の管理者が指定された複数の編集セッションを開くことができます。これは、構成編集セッションを並行して実行することで、時間を節約できます。

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

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