チュートリアル: 高可用性とディザスター リカバリーを使用して Oracle WebLogic Server を Azure Virtual Machines に移行する

このチュートリアルでは、Azure Virtual Machines (VM) で Oracle WebLogic Server (WLS) を使用して Java の高可用性とディザスター リカバリー (HA/DR) を実装する簡単で効果的な方法について説明します。 このソリューションは、WLS で実行されている単純なデータベース 駆動型 Jakarta Enterprise Edition アプリケーションを使用して、目標復旧時間 (RTO) と目標復旧時点 (RPO) を低くする方法を示しています。 HA/DR は複雑なトピックであり、多くのソリューションが考えられます。 最適なソリューションは、独自の要件によって異なります。 HA/DR を実装するその他の方法については、この記事の最後にあるリソースを参照してください。

このチュートリアルでは、次の作業を行う方法について説明します。

  • Azure で最適化されたベスト プラクティスを使用して、高可用性とディザスター リカバリーを実現します。
  • ペアになっているリージョンに Microsoft Azure SQL Database フェールオーバー グループを設定します。
  • Azure VM でペアになっている WLS クラスターを設定します。
  • Azure Traffic Manager を設定します。
  • 高可用性とディザスター リカバリーに WLS クラスターを構成します。
  • プライマリからセカンダリへのフェールオーバーをテストします。

次の図は、構築したアーキテクチャを示しています。

高可用性とディザスター リカバリーを備えた Azure VM 上の WLS のソリューション アーキテクチャの図。

Azure Traffic Manager は、リージョンの正常性をチェックし、それに応じてアプリケーション層にトラフィックをルーティングします。 プライマリ リージョンとセカンダリ リージョンの両には、完全な WLS クラスターのデプロイがあります。 ただし、プライマリ リージョンのみが、ユーザーからのネットワーク要求にアクティブに対応します。 セカンダリ リージョンはパッシブであり、プライマリ リージョンでサービスの中断が発生した場合にのみトラフィックを受信するようにアクティブ化されます。 Azure Traffic Manager は、Azure Application Gateway の正常性チェック機能を使用して、この条件付きルート指定を実装します。 プライマリ WLS クラスターが実行され、セカンダリ クラスターがシャットダウンされます。 アプリケーション層の geo フェールオーバー RTO は、VM の起動時間およびセカンダリ WLS クラスターの実行時間によって異なります。 RPO は、Azure SQL Database によって異なります。これは、データが Azure SQL Database フェールオーバー グループに保持され、レプリケートされるためです。

データベース層は、プライマリ サーバーとセカンダリ サーバーを含む Azure SQL Database フェールオーバー グループで構成されます。 プライマリ サーバーはアクティブな読み取り/書き込みモードで、プライマリ WLS クラスターに接続されています。 セカンダリ サーバーはパッシブの準備完了モードで、セカンダリ WLS クラスターに接続されています。 geo フェールオーバーでは、グループ内のすべてのセカンダリ データベースがプライマリ ロールに切り替まれます。 Azure SQL Database の geo フェールオーバー RPO と RTO については、「ビジネス継続性の概要」を参照してください。

この記事は、そのサービスの高可用性 (HA) 機能に依存しているため、Azure SQL Database サービスで記述されています。 他のデータベースを選択することもできますが、選択したデータベースの HA 機能を考慮する必要があります。 レプリケーション用のデータ ソースの構成を最適化する方法の詳細については、「Oracle Fusion ミドルウェアのアクティブ/パッシブ デプロイ用のデータ ソースの構成」を参照してください。

前提条件

ペアになっているリージョンで Azure SQL Database フェールオーバー グループを設定する

このセクションでは、WLS クラスターとアプリで使用するために、ペアになっているリージョンで Azure SQL Database フェールオーバー グループを作成します。 後のセクションで、セッション データとトランザクション ログ (TLOG) データをこのデータベースに格納するように WLS を構成します。 この方法は、Oracle Maximum Availability Architecture (MAA) と一貫しています。 このガイダンスでは、MAA に対する Azure の適応について説明します。 MAA の詳細については、「Oracle Maximum Availability Architecture」を参照してください。

まず、「クイック スタート: 単一データベースの作成 - Azure SQL Database」の Azure Portal 手順に従ってプライマリ Azure SQL Database を作成します。 次の手順 (「リソースのクリーンアップ」セクションの前まで) に従います。 記事を読み進んで指示に従い、Azure SQL Database を作成して構成したら、この記事に戻ります。

  1. 「単一データベースの作成」のセクションまでいったら、次の手順を実行します。

    1. 新しいリソース グループを作成する手順 4 で、たとえば、myResourceGroup など [リソース グループ名] の値を保存しておきます。
    2. データベース名の手順 5 で、たとえば、mySampleDatabase など [データベース名] の値を保存しておきます。
    3. サーバーを作成する手順 6 では、次の手順を実行します。
      1. たとえば、sqlserverprimary-ejb120623 などの一意のサーバー名を保存しておきます。
      2. [場所] で、[(米国) 米国東部] を選択します。
      3. [認証方法] に、[SQL 認証を使用] を選択します。
      4. たとえば、azureuser など [サーバー管理者のログイン] の値を保存しておきます。
      5. [パスワード] の値を保存しておきます。
    4. 手順 8 では、[ワークロード環境][開発] を選択します。 説明を確認し、ワークロードのその他のオプションを検討します。
    5. 手順 11 では、[バックアップ ストレージの冗長性][ローカル冗長バックアップ ストレージ] を選択します。 バックアップの他のオプションを検討してください。 詳細については、「Azure SQL Database での自動バックアップ」「バックアップ ストレージの冗長性」セクションを参照してください。
    6. 手順 14 では、[ファイアウォール規則の構成] [Azure サービスとリソースにこのサーバーへのアクセスを許可する] で、[はい] を選択します。
  2. 「データベースのクエリ」セクションにいったら、次の手順を実行します。

    1. 手順 3 で、サインインする SQL 認証サーバー管理者のサインイン情報を入力します。

      Note

      [IP アドレス「xx.xx.xx.xx」のクライアントはこのサーバーにアクセスできません] のようなエラー メッセージが表示されサインインできない場合は、エラー メッセージの末尾にある [Allowlist IP xx.xx.xx.xx on server <your-sqlserver-name]> を選択します。 サーバー ファイアウォール規則の更新が完了するまで待機してから、[OK] を再度選択します。

    2. 手順 5 でサンプル クエリを実行した後、エディターをクリアしてテーブルを作成します。

