FMW拡張クラスタの設定

このプレイブックでは、Oracle Fusion Middlewareストレッチ・クラスタをデプロイするためのインフラストラクチャの例として、Oracle Cloud Infrastructure (OCI)を使用します。

OCIインフラストラクチャ固有のステップの提供は、Oracle Fusion Middlewareのストレッチされたクラスタ実装に必要な構成および変更をより適切に反映しています。ただし、提供されているすべての考慮事項およびステップは、他のロード・バランサ、ネットワーク、ハードウェアおよびストレージ・インフラストラクチャを使用しているオンプレミス・システムに廃止できます。このマニュアルに記載されているOCIの例を参照として使用して、各ケースでベンダー固有の詳細を参照してください。

地域を設定

Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・モデルは、2つの異なるサイトにまたがって構成されます。

Oracle Cloud Infrastructure (OCI)では、レイテンシが低いOCIリージョン全体に実装できます。サポートされるリージョン間レイテンシの最大値は、10ミリ秒のラウンドトリップ時間(RTT)です。OCIコンソールで、「ネットワーキング」、「ネットワーク・コマンド・センター」、「リージョン間レイテンシ」の順に選択して、リージョン間のレイテンシを確認できます。

レイテンシ値を考慮すると、RTTが6-7ミリ秒のフランクフルトやアムステルダムなどのリージョン間でこのモデルをデプロイできます。ただし、これらのリージョン間のレイテンシが50ミリ秒のRTTを超えているため、アッシュバーンやフェニックスなどのロケーション間でこのモデルをデプロイすることはできません。

リージョン間のレイテンシが10ミリ秒RTTより低いリージョンのペアの例:

  • アムステルダム(AMS) - パリ(CDG)

  • アムステルダム(AMS) - ニューポート(CWL)

  • アムステルダム(AMS) - フランクフルト(FRA)

  • アムステルダム(AMS) - ロンドン(LHR)

  • パリ(CDG) - フランクフルト(FRA)

  • パリ(CDG) - ロンドン(LHR)

  • パリ(CDG) - ニューポート(CWL)

  • マルセイユ(MRS) - ミラノ(LIN)

  • チューリッヒ(ZHR) - フランクフルト(FRA)

  • チューリッヒ(ZHR) - ミラノ(LIN)

  • 大阪(KIX) - 東京(NRT)

  • シンガポール(SIN) - バタン(HSG)

  • サンパウロ(GRU) - ヴィニェード(VCP)

  • シンガポール(SIN) - シンガポール2 (XSP)

  • バタン(HSG) - シンガポール2 (XSP)

  • ソウル(ICN) - 春川(YNY)

  • トロント(YYZ) - モントリオール(YUL)

帯域幅に関しては、OCIリージョン間に保証された帯域幅はなく、OCIは特定のOCI帯域幅測定ツールを提供していません。正確な帯域幅測定には、iPerfなどのツールを使用します。フランクフルトとアムステルダムの間でテストされた帯域幅は、毎秒約2〜2.5ギガビット(Gbps)です。

このモデルは、同じリージョンにある可用性ドメイン(AD)間に実装することもできます。Oracle WebLogic ServerサーバーのADへのデプロイは、実際には、Oracle SOA Suite on MarketplaceやOracle WebLogic Server for OCIスタックなどのPlatform as a Service (PaaS)サービスの標準動作です。ただし、リージョン全体ではなくAD全体にこのモデルを実装することは、地域全体に影響を与えるイベントから保護しないため、実際には災害対策ソリューションではありません。

ヒント :

各サイトのFMWデプロイメントに必要なサブネット、ルール、コンピュート・インスタンス、共有記憶域およびロード・バランサを作成するには、WLS-HYDRフレームワークを使用できます(インフラストラクチャの作成プロシージャを参照)。

ネットワークの設定

このトポロジをデプロイするリージョンの仮想クラウド・ネットワーク(VCNs)を相互接続して、クラスタ内のすべてのWebLogicサーバーとWebLogicサーバーからデータベースへのトラフィックを許可する必要があります。

