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

[アーティクル]
04/17/2024

このチュートリアルでは、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 以降をインストールします (例: Microsoft build of OpenJDK)。
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. たとえば、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 クラスターのフェールオーバーテストに使用します。

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 管理者] のユーザー名とパスワードを保存しておきます。
他のフィールドはデフォルトのままにします。
[次へ] を選択して、[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

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

選択したリージョンのネットワークの状態やその他のアクティビティによっては、デプロイが完了するまでに最大 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`
セカンダリ	`myGatewayBackendPool`

ネットワーク設定のミラーリングを自動化するには、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 を設定するときに使用します。

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

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

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

次のコマンドを使用してサンプルリポジトリを複製し、この記事に対応するタグをチェックアウトします。
```
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-cafe を選択します。 [すべてのリクエストを処理する]> オプションが [はい] の [開始] を選択します。しばらく待機した後、デプロイ 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 を選択します。 [作業完了時]>のオプションが [はい] の [シャットダウン]を選択します。 [更新] アイコンを選択します。 [最後のアクション状態] が [タスクが完了] になるまで待機します。選択したサーバーの [状態] 値が [シャットダウン] になります。状態の監視を再度停止するには、[更新] アイコンを選択します。
msp1、msp2 および msp3 を再度選択します。 [開始]>[はい] の順に選択します。 [更新] アイコンを選択します。 [最後のアクション状態] が [タスクが完了] になるまで待機します。選択したサーバーの [状態] 値が [実行中] になります。状態の監視を再度停止するには、[更新] アイコンを選択します。

セカンダリクラスターで 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 の 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 でない場合、ぞっこする前にトラブルシューティングを行って問題を解決します。

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

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

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

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

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

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

次に、次の手順を実行して、プライマリサーバーからセカンダリサーバーに 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 の上部にある検索ボックスで 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 フェールオーバーグループを設定する