こんにちは、Enterprise Cloud部 技術1課 宮形 です。
先日、AWS Elastic Disaster Recovery (DRS) を試用してみましたので、その内容をBLOGとしてご紹介させていただきます。
AWS Elastic Disaster Recovery (DRS) とは
AWS Elastic Disaster Recovery (以下DRSと記) は、サーバーのディスクイメージ全体をレプリケーション によって、AWS上のストレージに継続して転送保管を行う機能を有するサービスです。レプリケーションで取得したサーバーイメージはEC2インスタンスとして復元(リカバリによるフェールオーバー)することができます。また、元のサイトに切戻し(フェールバック)する機能も有しており、オンプレミスのサーバーにも対応しています。組織のBCPの策定や、ディザスタリカバリサイト(DRサイト)の構築に役立つサービスとなります。
AWS環境同士、他社クラウドサービスとAWS、オンプレミスサーバーとAWS といった組み合わせのレプリケーションも可能です。
なぜ略称が "EDR" ではなく"DRS" なのか？については、AWS よくある質問に理由が書かれていました。（納得）
本BLOG試用での構成図と前提
試用では下記図のような構成で環境構成しました。DR対象サーバーは Windows Server としました。インターネット上ですでに公開されているDRSの情報の殆どが Linux Server だったためです。
前提
- メインサイト、DRサイト両方にAWSを利用
- メインサイトは東京リージョン、DRサイトは大阪リージョンを利用
- メインサイトのDR対象サーバーは Windows Server EC2 を利用
- DRSのレプリケーションはインターネット経由(Internet Gateway)のパブリック接続 [プライベートでの接続も可能]
- メインサイトとDRサイトのワークロードVPCのCIDRは同じIPアドレス
構築手順
試用の際の構築手順をご紹介します。DRSのセットアップ、レプリケーション、リカバリテストまで行ってみました。
DRSのセットアップ
AWSマネジメントコンソールより「AWS Elastic Disaster Recovery」コンソールへ移動し、大阪リージョンへ切替します。
「設定と初期化」を押下します。
「レプリケーションサーバーを設定」の画面が表示されます。「ステージングエリアサブネット」でレプリケーションサーバーを配置するVPCサブネットを選択します。これはDRサイトでEC2を復元するためのVPCサブネットではなく、DRSの動作に必要となるレプリケーションサーバーを配置するためのVPCサブネットです。私はデフォルトVPCを選びました。 レプリケーションサーバーのインスタンスタイプは「t3.small」から通常変更することは必要ないようですが、「情報」をクリックするとサイジングの指針情報が表示されました。
「ボリュームとセキュリティグループを指定」の画面が表示されます。ここは特別な要件がなければ基本デフォルトで問題無さそうです。
「その他のレプリケーション設定を設定」の画面が表示されます。試用では全てデフォルトとしましたが、レプリケーションをプライベート接続する場合、ネットワーク帯域幅の調整、バックアップ保持日数の変更といった要件において調整します。
「デフォルトのDRS起動設定を設定」の画面が表示されます。復元を行う際の挙動について設定できるようです。私の試用では「プライベートIPをコピー」のチェックをオンに変更しました。後からでも変更できますので、構築時点でわからなければデフォルト値で進めるとよいと思います。
「デフォルトの EC2 起動テンプレートを設定」の画面が表示されます。私の試用では「サブネット」にDRサイトのワークロードVPCのサブネットを選択しました。実運用ではDR対象サーバー毎に設定することが多いと思います。ここも後から変更できます。
「確認と初期化」の画面が表示されます。サマリーを確認し、末尾の「確認と初期化」を押下します。
これでDRSは利用可能になりました。続けて、DR対象サーバー毎の作業として「DRS用のIAMユーザーの作成」、「AWS Replication Agent 導入」を行います。
DRS用の IAMユーザー の作成
AWSアカウントにDRS用のIAMユーザーを作成します。このIAMユーザーは DR対象サーバーに導入する AWS Replication Agent がDRSとの制御通信において認証・認可を行う際に利用されます。IAMコンソールへ移動し、下記の要件でIAMユーザーを作成し、アクセスキー・シークレットを控えておきます。
- IAMユーザー名は任意でOK
- AWSマネジメントコンソールへのユーザーアクセスは不要・アクセスキーのみ利用
- IAMポリシーとしてAWS管理ポリシーの「AWSElasticDisasterRecoveryAgentInstallationPolicy」を付与
DR対象サーバーへの AWS Replication Agent 導入
DR対象サーバーへ AWS Replication Agent を導入します。AWSサイトからインストーラーをダウンロードして、インストールするたけです。本BLOGでは Windows Server で試用を行っています。
インストーラーを入手します。こちらのサイトにダウンロード元が記載されています。DRSを構築したリージョンから入手するようにとあるので、私は大阪リージョンからダウンロードしました。
https://aws-elastic-disaster-recovery-ap-northeast-3.s3.ap-northeast-3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe
DR対象サーバーのWindowsに管理者権限でサインインします。ダウンロードしたインストーラーを「管理者として実行」にて起動します。
コマンドプロンプトが起動します。最初に「AWS Region name」「AWS Access Key ID」「AWS Secret Access Key」の入力が求められます。DRSの利用は大阪リージョンなので「ap-northeast-3」とし、先ほど作成したIAMユーザーのアクセスキー・シークレットをコピーペーストで入力します。
レプリケーションするディスクを選択するか聞かれます。すべてのディスクが対象であれば、何も入力せず Enter キーで応答します。
インストールが成功すると「... successfully installed.」が表示されます。Enterキーで応答すると画面が閉じます。
Windows Server のタスクマネージャーやリソースモニターを眺めていると、AWS Replication Agent とみられる java.exe がアウトバウンドにデータ転送を行っていることが確認できます。初回のフルレプリケーションを行っているようです。
「AWS Elastic Disaster Recovery」コンソールを確認すると、DR対象サーバーのホスト名とインスタンスIDが表示されます。AWS公式AMIから起動しただけの Windows Server の EC2 でしたが、約40分後に確認すると「初期同期」→「準備完了」になっていました。初回のフルレプリケーションが完了したことが確認できます。
これでDR対象サーバーがDRSとのレプリケーションが行われている状態となります。平常時はこの状態で運用することになります。
起動テンプレートの設定
DRサイトでのEC2毎の復元時動作を起動テンプレートとして設定します。DRSのセットアップ時にも起動テンプレートを設定していますが、EC2毎に異なる設定とすることが一般的かと思います。DR対象サーバーが追加になる都度、設定を行います。
「AWS Elastic Disaster Recovery」コンソールのより「ソースサーバー」を開きます。一覧より DR対象サーバーを選択し、「アクション」ー「EC2起動テンプレートを編集」を押下します。
「EC2起動テンプレートを編集」の画面が表示されます。私の試用ではVPCサブネットとセキュリティグループを調整しました。パブリックサブネットでの利用になるので「パブリックIPを自動的に割り当てる」を「はい」としました。
リカバリテスト
DRSより復元を試してみます。DRSには本番稼働しているレプリケーションに影響することなくテストを行える「リカバリドリル」という機能がありますので、実際の運用ではこちらを行うことが一般的かと思います。今回は試用なのでいきなり本番想定の「リカバリを開始」から行いました。
「AWS Elastic Disaster Recovery」コンソールのより「ソースサーバー」を開きます。一覧より DR対象サーバーを選択し、「リカバリジョブを開始」ー「リカバリを開始」を押下します。
「ポイントインタイムを選択」が表示されます。試用では「最新のデータを使用する」を選択しましたが、DRSが自動的に管理している過去世代の静止点を指定することもできます。末尾にスクロールして「リカバリを開始」を押下します。
リカバリが開始されます。「リカバリジョブの履歴」の画面より進捗と結果を確認できます。 AWS公式AMIから起動しただけの Windows Server の EC2 でしたが、約15分ほど要してリカバリインスタンスが完了となっています。
EC2コンソールを開くと、無事大阪リージョンの ワークロードVPC上に復旧後のサーバーが起動していることが確認できました。
Windows Server へのリモートデスクトップ接続も出来ました。プライベートIPアドレスも維持できています。
Windows 固有のセキュリティ識別子のSIDも同一でした。DRSのプロセスにおいて Sysprep が行われはいないようです。
リカバリ時に「最新のデータを使用する」とした場合、どれほどリアルタイム性があるか確認したかったのでDR対象サーバーのメインサイトで1秒ごとログにタイムスタンプを書き出すバッチを仕込んでおきました。NACLを用いて疑似的にネットワーク通信断を起こして障害をシミュレーションしましたが、ラグは約10秒ほどでした。
無事、DRSを利用してリカバリテストを行うことが出来ました。
まとめ
DRSを効果的に利用するには、万一フェールオーバーする事態になった場合でも正しくEC2と通信が継続できるよう、VPC、DNS、Direct Connect や Site-to-Site VPN の冗長構成といったネットワーク面をしっかり設計できるかが肝だと感じました。 また、AWSとしても推奨していますが、DRS環境の構築完了した後も、リカバリドリルを用いるなどして定期的なBCPリハーサルを行うことも重要であります。
弊社エンジニアブログには、ネットワークの設計、冗長化に関する記事も多数ありますので、合わせてご活用いただけますと幸いです。 本BLOGの内容が皆様のお役に立てば幸いです。