設定には、次のネットワーク機能が必要です。

  • 各リージョンのVCNおよび階層化されたサブネット。
  • 動的ルーティング・ゲートウェイ(DRG)を使用したVCNs間のリモート・ピアリング接続。
  • サイト間のトラフィックをルーティングするための適切なルート・ルール。リージョン1では、ルート表に、動的ルーティング・ゲートウェイを介したリージョン2 VCN CIDRへのルートを含める必要があります。同様に、リージョン2ルート表には、動的ルーティング・ゲートウェイを介したリージョン1 VCN CIDRへのルートを含める必要があります。
  • ストレッチされたクラスタに対して次の通信を許可するネットワーク・セキュリティ・ルール:
    • リージョン1とリージョン2の中間層サブネット間のWebLogicサーバー・ポートとノード・マネージャ・ポートを開きます。Coherenceを使用する場合は、Coherenceのポートに対してもTCPおよびUDPトラフィックを許可します。
    • リージョン1およびリージョン2の中間層サブネットからの両方のリージョンのデータベース・リスナーおよびOracle Cloud Infrastructure Notifications (ONS)ポートへのトラフィックを許可します。
    • デフォルトでは、OHSサーバーとWebLogicサーバー間のリージョン間通信は不要です。中間層サブネットのWebLogicサーバー・ポートには、同じリージョン内のOHSサーバーからのみアクセスできるようにする必要があります。ただし、リージョン内のすべてのWebサーバーに障害が発生した場合など、例外的な状況ではリージョン間通信が必要になる場合があります。詳細は、「障害の管理」セクションを参照してください。
  • システムで使用されるすべてのホスト名(WebLogicリスニング・アドレス、プライマリおよびスタンバイ・データベースのSCANおよびVIPアドレス)は、両方のサイトから解決できる必要があります。デフォルトでは、OCIでは、ホスト名は各VCN内でのみ解決できます。リージョン1の名前をリージョン2で解決できるようにするには、リージョン1ドメインのリージョン2にプライベートDNSビューを作成し、関連する名前とIPアドレスを追加します。リージョン1でこのプロセスを繰り返して、リージョン2から名前を解決します。
  • 各サイトでは、システムのフロントエンド名(frontend.example.comなど)がローカル・ロード・バランサのIPアドレスを指している必要があります。これを実現するには、フロントエンド名を各リージョンのプライベートDNSビューまたは中間層ホストの/etc/hostsファイルに追加します。これにより、WebLogicサーバーからフロントエンドへのすべてのコールバックがローカル・リージョンに転送されます。

データベースの設定

リージョン1のOracle Real Application Clusters (Oracle RAC)データベース・システムを、リージョン2のスタンバイRACデータベース・システムに設定します。

ローカルの高可用性が重要な要件であるため、各リージョンでRACを使用することが重要です。クロスアベイラビリティ・ドメイン(AD)またはクロスリージョン保護の構成は、単一リージョン内のローカル障害に対してすでに信頼性の高い保護がある場合にのみ有効です。RACによって提供されるようなローカルの高可用性が実装されていない場合、複数のADまたはリージョンにわたって保護を追加しても、ローカル環境内の障害のリスクに対処できません。

RACデータベース・ノードまたはインスタンス障害が発生した場合にアプリケーションの接続を維持し、Oracle Notification Service通知を受信するには、アプリケーションがCluster Ready Services (CRS)データベース・サービスを使用してプラガブル・データベース(PDB)に接続していることを確認します。プライマリとスタンバイに同じCRSサービスが存在する必要があります。PDBに接続するサービスを作成するコマンドの例: 


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

共有ストレージの設定

Oracle Cloud Infrastructure File Storageは、OCIが提供するフルマネージドでスケーラブルかつセキュアなファイル・システム・サービスです。これは、共有および永続的なファイル・システムを必要とするエンタープライズ・アプリケーションに高パフォーマンスのファイル・ストレージを提供するように設計されています。

複数のコンピュート・インスタンスは、ネットワーク・ファイル・システム(NFS)プロトコルを介して同じファイル・システムを同時にマウントし、アクセスできます。

OCIのOracle Fusion Middleware (FMW)ストレッチ・クラスタ・モデルは、共有ファイル・システム(共有構成や共有ランタイム・データなど)の各リージョンでOCI File Storageシステムを使用します。OCI File Storageは、リージョン内の高可用性を提供します。可用性ドメイン内の複数のフォルト・ドメインに冗長ストレージを内部的に使用します。ただし、OCIファイル・ストレージにはリージョン間ではアクセスできません。したがって、共有記憶域はリージョンに対してローカルです。

ローカル・バックアップおよびリージョン間のファイル・システム・レプリカを使用して、アーティファクトのリカバリ可能なコピーを提供します。

中間層の設定

中間層コンピュート・ノードは、2つのリージョンに分散されます。

中間層コンピュート・ノードは2つのリージョンに分散され、ノードの半分はリージョン1に配置され、残りの半分はリージョン2に配置されます。プロビジョニングおよびインストールのプロセスは、単一のWebLogicドメインを作成する場合と同じです。高可用性機能(Java Message Service (JMS)およびJava Transaction API (JTA)サービス移行、管理サーバーのフェイルオーバー、ノード・マネージャによる自動クラッシュ検出など)を実装するには、エクスプローラ・セクションで参照されているFMWエンタープライズ・デプロイメント・ガイドで推奨されているベスト・プラクティスを使用します。

ドメインを作成し、最初からすべての管理対象サーバーで構成するか、他のリージョンにノードを追加することで、単一リージョンで実行される既存のドメインをスケール・アウトできます。

ノート:

Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・モデルは、Oracle WebLogic Server for OCIスタックやOracle SOA Suite on MarketplaceスタックなどのPlatform as a Service (PaaS)サービスを使用して作成されたドメインに適用できます。これらのPaaSサービスのプロビジョニングおよびスケールアウト機能は、デフォルトで単一のリージョンのみをサポートするため、クラスタを手動でスケール・アウトして別のリージョンにノードを追加する必要があります。この操作を実行するために必要なステップについては、WLSクラスタをスケール・アウトする手順を参照してください。これらのPaaSサービスにはWeb層は含まれず、管理サーバーのフェイルオーバーなど、特定の高可用性ベスト・プラクティスは実装されません。したがって、このドキュメントの推奨事項の一部は、これらの環境には適用されない場合があります。

