Go to Qiita Advent Calendar 2024 Top
LoginSignup
16
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tkonishi

AWS EC2からOCIコンピュートに移行してみる - その1（Oracle Cloud Migrations）

Last updated at Posted at 2024-10-24

OCIのOracle Cloud Migrations（クラウド移行サービス）はVMware上の仮想マシンをOCIの仮想マシンに移行することが可能なサービスとして2022年9月にリリースされました。VMwareからの移行を試してみた記事はこちら(実施時点の情報となり最新情報とは異なる部分もありますのでご注意ください)。

このOracle Cloud Migrationsが、先日、AWS EC2からの移行にも対応しました！これによって、VMwareとAWS EC2という2つのソース環境に対応しました。

さっそくですが、AWS EC2のインスタンスをOCIのコンピュートのVMインスタンスに移行してみたいと思います！

以前VMwareからの移行を試した際には事前準備や構築に工数がかかった記憶もあるので、まずはドキュメントをざっと読んで流れを把握しておきます。

おおまかな流れはこちらが参考になります。

VMwareからの移行の場合はエージェントになるアプライアンスをVMware上に構築する必要がありましたが、AWS EC2の場合はエージェントレスで動作できるようです！

比較してみるとわかりますが、「アセットの管理」の部分のステップが大幅に削減されていて、最初からアセット・ソースの作成をスタートできるようです。とはいえ要件の確認や準備は必要なので、実施する際にはしっかりとドキュメントを確認しながら進めていきましょう。

0. 事前準備

移行元と移行先の準備をしていきます。

AWSアカウントを準備

移行元のAWSのアカウントを用意します。この記事ではAWSアカウントの作成については省略します。

OCI コンパートメントやIAMポリシーの設定、ボールトの準備

「前提条件の作成」の機能でterraformによって自動的にコンパートメントやタグ、ポリシーの作成を行わせることも可能ですが、今回は私は各ポリシーの内容なども確認しながら進めたかったこともあったので手動で設定していきました。

ただし、「前提条件の作成」を利用したほうが作業としては簡単で抜け漏れがないのでお勧めです。その場合は以下のドキュメントに従って実施してください。

image-20241024095254878.png

手動で構成する場合は、

  • 以下2ページに記載されているポリシーをすべて適切に設定します。かなり量が多いので、抜け漏れがないように注意します。

  • 資格証明を保管するために必要なボールトはあらかじめ作成しておきます。

  • レプリケーションに使用するオブジェクト・ストレージのバケットはあらかじめ作成しておきます。

  • 移行先のインスタンスを配置するVCNやサブネットも用意しておきましょう。

1. 移行元インスタンスの準備

AWS側でEC2のインスタンスを用意します。私はAWSの操作には不慣れなのでやや心配でしたが、デフォルトの構成ですぐに作成することができました！

本記事ではEC2作成手順は割愛しますが、今回は無償で利用できると書かれていた、バージニア北部(us-east-1)リージョンのt2.microのインスタンスタイプ、Red Hat Enterprise LinuxのAMIを利用してみました。インターネットからsshでログインできるようにパブリック・サブネットに配置してグローバルIPも振っておきます。

そのほか、Oracle Cloud Migrationsでサポートされている移行元環境については以下のドキュメントを参照してください。

2. アセット・ソースを作成する

それではさっそく、OCIコンソールから移行元となるアセット・ソースを作成していきます。

  1. OCIコンソールのメニュー「移行とディザスタ・リカバリ」→「クラウド移行」をクリックします。
    image-20241024102244262.png
  2. 左側のメニューから「検出」をクリックします。
    image-20241024102446303.png
  3. アセット・ソースの画面で「アセット・ソースの作成」をクリックします。（初回実行時はインベントリの作成のため少し時間がかかるかもしれません。）
    image-20241024102559807.png
  4. アセットソースの作成画面で以下を入力し、「アセット・ソースの作成」をクリックします。
    1. アセット・ソース・タイプ：AWS
    2. アセットソース情報
      • 名前：任意の名前。
      • アカウントID：0.事前準備で用意しておいたAWSのアカウントIDを入力します。
      • リージョン：AWSの移行元となるインスタンスが存在するリージョンを指定します。ここではus-east-1です。
      • コンパートメント：アセット・ソースを作成するコンパートメントを指定します。
      • ターゲット・コンパートメント：ターゲットのリソースを作成するコンパートメントを指定します。image-20241024103020667.png
      • リモート接続ソース環境：「新規作成」を選択し、任意の名前を入力します。
        image-20241024103300896.png
      • 検出資格証明：「シークレットの作成」を選択し、以下の項目を入力していきます。
        • 名前：任意の名前
        • 説明：任意
        • コンパートメント：資格証明のボールト用のコンパートメント
        • <コンパートメント名>のボールト：あらかじめ用意してあるボールトを選択します。
        • <コンパートメント名>のマスター暗号化キー：あらかじめ対象のボールト用に用意してあるマスター暗号化キーを選択します。
        • アクセス・キーID：以下に示す手順で取得したアクセス・キーを入力します。
        • シークレット・アクセスキー：以下に示す手順で取得したシークレット・アクセスキーを入力します。image-20241024103515713.png
        • アクセス・キーの取得方法
          1. AWSのポータルから、「セキュリティ認証情報」を開きます。
            image-20241024104004786.png
          2. 「アクセスキーの作成」をクリックします。
            image-20241024104042071.png
          3. ルートユーザーでアクセスキーを作成することは推奨されていません。今回はこのテスト目的のインスタンスのみの環境で重要なデータなどは存在していないので続行します。image-20241024104115963.png
          4. アクセスキーとシークレットアクセスキーが取得できます。これをコピーしてさきほどの入力項目に入力します。image-20241024104230883.png
        • 注）通常ルートユーザーのアクセスキー利用は推奨されていません。実際の環境では適切な権限を持ったユーザーを用意するなどしてください。OCMの各ステップ実行に必要なAWS IAMの権限は以下のドキュメントに記載されていますので参照して適切に設定してください。
      • レプリケーション資格証明オプション：先ほど検出で作成した資格証明と同じものを使っていきますので、「検出資格証明の使用」を選択します。
      • 検出スケジュール：今回はスケジュール実行は無しでのちほど手動で検出を行いますので、「検出スケジュールなし」を選択します。
        image-20241024105531261.png
    3. すべて完了したら左下の「閉じる」をクリックします。
      image-20241024105816457.png
    4. アセット・ソースが作成はすぐに完了しました！
      image-20241024110004506.png

