チュートリアル: geo 冗長性を使用して Oracle WebLogic Server を Azure Kubernetes Service (AKS) に移行する

[アーティクル]
05/06/2024

このチュートリアルでは、Azure Kubernetes Service (AKS) 上の Oracle WebLogic Server (WLS) を使用して Java の事業継続とディザスターリカバリー (DR) 戦略を簡単かつ効果的に実装する方法について説明します。 AKS で実行されている単純なデータベース駆動型 Jakarta EE アプリケーションを使用して WLS ワークロードをバックアップおよび復元する方法を、このソリューションで説明します。 geo 冗長性は複雑なトピックであり、多くのソリューションが考えられます。最適なソリューションは、独自の要件によって異なります。 geo 冗長性を実装するその他の方法については、この記事の最後にあるリソースを参照してください。

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

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

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

Azure Traffic Manager は、リージョンの正常性をチェックし、それに応じてアプリケーション層にトラフィックをルーティングします。プライマリリージョンには、WLS クラスターが完全にデプロイされています。ユーザーからのネットワーク要求に応えてアクティブにサービスを提供しているのは、プライマリリージョンのみです。障害が発生した場合または DR イベントが宣言された場合、セカンダリリージョンはプライマリリージョンのバックアップから WLS クラスターを復元します。セカンダリリージョンは、プライマリリージョンでサービスの中断が発生した場合にのみトラフィックを受信するようにアクティブ化されます。

Azure Traffic Manager は、Azure Application Gateway の正常性チェック機能および WebLogic Kubernetes Operator (WKO) を使用して、この条件付きルート指定を実装します。 WKO は AKS の正常性チェックと深いレベルで統合されているため、Azure Traffic Manager で Java ワークロードの正常性を高いレベルで認識できます。プライマリ WLS クラスターが実行され、セカンダリクラスターがシャットダウンされます。

アプリケーション階層の geo フェールオーバーの目標復旧時間 (RTO) は、AKSの起動とセカンダリ WLS クラスターの実行にかかる時間 (通常は 1 時間未満) によって異なります。アプリケーションデータは Azure SQL Database フェールオーバーグループで保存とレプリケートが行われ、RTO は数分または数時間、目標復旧時点 (RPO) は数分または数時間になります。このアーキテクチャでは、Azure バックアップには、WLS 構成に対して、毎日 1 つの Vault 標準バックアップのみが含まれます。詳細については、「Azure Kubernetes Service (AKS) バックアップとは」を参照してください。

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

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

この記事では、Azure Backup を使用して AKS を保護します。利用可能なリージョン、サポートされるシナリオ、制限事項については、「Azure Kubernetes Service バックアップサポートマトリックス」を参照してください。現在、Azure Backup では、リージョン間でのコンテナー階層のバックアップと復元がサポートされており、パブリックプレビューで利用できます。詳細については、「AKS のコンテナー階層バックアップを有効にし、Azure Backup を使用してリージョン間で復元する」を参照してください。

Note

この記事では、さまざまなリソースの一意識別子を頻繁に作成する必要があります。この記事では、プレフィックスとして <initials><sequence-number> という規則を使用します。たとえば、ユーザーの名前が Emily Juanita Bernal の場合、一意の識別子は ejb01 になります。 MMDD 形式で今日の日付を追加して、あいまいさをさらに解消することもできます (ejb010307 など)。

前提条件

Azure サブスクリプション。 Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。
サブスクリプションの Owner ロールか、または、Contributor および User Access Administrator ロールが割り当てられていることを確認します。「Azure portal を使用して Azure ロールの割り当てを一覧表示する」の手順に従って、割り当てを確認できます。
Linux または macOS がインストールされたローカルマシンを準備します。
Azure CLI コマンドを実行できるように、Azure CLI バージョン 2.54.0 以降をインストールします。
kubectl をインストールして設定します。
Git をインストールして設定します。
Java SE 実装バージョン 17 以降 (OpenJDK の Microsoft ビルドなど) をインストールします。
Maven のバージョン 3.9.3 以降をインストールします。
Oracle シングルサインオン (SSO) アカウントの資格情報を持っている。作成するには、Oracle アカウントの作成ページを参照してください。
次の手順に沿って、WLS のライセンス条項に同意します。
1. Oracle Container Registry にアクセスしてサインインします。
2. サポートエンタイトルメントをお持ちの場合は、[ミドルウェア] を選択してから、weblogic_cpu を検索して選択します。
3. Oracle のサポートエンタイトルメントを持っていない場合は、[ミドルウェア] を選択してから、weblogic を検索して選択します。
4. 使用許諾契約書に同意します。
AKS で WLS を実行するには、WLS ドメインを理解する必要があります。 WLS ドメインの詳細については、「WebLogic Server アプリケーションを Azure Kubernetes Service に移行する」の「事前構築済みの Azure Marketplace オファーを使用するかどうかを決定する」セクションを参照してください。この記事では、トランザクションログとストアが外部データベースにあり、外部ストレージはなく、model in image ドメインホームソースタイプを使用して WLS on AKS が実行されていることを前提とします。

ペアになっているリージョンで 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 TLOG_msp4_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_msp5_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));

実行が成功すると、Query succeeded: Affected rows: 0 というメッセージが表示されます。

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

サンプル・アプリケーションのスキーマを作成するには、次のクエリを入力します。
```
CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));
```
実行が成功すると、Query succeeded: Affected rows: 0 というメッセージが表示されます。

