はじめに

Oracle WebLogic Serverは、複数のオンプレミス・サイトまたは複数のOracle Cloud Infrastructure (OCI)リージョンにまたがってデプロイできます。

このプレイブックの構成では、単一のOracle WebLogic Serverドメインを使用します。このドメインでは、2つのサイトのサーバーが同じクラスタ(ストレッチ・クラスタと呼ばれます)に参加し、Data Guardに依存してデータベースの保護を提供します。

OCIでは、トラフィック管理、ヘルス・チェック、ロード・バランサ、DNSプライベート・ビュー、動的ルーティング・ゲートウェイなどの機能により、この設定をサポートする拡張機能が提供されます。オンプレミス環境では、これらの要件を満たすために、同等のネットワーキングおよびインフラストラクチャ・コンポーネントを使用する必要があります。

サイトまたはリージョン間のネットワーク・レイテンシは、呼出しの遅延によって発生するパフォーマンス・ペナルティを最小限に抑え、デプロイメントおよび実行時の不整合を防止するために、十分に低くする必要があります。Oracleはこのトポロジをサポートしているのは、WebLogicサーバーとデータベース間のレイテンシが10ミリ秒の往復時間(RTT)を下回っている場合のみです。

最適なパフォーマンスおよびフェイルオーバー動作を実現するために、Oracleでは、WebLogicストレッチ・クラスタで実行されている各アプリケーションを分析し、このプレイブック(タイムアウト、セッション・レプリケーション構成、サービス移行リース、Java Transaction API (JTA)など)で説明されている様々なパラメータを適宜調整することをお薦めします。

Oracle Fusion Middlewareのストレッチ済クラスタについて学習

いかなるOracle Fusion Middlewareエンタープライズ・デプロイメントにおいても、Oracle最大可用性アーキテクチャ(MAA)の実現が重要な要件の一つとなります。

Oracle Fusion Middlewareには、プロセスの停止の検出と再起動、サーバー・クラスタリング、サービス移行、GridLink、ロード・バランシング、フェイルオーバー、バックアップとリカバリ、ローリング・アップグレード、ローリング構成変更など、広範囲にわたる高可用性機能が組み込まれています。これにより、エンタープライズ・デプロイメントが計画外の停止時間から保護され、計画された停止時間が最小限に抑えられます。これらの機能は、1つのデータ・センター内でローカルの高可用性ソリューションを提供します。

さらに、アプリケーションでは、データセンター全体に影響を与える可能性のある予期しない災害、自然災害、ダウンタイムからの保護が必要です。ほとんどの従来の障害保護システムでは、本番サイトとは地理的に異なる場所にスタンバイ・サイトを設定するアクティブ/パッシブ・モデルが使用されます。このモデルは、通常、サイト間の待機時間が長く、2つのサイト間でのクラスタリングが許可されていない場合に採用されます。このアプローチは、完全な最大可用性アーキテクチャ(MAA)保護を提供します。ただし、スタンバイ・ミドルウェア・システムはプライマリ・システムをミラー化し、連続レプリケーションを必要とするため、運用および管理コストが増大します。このモデルは、『Oracle Fusion Middleware障害時リカバリ・ガイド』で説明されています。

このプレイブックでは、別のモデル(Oracle Fusion Middlewareストレッチ・クラスタに基づくアクティブ/アクティブ・モデル)について説明します。これは、複数の場所にわたるダウンタイムからOracle Fusion Middlewareシステムを保護するために使用できます。このモデルでは中間層にアクティブ- アクティブ構成を使用し、データベース層ではData Guardでアクティブ- パッシブ構成を使用します。容量を最適化し、ワークロードをサイト全体に分散するように設計されています。スタンバイ・マシンをアイドル状態のままにするのではなく、使用可能なすべてのリソースを使用することで、アクティブ/パッシブ・モデルよりもリソースを効果的に利用します。このモデルは、FMWストレッチ・クラスタ・デプロイメントと呼ばれます。

