Go to Qiita Advent Calendar 2024 Top
LoginSignup
13
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Oracle Cloud Infrastructure Advent Calendar 2022

Day 4
@tkonishi

Oracle Cloud MigrationsサービスでVMwareからOCIに移行してみる

Last updated at Posted at 2022-12-03

2022年9月にOCIでOracle Cloud Migrationsサービスがリリースされました。
Oracle Cloud Migrationsは、Oracle Cloud Infrastructureに移行を行うためのOCIネイティブのサービスです。これまでOCIネイティブの移行サービスはなかったので、ついに登場したという感じです！

このOracle Cloud Migrations サービスでは、オンプレミスなどに存在するVMware環境の仮想マシンをOCIのコンピュート・インスタンスに移行できます。

image-20221021204242276.png

概要資料をspeakerdeckにアップしているので資料として読みたい方はこちらもどうぞ。
Oracle Cloud Migrationsサービス概要

ということで、さっそく試してみたいと思います。

私はオンプレミスのVMware環境を持っていないので、今回はOCI上のOCVS（Oracle Cloud VMware Solutions）のSDDC内に存在する仮想マシンをOCIのコンピュート・インスタンスに移行していきたいと思います。

ではやっていきましょう！

概要と手順の全体感

まずマニュアルを見てみましょう。目次を見るだけでも非常にボリュームが多そうに見えます。。

残念ながら現時点では日本語翻訳はされていません（2022年10月現在）。頑張って英語で読んでいきます。

作業を始める前にいくつかの用語とコンポーネントは抑えておくと理解がスムーズになりそうですので、ご紹介しておきます。

アーキテクチャの概略図を書いてみるとこんな感じです。
image-20221115181448587.png

リモート・エージェント・アプライアンス

  • 移行元のVMware上にデプロイする仮想アプライアンス。OVA形式で提供される。（OCIコンソールからダウンロード）
  • ディスカバリーやレプリケーションのためのプラグインが動作。OCI側のサービスやvCenterに通信を行う。

ハイドレーション・エージェント

  • 一時的なコンピュート・インスタンス。ソースデータをターゲットのボリュームに書き込む

インベントリ

  • 発見された仮想マシンなどのアセット情報などのメタデータを保存するリポジトリ

アセットとプラン

  • インベントリ内の分析、ディスカバリやインポートの状態や履歴の管理を行う。

移行プロジェクト

  • 移行プランやレプリケーションを管理するRootフォルダのようなもの。

移行プラン

  • 移行プロジェクト配下で同時に移行する仮想マシンをグループ化する。例：テスト用プランと本番用プラン
  • 移行プランの定義に従ってリソースを作成するためのリソース・マネージャのスタックが作成できる。

ディスカバリ（検出）

  • オンプレミスのVMware APIに接続して仮想マシンの情報を収集し、インベントリに保存する。

レプリケーション

  • スナップショット・レプリケーション。フル・イメージもしくは増分の仮想マシンスナップショット
  • スケジュール実行も可能

おおまかなステップのチャートはマニュアルにもあるのですが、この絵だけだと具体的な手順との紐づけがやや難しいです。
ocm-workflow.png

「Using the Oracle Cloud Migrations Service」に書いてある手順が具体的な流れを表していますので、次のステップが何かがわからなくなったらここに立ち戻るとよいと思います。

環境や要件によっては作業の順番は前後するかもしれません。

ステップが多いのですが、この記事ではボリュームによって以下の項目に分けて記載していきたいと思います。

0.事前準備
1.ソース環境の作成
2.リモート・エージェント・アプライアンスのデプロイ
3.検出の実行
4.移行

0. 事前準備

OCI側の準備