これで、「クイックスタート: 単一データベースの作成 - Azure SQL Database」の記事は終了です。

次に、「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 クラスターのフェールオーバーテストに使用します。

フェールオーバーグループの JDBC 接続文字列とデータベース管理者ユーザー名を取得する

次の手順に沿って、フェールオーバーグループ内のデータベースの JDBC 接続文字列とデータベースユーザー名を取得します。これらの値は、プライマリデータベースの対応する値とは異なります。

Azure portal で、プライマリデータベースをデプロイしたリソースグループを見つけます。
リソースの一覧で、種類が SQL データベースのプライマリデータベースを選択します。
[設定] で [接続文字列] を選択します。
[JDBC] を選択します。
[JDBC (SQL 認証)] の下にあるテキスト領域で、コピーアイコンを選択し、JDBC 接続文字列の値をクリップボードにコピーします。
テキストエディターにその値を貼り付けます。別の手順でその値を編集します。
リソースグループに戻ります。
前の手順で確認したデータベースを含む SQL Server の種類のリソースを選択します。
[データ管理] で [フェールオーバーグループ] を選びます。
ページの中央にあるテーブルで、フェールオーバーグループを選択します。
[読み取り/書き込みリスナーエンドポイント] の下にあるテキスト領域で、コピーアイコンを選択し、JDBC 接続文字列の値をクリップボードにコピーします。

テキストエディターの新しい行にその値を貼り付けます。テキストエディターには、次の例のような行が表示されます。

jdbc:sqlserver://ejb010307db.database.windows.net:1433;database=ejb010307db;user=azureuser@ejb010307db;password={your_password_here};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
ejb010307failover.database.windows.net

次の変更を行って新しい行を作成します。
1. 最初の行全体をコピーします。
2. URL のホスト名部分を、[読み取り/書き込みリスナーエンドポイント] 行のホスト名を使用するように変更します。
3. database の name=value ペアの後ろをすべて削除します。つまり、database=ejb010307db の直後にある ; も含め、それ以降をすべて削除します。
  
  完了すると、文字列は次の例のようになります。
```
jdbc:sqlserver://ejb010307failover.database.windows.net:1433;database=ejb010307db
```
  この値は、JDBC 接続文字列です。
同じテキストエディターで、元の JDBC 接続文字列から user パラメーターの値を取得し、データベース名を [読み取り/書き込みリスナーエンドポイント] 行の最初の部分に置き換えて、データベースユーザー名を導き出します。前の例を続けると、値は azureuser@ejb010307failover になります。この値は、データベース管理者のユーザー名です。

AKS でプライマリ WLS クラスターを設定して構成する

このセクションでは、Oracle WebLogic Server on AKS オファーを使用して、ASK 上に WLS クラスターを作成します。米国東部のクラスターはプライマリであり、アクティブクラスターとして構成されます。

Note

Oracle WebLogic Server on AKS オファーの詳細については、次の記事を参照してください。

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

このセクションでは、フェールオーバーテストのために後で 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 に配置されます。パッケージが表示されない場合は、続行する前に問題のトラブルシューティングと解決を行う必要があります。

サンプルアプリケーションを保持するストレージアカウントとストレージコンテナーを作成する

次の手順を使って、ストレージアカウントとコンテナーを作成します。これらの手順の一部は、他のガイドを参照するようになっています。手順を完了したら、サンプルアプリケーションをアップロードして WLS にデプロイできます。

Azure portal にサインインします。
「ストレージアカウントを作成する」の手順に従って、ストレージアカウントを作成します。この記事の値には、次の特殊化を使用します。
- ストレージアカウント用に新しいリソースグループを作成します。
- [リージョン] で、 [米国東部] を選択します。
- [ストレージアカウント名] には、リソースグループ名と同じ値を使用します。
- [パフォーマンス] には [Standard] を選択します
- [冗長] には [ローカル冗長ストレージ (LRS)] を選びます。
- その他のタブは特殊化する必要はありません。
アカウントの検証と作成に進んでから、この記事に戻ります。
「クイックスタート: Azure portal での BLOB のアップロード、ダウンロード、一覧表示」の「コンテナーの作成」セクションの手順に従って、アカウント内にストレージコンテナーを作成します。
同じ記事を使用して、「ブロック BLOB のアップロード」セクションの手順に従い、前に作成した azure-cafe/weblogic-cafe/target/weblogic-cafe.war パッケージをアップロードします。その後、この記事に戻ります。

AKS に WLS をデプロイする

次の手順に沿って、WLS on AKS をデプロイします。

