こんにちは、サイオステクノロジー　LifeKeeper 担当の宇野です。

本日は、Amazon EC２のインスタンス上にLifeKeeper for Linux にて構成したHAクラスター環境（クラスターノード）をAmazon Elastic Disaster Recoveryを使用してリージョン間レプリケーション、およびリストアを行った手順について紹介させていただきます。

Amazon Elastic Disaster Recoveryとは

AWS Elastic Disaster Recovery (AWS DRS) は、AWSで利用可能なリソースを用いて、容易に指定のリージョンへレプリケーションを行い、オンプレミスおよびクラウドベースのアプリケーションを迅速かつ確実に復旧することで、ダウンタイムやデータ損失を最小限に抑えます。そのため災害などによる大規模障害（リージョン障害）が発生した場合でも、速やかなシステムのリカバリーを行えるBC対策の一つとなります。

本記事ではAWS DRSを使用し、HAクラスターであるLifeKeeper/DataKeeperを導入したクラスターノードを、リージョンAからリージョンBへのレプリケーション、リカバリーする手順について紹介します。

図１：AWS Elastic Disaster Recoveryによるデータレプリケーションとリカバリー

＜注意：当社の責任範囲＞

AWS DRSのサービスそのものをLifeKeeperで冗長化しているわけではないため、AWS DRSはLifeKeeperのサポート対象として考慮されません。このため、お客様の責任でLifeKeeperの環境でAWS DRSをご使用願います。当社の製品サポートでは、AWS DRSをお使いになられていてもお問い合わせは受付致しますが、AWS DRSそのものに関するお問い合わせは受付致しかねます。なお本ブログは2024/11/18の動作検証にて確認した内容です。

レプリケーション対象となるクラスターの構成

■クラスター構成1（Load Balancer Health Checkリソース構成）

レプリケーション元のリソース構成は以下のようになります。

図２．バックアップ元の Network Load Blancer を使用したクラスターリソース構成

■クラスター構成2（Route53リソース構成）

レプリケーション元のリソース構成は以下のようになります。

図３．バックアップ元のRoute53  を使用したクラスターリソース構成

クラスターシステムを配置して、AWS DRSにてレプリケーション、リストアを行います。以下のような構成図となります。

図４：AWS Elastic Disaster Recoveryの動作検証環境

Amazon Elastic Disaster Recoveryによるレプリケーション、リストア

続いて、レプリケーションを行うための準備を行います。レプリケーション先となるリージョンを大阪リージョンとは別リージョンを選択して、レプリケーションの設定からリストアまでを以下の流れで紹介します。 

1. AWS Elastic Disaster Recovery の設定と初期化
2. Disaster Recovery用IAMインスタンスプロファイルの作成
3. レプリケーション対象となるインスタンスにAgentのインストールを行い、レプリケーションの開始
4. レプリケーション先のデータを使用したリカバリジョブの実施（リストア）

１．AWS Elastic Disaster Recovery の設定と初期化

1. レプリケーション先リージョンへ移動して、検索画面から”Disaster”を検索してください。サービスとして、”AWS Elastic Disaster Recovery”が表示されますので、このサービスを選択します。

   

2. AWS Elastic Disaster Recoveryの画面が表示されます。画面の右にあります”設定と初期化”をクリックして、レプリケーションのAWS Elastic Disaster Recoveryの設定を開始します。

   
   
3. セットアップを開始します。ステップは6まであります。この設定は後ほど管理画面から変更が可能です。

   ステップ1ではレプリケーションサーバーの設定を行います。レプリケーションサーバーはレプリケーションデータを受け取るインスタンスを指します。設定では配置するサブネットを選択する必要があります。ここではデフォルトVPCのサブネットワークを選択します。レプリケーションサーバーのインスタンスタイプは推奨となっている初期値のまま進めます。

   
   

4. ステップ2ではボリュームとセキュリティグループの指定を行います。ボリュームタイプは自動選択が推奨です。EBSの暗号化もデフォルトで進めます。セキュリティグループはDRS用に作成されたセキュリティグループがデフォルトで設定されますのでこのまま進めます。

   
   

5. ステップ３ではその他のレプリケーション設定を行います。レプリケーションはデフォルトでインターネット経由で行いますが、専用線（ダイレクトコネクトなど）を経由する場合はこちらから設定可能です。その他、スナップショット保持期間やタグ付けの設定が可能です。

   
   
   

