1 WebLogic永続ストア

この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。また、永続ストアを使用するJMSサービス・アーティファクトの高可用性を構成する方法についても説明します。

• 永続ストアとは

• 永続ストアの特長

• 高パフォーマンスのスループットとトランザクション・サポート

• ファイル・ストアとJDBC対応ストアの比較

• 永続ストアの高可用性

• 永続ストアの制限事項と考慮事項

• 高可用性ファイル・ストアの追加要件

• ファイルの場所

永続ストアとは

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。

表1-1に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するための一意の接続IDが指定されます。

表1-1 永続ストアのユーザー

サブシステム/サービス	ストアとは	参照
診断サービス	ログ・レコード、データ・イベント、収集されたメトリック	Oracle WebLogic Server診断フレームワークの構成と使用のWLDF構成の理解
JMSメッセージ	永続メッセージ、恒久サブスクライバ	『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージング・モデルの理解に関する項
JMSページング・ストア	各JMSサーバーに1つ。ページされた永続メッセージと非永続メッセージ。	Oracle WebLogic Server JMSリソースの管理の基本JMSシステム・リソースの構成の主なステップ。
JTAトランザクション・ログ(TLOG)	サーバーによって調整された、完了していない可能性のあるコミット済みトランザクションに関する情報TLOGは、デフォルトの永続ストアまたはJDBC TLOGストアに保存できます。	Oracle WebLogic Server JTAアプリケーションの開発のトランザクションの管理。 JDBC TLogストアの使用
パス・サービス	メッセージのグループからメッセージング・リソースへのマッピング	『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項
ストア・アンド・フォワード(SAF)サービス・エージェント	SAF送信エージェントからSAF受信エージェントに再転送するメッセージ	『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項
Webサービス	信頼性のあるWebLogic Webサービスの呼出しによるSOAPリクエスト・メッセージおよびレスポンス・メッセージ	『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』の信頼性のあるSOAPメッセージングの使用に関する項。
EJBタイマー・サービス	EJBタイマー・オブジェクト。	Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のEnterprise JavaBeansの理解

「ストア接続のモニター」を参照してください。

永続ストアの特長

永続ストアの主な特徴は以下のとおりです。

• 各サーバー・インスタンスのデフォルト・ファイル・ストアは構成不要です。

• すべてのサブシステムが同じサーバー・インスタンス、クラスタまたは移行可能ターゲットをターゲット指定している場合のみ、デフォルト・ストアおよびカスタム・ストアを複数のサブシステムで共有できます。

• 構成すると、JDBC TLOGストアには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報が格納されます。アプリケーションのニーズに応じて、TLOG情報をデフォルト・ストアまたはJDBC TLOGストアのどちらに保持するかを選択できます。「JDBC TLogストアの使用」を参照してください

• 高パフォーマンスのスループットとトランザクション・サポート

• パラメータを修正してカスタム・ファイル・ストアやJDBCストアを作成できる

• 永続ストアの統計情報と開いているストア接続をモニターできる

• クラスタリング環境では、サーバー全体レベルまたはサービス・レベルで、JDBC TLOGストアおよびカスタマイズしたストアを異常のあるサーバーからバックアップ・サーバーに移行できます。

• クラスタをターゲット指定している場合、永続ストアの高可用性パラメータによりJMSサービスの分散と高可用性の動作を制御します。移行可能ターゲットを構成する必要もなくなります。Oracle WebLogic Server JMSリソースの管理のJMSクラスタと高可用性の簡略化された構成を参照してください。

高パフォーマンスのスループットとトランザクション・サポート

永続ストアのパフォーマンス上の主な目標はスループットの向上です。すべてのサブシステムが同じサーバー・インスタンス、クラスタまたは移行可能ターゲットをターゲット指定している場合のみ、同じデフォルト・ストアまたはカスタム・ストアを複数のサブシステムで共有できます。

ノート:

• JDBC TLOGストアは、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持する場合にのみ使用されます。他のサブシステムによって共有できません。

• JDBC TLOGストアではHA構成設定は許可されません。

この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション・マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、TLOG、JMSとEJBのタイマーが1つのファイル・ストアを共有し、JMSメッセージとEJBタイマーが単一のトランザクションで作成された場合、そのトランザクションは1フェーズとなり、リソースの書込みは1回しか発生しません。一方、2フェーズの場合であれば、リソースごとに2回ずつで合計4回のリソース書込みが発生し、加えてトランザクション・ログでのトランザクション・エントリの書込みが1回発生することになります。