ブラウザーで Oracle WebLogic Server on AKS オファーを開き、[作成] を選択します。オファーの [基本] ペインが表示されます。
[基本] ペインを入力する手順を実行します。
1. [サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
2. このオファーを空のリソースグループにデプロイする必要があります。 [リソースグループ] フィールドで [新規作成] を選択し、リソースグループの固有値 (wlsaks-eastus-20240109 など) を入力します。
3. [インスタンス詳細] の[リージョン] で、[米国東部] を選択します。
4. [WebLogic の資格情報] で、[WebLogic 管理者] と [WebLogic モデル暗号化] のパスワードを指定します。 [WebLogic 管理者] のユーザー名とパスワードを保存しておきます。
5. [オプションの基本構成] の [オプションの構成の既定値を受け入れる] で [いいえ] を選択します。オプションの構成が表示されます。
6. [マネージドサーバーの名前プレフィックス] に msp と入力します。後で、プレフィックス TLOG_${serverName}_ を使用して WLS TLOG テーブルを構成します。この記事では、TLOG_msp${index}_WLStore という名前を持つ TLOG テーブルを作成します。別のマネージドサーバー名プレフィックスが必要な場合は、値が Microsoft SQL Server テーブル命名規則および実際のテーブル名と一致していることを確認してください。
7. 他のフィールドはデフォルトのままにします。
[次へ] を選択して、[AKS] ウィンドウに移動します。
[イメージの選択] で、次の情報を指定します。
- [Oracle シングルサインオン認証のユーザー名] に、前提条件の Oracle SSO ユーザー名を入力します。
- [Oracle シングルサインオン認証のパスワード] に、前提条件の Oracle SSO 資格情報を入力します。
[アプリケーション] では、次の手順を使用します。
1. [アプリケーション] セクションの [Deploy an application?] (アプリケーションをデプロイしますか?) の横にある [はい] を選択します。
2. [アプリケーションパッケージ (.war、.ear、.jar)] の横にある [参照] を選択します。
3. 前のセクションで作成したストレージアカウントの名前の入力を開始します。目的のストレージアカウントが表示されたら、それを選択します。
4. 前のセクションのストレージコンテナーを選択します。
5. 前のセクションでアップロードした、weblogic-cafe.war の横にあるチェックボックスを選択します。 [選択] を選択します。
6. 他のフィールドはデフォルトのままにします。
[次へ] を選択します。
[TLS/SSL 構成] ウィンドウは既定値のまま変更せず、[次へ] を選択して [負荷分散] ウィンドウに移動します。
[負荷分散] ウィンドウで、[管理コンソール用のイングレスを作成します。パス/コンソール* を持つアプリケーションがないことを確認します。ある場合、管理コンソールパスとの競合が発生します] の横にある [はい] を選択します。
他のフィールドは既定値のまま変更せず、[次へ] を選択します。
[DNS] ウィンドウは既定値のまま変更せず、[次へ] を選択して [データベース] ウィンドウに移動します。
[データベース] ウィンドウに次の値を入力します。
- [データベースに接続しますか?] で [はい] を選択します。
- [データベースの種類を選択] で、[Microsoft SQL Server (パスワードレス接続をサポート)] を選択します。
- [JNDI 名] には、jdbc/WebLogicCafeDB と入力します。
- [DataSource 接続文字列] には、[フェールオーバーグループの JDBC 接続文字列とデータベース管理者ユーザー名の取得] セクションで [JDBC 接続文字列] に保存した値を貼り付けます。
- [グローバルトランザクションプロトコル] には、[なし] を選択します。
- [データベースユーザー名] には、[フェールオーバーグループの JDBC 接続文字列とデータベース管理者ユーザー名の取得] セクションで [データベース管理者ユーザー名] に保存した値を貼り付けます。
- [データベースパスワード] で前に保存しておいたデータベースサーバー管理者のサインインパスワードを入力します。 [パスワードを確認] と同じ値を入力します。
- 他のフィールドはデフォルトのままにします。
[Review + create](レビュー + 作成) を選択します。
[最後の検証を実行中...] が正常に完了するまで待機し、[作成] を選択します。しばらくすると、デプロイが進行中の [デプロイ] ページが表示されます。

Note

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

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

TLOG データのストレージを構成する

このセクションでは、WLS イメージモデルを ConfigMap でオーバーライドして TLOG データのストレージを構成します。 ConfigMap の詳細については、「WebLogic Deploy Tooling モデル ConfigMap」を参照してください。

このセクションでは、Azure CLI と kubectl がインストールされている Bash ターミナルが必要です。次の手順を使用して、TLOG データに必要な YAML を導き出し、そのストレージを構成します。

次の手順を使用して、AKS クラスターに接続します。
1. Azure portal を開き、「WLS on AKS をデプロイする」セクションでプロビジョニングしたリソースグループに移動します。
2. リソース一覧から AKS クラスターを選択し、[接続] を選択して AKS クラスターに接続します。
3. [Azure CLI] を選択し、手順に従ってローカルターミナルの AKS クラスターに接続します。
WLS イメージモデル YAML から topology: エントリを取得するには、次の手順を使用します。
1. Azure portal を開き、「WLS on AKS をデプロイする」セクションでプロビジョニングしたリソースグループに移動します。
2. [設定]>[デプロイ] を選択します。名前が oracle.20210620-wls-on-aks で始まる最初のデプロイを選択します。
3. [出力] を選択します。 shellCmdtoOutputWlsImageModelYaml 値をクリップボードにコピーします。この値は、モデルファイルの base64 文字列をデコードし、model.yaml という名前のファイルに内容を保存するシェルコマンドです。
4. 値を Bash ターミナルに貼り付け、コマンドを実行して model.yaml ファイルを生成します。
5. ファイルを編集して、最上位の topology: エントリを除き、すべての内容を削除します。 topology: を除き、ファイルには最上位レベルのエントリは存在しません。
6. ファイルを保存します。
次の手順に従って、WLS ドメインモデル YAML から ConfigMap 名と名前空間名を取得します。
1. Azure portal を開き、「WLS on AKS をデプロイする」セクションでプロビジョニングしたリソースグループに移動します。
2. [設定]>[デプロイ] を選択します。名前が oracle.20210620-wls-on-aks で始まる最初のデプロイを選択します。
3. [出力] を選択します。 shellCmdtoOutputWlsDomainYaml の値をクリップボードにコピーします。この値は、モデルファイルの base64 文字列をデコードし、model.yaml に内容を保存するシェルコマンドです。
4. ターミナルに値を貼り付けると、domain.yaml という名前のファイルが表示されます。
5. domain.yaml で次の値を調べます。
  - spec.configuration.model.configMap. 既定値を受け入れた場合、この値は sample-domain1-wdt-config-map です。
  - metadata.namespace. 既定値を受け入れた場合、この値は sample-domain1-ns です。
  便宜上、次のコマンドを使用して、これらの値をシェル変数として保存できます。
```
export CONFIG_MAP_NAME=sample-domain1-wdt-config-map
export WLS_NS=sample-domain1-ns
```

次のコマンドを使用して ConfigMap YAML を取得します。

kubectl get configmap ${CONFIG_MAP_NAME} -n ${WLS_NS} -o yaml > configMap.yaml

次の手順を使用して、tlog-db-model.yaml ファイルを作成します。
1. テキストエディターで、tlog-db-model.yaml という名前の空のファイルを作成します。
2. model.yaml の内容を挿入し、空白行を追加して、configMap.yaml ファイルの内容を挿入します。

tlog-db-model.yaml ファイルで、　ListenPort: 8001 で終わる行を見つけます。このテキストを次の行に追加します。次の例に示されているように、TransactionLogJDBCStore が ListenPort の真下に配置され、次のスニペットの残りの行が 2 文字分インデントされるように細心の注意を払います。

TransactionLogJDBCStore:
  Enabled: true
  DataSource: jdbc/WebLogicCafeDB
  PrefixName: TLOG_${serverName}_

完成した tlog-db-model.yaml は、次の例に非常に近いものになるはずです。

topology:
  Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
  ProductionModeEnabled: true
  AdminServerName: "admin-server"
  Cluster:
    "cluster-1":
      DynamicServers:
        ServerTemplate: "cluster-1-template"
        ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
        DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MinDynamicClusterSize: "0"
        CalculatedListenPorts: false
  Server:
    "admin-server":
      ListenPort: 7001
  ServerTemplate:
    "cluster-1-template":
      Cluster: "cluster-1"
      ListenPort: 8001
      TransactionLogJDBCStore:
        Enabled: true
        DataSource: jdbc/WebLogicCafeDB
        PrefixName: TLOG_${serverName}_
  SecurityConfiguration:
    NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
    NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"

resources:
  JDBCSystemResource:
    jdbc/WebLogicCafeDB:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/WebLogicCafeDB
          ]
          GlobalTransactionsProtocol: None
        JDBCDriverParams:
          DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
          URL: '@@SECRET:ds-secret-sqlserver-1709938597:url@@'
          PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1709938597:password@@'
          Properties:
            user:
              Value: '@@SECRET:ds-secret-sqlserver-1709938597:user@@'
        JDBCConnectionPoolParams:
            TestTableName: SQL SELECT 1
            TestConnectionsOnReserve: true

