チュートリアル: 高可用性と障害復旧を使用して WebSphere Application Server を Azure Virtual Machines に移行する

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

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

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

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

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

Azure Traffic Manager は、リージョンの正常性をチェックし、それに応じてアプリケーション層にトラフィックをルーティングします。プライマリリージョンには、WebSphere クラスターが完全にデプロイされています。プライマリリージョンが Azure Site Recovery によって保護されたら、フェールオーバー中にセカンダリリージョンを復元できます。その結果、プライマリリージョンはユーザーからのネットワーク要求に積極的にサービスを提供しますが、セカンダリリージョンはパッシブであり、プライマリリージョンでサービスの中断が発生した場合にのみトラフィックを受信するようにアクティブ化されます。

Azure Traffic Manager は、IBM HTTP Server にデプロイされたアプリの正常性を検出して、条件付きルート指定を実装します。アプリケーション層の geo フェールオーバー RTO は、プライマリクラスターのシャットダウン、セカンダリクラスターの復元、VMの起動、セカンダリ WebSphere クラスターの実行にかかる時間によって異なります。 RPO は、Azure Site Recovery と Azure SQL Database の復元ポリシーに依存します。この依存関係は、クラスターデータが VM のローカルストレージに格納およびレプリケートされ、アプリケーションデータが Azure SQL Database フェールオーバーグループに永続化およびレプリケートされるためです。

上の図は、HA/DR アーキテクチャを構成する 2 つのリージョンとしてプライマリリージョンとセカンダリリージョンを示しています。これらのリージョンは、Azure のペアになっているリージョンである必要があります。ペアになっているリージョンの詳細については、「Azure のクロスリージョンレプリケーション」を参照してください。この記事では、米国東部と米国西部を 2 つのリージョンとして使用しますが、シナリオに適した任意のペアリージョンにすることができます。リージョンのペアリングの一覧については、「Azure クロスリージョンレプリケーション」の「Azure のペアになっているリージョン」セクションを参照してください。

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

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

前提条件

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

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

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

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

「単一データベースの作成」のセクションまでいったら、次の手順を実行します。
1. 新しいリソースグループを作成する手順 4 で、リソースグループ名 (例: myResourceGroup) を保存しておきます。
2. データベース名の手順 5 で、データベース名 (例: mySampleDatabase) の値を保存しておきます。
3. サーバーを作成する手順 6 では、次の手順を実行します。
  1. たとえば、sqlserverprimary-mjg022624 など一意のサーバー名を入力します。
  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 でサンプルクエリを実行したら、エディターをクリアし、次のクエリを入力し、[実行] を再度選択します。
```
CREATE TABLE sessions (
   ID VARCHAR(128) NOT NULL,
   PROPID VARCHAR(128) NOT NULL,
   APPNAME VARCHAR(128) NOT NULL,
   LISTENERCNT SMALLINT,
   LASTACCESS BIGINT,
   CREATIONTIME BIGINT,
   MAXINACTIVETIME INT,
   USERNAME VARCHAR(256),
   SMALL VARBINARY(MAX),
   MEDIUM VARCHAR(MAX),
   LARGE VARBINARY(MAX)
);
```
  正常に実行されると、"クエリが成功しました: 影響を受ける行: 0" というメッセージが表示されます。
  
  データベーステーブル sessions は、WebSphere アプリのセッションデータを格納するために使用されます。トランザクションログを含む WebSphere クラスターデータは、クラスターがデプロイされている VM のローカルストレージに保持されます。

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

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

Azure VM でプライマリ WebSphere クラスターを設定します。

このセクションでは、Azure VM 上の IBM WebSphere Application Server クラスターオファーを使用して、Azure VM上にプライマリ WebSphere クラスターを作成します。セカンダリクラスターは、後で Azure Site Recovery を使用してフェールオーバー中にプライマリクラスターから復元されます。

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

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

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

[サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
このオファーを空のリソースグループにデプロイする必要があります。 [リソースグループ] フィールドで [新規作成] を選択し、リソースグループの固有値 (was-cluster-eastus-mjg022624 など) を入力します。
[インスタンス詳細] の[リージョン] で、[米国東部] を選択します。
このチュートリアルでは、[既存の WebSphere エンタイトルメントまたは評価ライセンスを使用してデプロイする?] に対して、[評価] を選択します。 [エンタイトルメント] を選択して、IBMid 資格情報を指定することもできます。
[IBM 使用許諾契約書を読んで同意します] を選択します。
他のフィールドはデフォルトのままにします。
[次へ] を選択して、[クラスター構成] ペインに移動します。

以下の手順を実行して、[クラスター構成] ペインを入力します。

[VM 管理者用パスワード] に、パスワードを入力します。
[WebSphere 管理者用パスワード] に、パスワードを入力します。 [WebSphere 管理者] のユーザー名とパスワードを保存しておきます。
他のフィールドはデフォルトのままにします。
[次へ] を選択して、[Load Balancer] ペインに移動します。

次の手順を実行して、[Load Balancer] ペインを入力します。

[VM 管理者用パスワード] に、パスワードを入力します。
IBM HTTP サーバー管理者用パスワードの場合は、パスワードを指定します。
他のフィールドはデフォルトのままにします。
[次へ] を選択して、[ネットワーク] ペインに移動します。

[ネットワーク] ペインでは、すべてのフィールドに既定値が事前に設定されていることがわかります。 [次へ] を選択して、[データベース] ウィンドウに移動します。

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

[データベースに接続しますか?] で [はい] を選択します。
[データベースの種類の選択] で [Microsoft SQL Server ] を選択します。
[JNDI 名] には、jdbc/WebSphereCafeDB と入力します。
データソース接続文字列の場合 (jdbc:sqlserver://<host>:<port>;database=<database>))、プレースホルダーを、たとえば、jdbc:sqlserver://failovergroup-mjg022624.database.windows.net:1433;database=mySampleDatabase のような Azure SQL Database のフェールオーバーグループの前のセクションで保存しておいた値に置き換えます。
[データベースユーザー名] に、たとえば、azureuser@failovergroup-mjg022624 のような前のセクションで保存しておいたサーバー管理者のサインイン名とフェールオーバーグループ名を入力します。

Note

プライマリデータベースまたはバックアップデータベースのサーバーホスト名とユーザー名ではなく、フェールオーバーグループに正確なデータベースサーバーのホスト名とデータベースユーザー名を使用するように注意してください。実際には、フェールオーバーグループの値を使用して、フェールオーバーグループと通信するように WebSphere に指示します。ただし、WebSphere が接続されている限りこれは、通常のデータベース接続です。
[データベースパスワード] で前に保存しておいたサーバー管理者のサインインパスワードを入力します。 [パスワードを確認] と同じ値を入力します。
他のフィールドはデフォルトのままにします。
[Review + create](レビュー + 作成) を選択します。
[最後の検証を実行中...] が正常に完了するまで待機し、[作成] を選択します。

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

Note

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

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

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

クラスターに IBM HTTP サーバー (IHS) と WebSphere Deployment Manager (Dmgr) をデプロイしました。 IHS は、クラスターのすべてのアプリケーションサーバーに対してロードバランサーとして機能します。 Dmgr には、クラスター構成用の Web コンソールが用意されています。

次の手順に進む前に、次の手順を実行して、IHS コンソールと Dmgr コンソールが機能するかどうかを確認します。

[デプロイ] ページに戻り、[出力] を選択します。
プロパティ ihsConsole の値をコピーします。その URL を新しいブラウザータブで開きます。この例では IHS には https を使用しません。エラーメッセージなしで IHS のウェルカムページが表示されます。表示されない場合、問題のトラブルシューティングと解決を行う必要があります。コンソールを開いたままにして、後でクラスターのアプリのデプロイを確認するために使用します。
プロパティ adminSecuredConsole の値をコピーして保存しておきます。それを新しいブラウザータブで開きます。自己署名 TLS 認定資格証に対するブラウザーの警告を受け入れます。自己署名 TLS 認定資格証を使用して運用環境に移行しないでください。

WebSphere Integrated Solutions Console のサインインページが表示されます。前に保存しておいた WebSphere 管理者のユーザー名とパスワードを使用して、コンソールにサインインします。ログインできない場合は、続行する前に問題のトラブルシューティングと解決を行う必要があります。コンソールを開いたままにして、後で WebSphere クラスターをさらに構成するために使用します。

次の手順を使用して、IHS のパブリック IP アドレスの名前を取得します。これは、後で Azure Traffic Manager を設定するときに使用します。

クラスターがデプロイされているリソースグループを開きます。たとえば、[概要] を選択して、デプロイページの [概要] ペインに戻り、[リソースグループにアクセス] を選択します。
リソーステーブルで、[種類] 列を見つけます。リソースの種類で並べ替えるには、その列を選択します。
プレフィックス ihs が付いているパブリック IP アドレス リソースを見つけて、その名前をコピーして保存しておきます。

クラスターを構成する

まず、次の手順を実行して、[変更をノードと同期する] オプションを有効にして、任意の構成をすべてのアプリケーションサーバーに自動同期できるようにします。

WebSphere Integrated Solutions Console に戻り、サインアウトした場合はもう一度サインインします。
ナビゲーションウィンドウで、[システム管理]>[コンソール環境設定] の順に選択します。
[コンソール環境設定] ペインで、[変更をノードと同期する] を選択し、[適用] を選択します。 [環境設定が変更されました] というメッセージが表示されます。

次に、次の手順を実行して、すべてのアプリケーションサーバーのデータベース 分散セッション を構成します。

ナビゲーションペインで、[サーバー]>[サーバーの種類]>[WebSphere アプリケーションサーバー] の順に選択します。
[アプリケーションサーバー] ペインに、3 つのアプリケーションサーバーが表示されます。アプリケーションサーバーごとに次の手順を実行して、データベース分散セッションを構成します。
1. 次のリソースを管理できるテキストの下の表で、MyCluster から始まるアプリケーションサーバーのハイパーリンクを選択します。
2. [コンテナー設定] セクションで、[セッション管理] を選択します。
3. [追加のプロパティ] セクションで、[分散環境設定] を選択します。
4. [分散セッション] で、[データベース] を選択します (Web コンテナーでのみサポートされます)。
5. [データベース] を選択し、次の手順を実行します。
  1. [データソース JNDI 名] に、jdbc/WebSphereCafeDB と入力します。
  2. [ユーザー ID] に、たとえば azureuser@failovergroup-mjg022624 のような前のセクションで保存しておいたサーバー管理者のサインイン名とフェールオーバーグループ名を入力します。
  3. [パスワード] で前に保存しておいた Azure SQL Server 管理者のサインインパスワードを入力します。
  4. [テーブルスペース名] に sessions と入力します。
  5. [複数行スキーマを使用] を選択します。
  6. [OK] を選択します。 [分散環境設定] ペインに戻ります。
6. [追加のプロパティ] セクションで、[カスタムチューニングパラメーター] を選択します。
7. [チューニングレベル] で、[低 (フェールオーバー用に最適化)] を選択します。
8. [OK] を選択します。
9. [メッセージ] で [保存] を選択します。完了するまで待ちます。
10. 上部のパンくずリストで [アプリケーションサーバー] を選択します。 [アプリケーションサーバー] ペインに戻ります。
ナビゲーションペインで、[サーバー]>[クラスター]>[WebSphere Application Server クラスター] の順に選択します。
[WebSphere アプリケーションサーバークラスター] ペインに、クラスターMyClusterが一覧されます。 [MyCluster] の横にあるチェックボックスをオンにします。
[Ripplestart] を選択します。
クラスターが再起動されるまで待ちます。 [状態] アイコンを選択します。新しいウィンドウに [開始] と表示されない場合は、コンソールに戻り、しばらくしてから Web ページを更新します。 [開始] が表示されるまで操作を繰り返します。 [開始] 状態に達する前に、[一部開始]と表示される場合があります

コンソールを開いたままにして、後でアプリをデプロイするために使用します。

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

このセクションでは、後で障害復旧フェールオーバーテストを行うために、サンプルの CRUD Java/Jakarta Enterprise Edition アプリケーションを WebSphere クラスターにデプロイして実行する方法について説明します。

以前にセッションデータを格納するためにデータソース jdbc/WebSphereCafeDB を使用するようにアプリケーションサーバーを構成しました。これにより、WebSphere アプリケーションサーバーのクラスター全体でフェールオーバーと負荷分散が可能になります。サンプルアプリも、同じデータソース jdbc/WebSphereCafeDB にアプリケーションデータ coffee を保存するための永続化スキーマを構成します。

まず、次のコマンドを使用して、サンプルをダウンロード、ビルド、パッケージ化します。

git clone https://github.com/Azure-Samples/websphere-cafe
cd websphere-cafe
git checkout 20240326
mvn clean package

Detached HEAD 状態であることを示すメッセージが表示された場合、このメッセージは無視しても問題ありません。

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

その後、次の手順を実行して、サンプルアプリをクラスターにデプロイします。

WebSphere Integrated Solutions Console に戻り、サインアウトした場合はもう一度サインインします。
[ナビゲーション] ペインで、[アプリケーション]>[アプリケーションの種類]>[WebSphere エンタープライズアプリケーション] の順に選択します。
[エンタープライズアプリケーション] ペインで、[インストール]>[ファイルを選択] の順に選択します。次に、<parent-path-to-your-local-clone>/websphere-cafe/websphere-cafe-application/target/websphere-cafe.ear にあるパッケージを見つけて、[開く] を選択します。 [次へ]>[次へ]>[次へ] を選択します。
[モジュールをサーバーにマップする] ペインで、Ctrl キーを押し、[クラスターとサーバー] の下に一覧されているすべての項目を選択します。 websphere-cafe.war の横にあるチェックボックスを選択します。適用を選択します。 [完了] ボタンが表示されるまで [次へ] を選択します。
[完了]>[保存] の順に選択し、完了するまで待機します。 [OK] を選択します。
インストールされているアプリケーション websphere-cafe を選択し、[開始] を選択します。アプリケーションが正常に起動されたことを示すメッセージが表示されるまで待ちます。成功メッセージが表示さない場合は、続行する前に問題のトラブルシューティングをして問題を解決する必要があります。

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

IHS コンソールに戻ります。アドレスバーにデプロイされたアプリのコンテキストルート /websphere-cafe/ を追加し (例、http://ihs70685e.eastus.cloudapp.azure.com/websphere-cafe/)、Enter キーを押下します。サンプルアプリのウェルカムページが表示されます。
名前と価格が設定された新しいコーヒーを作成します (例: 価格が $10 のコーヒー 1)。これは、アプリケーションデータテーブルとデータベースのセッションテーブルの両方で保持されます。以下のスクリーンショットのような UI が表示されます。

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

Azure Site Recovery を使用してクラスター用の障害復旧を設定します。

このセクションでは、「チュートリアル: Azure VM の障害復旧を設定する」の手順を実行して、Azure Site Recovery を使用してプライマリクラスター内の Azure VM の障害復旧を設定します。「Recovery Services コンテナーを作成」および「レプリケーションを有効化」のセクションのみが必要です。読み進めるにあたって次の手順に注意し、プライマリクラスターを保護してからこの記事に戻ってください。

「Recovery Services コンテナーを作成」のセクションで、次の手順を実行します。
1. リソースグループの手順 5 で、たとえば、was-cluster-westus-mjg022624 など、サブスクリプション内に一意の名前を持つ新しいリソースグループを作成します。
2. コンテナー名の手順 6 で、たとえば recovery-service-vault-westus-mjg022624 のようなコンテナー名を指定します。
3. 手順 7 のリージョンで、[米国西部]を選択します。
4. 手順 8 で [確認と作成] を選択する前に、[次へ: 冗長性] を選択します。 [冗長性] ペインの [バックアップストレージの冗長性] に対して [geo 冗長] を、[リージョン間の復元を有効にする] に対して [有効化] を選択します。
  
  Note
  
  [冗長性] ペインで、[バックアップストレージの冗長性] に対して [geo 冗長] を、[リージョン間の復元を有効にする] に対して [有効化] を選択したことを確認します。このように選択しないと、プライマリクラスターのストレージをセカンダリリージョンにレプリケートできません。
5. [Site Recovery を有効化] セクションで、次の手順を実行して、[Site Recovery] を有効にします。
「レプリケーションを有効化」セクションにアクセスしたら、次の手順を実行します。
1. [ソース設定の選択] セクションで、次の手順を実行します。
  1. [リージョン] で、 [米国東部] を選択します。
  2. [リソースグループ] で、たとえば was-cluster-eastus-mjg022624 など、プライマリクラスターでデプロイされているリソースを選択します。
    
    Note
    
    目的のリソースグループが一覧にない場合は、最初にリージョンとして米国西部を選択してから、米国東部に切り替えることができます。
  3. 他のフィールドはデフォルトのままにします。 [次へ] を選択します。
2. [VM の選択] セクションの [仮想マシン] で、一覧表示されている 5 つの VM をすべて選択し、[次へ] を選択します。
3. [レプリケーション設定の確認] セクションで、次の手順を実行します。
  1. [対象の場所] で [米国西部] を選択します。
  2. [対象リソースグループ] で、たとえば、was-cluster-westus-mjg022624 など、サービス復旧コンテナーがデプロイされているリソースグループを選択します。
  3. 新しいフェールオーバー仮想ネットワークとフェールオーバーサブネットを書き留めておきます。これは、プライマリリージョンの仮想ネットワークからマップされます。
  4. 他のフィールドはデフォルトのままにします。
  5. [次へ] を選択します。
4. [管理] セクションで、次の手順を実行します。
  1. レプリケーションポリシーの場合は、既定のポリシーである 24 時間保持ポリシーを使用します。ビジネス用に新しいポリシーを作成することもできます。
  2. 他のフィールドはデフォルトのままにします。
  3. [次へ] を選択します。
5. [レビュー] セクションで、次の手順を実行します。
  1. [レプリケーションを有効化] を選択した後、「Azure リソースの作成中。このブレードを閉じないでください。」というメッセージがページ下部に表示されます。何も操作せず、ウィンドウが自動的に閉じられるまで待機します。 [Site Recovery] ページにリダイレクトされます。
  2. [保護されているアイテム] の下で、[レプリケートされたアイテム] を選択します。レプリケーションがまだ進行中であるため、最初は項目が一覧されません。レプリケーションの完了には約 1 時間かかります。次のスクリーンショットの例に示すように、すべての VM が [保護済み] 状態になるまで、ページを定期的に更新します。

次に、レプリケートされたすべての項目を含める復旧計画を作成して、一緒にフェールオーバーできるようにします。次のカスタマイズを行い、「復旧計画の作成」の手順を実行します。

手順 2 で、たとえば recovery-plan-mjg022624 など、プランの名前を入力します。
手順 3 で、[ソース] に [米国東部] を、[ターゲット] に [米国西部] を選択します。
手順 4 の項目の選択で、このチュートリアルで保護した 5 つの VM をすべて選択します。

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

セカンダリリージョンのその他のネットワーク構成

また、フェールオーバーイベントでセカンダリリージョンへの外部アクセスを有効にして保護するために、さらにネットワーク構成が必要になります。この構成では、次の手順を実行します。

「クイックスタート: Azure Portal を使用してパブリック IP アドレスを作成する」の手順に従って、セカンダリリージョンに Dmgr のパブリック IP アドレスを次の通りカスタマイズして作成します。
1. [リソースグループ] で、たとえば、was-cluster-westus-mjg022624 など、サービス復旧コンテナーがデプロイされているリソースグループを選択します。
2. [リージョン] で、[(米国) 米国西部] を選択します。
3. [名前 ] に、たとえば dmgr-public-ip-westus-mjg022624 などの値を入力します。
4. DNS 名ラベルには、たとえば dmgrmjg022624 などの一意の値を入力します。
次のようにカスタマイズして、同じガイドに従って、セカンダリリージョンに IHS 用の別のパブリック IP アドレスを作成します。
1. [リソースグループ] で、たとえば、was-cluster-westus-mjg022624 など、サービス復旧コンテナーがデプロイされているリソースグループを選択します。
2. [リージョン] で、[(米国) 米国西部] を選択します。
3. [名前 ] に、たとえば ihs-public-ip-westus-mjg022624 などの値を入力します。それを書き出しましょう。
4. DNS 名ラベルには、たとえば ihsmjg022624 などの一意の値を入力します。
次のようにカスタマイズして、「ネットワークセキュリティグループを作成、変更または削除」の「ネットワークセキュリティグループを作成」セクションの手順を実行してセカンダリリージョンでネットワークセキュリティグループを作成します。
1. [リソースグループ] で、たとえば、was-cluster-westus-mjg022624 など、サービス復旧コンテナーがデプロイされているリソースグループを選択します。
2. [名前 ] に、たとえば nsg-westus-mjg022624 などの値を入力します。
3. [リージョン] では [米国西部] を選択します。
同じ記事の「セキュリティ規則の作成」セクションの手順を実行して、次のカスタマイズを行って、ネットワークセキュリティグループの受信セキュリティ規則を作成します。
1. 手順 2 で、たとえば nsg-westus-mjg022624 など、作成したネットワークセキュリティグループを選択します
2. 手順 3 で、[受信セキュリティ規則]を選択します。
3. 手順 4 で、次の設定をカスタマイズします。
  1. [宛先ポート範囲] に、9060,9080,9043,9443,80 と入力します。
  2. [プロトコル] で [TCP] を選択します。
  3. [名前] に、ALLOW_HTTP_ACCESS と入力します。
ネットワークセキュリティグループをサブネットに関連付けるには、同じ記事の「ネットワークセキュリティグループの関連付けまたは関連付け解除」セクションの手順を実行して、次のカスタマイズを行います。
1. 手順 2 で、たとえば nsg-westus-mjg022624 など、作成したネットワークセキュリティグループを選択します
2. [関連付け] を選択して、前に説明したフェールオーバーサブネットにネットワークセキュリティグループを関連付けます。

Azure Traffic Manager の設定

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

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

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

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

作成したTraffic Managerプロファイルの [概要] を選択します。
Traffic Manager プロファイルの Domain Name System (DNS) の名前を選択してコピーしたら、/websphere-cafe/ に追加します (例: http://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/)。
新しいブラウザータブで URL を開きます。前に作成したコーヒーがページに一覧表示されます。
異なる名前と価格が設定された別コーヒーを作成します (価格 20 のコーヒー 2 など)。これは、アプリケーションデータテーブルとデータベースのセッションテーブルの両方で保持されます。以下のスクリーンショットのような UI が表示されます。

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

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

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

フェールオーバーをテストするには、Azure SQL Database サーバーとクラスターを手動でフェールオーバーしてから、Azure Portal を使用してフェールバックします。

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

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

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

次に、次の手順を実行して、復旧計画を使用して WebSphere クラスターをフェールオーバーします。

Azure Portal の上部にある検索ボックスに、Recovery Services vaults と入力し、検索結果で、[Recovery Services コンテナー] を選択します。
たとえば recovery-service-vault-westus-mjg022624 など、Recovery Services コンテナーの名前を選択します。
[管理] で、[復旧計画 (サイトの回復)] を選択します。たとえば recovery-plan-mjg022624 など、作成した復旧計画を選択します。
[フェールオーバー] を選択します。 [リスクを理解、テストフェールオーバーをスキップする] を選択します。他のフィールドは既定値のままにし、[OK] を選択します。

Note

必要に応じて、テストフェールオーバーとクリーンアップテストフェールオーバーを実行すると、フェールオーバーをテストする前にすべてが期待どおりに動作することを確認できます。詳細については、「チュートリアル: Azure VM 向け障害復旧ドリルを実行」を参照してください。このチュートリアルでは、フェールオーバーを直接テストして演習を簡略化します。
フェールオーバーが完了するまで、通知のフェールオーバーを監視します。このチュートリアルの演習には約 10 分かかります。
必要に応じて、通知から Failover of 'recovery-plan-mjg022624' is in progress... などのフェールオーバーイベントを選択すると、フェールオーバージョブの詳細を確認できます。

次に、次の手順を実行して、セカンダリリージョンの WebSphere Integrated Solutions Console とサンプルアプリへの外部アクセスを有効にします。

Azure Portal の上部にある検索ボックスに Resource groups と入力し、検索結果で [TMResourceGroup] を選択します。
たとえば was-cluster-westus-mjg022624 など、セカンダリリージョンのリソースグループの名前を選択します。 [リソースグループ] ページの [種類] で項目を並べ替えます。
dmgr のプレフィックスが付いたネットワークインターフェイスを選択します。 [IP 構成]>[ipconfig1] の順に選択します。 [パブリック IP アドレスを関連付ける] を選択します。 [パブリック IP アドレス] に対して、dmgr のプレフィックスが付いたパブリック IP アドレスを選択します。このアドレスは、前に作成したものです。この記事では、アドレスの名前を dmgr-public-ip-westus-mjg022624 と指定します。 [保存] を選択し、完了するまで待ちます。
リソースグループに戻り、ihs のプレフィックスが付いたネットワークインターフェイスを選択します。 [IP 構成]>[ipconfig1] の順に選択します。 [パブリック IP アドレスを関連付ける] を選択します。 [パブリック IP アドレス] に対して、ihs のプレフィックスが付いたパブリック IP アドレスを選択します。このアドレスは、前に作成したものです。この記事では、アドレスの名前を ihs-public-ip-westus-mjg022624 と指定します。 [保存] を選択し、完了するまで待ちます。

次の手順を実行して、フェールオーバーが期待どおりに動作することを確認します。

前に作成した Dmgr のパブリック IP アドレスの DNS 名ラベルを見つけます。新しいブラウザータブで Dmgr WebSphere Integrated Solutions Console の URL を開きます。かならず httpsを使用してください。たとえば、https://dmgrmjg022624.westus.cloudapp.azure.com:9043/ibm/console のようにします。サインインのウェルカムページが表示されるまで、ページを更新します。
前に保存しておいた WebSphere 管理者のユーザー名とパスワードを使用してコンソールにサインインし、次の手順を実行します。
1. ナビゲーションペインで、[サーバー]>[ すべてのサーバー] の順に選択します。 [ミドルウェアサーバー] ペインには、4 つのサーバーが一覧されます。これには、WebSphere クラスター MyCluster で構成されている 3 つの WebSphere アプリケーションサーバーと、IHS である 1 つの Web サーバーが含まれます。すべてのサーバーが起動するまでページを更新します。
2. [ナビゲーション] ペインで、[アプリケーション]>[アプリケーションの種類]>[WebSphere エンタープライズアプリケーション] の順に選択します。 [エンタープライズアプリケーション] ペインに、1 つのアプリケーション websphere-cafe (一覧および開始) が表示されます。
3. セカンダリリージョンのクラスター構成を検証するには、「クラスターを構成」セクションの手順を実行します。次のスクリーンショットに示すように、[ノードと変更を同期する] および [分散セッション] の設定がフェールオーバークラスターにレプリケートされていることがわかります。
前に作成した IHS のパブリック IP アドレスの DNS 名ラベルを見つけます。ルートコンテキスト /websphere-cafe/ が追加された IHS コンソールの URL を開きます。 https は使用しないでください。この例では、たとえば http://ihsmjg022624.westus.cloudapp.azure.com/websphere-cafe/ などの IHS 用 https は使用しません。前に作成した 2 つのコーヒーがページに表示されます。
Traffic Manager プロファイルのブラウザタブに切り替え、エンドポイント myFailoverEndpoint の [モニター状態] の値が [オンライン] に、エンドポイント myPrimaryEndpoint の [モニター状態] が [低下] になるまでページを更新します。
たとえば http://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/ など、Traffic Manager プロファイルの DNS 名でブラウザータブに切り替えます。ページを更新すると、アプリケーションデータテーブルとセッションテーブルに同じデータが保持されます。以下のスクリーンショットのような UI が表示されます。

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

フェールオーバーをコミットします

フェールオーバーの結果に問題が無ければ、次の手順を実行してフェールオーバーをコミットします。

Azure Portal の上部にある検索ボックスに、Recovery Services vaults と入力し、検索結果で、[Recovery Services コンテナー] を選択します。
たとえば recovery-service-vault-westus-mjg022624 など、Recovery Services コンテナーの名前を選択します。
[管理] で、[復旧計画 (サイトの回復)] を選択します。たとえば recovery-plan-mjg022624 など、作成した復旧計画を選択します。
[コミット]>[OK] の順に選択します。
完了するまで、通知内のコミットを監視します。
復旧計画で項目を選択します。 [コミット済みフェールオーバー]として一覧されている 5 つの項目が表示されます。

レプリケーションを無効化

次の手順を実行して、復旧計画内の項目のレプリケーションを無効化してから、復旧計画を削除します。

復旧計画の項目の各項目で、省略記号ボタン (...) を選択し、[レプリケーションを無効化]を選択します。
この仮想マシンの保護を無効にする理由を指定するように求められた場合は、目的の仮想マシンで、たとえば、「アプリケーションの移行が完了しました。」などを選択します。 [OK] を選択します。
すべての項目のレプリケーションを無効にするまで、手順 1 を繰り返します。
完了するまで、通知内のプロセスを監視します。
[概要]>[削除] の順に選択します。 [はい] を選択して削除を確定します。

フェールバックの準備: フェールオーバーサイトを再度保護する

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

まず、次の手順を実行して、未使用のリソースをクリーンし、後で Azure Site Recovery サービスがプライマリリージョンにレプリケートされるようにします。サイトの回復によってリソースが既存のリソースグループに復元されるため、リソースグループを削除することはできません。

Azure Portal の上部にある検索ボックスに Resource groups と入力し、検索結果で [TMResourceGroup] を選択します。
たとえば was-cluster-eastus-mjg022624 など、プライマリリージョンのリソースグループの名前を選択します。 [リソースグループ] ページの [種類] で項目を並べ替えます。
仮想マシンを削除するには、次の手順を実行します。
1. [種類] フィルターを選択し、[値] ドロップダウンリストから [仮想マシン] を選択します。
2. 適用を選択します。
3. すべての仮想マシンを選択し、[削除] を選択したら、delete と入力して削除を確定します。
4. [削除] を選択します。
5. 完了するまで、通知内のプロセスを監視します。
次の手順を実行して、ディスクを削除します。
1. [種類] フィルターを選択し、[値] ドロップダウンリストから [ディスク] を選択します。
2. 適用を選択します。
3. すべてのディスクを選択し、[削除] を選択したら、delete と入力して削除を確定します。
4. [削除] を選択します。
5. 通知内のプロセスを監視し、完了するまで待機します。
次の手順を実行して、エンドポイントを削除します。
1. [種類] フィルターを選択し、[値] ドロップダウンリストで [プライベートエンドポイント] を選択します。
2. 適用を選択します。
3. すべてのプライベートエンドポイントを選択し、[削除] を選択し、delete と入力して削除を確定します。
4. [削除] を選択します。
5. 完了するまで、通知内のプロセスを監視します。 [プライベートエンドポイント ]という種類が一覧にない場合は、この手順を無視します。
次の手順を実行して、ネットワークインターフェイスを削除します。
1. [種類] フィルター > を選択し、[値] ドロップダウンリストから [ネットワークインターフェイス] を選択します。
2. 適用を選択します。
3. すべてのネットワークインターフェイスを選択し、[削除] を選択してから、delete と入力して削除を確定します。
4. [削除] を選択します。完了するまで、通知内のプロセスを監視します。
次の手順を実行して、ストレージアカウントを削除します。
1. [種類] フィルター > を選択し、[値] ドロップダウンリストから [ストレージアカウント] を選択します。
2. 適用を選択します。
3. すべてのストレージアカウントを選択し、[削除] を選択してから、delete と入力して削除を確定します。
4. [削除] を選択します。完了するまで、通知内のプロセスを監視します。

次に、プライマリリージョンに対して、「Azure Site Recovery を使用してクラスターの障害復旧を設定する」セクションと同じ手順を実行します。ただし、次の違いがあります。

「Recovery Services コンテナーを作成」のセクションで、次の手順を実行します。
1. たとえば、 was-cluster-eastus-mjg022624 など、プライマリリージョンにデプロイされているリソースグループを選択します。
2. たとえば recovery-service-vault-eastus-mjg022624 など、サービスコンテナーに別の名前を入力します。
3. [リージョン] で、 [米国東部] を選択します。
[レプリケーションを有効化] の場合は、次の手順を実行します。
1. [ソース] の [リージョン] で [米国西部] を選択します。
2. [レプリケーション設定] の場合は、次の手順を実行します。
  1. [対象リソースグループ] で、たとえば was-cluster-eastus-mjg022624 など、プライマリリージョンでデプロイされた既存のリソースグループを選択します。
  2. [フェールオーバー仮想ネットワーク] の場合は、プライマリリージョンの既存仮想ネットワークを選択します。
[復旧計画を作成] で、[ソース] に対しては、[米国西部] を、[ターゲット] に対しては、[米国東部] を選択します。
前にこれらのリソースを作成して構成しているので、「セカンダリリージョンの追加ネットワーク構成」セクションの手順はスキップします。

Note

ターゲット VM が存在する場合、Azure Site Recovery で VM の再保護がサポートされていることがわかります。詳細については、「チュートリアル: Azure VM をセカンダリリージョンにフェールオーバーする」の「VM の再保護」セクションを参照してください。 WebSphere に対して実施するアプローチのため、この機能は機能しません。理由として、検証結果に基づいて、ソースディスクとターゲットディスクの間の変更のみが WebSphere クラスターに対して同期されるためです。このチュートリアルでは、VM 再保護機能の機能を置き換えるために、フェールオーバー後にセカンダリサイトからプライマリサイトへの新しいレプリケーションを確立します。ディスク全体が、フェールオーバーされたリージョンからプライマリリージョンにコピーされます。詳細については、「フェールオーバーした Azure 仮想マシンをプライマリリージョンで再保護する」の「再保護中に何が起こるか?」セクションを参照してください。

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

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

たとえば recovery-service-vault-eastus-mjg022624 など、プライマリリージョンでデプロイされた復旧サービスコンテナーを選択します。
たとえば、 was-cluster-eastus-mjg022624 など、プライマリリージョンにデプロイされているリソースグループを選択します。
プライマリリージョンで WebSphere Integrated Solutions Console とサンプルアプリへの外部アクセスを有効にしたら、WebSphere Integrated Solutions Console のブラウザータブと、前に開いたプライマリクラスターのサンプルアプリに再度アクセスします。期待どおりに動作することを確認します。フェールバックにかかった時間によっては、1 時間以上前に期限切れになった場合、サンプルアプリ UI の [新しいコーヒー] セクションにセッションデータが表示されない場合があります。
[フェールオーバーのコミット] セクションで、たとえば recovery-service-vault-eastus-mjg022624 などのプライマリにデプロイされている Recovery Services コンテナーを選択します。
Traffic Manager プロファイルでは、エンドポイント myPrimaryEndpoint が [オンライン] になり、エンドポイント myFailoverEndpoint が [低下] になります。
[フェールバックの準備: フェールオーバーサイトを再保護する] セクションで、次の手順を実行します。
1. プライマリリージョンはフェールオーバーサイトであり、アクティブであるため、セカンダリリージョンで再保護する必要があります。
2. セカンダリリージョンにデプロイされたリソース (たとえば、was-cluster-westus-mjg022624 でデプロイされたリソース) をクリーンアップします。
3. 次の変更を除き、「Azure Site Recovery を使用してクラスターの障害復旧を設定する」セクションと同じ手順を使用して、セカンダリリージョンでプライマリリージョンを保護します。
  1. 前に Recovery Services コンテナーを作成済みなので (例: recovery-service-vault-westus-mjg022624)、「Recovery Services コンテナーの作成」セクションの手順をスキップします。
  2. [レプリケーションを有効化]>[レプリケーション設定]>[フェールオーバー仮想ネットワーク] の順に選択し、セカンダリリージョンで既存の仮想ネットワークを選択します。
  3. 前にこれらのリソースを作成して構成しているので、「セカンダリリージョンの追加ネットワーク構成」セクションの手順はスキップします。

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

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

Azure Portal の上部にある検索ボックスで SQL Database サーバーのリソースグループ名 (例: myResourceGroup) を入力し、検索結果から一致するリソースグループを選択します。
[リソースグループの削除] を選択します。
[削除するリソースグループ名を入力する] で、リソースグループ名を入力します。
[削除] を選択します。
Traffic Manager のリソースグループに対して、手順 1 ～ 4 を繰り返します (例: myResourceGroupTM1)。
Azure Portal の上部にある検索ボックスに、Recovery Services vaults と入力し、検索結果で、[Recovery Services コンテナー] を選択します。
たとえば recovery-service-vault-westus-mjg022624 など、Recovery Services コンテナーの名前を選択します。
[管理] で、[復旧計画 (サイトの回復)] を選択します。たとえば recovery-plan-mjg022624 など、作成した復旧計画を選択します。
レプリケートされた項目のロックを削除するには、「レプリケーションを無効化」セクションと同じ手順を使用します。
たとえば was-cluster-westus-mjg022624 など、プライマリ WebSphere クラスターのリソースグループに対して、手順 1 ～ 4 を繰り返します。
たとえば was-cluster-eastus-mjg022624 など、セカンダリ WebSphere クラスターのリソースグループに対して、手順 1 ～ 4 を繰り返します。

次のステップ

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

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

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

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

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

Azure 上の WebSphere の詳細情報

次の方法で共有

チュートリアル: 高可用性と障害復旧を使用して WebSphere Application Server を Azure Virtual Machines に移行する

前提条件

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