ファイル・ストアおよびJDBCストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。

ファイル・ストアとJDBC対応ストアの比較

次に、ファイル・ストアとJDBC対応ストアの類似点と相違点を挙げます。

• デフォルトの永続ストアはファイル・ストアにしかできません。したがって、JDBCストアはデフォルトの永続ストアとしては使用できません。

• どちらもトランザクションのセマンティクスと保証を備えています。JDBCストアの書込みと同様、ファイル・ストアの書込みでもディスクへの保存が保証されており、単に中間キャッシュ(つまり、安全性が保障されないキャッシュ)に保存されるわけではありません。

• どちらも同じアプリケーション・インタフェースを備えています(アプリケーション・コードに違いがありません)。

• すべての条件が同じ場合、一般的にファイル・ストアの方がJDBCストアよりスループットが高くなります。

  ノート:

  データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Serverがそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBCストアの方がパフォーマンスが良くなる場合もあります。

• 通常、ファイル・ストアの方が構成および管理が簡単であり、WebLogicのサブシステムが外部コンポーネントに依存する必要もありません。

• ファイル・ストアは、ネットワーク・トラフィックを生成しません。JDBCストアは、データベースがWebLogic Serverとは異なるマシンに存在する場合にネットワーク・トラフィックを生成します。

• JDBCストアの方が障害リカバリが容易。JDBCインタフェースが同じネットワーク上の任意のマシンからデータベースにアクセスできるからです。ファイル・ストアの場合、ディスクが共有または移行されている必要があります。

• 動的拡張性: カスタム論理永続ストアが構成されてクラスタにターゲット指定されている場合、デフォルトでは、システムは自動的に各クラスタ・メンバーに1つの物理インスタンスを作成し、そのインスタンスには監視目的で一意の名前が付けられます。これにより、ストアおよび関連JMSアーティファクトは、各クラスタ・メンバーで個別に構成する必要なく動的に拡張することができます。この動作は、システムが1つの物理インスタンスのみを作成し、それがクラスタ内で高可用になるように、変更することができます。Oracle WebLogic Server JMSリソースの管理のJMSクラスタと高可用性の簡略化された構成を参照してください。

永続ストアの高可用性

高可用性のために、WebLogic Serverは次のオプションを提供します。

• サーバー全体の移行

• 自動サービス移行

• サービスの「再起動準備完了」

• 高可用性ストレージ・ソリューション

サーバー全体の移行

永続ファイルベースのストア(デフォルトまたはカスタム)は、サーバー全体レベルの移行機能の一部としてその親サーバーとともに移行できます。この場合、サービス・レベルではなく、サーバー・レベルで自動または手動で移行できます。『Oracle WebLogic Serverクラスタの管理』の「サーバー全体の移行」を参照してください。ただし、ファイルベースのストアは、クラスタ内のすべてのサーバーからアクセスできる共有ディスク上に構成する必要があります。

自動サービス移行

ファイルベースのストアおよびJDBC対応ストアも、ストアを使用してデータを維持するJMS関連サービス(JMSサーバー、SAFエージェント、パス・サービスなど)のサービス・レベル移行の一部として移行できます。WebLogic Serverは、次の2つの方法で自動サービス移行をサポートしています。

• 簡略化されたJMSクラスタ構成の使用: これによりストアとストアを参照するすべてのJMSサービス・アーティファクトの両方に対する自動サービス移行が可能になります。構成設定はストアがクラスタに対してターゲット指定されるたびに有効になります。このモデルは、自動フェイルバック、動的ロード・バランシングおよびフェイルオーバーなどの拡張された高可用性機能を提供します。Oracle WebLogic Server JMSリソースの管理のJMSクラスタと高可用性の簡略化された構成を参照してください。

• 移行可能ターゲット構成の使用: このモデルでは、移行可能ターゲットは、関連JMSサービスのグループ化メカニズムとして機能し、グループ全体はクラスタ内の1つの物理サーバーのみでホストされます。

ノート:

自動サービス移行の場合、従来の移行可能ターゲット・モデルのかわりに、簡略化されたJMSクラスタ構成を使用します。