WLS モデルを ConfigMap でオーバーライドします。 WLS モデルをオーバーライドするには、既存の ConfigMap を新しいモデルに置き換えます。詳細については、Oracle ドキュメントの「既存のモデルの更新」を参照してください。次のコマンドを実行して、ConfigMap を再作成します。

export CM_NAME_FOR_MODEL=sample-domain1-wdt-config-map
kubectl -n sample-domain1-ns delete configmap ${CM_NAME_FOR_MODEL}

# replace path of tlog-db-model.yaml
kubectl -n sample-domain1-ns create configmap ${CM_NAME_FOR_MODEL} \
  --from-file=tlog-db-model.yaml
kubectl -n sample-domain1-ns label configmap ${CM_NAME_FOR_MODEL} \
  weblogic.domainUID=sample-domain1

次のコマンドを使用して、WLS クラスターを再起動します。新しいモデルを動作させるには、ローリングアップデートを実行する必要があります。

export RESTART_VERSION=$(kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}')
# increase restart version
export RESTART_VERSION=$((RESTART_VERSION + 1))

kubectl -n sample-domain1-ns patch domain sample-domain1 \
    --type=json \
    '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "'${RESTART_VERSION}'" }]'

次に進む前に、WLS ポッドが実行されていることを確認します。次のコマンドを使用して、ポッドの状態を監視できます。

kubectl get pod -n sample-domain1-ns -w

Note

この記事では、WLS モデルは、WLS on AKS オファーによって作成されたアプリケーションコンテナーイメージに含まれています。 TLOG は、モデルファイルを含んだ WDT ConfigMap で既存のモデルをオーバーライドして構成され、ドメイン CRD configuration.model.configMap フィールドを使用してマップを参照します。運用シナリオでは、Model in Image モデルファイル、アプリケーションアーカイブファイル、および WebLogic Deploy Tooling インストールをポッドに含める場合、補助イメージが推奨される最適なアプローチです。この機能を使用すると、domain.spec.image で指定したイメージにこれらのファイルを提供する必要がなくなります。

Azure Backup を使用して geo 冗長性を構成する

このセクションでは、Azure Backup を使用して、クラスターにインストールする必要がある Backup 拡張機能を使用して AKS クラスターをバックアップします。

次の手順に従って、geo 冗長性を構成します。