6. レプリケーション先でのインスタンスイメージ起動時の設定を行います。クラスターシステムをレプリケーションして利用する際は、”プライベートIPのコピー”を設定してください。レプリケーションイメージのIPアドレスが変更となった場合、クラスターの設定変更箇所も増えます。

   
   
   

7. インスタンスイメージ起動時のサブネットやセキュリティグループなど、インスタンステンプレートの初期設定を行います。サブネットやセキュリティグループは後ほどリストア時にインスタンスに合わせて変更します。そのため何か適当な値を設定してください。その他の値についても後ほど変更は可能ですが、詳細など普段利用する設定をテンプレートに設定することで、リストア時に設定する必要が無くなります。

   
   
   
   

8. ステップ6では設定した値を確認する画面が表示されます。問題なければ最下部の”設定と初期化”を押して完了です。

   
   

9. 管理画面が表示されます。左のメニューの設定項目から、設定した値の変更が可能です。

   

２．Disaster Recovery用IAMインスタンスプロファイルの作成

レプリケーションの開始に必要な権限を持つ専用のロールを作成する必要があります。AWS DRSで利用するロールは１の初期設定時に作成されます。作成されるロール、ポリシーは以下に記載されています。

https://docs.aws.amazon.com/ja_jp/drs/latest/userguide/getting-started-initializing.html

上記のポリシーを割り当てた IAMユーザー（インスタンスプロファイル）を用意してください。レプリケーション時にアクセスキーを使用します。（AWSマネジメントコンソールへのユーザーアクセスは不要）

３．レプリケーション対象となるインスタンスにAgentのインストールを行い、レプリケーションの開始

 レプリケーションを開始するため、インスタンス、AWS環境の準備を行います。今回はRedHat Linux 8環境を前提に紹介します。

1. 1. OSのバージョンによりパッケージ名が異なる場合がありますが、 選択したRHEL8.6のAMIでは以下のコマンドでパッケージをインストールする必要があります。
      

      # dnf install wget  gcc kernel-headers kernel-devel curl
      

      ※起動中のカーネル(uname -r で確認) とkernel-headers のバージョンを一致させる必要があります。そのため、場合によってはカーネルのバージョンアップが必要となります。

   2. レプリケーションではネットワークが1経路しかコピーされません。複数のネットワークで構成をした場合、別リージョンへリストアした後、ネットワークの追加が必要となります。
   3. リストアを行うにあたり、事前に同じVPC設定（サブネット、ルートテーブル、セキュリティーグループなど）をリストア先のリージョンにも作成してください。
   4. レプリケーションを開始するため、エージェントのインストールを行います。以下のコマンドでエージェントファイルをダウンロードして実行してください。

      インストールツールのダウンロード ■ 東京リージョン # wget -O ./aws-replication-installer-init https://aws-elastic-disaster-recovery-ap-northeast-3.s3.ap-northeast-3.amazonaws.com/latest/linux/aws-replication-installer-init ■ 大阪リージョン # wget -O ./aws-replication-installer-init https://aws-elastic-disaster-recovery-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init

   5. ダウンロードしたファイルをインスタンス上で実行します。以下はインスタンスにエージェントがインストール時の出力です。※赤字は入力が必要な項目です。
      

      実行権限の付与、Agentのインストール、レプリケーション開始 # chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init The installation of the AWS Replication Agent has started. AWS Region Name: ap-northeast-1 ＜ レプリケーション先のリージョンを指定 AWS Access Key ID: AKIAZ***************** < 2で作成したIAMプロファイルを使用する AWS Secret Access Key: ****************************************　< 2で作成したIAMプロファイルを使用する Identifying volumes for replication. Choose the disks you want to replicate. Your disks are: /dev/xvda,/dev/xvdb To replicate some of the disks, type the path of the disks, separated with a comma (for example, /dev/sda, /dev/sdb). To replicate all disks, press Enter:/dev/xvda,/dev/xvdb　< 未入力でENTERするとすべて選択 Identified volume for replication: /dev/xvdb of size 8 GiB Identified volume for replication: /dev/xvda of size 10 GiB All volumes for replication were successfully identified. Downloading the AWS Replication Agent onto the source server... Finished. Installing the AWS Replication Agent onto the source server... Finished. Syncing the source server with the Elastic Disaster Recovery Console... Finished. The following is the Source Network ID: sn-63a853ff993a2**** ＜ 東京リージョンに作成されたネットワークID. The following is the source server ID: s-651463a589608****.＜東京リージョンに作成されたインスタンスID The AWS Replication Agent was successfully installed.　＜Agentのインストールに成功

   6. レプリケーション先となるリージョンのAWS DRS管理画面を確認してください。データレプリケーションが開始されます。

      

   7. 初期同期には時間がかかります。初期同期が完了しますと、データレプリケーションのステータスが”正常”になります。
      
      

   8. レプリケーション先のリージョンにはレプリケーションサーバーが作成されます。