これらの両方のモデルでは、ホストされている関連サービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。クラスタのターゲット指定されたストアの場合、ストア・インスタンスが移行するときに、そのストア・インスタンスを参照しているすべての関連JMSサービス・インスタンスも移行されます。

このリリースでは、サービスレベル移行は、関連JMSサービス・アーティファクトとして、同じクラスタへストアをターゲット指定することで制御されます。Oracle WebLogic Server JMSリソースの管理のJMSクラスタと高可用性の簡略化された構成を参照してください。このタイプの移行はすべてのクラスタ・タイプ(構成済、動的および混在)でサポートされ、これにより移行可能ターゲット構成の必要はなくなります。このオプションは、JMSアーティファクトのサービス移行を制御するだけでなく、自動フェイルバックもサポートします。以前のリリースと同様に、関連JMSサービスを移行可能ターゲットにターゲット指定することにより、サービス・レベルの移行を有効にすることができます。移行可能ターゲットは、JMS関連サービスのグループ化として機能し、クラスタ内の1つの物理サーバーのみでホストされます。移行可能ターゲット・ベースの構成では、移行可能なターゲットによってホストされるJMSサービスは、定期的なサーバー・メンテナンスの一環としてオンデマンドで手動でも移行できます。

どちらの場合も、JMSサービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。移行が実行されると、ストアと関連付けられている、またそのサーバーによってホストされているすべての固定サービスも移行されます。

Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

クラスタまたは以降可能ターゲット・ベース・モデルでは、JMS関連サービスで、デフォルトのファイル・ストアを使用することはできません。したがって、カスタムのファイル・ストアまたはJDBCストアを構成し、関連付けたJMSサーバー、SAFエージェント、またはパス・サービスと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。

ベスト・プラクティスについては、「高可用性ファイル・ストアの追加要件」を参照してください。

サービスの「再起動準備完了」

サービスの「再起動準備完了」では、元の稼働WebLogic Serverにおいて失敗したカスタム・ストアおよびそれに依存するサービスを自動的にリカバリするオプションを提供します。その他のストア・タイプおよびメッセージング・ブリッジのサービスの再起動準備完了の詳細は、次に示す「移行との組合せでのサービスの再起動準備完了」および「その他のノート」の項を参照してください。

「再起動準備完了」が構成されておらず、有効でない場合、WebLogic Serverでは、失敗したカスタム・ストアおよびその依存するJMSサービスが異常としてマークされ、停止されます。これは、たとえば、ファイル・ストアがファイル・システムからエラーを取得した場合、またはJDBCストアがデータベースにアクセスできない場合に起こる可能性があります。ストアのシャットダウン前に保持されたメッセージは、ストアが再起動されるか、同じクラスタの別のサーバーに移行されるまで使用できません。

カスタム・ストアで「再起動準備完了」を有効にする方法は、ストアのターゲットによって異なります。

カスタム・ストアのターゲット	サービスの「再起動準備完了」オプション
スタンドアロン・サーバーまたはクラスタ	オプション1: ストア「再起動準備完了」設定を明示的に「True」に構成します。 オプション2: ストア「移行ポリシー」を「常時」または「失敗時」に設定します。これにより、「再起動準備完了」設定がデフォルトで「True」になります。 どちらのオプションの場合でも、ストア構成で「再起動準備完了」動作を「再起動間隔」(デフォルトは30)および「再起動回数」(デフォルトは6)に変更することで調整します。
移行可能なターゲット	移行可能なターゲットで「再起動準備完了」を有効にします。 移行可能ターゲット構成で「再起動間隔」(デフォルトは30)および「再起動回数」(デフォルトは6)を変更することで「再起動準備完了」動作を調整します。『Oracle WebLogic Serverクラスタの管理』の障害が発生した移行可能サービスのインプレースでの再起動に関する項を参照してください。
クラスタ内の管理対象サーバー・インスタンス	クラスタ内のサーバーに直接ターゲットされているストアで「再起動準備完了」を有効にすることはできません。ストアおよびそれに依存するサービスをクラスタまたはそのかわりに移行可能なターゲットにターゲット指定することをお薦めします。

移行との組合せによるサービスの「再起動準備完了」

サービスの「再起動準備完了」はサーバー移行全体またはサービス移行とは別に構成できます。「再起動準備完了」および移行の両方が構成されている場合、次に示すように動作します。

「再起動準備完了」および「サービスの移行」

