| Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.2.1.3.0) E90356-04 |
|
 前 |
 次 |
可用性を最大限に高め、予期しない障害および天災から保護することは、エンタープライズ・デプロイメントの障害回復ソリューションの主要な要件です。障害回復ソリューションの1つの特徴は、本番サイトを利用できなくなった場合に、影響を受けたWebLogicドメインのすべてのXAトランザクションを必ずリカバリできるようにすることです。
アクティブ・アクティブ型: アクティブ・アクティブ型リカバリのソリューションでは、サイトのクラスタのすべてのサーバーで障害が発生した場合、トランザクションは、同一サイトまたは異なるサイトに配置された別のドメインのアクティブなサーバーによりリカバリできます。「アクティブ・アクティブ型XAトランザクション・リカバリ」を参照してください。
注意:
トランザクション・リカバリは、ドメイン全体で実行されますが、同一ドメインのクラスタ間では実行されません。アクティブ・パッシブ型: これらのソリューションには、アクティブな(本番)サイトとは地理的に異なる位置で、スタンバイ・サイトを設定してペアにする作業が含まれます。スタンバイ・サイトは通常はパッシブ・モードであり、本番サイトを利用できない場合に起動されます。「アクティブ・パッシブ型XAトランザクション・リカバリ」を参照してください。
アクティブ・アクティブ型ストレッチ・クラスタ: このアーキテクチャでは、クラスタは2つのサイトにまたがります。サイトをまたいだトランザクション・リカバリは、サービスまたはサーバーの移行により実施されます。「アクティブ・アクティブ型ストレッチ・クラスタXAトランザクション・リカバリ」を参照してください。
注意:
WebLogic Server JMSリソースが登録されたトランザクションは、アクティブ・アクティブ型リカバリのソリューションでリカバリできません。アクティブ・アクティブ型リカバリのソリューションは、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を構成する必要があります。
トランザクション・ストア名は、ドメインのSiteNameに対応する接頭辞を使用する必要があります。SiteName属性の詳細は、「クロスサイトXAトランザクション・リカバリのMBean属性の構成」を参照してください。
クロスサイトXAトランザクション・リカバリのソリューションでは、エラーが発生した場合にストア所有権の譲渡を決定するために、リース・フレームワークを使用します。リース設計は、クラスタ内でのTRS (トランザクション・リカバリ・サービス)移行のデータベース・リースの既存のモデルに従います。このモデルでは、複数のサーバーが同じリースの回復を試行することがないように、サーバーは書込みロックを使用してリースの取得を試行します。サイトごとの表が[site-name]SITELEASINGという命名規則で作成されます
注意:
クロスサイトXAトランザクション・リカバリと、データベース・リースがあるサーバー移行の両方が構成されている場合、DBリースと新規サイト・リースの2つの個別の表が存在します。
XAデータ・ソースでは、データベースに接続してサイト・リース表を更新することはできません。
WebLogic JMSは、このリカバリのソリューションでサポートされません。
各サイトは、クロスサイト・トランザクション・リカバリのための独自のリース表を持ちます。
アクティブ・アクティブ型リカバリは、WebLogic MTパーティションでサポートされます。『WebLogic Server MTの使用』の「トランザクションの構成」を参照してください。
Maximum Availability Architecture (MAA)では、異なる2つのサイト上にあるドメイン内のサーバーにトランザクションがまたがるのは、ベスト・プラクティスではありません。
この項では、トランザクションがドメインにまたがる場合のXAリカバリの制限について説明します。これは、トランザクションがあるドメインで起動し、トランザクションの範囲内の別のドメインにコールする場合です。
トランザクションに関係するドメインのすべてでフェイルオーバーする場合(たとえば、中間層またはサイトの障害)、トランザクションに関係するドメインのすべてがリカバリ・サイトにフェイルオーバーしまし。
トランザクションに関係する1つ以上のドメインで障害が発生したが、すべてのドメインではない場合、障害が発生していないドメインを手動でシャットダウンすると、リカバリ・サイトのすべてのドメインがトランザクション・リカバリで使用可能になります。
アクティブ・アクティブ型トポロジ構成は、WLSTスクリプト、REST、Fusion Middleware Controlまたは管理コンソールを使用して、両方のサイトで同一にしておく必要があります同一のドメイン名、サーバー名およびリソース名を両方のサイトで構成する必要があります。SiteNameおよびRecoverySiteNameなどのパラメータは、各サイトのドメインで別々に構成する必要があります。「クロスサイトXAトランザクション・リカバリのMBean属性の構成」を参照してください。
クロスサイトXAリカバリのシナリオでは、クラッシュ後にサーバーが再起動した場合、サーバーのストアが別ドメインのリカバリしたサーバーに引き継がれる可能性があります。
この場合、フェイルバックを発生させるため、元のサーバーからリカバリしたサーバーに、ストアを解放するようシグナルが送られます。必要に応じて、このフェイルバックは内部で再試行されます。この項では、アクティブ・アクティブ型リカバリのソリューションの例を示します。
この例では、アプリケーション・セッション・レプリケーション、ファイル・システム・レプリケーションおよびデータベース・レプリケーションが、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へのコミット・コールを認識できず、トランザクションはリカバリされません。フェイルバックが適切な時間に実行されない場合、トランザクション・リカバリのために、トランザクションに関係するドメインすべてをシャットダウンし、再起動する必要があります。
表7-1では、クロスサイトXAトランザクション・リカバリのために構成する必要があるDomainMBean属性について説明します。
これらのMBeanの詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください
表7-1 クロスサイトXAトランザクション・リカバリのDomainMBean属性
| 属性 | 値 |
|---|---|
| SiteName | ドメインが所属するサイトに与えられた名前。この属性は、JTAMBeanのRecoverySiteName属性に関連して使用されます。表7-2を参照してください。 たとえば、2つのサイトをトランザクション・リカバリに構成する場合、1つはSiteNameを"site1"として、RecoverySiteNameを"site2"として構成されます。2つめのサイトは、SiteNameを"site2"として、RecoverySiteNameを"site1"として構成されます。この方法では、サイトは互いのトランザクションをリカバリするように構成され、アクティブ・アクティブ型可用性を提供します。 |
表7-2では、クロスサイトXAトランザクション・リカバリのために構成する必要があるJTAMBeanおよびJTAClusterMBean属性について説明します。
表7-2 クロスサイトXAトランザクション・リカバリのJTAMBean属性
| 属性 | 値 |
|---|---|
| RecoverySiteName | ドメインがリカバリするサイトの名前。これは、リカバリされたサイトがSiteNameとして構成された値です。RecoverySiteNameがnullの場合、クロス・ドメインXAトランザクション機能は無効です。このMBean値は、動的に変更できます。 表7-1を参照してください。 |
| CrossSiteRecoveryRetryInterval | リースが失効していないことを検証するために、サイト・リース表を確認する間隔の値。これは、デフォルトでは60秒に設定されます。 |
| CrossSiteRecoveryLeaseExpiration | リースがCrossSiteRecoveryLeaseExpirationで更新されていない場合、リカバリ・サーバーがリースを引き継ぎ、リモート・サイトで障害が発生したサーバーのリカバリを開始します。値はデフォルトでは30秒であり、サイト間の待機時間に応じて調整する必要があります。 |
| CrossSiteRecoveryLeaseUpdate | リースのタイムスタンプを更新する時間(秒)。デフォルトは10秒に設定されます。 |
アクティブ・パッシブ型リカバリのソリューションのためのXAトランザクションのドメイン構成および要件について学習します。
アクティブ・パッシブ型障害回復ソリューションのためのXAトランザクションの要件
この項では、アクティブ・パッシブ型の障害回復ソリューションにおいて、本番サイトで障害が発生した後にXAトランザクションのリカバリを成功させるために必要な条件と構成要件を説明します。
アクティブ・パッシブ型のすべてのドメイン・ペアが対称トポロジで構成されており、それらのペアがまったく同じで、同一のドメイン構成となっていること。
WebLogic Continuous Availabilityを使用すると、フェイルオーバーはOracle Site Guardでまとめることができます。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層全体がしない場合、すべてのサーバーをシャットダウンする必要があり、パッシブ・ドメインのすべての同一のサーバーを起動する必要があります。ドメイン、クラスタ、サーバーおよびリソースの名前はすべて同一であるため、サーバーが起動した直後、リカバリが実行され、すべてのトランザクションがリカバリされます。操作が排出できるように、すべてのサーバーで正常停止を実行することをお薦めします。
クラスタのサーバーで障害が発生した場合、サーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。チェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。チェックポイントはトランザクションの早い段階で作成されるため、グローバル・トランザクションで参加者に変更がないかぎり、トランザクション・サービスの移行中や複数サイトまたはデータ・センターにわたるトランザクション・リカバリ中にチェックポイントが同期しなくなる危険はほとんどありません。クラスタの別のサーバーは、サービスまたはサーバー移行を使用してトランザクション・リカバリを引き継ぐことができます。この種類のアーキテクチャは、サイト間で低いレイテンシを必要とします。『Oracle WebLogic Serverクラスタの管理』のマルチキャストおよびクラスタ構成に関する項を参照してください。
この項では、アクティブ・アクティブ型ストレッチ・クラスタ・リカバリのソリューションのためのXAトランザクションのドメイン構成および要件について説明します。
アクティブ・アクティブ型ストレッチ・クラスタ障害回復ソリューションのためのXAトランザクションの要件
この項では、アクティブ・アクティブ型のストレッチ・クラスタの障害回復ソリューションにおいて、本番サイトで障害が発生した後にXAトランザクションのリカバリを成功させるために必要な条件と構成要件を説明します。
このアーキテクチャは、XAトランザクション・リカバリでサービスまたはサーバー移行を使用するため、要件は、サーバー移行に必要な条件と同様です。「サーバー移行」を参照してください。
加えて、ネットワークが次の要件を満たす必要があります。
IPマルチキャスト・パケットの伝播の完全サポート。つまり、すべてのルーターおよびその他のトンネリング技術がマルチキャスト・メッセージをクラスタ化されているサーバー・インスタンスに伝播するように構成されている必要があります。
大半のマルチキャスト・メッセージがその最終的な宛先に約10ミリ秒以内に到達することを保証する、低いネットワーク待機時間。
マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないことを保証する、クラスタのマルチキャストTTL (Time-To-Live: 存続時間)の高い値。マルチキャストTTLパラメータの設定手順については、「マルチキャスト存続時間(TTL)を構成する」を参照してください。
『Oracle WebLogic Serverクラスタの管理』のクラスタがWAN内の複数のサブネットにまたがる場合に関する項を参照してください。
アクティブ・アクティブ型ストレッチ・クラスタ・リカバリのソリューションで、トランザクション・リカバリのためにJTAサービスまたはサーバー移行を使用します。このアーキテクチャは、サイト間のレイテンシが低い場合にお薦めします。
この例では、Site1で稼働中のアプリケーションが、トランザクションを開始します。それがコミットをコールした後、Site1上の1つ以上のサーバーで障害が発生します。サービスまたはサーバー移行が構成された場合、Site2 (ストレッチ・クラスタ内)の正常なサーバーは障害が発生したサーバーのリカバリを引き継ぎます。
オラクル社では、最大限の可用性を実現する環境の構成方法についての追加情報を提供する、多数のリソースを用意しています。
次のトピックを参照してください。
http://www.oracle.com/technetwork/database/features/availability/fusion-middleware-maa-155387.html
Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド
Oracle Fusion Middleware高可用性ガイド