「ストレージアカウントとストレージコンテナーを作成してサンプルアプリケーションを保持する」セクションで作成したストレージアカウントに、AKS バックアップ拡張機能用の新しいストレージコンテナーを作成します。

次のコマンドを使用して AKS バックアップ拡張機能をインストールし、クラスターの CSI ドライバーとスナップショットを有効にします。

#replace with your resource group name.
export RG_NAME=wlsaks-eastus-20240109
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv)

az aks update \
    --resource-group ${RG_NAME} \
    --name ${AKS_NAME} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

ドライバーが有効になるまで約 5 分かかります。次に進む前に、エラーなしでコマンドが完了したことを確認してください。

AKS がデプロイされているリソースグループを開きます。リソース一覧から AKS クラスターを選択します。
AKS ランディングページで、[設定]>[バックアップ]>[拡張機能のインストール] を選択します。
[AKS Backup 拡張機能のインストール] ページで、[次へ] を選択します。前の手順で作成したストレージアカウントと BLOB コンテナーを選択します。 [次へ]、[作成] の順に選択します。これらの手順が完了するまで約 3 分かかります。

Azure portal を開き、上部の検索バーで Backup コンテナーを検索します。 [サービス] の下に Backup コンテナーが表示されます。それを選択します。
AKS Backup を有効にするには、「Azure Backup を使用して Azure Kubernetes Service をバックアップする」の手順 (「AKS バックアップ中にフックを使用する」セクションの前まで) に従います。次の手順で示されている調整を行います。
[バックアップコンテナーの作成] セクションに到達したら、次の調整を行います。
- 手順 1 の [リージョン] で [米国東部] を選択します。 [バックアップストレージの冗長性] で、[グローバルな冗長性] を使用します。
- 手順 2 で、[リージョンをまたがる復元] を有効にします。
[バックアップポリシーの作成] セクションに到達し、保持ポリシーの作成を求められたら、次の調整を行います。
1. [Vault-Standard] が選択されている保持ルールを追加します。
2. [追加] を選択します。
[バックアップの構成] セクションに到達したら、次の調整を行います。手順 1 から 5 は、AKS 拡張機能のインストール用です。手順 1 から 5 をスキップし、手順 6 から開始します。
- 手順 7 で、アクセス許可のエラーが発生します。 [アクセス許可の付与] を選択して次に進みます。アクセス許可のデプロイが完了した後もエラーが表示される場合は、[再検証] を選択してロールの割り当てを更新します。
- 手順 10 では、[バックアップするリソースの選択] を見つけて、次の調整を行います。
  - [バックアップインスタンス名] に、一意の名前を入力します。
  - [名前空間] で、WebLogic Operator と WebLogic Server の名前空間を選択します。この記事では、weblogic-operator-ns と sample-domain1-ns を選択します。
  - [その他のオプション] で、すべてのオプションを選択します。 [シークレットを含める] が選択されていることを確認します。
- 手順 11 では、ロールの割り当てのエラーが発生します。一覧からデータソースを選択し、[不足しているロールの割り当て] を選択してエラーを軽減します。

セカンダリリージョンで WLS クラスターの復元を準備する

このセクションでは、セカンダリリージョンの WLS クラスターの復元を準備します。ここでは、セカンダリリージョンは米国西部です。復元する前に、AKS Backup 拡張機能を備えた AKS クラスターが米国西部リージョンにインストールされている必要があります。

geo レプリケーションのための Azure Container Registry を構成する

次の手順を使用して、geo レプリケーション用に Azure Container Registry (ACR) を構成します。これには、「WLS on AKS をデプロイする」セクションで作成した WLS イメージが含まれています。 ACR レプリケーションを有効にするには、Premium 価格プランにアップグレードする必要があります。詳細については、「Azure Container Registry の geo レプリケーション」を参照してください。

「WLS on AKS をデプロイする」セクションでプロビジョニングしたリソースグループを開きます。リソース一覧から、名前が wlsaksacr で始まる ACR を選択します。
ACR ランディングページで、[設定]>[プロパティ] を選択します。 [価格プラン] では、[Premium] を選択して [保存] を選択します。
ナビゲーションウィンドウで、[サービス]>[geo レプリケーション] を選択します。 [追加] を選択して、ページにレプリケーションリージョンを追加します。
[レプリケーションの作成] ページの [場所] で [米国西部] を選択し、[作成] を選択します。

デプロイが完了すると、geo レプリケーションに対して ACR が有効になります。

セカンダリリージョンにストレージアカウントを作成する

AKS Backup 拡張機能を有効にするには、同じリージョンで空のコンテナーを持つストレージアカウントを指定する必要があります。

リージョンをまたいでバックアップを復元するには、バックアップデータがハイドレートされるステージング場所を指定する必要があります。このステージング場所には、復元用のターゲットクラスターと同じリージョンおよびサブスクリプション内のリソースグループとストレージアカウントが含まれます。

次の手順を使って、ストレージアカウントとコンテナーを作成します。これらの手順の一部は、他のガイドを参照するようになっています。

Azure portal にサインインします。
「ストレージアカウントを作成する」の手順に従って、ストレージアカウントを作成します。この記事のすべての手順を実行する必要はありません。 [基本] ウィンドウに表示されるフィールドに入力します。 [リージョン] で [米国西部] を選択し、[確認と作成] を選択して既定のオプションをそのまま使用します。アカウントの検証と作成に進んでから、この記事に戻ります。
「クイックスタート: Azure portal での BLOB のアップロード、ダウンロード、一覧表示」の「コンテナーの作成」セクションの手順に従って、AKS Backup 拡張機能のストレージコンテナーを作成します。
復元時に使用するステージング場所としてストレージコンテナーを作成します。