FMWストレッチ・クラスタ・モデルを使用する場合、WebLogic構成に実装する最も関連性の高い側面は次のとおりです。

  • データベース永続ストアの使用

    Oracleでは、Oracle WebLogic Serverトランザクション・ログおよびJMSのデータベース永続ストアを使用するストレッチ・クラスタがサポートされています。トランザクション・ログおよび永続データをデータベースに格納するには、データベースの組込みレプリケーションおよび高可用性機能(Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardなど)を利用します。Data Guard保護されたデータベースのJMS、トランザクション・ログ(TLOG)およびメタデータでは、クロスサイト同期が簡素化され、アプリケーション・レベルでの一貫性が保証されます。これは、中間層がこれらのアーティファクトの共有記憶域を必要としなくなったことも意味します(ただし、管理サーバーのフェイルオーバー、デプロイメント・プランおよびファイル・アダプタなどの一部のアダプタでは引き続き必要になります)。

    ただし、TLOGおよびJMSストアをデータベースで使用すると、システム・パフォーマンスが低下します。このペナルティは、中間層の1つが他のサイトのデータベースと相互通信する必要がある場合に増加します。パフォーマンスの観点から見ると、各サイトにローカルな共有ストレージのパフォーマンスは向上しますが、これにより、リージョン間のデータ損失ゼロとアプリケーションの一貫性を保証する複雑さと制限が導入されます。

  • 各リージョンにローカルな共有ファイル・システム・アーティファクト

    Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドに示されているように、管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)は、管理対象サーバーのドメイン・フォルダ(MSERVER_HOME)から分離された共有記憶域に配置する必要があります。これにより、管理サーバーのリスニング・アドレスに仮想ホスト名を使用するとともに、管理サーバーは同じリージョン内または別のリージョン内の別のホストにフェイルオーバーできます。

    共有ファイル・システムに存在する他のアーティファクトは、Oracleホーム・インストール(バイナリ)、デプロイメント・プランおよびファイル・アダプタ・ディレクトリ(ランタイム・フォルダ)です。

    FMWストレッチ・クラスタ・トポロジでは、各リージョンが独自のローカル共有記憶域を利用します。その結果、2番目のリージョンでは、独自の冗長バイナリ(高可用性のためにサイトごとに少なくとも2つのバイナリ・インストールを保証)および共有構成、デプロイメント・プラン、ランタイム・ファイルなどの独自の共有ディレクトリが保持されます。これらのアーティファクトはすべて、一貫性とシームレスなフェイルオーバーを確保するために、両方のリージョン間で同じパスを使用する必要があります。

  • WebLogicクラスタに対するアフィニティ・ベースのアルゴリズムの使用
    クロスサイト・トラフィックを最小限に抑えるには、Java Naming and Directory Interface (JNDI)コンテキスト・ファクトリ解決にローカル・アフィニティを使用します。WebLogicクラスタの「デフォルト・ロード・アルゴリズム」をアフィニティ・ベースのアルゴリズムに設定するには:
    1. WebLogicリモートコンソールの「ツリーの編集」に移動します。
    2. 「環境」に移動し、「クラスタ」を選択し、クラスタを選択します。
    3. 「一般」タブで、WebLogicクラスタの「デフォルト・ロード・アルゴリズム」をラウンドロビン・アフィニティ(デフォルトはラウンドロビン)または任意のアフィニティ・ベース・アルゴリズムに設定します。

    「クラスタ・アドレス」は、クラスタ内のすべてのサーバーの明示的なリストを使用して設定する必要はありません。空の場合、「クラスタ・アドレス」の値は自動的に生成されます。クラスタ・アドレスの自動生成時にリストされるサーバー数を制限するプロパティ「クラスタ・アドレスのサーバー数」に、クラスタ内のすべてのサーバーを含めるのに十分な値が設定されていることを確認してください。

  • 自動サービス移行構成の使用

    Oracleでは、エンタープライズ・デプロイメント・トポロジのJava Database Connectivity (JDBC)永続ストアとともに自動サービス移行を構成することをお薦めします。FMWストレッチ・クラスタ・トポロジでは、JMSおよびTLOGデータが両方のサイトからアクセス可能であるかぎり、リージョン内およびリージョン間での自動サービス移行も可能です。JDBC永続ストアを使用する場合、ストレッチされたクラスタでASMを構成する際に特別な考慮事項は必要ありません。

    サイト間で高いレイテンシが発生すると、リージョン1からリージョン2へのサービス移行操作にかかる時間が長くなる可能性があります。この増加は、他のリージョンのデータベース内の永続ストアからメッセージが読み取られるため、他のサーバーでのメッセージのリカバリに要した時間が原因です。このレイテンシは、永続ストア内の保留中のメッセージ数とともに増加します。ただし、ペナルティは、非常に高いレイテンシ、または多数の保留中のメッセージのみに関連するようになります。予想される動作の詳細は、「パフォーマンス・データのレビュー」の項を参照してください。

  • フロントエンドのホスト名と解決策

    WebLogicクラスタのフロントエンド・ホストを構成する場合は、標準デプロイメントと同様に、クライアントがシステムへのアクセスに使用する仮想ホスト名を指定します。クライアントは、この仮想ホスト名を、リージョン1とリージョン2のOCIロード・バランサ・インスタンス間でバランスのとれた外部アドレスに解決する必要があります。グローバル・ロード・バランシングについてを参照してください。

    各リージョンのWebLogicサーバーが内部コールをそれぞれのローカルOCIロード・バランサにのみルーティングするようにするには、フロントエンド・ホスト名をリージョン内のOCIロード・バランサのIPアドレスに解決するようにサーバーを構成します。これは、各WebLogicサーバー・ホストの/etc/hostsファイルにエントリを追加するか、各リージョンのDNSプライベート・ビューに追加することで実現できます。

    リージョン1のサーバーの場合:

    [IP address of Region 1 OCI Load Balancer] [frontend hostname]

    リージョン2のサーバーの場合:

    [IP address of Region 2 OCI Load Balancer] [frontend hostname]

    この構成により、WebLogicサーバーからの内部通信が適切なリージョナル・ロード・バランサに転送され、ルーティングとパフォーマンスが最適化されます。

