Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.2.1) E72527-01 |
|
前 |
次 |
この章では、障害回復(DR)ソリューションの一部としての、物理的サイト全体にわたるWebLogicドメインのXAトランザクション・リカバリのベスト・プラクティスを紹介します。
この章には次の項が含まれます:
可用性を最大限に高め、予期しない障害および天災から保護することは、エンタープライズ・デプロイメントの障害回復ソリューションの主要な要件です。障害回復ソリューションの1つの特徴は、本番サイトを利用できなくなった場合に、影響を受けたWebLogicドメインのすべてのXAトランザクションを必ずリカバリできるようにすることです。トランザクションのリカバリのために、次のソリューションが提供されています。
アクティブ・アクティブ型: アクティブ・アクティブ型リカバリのソリューションでは、1つ以上のサーバー、ドメイン全体またはサイト全体で障害が発生した場合、トランザクションはアクティブな1つのサーバーまたは同一サイトまたは異なるサイトに配置された別のドメインの複数のサーバーによりリカバリできます。詳細は、「アクティブ・アクティブ型XAトランザクション・リカバリ」を参照してください。
注意: トランザクション・リカバリは、ドメイン全体で実行されますが、同一ドメインのクラスタ間では実行されません。 |
アクティブ・パッシブ型: これらのソリューションには、アクティブな(本番)サイトとは地理的に異なる位置で、スタンバイ・サイトを設定してペアにする作業が含まれます。スタンバイ・サイトは通常はパッシブ・モードであり、本番サイトを利用できない場合に起動されます。詳細は、「アクティブ・パッシブ型XAトランザクション・リカバリ」を参照してください。
アクティブ・アクティブ型ストレッチ・クラスタ: このアーキテクチャでは、クラスタは2つのサイトにまたがります。サイトをまたいだトランザクション・リカバリは、サービスまたはサーバーの移行により実施されます。詳細は、「アクティブ・アクティブ型ストレッチ・クラスタXAトランザクション・リカバリ」を参照してください。
注意: WebLogic Server JMSリソースが登録されたトランザクションは、これらのリカバリのソリューションのいずれを使用してもリカバリできません。 |
エンタープライズ・デプロイメントの障害回復ソリューションの詳細は、『Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド』の障害回復の概要に関する項を参照してください。次の項では、障害が発生した本番ドメインからXAトランザクションをリカバリするための要件とガイドラインを説明します。
アクティブ・アクティブ型リカバリのソリューションは、2つ以上のアクティブなドメイン構成があり、スケーラビリティと可用性を高めるために使用されます。この項では、アクティブ・アクティブ型リカバリのソリューションのためのXAトランザクションのドメイン構成および要件について説明します。この項の内容は、次のとおりです。
クロス・ドメインXAトランザクション・リカバリ機能は、site-name
およびrecovery-site-name
属性を設定して動的に有効化できます。詳細は、「クロス・ドメインXAトランザクション・リカバリのMBean属性の構成」を参照してください。また、クロス・ドメイン・リカバリ機能は、ドメインおよびサイトの両方が起動した後にアクティブ化する必要があります。
注意: site-name 属性は、recovery-site-name と同時に、またはサーバーの起動より前に設定できます。 |
この項では、アクティブ・アクティブ型のストレッチ・クラスタの障害回復ソリューションにおいて、本番サイトで障害が発生した後にXAトランザクションのリカバリを成功させるために必要な構成要件を説明します。
別々のデータ・センターにあるすべてのドメインの構成は同一で、同一のドメイン、サーバーおよびリソース名を持ちます。
ホスト名のみ(静的IPではなく)を使用して、管理対象サーバーのリスナー・アドレスを指定する必要があります。これらのホスト名の構成は、すべてのサイトで同一である必要があります。サイト間でホスト名は同一で、IPは同一ではないため、同じように構成されたサーバーまたはドメインをリカバリ・サイトで単純に開始する動的な機能がホスト名により提供されます。
TLogを格納するために、JDBC TLog、LLRまたは決定子リソースを使用できます。JDBC TLogは、すべてのWebLogic Serverへの共通の記憶域の場所としてデータベースを使用し、通常は、高可用性を確保するためにDataGuardまたはActive DataGuardを使用してレプリケートされます。LLRまたは決定子リソースを使用してトランザクション・ログをソートする場合も、非トランザクション・チェックポイントのためにJDBC TLogを構成する必要があります。
JDBC TLog表名では、形式[SITENAME] + "_" + [SERVERNAME] + "_WLSTORE"を使用し、名前を大文字で記述する必要があります。たとえば、SITE1_MS1_WLSTOREです。
注意: Oracleデータベースでは、表名の長さは30文字を超えることはできません。従って、TLog表名でOracleデータベースを使用する場合、SITENAMEおよびSERVERNAMEを選択すると、表名の長さが30文字よりも小さくなります。 |
トランザクション・ストア名は、ドメインのSiteNameに対応する接頭辞を使用する必要があります。SiteName属性の詳細は、「クロス・ドメインXAトランザクション・リカバリのMBean属性の構成」を参照してください。
TLogデータベースの他の表で、SiteNameまたはRecoverySiteNameを表名の接頭辞として使用できません。
WebLogic JMSは、このリカバリのソリューションでサポートされません。
Databaseリースを使用する場合、各サイトで異なるリース表を使用する必要があります。つまり、リース表はドメインまたはサイト通じて共有することはできません。
アクティブ・アクティブ型リカバリは、WebLogic MTパーティションでサポートされます。詳細は、『WebLogic Server MTの使用』のトランザクションの構成に関する項を参照してください。
Maximum Availability Architecture (MAA)では、異なる2つのサイト上にあるドメイン内のサーバーにトランザクションがまたがるのは、ベスト・プラクティスではありません。
この項では、トランザクションがドメインにまたがる場合のXAリカバリの制限について説明します。これは、トランザクションがあるドメインで起動し、トランザクションの範囲内の別のドメインにコールする場合です。
トランザクションに関係するドメインのすべてでフェイルオーバーする場合(たとえば、中間層またはサイトの障害)、トランザクションに関係するドメインのすべてがリカバリ・サイトにフェイルオーバーしまし。
トランザクションに関係する1つ以上のドメインで障害が発生したが、すべてのドメインではない場合、障害が発生していないドメインを手動でシャットダウンすると、リカバリ・サイトのすべてのドメインがトランザクション・リカバリで使用可能になります。
アクティブ・アクティブ型トポロジ構成は、WLSTスクリプト、REST、Fusion Middleware Controlまたは管理コンソールを使用して、両方のサイトで同一にしておく必要があります同一のドメイン名、サーバー名およびリソース名を両方のサイトで構成する必要があります。SiteName
およびRecoverySiteName
などのパラメータは、各サイトのドメインで別々に構成する必要があります。詳細は、「クロス・ドメインXAトランザクション・リカバリのMBean属性の構成」を参照してください。
クロス・ドメインXAリカバリのシナリオでは、クラッシュ後にサーバーが再起動した場合、サーバーのストアが別ドメインのリカバリしたサーバーに引き継がれる可能性があります。このような場合、weblogic.store.io.jdbc.OwnershipException
がスローされ、サーバーの起動を防止します。引き継がれたサーバーは、最終的にストア・ロックを解除し、元のサーバーはそれを取得して起動できます。
ただし、サーバーでストアを取得して効率的に再起動するには、次の構成プロパティをチューニングしてタイミングを調整する必要があります。
ノード・マネージャstartup.properties
ファイルの次のプロパティ:
RestartMax RestartDelaySeconds
これらの起動プロパティの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のサーバー起動プロパティの設定に関する項を参照してください。
ドメインのcross-domain-recovery-retry-interval
設定。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「ドメイン: 構成: JTA」を参照してください。
注意: 一定の時間の間隔の後に、サーバーの起動が失敗する場合、RestartMax 値を大きく必要があります。weblogic.store.io.jdbc.OwnershipException が正常な間隔を超えて発生し続ける場合、RestartDelaySeconds 値を小さくする(推奨する値は0/即時)またはcross-domain-recovery-retry-interval 値を大きくする、あるいはその両方を実行します。 |
この項では、アクティブ・アクティブ型リカバリのソリューションの例を示します。
この例では、アプリケーション・セッション・レプリケーション、ファイル・システム・レプリケーションおよびデータベース・レプリケーションが、2つのサイト間で実施されます。Site1で稼働中のアプリケーションが、トランザクションを開始します。それがコミットをコールした後、次のような障害シナリオが発生する可能性があります。
Site1上のアプリケーション・インフラストラクチャ層(WebLogicドメインを含む)で障害が発生しますが、データベース層はクラッシュしていません。
この障害シナリオでは、Site2上のWebLogicドメインのサーバーが、Site1上のデータベースのTLogを障害の発生したサーバーに引き継ぎ、すべてのトランザクションがリカバリされます。
Site1上のアプリケーション・インフラストラクチャ層(WebLogicドメインを含む)で障害が発生し、データベース層はクラッシュします。
この障害シナリオでは、Site2上のWebLogicドメインのサーバーが、Site2上のデータベースのTLogを障害の発生したサーバーに引き継ぎ、すべてのトランザクションがリカバリされます。
Site1上のWebLogicドメインの1つのサーバーで障害が発生します。サービスまたはサーバーの移行が構成されると、高い可能性でトランザクションは移行によってリカバリします。2つのサイト間のレイテンシのため、Site2上のWebLogicドメインのいずれかのサーバーは、障害が発生したサーバーのリカバリの引き継ぎにより長く時間がかかります。
トランザクションが、2つのドメイン、Site1上のDomain1およびDomain2にまたがっています。Domain1のサーバーは、トランザクション・コーディネータです。Site1上のDomain1のみで障害が発生します。
このシナリオでは、Site2上のDomain1のサーバーが、Site1上のデータベースのTLogを引き継ぎます。トランザクションがリカバリされると、Site1上のDomain2は、Site1上のDomain1へのコミット・コールを認識できず、トランザクションはリカバリされません。フェイルバックが適切な時間に実行されない場合、トランザクション・リカバリのために、トランザクションに関係するドメインすべてをシャットダウンし、再起動する必要があります。
表6-1では、クロス・ドメインXAトランザクション・リカバリのために構成する必要があるDomainMBean属性について説明します。
これらのMBeanの詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。
表6-1 クロス・ドメインXAトランザクション・リカバリのDomainMBean属性
属性 | 値 |
---|---|
SiteName |
ドメインが所属するサイトに与えられた名前。この属性は、JTAMBeanのRecoverySiteName属性に関連して使用されます。「クロス・ドメインXAトランザクション・リカバリのJTAMBean属性」を参照してください。 たとえば、2つのサイトをトランザクション・リカバリに構成する場合、1つはSiteNameを"site1"として、RecoverySiteNameを"site2"として構成されます。2つめのサイトは、SiteNameを"site2"として、RecoverySiteNameを"site1"として構成されます。この方法では、サイトは互いのトランザクションをリカバリするように構成され、アクティブ・アクティブ型可用性を提供します。 |
表6-2では、クロス・ドメインXAトランザクション・リカバリのために構成する必要があるJTAMBean
およびJTAClusterMBean
属性について説明します。
表6-2 クロス・ドメインXAトランザクション・リカバリのJTAMBean属性
属性 | 値 |
---|---|
RecoverySiteName |
ドメインがリカバリするサイトの名前。これは、リカバリされたサイトがSiteNameとして構成された値です。RecoverySiteNameがnullの場合、クロス・ドメインXAトランザクション機能は無効です。このMBean値は、動的に変更できます。 「クロス・ドメインXAトランザクション・リカバリのDomainMBean属性」を参照してください。 |
この項では、アクティブ・パッシブ型リカバリのソリューションのためのXAトランザクションのドメイン構成および要件について説明します。
この項では、アクティブ・パッシブ型の障害回復ソリューションにおいて、本番サイトで障害が発生した後にXAトランザクションのリカバリを成功させるために必要な条件と構成要件を説明します。
アクティブ・パッシブ型のすべてのドメイン・ペアが対称トポロジで構成されており、それらのペアがまったく同じで、同一のドメイン構成となっていること。
フェイルオーバーのタイミングを手動で制御すること。Oracle Enterprise Manager Cloud Controlは、複数のデータ・センターにわたるWebLogic Serverドメインの障害回復を管理できるようにする手段の1つです。
実行時およびリカバリ時に一貫した処理能力を実現するために、実行時のアクティブ・パッシブ型サイトでの最大処理能力よりも負荷を少なく保つこと。
ホスト名のみ(静的IPではなく)を使用して、管理対象サーバーのリスナー・アドレスを指定する必要があります。これらのホスト名の構成は、すべてのサイトで同一である必要があります。サイト間でホスト名は同一で、IPは同一ではないため、同じように構成されたサーバーまたはドメインをリカバリ・サイトで単純に開始する動的な機能がホスト名により提供されます。
パッシブ・ドメイン内のサーバーを起動してトランザクション・リカバリ・サービスを開始する前に、パッシブなデータ・センター内のマシンにDNS名を指定するようDNSサーバーを更新します。
例: アクティブなドメインDomain1には、Mc1とMc2という2台のマシン上で稼働している2つの管理対象サーバーがあります。ドメイン構成において、対応するDNS名としてdns-1およびdns-2を使用します。アクティブなドメインに障害が発生して、対応するパッシブ・ドメインをアクティブにする場合、DNSサーバーを更新してMc3およびMc4にそれぞれdns-1およびdns-2を指定するよう構成を変更します。その後、パッシブのDomain2を起動します。
DNS名にはアンダースコアを使用しないでください。WebLogic Serverドメインでは、そのようなDNS名は無効です。ダッシュが使用されているDNS名は有効です。
TLogの格納先として選択できるのは、デフォルト・ストア、JDBC TLog、LLRおよび決定子リソースです。デフォルト・ストアは、共通領域(通常はNFSまたはSAN)に存在する必要があります。JDBC TLogは、すべてのWLSサーバーへの共通の記憶域の場所としてデータベースを使用し、通常は、高可用性を確保するためにDataGuardまたはActive DataGuardを使用してレプリケートされます。可能な場合、決定子リソースを使用し、XAトランザクションTLog書込みを除去します(「トランザクションTLog書込みなしのXAトランザクション」を参照)。
クラスタ内でのトランザクション・サービスの移行は、対応するドメインおよびサーバーを含むクラスタ全体がリカバリ・サイトにフェイルオーバーされる場合のみサポートされます。具体的には、管理者は、ノード・マネージャとクラスタ全体、対応するドメイン、および影響を受けたすべてのサーバーが障害が発生したサイト上で停止されていることを確認してから、リカバリ・サイト上でそれらすべてを起動する必要があります。
複数のWebLogicドメインにわたるトランザクションは、そのトランザクションに関与するすべてのドメインがフェイルオーバーされる場合にのみ、サイトのフェイルオーバーでリカバリできます。
ドメイン情報は、ドメイン構成の同期が必ず確保されるよう、共有場所で保持されます。アプリケーションは、同期が必ず確保されるよう、共有場所で保持されます。
注意: 構成の同期を確保するためのもう1つの手法として、圧縮と解凍を使用することもできます。 |
エンタープライズ・デプロイメントのアクティブおよびパッシブのリカバリ・サイトの設定の条件および要件の詳細は、『Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド』の障害回復サイトの設定と管理に関する項を参照してください。
アクティブ・パッシブ型のすべてのドメイン・ペアが対称トポロジで構成されており、それらのペアがまったく同じで、同一のドメイン構成となっていること。アクティブ・パッシブ型アーキテクチャのフェイルオーバー処理は、手動により、または外部ツールに制御されて実施されます。
Site1で稼働中のアプリケーションが、トランザクションを開始します。それがコミットをコールした後、アプリケーション・インフラストラクチャ層全体がこの例では、アプリケーション・セッション・レプリケーション、ファイル・システム・レプリケーションおよびデータベース・レプリケーションが、2つのサイト間で実施されます。
WebLogic Server層全体がしない場合、すべてのサーバーをシャットダウンする必要があり、パッシブ・ドメインのすべての同一のサーバーを起動する必要があります。ドメイン、クラスタ、サーバーおよびリソースの名前はすべて同一であるため、サーバーが起動した直後、リカバリが実行され、すべてのトランザクションがリカバリされます。操作が排出できるように、すべてのサーバーで正常停止を実行することをお薦めします。
このアーキテクチャでは、WebLogic Serverクラスタは2つのサイトにまたがります。クラスタのサーバーで障害が発生した場合、サーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。チェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。チェックポイントはトランザクションの早い段階で作成されるため、グローバル・トランザクションで参加者に変更がないかぎり、トランザクション・サービスの移行中や複数サイトまたはデータ・センターにわたるトランザクション・リカバリ中にチェックポイントが同期しなくなる危険はほとんどありません。クラスタの別のサーバーは、サービスまたはサーバー移行を使用してトランザクション・リカバリを引き継ぐことができます。この種類のアーキテクチャは、サイト間で低いレイテンシを必要とします。詳細は、『Oracle WebLogic Serverクラスタの管理』のマルチキャストおよびクラスタ構成に関する項を参照してください。
この項では、アクティブ・アクティブ型ストレッチ・クラスタ・リカバリのソリューションのためのXAトランザクションのドメイン構成および要件について説明します。
この項では、アクティブ・アクティブ型のストレッチ・クラスタの障害回復ソリューションにおいて、本番サイトで障害が発生した後にXAトランザクションのリカバリを成功させるために必要な条件と構成要件を説明します。
このアーキテクチャは、XAトランザクション・リカバリでサービスまたはサーバー移行を使用するため、要件は、サーバー移行に必要な条件と同様です。「サーバー移行」を参照してください。
加えて、ネットワークが次の要件を満たす必要があります。
IPマルチキャスト・パケットの伝播の完全サポート。つまり、すべてのルーターおよびその他のトンネリング技術がマルチキャスト・メッセージをクラスタ化されているサーバー・インスタンスに伝播するように構成されている必要があります。
大半のマルチキャスト・メッセージがその最終的な宛先に約10ミリ秒以内に到達することを保証する、低いネットワーク待機時間。
マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないことを保証する、クラスタのマルチキャストTTL (Time-To-Live: 存続時間)の高い値。マルチキャストTTLパラメータの設定手順については、「マルチキャスト存続時間(TTL)を構成する」を参照してください。
要件の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタがWAN内の複数のサブネットにまたがる場合に関する項を参照してください。
アクティブ・アクティブ型ストレッチ・クラスタ・リカバリのソリューションで、トランザクション・リカバリのためにJTAサービスまたはサーバー移行を使用します。このアーキテクチャは、サイト間のレイテンシが低い場合にお薦めします。
この例では、Site1で稼働中のアプリケーションが、トランザクションを開始します。それがコミットをコールした後、Site1上の1つ以上のサーバーで障害が発生します。サービスまたはサーバー移行が構成された場合、Site2 (ストレッチ・クラスタ内)の正常なサーバーは障害が発生したサーバーのリカバリを引き継ぎます。
オラクル社では、最大限の可用性を実現する環境の構成方法についての追加情報を提供する、多数のリソースを用意しています。次を参照してください。