セカンダリリージョンで AKS クラスターを準備する

以降のセクションでは、セカンダリリージョンで AKS クラスターを作成する方法について説明します。

新しい AKS クラスターを作成する

この記事では、Application Gateway イングレスコントローラーを使用して WLS アプリケーションを公開します。このセクションでは、米国西部リージョンに新しい AKS クラスターを作成します。次に、新しいアプリケーションゲートウェイインスタンスでイングレスコントローラーアドオンを有効にします。詳細については、「新しいアプリケーションゲートウェイインスタンスを使用して新しい AKS クラスターのイングレスコントローラーアドオンを有効にする」を参照してください。

次の手順に従って、AKS クラスターを作成します。

次のコマンドを使用して、セカンダリリージョンにリソースグループを作成します。
```
export RG_NAME_WESTUS=wlsaks-westus-20240109

az group create --name ${RG_NAME_WESTUS} --location westus
```
アドオンが有効になっている AKS クラスターをデプロイするには、次のコマンドを使用します。
```
export AKS_NAME_WESTUS=${RG_NAME_WESTUS}aks
export GATEWAY_NAME_WESTUS=${RG_NAME_WESTUS}gw

az aks create \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --network-plugin azure \
    --enable-managed-identity \
    --enable-addons ingress-appgw \
    --appgw-name ${GATEWAY_NAME_WESTUS} \
    --appgw-subnet-cidr "10.225.0.0/16" \
    --generate-ssh-keys
```
このコマンドは、AKS ノードリソースグループ内の名前 ${RG_NAME_WESTUS}gw を持つ Standard_v2 SKU アプリケーションゲートウェイインスタンスを自動的に作成します。既定では、リソースグループの場所の名前は MC_resource-group-name_cluster-name_location です。

Note

「WLS on AKS をデプロイする」セクションでプロビジョニングした AKS クラスターは、米国東部リージョンの 3 つの可用性ゾーンにわたって実行されます。可用性ゾーンは、米国西部リージョンではサポートされていません。米国西部の AKS クラスターはゾーン冗長ではありません。運用環境でゾーン冗長が必要な場合は、ペアのリージョンで可用性ゾーンがサポートされていることを確認します。詳細については、「可用性ゾーンを使用する Azure Kubernetes Service (AKS) クラスターの作成」の「AKS クラスターの可用性ゾーンの概要」セクションを参照してください。

次のコマンドを使用して、アプリケーションゲートウェイインスタンスのパブリック IP アドレスを取得します。 IP アドレスを保存しておいてください。この記事の後半で使用します。

export APPGW_ID=$(az aks show \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --query 'addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId' \
    --output tsv)
echo ${APPGW_ID}
export APPGW_IP_ID=$(az network application-gateway show \
    --id ${APPGW_ID} \
    --query frontendIPConfigurations\[0\].publicIPAddress.id \
    --output tsv)
echo ${APPGW_IP_ID}
export APPGW_IP_ADDRESS=$(az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query ipAddress \
    --output tsv)
echo "App Gateway pubilc IP address: ${APPGW_IP_ADDRESS}"

次のコマンドを使用して、ドメインネームサービス (DNS) の名前ラベルをパブリック IP アドレスリソースにアタッチします。 <your-chosen-DNS-name> を適切な値 (ejb010316 など) に置き換えます。
```
az network public-ip update --ids ${APPGW_IP_ID} --dns-name <your-chosen-DNS-name>
```
az network public-ip show で、パブリック IP の完全修飾ドメイン名 (FQDN) を確認できます。次の例は、DNS ラベル ejb010316 を持つ FQDN を示しています。
```
az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query dnsSettings.fqdn \
    --output tsv
```
次の例のような出力が表示されます。
```
ejb010316.westus.cloudapp.azure.com
```

Note

既存の AKS クラスターを使用している場合は、先に進む前に次の 2 つのアクションを実行します。

「既存の AKS クラスターに対してアプリケーションゲートウェイのイングレスコントローラーアドオンを有効にする」の手順に従って、イングレスコントローラーアドオンを有効にします。
ターゲット名前空間で WLS を実行している場合は、競合を回避するために、WebLogic Operator 名前空間と WebLogic Server 名前空間の WLS リソースをクリーンアップします。この記事では、WLS on AKS オファーによって、名前空間 weblogic-operator-ns に WebLogic 演算子がプロビジョニングされ、名前空間 sample-domain1-ns に WebLogic Server がプロビジョニングされました。 kubectl delete namespace weblogic-operator-ns sample-domain1-ns を実行して、2 つの名前空間を削除してください。

AKS Backup 拡張機能を有効にする

続行する前に、次の手順を使用して、セカンダリリージョンのクラスターに AKS Backup 拡張機能をインストールします。

次のコマンドを使用して、米国西部リージョンの AKS クラスターに接続します。
```
az aks get-credentials \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS}
```

次のコマンドを使用して、クラスターの CSI ドライバーとスナップショットを有効にします。

az aks update \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

