AcronisCyberCloudを利用して、EC2に物理マシンをP2Vしてみた

はじめに

最近はAmazonConnectに触れる機会が多い、ソリューション課の谷口です。
オンプレからの移行も数多く対応させて頂いておりますので、その際に取った手法を紹介させて頂きます。

物理マシンをAWS環境にP2Vするケースがありましたので、その際にCloudEndureを利用したが100%状態でStuckに陥って解決の目途が経たなかったのでAcronisを使ってみました。
ちなみにStuckのナレッジ自体はAWSから出ております。（参考まで
https://aws.amazon.com/jp/premiumsupport/knowledge-center/cloudendure-replication-process-stuck/

Acronis Cyber Cloudとは

バックアップ製品として有名なAcronisが提供しております、
クラウドにイメージバックアップ等が取る事が出来るサービスでございます。
弊社では、あんしんクラウドバックアップという名前でご提供しております。
台数に関係なくバックアップ容量に応じた課金となっており、導入しやすい製品となっています。

P2Vまでの流れ

物理マシンにバックアップエージェントをインストールし、バックアップを行います。
これをAWS上に復元出来れば問題ないのですが、ドライバ周りなどその辺りの関係でAWS上に
復元しても正常に起動がしません。
※復元用のブータブルメディアがあるのですが、AWSだとコンソールを使ってメディア起動みたいなのが出来ないので今回はこちらの手が取れません。

今回は、直接AWSに復元するのではなく一旦VMWare上に展開しOVAとしてエクスポートを行い、AWSのVMインポートを使って展開まで持っていこうかと思います。

ですので、流れは以下となります。
１．物理マシンにバックアップエージェントをインストール
２．物理マシンのフルバックアップを取得
３．VMWare上に仮想マシンを作成し、バックアップエージェントをインストール
４．Acronis上のコンパネから復元先を指定して復元を実施
５．VMWare上で復元を確認し、OVAへエクスポート実施
６．VMインポート用のロール・ポリシー作成
７．S3にOVAファイルをアップロード
８．VMインポート実施
９．作成されたAMIからEC2を作成

物理マシンにバックアップエージェントをインストール

Acronisのコンパネからバックアップエージェント用のセットアップファイルをDLします。
ダウンロードしたセットアップファイルを対象マシンでインストールします。

インストールを行うとAcronis側でデバイス登録を行い、バックアップが出来る状態となります。

物理マシンのフルバックアップを取得

Acronisの管理画面上からバックアップを実施します。
※帯域制限は行えないので、対象環境のトラフィック等にご注意ください。

VMWare上に仮想マシンを作成し、バックアップエージェントをインストール

VMWareにて仮想マシンを作成し、先程と同様にエージェントをインストールします。

Acronis上のコンパネから復元先を指定して復元を実施

コンパネ上から物理マシンのバックアップから復元を選択します。
復元先をVMWare上で作成した仮想マシンをターゲットとして指定します。

復元先は、「物理マシン」となります。
※仮想マシンが選択可能ですが、これはVMWareのESXiに対して行う動きとなります。今回はこちらは利用しませんので、物理マシンを選択します。

ターゲットマシンは、「VMWare上で作成したマシン」になります。
※こちらは対象マシンを間違わないようにご注意ください。

VMWare上で復元を確認し、OVAへエクスポート実施

VMWare上で復元したマシンが正常に起動する事を確認します。
起動が問題なければ、一旦サーバを停止します。
CDドライブ等はVMWare上の設定から削除しておいてください。
こちらはAWS側に要件が記載されておりますので、そちらをご確認下さい。
https://docs.aws.amazon.com/ja_jp/vm-import/latest/userguide/vmie_prereqs.html

VMインポート用のロール・ポリシー作成

VMインポートはAWS CLIからのみ実行可能となります。
VMインポート用にロールとポリシーの作成が必要となります。

ロール作成（trust-policy.json）

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Principal": { "Service": "vmie.amazonaws.com" },
         "Action": "sts:AssumeRole",
         "Condition": {
            "StringEquals":{
               "sts:Externalid": "vmimport"
            }
         }
      }
   ]
}

AWS CLIにてロール作成

aws iam create-role --role-name vmimport --assume-role-policy-document file://E:\import\trust-policy.json

ポリシー作成（role-policy.json）

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "s3:ListBucket",
            "s3:GetBucketLocation"
         ],
         "Resource": [
            "arn:aws:s3:::OVAファイルアップロード先のバケット名"
         ]
      },
      {
         "Effect": "Allow",
         "Action": [
            "s3:GetObject"
         ],
         "Resource": [
            "arn:aws:s3:::OVAファイルアップロード先のバケット名/*"
         ]
      },
      {
         "Effect": "Allow",
         "Action":[
            "ec2:ModifySnapshotAttribute",
            "ec2:CopySnapshot",
            "ec2:RegisterImage",
            "ec2:Describe*"
         ],
         "Resource": "*"
      }
   ]
}

※OVAファイルアップロード先のバケット名は、利用するバケット名をご指定下さい。

AWS CLIにて実行

aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://E:\import\role-policy.json

S3にOVAファイルをアップロード

OVAファイルのアップロード

aws s3 cp E:\import\XXXXXX.ova s3://アップロード先のバケット名/

VMインポート実施

OVAファイルのインポート用ファイル作成（containers.json）

[
  {
    "Description": "VM Import",
    "Format": "ova",
    "UserBucket": {
      "S3Bucket": "アップロード先のバケット名",
      "S3Key": "XXXXXXXX.ova"
    }
  }
]

インポート実施

aws ec2 import-image --description "VM Import" --disk-containers file://E:\import\containers.json

インポートを実施すると基本的に権限等が問題なければ上記コマンドで動作しますが、
「AWS CLI」を実行しているユーザ権限を接続元IP制限をしているとエラーになる事がございます。
私自身が発生した際のエラーとしては、以下のようなパターンがございました。

ポリシーのバケット名が間違えている場合
client error disk validation failed access to the given resource

AWS CLIを実行しているユーザの権限問題
AWS Import-image User does not have access to the S3 object

インポート実施後のステータスは以下コマンドで確認が可能です。

aws ec2 describe-import-image-tasks --import-task-ids import-ami-XXXXXXXX

import-amiは、インポート実施出てきますので控えておいてください。
次のようなステータス値が返ってきます。

active— インポートタスクは進行中です。
deleting— インポートタスクはキャンセルされています。
deleted— インポートタスクはキャンセルされました。
updating— インポートのステータスを更新しています。
validating— インポートしたイメージを検証中です。
validated— インポートしたイメージが検証されました。
converting— インポートしたイメージを AMI に変換しています。
completed— インポートタスクは完了し、AMI はすぐに使用できます。

作成されたAMIからEC2を作成

正常に作業が完了するとAMIが作成されていますので、AMIを利用してEC2を作成します。
正常にログイン出来る事を確認して作業完了となります。

おわりに

移行用ツール自体は色々と出ておりますが、ダウンタイムや切替までの時間等によって利用するツールはご選択頂ければと思います。
今回は結構変則的なP2Vを行っておりますので、問題などがなければCloudEndure等が自動的にAWS側でよしなに変換してくれるのでP2Vするうえでは簡単だと思われますが、色々な部分で費用が発生したりもしますのでその辺は事前にご確認の上、ご利用頂ければと思います。

谷口直明