Oracle Cloud Migration Service（OCM）の検証です。
AWS EC2(CentOS Stream9)からOCI Computeへの移行検証をします。
OCIクラウド移行ガイドとは?
オンプレミスやAWSなどからOCIへの移行プロジェクトに取り組んでいるクラウドエンジニア（@araidon,@kazunishi,@yama6,@tktk2712,@ritokuna,@nomu_kyou,@ora-777,@sshatari,@makoji,@miztana）による、OCI移行手順をまとめたシリーズ記事です
サンプルワークロードから対象サービスを取り上げ、移行手順をガイドいたします
まとめ記事は以下です
今回利用するOCMとは?
VMware仮想マシンおよびAmazon Web Services (AWS) EC2インスタンスを、
Oracle Cloud Infrastructure (OCI)コンピュートに移行するためのサービスです
OCM概要資料はこちら↓
OSのサポートってについて
仮に移行はできたとしても、CentOS Stream9がサポートされる否かで、実際に業務用途のサーバーを移すか変わってきますよね。
以下の資料に、CentOS（CentOS Streamを除く）は、リポジトリをOCI Yum Serverに変更することでOracle Linux Premier Supportを提供とあります。
つまりCentOS StreamはOCIではOSサポートはしていないとのことです。
ここからは私の所感が入りますが、CentOS Streamは最新の変更が適用される、安定版ではないため、OCIもサポートを見送ったということなのでしょうか、、
移行の流れ
前提条件の作成を実施しているものとします。
前提条件の作成方法は以下の記事をご参照ください。
また上記の記事にOCMのコンポーネントが解説されてます。
手順だけではなく、より詳しい移行イメージや構成を見たい方はご参照ください。
この記事では、以下の7STEPを踏んで移行していきます。
1 【AWS】AWSの資格情報取得
2 【AWS】移行元インスタンスの準備
3 【OCI】アセットソースの作成
4 【OCI】アセットソースで検出の実行
5 【OCI】移行プロジェクトの作成
6 【OCI】アセットのレプリケート
7 【OCI】移行検証
1 【AWS】AWSの資格情報取得
OCIからAWSに接続するための、資格情報を先に確認しておきます。
必要な情報は以下。
- アカウントID
- アクセスキーID / シークレット・アクセスキー
これらをマネジメントコンソールから確認してメモっておきましょう。
具体的な確認方法を知りたい方は以下をご確認下さい。
それ以外の方は 2 【AWS】移行元インスタンスの準備にスキップしてください。
- アカウントID
- アクセスキーID / シークレット・アクセスキー
セキュリティ認証情報をクリック。
「アクセスキー作成」をクリック
「アクセスキーの作成を続行しますか？」にチェックを入れ、アクセスキー作成をクリック
[アクセスキー]と[シークレットアクセスキー]が表示されるので、これをメモっておきましょう。
それか[.csvファイルのダウンロード]を押して、アクセスキーとシークレットアクセスキーを控えておく形でも大丈夫です。
[シークレットアクセスキー]はここでしか表示されないので、忘れずに控えておきましょう
アクセスキーID / シークレット・アクセスキーを控えたら[完了]を押して、画面を閉じてOKです。
2 【AWS】移行元インスタンスの準備
AWS環境にて、移行元となるEC2インスタンス（CentOS Stream9）を作成します。
- OS：CentOS Stream9
- AMI ID：ami-0d8ee41b4b6f8343b
- 提供元：CentOS公式 （こちら）
- インスタンスタイプ：t2.micro
インスタンス作成画面からAMI IDを検索することも可能ですが、私はCentOSの公式のHPの「Deploy link」からインスタンスを作成しました。
AMIの詳細です。
ssh接続の確認
3 【OCI】アセット・ソースの作成
アセット・ソースとはAWS環境との接続情報を扱うためのコンポーネントです。
OCIコンソールでアセットソースを作成します。
[アセット・ソース作成]を押します。
このタイミングで、「前提条件の作成」で作成した移行用のコンパートメントか確認しておきます。
間違ったコンパートメントで作成していた場合、処理の失敗などに繋がります
ここでAWSの情報も入力します。
無事に作成が出来たら、作業リクエストのステータスが成功になります。
4 【OCI】アセットソースで検出の実行
[検出の実行]ボタンを押してください。
再度、検出の実行をするかどうか問われるため、再度検出の実行を押してください。
検出自体は、1、2分くらいで終わりました。
検出が終わると、AWS環境のEC2インスタンスとアタッチされたEBSの情報が取得され、「アセット」欄に表示されます。
ちなみに、外部アセットIDがAWSのインスタンスIDやボリュームIDに該当します。
5 【OCI】移行プロジェクトの作成
移行プロジェクトとは～～～。
今回は[初期移行プランを使用して移行プロジェクトを作成します]で進めます。
基本情報の入力
- 表示名：任意の値
- コンパートメント：移行プロジェクトのリソースの配置場所
- レプリケーション・スケジュール：移行元からのデータのレプリケーションを手動実行するか、スケジュールベースで実行するか
アセットの入力
[OCMインベントリからの追加]をクリック
移行したいアセットのチェックボックスにチェックをいれ、[移行アセットの追加]を押す
ちゃんとCentOSが選択されていることを確認して、「次」に進む
レプリケーション位置の入力
レプリケーション・バケットを指定し、移行アセットを指定済みにして、[次]に進む
初期移行プラン
確認および作成
入力内容をサクッと確認して[作成]ボタンを押す。
無事にすべての内容が作成できたら[閉じる]ボタンでOK。
移行プロジェクト詳細のページでも、移行プランがアクティブになっているのが確認できます！
6 【OCI】アセットのレプリケート
そのままの画面で、レプリケートを実施します。
この作業は約３０分程、かかりました
完了すると、作業リクエストで完了率が100%になっているのが確認できます。
この作業で作成される一時的なリソースについても、触れていきたいと思います。
コンピュート一覧を確認すると２つ、今回のタイミングで作成されたのが確認できます。
役割としては以下です。
- HydrationAgent：EBS Direct APIを実行し、ブートボリュームにEBSからデータを書き込むインスタンス
- vanilla-instance：ブートボリュームを生成するためだけに起動され、ボリュームを生成できたらすぐに終了されるインスタンス
ちなみにブート・ボリュームも一覧確認すると、今回のタイミングで作成されたものがわかります。
G-から始まるボリュームに関して、ゴールデン・ボリュームと呼ばれるもので、このあと生成するCompute VM（EC2から移行するCentOS Stream9）のブート・ボリュームになります。
7 【OCI】移行検証
移行プロジェクト内にある、移行プランを選択。
ターゲット・アセットから、アクションより構成を選択。
構成は非活性にならない場合は、ターゲットアセットを選択して、アクションボタンを教えてください。
デプロイ先のVCN、サブネットをここで設定します。
RMSスタックの作成
無事に作成ができると、RMSスタックの欄に、スタックが表示されます。
RMSスタックのデプロイを実施します。
このデプロイが完了すると、EC2からの移行が完了します。
実際にコンピュートを見てみると、該当のEC2がありました。
CloudShellにpemファイルをアップロードして、接続します。
ユーザは “opc”ではなく、”ec2-user”です。
接続できました！！！
移行するまでに複数のSTEPを踏むため、わかりにくい部分は有ります。
とはいえ、今までこのような移行ツールがなかったため、インスタンス数が多いなどの条件によっては、検討の余地があるのかなと思いました。
以上