WebLogicデータ・ソースの設定

すべてのWebLogicデータ・ソース(Oracle Fusion Middleware (FMW)メタデータ、データベース永続ストア、リース表、DBアダプタなど)に二重接続文字列を含むGridLinkデータ・ソースを使用して、データベース・フェイルオーバーを自動化します。Oracle Real Application Clusters (Oracle RAC)のいずれかのノードで障害またはシャットダウンが発生した場合でも、もう一方のリージョンへのデータベースの完全なスイッチオーバーが発生した場合は、自動的に再接続する必要があります。これを実現するには、次の推奨事項を適用します。

  • GridLinkデータ・ソースを使用

    GridLinkデータソースは、Oracle Notification Service (ONS)を利用して、データベース・ノードの障害やネットワークの中断を迅速に検出して対応し、アプリケーションの可用性とレジリエンスを向上させます。リアルタイムのワークロード情報に基づいてデータベース接続を自動的に分散し、すべてのRACノード間でパフォーマンスとリソース使用率を最適化します。データベース・トポロジの変更(RACノードの追加や削除など)が自動的に認識および処理されるため、管理オーバーヘッドが削減され、停止時間が最小限に抑えられます。

    GridLinkデータ・ソース構成でONSホストおよびポートを手動で指定する必要はありません。ONSリストは、データベースによってドライバに自動的に提供され、プライマリ・データベースとスタンバイ・データベースの両方のONS情報を取得して、両方への接続を容易にします。

  • TNS別名の使用

    データ・ソースの接続文字列で、プライマリSCANアドレスとスタンバイSCANアドレスの両方を含むtnsnames.oraファイルのエントリを指すTNS別名を使用します。推奨される接続文字列の形式は次のとおりです。RACデータベースごとに1つずつ、1つの説明と2つのアドレス・リストがあります。 

    PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)

    データ・ソースおよびFMW構成ファイルでTNS別名を構成する方法の詳細は、Oracle SOA Suiteエンタープライズ・デプロイメント・ガイドの接続文字列でのTNS別名の使用を参照してください。

  • 「予約時の接続テスト」オプションの使用

    「予約時に接続をテスト」オプションがすべてのデータ・ソースに対して有効になっていることを確認します。これは、永続ストアへのアクセスに使用されるデータ・ソースにとって特に重要です。これは、永続ストアがWebLogicサーバー全体の状態において重要であるためです。このフラグにより、WebLogicサーバーは、接続をアプリケーションに渡す前にテストできます。

    「テスト表名」には、デフォルト値SQL ISVALIDを使用します。これは高速で効率的なテストであり、特定の物理表にアクセスすることなく、データベース接続がまだアクティブであるかどうかを判断するために軽量検証を実行します。

  • 初期容量のチューニング

    WebLogicサーバーが起動すると、データ・ソース・プールの初期接続の作成にかなりの時間が費やされます。データ・ソースの初期容量設定に従って、異なる遅延が予想されます。デフォルトでは、ほとんどのFMWデータ・ソースは、接続プールにゼロの初期容量を使用します。ただし、通常のランタイム操作中のシステムの応答時間を短縮するために、初期プール容量を増やすと有益な場合があります。

    初期容量はデータ・ソース(接続プール)レベルで構成されるため、これらの設定は、クラスタ内のすべてのサーバー(データベースに対してローカルなサーバーおよびリモートのサーバー)の起動時間に影響します。FMWストレッチ・クラスタでは、データベースからリモートに存在するサーバーは、初期プール容量が大きいほど、起動時のレイテンシが増加します(「開始時間の確認」を参照)。したがって、通常の操作中に応答時間を最適化し、開始時間を最小限に抑えて理想的な初期容量設定を決定するには、バランスのとれた決定が必要です。
  • 最大容量のチューニング

    アクティブなデータ・ソース接続の数は、データベースへの待機時間が長くなるにつれて増加します。実施されたテストでは、リモート・リージョン内のサーバーは、データベースと配置されたサーバーよりも最大2xのアクティブな接続を表示します(「ストレス・テストの確認」を参照)。アプリケーションの使用状況を監視し、WebLogicデータ・ソースおよびデータベース・セッションのサイズを正しく設定することを検討してください。