次のクエリを入力して、TLOG のスキーマを作成します。

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

正常に実行されると、"クエリが成功しました: 影響を受ける行: 0" というメッセージが表示されます。

これらのデータベース テーブルは、WLS クラスターとアプリのトランザクション ログ (TLOG) とセッション データを格納するために使用されます。 詳細については、「JDBC TLOG ストアの使用」「永続ストレージ用データベースの使用 (JDBC 永続性)」を参照してください。

次に、「Azure SQL Database のフェールオーバー グループを構成する」の Azure portal の手順に従って、Azure SQL Database フェールオーバー グループを作成します。 必要なセクションは、「フェールオーバー グループの作成」「計画フェールオーバーのテスト」のみです。 記事を読み進んで手順に従い、Azure SQL Database フェールオーバー グループを作成して構成したら、この記事に戻ります。

  1. 「フェールオーバー グループの作成」セクションにきたら次の手順を実行します。

    1. フェールオーバー グループを作成するための手順 5 で、新しいセカンダリ サーバーを作成するオプションを選択し、次の手順を実行します。
      1. フェールオーバー グループ名 (failovergroupname-ejb120623 など) を入力して保存しておきます。
      2. たとえば、sqlserversecondary-ejb120623 などの一意のサーバー名を入力して保存しておきます。
      3. プライマリ サーバーと同じサーバー管理者とパスワードを入力します。
      4. [場所] で、プライマリ データベースに使用したリージョンとは異なるリージョンを選択します。
      5. [Azure サービスにサーバーへのアクセスを許可する] が選択されていることを確認します。
    2. グループ内のデータベースを構成する手順 5 で、たとえば、mySampleDatabase などのプライマリ サーバーで作成したデータベースを選択します。
  2. 「計画フェールオーバーのテスト」セクションのすべての手順を実行したら、[フェールオーバー グループ] ページを開いたままにして、後で WLS クラスターのフェールオーバー テストに使用します。

Azure VM でペアになっている WLS クラスターを設定する

このセクションでは、Azure VM 上の Oracle WebLogic Server クラスターのオファーを使用して、Azure VM 上に 2 つの WLS クラスターを作成します。 米国東部のクラスターはプライマリであり、後でアクティブ クラスターとして構成します。 米国西部のクラスターはセカンダリであり、後でパッシブ クラスターとして構成します。

プライマリ WLS クラスターを設定する

まず、ブラウザーで [Azure VM の Oracle WebLogic Server クラスター] オファーを開き、[作成] を選択します。 オファーの [基本] ペインが表示されます。

