はじめに
こんにちは、ネットワールドSEの藤居です。
Veeam Backup & Replication には、取得済みバックアップから Amazon EC2 インスタンスとしてリストアする機能があります。オンプレミス環境の仮想マシンや物理サーバーのバックアップを、クラウド上の仮想マシンとして復元できる点は、移行・DR・検証環境作成の観点で非常に有効です。
今回はその中でも、VMware vSphere 仮想マシンのバックアップを Amazon EC2 へリストアするケースを取り上げます。Veeam の Restore to Amazon EC2 は、単なる障害復旧だけでなく、オンプレミス環境からクラウドへの移行や、クラウド上での一時的な検証環境作成にも利用できる機能です。
一方で、実際のお客様環境では、次のような要件をいただくことがあります。
Amazon EC2 へリストアしたいが、インターネット経由ではなく、AWS PrivateLink 経由で実施したい。
AWS PrivateLink とは、Amazon S3 や Amazon EC2 などの AWS サービスへ、パブリックインターネットを介さずにプライベート接続するための仕組みです。AWS サービスへ接続するための専用の入口として VPC エンドポイントを作成することで、通信を AWS ネットワーク内に閉じた形で利用できます。なお、オンプレミスからVPCエンドポイントへ到達するための経路（Site-to-Site VPN / Direct Connect など）は別途必要です。
特に金融、公共、エンタープライズ系のお客様では、セキュリティポリシー上、バックアップデータやリストア通信を可能な限りパブリックインターネットへ出したくない、という要件は珍しくありません。そのため、Amazon EC2 へのリストア機能そのものだけでなく、閉域接続を前提とした構成で実際にリストアできるのかを確認しておくことは、提案・設計時にも重要なポイントになります。
そこで今回は、Veeam Backup & Replication から VMware 仮想マシンのバックアップを Amazon EC2 へリストアする際に、AWS PrivateLink 経由でリストア処理を実行できるかを検証しました。構成は、VBR サーバ 1 台構成、バックアップデータはローカルリポジトリに保存しているシンプルな環境で確認しています。
先に結論
AWS PrivateLink 用の事前設定を行うことで、VMware 仮想マシンのバックアップを Amazon EC2 へリストアできることを確認しました。今回のポイントは次のとおりです。
- AWS 側で S3 Interface Endpoint と EC2 Endpoint を作成する
- VBR 側で
AmazonS3Regions.xmlを編集し、対象リージョンの S3 / EC2 エンドポイントを PrivateLink 用の DNS 名へ変更する - VBR サーバ、およびバックアップデータ転送を担うリポジトリサーバ／ゲートウェイサーバから、S3 Interface Endpoint と EC2 Endpoint の名前解決・通信ができるようにする
- 上記の事前設定を行えば、Veeam のリストア操作自体は、通常のインターネット経由での Restore to Amazon EC2 と同じ流れで実施できる
特に名前解決については、今回のような VBR サーバ 1 台構成かつローカルリポジトリ構成であれば、VBR サーバ自身から PrivateLink 用の S3 Interface Endpoint および EC2 Endpoint へ名前解決・通信できることを確認します。
Veeam では、Restore to Amazon EC2 を AWS PrivateLink または Direct Connect 経由で利用するための手順として、KB4264 が公開されています。本検証では、同 KB に記載されている S3 Interface Endpoint／EC2 Endpoint の作成、および AmazonS3Regions.xml の編集手順を参考に、閉域経路での EC2 リストアを検証しました。
KB4264: How to use "Restore to Amazon EC2" via AWS PrivateLink / Direct Connect
検証環境
今回の検証環境は以下のとおりです。
- Veeam Backup & Replication サーバ：1 台
- バックアップリポジトリ：VBR サーバ上のローカルリポジトリ
- バックアップ対象：VMware vSphere 上の Windows 仮想マシン
- リストア先：Amazon EC2
- AWS 接続：AWS PrivateLink 経由
- AWS 側エンドポイント：S3 Interface Endpoint、EC2 Endpoint
VBR サーバ 1 台に、バックアップサーバ、プロキシサーバ、リポジトリサーバの役割を集約しているシンプル構成です。
事前設定
（1）AWS 環境の準備
まず、AWS 側で PrivateLink 用のエンドポイントを準備します。今回の検証では、以下の VPC エンドポイントを作成しました
- S3 Interface Endpoint
- EC2 Endpoint
S3 Interface Endpoint は、後続の AmazonS3Regions.xml の編集で使用するため、作成後に DNS 名を控えておきます。EC2 Endpoint についても同様に、AmazonS3Regions.xml の編集で使用するため、作成後に DNS 名を控えておきます。
なお、これらのエンドポイントは、VBR サーバおよびバックアップデータ転送を担うサーバから名前解決・通信できる状態にしておく必要があります。今回のような VBR サーバ 1 台構成では、VBR サーバから S3 Interface Endpoint および EC2 Endpoint へ到達できることを確認しておきます。
（2）VBR 側の事前設定
まず、AmazonS3Regions.xml の自動更新を無効化します。このファイルは、Veeam が利用する AWS リージョンや各サービスのエンドポイント情報を保持しているファイルです。後続の手順で対象リージョンの S3 / EC2 エンドポイントを PrivateLink 用の DNS 名へ変更するため、自動更新によって編集内容が上書きされないように設定します。
以下のレジストリ値を追加します。
Key Location:
HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\Value Name:
CloudRegionsDisableUpdateValue Type:
DWORD (32-Bit) ValueValue Data:
1
設定後、AmazonS3Regions.xml を編集する前に、念のためファイルのバックアップを取得しておきます。また、Veeam Backup & Replication のアップデート適用時などに同ファイルが更新される可能性があるため、製品アップデート後は編集内容が維持されているか確認することを推奨します。
（3）CRL チェックに関する設定
インターネット接続が制限されている環境では、証明書失効リスト、いわゆる CRL（Certificate Revocation List）の確認ができず、リストア処理に影響する場合があります。特に、VBR サーバや関連コンポーネントからインターネット上の CRL 配布ポイントへアクセスできない構成では、証明書の失効確認に失敗する可能性があります。そのため、環境によっては CRL チェックを無効化する設定が必要になります。
ただし、この設定は Restore to Amazon EC2 だけでなく、Veeam の Object Storage 連携全体に影響する可能性があります。そのため、セキュリティポリシーや通信要件を確認したうえで、必要に応じて設定してください。今回の検証では、AWS PrivateLink 経由でのリストアを前提としているため、以下のレジストリ値を追加しました。
Key Location:
HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\Value Name:
ObjectStorageTlsRevocationCheckValue Type:
DWORD (32-Bit) ValueValue Data:
0
（4）AmazonS3Regions.xml の編集
次に、VBR サーバ上の AmazonS3Regions.xml を編集します。Veeam Backup & Replication では、以下のパスに配置されています。
C:\Program Files\Veeam\Backup and Replication\Backup\AmazonS3Regions.xml
事前にファイルのバックアップを取得したうえで、対象リージョンの定義を探します。
東京リージョンの場合は、以下のような定義です。
<Region Id="ap-northeast-1" Name="Asia Pacific (Tokyo)" Type="Global">
このリージョン定義内にある S3 および EC2 のエンドポイントを、AWS 側で作成した VPC Endpoint の DNS 名へ変更します。
S3 Endpoint は、S3 Interface Endpoint の DNS 名に変更します。
<Endpoint Type="S3">bucket.vpce-xxxxxxxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com</Endpoint>
EC2 Endpoint も同様に、EC2 Endpoint の DNS 名へ変更します。
<Endpoint Type="EC2">vpce-xxxxxxxxxxxxxxxxx-xxxxxxxx.ec2.ap-northeast-1.vpce.amazonaws.com</Endpoint>
S3 Interface Endpoint の DNS 名が *.vpce-xxxxxxxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com のように表示される場合、AmazonS3Regions.xml では * の部分を bucket に置き換えて設定します。
また、同じリージョン内に複数の S3 Endpoint 定義が存在する場合は、今回使用する PrivateLink 用の Endpoint 定義のみを残す形にします。
注意点として、AmazonS3Regions.xml のリージョン定義は、1 リージョンにつき 1 つのエンドポイント構成として扱われます。そのため、同一の VBR 環境・同一 AWS リージョン内で、PrivateLink 経由とパブリックエンドポイント経由を混在させる構成は避ける必要があります。編集後は、VBR サーバから設定した S3 Interface Endpoint および EC2 Endpoint の DNS 名が名前解決できることを確認しておきます。
Amazon EC2 へのリストア手順
事前設定が完了したら、Veeam Backup & Replication から Amazon EC2 へのリストアを実行します。
（1）Restore to Amazon EC2 ウィザードを起動
バックアップ一覧から対象の VMware 仮想マシンを選択し、Restore to Amazon EC2 を実行します。
（2）リストア対象のワークロードとリストアポイントを選択
次に、リストア対象のワークロードとリストアポイントを選択します。検証では、最新のリストアポイントを選択して処理を進めました。
（3） AWS 認証情報とリージョンを指定
次に、リストア先の AWS アカウントとリージョンを指定します。ここでは、先ほど AmazonS3Regions.xml を編集したリージョン（本検証では東京リージョン）を選択します。
（4）リストアマシン名とタグを指定
次に、Amazon EC2 上に作成されるリストア後のマシン名を指定します。必要に応じて AWS タグも設定できます。タグを設定しておくことでリストア後のインスタンスを識別しやすくなります。
（5）インスタンスタイプとディスクを指定
次に、リストア後の Amazon EC2 インスタンスで使用するインスタンスタイプを指定します。あわせて、復元するディスク構成やディスクタイプを確認し必要に応じて設定を調整します。
（6）ネットワーク設定を指定
次に、リストア後の Amazon EC2 インスタンスを配置する VPC、サブネット、セキュリティグループを指定します。
（7）Secure Restore 設定を指定
次に、Secure Restore の設定を指定します。Secure Restore を有効にすると、リストア前にバックアップデータのマルウェアスキャンを実行できます。今回は検証目的のため設定なしで進めます。
（8）Helper Appliance の確認
次に、Helper Appliance の設定を確認します。本検証ではデフォルト設定のまま Helper Appliance は指定せずに進めました。
（9）リストア処理を開始
最後に、設定内容を確認し、リストア処理を開始します。処理開始後は、Veeam のジョブセッションで進捗やエラー有無を確認します。リストアが完了すると、AWS 側に Amazon EC2 インスタンスが作成されます。
リストア実行～完了まで
リストアを実行すると、Veeam のジョブセッション上で Amazon EC2 へのリストア処理が開始されます。ただし、Veeam のジョブセッションログ上では、通信が AWS PrivateLink 経由で行われているかを直接判別することはできません。そのため今回は、VBR サーバ上のリソースモニターを使用し、リストア処理中の通信先のアドレスを確認しました。
リストア実行中に、事前設定した S3 Interface Endpoint および EC2 Endpoint のIPアドレス宛ての通信が発生していることを確認し、AWS PrivateLink 経由で処理されていることを確認しました。
データの流れとしては、バックアップリポジトリから、リストア対象マシンのディスクデータが Amazon S3 の一時バケットへアップロードされます。Amazon S3 上にアップロードされたディスクデータは RAW 形式の一時データとして保持され、その後、Amazon EC2 側で EBS ボリュームへインポートされます。最後に、作成された EBS ボリュームをもとに Amazon EC2 インスタンスが作成され、リストア後のマシンとして起動できる状態になります。
今回の検証では、AmazonS3Regions.xml に設定した S3 Interface Endpoint および EC2 Endpoint を利用することで、この一連の処理が AWS PrivateLink 経由で行われます。
その後、ジョブセッションが正常に完了していることを確認し、Amazon EC2 へのリストア処理が完了したことを確認します。
ジョブセッションが正常に完了すると、AWS マネジメントコンソール上にリストアされた EC2 インスタンスが表示されます。インスタンス一覧から、指定したリストア後のマシン名で EC2 インスタンスが作成されていることを確認します。あわせて、インスタンスの状態が起動中または実行中になっていることを確認します。
リストア後の状態
今回のように VMware 仮想マシンを Amazon EC2 へリストアした場合、ゲスト OS 内の設定は基本的に引き継がれます。今回の検証でも、OS のホスト名はリストア後の EC2 インスタンス上でも引き継がれていることを確認しました。
一方で、リストア先は Amazon EC2 となるため、仮想ハードウェアやネットワーク情報は VMware 環境とは異なります。ネットワークインターフェースは EC2 の ENI として作成されるため、MAC アドレスは元の VMware 仮想マシンとは別の値になります。IP アドレスについても、通常はリストア先の VPC / サブネット上で割り当てられるため、元の IP アドレスがそのまま引き継がれるわけではありません。
なお、Veeam Backup & Replication v13 の Restore to Amazon EC2 では、ネットワーク設定で Public dynamic / Private dynamic / Private static を選択できるため、要件に応じてプライベート IP アドレスを指定することも可能です。
移行元が VMware 仮想マシンの場合、ゲスト OS 内には VMware Tools や VMware 関連のドライバ、サービスが残っています。通常は Windows の「アプリと機能」から VMware Tools をアンインストールします。ただし、移行先環境では、仮想ハードウェアやドライバ構成の差異により、アンインストール処理が正常に完了しない場合があります。そのような場合は、GitHub で公開されている Uninstall-VMwareTools.ps1 のような PowerShell スクリプトを参考に、VMware Tools 関連のファイルやサービスを強制的に削除する方法も検討します。
参考）
Force removal of VMware Tools, Program Files, and Windows Services · GitHub
おわりに
今回は、Veeam Backup & Replication を使用して、VMware 仮想マシンのバックアップを AWS PrivateLink 経由で Amazon EC2 へリストアする検証を行いました。AWS PrivateLink 経由で利用する場合は、AWS 側での VPC Endpoint 作成や、VBR 側での AmazonS3Regions.xml 編集など、通常のリストアとは異なる事前設定が必要です。一方で、事前設定が完了していれば、Veeam 側のリストア操作自体は通常の Restore to Amazon EC2 と大きく変わりません。ポイントは、Veeam が接続する S3 / EC2 エンドポイントを PrivateLink 側へ正しく向けることです。
閉域接続やインターネットアクセス制限が求められる環境で、Amazon EC2 へのリストアを検討する際の参考になれば幸いです。バックアップ基盤の見直しや、AWS への移行・DR 構成をご検討の際は、ぜひネットワールド営業までお問い合わせください。