Webサーバーの設定

システムでOracle HTTP Serverインスタンスを含むWeb層を使用する場合は、リージョン内で高可用性を提供するために、各リージョンに少なくとも2つのサーバーが必要です。

リージョン間のトラフィックを減らすために、Oracle WebLogic Serverのルーティング・セクションで動的サーバー・リスト構成を使用しないでください。かわりに、DynamicServerListパラメータをOFFに設定して、サーバーの静的リストを構成します。これは、障害検出が遅くなるという注意事項です。WebLogicサーバーがクラッシュすると、HTTPサーバーは動的リストよりも障害の検出に時間がかかります。また、新しいサーバーが追加された場合は、構成の更新が必要です。ただし、システムのパフォーマンスは向上します。

Oracle HTTP Serverのmod_wl_ohs.confファイルからの次の抜粋は、soa-infra Webアプリケーションへのルーティングに必要な構成の例を示しています。

リージョン1:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

リージョン2:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

ロード・バランサの設定

各リージョンには、そのサイト内のサーバー間でリクエストを分散するための独自のロード・バランサが必要です。

各ロード・バランサで同じSSL証明書を使用して、両方のリージョンでリスナーを構成します。リージョン1のロード・バランサに、リージョン1のOracle HTTP Server (OHS)インスタンスが含まれるようにバックエンド・サーバーを設定します(システムがWebサーバーを使用しない場合、バックアップされたサーバーはWebLogicです)リージョン1のサーバー)およびリージョン2のロード・バランサには、リージョン2のOHSサーバーが含まれます(システムがWebサーバーを使用しない場合、バックエンド・サーバーはリージョン2のWebLogicサーバーです)。

アプリケーションのステータスを正確に反映するURLを使用して、バックエンド・サーバーの可用性を判断するためのヘルス・チェックを構成します。これにより、Oracle WebLogic Serverが実行されているが、アプリケーション自体が使用できないサーバーにトラフィックがルーティングされるのを防ぎます。これは、ヘルス・チェックがルート・コンテキスト(/)のみをターゲットとする場合にのみ発生する可能性があります。ただし、頻繁に大量のチェックを行うと、バックアップされたサーバーが過負荷になる可能性があるため、リソースを大量に消費するヘルス・チェックは使用しないでください。たとえば、Oracle SOAの場合、推奨されるヘルス・チェックURLは/soa-infra/services/isSoaServerReady です。

グローバル・ロード・バランシングについて

Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・モデルでは、2つのリージョン間でクライアントのリクエストを均衡化するために、各データ・センターのロード・バランサの上に要素が必要です。

オンプレミス実装では、これは従来、スマート・ルーティングを担当するグローバル・ロード・バランサ(通常はオリジンIPアドレスに基づく)を使用して実装されていました。このグローバル・ロード・バランサは通常、いずれかのサイトに配置され、もう一方のサイトにはフェイルオーバー用のバックアップがあります。

Oracle Cloud Infrastructure (OCI)には、専用のグローバル・ロード・バランサ・サービスはありません。ただし、トラフィック管理ポリシーを使用すると、グローバルなロード・バランシング機能を実現できます。

OCI Traffic Management Steering Policiesをグローバル・ロード・バランサとして使用

Oracle Cloud Infrastructure (OCI)トラフィック管理ステアリング・ポリシーを使用して、2つのサイト間のクライアントのトラフィックのロード・バランシングを行います。

トラフィック管理ステアリング・ポリシーは、ドメイン・ネーム・システム(DNS)問合せに対するインテリジェントなレスポンスを提供します。つまり、ポリシーで定義されたロジックに応じて、問合せに対して異なる回答が提供される場合があります。様々なポリシー・タイプがあります。

  • ロード・バランサ・ポリシー

    ロード・バランサ・ポリシーは、トラフィックを多くのエンドポイントに分散します。エンドポイントに同じ重みを割り当ててエンドポイント間でトラフィックを均等分散したり、カスタム重みを比率ロード・バランシングに割り当てることができます。Oracle Cloud Infrastructure Health Checksモニターおよびオンデマンド・プローブを利用して、エンドポイントの健全性を評価します。エンドポイントの異常であると判断された場合、DNSトラフィックは自動的に他のエンドポイントに配布されます。

  • フェイルオーバーポリシー

    フェイルオーバー・ポリシーにより、回答をポリシーで提供する順序(例: プライマリとセカンダリ)を優先できます。OCIヘルス・チェック・モニターおよびオンデマンド・プローブを利用して、ポリシー内の回答の健全性を評価します。プライマリの回答が不健全であると判断されると、DNSトラフィックが自動的にセカンダリの回答に渡されます。

  • ジオロケーション・ステアリング・方針

    ジオロケーション・ステアリング・ポリシーは、エンド・ユーザーの場所に基づいて、DNSトラフィックを異なるエンドポイントに分散します。顧客は、発信元の大陸、国または州/地域(北米)で構成される地理的リージョンを定義でき、また、リージョンごとに個別のエンドポイントまたはエンドポイントのセットを定義できます。

  • ASNステアリング・方針

    ASNステアリング・ポリシーにより、DNSトラフィックを自律システム番号(ASN)に基づいてステアリングできます。特定のASNまたはASNのセットから発生したDNS問合せは、指定のエンドポイントに渡すことができます。

  • IPプレフィックス・ステアリング・ポリシー

    IP接頭辞ステアリング・ポリシーでは、顧客は、開始元の問合せのIP接頭辞に基づいてDNSトラフィックを制御できます。

