前回の記事の続きです。その1では事前準備、Oracle Cloud Migrationsから移行対象の検出、移行プロジェクトの作成までを実施したので、その2では実際にレプリケーションしてからインスタンスの移行を実施していきます！

（注：その1とその2の間に、ターゲット・アセットを変更したのでターゲットのインスタンス名が変わっていますが、設定している内容は同じです。）

1. 移行元インスタンスの確認

作成したEC2インスタンスにssh接続します。
レプリケーションが正しく行われたことを確認するために念のためテストファイルを作成しておきます。

2. レプリケーションの実行

レプリケーションを手動実行していきます。移行アセットごとに実施することもできますが、今回はプロジェクト全体でレプリケーションを実行します。また、初回実行時はサービス内部でイメージのインポートなどの作業が行われるので少し時間がかかります。

移行プロジェクトの「レプリケート」をクリックする
進行状況は作業リクエストから確認できます。
自動的にHydrationAgent_から始まる名前のインスタンスが起動してきてレプリケーションを実行しています。
HydrationインスタンスはOracle Linuxのインスタンスです。シェイプなどは自動的に決まるので指定することはできません。今回はVM.Standard.E4.Flexの1 OCPU、16GBメモリのインスタンスが一つ起動しました。また、ブート・ボリュームがブロック・ボリュームとしてアタッチされており、Hydrationインスタンスがここにデータを書き込んでいる様子が分かります。G_vol-からはじまるボリュームがレプリケーション用のボリュームのようです。
VMwareからの移行の際には指定したバケット内にスナップショットが一時的に書き込まれていましたが、今回はレプリケーション中にオブジェクトストレージのバケットに何かが書き込まれている様子は見えませんでした。オブジェクト・ストレージは経由していないのかもしれません。
- と思ったら、EC2アセットの場合はEBSボリュームから直接コピーされるのでオブジェクト・ストレージは利用しないとドキュメントにもちゃんと書いてありました。（やはりドキュメントはきちんと読もう。）
レプリケーションが完了しました。
移行アセットのページからも、レプリケーションされたボリュームの情報や最終レプリケーションの開始と完了の時刻がわかります。

レプリケーションは完了しました！

【補足】

初回レプリケーション実行時に、以下のようなエラーでレプリケーションに失敗しました。原因は、カスタムイメージのサービス制限の上限にあたっており、OCMが必要とするOCM用のカスタムイメージがインポートできずエラーになっていました。不要なイメージを削除してから再実行すれば問題なく実行できました。
実は以前VMware移行を試した際にも同じ原因で失敗したのですが、事前にカスタムイメージのサービス制限と使用量を確認しておくことを忘れていました。カスタムイメージのサービス制限がギリギリのテナンシでは注意しましょう。
OCMによって以下のようなカスタムイメージがインポートされています。これは、ブートボリューム作成用のインスタンス（Vanillaインスタンスと呼ばれる。Vanillaインスタンスはブートボリュームを生成するためだけに起動され、ボリュームを生成できたらすぐに終了される。）を起動するためだけのイメージです。

3. 移行プランの実行

続いて移行プランを実行していきます。

移行プロジェクトの中の移行プランを表示します。このままRSMスタックを生成することもできますが、デフォルトだとインスタンスにパブリックIPが付与されないので、事前にインスタンスのネットワーク設定を変更していきます。そのためにターゲット・アセットの構成を変更します。
移行プランのページ下部のリソースの「ターゲット・アセット」をクリックし、編集したい対象のターゲット・アセットにチェックを入れます。
「アクション」→「構成」をクリックします。
ターゲット・アセットの一括構成で、上書きするプロパティとして「サブネット」を選択します。ほかにも構成を変更したい場合は同様の手順で実施可能です。
正しいVCNとサブネットを選択し、「パブリックIPv4アドレスの割当て」にチェックを入れ、左下の「構成」ボタンをクリックします。
移行プランのページから「RMSスタックの作成」をクリックします。スタックが出来上がるまでしばらく待ちます。
スタックの生成が完了したので、「RMSスタックのデプロイ」をクリックします。
スタックのデプロイ状況はRMS（リソースマネージャ）のページから確認できます。
ジョブの詳細を表示するとログも確認できます。問題なく完了したようです！
コンピュートのページを確認すると、無事インスタンスができていました。

4. 移行されたインスタンスへの接続確認

コンピュートのページから移行されたインスタンスをクリックしてインスタンスの詳細を表示します。構成した通りパブリックIPアドレスが付与されているので、パブリックIPアドレスをコピーします。
ちなみに、このインスタンスのブート・ボリュームはI_vol-から始まる名前のボリュームで、レプリケーションで利用されていたG_volからクローンされたボリュームであることが分かります。
インスタンスにsshで接続していきます。ユーザー名は移行前と同じec2-userです。
無事に接続できました！あらかじめ作成していたファイルも確認できたのでレプリケーションされていることが分かります。

5. 移行の完了

インスタンスが問題なく移行できていることが確認できたら、忘れがちですが移行を完了します。

移行プロジェクトのページを表示して、「移行完了とマーク」をクリックします。

注：現時点ではレプリケーション実行時に取得されたAWS側のスナップショットは自動削除されないため、クリーンアップしたい場合は手動で削除する必要があります。

以上で、EC2からOCIコンピュートへの移行は完了です！

簡単な操作でEC2のインスタンスをOCIコンピュート・インスタンスに移行できることが確認できました。