４．レプリケーション先のデータを使用したリカバリジョブの実施（リストア）

レプリケーションが完了しましたら、 データのリストアを試してみます。AWS DRSではリストアのテスト用メニューとして、”リカバリドリルの開始”が用意されていますので、こちらを実施してみます。

1. 1. リストアを実施するサブネット、セキュリティグループを設定します。リストアを行うデータはレプリケーション元のサブネット情報を保持していますので、リストア時にサブネットの一致についてチェックを行います。そのため、以下のように該当のデータを選択して、”EC2起動テンプレートを編集”からサブネット情報を変更する必要があります。

      

   2. ”EC2起動テンプレートを編集”画面が開きます。一致するサブネットを選択してテンプレートの更新を行ってください。

      

   3. リカバリドリルを開始します。対象ホストを選択して、右上のプルダウンメニューから”リカバリドリルを開始”を選択します。
      
      

1. ポイントタイムを選択します。10分ごとに差分バックアップを取得しているため、過去にさかのぼったリカバリが可能です。ここでは最新データを選択してドリルを開始します。

   

2. リカバリドリルが成功すると前回のリカバリの結果が”成功”と表示されます。

   

   
   リストアされたインスタンスがレプリケーション先のリージョンで起動します。

   

５．リストア後の設定変更

大阪リージョンから東京リージョンへのレプリケーション、リストアが成功しましたが、リージョンが変わる事で以下の変更が必要となります。

1. ホスト名の情報の変更
   ホスト名はリージョン間で以下のように変更されてます。

   リージョンA	ip-10-222-BB-AA.ap-northeast-3.compute.internal
   リージョンB	ip-10-222-BB-AA.ap-northeast-1.compute.internal

   
   以下のコマンドを使用してLifeKeeper で内部保持するホスト名情報を書き換えます。ホスト名情報の変更を行う以下のコマンドは両ノードで実行してください。

   # /opt/LifeKeeper/bin/lk_chg_value -o ip-10-222-BB-AA.ap-northeast-3.compute.internal -n ip-10-222-BB-AA.ap-northeast-1.compute.internal # /opt/LifeKeeper/bin/lk_chg_value -o ip-10-222-CC-AA.ap-northeast-3.compute.internal -n ip-10-222-CC-AA.ap-northeast-1.compute.internal

   ※lk_chg_value コマンドについては以下をご確認ください。
   https://docs.us.sios.com/spslinux/9.9.0/ja/topic/changing-lifekeeper-configuration-values

   OSコマンドで事前にホスト名の変更を行って導入した場合も、ホスト名がAWSでのホスト名に変更されます。

   リージョンA	rhel801
   リージョンB	ip-10-222-BB-AA.ap-northeast-1.compute.internal

   事前にホスト名を変更してLifeKeeperのインストールを行っている場合、LifeKeeper が保持するホスト名はOS上で変更したホスト名”rhel801”となります。そのため、リカバリ後のシステムにログインして、以下のコマンドでホスト名を変更してください。両ノードで実行してください。

   # hostnamectl set-hostname rhel801

2. インスタンス、VPC、サブネット以外のAWSサービスの設定
   ・Load Balancer 構成では Network Load Balancerやターゲットグループ を再作成する必要があります。
   ・Route53構成では、リストア先のVPCと通信が行えるよう設定変更が必要となります。
   ・Load Balancer やRoute53のリージョン変更設定により、クライアントからの接続も確認してください。クライアント接続についても設定変更が必要となる場合があります。

