Amazon Web Services ブログ

AWS 上で Google Cloud ワークロード向けのディザスタリカバリサイト構築 (Part 2)

信頼性の高いワークロードを構築するための設計原則の 1 つは、復旧手順をテストすることです。トラディショナルな環境 (オンプレミスなど) では難しい課題となりますが、クラウドはアプリケーションの障害を予測し、障害をシミュレートすることが可能のためはるかに簡単です。そして、障害から復旧するために人員、テクノロジー、プロセスがどのように連携するのか検証できます。クラウド設計原則の詳細については、AWS Well-Architected Framework の信頼性の柱を確認してください。

2部構成のブログシリーズのパート1では、プライマリが Google Cloud Platform (GCP) 、 ディザスタリカバリ(DR)サイトとして AWS Cloud を使用するワークロード向けの DR ソリューションを構築しました。 AWS Elastic Disaster Recovery (AWS DRS) を GCP から AWS にソースサーバーのレプリケーションのために利用し、GCP から AWS にソースサーバーをレプリケート及び、GCP から AWS にフェイルオーバーを行いました。その後、Domain Name System (DNS) を変更して、カットオーバーしました。

この記事では、DR サイトを使用してトラフィック処理やトランザクションを実行し、完了後はシステム障害前の通常運用に戻すといった企業や組織で広く用いられている要件をシミュレーションします。

フェイルバックと呼ばれるこのプロセスは、リカバリシステム(この記事では AWS )からプライマリシステム( この記事では GCP )へトラフィックをリダイレクトします。 AWS DRS は 元のソースサーバー (GCP) 上の Failback Client にて、レプリケーション方向を反転させます。この仕組みは、障害発生中に AWS で生じたデータを GCP へレプリケーションする際に役立ちます。

事前準備

このソリューションは、2部構成のブログシリーズのパート1 で記載している、フェイルオーバーを行う部分の実施が完了していることを前提とします。

ソリューションの概要と説明

以下の図でソリューション全体の概要を示します。

概要図を元に、次の流れで手順を進めていきます。

  1.  Failback Client の準備
  2. ネットワーク要件の確認及び、必要なポートの開放
  3.  AWS Identify and Access Management (IAM) ユーザーの作成と IAM 認証情報の生成
  4.  GCP 上で Failback Client の起動とレプリケーションの完了
  5. カットオーバーの実施と平常状態に戻すためのレプリケーションバックの実施

1. Failback Client の準備

Failback Client はシステムがフェイルバックするサーバーの起動に使用されます。クライアントをダウンロードするリンクはリカバリインスタンスが稼動しているリージョンによって異なります。この記事では、 us-east-2 を使用しているため、このリンクからフェイルバッククライアントのソフトウェアをダウンロードしています。

フェイルバッククライアントは livecd.iso 形式で保存されています。livecd.iso 形式は GCP 上の VM (Virtual Machine)起動に使用できず、このソリューションで使用できません。これを解決するために、 GCP 上で使用できる仮想ディスクへ変換します。変換処理では、 Linux Kernel のインストール、 Grand Unified Bootloader (GRUB) の設定ファイル(grub.cfg)の生成および、仮想ディスクへ GRUB をインストールします。変換処理のアウトプットは仮想ディスク(VMDK) となります。この仮想ディスクを用いて GCP に互換性のあるイメージ(こちらも確認下さい)を作成し、フェイルバック VM の作成に使用します。

変換の手順は本記事の範囲外となりますが、変換に用いるコードの閲覧とダウンロードはこちらから可能です。

2.ネットワーク要件の確認及び、必要なポートの開放

フェイルバックプロセスでは、次のネットワーク要件を満たす必要があります。

  • GCP 上の Failback Client から AWS 上のリカバリインスタンスへの TCP 1500
    • ブログシリーズのパート1 で GCP から AWS への接続に使用したレプリケーションとは、逆方向のレプリケーションを可能とするために必要です。
  • GCP 上の Failback Client から S3 エンドポイントへの TCP 443
    • レプリケーションソフトウェアのダウンロードのために必要です。
  • GCP 上の Failback Client から AWS DRS エンドポイントへの TCP 443
    • 通信を開始や、進行中のレプリケーションステータスのアップデート及び、ペアリングの実施のために必要です。