特に、このプレイブックでは、このモデルをOracle Cloud Infrastructure (OCI)リージョンにまたがって実装する方法について説明します。ここでは、推奨されるトポロジを設定するための構成ステップと、この設定のパフォーマンスおよびフェイルオーバーへの影響に関するガイダンスを示します。

このプレイブックの結果と例は、エンタープライズ・デプロイメント・ガイド・アーキテクチャに従ったOracle SOA Suite 14.1.2システムに基づいています。これは、標準のJakartaコンポーネント、HTTPセッション・レプリケーション、データベース・メタデータの永続性、Coherenceクラスタ、Java Message Service (JMS)とJavaトランザクションAPI (JTA)の両方の永続ストアなどの多くの機能、およびストレッチされたクラスタに関するその他の関連する考慮事項が含まれているため、重要な例です。その結果、記述されたトポロジおよび推奨事項を他のOracle Fusion Middleware環境にも適用できます。

用語

このプレイブックで使用されるいくつかの用語の定義を次に示します。

  • 中間層(中間層またはミドルウェア)

    中間層とは、ユーザー・インタフェース(フロント・エンド)とデータ・ストレージ(バック・エンド)の間に位置する、複数層のアプリケーション・アーキテクチャ内のレイヤーを指します。ビジネス・ロジック、データ処理およびセキュリティを処理し、ユーザーとデータベース間のブリッジとして機能します。

  • Oracle Fusion Middleware

    Oracle Fusion Middlewareは、Oracleのエンタープライズ・ミドルウェア製品の包括的なファミリであり、組織がアプリケーションを効率的かつ安全に構築、デプロイおよび管理できるようにします。これには、アプリケーション・サーバー、統合、ビジネス・プロセス管理、ビジネス・インテリジェンス、セキュリティ、アイデンティティ管理、Webサーバーなどのソリューションが含まれます。

  • 災害

    サイトまたは地理的に許容できないダメージまたは損失を引き起こす、突然かつ計画外の致命的なイベント。この障害というイベントが発生すると、許容できないほどの期間にわたって、重大な機能、プロセスまたはサービスを提供する機会を損なうので、組織はそのリカバリ計画を起動します。

  • ディザスタ・リカバリ

    地理的に異なるスタンバイ・サイトにアプリケーションやデータを格納するためのリカバリ戦略を備えることで、本番サイトでの自然事故や計画外停止に対する保護対策の機能です。

  • Oracle最大可用性アーキテクチャ

    Oracle Maximum Availability Architecture (Oracle MAA)は、Oracle製品(Oracle Database、Oracle Fusion Middleware、Applications)のデータ保護と可用性のためのベストプラクティスの青写真です。Oracle MAAのベスト・プラクティスの実装は、Oracleデプロイメントの主要な要件の1つです。Oracleシステムを設定および管理するための推奨事項を提供します。Oracle MAAには、Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドの推奨事項が含まれており、災害保護のベスト・プラクティスを追加して、データ・センターまたはリージョン全体に影響する停止の計画的および計画外の停止時間を最小限に抑えます。関連ドキュメントおよびその他のリソースへのリンクについては、「まとめの問題」の項を参照してください。

  • サイト(またはデータ・センター)

    サイトとは、アプリケーションのグループを実行するのに必要な、データ・センター内の様々なコンポーネントのセットを指します。たとえば、サイトは、Oracle Fusion Middlewareインスタンス、データベース、ストレージなどで構成されます。

  • システム

    システムとは、相互に機能してアプリケーションをホストする、一連のターゲット(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、Oracle Enterprise Managerでアプリケーションをモニターするには、最初に、データベースが動作するターゲットであるデータベース、リスナー、アプリケーション・サーバーおよびホストで構成される、システムを作成します。

  • ストレッチされたクラスタ

    ストレッチされたクラスタとは、単一の論理クラスタ内のノードが地理的に異なるデータ・センターまたは場所に分散されるクラスタ・アーキテクチャのことです。

  • スイッチオーバー

    スイッチオーバーとは、本番サイトとスタンバイ・サイトのロールを逆転させるプロセスのことです。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。このプレイブックでは、サイトのスイッチオーバーを指す用語としてスイッチオーバーも使用します。

  • スイッチバック

    スイッチバックとは、現在の本番サイトおよび現在のスタンバイ・サイトをそれらの元の役割に戻すプロセスのことです。スイッチバックは、スイッチオーバー処理の完了後に行う計画済の操作です。スイッチバックを行うと、各サイトの元のロールがリストアされます。具体的には、現在のスタンバイ・サイトが本番サイトになり、現在の本番サイトがスタンバイ・サイトになります。このプレイブックでは、サイトのスイッチバックを指す用語としてスイッチバックも使用します。

  • フェイルオーバー

    フェイルオーバーとは、(本番サイトに障害が発生したこと等が原因で)本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトに新しい本番サイトにするプロセス。このプレイブックでは、サイトのフェイルオーバーを指す用語として「フェイルオーバー」も使用します。

  • リカバリ・ポイントの目標(RPO)

    リカバリ・ポイント目標は、停止が発生したときに許容されるデータ損失の量など、ビジネス観点からシステムが許容できるデータ損失の量です。

  • 回復時間目標(RTO)

    リカバリ時間の目標は、システムが許容できる停止時間、または停止が発生してもアプリケーションやサービスを使用できないままにできる許容可能な時間の量です。

  • Oracle Cloud Infrastructure

    Oracle Cloud Infrastructure (OCI)は、可用性の高いホスト環境で幅広いアプリケーションおよびサービスを構築および実行できる、補完的なクラウド・サービスのセットである。OCIは、オンプレミス・ネットワークの安全にアクセスできる柔軟なオーバーレイ仮想ネットワークにおいて、高パフォーマンスなコンピュート機能(物理ハードウェア・インスタンスとして使用可能)とストレージ容量を提供しています。

  • OCIのリージョン

    OCIリージョンとは、可用性ドメインをホストする1つ以上のデータ・センターを含む、ローカライズされた地理的領域のことです。リージョンは他のリージョンから独立しており、長距離の場合は複数の国または大陸にまたがる領域を分離できます。

    リージョンは、ディザスタ・リカバリに関するサイトです。

  • 可用性ドメイン

    可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、あるアベイラビリティ・ドメインでの障害が、リージョン内の他のアベイラビリティ・ドメインに影響を及ぼすことはありません。

  • OCI仮想クラウド・ネットワークおよびサブネット

    仮想クラウド・ネットワーク(VCN)は、ソフトウェアで定義されたカスタマイズ可能なネットワークであり、OCIリージョン内に設定します。従来のデータ・センター・ネットワークと同様に、VCNsではネットワーク環境を制御できます。VCNには、VCNの作成後に変更できる重複しないクラスレス・ドメイン間ルーティング(CIDR)ブロックを複数に含めることができます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

  • 動的ルーティング・ゲートウェイ(DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

  • OCI DNS

    Oracle Cloud Infrastructure Domain Name System (DNS)サービスは、高度にスケーラブルなグローバル・エニーキャスト・ドメイン・ネーム・システム(DNS)であり、DNSのパフォーマンス、自己回復性およびスケーラビリティが向上するため、エンド・ユーザーがどこからでもインターネット・アプリケーションに簡単に接続できます。

  • OCI DNSプライベート・表示

    OCI DNSプライベート・ビューは、1つ以上のOCIプライベートDNSゾーンのコレクションで、DNSゾーンを論理的にグループ化して解決方法を制御するために使用されます。ビューはプライベートDNSリゾルバにアタッチされます。これは、仮想クラウド・ネットワーク(VCN)のデフォルト・リゾルバまたはカスタム・リゾルバです。これにより、VCN内の環境またはアプリケーションごとに個別のDNS構成を管理できます。

  • 仮想IP

    仮想IP (VIP)アドレスは、特定の物理ネットワーク・インタフェースまたはデバイスに関連付けられていないIPアドレスを指します。代わりに、これは抽象化され、デバイス間で移動したり、さまざまなネットワーク機能に使用したりできます。

  • OCIトラフィック管理

    OCI Traffic Managementは、高度なDNSベースのポリシー(OCIトラフィック・ステアリング・ポリシー)を使用して、ユーザー・トラフィックを最適なエンドポイントにインテリジェントに誘導します。これにより、組織はDNSクエリの解決方法を制御し、クライアント・リクエストのルーティングを最適化して、OCIまたは他の場所に導入されたアプリケーションまたはサービスの可用性、パフォーマンスおよび回復性を向上させることができます。

  • ロード・バランサー

    ロード・バランサは、受信ネットワーク・トラフィックを複数のサーバーに分散して、アプリケーションの高可用性、信頼性、最適なパフォーマンスを実現するシステムまたはサービスです。

  • OCIロード・バランサ

    OCI Load Balancerは、受信トラフィックを複数のバックエンド・サーバーまたはリソースに自動的に分散し、アプリケーションの高可用性、パフォーマンスの向上およびスケーラビリティを実現する、フルマネージドのOracle Cloud Infrastructureサービスです。

  • ブロック・ストレージ

    ブロック・ストレージは、情報が固定サイズのブロックに保存され、iSCSIやファイバ・チャネルなどのストレージ・プロトコルを介してサーバーやアプリケーションによって直接アクセスできる一種のデータ・ストレージです。

  • OCIブロック・ボリューム

    Oracle Cloud Infrastructure Block Volumesでは、ストレージ・ボリュームを作成、アタッチ、接続および移動し、ストレージ、パフォーマンスおよびアプリケーションの要件を満たすようにボリューム・パフォーマンスを変更できます。ボリュームをインスタンスにアタッチおよび接続した後は、そのボリュームを通常のハード・ドライブのように使用できます。また、データを失わないで、ボリュームの切断および別のインスタンスにアタッチできます。

  • 共有ストレージ

    共有ストレージとは、IT環境内の複数のサーバー、コンピュータまたはアプリケーションによって同時にアクセスできるストレージ・システムまたはリソースのことです。この設定により、すべての関連システムが同じデータ・リポジトリに対して読取りおよび書込みを行うことが可能になり、データの一貫性、コラボレーション、高可用性およびスケーラビリティを必要とするシナリオに最適です。

  • OCI File Storage

    Oracle Cloud Infrastructure File Storageは、永続的かつスケーラブルで安全な、エンタープライズ・グレードのネットワーク・ファイル・システムを提供します。VCN内の任意のベア・メタル、仮想マシンまたはコンテナ・インスタンスからOCIファイル・ストレージに接続できます。Oracle Cloud Infrastructure FastConnectおよびIPSec VPNを使用して、VCNの外部からOCI File Storageにアクセスすることもできます。

  • OCIデータベース・サービス

    OCIデータベース・サービスは、Oracle Cloud Infrastructure (OCI)によって提供されるマネージド・データベース・ソリューションのポートフォリオを指します。これらのサービスは、様々なワークロード、パフォーマンス・ニーズ、およびデータ・モデル(Oracle Base Database ServiceやOracle Exadata Database Serviceなど)をサポートする、Oracle Cloudでの様々なデータベース・デプロイメントおよび管理オプションを提供します。

  • Oracle Data Guard

    Oracle Data GuardおよびActive Data Guardは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービスのセットを提供し、本番Oracleデータベースを障害なく使用できるようにする。Oracle Data Guardでは、インメモリー・レプリケーションを使用して、これらのスタンバイ・データベースを本番データベースのコピーとして維持します。計画停止または計画外停止により、本番データベースが使用できなくなった場合、Oracle Data Guardはいずれかのスタンバイ・データベースを本番ロールに切り替えることで、停止に伴う停止時間を最小化できます。Oracle Active Data Guardには、read-mostlyワークロードをスタンバイ・データベースにオフロードする追加機能と、高度なデータ保護機能があります。

このプレイブックでは、Oracle Fusion Middlewareストレッチ・クラスタをデプロイするためのインフラストラクチャの例としてOCIを使用します。Oracle Fusion Middlewareストレッチ・クラスタ設定に必要な主要コンポーネントのオンプレミスからOCIへの等価性は次のとおりです:

オンプレミス(または汎用) OCI同等
サイト(またはデータ・センター) OCIリージョン
共有記憶域(NFSなど) OCI File Storage
ブロック・ストレージ OCIブロック・ボリューム
グローバル・ロード・バランサ OCI Traffic Managementおよびステアリング・ポリシー
ローカル・ロード・バランサ OCIロード・バランサ
ネットワーク OCI仮想クラウド・ネットワーク
ファイアウォール/ファイアウォール・ルール OCIネットワーク・セキュリティ・ルール
内部DNS OCI DNSプライベート・表示
物理サーバー/仮想マシン OCI Computeインスタンス
オンプレミスのデータベース OCIデータベース・サービス
サイト間のオンプレミス接続 動的ルーティング・ゲートウェイを使用したOCIリモート・ピアリング

アーキテクチャ

この項では、Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・アーキテクチャのトポロジおよび考慮事項について説明します。

FMWストレッチ・クラスタ・アーキテクチャには、次の考慮事項が適用されます。

  • リージョン

    このトポロジには、2つのリージョン(サイト)があります。それらの間の待機時間は、10ミリ秒の往復時間(RTT)を超えないようにしてください。帯域幅の要件は、各システムで処理されるペイロードのタイプによって異なりますが、1秒あたり最低1ギガビットまたは2ギガビット(Gbps)が推奨されます。

  • 中間階層

    中間層は、単一のドメインを持つアクティブ/アクティブ・モデルで動作します。管理対象サーバーの半分は、一方のサイトに配置され、もう一方のサイトに配置されます。管理サーバーはあるサイトで実行されますが、必要に応じて別のサイトにフェイルオーバーできます。この設定は、通常、ストレッチされたクラスタと呼ばれます。

  • データベース階層

    データベース層では、Oracle Data Guardでサポートされているアクティブ/パッシブ・アーキテクチャを使用します。プライマリ・データベースは1つのサイトに配置され、スタンバイ・データベースはもう一方のサイトに配置されます。すべての中間層サーバーは、その場所に関係なく、現在プライマリとして機能しているデータベースに接続するように構成されます。各サイトで構成されたOracle Databaseは、Oracle Real Application Clusters (Oracle RAC)です。Oracle RACを使用すると、Oracleデータベースを同じデータ・センター内のサーバーのクラスタ全体に実行することができるようになり、アプリケーションを変更せずにフォルト・トレランス、パフォーマンスおよびスケーラビリティを向上させることができます。

  • 記憶域

    共有ストレージは各サイトに対してローカルです。競合およびセキュリティ上の理由から、サイト間で共有記憶域を使用することはお薦めしません。site1からsite2へのディスク・ミラーリングまたはレプリケーション(およびその逆)を使用して、各サイトのアーティファクトのリカバリ可能なコピーを提供することをお薦めします。

  • 永続ストア

    WebLogic永続ストア(Java Message Service (JMS)およびJava Transaction API (JTA))は、データベース内のJava Database Connectivity (JDBC)ストアとして構成されます。これにより、両サイトからアクセス可能になります。これにより、自動サービス移行機能が両方のサイト間で機能するようになります。

  • 転送のリクエスト

    各サイトのWebサーバーは、同じサイトにあるOracle WebLogic Serverインスタンスにのみリクエストを転送します。レイテンシとリージョン間のトラフィックを最小限に抑えるために、Webサーバー(Oracle HTTP Serverインスタンス)と他サイトのWebLogicサーバー間のリージョン間通信はありません。

  • ロード・バランサー

    各サイトには専用のロード・バランサがあり、リクエストはそのローカル・サイト内のWebサーバーに排他的に転送されます。ロード・バランサと他方のサイトにあるWebサーバー間には、リージョン間通信はありません。

  • フロントエンド・アクセス

    システムの前面では、このソリューションはシステムへの単一のフロントエンドアクセスを提供します。クライアントは、転送先のサイトに関係なく、同じままの単一のアドレスを使用して接続します。このメカニズムは、すべてのクライアントからアクセス可能なドメインネームシステム(DNS)名を提供し、クライアントの地理的な場所などの事前定義された条件とルールに基づいて、要求をいずれかのサイトにルーティングします。

次の図は、Oracle Fusion Middlewareストレッチ・クラスタ・トポロジを示しています


stretch-cluster-topology.pngの説明が続きます
図stretched-cluster-topology.pngの説明

ストレッチ・クラスタ・トポロジ-oracle.zip

次の図は、Oracle Fusion Middlewareストレッチ・クラスタ・トポロジのWebLogicドメインおよびクラスタを示しています。


stretch-cluster-topology-wls-domain.pngの説明が続きます
図stretched-cluster-topology-wls-domain.pngの説明

ストレッチされたクラスタトポロジー-wls-domain-oracle.zip

長所

従来のアクティブ/パッシブ・モデルに対してOracle Fusion Middleware (FMW)ストレッチ・クラスタ・モデルを使用する利点は次のとおりです。
  • シンプルな管理

    アクティブ/パッシブ・デプロイメントでは、プライマリ・サイトとスタンバイ・サイトの間で構成の同期を維持するために、追加の管理オーバーヘッドが発生します。ほとんどの実行時情報およびメタデータはデータベース内に存在しますが、Oracle WebLogic Server構成はファイル・システム内に存在します。したがって、アクティブ/パッシブ・モデルには、データベースのOracle Data Guardレプリケーションに加えて、様々な方法で実装できる継続的なファイル・システム・レプリケーション(同期、ストレージ・レベルのレプリカなど)が必要です。

    ただし、FMWストレッチ・クラスタ・モデルでは、Oracle WebLogic Serverインフラストラクチャにより、同じドメイン内の複数のノード間で構成の同期が維持されます。この構成の大半は通常、管理サーバーのドメイン・ディレクトリにあります。この構成は、管理対象サーバーの起動時または変更が実装されたときに、同じドメイン内の他のノードに自動的に伝播されます。このため、構成変更の定期的なレプリケーションが必要なアクティブ/パッシブ・アプローチと比較して、デプロイメントの管理オーバーヘッドは非常に小さくなります。

  • 一部のフェイルオーバー・シナリオでの可用性の向上とRTOおよびRPOの削減

    FMWストレッチ・クラスタ・モデルでは、次のシナリオでアクティブ/パッシブ・モデルよりもリカバリ・ポイント目標(RPO)とリカバリ時間目標(RTO)の方が優れています。

    • 1つのサイト・イベントでの完全な中間層の障害

      1つの場所にあるすべての中間層サーバーに障害が発生した場合、システムはピア・サイトの中間層サーバーでリクエストをただちに処理し続けることができます。このタイプのシナリオでは、RTOとRPOはゼロです。

      これを実現するには、代替の場所にある中間層サーバーが、2つの場所の複合ワークロードを維持できる必要があります。このようなシナリオを考慮して、適切なキャパシティ・プランニングを行う必要があります。1つのサイトのみがアクティブな場合、設計によっては、エンド・クライアントからのリクエストのスロットルが必要になる場合があります。それ以外の場合、サイトは、絶え間ない容量で設計され、一定で効率的な容量使用の目的を部分的に破る必要があります。

    • データベース層イベントの障害

      データベースのスイッチオーバーでは、アクティブ/パッシブおよびFMWストレッチ・クラスタ・モデルで同じRTOおよびRPOが発生します。ただし、中間層サーバーがセカンダリ・サイトですでにアクティブであるため、ストレッチされたクラスタ・モデルではシステム全体のRTOが低くなります。中間層の再起動は必要ありません。適切なデータ・ソース構成は、GridLinkおよび高速アプリケーション通知(FAN)通知を含む二重接続文字列を使用して、中間層からのデータベース接続を自動化し、システムRTOを削減します。

考慮事項

Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・モデルを実装する場合は、次の点を考慮してください。
  • キャパシティ計画

    このモデルでは、2つのサイト間のフェイルオーバー・シナリオを考慮して容量計画が必要です。サイト全体が中間層を失う場合、もう一方は完全なワークロードを維持できる必要があります。そうしないと、オーバーヘッドが原因で、使用可能なサイトが応答しなくなる可能性があります。つまり、通常の操作では、フェイルオーバー・シナリオを処理するのに十分な容量を確保するために、中間層ノードの使用率を低くする必要があります。同じルールがWeb層にも適用されます。1つのサイトがすべてのWebサーバーを失った場合、もう一方のサイトのWebサーバーはすべてのシステム要求を処理できる必要があります。

  • サイト間のネットワーク・スループット

    ネットワークのスループットは主に、サイトがどの程度あるか、およびネットワークが信頼性と輻輳をどの程度うまく処理しているかという2つの点によって決まります。サーバーやソフトウェアがどれだけ高速であっても、サイト間でデータがどの程度迅速に移動できるかに制限があります。これに影響する2つの重要な要因は、レイテンシとジッターです。

    • 「レイテンシ」は、あるサイトから別のサイトへのネットワーク全体のデータの移動にかかる時間です。これは、一方向(ソースから宛先)または往復(ここおよび戻る)で測定できます。ラウンドトリップ時間(RTT)はより一般的であり、pingコマンドで確認できます。

    • Jitterは、データパケットの到着にかかる時間の変化です。

    現在のモデルでは、待機時間を低く保つことが特に重要です。ジッタは通常、待機時間がすでに非常に低い場合にのみ重要です。したがって、この種の設定では、待機時間の制御が良好なパフォーマンスの主な優先事項です。通常、距離はレイテンシの最も関連性の高い原因です。

    実施されたテストは、このモデル(クラスタ内の一部のOracle WebLogic Serverインスタンスがデータベースとは異なるサイトにある)のパフォーマンスが、レイテンシ(RTT)が10ミリ秒を超えると大幅に低下することを示しています。

    複数のテストがOracleによって実行され、異なるレイテンシの影響を受ける構成が異なります。このプレイブックに表示される参照レイテンシは、次のクラスタを区別します。
    • 同じ可用性ドメインのすべてのメンバー
    • 異なる可用性ドメインのメンバー
    • 近くの2つのOCIリージョンのメンバー

    次の図は、Fusion Order Demo (FOD)を実行しているOracle Fusion Middleware SOAシステムのスループット(1秒当たりのトランザクション数)を、WebLogicサーバーとデータベース間の異なるレイテンシで示しています。


    wls-server-throughput.pngの説明が続きます
    図wls-server-throughput.pngの説明

    次の図は、異なるサイト上のデータベースを使用するFusion Order Demo (FOD)を実行しているOracle Fusion Middleware SOAシステムのJava Transaction API (JTA)のアクティブ時間で、サイト間のレイテンシが異なります。


    wls-average-jta-active-time.pngの説明が続きます
    図wls-average-jta-active-time.pngの説明

    次の図は、サイト間の異なるレイテンシ(両方のサイトがいずれかのサイトでデータベースと連携して動作している)について、1秒当たりのトランザクションにおけるシステム全体のスループットが低下していることを示しています。


    system-throughput.pngの説明が続きます
    図system-throughput.pngの説明

    ノート:

    前述のすべてを考慮し、多くのテストでパフォーマンス・ペナルティが確認されたため、Oracleでは、サイト間のレイテンシ(RTT)が10ミリ秒を超えるOracle Fusion Middlewareストレッチ・クラスタはサポートされません。システムは問題なく動作する可能性がありますが、トランザクション時間は大幅に増加します。レイテンシが10ミリ秒(RTT)を超えると、デプロイメントおよびJTA、Webサービスまたはアプリケーション・タイムアウトに使用されるOracle Coherenceクラスタでも問題が発生します。これにより、このプレイブックに示されているソリューションは、主にサイトまたはリージョン間のレイテンシが低い場合に適しています。

  • リージョン間のトラフィック

    現在のモデルでは、システムのスループットに対する待機時間の影響を軽減するために、サイト間のトラフィックを最小化する必要があります。一般的なFMWシステムでは、異なる層または要素間の通信は次のようになります。

    • メタデータ・アクセスおよびその他のデータベースの読取り/書込み操作のために、Oracle WebLogic Serverインスタンスからデータベースにアクセスします。

    • ロード・バランサ(LBR)またはOracle HTTP Serverインスタンスからの受信HTTP呼出しおよびHTTPコールバック。

    • Oracle WebLogic Serverインスタンス間のJava Naming and Directory Interface (JNDI)/Remote Method Invocation (RMI)およびJava Message Service (JMS)呼出し。

    • システム内のすべてのサーバー間のOracle Coherence通知。たとえば、SOAではCoherenceを使用して、一貫性のあるコンポジットおよびメタデータ・イメージを提供します。

    • Oracle WebLogic Serverインスタンス間のHTTPセッション・レプリケーション。サーバー間でのセッションを透過的にフェイルオーバーできるようにするため、一部のコンポーネントではセッション・レプリケーションに依存する可能性があるステートフルなWebアプリケーションが使用されます。使用パターンとユーザー数によっては、かなりの量のレプリケーション・データが生成される場合があります。

    • Lightweight Directory Access Protocol (LDAP)/policy/identityストア・アクセスは、認可および認証のためにOracle WebLogic Serverインフラストラクチャによって実行されます。各サイトに独立したアイデンティティおよびポリシー・ストアがあり、定期的に同期して、一方のサイトからもう一方のサイトへの呼出しが最小限になることが理想的です。または、両方のサイトで同じストアを共有できます。ストアの共有の影響は、ストアのタイプとシステムの使用パターンによって異なります。

    可能な限り、パフォーマンスを向上させるために、上記のすべてをサイト内に含める必要があります。たとえば:

    • 1つのサイトのサーバーは、同じサイトのOracle HTTP Serverインスタンスからの呼出しのみを受信する必要があります。

    • 1つのサイト内のサーバーは、同じサイト内のサーバーに対してのみJMS、RMIおよびJNDI呼出しを行い、同じサイト内のサーバーによって生成されたコールバックのみを取得する必要があります。

    • HTTPセッション・レプリケーションは、同じサイト内の他のサーバーのみに制限する必要があります。レプリケーションとフェイルオーバーの要件をビジネス・ケースごとに分析する必要がありますが、セッション・レプリケーション・トラフィックをサイト間で可能なかぎり削減することが理想的です。

  • 共有ストレージ

    サイト間のネットワーク・ファイル・システム(NFS)書込みの待機時間によって、パフォーマンスが著しく低下する可能性があります。サーバーは、ファイル・システムへの読取り/書込みリクエストの競合を排除するために、サイトにローカルなストレージ・デバイスを使用する必要があります。共有記憶域は、各サイト内に限定する必要があります。

  • その他のリソース

    2つのサイトでは、LDAP、外部JMS宛先、外部Webサービスなど、他の外部リソースを共有できます。これらのリソースは、両方のサイトで一貫して使用可能にする必要があります。これらの外部リソースの構成の詳細は、このプレイブックの対象外です。