「再起動準備完了」を有効にすると、ストアの元のホストJVMがまだ実行中で、失敗したストアがWebLogic内のあるサーバーから別のサーバーに移行するように構成されている場合、移行が試みられる前に元のホストJVM上でストアの再起動が試みられます。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

「再起動準備完了」および「サーバー全体の移行」

グローバル・スコープのストアがスタンドアロン・サーバーにターゲット指定されるか、クラスタ内のサーバーにターゲット指定されるか、クラスタにターゲット指定されて「移行ポリシー」が「オフ」の場合、ストアは再起動がすべて失敗してからホストWebLogic Serverインスタンスを失敗したヘルス状態にします。失敗したWebLogic Serverのヘルス状態によって、オプションの「サーバー全体の移行」フレームワークが問題を検出し、WebLogic Server JVMを再起動するかJVMを別のサーバーに移行します。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

その他のノート

• インプレースでのサービス再起動はWebLogicのデフォルト・ストア、トランザクション・ログ・ストアまたはメッセージング・ブリッジには適用されません。

  • デフォルト・ストアが失敗すると、サーバーは「失敗」のヘルス状態を入力し、サーバー移行全体またはサーバー再起動全体のリカバリが必要になります。重大な情報をデフォルト・ストアではなくカスタム・ストアに保持するようにサービスを構成することをお薦めします。

  • トランザクション・ログ・ストアが再起動するように調整する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・ログ・ストアの構成に関する項を参照してください。

  • 「メッセージング・ブリッジ」は「再起動準備完了」設定を無視します。かわりに、ソース宛先またはターゲット宛先への接続に失敗した時に定期的に再試行することで失敗を自動的に処理します。

• カスタムJDBCストアには、シャットダウンの前に最初に有効になる追加の内部再試行メカニズムがあり、ストアおよびそれに依存するサービスを再起動する必要があります。この機能は、簡単なデータベース停止からのサイレント・リカバリに役立ちます。「JDBCストアの再接続再試行の構成」を参照してください。

高可用性ストレージ・ソリューション

JMSサーバーまたはJTAトランザクション・ログの移行後に、リモート・マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ・ソリューションのいずれかを実装する必要があります。

• ファイル・ベース・ストア(デフォルトまたはカスタム) - デュアルポートSCSIディスクまたはストレージ領域ネットワーク(SAN)などのハードウェア・ソリューションを実装して、共有可能ディスクやリモート・マシンからもファイル・ストアを利用できるようにします。

  ノート:

  • 別のJVMまたはマシンに移行する可能性のある永続ファイル・ストアでは、明示的に共有ディレクトリを参照するように構成する必要があります。「高可用性ファイル・ストアの追加要件」を参照してください。

  • ファイル・ストアが切断されて再接続された場合、永続JMSメッセージの送受信を正常に続行するには、ホスト・サーバー・インスタンスを再起動する必要があります。たとえば、ファイル・ストアを含むファイル・システムがアンマウントされた後再びマウントされた場合、ホスト・サーバーを再起動せずに永続JMSメッセージを送信しようとするとJMS例外が生成されます。

• JDBC対応ストア - JDBCストアまたはJDBC TLOGストアを構成し、JDBCを使用してこのストアにアクセスします。このストアは、別のサーバーに存在する場合もあります。そのあと、アプリケーションでは、データベース・ベンダーによって提供されるあらゆる高可用性ソリューションまたはフェイルオーバー・ソリューションを利用できます。また、JDBCストアではGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされるため、Oracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーが可能です。詳細は、次を参照してください。

  • Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCマルチ・データ・ソースの構成

  • Oracle WebLogic Server JDBCデータ・ソースの管理のGridLinkデータ・ソースの使用

• 任意の永続ストア - WebLogic Serverベースのアプリケーション用の即時利用可能な統合ソリューションを提供する、高可用性クラスタリング・ソフトウェアを使用します。

永続ストアの制限事項と考慮事項

永続ストアには以下の制限があります:

• 永続ファイル・ストアは、2つのサーバー・インスタンスから同時に開かないでください。同時に開いた場合、ファイル内のデータが破損しないという保証はありません。可能であれば永続ストアはこの場合にエラーを戻そうとしますが、この状態を必ず検知できるとはかぎりません。管理者の責任において、複数のサーバーが同じ永続ストアに同時にアクセスを試みない環境でのみ永続ストアを使用するようにしてください。(名前とディレクトリが同じである場合、2つのファイル・ストアは「同じストア」とみなされます。)

