| Oracle® Fusion Middleware Oracle WebLogic Serverドメイン構成の理解 12c (12.2.1.3.0) E90324-02 |
|
 前 |
 次 |
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 Server管理コンソールでは、構成の変更管理プロセスを「チェンジ・センター」ペインに一元化しています。
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ツリーもインスタンス化しますが、これらは構成の管理には使用されません。
構成の変更を始めるには、次の手順に従います。
現在の構成でロックを取得します。
任意のツール(WebLogic Server管理コンソール、FMWC、WLST、JMX APIなど)を使用して、必要な変更を行います。
WebLogic Server管理コンソールの「保存」 ボタン、WLST saveコマンド、またはConfigurationManagerMBeanのsave操作を使用して、config.xmlファイルの保留中バージョンに変更を保存します。
構成マネージャ・サービスは、編集MBeanツリーのすべてのデータを、pendingという名前のディレクトリで、別の構成ファイルのセットとして保存します。図4-2を参照してください。
pendingディレクトリはドメインのルート・ディレクトリのすぐ下にあります。たとえば、ドメインの名前がmydomainである場合、保留中のconfig.xmlファイルのデフォルトのパス名はmydomain/pending/config.xmlになります。
さらに変更を行うか、行った変更を取り消します。
変更が済んだら、WebLogic Server管理コンソールのチェンジ・センターにある「変更のアクティブ化」ボタン、WLST activateコマンド、またはConfigurationManagerMBeanのactivate操作を使用して、変更内容をドメイン内でアクティブ化します。
変更をアクティブ化すると、次のことが行われます(図4-3を参照)。
構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスで、サーバーのルート・ディレクトリ内のconfigディレクトリに、保留中の構成ファイルをコピーします。
管理対象サーバーが管理サーバーとルート・ディレクトリを共有している場合、ConfigurationManagerMBeanは保留中の構成ファイルをコピーしません。つまり、管理対象サーバーは管理サーバーのconfigディレクトリを使用します。
各サーバー・インスタンスは、現在の構成と保留中の構成を比較します。
各サーバー内のサブシステムは、新しい構成を使用できるかどうかを表明します。
いずれかのサブシステムが変更を使用できないと表明した場合、アクティブ化プロセス全体がロールバックされ、ConfigurationManagerMBeanは例外を送出します。変更内容を修正して変更のアクティブ化を再試行するか、または、ロックを解放できます。ロックを解放した場合、編集用の構成MBeanツリーと保留中の構成ファイルは、読取り専用の構成MBeanツリーと構成ファイルの状態に戻ります。
すべてのサーバーのすべてのサブシステムで変更内容を使用できる場合、構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスにある読取り専用の構成ファイルを、保留中の構成ファイルで置き換えます。
各サーバー・インスタンスは、各Beanと読取り専用の構成MBeanツリーを、新しい構成ファイルの変更内容に従って更新します。サーバーの再起動が必要な変更が1つまたは複数ある場合、この処理はサーバーの再起動時に行われます。
保留中の構成ファイルは、pendingディレクトリから削除されます。
ロックを保持してさらに変更を行うことも、他のユーザーが構成を更新できるようにロックを解放することもできます。タイムアウト期間を構成して、構成マネージャ・サービスにロックを解放させることができます。
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サーバーを使用してドメイン構成を変更することはできません。
既存の編集セッションがあります。
以前の編集セッションの、保留中の変更が保存されていますが、まだアクティブ化されていません。
ドメインを読取り専用に設定することで、構成の変更からブロックすることができます。それには、WLSTまたは管理APIを使用して、JMXMBean構成MBeanのEditMBeanServerEnabled属性をfalseに設定します。
ドメインを読取り専用に設定すると、WebLogic Server管理コンソール、WLSTオンラインまたは管理APIを使用してその構成を変更できなくなります。ドメインを再び編集可能にするには、config.xmlファイルをテキスト・エディタで直接編集するか、WLSTオフラインを使用した後で、影響を受けるサーバーを再起動します。
ドメインの構成に対する適切なアクセス制御を確立して、適切なセキュリティ・ロールを持つユーザーのみにアクセスを制限する必要があります。WebLogic監査プロバイダまたは他の監査セキュリティ・プロバイダを使用して、Oracle WebLogic Server構成の変更に関する監査情報を記録することもできます。Oracle WebLogic Serverセキュリティの管理の構成監査の有効化を参照してください。
一時的な構成のオーバーライドにより、管理者はXMLファイルに含まれている構成情報を既知の場所に格納します。そこで実行中のサーバーがその構成情報を識別し、ロードして、既存の構成のアスペクトをオーバーライドします。
クラウド・プラットフォームなどにおける大きいクラスタまたは複雑な分散環境では、ネットワーク、ソフトウェアおよびスケーリングの問題により、構成プロパティの設定および削除は困難な作業です。この状況は、サーバーを管理対象サーバーの独立モード(MSI)モードで実行する必要がある場合に発生します。一時的な構成のオーバーライド(状況構成とも呼ばれます)を使用すると、サーバーのデバッグ・フラグ、タイムアウト値または診断設定などの設定を、管理サーバーを実行せずに変更できます。
状況構成では、実行中のWebLogic Serverインスタンスに追加してから削除する必要がある構成変更(オーバーライド)を含むファイルを格納します。構成変更が必要以上に長い間持続しないようにするために、オーバーライドには有効期限があります。
構成のオーバーライドは管理対象サーバーを対象にしていますが、管理サーバーにも適用できます。管理サーバーと管理対象サーバー間は同期されません。一時的な構成のオーバーライドでは、構成情報を管理対象サーバーに配布するための主な手段として、管理サーバーをバイパスします。
状況構成は、次のようになります。
一時的な構成変更を実行中のシステムに適用します。格納されている構成には影響しません。
変更する値とコンテキスト情報を含むファイルでXMLフラグメントを使用します。このファイルは、config.xmlファイルからの構成情報を更新するためにのみ使用されます。
動的属性のみを更新できます。状況構成XMLファイルには、任意の動的属性を設定できます。
構成のオーバーライドには有効期限が必要です。XMLファイルが削除、名前変更または有効期限切れになると、オーバーライドは元に戻されます。
管理サーバーの関与を必要とせず、管理対象サーバーはどのような方法であってもその値を同期しません。
状況構成によって現在オーバーライドされている値が編集セッションで変更された場合、その変更は、状況構成のオーバーライドが削除されるまで有効になりません。状況構成では、適用または有効期限切れになったとき、および削除されたときに、サーバーのログにメッセージが記録されます。
状況構成ファイルは、接尾辞situational-config.xmlで終わり、新しいoptconfigディレクトリに格納されるドメイン構成ファイルのみです。optconfigディレクトリにあるsituational-config.xmlファイルは、管理者が作成、更新および削除します。
ドメインが別のシステムにある場合は、状況構成XMLファイルを各optconfigディレクトリにコピーする必要があります。
状況構成ファイルには、変更対象の構成の構造を参照するXMLフラグメントが含まれています。たとえば、config.mlでこのサーバーのデバッグ構成を変更するには、次のようにします。
<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> 2017-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フラグメントで参照される必要があります。次の例に示すように、値を置換(オーバーライド)するには、構文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> 2016-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>
situational-config.xsdスキーマを参照して有効期限要素を設定し、XMLフラグメントに明示的な有効期限を設定する必要があります。有効期限は、long (システム時間)またはW3C準拠の文字列です。
<s:expiration> 2017-11-29T10:24-08:00 </s:expiration>
11/29/2017 @ 10:24 am (PDT)
<s:expiration> 2017-11-29T10:24 </s:expiration>
11/29/2017 @ 10:24 am (local timezone)
<s:expiration> 2017-11-29T10:24:15 </s:expiration>
11/29/2017 @ 10:24:15 am (local timezone)
状況構成の値は、ファイルが削除されるかシステム時間が有効期限切れになるまでの間、配置されます。その後、ファイルとその値はアンロードされ、設定は以前の値に戻されます。
状況構成ファイルに現在時刻よりも早いタイムアウト値が指定されている場合(ファイルが有効期限切れになっている場合)、ファイルの内容は無視されます。
状況構成ファイルは、サーバーが起動したときに終了します。状況構成は、構成階層ではなく実行時階層にロードされます。管理者は、実行時ツリーを参照することにより、有効な構成(ベース構成と状況構成のオーバーライド)を確認できます。構成編集ツリーには、状況構成が適用される前または状況構成が削除された後のベース値のみが表示されます。
各状況構成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*の場合は一致しないためエラーが生成されます。
ワイルドカードのオーバーライド
ファイルの値にワイルドカードのエントリとワイルドカードではないエントリの両方がある場合、最初に一致したほうが優先されます。
次に例を示します。
<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);
以前のリリースでは、WebLogic Serverは、一度に1つのアクティブな構成編集セッションのみをサポートしていました。システム管理者は、グローバルな編集をロックし、変更を加えた後、それをアクティブ化していました。同時に他の管理者が変更を加えることはできませんでした。しかし、WebLogic Serverでは、複数の名前付き同時編集セッションが可能になり、複数の管理者が同時に構成を変更できるようになりました。
複数の管理者がシステムの別の部分で作業する場合は、通常、同時編集セッションが便利です。また、構成コマンドをシリアルに実行することでシステムの構成に時間がかかる場合、1人の管理者が指定された複数の編集セッションを開くことができます。これは、構成編集セッションを並行して実行することで、時間を節約できます。
マルチテナント環境では、複数の管理者が同時に構成変更をする必要があります。マルチテナントWebLogicドメインには複数のパーティションがあり、それぞれに独自の管理者がいます。パーティション管理者は、他のパーティションの管理者やWebLogicのシステム管理者に影響を与えることなく、自分のパーティションに対する構成変更およびそこにデプロイされているリソースを変更できる必要があります。複数の、指定された並行編集セッションはパーティションごとの1つ以上の構成編集セッションに加えて、グローバル構成編集セッションをサポートします。
『WebLogic Server Multitenantの使用』の名前が付いた同時編集セッションの管理に関する項を参照してください。