ニーズに最も適したポリシーを選択します。ストレッチされたクラスタ・デプロイメントに最適なオプションは、ジオロケーション・ステアリング・ポリシーとIPプリフィクス・ステアリング・ポリシーです。フェイルオーバーポリシーは、WebLogic Remote Consoleなどのいずれかのサイトでのみ動作するサービスに適しています。

ポリシーのタイプに関係なく、OCIヘルス・チェックを定義してサイトの可用性を検証する必要があります。これにより、サーバーが停止しているサイトまたはアプリケーションが使用できないサイトに到達するトラフィックが回避されます。ヘルス・チェックを実行するバンテージ・ポイントからの受信トラフィックを、チェックするOCIロード・バランサ・ポートに必ず許可してください。

次の図は、OCIトラフィック管理ステアリング・ポリシーによるグローバル・ロード・バランシングを示しています。


global-load-balancer-steering-policies.pngの説明が続きます
図global-load-balancer-steering-policies.pngの説明

global-load-balancer-steering-policies-oracle.zip

OCIトラフィック管理ステアリング・ポリシーを使用してグローバル・ロード・バランサをエミュレートする場合:

  • フェイルオーバー反応時間

    サイト障害に対するレスポンス時間は、ヘルス・チェック間隔(サイトが使用不可としてマークされる速度を決定する)とDNSレコードの存続時間値(TTL)の両方によって異なります。サイトが使用不可とフラグ付けされ、トラフィックが別の場所に転送された後でも、クライアントは、以前のDNS TTLがローカル・キャッシュで期限切れになるまで、更新されたIPアドレスを受信しません。フェイルオーバーの遅延を最小限に抑えるには、ポリシーが小さいTTL値を設定することをお薦めします。

  • セッション永続性の制限

    これらのポリシーによるロード・バランシングはDNSレスポンス値に依存するため、セッション永続性の組込みメカニズムはありません。その結果、ランダムまたは単純なロード・バランサ・ポリシーを使用する場合、クライアントに提供されたDNS応答はいつでも変更され、永続性を必要とするアプリケーション・セッションに影響を与える可能性があります。アプリケーションで永続セッションが必要な場合は、可能なすべてのクライアントの場所がジオロケーション・ベースのルール内で明示的に定義されていることを確認し、ランダムまたはロード・バランサのステアリング・アルゴリズムを使用しないようにします。

次に、フランクフルトおよびアムステルダム・リージョンにデプロイされたOracle Fusion Middleware (FMW)ストレッチ・クラスタ・システムのOCIトラフィック管理ステアリング・ポリシーの構成例を示します。フロントエンドは、Oracle SOA用、OSB用、およびWebLogicリモート・コンソール用です。フランクフルトのロード・バランサ(LBR)のIPは111.111.111.111で、アムステルダムのLBRのIPは222.222.222.222です。この例では、ステアリング・ポリシーによって次のルールが定義されています。

  • SOAおよびOSBフロント・エンドの場合、ドイツ、ヨーロッパ、アジアおよび南米のロケーションのクライアントは、DNSからフランクフルト・ロード・バランサのIPを主な回答として取得します。

  • SOAおよびOSBフロント・エンドの場合、オランダ、アフリカ、オセアニアおよび北米のロケーションのクライアントは、DNSからアムステルダム・ロード・バランサのIPを主な回答として取得します。

  • 他のクライアント(すべてのリージョンがジオロケーション・ルールに含まれているため、想定されていない)の場合、DNSはデフォルトの回答を返して、フランクフルトにリダイレクトします。

  • OCIヘルス・チェックはフロント・エンドごとに定義されるため、プライマリが使用不可とマークされている場合、トラフィックは代替IPレコードに誘導されます。

  • WebLogic Remote Consoleフロントエンドはフェイルオーバーモデルを使用します。DNSは、すべてのクライアントのフランクフルト・ロード・バランサのIPを返します。フランクフルトでヘルス・チェックが失敗すると、DNSはAmsterdamロード・バランサのIPを返します。