• データが破損するので、2つのJDBCストアで同じデータベース表を共有することはできません。JDBCストアでは、通常、バッキング表がすでに別のインスタンスで開いているかどうかを検出することで共有を防止しますが、この条件をすべてのケースで検出することはできません。管理者の責任において、複数のサーバーが同じ永続ストアに同時にアクセスを試みない環境でのみ永続ストアを使用するようにしてください。(表名接頭辞およびデータベース・スキーマが同じ場合、2つのJDBCストアで同じ表を参照できます。)

• 永続ストアは、任意の破損に対応できない可能性があります。ディスク・ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが戻されたり、ストアをまったく回復できなくなったりするおそれがあります。

• ディスクが一杯になると、ファイル・ストアから例外が戻されることがあります。しかし、ディスク・スペースが使用可能になると例外をスローされなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。

• MySQLをJDBCストア用のバッキング・データベースとして使用する場合は、安全な書込み機能を備えているInnoDBエンジンの使用をお薦めします。MyISAMエンジンが使用されていると、データが失われる場合があります。

高可用性ファイル・ストアの追加要件

サービス移行またはサーバー全体の移行を通じて高可用性のために構成されたカスタムおよびデフォルトのファイル・ストアは、共有ディスクの中央に明示的にディレクトリを構成する必要があります。こうすることで、ストアがホストする可能性のあるすべてのサーバーおよびマシンで同じディレクトリとファイルが使用できるようになり、移行後にストアがデータを確実にリカバリできるようになります。

これは、デフォルトおよびカスタムのファイル・ストアの場所に適用されます。キャッシュまたはページのファイル・ディレクトリでは、高可用性が必要なく、パフォーマンスの理由からローカル・ドライブに置かれる必要があるため適用されません。

「ファイルの場所」を参照してください。

『Oracle WebLogic Server JMSリソースの管理』の移行可能なターゲットに関する項および簡略化されたJMSクラスタ構成と高可用性構成に関する項を参照してください。

ファイルの場所

永続ストアは、様々な目的のためにファイル・システムに多数のファイルを作成します。 これらのファイルには、ファイル・ストア・データ・ファイル、ファイル・ストア・キャッシュ・ファイル( DirectWriteWithCache 同期書込みポリシーが指定されたファイル・ストア用)、およびJMSサーバーとSAFエージェントのページング・ファイルがあります。

表1-2では、ドメイン・レベルでファイル・ストア・システムで使用される様々なファイルの場所を説明しています。

表1-2 ファイルの場所

ストア・タイプ	構成されないストア・パス	相対ストア・パス	絶対ストア・パス	ファイル名
default	<domainRoot>/servers/<serverName>/data/store/default	<domainRoot>/<relPath>	<absPath>	_WLS_<serverName>NNNNNN.DAT
custom file	<domainRoot>/servers/<serverName>/data/store/<storeName>	<domainRoot>/<relPath>	<absPath>	<storeName>NNNNNN.DAT
cache	${java.io.tmpdir}/WLStoreCache/${domainName}/<storeUuid>	<domainRoot>/<relPath>	<absPath>	<storeName>NNNNNN.CACHE
paging	<domainRoot>/servers/<serverName>/tmp	<domainRoot>/<relPath>	<absPath>	<jmsServerName>NNNNNN.TMP <safAgentName>NNNNNN.TMP

表1-3では、前述の各ストア・タイプがディレクトリの場所を構成する方法を示します。

表1-3 ストア・タイプのディレクトリ構成

ストア・タイプ	ディレクトリ構成
default	WebLogic Serverデフォルト・ストアに構成されたディレクトリ。「デフォルト永続ストアの使用方法」を参照してください。
custom file	カスタム・ファイル・ストアに構成されたディレクトリ。「カスタム・ファイル・ストアの使用」を参照してください。
cache	DirectWriteWithCache 同期書込みポリシーを持つカスタムまたはデフォルトのファイル・ストアに構成されたキャッシュ・ディレクトリ。『Oracle WebLogic Serverのパフォーマンスのチューニング』の「WebLogic永続ストアのチューニング」を参照してください。
paging	SAFエージェントまたはJMSサーバーに構成されたページング・ディレクトリ。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージのページングによるメモリーの解放に関する項を参照してください。