6 複数サイトまたはデータ・センターにわたるトランザクション・リカバリ
障害回復におけるXAトランザクション・リカバリの理解
可用性を最大限に高め、予期しない障害および天災から保護することは、エンタープライズ・デプロイメントの障害回復ソリューションの主要な要件です。障害回復ソリューションの1つの特徴は、本番サイトを利用できなくなった場合に、影響を受けたWebLogicドメインのすべてのXAトランザクションを必ずリカバリできるようにすることです。
-
アクティブ・パッシブ型: これらのソリューションには、アクティブな(本番)サイトとは地理的に異なる位置で、スタンバイ・サイトを設定してペアにする作業が含まれます。スタンバイ・サイトは通常はパッシブ・モードであり、本番サイトを利用できない場合に起動されます。「アクティブ・パッシブ型XAトランザクション・リカバリ」を参照してください。
-
アクティブ・アクティブ型ストレッチ・クラスタ: このアーキテクチャでは、クラスタは2つのサイトにまたがります。サイトをまたいだトランザクション・リカバリは、サービスまたはサーバーの移行により実施されます。「アクティブ・アクティブ型ストレッチ・クラスタXAトランザクション・リカバリ」を参照してください。
ノート:
WebLogic Server JMSリソースが登録されたトランザクションは、アクティブ・アクティブ型リカバリのソリューションでリカバリできません。
アクティブ・パッシブ型XAトランザクション・リカバリ
アクティブ・パッシブ型リカバリのソリューションのための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ディザスタ・リカバリ・ガイド』の「障害時リカバリ・サイトの設定と管理」を参照してください。
XAトランザクション・リカバリのためのアクティブ・パッシブ型ドメイン構成の例
アクティブ・パッシブ型のすべてのドメイン・ペアが対称トポロジで構成されており、それらのペアがまったく同じで、同一のドメイン構成となっていること。アクティブ・パッシブ型アーキテクチャのフェイルオーバー処理は、手動により、または外部ツールに制御されて実施されます。
Site1で稼働中のアプリケーションが、トランザクションを開始します。それがコミットをコールした後、アプリケーション・インフラストラクチャ層全体がこの例では、アプリケーション・セッション・レプリケーション、ファイル・システム・レプリケーションおよびデータベース・レプリケーションが、2つのサイト間で実施されます。
WebLogic Server層全体がしない場合、すべてのサーバーをシャットダウンする必要があり、パッシブ・ドメインのすべての同一のサーバーを起動する必要があります。ドメイン、クラスタ、サーバーおよびリソースの名前はすべて同一であるため、サーバーが起動した直後、リカバリが実行され、すべてのトランザクションがリカバリされます。操作が排出できるように、すべてのサーバーで正常停止を実行することをお薦めします。
アクティブ・アクティブ型ストレッチ・クラスタXAトランザクション・リカバリ
クラスタのサーバーで障害が発生した場合、サーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。チェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。チェックポイントはトランザクションの早い段階で作成されるため、グローバル・トランザクションで参加者に変更がないかぎり、トランザクション・サービスの移行中や複数サイトまたはデータ・センターにわたるトランザクション・リカバリ中にチェックポイントが同期しなくなる危険はほとんどありません。クラスタの別のサーバーは、サービスまたはサーバー移行を使用してトランザクション・リカバリを引き継ぐことができます。この種類のアーキテクチャは、サイト間で低いレイテンシを必要とします。『Oracle WebLogic Serverクラスタの管理』のマルチキャストおよびクラスタ構成に関する項を参照してください。
この項では、アクティブ・アクティブ型ストレッチ・クラスタ・リカバリのソリューションのためのXAトランザクションのドメイン構成および要件について説明します。
アクティブ・アクティブ型ストレッチ・クラスタ障害回復ソリューションのためのXAトランザクションの要件
この項では、アクティブ・アクティブ型のストレッチ・クラスタの障害回復ソリューションにおいて、本番サイトで障害が発生した後にXAトランザクションのリカバリを成功させるために必要な条件と構成要件を説明します。
このアーキテクチャは、XAトランザクション・リカバリでサービスまたはサーバー移行を使用するため、要件は、サーバー移行に必要な条件と同様です。「サーバーの移行」を参照してください。
加えて、ネットワークが次の要件を満たす必要があります。
-
IPマルチキャスト・パケットの伝播の完全サポート。つまり、すべてのルーターおよびその他のトンネリング技術がマルチキャスト・メッセージをクラスタ化されているサーバー・インスタンスに伝播するように構成されている必要があります。
-
大半のマルチキャスト・メッセージがその最終的な宛先に約10ミリ秒以内に到達することを保証する、低いネットワーク待機時間。
-
マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないことを保証する、クラスタのマルチキャストTTL (Time-To-Live: 存続時間)の高い値。マルチキャストTTLパラメータの設定手順については、「マルチキャスト存続時間(TTL)を構成する」を参照してください。
『Oracle WebLogic Serverクラスタの管理』のクラスタがWAN内の複数のサブネットにまたがる場合に関する項を参照してください。
XAトランザクション・リカバリのためのアクティブ・アクティブ型ストレッチ・クラスタの例
アクティブ・アクティブ型ストレッチ・クラスタ・リカバリのソリューションで、トランザクション・リカバリのためにJTAサービスまたはサーバー移行を使用します。このアーキテクチャは、サイト間のレイテンシが低い場合にお薦めします。
この例では、Site1で稼働中のアプリケーションが、トランザクションを開始します。それがコミットをコールした後、Site1上の1つ以上のサーバーで障害が発生します。サービスまたはサーバー移行が構成された場合、Site2 (ストレッチ・クラスタ内)の正常なサーバーは障害が発生したサーバーのリカバリを引き継ぎます。