3. AWS CLI のリージョン情報設定の更新（aws configureで再設定）
   AWS CLI が保持するデフォルトリージョン情報が変わります。Route53ではAWS CLI を使用するため、変更してください。変更は以下のコマンドで実施可能です。両ノードで実行してください。
   

   # aws configure

4. LifeKeeperの手動起動
   

   ホスト名の不一致が発生するため、LifeKeeperはOS起動時の起動に失敗しています。1)～3)の設定を確認するため、以下のコマンドで手動起動を行います。両ノードで実行してください。
   

   # systemctl start lifekeeper

    

5. DataKeeperリソースの全同期
   

   リストア後にDataKeeperリソースが正常に起動した場合でも、ディスク内のデータの整合性がとれていない状態になります。全同期コマンドを実行してDataKeeperの情報を初期化します。全同期を行うには以下のコマンドを実行します。このコマンドはどちらかのノードで１回実行してください。

   # lkcli mirror pause --tag dkrep-pgsql10.23 # lkcli mirror fullresync --tag dkrep-pgsql10.23

6. Quorum/Witness の設定
   /etc/default/LifeKeeper で設定する s3 を使用したQuorum/Witness の設定ではホスト名情報を使用したパラメータを設定します。ホスト名はリージョンを切り替える際に変更が必要なため、パラメータ設定情報も以下のように設定変更を行います。両ノードで変更してください。

   ※事前にOSコマンドでホスト名を変更していた場合、/etc/default/LifeKeeper 設定ファイルの更新が不要です。

   
   

   変更前	QWK_STORAGE_OBJECT_ip_10_222_BB_AA_ap_northeast_3_compute_internal=s3://storagequorumtokyo1/ip-10-222-BB-AA.ap-northeast-3.compute.internal QWK_STORAGE_OBJECT_ip_10_222_CC_AA_ap_northeast_3_compute_internal=s3://storagequorumtokyo2/ip-10-222-CC-AA.ap-northeast-3.compute.internal
   変更後	QWK_STORAGE_OBJECT_ip_10_222_BB_AA_ap_northeast_1_compute_internal=s3://storagequorumtokyo1/ip-10-222-BB-AA.ap-northeast-1.compute.internal QWK_STORAGE_OBJECT_ip_10_222_CC_AA_ap_northeast_1_compute_internal=s3://storagequorumtokyo2/ip-10-222-CC-AA.ap-northeast-1.compute.internal

   変更後、以下のコマンドでQuorum/Witness の設定変更を反映します。設定変更を行わなかった場合でも、リストア後のQuorumの設定が正しく動作するかどうか確認する目的で以下のコマンドを実行してください。両ノードで実行します。

   # qwk_storage_exit # qwk_storage_init ※上記のコマンドを両ノードで実施します。qwk_storage_initコマンドは両ノードで実行後に同期をとり終了しますので、同時期に実行してください。

7. リストア後のリソース構成を確認してください。エラーが発生している場合は、上記のリストア後の設定変更に漏れがないか確認してください。またVPCやサブネット , セキュリティグループなど、元のリージョンと同じ設定となっているかどうか確認してください。

8. リストア後、リソースが正常に起動しているかどうか、LifeKeeper Web Management Console を起動して確認します。

■ Load Balancer Health checkリソース構成

図５．リストア後の Network Load Blancer を使用したクラスターリソース構成

■ Route53リソース構成

図６．リストア後のRoute53  を使用したクラスターリソース構成

まとめ

以上が、AWS Elastic Disaster Recovery (AWS DRS) でクラスターシステムのレプリケーション、リストアを行う手順です。Agentのインストール時に制限が多いため、エラーとなった場合はエラーメッセージを確認して原因調査が必要になると考えられます。またkernel-headers などパッケージが必要となりますが、dnf (yum)コマンドでダウンロードを行うにあたり、起動カーネルと一致するバージョンのkernel-headersが無い場合もあります。この場合、カーネルのアップデートも必要となります。

Linux OSでは上記のような条件があり当初はレプリケーションが成功せず、個別の環境でも問題解決が必要になりました。また現状では Route53 と Load Balancer 構成のみがリストア可能となっていました。ルートテーブル構成では、VPC外のIPアドレスを利用することが原因となり、リストアが出来ませんでした。クラウド環境は日々変更がはいりますので、将来のバージョンに期待したいところです。