AKS がデプロイされているリソースグループを開きます。リソース一覧から AKS クラスターを選択します。
AKS ランディングページで、[設定]>[バックアップ]>[拡張機能のインストール] を選択します。
[AKS Backup 拡張機能のインストール] ページで、[次へ] を選択します。前の手順で作成したストレージアカウントと BLOB コンテナーを選択します。 [次へ]、[作成] の順に選択します。これらの手順が完了するまで約 3 分かかります。

Note

コストを節約するには、「Azure Kubernetes Service (AKS) クラスターの停止と開始」の手順に従って、セカンダリリージョンの AKS クラスターを停止できます。 WLS クラスターを復元する前にそれを開始します。

Vault-Standard バックアップが行われるのを待つ

AKS では、Vault-Standard 階層 が geo 冗長性およびリージョンをまたがる復元をサポートする唯一の階層です。「AKS のバックアップがサポートされているバックアップストレージ階層」に記載されているように、"コンテナー階層に移動できるスケジュールされた復旧ポイントは 1 日に 1 つだけです"。Vault-Standard バックアップが実行されるまで待つ必要があります。前の手順を完了してから少なくとも 24 時間待ってから続行することが適切です。

プライマリクラスターを停止する

プライマリ WLS クラスターとセカンダリ WLS クラスターは、同じ TLOG データベースで構成されます。データベースを同時に所有できるクラスターは 1 つだけです。セカンダリクラスターが正しく動作するようにするには、プライマリ WLS クラスターを停止します。この記事では、次の手順を使用して、AKS クラスターを停止して WLS クラスターを無効にします。

Azure portal を開き、「WLS on AKS をデプロイする」セクションでプロビジョニングしたリソースグループに移動します。
リソースグループに一覧表示されている AKS クラスターを開きます。
[停止] を選択して、AKS クラスターを停止します。次に進む前に、デプロイが完了していることを確認してください。

WLS クラスターを復元する

AKS バックアップは、運用層とコンテナー層の両方のバックアップをサポートします。別のリージョン (Azure ペアリージョン) にあるクラスターへの復元には、コンテナー層に保存されているバックアップのみを使用できます。バックアップポリシーで設定された保持ルールに従って、その日の最初の正常なバックアップがリージョンをまたいで BLOB コンテナーに移動されます。詳細については、「Azure Kubernetes Service バックアップとは」の「AKS のバックアップがサポートされているバックアップストレージ階層」セクションを参照してください。

[Azure Backup を使用して geo 冗長性を構成する] セクションで geo 冗長性を構成した後、コンテナー階層のバックアップが復元可能になるまでに少なくとも 1 日かかります。

次の手順に従って、WLS クラスターを復元します。

Azure portal を開き、バックアップセンターを検索します。 [サービス] で [バックアップセンター] を選択します。
[管理] で、[バックアップインスタンス] を選択します。データソースの種類 Kubernetes Services でフィルター処理して、前のセクションで作成したバックアップインスタンスを見つけます。
バックアップインスタンスを選択して、復元ポイントの一覧を表示します。この記事では、インスタンス名は wlsonaks*\wlsaksinstance20240109 のような文字列です。
最新の運用および Vault-Standard バックアップを選択し、[その他のオプション] を選択します。 [復元] を選択して復元プロセスを開始します。
[復元] ページの既定のウィンドウは [復元ポイント] です。 [前へ] を選択して、[基本] ウィンドウに変更します。 [復元リージョン] で [セカンダリリージョン] を選択し、[次へ: 復元ポイント] を選択します。
[復元ポイント] ウィンドウの [復元する層の選択] で [コンテナーストア] を選択し、[次へ:復元パラメーター] を選択します。
[パラメーターの復元] ウィンドウで、次の手順を使用します。
1. [ターゲットクラスターの選択] で、米国西部リージョンで作成した AKS クラスターを選択します。次のスクリーンショットに示すように、アクセス許可の問題が発生します。 [アクセス許可の付与] を選択してエラーを軽減します。
2. [バックアップのステージング場所] で、米国西部で作成したストレージアカウントを選択します。次のスクリーンショットに示すように、アクセス許可の問題が発生します。 [不足しているロールの割り当て] を選択して、エラーを軽減します。
3. ロールの割り当てが完了した後もエラーが発生する場合は、[再検証] を選択してアクセス許可を更新します。
4. 不足しているアクセス許可を付与するときに、[スコープ] の指定を求められた場合は、既定値をそのまま使用します。
5. [検証] を選択します。 "検証が正常に完了しました" というメッセージが表示されます。表示されない場合は、トラブルシューティングで問題を解決してから続行してください。
[次へ:確認と復元] を選択し、[復元] を選択します。 WLS クラスターの複製には約 10 分かかります。
次のスクリーンショットに示すように、[バックアップセンター]>[監視とレポート]>[バックアップジョブ] から復元プロセスを監視できます。
最新の進行状況を表示するには、[最新の情報に更新] を選択します。
エラーなしでプロセスが完了したら、バックアップ AKS クラスターを停止します。停止しないと、後の手順で TLOG データベースにアクセスするときに所有権の競合が発生します。
プライマリクラスターを起動します。

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. 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 名を確認する] の手順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. 手順 4 では、/weblogic/ready にアクセスできません。セカンダリクラスターが停止しているために想定されます。
  3. プライマリエンドポイントを再び有効にします。

これで、Traffic Manager プロファイルでは、プライマリエンドポイントの状態が [有効] と [オンライン] になり、フェールオーバーエンドポイントの状態が [有効] と [機能低下] になります。後でエンドポイントの状態を監視できるように、ページを開いたままにしておきます。

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

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

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

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

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

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

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