事前にOCI上で作成しておく必要のあるリソースが色々あります。マニュアルに沿って準備していきます。

  • （当たり前ですが）テナンシ
  • コンパートメント
    • 移行先のコンパートメントや、移行で一時的に使うコンパートメントを用意します。今回は両方同じコンパートメントを使いました。
  • ユーザ、グループ
    • Oracle Cloud Migrations Serviceの操作をするユーザとグループを用意します。
  • 動的グループ、ポリシー
    • ポリシーリファレンスはこちら になりますが、具体的に設定すべきポリシーは、以下の2つのページに記載されています。これらのポリシーを確実にすべて設定していきます。ユーザに対するポリシーだけでなく、サービスや動的グループに対するポリシー設定も必要ですので、たとえAdministratorsグループ所属の管理者ユーザで操作する場合でも後者は設定が必要です。
    • 非常に量が多いですが、サンプルをコピーして対象のグループ、動的グループ、コンパートメントの名前を適切に修正すればOKです。ここでミスるとエラーになる可能性がありますので、何か問題があった場合はきちんとすべてのポリシーが設定されているかを見直しましょう。
    • 動的グループはいくつかの種類に分かれていますが、一つにまとめてしまってもOKです。
  • オブジェクト・ストレージのバケット
    • スナップショットのレプリケーションで使われます。
  • ボールト
    • vCenterのパスワードをシークレットとして保存するために使われます。
  • 移行先のVCNやサブネットも事前作成が必要です。

VMware側の準備

VMware側では、これから作成するAgentとOCI間のネットワークの準備、また、VMwareのVirtual Disk Development Kit (VDDK)のダウンロードが必要です。

  • リモート・エージェント・アプライアンスの要件
    • マニュアルにリモート・エージェント・アプライアンスの要件がありますのでこれらを確実に満たす必要があります。設定の仕方は既存環境のネットワーク構成に依存します。
    • DNSによる名前解決が必須
      • oraclecloud.comドメインの名前解決と、vCenter serverやESXiホストのFQDNを名前解決できる必要がある。
    • ネットワーク要件
      • External Network（Oracle Cloud Migrations Serviceと通信するためのネットワーク）、Internal Network（vCenterと通信するためのネットワーク）
      • それぞれ、空けるべきポートが記載されているのでそれに従って通信できる状態にしておく。
    • vCenterの権限
      • 今回はAdministratorユーザで操作たので特に設定しませんでしたが、権限を絞りたいような場合はマニュアルに沿って準備してください。
  • エージェント依存性
    • こちらに記載されている通り、エージェントにプリインストールされていないライブラリ（Virtual Disk Development Kit (VDDK)）をVMwareのサイトからダウンロードする必要があります。VMware Customer Connectのユーザ・アカウントが必要です。
  • 仮想マシンの増分スナップショットをとるためにはChange Block Trackingを有効化（デフォルトoff）

1. ソース環境の作成

事前準備ができたらコンソールからの構築作業に入っていきます。一番初めにOracle Cloud Migrationsサービスを利用する際にのみ、インベントリの作成を行います。この部分の画面ショットを保存し忘れていましたが、単純にインベントリの作成というボタンをクリックするだけでした。マニュアルはこちら

インベントリが作成できたら、まずはソース環境の作成です。

  1. コンソールのメニューから、クラウド移行→リモート接続→Source Environment のページで「ソース環境の作成」をクリックします。
    image-20221115143050394.png

  2. 好きな名前を入力して「ソース環境の作成」ボタンをクリックします。
    image-20221115143146153.png

  3. ソース環境が作成できました。
    image-20221115143902095.png

ここまでは特に問題はなくスムーズです。

2. リモート・エージェント・アプライアンスのデプロイ