3. AWS Identify and Access Management (IAM) ユーザーの作成と IAM 認証情報の生成

Elastic Disaster Recovery Failback Client を使用したフェイルバックを行うためには、要件を満たす AWS 認証情報の作成が必要です。この認証情報は、永続的な認証情報 ( IAM ユーザー) または一時的な認証情報( assume role を使用)のいずれかを用いることができます。これらの認証情報は、 Failback Client のインストール時のみ使用します。 このデモでは、 Using the Failback Client の手順に従い IAM ユーザー (drs-failback)を作成します。このユーザーの認証情報は次に実施する手順 4 で使用する認証情報となります。

4. GCP 上で Failback Client の起動とレプリケーションの完了

フェイルバックレプリケーションに向けた準備：

  1.  AWS DRS の管理画面中の Failback replication setting タブに表示されている、”Use private IP for data replication” の値が Yes となっていることを確認します。このブログシリーズのパート1にて VPN 接続を構築しているため、 Yes と表示されています。
  2.  AWS からフェイルバックを行うリカバリインスタンスのインスタンス ID を確認し、控えておきます。この ID は 次の手順で使用します。
  3.  フェイルバックが機能するためには、Failback Client が AWS 上の オリジナルサーバーよりも大きなボリュームを有している必要があります。これは、 プライマリサイトに障害が発生している間も DR サイトに書き込まれるデータを格納していくために大きなボリュームが必要となります。このデモでは、このブログシリーズのパート1で使用したものと同一の GCP 上の仮想マシンを使用し、VMに 30 GB のボリュームを追加します。その新たに追加したボリューム (sdb)をフェイルバックデータレプリケーションに使用します。

追加ボリュームをアタッチした Failback Client VM のファイルシステムは次のようになります：

Failback Client をstart.sh コマンドを実行し起動します。 その際に、 AWS Region 名の入力を求められます。この記事の構成の場合、 us-east-2 と入力します。

フェイルバックプロセスが開始され、ウィザード形式で次のようなパラメータを入力していきます：

AWS access key and secret access keys : 手順3で作成した認証情報を入力します。

Recovery instance ID: Failback Client は、Failback Client がインストールされているサーバーの構成と、 AWS 上のリカバリインスタンスのマッピングを試行します。一致するインスタンスが見つからない場合は、フェイルバック元となるリカバリインスタンスの ID を入力するように要求されます。今回の例では、手順4.2で控えておいた ID を入力します。

Local block device: 全手順と同様に、Failback client はリカバリインスタンスとフェイルバックサーバーのボリュームのマッピングを試行します。もし、 マッピングを行うボリュームが見つからない場合、データレプリケーションを行うボリューム のIDの入力が要求されます。

ボリュームのマッピングおよびコネクション確立に成功すると、 Failback client はレプリケーションソフトウェアをダウンロードし、 AWS から GCP に対する逆方向レプリケーションを開始します。レプリケーションが開始された後、コンソール画面上には “Replication in progress ” と表示されます。 AWS 側のステータスを確認を行っていきます。

ステータス確認のために AWS DRS の管理画面に戻りると、コネクションが確立されている事、レプリケーションが開始されようとしていることが確認できます。

しばらく待機します。次の図の例では、レプリケーションの進捗率は 44% となっています。

その後、レプリケーションが完了状態となります。

フェイルバックを計画しているすべてのリカバリインスタンスが上記のようなステータスとなった後、各インスタンス ID の左側にあるチェックボックスにチェックを入れます。その後、 Failback をクリックします。これによって、データレプリケーションが停止し、変換処理が開始されます。フェイルバック処理が終了すると各リカバリインスタンスのレプリカが対応するソースサーバー上に作成されます。

