| Oracle® Fusion Middleware WebLogic永続ストアの管理 12c (12.2.1.1.0) E77381-01 |
|
 前 |
 次 |
永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。
表2-1に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するための一意の接続IDが指定されます。
表2-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 JMSリソースの管理』のWebLogicパス・サービスの使用に関する項 |
ストア・アンド・フォワード(SAF)サービス・エージェント |
SAF送信エージェントからSAF受信エージェントに再転送するメッセージ |
『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項 |
Webサービス |
信頼性のあるWebLogic Webサービスの呼出しによるSOAPリクエスト・メッセージおよびレスポンス・メッセージ |
の信頼性のあるSOAPメッセージングの使用に関する項 |
EJBタイマー・サービス |
EJBタイマー・オブジェクト。 |
『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEnterprise JavaBeansの理解に関する項 |
ストアの接続IDの詳細は、「ストア接続のモニター」を参照してください。
永続ストアの主な特徴は以下のとおりです。
各サーバー・インスタンスのデフォルト・ファイル・ストアは構成不要です。
すべてのサブシステムが同じサーバー・インスタンス、クラスタまたは移行可能ターゲットをターゲット指定している場合のみ、デフォルト・ストアおよびカスタム・ストアを複数のサブシステムで共有できます。
構成すると、JDBC TLOGストアには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報が格納されます。アプリケーションのニーズに応じて、TLOG情報をデフォルト・ストアまたはJDBC TLOGストアのどちらに保持するかを選択できます。「JDBC TLogストアの使用」を参照してください
高パフォーマンスのスループットとトランザクション・サポート
パラメータを修正してカスタム・ファイル・ストアやJDBCストアを作成できる
永続ストアの統計情報と開いているストア接続をモニターできる
クラスタリング環境では、サーバー全体レベルまたはサービス・レベルで、JDBC TLOGストアおよびカスタマイズしたストアを異常のあるサーバーからバックアップ・サーバーに移行できます。
クラスタをターゲット指定している場合、永続ストアの高可用性パラメータによりJMSサービスの分散と高可用性の動作を制御します。移行可能ターゲットを構成する必要もなくなります。詳細は、『Oracle Fusion Middleware 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ストアよりスループットが高くなります。
注意:
データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Serverがそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBCストアの方がパフォーマンスが良くなる場合もあります。
通常、ファイル・ストアの方が構成および管理が簡単であり、WebLogicのサブシステムが外部コンポーネントに依存する必要もありません。
ファイル・ストアは、ネットワーク・トラフィックを生成しません。JDBCストアは、データベースがWebLogic Serverとは異なるマシンに存在する場合にネットワーク・トラフィックを生成します。
JDBCストアの方が障害リカバリが容易。JDBCインタフェースが同じネットワーク上の任意のマシンからデータベースにアクセスできるからです。ファイル・ストアの場合、ディスクが共有または移行されている必要があります。
動的拡張性: カスタム論理永続ストアが構成されてクラスタにターゲット指定されている場合、デフォルトでは、システムは自動的に各クラスタ・メンバーに1つの物理インスタンスを作成し、そのインスタンスには監視目的で一意の名前が付けられます。これにより、ストアおよび関連JMSアーティファクトは、各クラスタ・メンバーで個別に構成する必要なく動的に拡張することができます。この動作は、システムが1つの物理インスタンスのみを作成し、それがクラスタ内で高可用になるように、変更することができます。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。
永続ファイルベースのストア(デフォルトまたはカスタム)は、サーバー全体レベルの移行機能の一部としてその親サーバーとともに移行できます。この場合、サービス・レベルではなく、サーバー・レベルで自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。ただし、ファイルベースのストアは、クラスタ内のすべてのサーバーからアクセスできる共有ディスク上に構成する必要があります。
ファイルベースのストアおよびJDBC対応ストアも、ストアを使用してデータを維持するJMS関連サービス(JMSサーバー、SAFエージェント、パス・サービスなど)のサービス・レベル移行の一部として移行できます。WebLogic Serverは、次の2つの方法で自動サービス移行をサポートしています。
簡略化されたJMSクラスタ構成の使用: これによりストアとストアを参照するすべてのJMSサービス・アーティファクトの両方に対する自動サービス移行が可能になります。構成設定はストアがクラスタに対してターゲット指定されるたびに有効になります。このモデルは、自動フェイルバック、動的ロード・バランシングおよびフェイルオーバーなどの拡張された高可用性機能を提供します。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。
移行可能ターゲット構成の使用: このモデルでは、移行可能ターゲットは、関連JMSサービスのグループ化メカニズムとして機能し、グループ全体はクラスタ内の1つの物理サーバーのみでホストされます。
注意:
自動サービス移行の場合、従来の移行可能ターゲット・モデルのかわりに、簡略化されたJMSクラスタ構成を使用します。
これらの両方のモデルでは、ホストされている関連サービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。クラスタのターゲット指定されたストアの場合、ストア・インスタンスが移行するときに、そのストア・インスタンスを参照しているすべての関連JMSサービス・インスタンスも移行されます。
このリリースでは、サービスレベル移行は、関連JMSサービス・アーティファクトとして、同じクラスタへストアをターゲット指定することで制御されます。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。このタイプの移行はすべてのクラスタ・タイプ(構成済、動的および混在)でサポートされ、これにより移行可能ターゲット構成の必要はなくなります。このオプションは、JMSアーティファクトのサービス移行を制御するだけでなく、自動フェイルバックもサポートします。以前のリリースと同様に、関連JMSサービスを移行可能ターゲットにターゲット指定することにより、サービス・レベルの移行を有効にすることができます。移行可能ターゲットは、JMS関連サービスのグループ化として機能し、クラスタ内の1つの物理サーバーのみでホストされます。移行可能ターゲット・ベースの構成では、移行可能なターゲットによってホストされるJMSサービスは、定期的なサーバー・メンテナンスの一環としてオンデマンドで手動でも移行できます。
どちらの場合も、JMSサービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。移行が実行されると、ストアと関連付けられている、またそのサーバーによってホストされているすべての固定サービスも移行されます。
サービス・レベルの移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。
クラスタまたは以降可能ターゲット・ベース・モデルでは、JMS関連サービスで、デフォルトのファイル・ストアを使用することはできません。したがって、カスタムのファイル・ストアまたはJDBCストアを構成し、関連付けたJMSサーバー、SAFエージェント、またはパス・サービスと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。
ベスト・プラクティスについては、「永続ストアの高可用性を有効にする場合の追加要件」を参照してください。
JMSサーバーまたはJTAトランザクション・ログの移行後に、リモート・マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ・ソリューションのいずれかを実装する必要があります。
ファイル・ベース・ストア(デフォルトまたはカスタム) - デュアルポートSCSIディスクまたはストレージ領域ネットワーク(SAN)などのハードウェア・ソリューションを実装して、共有可能ディスクやリモート・マシンからもファイル・ストアを利用できるようにします。
注意:
ファイル・ストアが切断されて再接続された場合、永続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ストアで同じデータベース表を共有することはできません。
永続ストアは、任意の破損に対応できない可能性があります。ディスク・ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが戻されたり、ストアをまったく回復できなくなったりするおそれがあります。
ディスクが一杯になると、ファイル・ストアから例外が戻されることがあります。しかし、ディスク・スペースが使用可能になると例外をスローされなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。
MySQLをJDBCストア用のバッキング・データベースとして使用する場合は、安全な書込み機能を備えているInnoDBエンジンの使用をお薦めします。MyISAMエンジンが使用されていると、データが失われる場合があります。