続いて、VMware環境にリモート・エージェント・アプライアンスをデプロイし、ソース環境に登録します。

  1. ソース環境のページから「Download agent VM」をクリック
    image-20221115144236560.png

  2. 「ダウンロード」ボタンをクリックしてエージェントVMのOVAファイルをダウンロード。
    image-20221115144325733.png

  3. vCenterにログインし「OVFテンプレートのデプロイ」
    image-20221115144514959.png

  4. テンプレートに沿って必要な項目を入力していきます。環境によって入力項目は異なりますので、必要に応じて選択していってください。（ただし、私ははまった点があるのでこれは後述します。）
    image-20221115144608984.png
    image-20221115144642584.png
    image-20221115144710664.png
    image-20221115144731325.png
    image-20221115144800340.png
    image-20221115144819845.png
    image-20221115144846745.png
    image-20221115144911906.png

  5. デプロイできたら、仮想マシンを起動します。
    image-20221115145008461.png

  6. vCenterから起動した仮想マシンのREMOTE CONSOLEを起動し、IPアドレスを確認
    image-20221115165859557.png

  7. 仮想マシンのネットワークにアクセス可能なブラウザから https://<リモート・エージェントのIPアドレス>:3000/ を開く。エージェントの表示名を入力し、リージョンを選択して「Register」ボタンをクリック。
    image-20221115170013171.png

  8. 自動的にOCIテナンシのコンソール画面に遷移します。先ほど作成したソース環境の名前を選択して、「Register agent」ボタンをクリック。確認ウィンドウでも「Register agent」をクリック。
    image-20221115170323101.png
    image-20221115170352589.png

  9. リモートエージェントの登録が完了
    image-20221115170517675.png

  10. コンソールのソース環境のページを表示すると、エージェントが登録されていることが分かります。依存関係の追加をするようにと注意書きが書いてあるので、このあとで依存関係ファイルを追加します。
    image-20221115170702803.png

  11. 数分待ち、エージェントとOCIの通信が正しくできれいれば、エージェントのHeartBeatがアクティブになります。ここでHeartBeatやAgentHealthMonitoring, Discoveryの状態がアクティブではない場合は通信に何らかの問題がある、あるいは権限設定が足りない可能性があります。DNS設定やExternal Networkの設定、また、IAMポリシーの設定を見直しましょう。
    image-20221115170827821.png

  12. レプリケーションを行うためのエージェント依存関係ファイルをダウンロードします。VMware Customer Connectにログインし、ファイルをダウンロードします。
    image-20221115171025490.png
    image-20221115171123755.png

  13. ソース環境のページのエージェント依存関係の作成から、ダウンロードしたファイルをアップロードします。アップロードするオブジェクトストレージのバケットを指定します。
    image-20221115171339841.png

  14. このようにソース環境のエージェント依存関係がアクティブになれば登録は完了です。
    image-20221115171446611.png

OCVSのSDDCでのエージェント構成時の注意点

今回OCVS上にエージェントを構築したのですが、ネットワーク構成についていくつかはまった点があったので記載しておきます。これらは既存環境次第なので、既存のVMware環境のネットワーク構成に応じて検討する必要があります。

  • DNSによる名前解決
    • エージェントからcloud.oracle.comのドメインや、vCenterのFQDNを名前解決できるようにしなくてはいけない。
    • 今回は、VCN内のデフォルトDNSにリスニング・エンドポイントを作成し仮想マシンのセグメントから参照できるようにしておいて、エージェントのデプロイ時にDNSサーバとしてリスニング・エンドポイントのIPを指定した。
  • vCenterへの接続ネットワーク（Internal Network）
    • エージェントのデプロイ時にはInternal NetworkとExternal Networkのネットワークはそれぞれ指定ができるのですが、Internal NetworkについてはIPアドレスを設定する項目がありません。つまりDHCPでIP取得しなくてはなりません。ただし、vCenterが存在するvShepre VLANはDHCPでIPアドレスが取得できなかったので、単純にvSphere VLANを指定してもvCenterへの通信はできませんでした。（External NetworkについてはIPアドレス指定など可能。）
    • 回避策として、以下の二点を行ってworkloadセグメントからvCenterへの通信を行いました。
      • External Networkにはworkloadセグメントを指定し、デプロイ時にはInternal用にも同じworkloadセグメントを指定しておいて、仮想マシン起動前に仮想マシンの設定でInternalのNICを無効化することで、エージェントが使用するネットワークをExternal Networkのみに限定した。
      • vSphere VLANのルート表にworkloadセグメントに向けてはNSX Edgeへ向かうようにという戻りのルートを追加した。