この一連の作業によってジョブが作成さており、Recovery job history ページにて状態を確認できます。フェイルバックが完了すると、 Failback Client  にてフェイルバックが正常に完了したことが表示されます。

AWS 上のリカバリインスタンスの全データを GCP に作成した Failback Client VM の新しいボリューム(sdb)にレプリケーションしています。フェイルバックプロセスを完了させるための最終ステップは、このボリュームを使用して新しいイメージを作成し、作成したイメージを用いて GCP に新たな Compute Engine のスピンアップ(訳注: 起動過程の一連の流れを指します)することです。この新しい VM には、オリジナルデータ(つまり災害前のデータ)と DR のテスト中に AWS に書き込まれたデータが保存されており、この VM を用いて通常の運用へ復帰させます。これは、 GCP から AWS へのレプリケーションを開始し、障害発生時や DR 訓練を実施したい時に、演習を再実行することを意味します。

この記事にて前述した手順に従い、新しいイメージを作成します：

5.カットオーバーの実施と平常状態に戻すためのレプリケーションバックの実施

最後の手順として、 DNS をカットオーバーし、 GCP 上のオリジナルワークロードへの切り戻しを行います。 DNS の切り替えを行う際のオプションの詳細については、2部構成のブログシリーズのパート1を参照ください。

ソリューションのコストと料金

このブログシリーズのパート1で説明を行った料金の詳細はパート2でも同様のものとなりますが、パート2では考慮すべき追加要素があります。それは、 AWS から GCP へフェイルバックレプリケーションを行うためのアウトバウンドデータ転送料金です。 AWS からインターネットへのデータ転送はサービス毎に課金され、リージョン毎に料金が異なります。詳細については、各サービスの料金ページを参照ください。一例としては、 Amazon Elastic Compute Cloud (Amazon EC2) の料金ページを参照ください。

クリーンアップ

これらの手順を実施後に不要な AWS 費用を発生しないようにするためには、本デモで作成した AWS 及び GCP のリソースを削除します。 これには GCP 上の Compute Engine とネットワークコンポーネント、レプリケーションインスタンス、 EBS スナップショット及び AWS DRS によって作成されたリカバリインスタンスが含まれます。

最後に

本記事では、DR サイト (AWS Cloud) からプライマリサイト (GCP) へフェイルバックする手順を紹介しました。この手順は通常 DR サイトにてユーザーリクエストを処理しトランザクションを実行させる場合において DR テストを完了するための最終作業となります。フェイルバックプロセスでは、AWS から GCP へのレプリケーションを逆転させることで、障害時に DR サイトに書き込まれたデータをプライマリサイトに対するレプリケーションを可能にします。Failback Client の ISO イメージは GCP 上で直接的に使用できないため、 GCP に対応したブータブルディスクを作成するための変換処理を行いました。フェイルバックプロセスのために作成したボリュームに対するレプリケーションを行い、それを使用することで GCP 上に障害前のオリジナルサーバーの代わりとなる Compute Engine を新規作成しました。GCP 上でお客様のトラフィックを処理するサーバーへ DNS の向き先を切り替えました。

この2部構成のブログシリーズをご覧いただきありがとうございます。

この記事はアマゾン ウェブ サービス ジャパンの畠泰三が翻訳を担当しました。 (原文はこちら)

Ebrahim (EB) Khiyami

Ebrahim (EB) Khiyami

Ebrahim (EB) Khiyami は、AWSのシニアソリューションアーキテクトです。AWS Well-Architected Framework のスペシャリストであり、マイグレーションとディザスタリカバリの SME でもああります。仕事以外の多くの時間は、サッカーをしたり、観戦をしたり、指導をしています。

Shanmugam Shanker

Shanmugam Shanker

Shanmugam Shanker は AWS プロフェッショナルサービスのリードコンサルタントです。AWS のサービスを利用して革新的なソリューションを構築し、顧客のビジネス目標の達成を支援することに情熱を注いでいます。趣味は、家族や友人と過ごすことや、PS ゲーム及びハイキングです。