3. アセットを検出する

続いて、アセット（移行対象にできるリソース）を検出していきます。

  1. アセット・ソースのページから「検出の実行」をクリックします。
    image-20241024125434220.png
  2. 検出の実行にはしばらく時間がかかります。完了するまでしばらく待ちます。
    image-20241024125524554.png
  3. 検出が完了すると、リソースの「アセット」に検出されたアセットが表示されます。今回あらかじめ作成しておいた仮想マシンとボリュームが一つずつ検出されたので成功です。
    image-20241024125704902.png

4. 移行プロジェクトの作成

続いて移行プロジェクトを作成します。

  1. OCIコンソールのメニューから「クラウド移行」→「移行プロジェクト」のページを開き、「移行プロジェクトの作成」をクリックします。
    image-20241024125942343.png

  2. 今回は初期移行プランも含めて一気に作成していきますので、「初期移行プランを使用して移行プロジェクトを作成します」を選択して作成していきます。
    image-20241024130019288.png

  3. 移行プロジェクトの作成画面の基本情報に以下の情報を入力して次に進みます。

    • 移行情報
      • 表示名：任意の名前
      • コンパートメント：対象のコンパートメント
    • レプリケーション・スケジュール：今回はスケジュール実行ではなく手動実行していくので「レプリケーション・スケジュールはありません」を選択します。image-20241024130147801.png

  4. 続いて、アセットの画面で「OCMインベントリからの追加」をクリックします。
    image-20241024130406841.png

  5. アセットを選択します。この環境には他のアセットも表示されてしまっていますが、検索で絞り込むことも可能です。
    image-20241024130442073.png

  6. assetTypeでAWS_EC2を検索すると対象はひとつだけ表示されました。このインスタンスを選択して「移行アセットの追加」をクリックし、次に進みます。
    image-20241024130542592.png

  7. レプリケーション位置として、オブジェクトストレージのバケットを選択します。あらかじめ用意しておいたバケットを選択し、選択済みの状態にして次に進みます。
    image-20241024130726101.png

  8. 続いて初期移行プランも設定します。以下の情報を入力して次に進みます。

    • 初期移行プラン
      • 表示名：任意の名前
      • コンパートメント：対象のコンパートメント
      • 戦略：ここでは移行先のサイジングに関する戦略を決めることができます。今回はリソース・タイプは「デフォルト」のままで、戦略タイプは「現状維持」を選択しました。image-20241024130829633.png
    • ターゲット環境
      • 環境タイプ：「システム推奨」の使用を選択しました。特定のシェイプの希望があれば選択することもできます。
      • VCN：移行先のインスタンスを配置するVCNを選択します。
      • サブネット：移行先のインスタンスを配置するサブネットを選択します。
      • 専用仮想マシン・ホスト：今回は特に使用しないので選択しません。image-20241024131217620.png

  9. 確認画面が表示されたら、左下の「送信」ボタンをクリックします。
    image-20241024131405924.png

    image-20241024131428598-1729743269472-1.png

  10. 移行プランや移行アセットを含んだ移行プロジェクトが完成しました！
    image-20241024131509392.png

さて、ここまででアセット・ソースや移行プロジェクトなどの設定が完了しました。ここからが最も気になる実際の移行作業の部分に入りますが、記事が長くなってきたので今日はいったんここまでにしたいと思います。

次の記事で、レプリケーションとインスタンスの移行を試していきます！

16
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
16
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?