3. 検出の実行

ここまででソース環境とエージェントの登録ができたので、アセット・ソース（仮想マシン）の検出をしていきます。

image-20221115181805700.png

  1. アセット・ソースの作成をクリックし、必要事項を入力していきます。

    • vCenterエンドポイントのURLは通常、 https://＜vCenterのFQDN＞:sdk になります。（IPアドレスではなくFQDNで名前解決する必要があります。）
    • 資格証明ではあらかじめ作成しておいたボールトを選択し、vCenterユーザ名とパスワードを格納します。
      image-20221115172246357.png

  2. アセット・ソースが作成できるとこのように完了と表示されます。
    image-20221115172540989.png

  3. しばらく待つと、コネクタの接続ステータスが変わります。検出とレプリケーションが両方アクティブになっていればアセットソースの作成は成功です。
    image-20221115172901760.png

  4. もし、何らかの理由でエージェントからvCenterへの通信ができていないような場合にはこのようなエラーになります。DNSやネットワークの設定などを見直しましょう。
    image-20221115172744026.png

  5. ただしく接続ができていることが確認出来たら、アセットソースの「リフレッシュ」を行ってアセットの検出を行います。
    image-20221115173226329.png

  6. しばらく待つと検出が実行され、「アセット」に仮想マシンの一覧が表示されます。
    image-20221115181127238.png

  7. 検出されたアセットの情報は「インベントリ」に格納されています。メニューの「クラウド移行」→「インベントリ」→「インベントリ・アセット」を表示すると一覧や検索、詳細の表示ができます。
    image-20221115181911759.png
    image-20221115182010662.png

ここまで無事に完了すれば、あとはOCIコンソールからのポチポチ作業だけです！

4. 移行

移行する際には、移行プロジェクトを作成し、その中に移行アセットと移行プランを作成します。それぞれの関係性はこのような形です。

  • 移行プランは1つの移行プロジェクトの中に複数作成できます。
  • 1つの移行プロジェクトの中に複数のアセットを登録できます。1つのアセットは複数の移行プロジェクトには所属できません。
    image-20221115181542870.png

ということで、さっそく作っていきます。

  1. メニュー→クラウド移行→移行プロジェクトで、「移行プロジェクトの作成」をクリックします。
    image-20221115182312636.png

  2. 移行プランや移行アセットも同時にまとめて作るか、移行プロジェクトだけを作成するかが選べます。今回はまず移行プロジェクトだけを作成しました。（後から思えば、今回はテスト目的ですし、初期移行プランを使用してすべて一気に作ったほうが簡単だったなと思いました。）
    image-20221115182413335.png

  3. 移行プロジェクトの名前を付けるだけです。
    image-20221115182528729.png

  4. 移行プロジェクトができました。
    image-20221115182556782.png

  5. 続けて、「移行プランの作成」ボタンをクリックして移行プランを作成していきます。

    • 移行の戦略を決めることができます。今回はデフォルトの現状維持を選択しました。
      • リソースタイプ：デフォルト/CPU/メモリー
      • 戦略タイプ：現状維持/平均/ピーク/パーセンタイル
    • ターゲット環境のシェイプも選択可能です。優先シェイプ・タイプの選択を選択すると、好きなシェイプ・タイプを選ぶことができます。
    • また、VMインスタンスを配置するVCNのサブネットを指定します。