定義されているOCIトラフィック管理ステアリング・ポリシーは次のとおりです。

  • SOAフロント・エンドにアクセスするためのジオロケーション・ステアリング・ポリシー。

    構成品目 値の例

    ポリシー名

    strecthed_cluster_steering_policy-SOA

    テンプレート

    ジオロケーション・ステアリング

    ポリシーTTL

    60s

    回答 Pool1 (Frankfurt_Pool)

    名前: Frankfurt_LBR_IP

    タイプ: A

    RDATA: 111.111.111.111

    アンサー・プール2 (Amsterdam_Pool)

    名前: Amsterdam_LBR_IP

    タイプ: A

    RDATA: 222.222.222.222

    ジオロケーション・ステアリング・ルール1

    Geolocation: ドイツ、ヨーロッパ、アジア、南アメリカ

    プール優先度1: Frankfurt_Pool

    プール優先度2: Amsterdam_Pool

    ジオロケーション・ステアリング・ルール2

    ジオロケーション: オランダ、アフリカ、オセアニア、北米

    プール優先度1: Amsterdam_Pool

    プール優先度2: Frankfurt_Pool

    グローバル・キャッチオール

    回答 Pool1 (Frankfurt_Pool)

    ヘルス・チェックのアタッチ

    リクエスト・タイプ: HTTP

    ヘルス・チェック: SOA_IS_ALIVE (HTTPS)

    アタッチ済ドメイン

    soafrontend.example.com

  • OSBフロント・エンドにアクセスするためのジオロケーション・ステアリング・ポリシー。

    構成品目 値の例

    ポリシー名

    strecthed_cluster_steering_policy-OSB

    テンプレート

    ジオロケーション・ステアリング

    ポリシーTTL

    60s

    アンサー・プール1(Frankfurt_Pool)

    名前: Frankfurt_LBR_IP

    タイプ: A

    RDATA: 111.111.111.111

    アンサー・プール2 (Amsterdam_Pool)

    名前: Amsterdam_LBR_IP

    タイプ: A

    RDATA: 222.222.222.222

    ジオロケーション・ステアリング・ルール1

    Geolocation: ドイツ、ヨーロッパ、アジア、南アメリカ

    プール優先度1: Frankfurt_Pool

    プール優先度2: Amsterdam_Pool

    ジオロケーション・ステアリング・ルール2

    ジオロケーション: オランダ、アフリカ、オセアニア、北米

    プール優先度1: Amsterdam_Pool

    プール優先度2: Frankfurt_Pool

    グローバル・キャッチオール

    回答 Pool1 (Frankfurt_Pool)

    ヘルス・チェックのアタッチ

    リクエスト・タイプ: HTTP

    ヘルス・チェック: OSB_IS_ALIVE (HTTPS)

    アタッチ済ドメイン

    osbfrontend.example.com

  • フェイルオーバー・ポリシーは、WebLogicリモート・コンソールへのアクセスに使用されます。通常の操作中、管理サーバーはいずれかのサイト(この場合はフランクフルト)でのみ実行されます。サイトに障害が発生した場合にのみ、他のサイトで起動されます。したがって、WebLogicリモート・コンソールおよびEMへのアクセスは、フェイルオーバー・ポリシーによって制御されます。

    構成品目 値の例

    ポリシー名

    strecthed_cluster_steering_policy- 管理者

    テンプレート

    フェイルオーバー

    ポリシーTTL

    60s

    回答 Pool1 (Frankfurt_Pool)

    名前: Frankfurt_LBR_IP

    タイプ: A

    RDATA: 111.111.111.111

    アンサー・プール2 (Amsterdam_Pool)

    名前: Amsterdam_LBR_IP

    タイプ: A

    RDATA: 222.222.222.222

    プールの優先度 1

    Frankfurt_Pool

    プールの優先度 2

    Amsterdam_Pool

    ヘルス・チェックのアタッチ

    リクエスト・タイプ: HTTP

    ヘルス・チェック: EM_IS_ALIVE (HTTPS)

    アタッチ済ドメイン

    admin.example.com