[基本] ペインを入力する手順を実行します。

  1. [サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
  2. このオファーを空のリソース グループにデプロイする必要があります。 [リソース グループ] フィールドで、[新規作成] を選択し、リソース グループに対して固有値 (wls-cluster-eastus-ejb120623 など) を入力します。
  3. [インスタンス詳細][リージョン] で、[米国東部] を選択します。
  4. [仮想マシンと WebLogic の資格情報] で、VM の管理者アカウント[WebLogic 管理者]にそれぞれパスワードを指定します。 [WebLogic 管理者] のユーザー名とパスワードを保存しておきます。
  5. 他のフィールドはデフォルトのままにします。
  6. [次へ] を選択して、[TLS/SSL 構成] ウィンドウに移動します。

Azure VM の [基本] ペインの Oracle WebLogic Server Cluster を示す Azure Portal のスクリーンショット。

[TLS/SSL 構成] ペインは既定値のままにし、[次へ] を選択して [Azure Application Gateway] ペインに移動し、次の手順を実行します。

  1. [Connect to Azure Application Gateway?] (Azure Application Gateway に接続しますか?) には [はい] を選びます。
  2. [目的の TLS/SSL 資格認定オプションを選択] には、[自己署名資格認定を生成] を選択します。
  3. [次へ] を選択して、[ネットワーク] ペインに移動します。

Azure VMs Azure Application Gateway 上の Oracle WebLogic Server Cluster を示す Azure Portal のスクリーンショット。

[ネットワーク] ペインでは、すべてのフィールドに既定値が事前に設定されていることがわかります。 次の手順を実行して、ネットワーク構成を保存します。

  1. [仮想ネットワークを編集] を選択します。 10.1.4.0/23 などの仮想ネットワークのアドレス空間を保存しておきます。

    Azure VM 仮想ネットワーク ペインの Oracle WebLogic Server Cluster を示す Azure Portal のスクリーンショット。

  2. wls-subnet を選択して、サブネットを編集します。 [サブネット詳細] で、10.1.5.0/28 などの開始アドレスとサブネット サイズを保存しておきます。

    仮想ネットワークの Azure VM WLS サブネット ペインの Oracle WebLogic Server Cluster が表示されている Azure Portal のスクリーンショット。

  3. 変更を加えた場合は、変更を保存します。

  4. [ネットワーク] ペインに戻ります。

  5. [次へ] を選択して、[データベース] ウィンドウに移動します。

次の手順は、[データベース] ペインの入力方法を示しています。

  1. [データベースに接続しますか?][はい] を選択します。
  2. [データベースの種類を選択] には、[Microsoft SQL Server (パスワードレス接続をサポート)] を選択します。
  3. [JNDI 名] には、jdbc/WebLogicCafeDB と入力します。
  4. [DataSource 接続文字列] で、プレースホルダーをプライマリ SQL データベースの前のセクションで保存しておいた jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433;database=mySampleDatabase などの値に置き換えます。
  5. [グローバル トランザクション プロトコル] には、[なし] を選択します。
  6. [データベース ユーザー名] で、プレースホルダーをプライマリ SQL データベースの前のセクションで保存しておいた azureuser@sqlserverprimary-ejb120623 などの値に置き換えます。
  7. [データベース パスワード] で前に保存しておいたサーバー管理者のサインイン パスワードを入力します。 [パスワードを確認] と同じ値を入力します。
  8. 他のフィールドはデフォルトのままにします。
  9. [Review + create](レビュー + 作成) を選択します。
  10. [最後の検証を実行中...] が正常に完了するまで待機し、[作成] を選択します。

Azure VM の [データベース] ペインの Oracle WebLogic Server Cluster を示す Azure Portal のスクリーンショット。

しばらくすると、デプロイが進行中[デプロイ] ページが表示されます。

Note

[最後の検証を実行中...] で問題が発生した場合は、修正してから再試行します。

選択したリージョンのネットワークの状態やその他のアクティビティによっては、デプロイが完了するまでに最大 50 分かかる場合があります。 その後、[デプロイ] ページに [デプロイが完了しました] というテキストが表示されます。

それまでの間は、セカンダリ WLS クラスターを同時に設定できます。

セカンダリ WLS クラスターをセットアップします。

次の違いを除き、[プリマり WLS クラスターの設定] セクションと同じ手順を実行して、米国西部リージョンでセカンダリ WLS クラスターを設定します。

  1. [基本] ペインで、次の手順を実行します。

    1. [リソース グループ] フィールドで、[新規作成] を選択し、リソース グループに対して別の固有値 (wls-cluster-westtus-ejb120623 など) を入力します。
    2. [インスタンス詳細][リージョン] で、[米国西部] を選択します。
  2. [ネットワーク] ペインで、次の手順を実行します。

    1. [仮想ネットワークの編集] には、10.1.4.0/23 などプライマリ WLS クラスターと同じ仮想ネットワークのアドレス空間を入力します。

      Note

      「アドレス空間「10.1.4.0/23 (10.1.4.0 - 10.1.5.255)」が仮想ネットワーク「wls-vnet」の「10.1.4.0/23 (10.1.4.0 - 10.1.5.255」と重複しています。重複しているアドレス空間がある仮想ネットワークは、ピアリングできません。これらの仮想ネットワークをピアリングする場合は、アドレス空間を「10.1.4.0/23 (10.1.4.0 - 10.1.5.255」に変更してください。」 のようなワーニング メッセージが表示されます。 同じネットワーク構成を持つ 2 つの WLS クラスターが必要なため、このメッセージは無視できます。

    2. wls-subnet に、たとえば、10.1.5.0/28 など、プライマリ WLS クラスターと同じ開始アドレスとサブネット サイズを入力します。

  3. [データベース] ペインで、次の手順を実行します。

    1. [DataSource 接続文字列] で、プレースホルダーをセカンダリ SQL データベースの前のセクションで保存しておいた jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433;database=mySampleDatabase などの値に置き換えます。
    2. [データベース ユーザー名] で、プレースホルダーをセカンダリ SQL データベースの前のセクションで保存しておいた azureuser@sqlserversecondary-ejb120623 などの値に置き換えます。

2 つのクラスターのネットワーク設定をミラーリングする

フェールオーバー後にセカンダリ WLS クラスターで保留中のトランザクションを再開するフェーズでは、WLS は TLOG ストアの所有権をチェックします。 チェックに正常にパスするには、セカンダリ クラスターのすべてのマネージド サーバーにプライマリ クラスターと同じプライベート IP アドレスを設定する必要があります。

このセクションでは、プライマリ クラスターからセカンダリ クラスターにネットワーク設定をミラーリングする方法について説明します。

まず、次の手順を実行して、デプロイの完了後にプライマリ クラスターのネットワーク設定を構成します。

  1. [デプロイ] ページの [概要] ペインで、[リソース グループに移動] を選択します。

  2. ネットワーク インターフェイスを選択しますadminVM_NIC_with_pub_ip

    1. [設定][IP 構成] を選択します。
    2. [ipconfig1] を選択します。
    3. [プライベート IP アドレス設定] で、[割り当て] に対して [静的]を選択します。 プライベート IP アドレスを保存しておきます。
    4. [保存] を選択します。
  3. プライマリ WLS クラスターのリソース グループに戻り、ネットワーク インターフェイス mspVM1_NIC_with_pub_ipmspVM2_NIC_with_pub_ip および mspVM3_NIC_with_pub_ip に対して手順 3 を繰り返します。

  4. すべての更新が完了するまで待ちます。 Azure Portal で [通知] アイコンを選択すると、状態監視用の [通知] ウィンドウを開くことができます。

    Azure Portal の通知アイコンのスクリーンショット。

  5. プライマリ WLS クラスターのリソース グループに戻り、7e8c8bsaep など種類がプライベート エンドポイントのリソースの名前をコピーします。 この名前を使用して、たとえば、7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a などの残りのネットワーク インターフェイスを検索します。 それを選択し、前の手順に従ってプライベート IP アドレスを取得します。

次に、次の手順を実行して、セカンダリ クラスターのデプロイが完了した後で、ネットワーク設定を構成します。

  1. [デプロイ] ページの [概要] ペインで、[リソース グループに移動] を選択します。

  2. ネットワーク インターフェイス adminVM_NIC_with_pub_ipmspVM1_NIC_with_pub_ipmspVM2_NIC_with_pub_ip および mspVM3_NIC_with_pub_ip の場合は、上記の手順を実行して、プライベート IP アドレス割り当てを [静的] に更新します。

  3. すべての更新が完了するまで待ちます。

  4. ネットワーク インターフェイス mspVM1_NIC_with_pub_ipmspVM2_NIC_with_pub_ip および mspVM3_NIC_with_pub_ip の場合は、上記の手順を実行しますが、プライベート IP アドレスをプライマリ クラスターで使用されているものと同じ値に更新します。 ネットワーク インターフェイスの現在の更新が完了するまで待ってから、次に進みます。

    Note

    プライベート エンドポイントの一部であるネットワーク インターフェイスのプライベート IP アドレスを変更することはできません。 マネージド サーバーのネットワーク インターフェイスのプライベート IP アドレスを簡単にミラーリングするには、使用されていない IP アドレスにadminVM_NIC_with_pub_ip の プライベート IP アドレスを更新することを検討してください。 2 つのクラスターでのプライベート IP アドレスの割り当てによっては、プライマリ クラスターのプライベート IP アドレスも更新する必要があります。

次の表に、2 つのクラスターのネットワーク設定をミラーリングする例を示します。

クラスター ネットワーク インターフェイス プライベート IP アドレス (前) プライベート IP アドレス (後) 更新シーケンス
プライマリ 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a 10.1.5.4 10.1.5.4
プライマリ adminVM_NIC_with_pub_ip 10.1.5.7 10.1.5.7
プライマリ mspVM1_NIC_with_pub_ip 10.1.5.5 10.1.5.5
プライマリ mspVM2_NIC_with_pub_ip 10.1.5.8 10.1.5.9 1
プライマリ mspVM3_NIC_with_pub_ip 10.1.5.6 10.1.5.6
セカンダリ 1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1 10.1.5.8 10.1.5.8
セカンダリ adminVM_NIC_with_pub_ip 10.1.5.5 10.1.5.4 4
セカンダリ mspVM1_NIC_with_pub_ip 10.1.5.7 10.1.5.5 5
セカンダリ mspVM2_NIC_with_pub_ip 10.1.5.6 10.1.5.9 2
セカンダリ mspVM3_NIC_with_pub_ip 10.1.5.4 10.1.5.6 3

各クラスターにデプロイした Azure Application Gateway のバックエンド プールで構成されるすべてのマネージド サーバーのプライベート IP アドレスの一式を確認します。 更新された場合は、次の手順に従って、Azure Application Gateway バックエンド プールを適宜更新します。

  1. クラスターのリソース グループを開きます。
  2. Application gateway タイプの myAppGateway リソースを検索します。 そのストレージ アカウントを選択して開きます。
  3. [設定] セクションで、[バックエンド プール] を選択し、[myGatewayBackendPool] を選択します。
  4. [バックエンド ターゲット] 値を更新したプライベート IP アドレスまたは複数のアドレスで変更し、[保存] を選択します。 完了するまで待機してください。
  5. [設定] セクションで、[正常性プローブ] を選択し、[HTTPhealthProbe] を選択します。
  6. [正常性プローブを追加する前にバックエンド正常性をテストする] が選択されていることを確認したら、[テスト] を選択します。 バックエンド プール myGatewayBackendPool[状態] 値が正常としてマークされていることがわかります。 そうでない場合は、プライベート IP アドレスが想定どおりに更新され、VM が実行されているかどうかをチェックし、正常性プローブをもう一度テストします。 続行する前に、問題のトラブルシューティングと解決を行う必要があります。

次の例では、各クラスターの Azure Application Gateway バックエンド プールが更新されます。

クラスター Azure Application Gateway バックエンド プール バックエンド ターゲット (前) バックエンド ターゲット (後)
プライマリ myGatewayBackendPool (10.1.5.5, 10.1.5.8, 10.1.5.6) (10.1.5.5, 10.1.5.9, 10.1.5.6)
セカンダリ myGatewayBackendPool (10.1.5.7, 10.1.5.6, 10.1.5.4) (10.1.5.5, 10.1.5.9, 10.1.5.6)

ネットワーク設定のミラーリングを自動化するには、Azure CLI の使用を検討してください。 詳細については、Azure CLI の概要に関するページをご覧ください。

クラスターのデプロイを確認する

各クラスターに Azure Application Gateway と WLS 管理サーバーをデプロイしました。 Azure Application Gateway は、クラスター内のすべてのマネージド サーバーのロード バランサーとして機能します。 WLS 管理サーバーには、クラスター構成用の Web コンソールが用意されています。

次の手順に進む前に、各クラスターの Azure Application Gateway と WLS 管理コンソールが機能するかどうかを確認するには、次の手順を実行します。

  1. [デプロイ] ページに戻り、[出力] を選択します。
  2. プロパティ appGatewayURL の値をコピーします。 文字列 weblogic/ready を追加し、その URL を新しいブラウザー タブで開きます。エラー メッセージなしで空のページが表示されます。 表示されない場合、問題のトラブルシューティングと解決を行う必要があります。
  3. プロパティ adminConsole の値をコピーして保存しておきます。 新しいブラウザー タブで開きます。[WebLogic Server Administration Console] サインイン ページが表示されます。 前に保存しておいた WebLogic 管理者のユーザー名とパスワードを使用して、コンソールにサインインします。 ログインできない場合は、続行する前に問題のトラブルシューティングと解決を行う必要があります。

次の手順を実行して、各クラスターの Azure Application Gateway の IP アドレスを取得します。 これらの値は、後で Azure Traffic Manager を設定するときに使用します。

  1. クラスターがデプロイされているリソース グループを開きます。たとえば、[概要] を選択して、デプロイ ページの [概要] ペインに戻ります。 その後、[リソース グループに移動] を選択します。
  2. パブリック IP アドレスの種類gwipが指定されたリソースを探し、それを選択して開きます。 [IP アドレス] フィールドを探し、その値を保存しておきます。

Azure Traffic Manager の設定

このセクションでは、グローバル Azure リージョン間で一般向けアプリケーションにトラフィックを分散するための Azure Traffic Manager を作成します。 プライマリ エンドポイントはプライマリ WLS クラスター内の Azure Application Gateway を指し、セカンダリ エンドポイントはセカンダリ WLS クラスター内の Azure Application Gateway を指します。

「クイック スタート: Azure Portal を使用して Traffic Manager プロファイルを作成する」の手順に従って、Azure Traffic Manager プロファイルを作成します。 「前提条件」セクションはスキップしてください。 必要なセクションは、「Traffic Manager プロファイルの作成」「Traffic Manager エンドポイントの追加」、および 「Traffic Manager プロファイルのテスト」だけです。 その記事を読み進んで Azure Traffic Manager を作成して構成したら、この記事に戻ります。

  1. 「Traffic Manager プロファイルの作成」セクションにきたら、次の手順を実行します。

    1. 手順 2 でTraffic Manager プロファイルを作成し、次の手順を実行します。
      1. tmprofile-ejb120623 など、[名前] に対する Traffic Manager プロファイルの一意の名前を保存しておきます。
      2. myResourceGroupTM1 など、[リソース グループ] の新しいリソース グループ名を保存しておきます。
  2. 「Traffic Manager エンドポイントを追加」セクションまできたら、次の手順を実行します。

    1. 検索結果からプロファイルを選択する」手順の後に、この追加アクションを実行します。
      1. [設定] の下で [構成] を選択します。
      2. [DNS time to live (TTL)] に、10 と入力します。
      3. [エンドポイント モニター設定][パス]/weblogic/ready と入力します。
      4. [高速エンドポイント フェールオーバーの設定] で、次の値を使用します。
        • [プローブ内部]10 と入力します。
        • [許容失敗数]3 と入力します。
        • [プローブ タイムアウト] の場合は、5 です。
      5. [保存] を選択します。 完了するまで待機してください。
    2. プライマリ エンドポイント myPrimaryEndpoint を追加する手順 4 では、次の手順を実行します。
      1. [ターゲット リソースの種類] で、[パブリック IP アドレス] を選択します。
      2. [パブリック IP アドレスの選択] ドロップダウンを選択し、米国東部 WLS クラスターにデプロイされた Application Gateway の IP アドレス (前に保存しておいたもの) を入力します。 一致するエントリが 1 つ表示されます。 [パブリック IP アドレス] に対して選択します。
    3. フェールオーバー/セカンダリ エンドポイント myFailoverEndpoint を追加する手順 6 では、次の手順を実行します。
      1. [ターゲット リソースの種類] で、[パブリック IP アドレス] を選択します。
      2. [パブリック IP アドレスの選択] ドロップダウンを選択し、米国西部 WLS クラスターにデプロイされた Application Gateway の IP アドレス (前に保存しておいたもの) を入力します。 一致するエントリが 1 つ表示されます。 [パブリック IP アドレス] に対して選択します。
    4. しばらく待機します。 両方のエンドポイントの [監視] 状態の値が [オンライン] になるまで [最新の情報に更新] を選択します。
  3. 「Traffic Manager プロファイルのテスト」セクションにきたら、次の手順を実行します。

    1. サブセクションで、DNS 名を確認し、次の手順を実行します。
      1. 手順 3 で、http://tmprofile-ejb120623.trafficmanager.net など Traffic Manager プロファイルの DNS 名を保存しておきます。
    2. サブセクションで、アクションの Traffic Manager を表示するには、次の手順を実行します。
      1. 手順 1 と 3 で、Web ブラウザで http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready などの Traffic Manager プロファイルの DNS 名に /weblogic/ready を追加します。 エラー メッセージなしで空のページが表示されます。
      2. すべての手順を完了したら、手順 2 を参照してプライマリ エンドポイントを有効にしてください。ただし、[無効] [有効] に置き換えます。 次に、[エンドポイント] ページに戻ります。

これで、Traffic Manager プロファイルでエンドポイントが 有効 そして オンライン になりました。 ページを開いたままにして、後でエンドポイントの状態を監視するために使用します。

高可用性とディザスター リカバリーに WLS クラスターを構成します。

このセクションでは、高可用性とディザスター リカバリーのために WLS クラスターを構成します。

サンプル アプリを準備する

このセクションでは、フェールオーバー テストのために後で WLS クラスターにデプロイして実行するサンプル CRUD Java/JakartaEE アプリケーションをビルドしてパッケージ化します。

アプリは、WebLogic Server JDBC セッション永続化を使用して HTTP セッション データを格納します。 データソース jdbc/WebLogicCafeDB は、セッション データを格納して、WebLogic Server のクラスター全体でフェールオーバーと負荷分散を有効にします。 同じデータソース jdbc/WebLogicCafeDB にアプリケーション データ coffee を保存するための永続化スキーマを構成します。

サンプルをビルドしパッケージ化するには、次の手順を実行します。

  1. 次のコマンドを使用してサンプル リポジトリを複製し、この記事に対応するタグをチェックアウトします。

    git clone https://github.com/Azure-Samples/azure-cafe.git
    cd azure-cafe
    git checkout 20231206
    

    Detached HEAD に関するメッセージが表示された場合、無視しても問題ありません。

  2. 次のコマンドを使用してサンプル ディレクトリに移動し、サンプルをコンパイルしてパッケージ化します。

    cd weblogic-cafe
    mvn clean package
    

パッケージは正常に生成されると、<parent-path-to-your-local-clone>/azure-cafe/weblogic-cafe/target/weblogic-cafe.war に配置されます。 パッケージが表示されない場合は、続行する前に問題のトラブルシューティングと解決を行う必要があります。

サンプル アプリのデプロイ

次の手順を実行して、サンプル アプリをクラスターにデプロイします。まずはプライマリ クラスターから開始します。

  1. Web ブラウザーの新しいタブでクラスター adminConsole を開きます。 前に保存しておいた、WebLogic Administrator のユーザー名とパスワードを使用して、WebLogic Server Administration Console にサインインします。
  2. ナビゲーション ペインで ドメイン構造体>wlsd>Deployments 検索します。 [デプロイ] を選択します。
  3. [ロック] & [編集]>[インストール]>[ファイルをアップロード]>[ファイルを選択] の順に選択します。 前に準備した weblogic-cafe.war ファイルを選択します。
  4. [次へ]>[次へ]>[次へ] を選択します。 デプロイ ターゲットでクラスター内のすべてのサーバーオプションがある cluster1 を選択します。 [次へ]>[完了] の順に選択します。 [変更を有効化] を選択します。
  5. [制御] タブに切り替え、デプロイ テーブルで weblogic-cafe を選択します。 [すべてのリクエストを処理する]> オプションが [はい][開始] を選択します。 しばらく待機した後、デプロイ weblogic-cafe の状態が [アクティブ] になるまでページを更新します。 [監視] タブに切り替え、デプロイされたアプリケーションのコンテキスト ルートが /weblogic-cafe であることを確認します。 後で追加構成に使用できるように、WLS 管理コンソールを開いたままにしておきます。

WebLogic Server Administration Console で同じ手順を、米国西部リージョンのセカンダリ クラスターに対して繰り返します。

フロントエンド ホストを更新する

次の手順を実行して、WLS クラスターに Azure Traffic Manager を認識させます。 Azure Traffic Manager は、ユーザー リクエストのエンドポイントなので、WebLogic Server クラスターの フロント ホストを Traffic Manager プロファイルの DNS 名に更新します。これは、プライマリ クラスターから開始します。

  1. WebLogic Server Administration Console にサインインしていることを確認します。
  2. ナビゲーションで、[ドメイン構造体]>[wlsd]>[環境]>[クラスター] の順に選択します。 [クラスター] を選択します。
  3. クラスター テーブルから cluster1 を選択します。
  4. [ロック]& [編集]>[HTTP] の順に選択します。 フロントエンド ホストの現在の値を削除し、前に保存しておいた Traffic Manager プロファイルの DNS 名を http:// なしで入力します (例: tmprofile-ejb120623.trafficmanager.net)。 [保存]>[変更を有効化] の順に選択します。

WebLogic Server Administration Console で同じ手順を、米国西部リージョンのセカンダリ クラスターに対して繰り返します。

トランザクション ログ ストアを構成する

次に、クラスターのすべてのマネージド サーバーに対して JDBC トランザクション ログ ストアを構成します。これは、プライマリ クラスターから開始します。 この実習については、「トランザクション ログ ファイルを使用して、トランザクションをリカバリする」を参照してください。

米国東部リージョンのプライマリ WLS クラスターで次の手順を使用します。

  1. WebLogic Server Administration Console にサインインしていることを確認します。
  2. ナビゲーションで、[ドメイン構造体]>[wlsd]>[環境]>[サーバー] の順に選択します。 [サーバー] を選択します。
  3. サーバー msp1msp2msp3 がサーバー テーブルに一覧されます。
  4. msp1>[サービス]>[ロック]&[編集] の順に選択します。 [トランザクション ログ ストア] で、[JDBC]を選択します。
  5. [タイプ]>[データ元] には、jdbc/WebLogicCafeDBを選択します。
  6. プレフィックス名の値が既定値である [TLOG_msp1_] になっていることを確認します。 値が異なる場合は、[TLOG_msp1_] に変更します。
  7. [保存] を選択します。
  8. [サーバー]>msp2 を選択し、同じ手順を繰り返しますが、[プリフィックス名] のデフォルト値は、[TLOG_msp2_] にします。
  9. [サーバー]>msp3 を選択し、同じ手順を繰り返しますが、[プリフィックス名] のデフォルト値は、[TLOG_msp3_] にします。
  10. [変更を有効化] を選択します。

WebLogic Server Administration Console で同じ手順を、米国西部リージョンのセカンダリ クラスターに対して繰り返します。

プライマリ クラスターのマネージド サーバーを再起動する

次に、次の手順を実行して、プライマリ クラスターのすべてのマネージド サーバーを再起動し、変更を有効化します。

  1. WebLogic Server Administration Console にサインインしていることを確認します。
  2. ナビゲーションで、[ドメイン構造体]>[wlsd]>[環境]>[サーバー] の順に選択します。 [サーバー] を選択します。
  3. [コントロール] タブを選択し、msp1msp2msp3 を選択します。 [作業完了時]>のオプションが [はい][シャットダウン]を選択します。 [更新] アイコンを選択します。 [最後のアクション状態][タスクが完了] になるまで待機します。 選択したサーバーの [状態] 値が [シャットダウン] になります。 状態の監視を再度停止するには、[更新] アイコンを選択します。
  4. msp1msp2 および msp3 を再度選択します。 [開始]>[はい] の順に選択します。 [更新] アイコンを選択します。 [最後のアクション状態][タスクが完了] になるまで待機します。 選択したサーバーの [状態] 値が [実行中] になります。 状態の監視を再度停止するには、[更新] アイコンを選択します。

セカンダリ クラスターで VM を停止する

ここで、次の手順を実行してセカンダリ クラスターのすべての VM を停止して、パッシブにします。

  1. ブラウザーの新しいタブで Azure Portal ホームを開き、[すべてのリソース]を選択します。 [任意のフィールドをフィルタ...] ボックスで、セカンダリ クラスターをデプロイするリソース グループ名 (wls-cluster-westus-ejb120623 など) を入力します。
  2. [Type equals all] を選択して、[タイプ] フィルタを開きます。 [値]Virtual machine と入力します。 一致するエントリが 1 つ表示されます。 それを、[値] に選択します。 適用を選択します。 adminVMmspVM1mspVM2mspVM3 など、4 つの VM が一覧されます。
  3. 各 VM を選択して開きます。 [停止] を選択して、各 VM を確認します。
  4. Azure Portal で [通知] アイコンを選択し、[通知] ペインを開きます。
  5. 値が [仮想マシンが正常に停止されました] になるまで、各 VM の Stopping virtual machine イベントを監視します。 後でフェールオーバー テストに使用するために、ページを開いたままにしておきます。

次に、Traffic Manager のエンドポイントの状態を監視するブラウザー タブに切り替えます。 エンドポイント myFailoverEndpoint[ディグレード] になり、エンドポイント myPrimaryEndpoint が、[オンライン] になるまでページを更新します。

Note

運用対応 HA/DR ソリューションでは、VM を実行したままにして、VM で実行される WLS ソフトウェアだけを停止することで低い RTO を実現することが望ましい場合があります。 その後、フェールオーバーが発生しても、VM は既に実行されており、WLS ソフトウェアの起動時間は短くなります。 この記事では、Azure VM 上の Oracle WebLogic Server クラスターがデプロイしたソフトウェアが、VM の起動時に WLS ソフトウェアを自動的に起動するため、VM を停止することを選択しました。

アプリを確認する

プライマリ クラスターは稼働しているため、アクティブなクラスターとして機能し、Traffic Manager プロファイルによってルーティングされたすべてのユーザー要求を処理します。

ブラウザーの新しいタブで Azure Traffic Manager プロファイルの DNS 名を開き、http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe などのデプロイされたアプリの コンテキスト ルート /weblogic-cafe を追加します。 名前と価格 (価格 10コーヒー 1 など) で新しいコーヒーを作成します。 このエントリは、アプリケーション データ テーブルと、データベースのセッション テーブルの両方に保存されます。 以下のスクリーンショットのような UI が表示されます。

サンプル UI アプリケーションのスクリーンショット。

UI がスクリーンショットのような UI でない場合、ぞっこする前にトラブルシューティングを行って問題を解決します。

後でフェールオーバー テストで使用できるように、ページを開いたままにしておきます。

プライマリからセカンダリへのフェールオーバーをテストする

フェールオーバーをテストするには、プライマリ データベース サーバーとクラスターをセカンダリ データベース サーバーとクラスターに手動でフェールオーバーしてから、このセクションの Azure Portal を使用してフェールバックします。

セカンダリ サイトにフェールオーバー

まず、次の手順を実行して、プライマリ クラスターで VM をシャットダウンします。

  1. プライマリ WLS クラスターがデプロイされているリソース グループの名前 (wls-cluster-eastus-ejb120623 など) を見つけます。 次に、[セカンダリ クラスターで VM を停止する] セクションで手順を実行しますが、対象リソース グループを プライマリ WLS クラスターに変更し、そのクラスターのすべての VM を停止します。
  2. Traffic Manager のブラウザー タブに切り替え、エンドポイント myPrimaryEndpoint[監視状態] 値が [ディグレード] になるまで、ページを更新します。
  3. サンプル アプリのブラウザー タブに切り替えて、ページを更新します。 どのエンドポイントにもアクセスできないため、504 Gateway Time-out または 502 Bad Gateway が表示されます。

次に、次の手順を実行して、プライマリ サーバーからセカンダリ サーバーに Azure SQL Database をフェールオーバーします。

  1. Azure SQL Database フェールオーバー グループのブラウザー タブに切り替えます。
  2. [フェールオーバー]>[はい] の順に選択します。
  3. 完了するまで待機してください。

次に、次の手順を実行して、セカンダリ クラスター内のすべてのサーバーを起動します。

  1. セカンダリ クラスター内のすべての VM を停止したブラウザー タブに切り替えます。
  2. [VM adminVM] を選択します。 [スタート] を選択します。
  3. [通知] パネルで adminVMStarting virtual machine イベントを監視し、値が、[仮想マシンを開始済み] になるまで待機します。
  4. セカンダリ クラスターの WebLogic Server Administration Console のブラウザー タブに切り替え、サインインするためにウェルカム ページが表示されるまでページを更新します。
  5. セカンダリ クラスター内のすべての VM が一覧表示されているブラウザー タブに戻ります。 VM mspVM1mspVM2mspVM3 の場合、各 VM を選択して開き、[開始] を選択します。
  6. VM mspVM1mspVM2mspVM3 の場合、[通知] ペインで Starting virtual machine イベントを監視し、値が [仮想マシンを開始済み] になるまで待機します。

最後に、次の手順を使用して、エンドポイント myFailoverEndpoint[オンライン] 状態になった後に、サンプル アプリを確認します。

  1. Traffic Manager のブラウザー タブに切り替え、エンドポイント myFailoverEndpoint[監視状態][オンライン] 状態になるまで、ページを更新します。

  2. サンプル アプリのブラウザー タブに切り替えて、ページを更新します。 次のスクリーンショットに示すように、同じデータがアプリケーション データ テーブルに保持され、セッション テーブルが UI に表示されます。

    フェールオーバー後のサンプル アプリケーション UI のスクリーンショット。

    この動作が確認できない場合は、Traffic Manager がフェールオーバー サイトを指すように DNS の更新に時間がかかっている可能性が考えられます。 問題として、ブラウザーが失敗したサイトを指す DNS 名前解決の結果をキャッシュした可能性も挙げられます。 しばらく待ってから、もう一度ページを更新してください。

Note

運用対応の HA/DR ソリューションでは、通常のスケジュールでプライマリ クラスターからセカンダリ クラスターに WLS 構成を継続的にコピーする必要があります。 これを行う方法については、この記事の最後にある Oracle ドキュメントのリファレンスを参照してください。

フェールオーバーを自動化するには、Traffic Manager メトリックと Azure Automation でアラートを使用することを検討します。 詳細については、「Traffic Manager メトリックとアラート」「Traffic Manager メトリックのアラート」セクションおよび「アラートを使用して Azure Automation Runbook をトリガーする」を参照してください。

プライマリ サイトにフェールバックする

次の違いを除き、「セカンダリ サイトへのフェールオーバー」セクションで同じ手順を使用して、データベース サーバーとクラスターを含むプライマリ サイトにフェールバックします。

  1. まず、セカンダリ クラスター内の VM をシャットダウンします。 エンドポイント myFailoverEndpoint[ディグレード] になっていることを確認します。
  2. 次に、セカンダリ サーバーからプライマリ サーバーに Azure SQL Database をフェールオーバーします。
  3. 次に、プライマリ クラスター内のすべてのサーバーを起動します。
  4. 最後に、エンドポイント myPrimaryEndpoint[オンライン] になったら、サンプル アプリを確認します。

リソースをクリーンアップする

WLS クラスターとその他のコンポーネントを引き続き使用しない場合は、次の手順を実行してリソース グループを削除し、このチュートリアルで使用するリソースをクリーンします。

  1. Azure Portal の上部にある検索ボックスで SQL Database サーバーのリソース グループ名 (例: myResourceGroup) を入力し、検索結果から一致するリソース グループを選択します。
  2. [リソース グループの削除] を選択します。
  3. [削除するリソース グループ名を入力する] で、リソース グループ名を入力します。
  4. [削除] を選択します。
  5. Traffic Manager のリソース グループに対して、手順 1 ~ 4 を繰り返します (例: myResourceGroupTM1)。
  6. プライマリ WLS クラスターのリソース グループに対して、手順 1 ~ 4 を繰り返します (例: wls-cluster-eastus-ejb120623)。
  7. セカンダリ WLS クラスターのリソース グループに対して、手順 1 ~ 4 を繰り返します (例: wls-cluster-westus-ejb120623)。

次のステップ

このチュートリアルでは、アクティブ/パッシブ データベース層を持つアクティブ/パッシブ アプリケーション インフラストラクチャ層で構成され、両方の層が地理的に異なる 2 つのサイトにまたがる HA/DR ソリューションを設定します。 最初のサイトでは、アプリケーション インフラストラクチャ層とデータベース層の両方がアクティブになります。 2 つ目のサイトでは、セカンダリ ドメインがシャットダウンされ、セカンダリ データベースがスタンバイ状態になります。

HA/DR ソリューションを構築し、Azure で WLS を実行するためのその他のオプションについては、引き続き次のリファレンスを参照してください。