プライマリからセカンダリにフェールオーバーするには、次の手順を使用します。

まず、次の手順を使用して、プライマリ AKM クラスターを停止します。

Azure portal を開き、「WLS on AKS をデプロイする」セクションでプロビジョニングしたリソースグループに移動します。
リソースグループに一覧表示されている AKS クラスターを開きます。
[停止] を選択して、AKS クラスターを停止します。次に進む前に、デプロイが完了していることを確認してください。

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

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

次に、次の手順を使用してセカンダリクラスターを起動します。

Azure portal を開き、セカンダリリージョンに AKS クラスターがあるリソースグループに移動します。
リソースグループに一覧表示されている AKS クラスターを開きます。
[開始] を選択して AKS クラスターを起動します。次に進む前に、デプロイが完了していることを確認してください。

最後に、次の手順を使用して、エンドポイント 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 をトリガーする」を参照してください。

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

プライマリサイトにフェールバックするには、2 つのクラスターにミラーバックアップ構成があることを確認する必要があります。次の手順を使用すると、この状態を達成できます。

手順 4 から始まる「Azure Backup を使用して geo 冗長性を構成する」セクションの手順に従って、米国西部リージョンで AKS クラスターバックアップを有効にします。
「セカンダリリージョンで WLS クラスターの復元を準備する」セクションの手順に従って、最新のコンテナー階層バックアップを米国東部リージョンのクラスターに復元します。既に完了した手順をスキップします。
「セカンダリサイトへのフェールオーバー」セクションの似たような手順を使用して、データベースサーバーとクラスターを含むプライマリサイトにフェールバックします。

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

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

Azure portal の上部にある検索ボックスに「バックアップコンテナー」と入力し、検索結果からバックアップコンテナーを選択します。
[管理]>[プロパティ]>[論理的な削除]>[更新] を選択します。 [論理的な削除を有効にする] の横にあるチェックボックスの選択を解除します。
[管理]>[バックアップインスタンス] を選択します。作成したインスタンスを選択して削除します。
Azure Portal の上部にある検索ボックスで SQL Database サーバーのリソースグループ名 (例: myResourceGroup) を入力し、検索結果から一致するリソースグループを選択します。
[リソースグループの削除] を選択します。
[削除するリソースグループ名を入力する] で、リソースグループ名を入力します。
[削除] を選択します。
Traffic Manager のリソースグループに対して、手順 4 ～ 7 を繰り返します (例: myResourceGroupTM1)。
プライマリ WLS クラスターのリソースグループに対して、手順 4 ～ 7 を繰り返します (例: wls-aks-eastus-20240109)。
セカンダリ WLS クラスターのリソースグループに対して、手順 4 ～ 7 を繰り返します (例: wls-aks-westus-20240109)。

次のステップ

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

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

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

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

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

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

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

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

次の方法で共有

チュートリアル: geo 冗長性を使用して Oracle WebLogic Server を Azure Kubernetes Service (AKS) に移行する

前提条件

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

フェールオーバーグループの JDBC 接続文字列とデータベース管理者ユーザー名を取得する

AKS でプライマリ WLS クラスターを設定して構成する

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

サンプルアプリケーションを保持するストレージアカウントとストレージコンテナーを作成する

AKS に WLS をデプロイする

TLOG データのストレージを構成する

Azure Backup を使用して geo 冗長性を構成する

セカンダリリージョンで WLS クラスターの復元を準備する

geo レプリケーションのための Azure Container Registry を構成する

セカンダリリージョンにストレージアカウントを作成する

セカンダリリージョンで AKS クラスターを準備する

新しい AKS クラスターを作成する

AKS Backup 拡張機能を有効にする

Vault-Standard バックアップが行われるのを待つ

プライマリクラスターを停止する

WLS クラスターを復元する

Azure Traffic Manager の設定

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

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

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

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

チュートリアル: geo 冗長性を使用して Oracle WebLogic Server を Azure Kubernetes Service (AKS) に移行する

前提条件

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

フェールオーバー グループの JDBC 接続文字列とデータベース管理者ユーザー名を取得する

AKS でプライマリ WLS クラスターを設定して構成する

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

サンプル アプリケーションを保持するストレージ アカウントとストレージ コンテナーを作成する

AKS に WLS をデプロイする

TLOG データのストレージを構成する

Azure Backup を使用して geo 冗長性を構成する

セカンダリ リージョンで WLS クラスターの復元を準備する

geo レプリケーションのための Azure Container Registry を構成する

セカンダリ リージョンにストレージ アカウントを作成する

セカンダリ リージョンで AKS クラスターを準備する

新しい AKS クラスターを作成する

AKS Backup 拡張機能を有効にする

Vault-Standard バックアップが行われるのを待つ

プライマリ クラスターを停止する

WLS クラスターを復元する

Azure Traffic Manager の設定

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

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

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

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

次のステップ

フィードバック

その他のリソース

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

フェールオーバーグループの JDBC 接続文字列とデータベース管理者ユーザー名を取得する

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

サンプルアプリケーションを保持するストレージアカウントとストレージコンテナーを作成する

セカンダリリージョンで WLS クラスターの復元を準備する

セカンダリリージョンにストレージアカウントを作成する

セカンダリリージョンで AKS クラスターを準備する

プライマリクラスターを停止する

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

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