これは、各DNSステアリング・ポリシーで使用されるOCIヘルス・チェックの構成です:

  • SOAフロントエンドのヘルス・チェック。SOAには、パス/soa-infra/services/isSoaServerReadyでSOAステータスを確認するための簡単なページが用意されています。したがって、このヘルス・チェックでは、そのパスへのHTTPSを使用してHEADリクエストを実行し、SOAアプリケーションが使用可能かどうかを検証します。hostヘッダーは、Webサーバーおよびロード・バランサで名前付き仮想ホストを使用する場合、テストするフロントエンド名(この例ではsoafrontend.example.com)を指定するために必要です。

    構成品目 値の例

    ヘルス・チェック名

    SOA_IS_ALIVE

    ターゲット

    111.111.111.111 (フランクフルトLBR IP)

    222.222.222.222 (アムステルダムLBR IP)

    バンテージ・ポイント

    Microsoft Azure北ヨーロッパ

    Google米国東部

    入力してください

    HTTP

    プロトコル

    HTTPS

    ポート

    443

    パス

    /soa-infra/services/isSoaServerReady

    ヘッダー

    ホスト: soafrontend.example.com:443

    Method

    HEAD

    間隔

    30秒

    タイムアウト

    10秒

  • OSBフロント・エンドのヘルス・チェック。OSBは、そのサービスのヘルスURLを実装しません。OSBのステータスを検証するために通常使用されるURLの一部(/sbinspection.wsilなど)では認証が必要であり、OCIヘルス・チェックではauthorizationヘッダーがサポートされていません。したがって、OSBのステータスを確認するには、単純なカスタムRESTプロキシ・サービスをデプロイします。このOCIヘルス・チェックは、HTTPSを介してそのようなエンドポイントに対してHEADリクエストを実行します。hostヘッダーは、Webサーバーおよびロード・バランサで名前付き仮想ホストを使用する場合、テストするフロントエンド名(この例ではosbfrontend.example.com)を指定するために必要です。

    構成品目 値の例

    ヘルス・チェック名

    OSB_IS_ALIVE

    ターゲット

    111.111.111.111 (フランクフルトLBR IP)

    222.222.222.222 (アムステルダムLBR IP)

    バンテージ・ポイント

    Microsoft Azure北ヨーロッパ

    Google米国東部

    入力してください

    HTTP

    プロトコル

    HTTPS

    ポート

    443

    パス

    /default/isOSBReadySample

    ヘッダー

    ホスト: osbfrontend.example.com:443

    Method

    HEAD

    間隔

    30秒

    タイムアウト

    10秒

  • WebLogic Remote ConsoleフロントエンドEM_IS_ALIVEのヘルス・チェック。

    OCIヘルス・チェックは、パス/em/faces/targetauth/emasLoginへのHTTPSを使用してHEADリクエストを実行し、FMW Controlコンソールのステータスを確認します。

    構成品目 値の例

    ヘルス・チェック名

    SOA_IS_ALIVE

    ターゲット

    111.111.111.111 (フランクフルトLBR IP)

    222.222.222.222 (アムステルダムLBR IP)

    バンテージ・ポイント

    Microsoft Azure北ヨーロッパ

    Google米国東部

    入力してください

    HTTP

    プロトコル

    HTTPS

    ポート

    443

    パス

    /em/faces/targetauth/emasLogin

    ヘッダー

    ホスト: admin.example.com:445

    Method

    HEAD

    間隔

    30秒

    タイムアウト

    10秒

サードパーティ・グローバル・ロード・バランサの使用

Oracle Cloud Infrastructure (OCI)トラフィック管理ステアリング・ポリシーの代替として、サード・パーティのグローバル・ロード・バランサ(GLBR)を使用できます。

ローカル・ロード・バランサ間のリクエストのスマート・ルーティングの実行を担当します。

GLBRは、すべてのサイトおよび外部の場所のユーザーがアドレスとしてアクセスできるように構成されたロード・バランサである。このデバイスは、接続先のサイトにかかわらず、任意のクライアントからアクセス可能なドメイン・ネーム・システム(DNS)名にマップされた仮想サーバーを提供します。

GLBRは、設定された基準とルールをベースにして、トラフィックをどちらか一方のサイトに転送します。これらの基準は、クライアントのIPなどに基づいて設定できます。これを使用して、GLBRを初回要求時と次の要求時にユーザーを同じサイトにマップできるようにする永続性プロファイルを作成してください。GLBRは、すべてのローカル・ロード・バランサのアドレスで構成されるプールを保持します。サイトのいずれかで障害が発生すると、ユーザーはまだ機能しているアクティブなサイトに自動的にリダイレクトされます。

各サイトでは、ローカル・ロード・バランサがGLBRからリクエストを受信し、適切なHTTPサーバーにリクエストを転送します。不要なルーティングと高コストな再送をなくすため、GLBRも構成されますが、コールバックを生成したサーバーに対してのみローカルなLBRにコールバックをルーティングするという特定のルールが適用されます。たとえば、これはOracle SOAサービスの内部コンシューマに役立ちます。これらのGLBRルールは次のようにまとめることができます。

  • リクエストがsite1 (たとえば、サイト1のWebLogicサーバーから送信されたリクエスト)からのものである場合、GLBRはsite1のLBRにルーティングされます。

  • リクエストがsite2 (たとえば、サイト2のWebLogicサーバーから送信されたリクエスト)からのものである場合、GLBRはsite2のLBRにルーティングされます。

  • 要求が他のアドレスからのものである場合(クライアント呼出し)、GLBRは接続を両方のLBRにロード・バランシングします。

  • 特定のクライアントを特定のサイトにルーティングするために、追加のルーティング・ルールがGLBRで定義される場合があります(たとえば、2つのサイトは各ケースのハードウェア・リソースによって応答時間が異なります)。

その他のリソースの設定

2つのリージョンでは、LDAP、アイデンティティ・ストア、ポリシー・ストア、外部javaメッセージ・サービス(JMS)宛先、外部Webサービス、Oracle Cloud Infrastructure Object Storageなどの外部リソースを使用できます。

これらの外部リソースの構成の詳細は、このドキュメントの範囲外です。ただし、均一な動作を実現するには、これらのリソースが両方のリージョンで一貫している必要があります。

たとえば、Oracle SOAでは、非同期コールバックによって、別のリージョンで開始されたインスタンスがリハイドレーションされます。同様に、自動リカバリの場合、Oracle WebLogic Serverはクラスタ・マスターの役割を担い、どちらのリージョンでもリカバリ操作を実行できます。これらのプロセスがシームレスに機能し、一貫した動作を実現するには、両方のリージョンから同じ外部リソースにアクセスできる必要があります。