チュートリアル: 高可用性とディザスター リカバリーを使用して、WebSphere Liberty または Open Liberty を Azure Kubernetes Service に移行する

  • [アーティクル]

このチュートリアルでは、Azure Kubernetes Service (AKS) で WebSphere Liberty または Open Liberty を使用して、Java の高可用性とディザスター リカバリー (HA/DR) を実装する簡単で効果的な方法について説明します。 このソリューションは、WebSphere Liberty または Open Liberty で実行されている単純なデータベース 駆動型 Jakarta Enterprise Edition アプリケーションを使用して、低く設定された目標復旧時間 (RTO) と目標復旧時点 (RPO) を達成するための方法を示しています。

HA/DR は複雑なトピックであり、多くのソリューションが考えられます。 最適なソリューションは、独自の要件によって異なります。 HA/DR を実装するその他の方法については、この記事の最後にあるリソースを参照してください。

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

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

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

高可用性とディザスター リカバリーを備えた AKS 上の WebSphere Liberty または Open Liberty のソリューション アーキテクチャの図。

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

データベース層は、プライマリ サーバーとセカンダリ サーバーを含む Azure SQL Database フェールオーバー グループで構成されます。 読み取り/書き込みリスナー エンドポイントは常にプライマリ サーバーを指し、各リージョンの WebSphere Liberty または Open Liberty クラスターに接続されます。 geo フェールオーバーでは、グループ内のすべてのセカンダリ データベースがプライマリ ロールに切り替まれます。 Azure SQL Database の geo フェールオーバー RPO と RTO については、「Azure SQL Database を使用したビジネス継続性の概要」を参照してください。

このチュートリアルは、Azure Backup サービスと Azure SQL Database サービスの HA 機能に依存しているため、これらのサービスを使用した手順が記述されています。 他のデータベースを選択することもできますが、選択したデータベースの HA 機能を考慮する必要があります。

前提条件

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

このセクションでは、WebSphere Liberty または Open Liberty クラスターとアプリで使用するために、ペアになっているリージョンで Azure SQL Database フェールオーバー グループを作成します。 後のセクションでは、セッション データとトランザクション ログをこのデータベースに格納するように WebSphere Liberty または Open Liberty を構成します。 このプラクティスでは、セッション永続化用のテーブルの作成を参照します。

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

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

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

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

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

    1. フェールオーバー グループを作成するための手順 5 で、一意のフェールオーバー グループ名 (例: failovergroup-mjg032524) を入力して保存しておきます。
    2. サーバーを構成する手順 5 で、新しいセカンダリ サーバーを作成するオプションを選択し、次の手順を実行します。
      1. たとえば sqlserversecondary-mjg032524 などの一意のサーバー名を入力します。
      2. プライマリ サーバーと同じサーバー管理者とパスワードを入力します。
      3. [場所] に [(US) 米国西部] を選択します。
      4. [Azure サービスにサーバーへのアクセスを許可する] が選択されていることを確認します。
    3. グループ内のデータベースを構成する手順 5 で、たとえば、mySampleDatabase など、プライマリ サーバーで作成したデータベースを選択します。

  2. 「計画フェールオーバーのテスト」セクションのすべての手順を実行したら、[フェールオーバー グループ] ページを開いたままにしておきます。これは、後で WebSphere Liberty または Open Liberty クラスターのフェールオーバー テストに使用します。

AKS でプライマリ WebSphere Liberty または Open Liberty クラスターを設定する

このセクションでは、Azure Kubernetes Service オファーの IBM WebSphere Liberty と Open Liberty を使用して、AKS 上にプライマリ WebSphere Liberty または Open Liberty クラスターを作成します。 セカンダリ クラスターは、後で Azure Backup を使用してフェールオーバー中にプライマリ クラスターから復元されます。

プライマリ WebSphere Liberty/Open Liberty クラスターをデプロイする

