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

[アーティクル]
01/07/2025

このチュートリアルでは、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 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 サブスクリプション。 Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。
サブスクリプションの Owner ロールか、または、Contributor および User Access Administrator ロールが割り当てられていることを確認します。「Azure portal を使用して Azure ロールの割り当てを一覧表示する」の手順に従って、割り当てを確認できます。
Linux または macOS がインストールされたローカルマシンを準備します。
Gitをインストールして設定します。
Java SE 実装 (バージョン 17 以降) をインストールします。たとえば、OpenJDKの Microsoft ビルドをします。
Maven、バージョン 3.9.3 以降をインストールします。

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

Note

この記事では、この記事で重点を置いた HA/DR セットアップは既に非常に複雑であるため、わかりやすくするために、SQL 認証を使用して Azure SQL Database Single Database に接続する方法を説明します。より安全な方法は、Azure SQL 向け Microsoft Entra 認証を使用してデータベースサーバー接続を認証することです。 Microsoft Entra 認証を使用してデータベース接続を構成する方法については、「Oracle WebLogic Serverで Java アプリ用パスワードレスデータベース接続を構成する」を参照してください。

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

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

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

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

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

[サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
[リソースグループ] フィールドで、[新しい作成] を選択し、リソースグループの一意の値を入力します。例えば、[wls-cluster-eastus-ejb120623] など。
インスタンスの詳細で、リージョンの 米国東部を選択します。
[仮想マシンと WebLogic の資格情報] で、VM の管理者アカウントと [WebLogic 管理者]にそれぞれパスワードを指定します。 [WebLogic 管理者] のユーザー名とパスワードを保存しておきます。セキュリティを強化するために、VM 認証の種類として SSH パブリックキー使用することを検討します。
他のフィールドはデフォルトのままにします。
[次へ] を選択して、[TLS/SSL 構成] ウィンドウに移動します。

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

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

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

[仮想ネットワークを編集] を選択します。 10.1.4.0/23 などの仮想ネットワークのアドレス空間を保存しておきます。
wls-subnet を選択して、サブネットを編集します。 [サブネット詳細] で、10.1.5.0 や /28 などの開始アドレスとサブネットサイズを保存しておきます。
変更を加えた場合は、変更を保存します。
ネットワーキング ペインに戻ります。
[次へ] を選択して、[データベース] ウィンドウに移動します。

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

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

Note

しばらくすると、展開ページが表示され、展開が進行中であることが 表示されます。

Note

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

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

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

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

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

[基本] ペインで、次の手順を実行します。
1. [リソースグループ] フィールドで、[新規作成] を選択し、リソースグループに対して別の固有値 (wls-cluster-westtus-ejb120623 など) を入力します。
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 クラスターと同じ開始アドレスとサブネットサイズを入力します。
[データベース] ペインで、次の手順を実行します。
1. [DataSource 接続文字列] で、プレースホルダーをセカンダリ SQL データベースの前のセクションで保存しておいた jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433;database=mySampleDatabase などの値に置き換えます。
2. [データベースユーザー名] で、プレースホルダーをセカンダリ SQL データベースの前のセクションで保存しておいた azureuser@sqlserversecondary-ejb120623 などの値に置き換えます。

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

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

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

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

[デプロイ] ページの [概要] ペインで、[リソースグループに移動] を選択します。
ネットワークインターフェイスを選択しますadminVM_NIC_with_pub_ip。
1. [設定]で、[IP 構成]を選択します。
2. [ipconfig1] を選択します。
3. [プライベート IP アドレス設定] で、[割り当て] に対して [静的]を選択します。プライベート IP アドレスを保存しておきます。
4. 保存を選択します。
プライマリ WLS クラスターのリソースグループに戻り、ネットワークインターフェイス mspVM1_NIC_with_pub_ip、mspVM2_NIC_with_pub_ip および mspVM3_NIC_with_pub_ip に対して手順 3 を繰り返します。
すべての更新が完了するまで待ちます。 Azure Portal で [通知] アイコンを選択すると、状態監視用の [通知] ウィンドウを開くことができます。
プライマリ WLS クラスターのリソースグループに戻り、種類がプライベートエンドポイントであるリソースの名前をコピーします (7e8c8bsaep など)。この名前を使用して、たとえば、7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a などの残りのネットワークインターフェイスを検索します。それを選択し、前の手順に従ってプライベート IP アドレスを取得します。

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

[デプロイ] ページの [概要] ペインで、[リソースグループに移動] を選択します。
ネットワークインターフェイス adminVM_NIC_with_pub_ip、mspVM1_NIC_with_pub_ip、mspVM2_NIC_with_pub_ip および mspVM3_NIC_with_pub_ip の場合は、上記の手順を実行して、プライベート IP アドレス割り当てを [静的] に更新します。
すべての更新が完了するまで待ちます。
ネットワークインターフェイス mspVM1_NIC_with_pub_ip、mspVM2_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 バックエンドプールを適宜更新します。

クラスターのリソースグループを開きます。
Application gateway タイプの myAppGateway リソースを検索します。そのストレージアカウントを選択して開きます。
[設定] セクションで、[バックエンドプール] を選択し、[myGatewayBackendPool] を選択します。
バックエンドターゲットの値 を更新されたプライベートIPアドレスに変更し、次に [保存] を選択します。完了するまで待機してください。
[設定] セクションで、[正常性プローブ] を選択し、[HTTPhealthProbe] を選択します。
[正常性プローブを追加する前にバックエンド正常性をテストする] が選択されていることを確認したら、[テスト] を選択します。バックエンドプール 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 管理コンソールが機能するかどうかを確認するには、次の手順を実行します。

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

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

クラスターがデプロイされているリソースグループを開きます。たとえば、[概要] を選択して、デプロイページの [概要] ペインに戻ります。その後、[リソースグループに移動] を選択します。
リソース gwip を見つけ、その種類が でパブリック IP アドレスの場合、そのリソースを選択して開いてください。 [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 を作成して構成したら、この記事に戻ります。

「Traffic Manager プロファイルの作成」セクションに到達したら、手順 2 の「Traffic Manager プロファイルを作成する」で、次の手順を使用します。
1. Name 用の一意の Traffic Manager プロファイル名を別途保存します (たとえば、tmprofile-ejb120623)。
2. 新しいリソースグループ名 をリソースグループ のために別に保存します (例: myResourceGroupTM1)。
「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. 手順 6 のフェールオーバー/セカンダリエンドポイント myFailoverEndpoint を追加するでは、次の手順を実行します。
  1. [ターゲットリソースの種類] で、[パブリック IP アドレス] を選択します。
  2. [パブリック IP アドレスの選択] ドロップダウンを選択し、米国西部 2 WLS クラスターにデプロイされた Application Gateway の IP アドレス (前に保存しておいたもの) を入力します。一致するエントリが 1 つ表示されます。 [パブリック IP アドレス] に対して選択します。
4. しばらく待機します。両方のエンドポイントの [監視] 状態の値が [オンライン] になるまで [最新の情報に更新] を選択します。
セクションテストトラフィックマネージャープロファイルに到達したら、次の手順に従います。
1. 「DNS 名を確認する」セクションの手順 3 で、Traffic Manager プロファイルの DNS 名 (http://tmprofile-ejb120623.trafficmanager.net など) を保存しておきます。
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 を保存するための永続化スキーマを構成します。

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

次のコマンドを使用してサンプルリポジトリを複製し、この記事に対応するタグをチェックアウトします。
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Detached HEAD に関するメッセージが表示された場合、無視しても問題ありません。
次のコマンドを使用してサンプルディレクトリに移動し、サンプルをコンパイルしてパッケージ化します。
```
cd weblogic-cafe
mvn clean package
```

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

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

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

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

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

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

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

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

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

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

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

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

WebLogic Server Administration Console にサインインしていることを確認します。
ナビゲーションで、[ドメイン構造体]>[wlsd]>[環境]>[サーバー] の順に選択します。 [サーバー] を選択します。
サーバーテーブルには、msp1、msp2、および msp3 サーバーが表示されているはずです。
msp1>[サービス]>[ロック]&[編集] の順に選択します。トランザクションログストアの下で、JDBCを選択します。
[種類]>[データソース] で、jdbc/WebLogicCafeDB を選択します。
プレフィックス名の値が既定値である [TLOG_msp1_] になっていることを確認します。値が異なる場合は、[TLOG_msp1_] に変更します。
保存を選択します。
[サーバー>msp2] を選択し、同じ手順を繰り返します。ただし、プレフィックス名 の既定値が TLOG_msp2_。
[サーバー]>[msp3] を選択し、同じ手順を繰り返しますが、[プレフィックス名] の既定値は TLOG_msp3_ です。
[変更を有効化] を選択します。

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

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

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

WebLogic Server Administration Console にサインインしていることを確認します。
ナビゲーションで、[ドメイン構造体]>[wlsd]>[環境]>[サーバー] の順に選択します。 [サーバー] を選択します。
[コントロール] タブを選択します。msp1、msp2、および msp3を選択します。 [作業完了時]のオプションが > の [シャットダウン]を選択します。 [更新] アイコンを選択します。 [最後のアクション状態] が [タスクが完了] になるまで待機します。選択したサーバーの状態値が SHUTDOWNになっていることがわかります。状態の監視を再度停止するには、[更新] アイコンを選択します。
msp1、msp2、msp3 をもう一度選択します。 [開始]>[はい] の順に選択します。 [更新] アイコンを選択します。 [最後のアクション状態] が [タスクが完了] になるまで待機します。選択したサーバーの状態の値がRUNNINGであることを確認してください。状態の監視を再度停止するには、[更新] アイコンを選択します。

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

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

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

次に、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 が似ていない場合は、トラブルシューティングを行い、問題を解決してから続行してください。

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

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

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

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

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

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

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

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

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

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

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

Traffic Manager のブラウザータブに切り替え、エンドポイント myFailoverEndpoint の [監視状態] が [オンライン] 状態になるまで、ページを更新します。
サンプルアプリのブラウザータブに切り替えて、ページを更新します。次のスクリーンショットに示すように、同じデータがアプリケーションデータテーブルに保持され、セッションテーブルが UI に表示されます。

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

Note

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

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

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

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

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

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

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

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

次のステップ

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

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

Oracle Fusion Middleware 製品向け障害復旧ソリューション

Azure 信頼性に関するドキュメント

高可用性のためのソリューションを構築する

Azure Traffic Manager を使用した自動フェールオーバー

Azure VM 上の Oracle WebLogic の詳細を確認する

AKS 上の Oracle WebLogic の詳細を確認する

次の方法で共有

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

前提条件

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