image-20221115182932731.png

  1. 移行プランが作成できました。ただし、まだ対象のターゲット・アセットがないので、金額の見積もりや互換性チェックなどができません。先にアセットを登録しておけばよかったかもしれません。
    image-20221115183408437.png

  2. ということで、続いて移行アセットを登録していきます。移行アセットは移行プロジェクトに登録します。移行プロジェクトのページから「移行アセットの追加」をクリックします。
    image-20221115183548966.png

  3. 「OCMインベントリからの追加」をクリックします。
    image-20221115185449477.png

  4. 追加したい対象のアセットにチェックを入れて、「移行アセットの追加」をクリックします。
    image-20221115185550408.png

  5. 続いて、レプリケーションで利用するオブジェクト・ストレージのバケットを指定し、「送信」をクリックします。
    image-20221115185654719.png

  6. アセットが登録できると、移行プランのページからもアセットの互換性や推定コストが算出できるようになりました。
    image-20221115185859926.png

  7. 続いて、レプリケーションを行います。レプリケーションはスケジュール実行もできますが、ここでは手動でまずレプリケーションしてみます。移行プロジェクトのページから「レプリケート」ボタンをクリックします。作業リクエストのページを見れば進捗状況がわかります。
    image-20221115190129224.png

  8. これで仮想マシンのスナップショットのレプリケーションができました。続いて、インスタンスを作成するためのリソース・マネージャ・スタックを作成します。RMSスタックは、移行プランで設定した戦略に基づいて生成されるため、移行プランのページから作成します。
    image-20221115190247551.png

  9. スタックが作成できたら、「RMSスタックのデプロイ」をクリックします。
    image-20221115190504128.png

  10. リソース・マネージャの進行状況やログはリソース・マネージャのページから確認できます。
    image-20221115190610885.png

  11. 完了したら、コンピュートのページから確認してみます。インスタンスが作成できていました！
    また、対象のインスタンス以外に、HydrationAgentというインスタンスも自動的に起動しています。これはレプリケーションを実行する一時インスタンスです。しばらくすると自動的に終了されました。
    image-20221115190648366.png

  12. インスタンスにsshで接続しようとしたらつながらなかったので、コンソール接続を使って直接VMインスタンスにログインしてみました。OSは起動していますが、どうやらIPアドレスが取得できていないようです。ネットワークデバイス名がVMware上での名前と変わってeth0になっていたのですが、/etc/sysconfig/network-scripts/にはifcfg-eth0ファイルがないので、手動でファイルを作ってあげたらIPがとれて接続できるようになりました。
    image-20221115190916954.png

    [root@tkvm3 network-scripts]# cat ifcfg-eth0
    NAME="eth0"
    DEVICE="eth0"
    ONBOOT=yes
    NETBOOT=yes
    BOOTPROTO=dhcp
    TYPE=Ethernet
    [root@tkvm3 network-scripts]# 
    [root@tkvm3 network-scripts]# ifconfig
    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
            inet 10.0.1.186  netmask 255.255.255.0  broadcast 10.0.1.255
            inet6 fe80::17ff:fe00:2551  prefixlen 64  scopeid 0x20<link>
            ether 02:00:17:00:25:51  txqueuelen 1000  (Ethernet)
            RX packets 55  bytes 4649 (4.5 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 26  bytes 2596 (2.5 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    [root@tkvm3 network-scripts]# 

    [opc@bastion ~]$ ssh root@10.0.1.186
    The authenticity of host '10.0.1.186 (10.0.1.186)' can't be established.
    ECDSA key fingerprint is SHA256:SAZr0w5h7a87okFdrQ0H1SWEFQRE1rdo10FQsGUdUkI.
    ECDSA key fingerprint is MD5:45:95:cb:13:d6:b7:05:ae:79:ad:7a:98:cb:58:8c:2f.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '10.0.1.186' (ECDSA) to the list of known hosts.
    root@10.0.1.186's password:
    Last login: Mon Oct 24 19:59:49 2022
    [root@tkvm3 ~]#

以上で、仮想マシンの移行は完了です！！！

実は途中でネットワーク設定などでエラーになってしまったりしてVMware環境の設定を見直しながら何度かやり直したりしていたので、道のりは長かったです。構築する際には面倒くさがらずにあらかじめ要件をしっかり確認して、事前準備をしておくことが大切だなとあらためて実感しました。

後半の移行の部分については、これ以外にも例えば自動検出されたシェイプからカスタマイズすることなどもできるのでご紹介したかったのですが、あまりに長くなってきたのでここでいったんこの記事は終了します。

皆様もぜひ既存のVMware環境があれば試してみてはいかがでしょうか？

13
3
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
13
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?