次の手順を使用して、プライマリ クラスターをデプロイします。

  1. ブラウザーで Azure Kubernetes Service オファーで IBM WebSphere Liberty と Open Liberty を開き、[作成] を選択します。 オファーの [基本] ペインが表示されます。

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

    1. [サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
    2. このオファーを空のリソース グループにデプロイする必要があります。 [リソース グループ] フィールドで [新規作成] を選択し、リソース グループの固有値 (liberty-aks-eastus-mjg032524 など) を入力します。
    3. [インスタンス詳細] の[リージョン] で、[米国東部] を選択します。
    4. [次へ] を選択して、[AKS] ウィンドウに移動します。

    Azure Kubernetes Service での IBM WebSphere Liberty と Open Liberty の [基本] ペインが表示されている Azure Portal のスクリーンショット。

  3. しばらく待機します。 [AKS] ペインで、すべてのフィールドに既定値が事前に設定されていることを確認してください。 [次へ] を選択して、[負荷分散] ペインに移動します。

    Azure Kubernetes Service での IBM WebSphere Liberty と Open Liberty の [AKS] ペインが表示されている Azure Portal のスクリーンショット。

  4. 次の手順を実行して、[負荷分散] ペインを入力します。

    1. [Connect to Azure Application Gateway?] (Azure Application Gateway に接続しますか?) には [はい] を選びます。
    2. 他のフィールドはデフォルトのままにします。
    3. [次へ] を選択して、[オペレーターとアプリケーション] ペインに移動します。

    Azure Kubernetes Service での IBM WebSphere Liberty と Open Liberty の [負荷分散] ペインが表示されている Azure Portal のスクリーンショット。

  5. 次の手順に従って、[オペレーターとアプリケーション] ペインに情報を入力します。

    1. すべてのフィールドをデフォルトのままにします。

      Note

      このチュートリアルでは、既定値を使用して Open Liberty オペレーターをデプロイします。 必要に応じて、[IBM でサポートされている] で [はい] を選択して、WebSphere Liberty オペレーターをデプロイすることができます。

    2. [Review + create](レビュー + 作成) を選択します。

    3. [最後の検証を実行中...] が正常に完了するまで待機し、[作成] を選択します。

    Azure Kubernetes Service での IBM WebSphere Liberty と Open Liberty の [オペレーターとアプリケーション] ペインが表示されている Azure Portal のスクリーンショット。

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

Note

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

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

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

AKS クラスター、Azure Container Registry (ACR) インスタンス、および Azure Application Gateway をプライマリ リージョンにデプロイしました。 AKS クラスターは、アプリがデプロイされて実行されているターゲット コンピューティング プラットフォームです。 ACR インスタンスには、アプリのデプロイ中に AKS によってプルされるアプリケーション イメージが格納されます。 Azure Application Gateway は、AKS クラスターにデプロイされたアプリケーションのロード バランサーとして機能します。

次の手順に進む前に、以下の手順を使用してこれらの主要なコンポーネントを確認します。

  1. [デプロイ] ページに戻り、[出力] を選択します。

  2. プロパティ cmdToConnectToCluster の値をコピーします。 ターミナルを開き、コピーしたコマンドを貼り付け、Enter キーを押して実行します。 出力に含まれる次の例ようなメッセージが表示されます。

    Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config

  3. 後でクラスターに接続するために使用するため、このコマンドを保存しておきます。

  4. ターミナルで kubectl get pod --all-namespaces を実行して、AKS クラスターで実行されているすべてのポッドを一覧表示します。 次の例のような出力が表示されます。

    NAMESPACE      NAME                                        READY   STATUS    RESTARTS      AGE
cert-manager   cert-manager-66bc9756fd-255pk               1/1     Running   0             8m55s
cert-manager   cert-manager-cainjector-669c9fb694-k4q88    1/1     Running   0             8m55s
cert-manager   cert-manager-webhook-84967d556d-vj4lp       1/1     Running   0             8m55s
kube-system    azure-ip-masq-agent-dgzkt                   1/1     Running   0             29m
kube-system    cloud-node-manager-6x7bp                    1/1     Running   0             29m
kube-system    coredns-789789675-6b7dh                     1/1     Running   0             28m
kube-system    coredns-789789675-n68wt                     1/1     Running   0             29m
kube-system    coredns-autoscaler-649b947bbd-zhdbn         1/1     Running   0             29m
kube-system    csi-azuredisk-node-h9p7m                    3/3     Running   0             29m
kube-system    csi-azurefile-node-jnllw                    3/3     Running   0             29m
kube-system    ingress-appgw-deployment-69944d8fb9-v9btr   1/1     Running   5 (12m ago)   17m
kube-system    konnectivity-agent-94878f88c-hfqng          1/1     Running   0             29m
kube-system    konnectivity-agent-94878f88c-ln2vp          1/1     Running   0             29m
kube-system    kube-proxy-28lkg                            1/1     Running   0             29m
kube-system    metrics-server-5fffcb8954-549xl             2/2     Running   0             28m
kube-system    metrics-server-5fffcb8954-fn56g             2/2     Running   0             28m
open-liberty   olo-controller-manager-7954d76cf8-qhmxw     1/1     Running   0             8m40s

  5. ターミナルで kubectl get secret を実行して、AKS クラスターにインストールされているすべてのシークレットを一覧表示します。 次の例に示されているように、出力に 1 つのシークレットが表示されます。

    NAME           TYPE                DATA   AGE
secret3984d1   kubernetes.io/tls   2      24m

    このシークレットは、TLS トラフィックの証明書とキー データを含む TLS シークレットです。 シークレットの名前をコピーして保存します。この例では、secret3984d1 です。これは、後でアプリのデプロイで使用します。

  6. [出力] ページに戻ります。 プロパティ cmdToLoginInRegistry の値をコピーします。 ターミナルでコピーしたコマンドを貼り付け、Enter キーを押して実行します。 出力に「Login Succeeded (ログインに成功しました)」が表示されます。 ターミナルを開いたままにします。これは、後で WebSphere Liberty/Open Liberty クラスターをさらに構成するために使用します。

次の手順を使用して、Azure Application Gateway のパブリック IP アドレスの名前と DNS 名を取得します。 これらは、後でアプリのデプロイと Azure Traffic Manager のセットアップに使用します。

  1. Azure Portal で、検索ボックスに「Resource groups (リソース グループ)」と入力し、検索結果で [Resource groups (リソース グループ)] を選択します。
  2. たとえば liberty-aks-eastus-mjg032524 など、プライマリ リージョンのリソース グループの名前を選択します。
  3. プレフィックス gwip が付いているパブリック IP アドレス リソースを見つけて、その名前をコピーして保存しておきます。
  4. パブリック IP アドレス リソースを選択し、DNS 名 (例: olgw3984d1.eastus.cloudapp.azure.com) をコピーして保存します。

ACR インスタンスの geo レプリケーションを有効にする

ACR インスタンスは、プライマリ クラスターとセカンダリ クラスターの両方のアプリケーション イメージを格納するように設計されています。 次の手順に従って、ACR インスタンスの geo レプリケーションを有効にします。

  1. Azure Portal で、検索ボックスに「Resource groups (リソース グループ)」と入力し、検索結果で [Resource groups (リソース グループ)] を選択します。

  2. たとえば liberty-aks-eastus-mjg032524 など、プライマリ リージョンのリソース グループの名前を選択します。

  3. プレフィックス acr が付いたコンテナー レジストリ リソースを見つけ、それを選択して開きます。

  4. プロパティを選択します。 [価格プラン] では、[Premium] を選択して [保存] を選択します。 完了するまで待ちます。

  5. [geo レプリケーション] を選択し、[追加] を選択します。 [場所] で [米国西部] を選択し、[作成] を選択します。 完了するまで待ちます。

  6. しばらく待ってから、[最新の情報に更新] を選択します。 2 つの場所が一覧表示され、[状態] が [準備完了] になるまで操作を繰り返します。

    ペア リージョンで geo レプリケーションが有効になっている ACR インスタンスが示されている Azure portal のスクリーンショット。

次の手順に従って、ACR サインイン資格情報を取得します。 これらは、後でアプリのデプロイに使用します。

  1. [アクセス キー] を選択します。
  2. [ログイン サーバー]、[ユーザー名]、[パスワード] の値をコピーして保存しておきます。

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

以下のステップを使用して、後でディザスター リカバリー フェイルオーバー テストを行うために、サンプルの CRUD Java/Jakarta Enterprise Edition アプリケーションを WebSphere Liberty/Open Liberty クラスターにデプロイして実行します。

  1. 次のコマンドを使用してサンプルをダウンロードします。

    git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240325

    アプリケーションは、前にデプロイした Azure SQL Database に接続するデータ ソース jdbc/JavaEECafeDB を構成します。 このデータ ソースは、HTTP セッション データを格納するために使用されます。これにより、WebSphere Liberty/Open Liberty サーバーのクラスター全体でフェールオーバーと負荷分散が可能になります。 サンプル アプリも、同じデータソースにアプリケーション データ coffee を保存するための永続化スキーマを構成します。 サンプルのコンテキスト ルートが、server.xml ファイルで / として構成されていることに注意してください。

  2. 次のコマンドを使用して、前に保存した値で環境変数を定義します。

    export DB_SERVER_NAME=<failover-group-name>.database.windows.net
export DB_NAME=mySampleDatabase
export DB_USER=azureuser@<failover-group-name>
export DB_PASSWORD='<SQL-Server-admin-login-password>'
export LOGIN_SERVER=<ACR-login-server>
export USER_NAME=<ACR-username>
export PASSWORD='<ACR-password>'
export INGRESS_TLS_SECRET=<TLS-secret-name>

  3. 次のコマンドを使用して、アプリのパッケージ化、Docker イメージのビルド、イメージの ACR インスタンスへのプッシュ、AKS クラスターへのサンプルのデプロイを行います。

    cd $BASE_DIR/java-app
mvn clean install

cd $BASE_DIR/java-app/target

# If you deployed WebSphere Liberty Operator previously, use "Dockerfile-wlp" instead of "Dockerfile"
docker buildx build --platform linux/amd64 -t javaee-cafe:v1 --pull --file=Dockerfile .
docker tag javaee-cafe:v1 ${LOGIN_SERVER}/javaee-cafe:v1
docker login -u ${USER_NAME} -p ${PASSWORD} ${LOGIN_SERVER}
docker push ${LOGIN_SERVER}/javaee-cafe:v1

cd $BASE_DIR/java-app/target
kubectl apply -f db-secret.yaml

# If you deployed WebSphere Liberty Operator previously, use "webspherelibertyapplication-agic.yaml" instead of "openlibertyapplication-agic.yaml"
kubectl apply -f openlibertyapplication-agic.yaml

  4. 次のコマンドを実行して、デプロイしたサンプル アプリを取得します。

    # If you deployed WebSphere Liberty Operator previously, use "WebSphereLibertyApplication" instead of "OpenLibertyApplication"
kubectl get OpenLibertyApplication

    出力に READY アプリケーションが 1 つ表示されます。

    NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    45s

  5. 次のコマンドを実行して、デプロイ中に作成されたポッドの状態を取得します。

    kubectl get pods

    次の出力例では、すべてのポッドが実行中であることが示されています。 同様の出力が表示されない場合は、しばらく待ってから操作を繰り返してください。

    NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-6bbb8d6f5c-2xjc4   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-4f449   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-m2wg6   1/1     Running   0          1m

  6. 次の手順を実行して、アプリが想定通りに実行されているかを確認します。

    1. 新しいブラウザー タブで、前に保存した Azure Application Gateway のパブリック IP アドレスの DNS 名を開きます。 https プロトコルを使用します (例: https://olgw3984d1.eastus.cloudapp.azure.com)。 サンプル アプリのウェルカム ページが表示されます。

    2. 名前と価格が設定された新しいコーヒーを作成します (例: 価格が $10 のコーヒー 1)。これは、アプリケーション データ テーブルとデータベースのセッション テーブルの両方で保持されます。 以下のスクリーンショットのような UI が表示されます。

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

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

Azure Backup を使用してクラスター用のディザスター リカバリーを設定する

このセクションでは、Azure Backup を使用してプライマリ リージョンの AKS クラスターのディザスター リカバリーを設定します。

ストレージ アカウントの作成

AKS バックアップでは、BLOB コンテナーを使用して AKS クラスター リソースを保持します。 リージョン間の復元中に使用するステージングの場所として、別の BLOB コンテナーを作成します。

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

  1. Azure portal にサインインします。
  2. 「ストレージ アカウントを作成する」の手順に従って、ストレージ アカウントを作成します。 この記事に示されているすべての手順を実行する必要はありません。 [基本] ペインに示すように、次の手順に従ってフィールドに入力します。
    1. [リソース グループ] で、たとえば liberty-aks-eastus-mjg032524 など、プライマリ クラスターでデプロイされている既存のリソース グループを選択します。
    2. [ストレージ アカウント名] に一意の名前を入力します (例: storageeastusmjg032524)。
    3. [リージョン] で、 [米国東部] を選択します。
    4. [確認および作成] を選択して、既定の構成オプションをそのまま使用します。
    5. アカウントの検証と作成に進んでから、この記事に戻ります。
  3. 「ストレージ コンテナーの作成」の手順 に従って、AKS Backup 拡張機能のストレージ コンテナーを作成します。 このガイドでは、このコンテナー名に aks-backup-ext を使用します。
  4. 復元時に使用するステージングの場所として別のストレージ コンテナーを作成します。 このガイドでは、このコンテナー名に staging を使用します。

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

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

  1. クラスターの CSI ドライバーとスナップショットを有効にします。 次の az aks update コマンドでは、Bash 変数 RG_NAME の値をリソース グループ名 (たとえば liberty-aks-eastus-mjg032524) に更新し、ローカルの Bash ターミナルでこれを実行します。

    export RG_NAME=<your-aks-cluster-resource-group>
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv | tr -d '\r')

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

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

  2. AKS がデプロイされているリソース グループ (たとえば liberty-aks-eastus-mjg032524) を開きます。 リソース一覧から AKS クラスターを選択します。

  3. AKS ランディング ページの　[設定]で、[バックアップ] を選択し、[拡張機能のインストール] を選択します。

  4. [AKS Backup 拡張機能のインストール] ページで、[次へ] を選択します。 同じリソース グループで作成したストレージ アカウント storageeastusmjg032524 と BLOB コンテナー aks-backup-ext を選択します。 [次へ] を選択して、[作成] を選択します。 これらの手順が完了するまで約 3 分かかります。

AKS クラスターをバックアップする

次の手順に従って、AKS クラスターをバックアップします。

  1. Azure Portal の検索バーで、「バックアップ コンテナー」を検索します。 [サービス] の下にバックアップ コンテナーが表示されます。 それを選択します。

  2. 「Azure Backup を使用して Azure Kubernetes Service をバックアップする」の手順に従って、プライマリ クラスターの AKS バックアップを有効にします。 「AKS バックアップ中にフックを使用する」セクションの前までの手順を実行します。このセクションの残りの手順を使用して調整を行いながら進めます。

  3. 「バックアップ コンテナーの作成」セクションまで進んだら、次の手順を実行します。

    1. 手順 1 として、[リソース グループ] で、たとえば liberty-aks-eastus-mjg032524 など、プライマリ クラスターでデプロイされている既存のリソース グループを選択します。

    2. [バックアップ コンテナー名] に、一意の値 (例: aks-backup-vault-eastus-mjg032524) を入力します。

    3. [リージョン] で、 [米国東部] を選択します。

    4. [バックアップ ストレージの冗長性] で、[グローバルな冗長性] を選択します。

      [バクアップ コンテナー] の [基本] ウィンドウを示す Azure portal のスクリーンショット。

    5. 手順 2 では、[リージョンをまたがる復元] で [有効化] を選択します。

  4. 「バックアップ ポリシーの作成」セクションまで進んだら、次の手順を実行します。

    1. 手順 3 では、バックアップ ポリシーの名前 (例: aksbackuppolicy) を入力します。

    2. 同じリソース グループに作成したバックアップ コンテナー (例: aks-backup-vault-eastus-mjg032524) を選択します。

    3. 手順 4 で、[Vault-Standard] が選択されている保持ルールを追加します。

      [保持期間の追加] ペインで [Vault-standard] オプションが強調表示されている、[バックアップ ポリシーの作成] ページを示す Azure Portal のスクリーンショット。

    4. [追加] を選択します。

  5. [バックアップの構成] セクションで、次の手順を使用します。

    1. AKS 拡張機能のインストールに関する手順 1 から 5 をスキップします。 プライマリ リージョンの AKS クラスターに関する手順 6 から開始します。

    2. 手順 7 では、[コンテナー] で、同じリソース グループに作成したバックアップ コンテナー (例: aks-backup-vault-eastus-mjg032524) を選択します。 アクセス許可エラーが発生した場合は、[アクセス許可の付与] を選択して先に進みます。 アクセス許可のデプロイが完了した後もエラーが表示される場合は、[再検証] を選択してロールの割り当てを更新します。

      アクセス許可エラーと [アクセス許可の付与] リンクが強調表示されている [バックアップの構成] の [基本] ペインを示す Azure Portal のスクリーンショット。

    3. 手順 10 で、[バックアップするリソースの選択] を見つけます。 [バックアップ インスタンス名] に、一意の名前 (例: akseastusmjg032524) を入力します。 [その他のオプション] で、すべてのオプションを選択します。 [シークレットを含める] が選択されていることを確認します。

      [シークレットを含める] オプションが強調表示されている [バックアップするリソースの選択] ペインを示す Azure Portal のスクリーンショット。

    4. 手順 11 では、ロールの割り当てエラーが発生します。 手順 12 から 14 に従って、エラーを軽減します。

      [不足しているアクセス許可の付与] ダイアログ ボックスが開いた状態の [バックアップの構成] ペインが表示されている Azure Portal のスクリーンショット。

    5. 手順 15 で [バックアップの構成] を選択したら、[バックアップ] ページに戻ります。 しばらく待ってから、[最新の情報に更新] を選択します。 バックアップ インスタンスが一覧表示され、その [保護の状態] が [保護が構成済み] になるまで、操作を繰り返します。

      AKS バックアップ インスタンスの保護が構成された状態であることを示す Azure Portal のスクリーンショット。

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

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

次の手順を使用して、Vault-Standard バックアップが使用可能であることを確認します。

  1. プライマリ AKS クラスターの [バックアップ] ページで、バックアップ インスタンスを選択します。

  2. しばらく待ってから、[最新の情報に更新] を選択します。 [復元ポイント] セクションに少なくとも 1 つの [運用および Vault-Standard] の復元ポイントが表示されるまで、操作を繰り返します。

    [運用および Vault-Standard] の復元ポイントが強調表示されている [復元ポイント] セクションを示す Azure Portal のスクリーンショット。

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

プライマリ AKS クラスターの Vault-standard バックアップを待っている間に、後で復元できるようにセカンダリ AKS クラスターを設定します。

次の相違点を除いて、「プライマリ WebSphere Liberty/Open Liberty クラスターをデプロイする」セクションと同じ手順を使用して、セカンダリ リージョンにセカンダリ AKS クラスターを設定します。

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

    1. [リソース グループ] フィールドで [新規作成] を選択し、リソース グループの異なる一意の値 (例: liberty-aks-westus-mjg032524) を入力します。
    2. [インスタンス詳細] の[リージョン] で、[米国西部] を選択します。

  2. [AKS] ペインで、次の手順に従います。

    1. Azure Container Registry (ACR) の [ACR インスタンスの選択] で [いいえ] を選択します。

    2. geo レプリケーションを有効にしたプライマリ リージョンの既存の ACR インスタンスを選択します。

      Azure Portal で、ACR インスタンスが強調表示されている [Azure Kubernetes Service での IBM WebSphere Liberty と Open Liberty の作成] ページのスクリーンショット。

次の相違点を除いて、「クラスターのデプロイを確認する」セクションと同じ手順を使用して、セカンダリ リージョンでのデプロイを確認します。

  1. TLS シークレットの名前をコピーして保存する必要はありません。 TLS シークレットは、プライマリ AKS クラスターのバックアップから復元されます。
  2. セカンダリ リージョンにデプロイされている Azure Application Gateway のパブリック IP アドレスの名前と DNS 名を調べるときは、セカンダリ クラスターのリソース グループを使用します (例: liberty-aks-westus-mjg032524)。

次の相違点を除いて、「ストレージ アカウントを作成する」セクションと同じ手順を使用して、セカンダリ リージョンにストレージ アカウント作成します。

  1. [リソース グループ] フィールドで、たとえば liberty-aks-westus-mjg032524 など、セカンダリ クラスターでデプロイされている既存のリソース グループを選択します。
  2. [ストレージ アカウント名] に一意の名前を入力します (例: storagewestusmjg032524)。
  3. [リージョン] では [米国西部] を選択します。

次の相違点を除き、「AKS Backup 拡張機能を有効にする」セクションと同じ手順を使用して、セカンダリ リージョンにクラスターの AKS Backup 拡張機能をインストールします。

  1. セカンダリ クラスターの CSI ドライバーとスナップショットを有効にする手順 1 では、Bash 変数 RG_NAME の値をセカンダリ リージョンのリソース グループに更新します (例: liberty-aks-westus-mjg032524)。
  2. 手順 2 で、セカンダリ リージョンのリソース グループから AKS クラスターを選択します (例: liberty-aks-westus-mjg032524)。
  3. セカンダリ クラスターの AKS Backup 拡張機能をインストールする手順 4 では、セカンダリ リージョンの同じリソース グループに作成したストレージ アカウント (例: storagewestusmjg032524) を選択します。

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

Azure Traffic Manager の設定

Vault-standard バックアップについては、「Vault-standard バックアップが行われるのを待つ」セクションで触れました。 Vault-standard バックアップが使用可能であることを確認したら、グローバル Azure リージョン全体にわたって公開されているアプリケーションにトラフィックを分散するための、Azure Traffic Manager を作成することができます。 プライマリ エンドポイントは、プライマリ リージョンの Azure Application Gateway のパブリック IP アドレスを指します。 セカンダリ エンドポイントは、セカンダリ リージョンの Azure Application Gateway のパブリック IP アドレスを指します。

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

  1. 「Traffic Manager プロファイルの作成」セクションまで進んだら、手順 2 の「Traffic Manager プロファイルを作成する」で、次の手順を使用します。

    1. [名前] に、一意の Traffic Manager プロファイル名を入力します (例: tmprofile-mjg032524)。
    2. [ルーティング方法] で、[優先度] を選択します。
    3. [リソース グループ] に、新しいリソース グループ名を入力して保存しておきます (例: myResourceGroupTM1)。

  2. 「Traffic Manager エンドポイントを追加」セクションまできたら、次の手順を実行します。

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

次に、以下の手順を実行して、プライマリ クラスターにデプロイされたサンプル アプリが Traffic Manager プロファイルからアクセス可能であることを確認します。

  1. 作成した Traffic Manager プロファイルの [概要] を選択します。

  2. Traffic Manager プロファイルの DNS 名を確認してコピーしておき、プロトコル http を https に置き換えます。 たとえば、https://tmprofile-mjg032524.trafficmanager.net のようにします。

  3. 新しいブラウザー タブで URL を開きます。前に作成したコーヒーがページに一覧表示されます。

  4. 異なる名前と価格が設定された別のコーヒーを作成します (価格 20 のコーヒー 2 など)。これは、アプリケーション データ テーブルとデータベースのセッション テーブルの両方で保持されます。 以下のスクリーンショットのような UI が表示されます。

    2 番目のコーヒーを含むサンプル アプリケーション UI のスクリーンショット。

UI がスクリーンショットのような UI でない場合、ぞっこする前にトラブルシューティングを行って問題を解決します。 コンソールを開いたままにしておきます。これは後でフェールオーバー テストに使用します。

これで Traffic Manager プロファイルのセットアップが完了しました。 このページを開いたままにしておき、後でフェールオーバー イベントでエンドポイントの状態の変化を監視するために使用します。

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

このセクションでは、フェールオーバーをテストするために、Azure SQL Database サーバーを手動でフェールオーバーし、AKS クラスターのバックアップを復元してから、Azure Portal を使用してフェールバックします。

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

プライマリ リージョンの停止をシミュレートするには、「Azure Kubernetes Service (AKS) クラスターの停止と開始」の手順に従って、プライマリ AKS クラスターを停止します。

次に、プライマリ クラスターのバックアップから復元できるように、セカンダリ AKS クラスターを起動します。

Note

復元のターゲット クラスター上で WebSphere Liberty/Open Liberty アプリケーションが実行されている場合は、競合を回避するために、次の手順に従って WebSphere Liberty/Open Liberty アプリケーションをクリーンアップします。

  • 前に保存した cmdToConnectToCluster のコマンドを実行して、ターゲット クラスターに接続します。

  • Open Liberty アプリケーションの場合は、次のコマンドを実行します。

    kubectl delete OpenLibertyApplication --all --all-namespaces

  • WebSphere Liberty アプリケーションの場合は、次のコマンドを実行します。

    kubectl delete WebSphereLibertyApplication --all --all-namespaces

次に、Traffic Manager プロファイルのブラウザー タブに切り替え、myPrimaryEndpoint と myFailoverEndpoint の両方のエンドポイントの [監視状態] が [低下] になっていることを確認します。

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

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

次に、以下の手順を使用して、プライマリ AKS クラスターのバックアップをセカンダリ AKS クラスターに復元します。

  1. Azure Portal で、検索ボックスに「バックアップ センター」と入力し、検索結果から [バックアップ センター] を選択します。

  2. [管理] で、[バックアップ インスタンス] を選択します。 データソースの種類 [Kubernetes サービス] でフィルター処理します。 前のセクションで作成したバックアップ インスタンスを見つけます (例: <aks-cluster-name>\akseastusmjg032524)。

  3. バックアップ インスタンスを選択します。

  4. [復元] を選択します。

  5. [復元] ページの既定のウィンドウは [復元ポイント] です。 [前へ] を選択して、[基本] ウィンドウに変更します。 [復元リージョン] で [セカンダリ リージョン] を選択し、[次へ: 復元ポイント] を選択します。

    [復元] の [基本] ウィンドウを示す Azure portal のスクリーンショット。

  6. [復元ポイント] ペインで、最新の [操作および Vault-standard] 復元ポイントが選択されています。 既定値をそのまま使用し、[次へ: 復元パラメーター] を選択します。

    [復元] の [復元ポイント] ウィンドウを示す Azure portal のスクリーンショット。

  7. [パラメーターの復元] ウィンドウで、次の手順を使用します。

    1. [ターゲット クラスターの選択] で、米国西部リージョンで作成したセカンダリ AKS クラスターを選択します。 次のスクリーンショットに示されているように、アクセス許可の問題が発生します。 [アクセス許可の付与] を選択してエラーを軽減します。

    2. [バックアップのステージング場所] で、米国西部リージョンで作成したストレージ アカウントを選択します。 次のスクリーンショットに示されているように、アクセス許可の問題が発生します。 [不足しているロールの割り当て] を選択して、エラーを軽減します。

      [復元パラメーター] ペインを示す Azure Portal のスクリーンショット。

    3. ロールの割り当てが完了した後もエラーが発生する場合は、[再検証] を選択してアクセス許可を最新の情報に更新します。

    4. 不足しているアクセス許可を付与するときに、[スコープ] の指定を求められた場合は、既定値をそのまま使用します。

    5. [検証] を選択します。 Validation completed successfully というメッセージが表示されます。 表示されない場合は、トラブルシューティングで問題を解決してから続行してください。

  8. Next:[次へ: レビューと復元] を選択します。 次に、 [復元] を選択します。 クラスターの複製には約 10 分かかります。

  9. 次のスクリーンショットに示すように、[バックアップ センター]>[監視とレポート]>[バックアップ ジョブ] から復元プロセスを監視できます。

    進行中の CrossRegionRestore を示す Azure portal のスクリーンショット。

  10. しばらく待ってから、[最新の情報に更新] を選択します。 [状態] が [完了] になるまで、操作を繰り返します。

次に、以下の手順を実行して、復元が想定どおりに動作することを確認します。

  1. セカンダリ AKS クラスターに接続したターミナルに切り替えます。

  2. 次のコマンドを実行して、バックアップから復元されたサンプル アプリを取得します。

    kubectl get OpenLibertyApplication

    出力に READY アプリケーションが 1 つ表示されます。

    NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    3m

  3. 次のコマンドを実行して、デプロイ中に作成されたポッドの状態を取得します。

    kubectl get pods

    出力には、[実行中] のポッドが 3 つ表示されます。

    NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-7bb57dd945-6ljll   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-h2xdf   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-k744w   1/1     Running   0          3m

  4. Traffic Manager プロファイルのブラウザ タブに切り替え、エンドポイント myFailoverEndpoint の [モニター状態] が [オンライン] に、エンドポイント myPrimaryEndpoint の [モニター状態] が [低下] になるまでページを更新します。

  5. たとえば https://tmprofile-mjg032524.trafficmanager.net など、Traffic Manager プロファイルの DNS 名でブラウザー タブに切り替えます。 ページを更新すると、アプリケーション データ テーブルとセッション テーブルに同じデータが保持されます。 以下のスクリーンショットのような UI が表示されます。

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

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

    Note

    アプリは、セッション タイムアウトを 1 時間として構成します。 フェールオーバーにかかった時間によっては、1 時間以上前に期限切れになった場合、サンプル アプリ UI の [新しいコーヒー] セクションにセッション データが表示されない場合があります。

フェールオーバー サイトを再保護する

セカンダリ リージョンがフェールオーバー サイトであり、アクティブになったので、Azure Backup で再保護する必要があります。

最初に、次の相違点を除き、「AKS クラスターのバックアップ」セクションと同じ手順を使用して、セカンダリ AKS クラスターをバックアップします。

  1. [バックアップ コンテナーの作成] で、次の手順を使用します。
    1. [リソース グループ] で、セカンダリ リージョンでデプロイされた既存のリソース グループを選択します (例: liberty-aks-westus-mjg032524)。
    2. [バックアップ コンテナー名] に、一意の値 (例: aks-backup-vault-westus-mjg032524) を入力します。
    3. [リージョン] では [米国西部] を選択します。
  2. [バックアップ ポリシーの作成] で、次の手順を使用します。
    1. セカンダリ リージョンで作成したバックアップ コンテナーを選択します (例: aks-backup-vault-westus-mjg032524)。
  3. [バックアップの構成] で、次の手順を実行します。
    1. セカンダリ リージョンで作成したバックアップ コンテナーを選択します (例: aks-backup-vault-westus-mjg032524)。
    2. [バックアップ インスタンス名] に、一意の名前 (例: akswestusmjg032524) を入力します。

次に、セカンダリ AKS クラスターの [バックアップ] ページからバックアップ インスタンスを選択する手順を除き、「Vault-Standard バックアップが行われるのを待つ」セクションと同じ手順を使用して、セカンダリ AKS クラスターの Vault-standard バックアップが使用可能になるまで待ちます。

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

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

  1. フェールバックの準備をする場合は、次の手順を使用します。

    1. セカンダリ AKS クラスターを停止して、セカンダリ リージョンの停止をシミュレートします。
    2. プライマリ AKS クラスターを起動します。
    3. プライマリ AKS クラスターに接続し、WebSphere Liberty/Open Liberty アプリケーションをクリーンアップします。

  2. セカンダリ AKS クラスターのバックアップをプライマリ AKS クラスターに復元する場合は、以下の手順を使用します。

    1. セカンダリ リージョンのバックアップ インスタンスを選択します (例: <aks-cluster-name>\akswestusmjg032524)。
    2. [復元パラメーター] ペインで、次の手順を使用します。
      1. [ターゲット クラスターの選択] で、米国東部リージョンで作成したプライマリ AKS クラスターを選択します。
      2. [バックアップのステージング場所] で、米国東部リージョンで作成したストレージ アカウントを選択します。

  3. 復元が想定どおりに動作することを確認する場合は、以下の手順を実行します。

    1. プライマリ AKS クラスターに接続したターミナルに切り替え、アプリが正常に復元されたことをチェックします。
    2. Traffic Manager プロファイルのブラウザ タブに切り替え、エンドポイント myPrimaryEndpoint の [モニター状態] が [オンライン] に、エンドポイント myFailoverEndpoint の [モニター状態] が [低下] になるまでページを更新します。

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

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

  1. Azure Portal で、検索ボックスに SQL Database サーバーのリソース グループ名 (例: myResourceGroup) を入力し、検索結果から一致するリソース グループを選択します。
  2. [リソース グループの削除] を選択します。
  3. [削除するリソース グループ名を入力する] で、リソース グループ名を入力します。
  4. [削除] を選択します。
  5. Traffic Manager のリソース グループに対して、手順 1 ～ 4 を繰り返します (例: myResourceGroupTM1)。
  6. Azure Portal で、検索ボックスに「バックアップ コンテナー」と入力し、検索結果から [バックアップ コンテナー] を選択します。 2 つのバックアップ コンテナーが一覧表示されます (例: aks-backup-vault-eastus-mjg032524 と aks-backup-vault-westus-mjg032524)。 各バックアップ コンテナーで、次の手順を実行します。
    1. 選択してバックアップ コンテナーを開きます。
    2. [管理]>[プロパティ]>[論理的な削除]>[更新] を選択します。 [論理的な削除を有効にする] の横にあるチェックボックスをオフにして、[更新] を選択します。
    3. [管理]>[バックアップ インスタンス] を選択します。 データソースの種類 [Kubernetes サービス] でフィルター処理します。 作成したインスタンスを選択して削除します。
  7. 2 つのバックアップ インスタンスが削除されるまで待ちます。
  8. プライマリ クラスターのリソース グループ (例: liberty-aks-eastus-mjg032524) に対して、手順 1 ～ 4 を繰り返します。
  9. セカンダリ クラスターのリソース グループ (例: liberty-aks-westus-mjg032524) に対して、手順 1 ～ 4 を繰り返します。

次のステップ

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

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

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

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

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

Azure 上の WebSphere の詳細情報