はじめに

VMware Cloud on AWS では、オンプレミスのワークロード (仮想マシンで構成されるシステム) を非常に容易に移行させることが可能です。他の移行ツールでオンプレミスのワークロードをパブリック クラウドに移行させる場合、仮想マシンの長時間の停止、IP アドレスの変更、多くの手順が必要になります。これに対し、VMware Cloud on AWS では、無停止での移行、IP アドレスの変更不要、vSphere Client に統合された移行用 UI が提供されます。クラウドへの移行を、「リフト & シフト」と表現することがありますが、VMware Cloud on AWS においては「リフト」する必要はなく「シフト」だけと言っても良いでしょう。

ワークロードの移行は、以下の 2 つの重要な要素が必要となります。

  • 仮想マシンの双方向の移動
  • L2 ネットワークの延伸

仮想マシンの双方向の移動

VMware Cloud on AWS では、多くの仮想マシンの移動手段を提供しています。無停止での移行が必要な場合、数百台/数千台の仮想マシンを短期間に移行する必要がある場合、「オンプレミスからクラウドへ」ではなく「クラウドからオンプレミス」へ移行する必要がある場合など様々です。

仮想マシンを移行する際に無停止で移行できること、これは移行作業を最小限にするための最善の手段です。停止させないことにより、移行時間の制約がほぼなくなり、移行調整作業を大幅に削減できます。 P2V 経験者であれば、業務アプリケーションの停止調整の大変さは十分に理解できるかと思います。個々の停止調整が大変なシステムもありますが、なにより何十、何百のシステムの停止調整は非常に多くの時間を要します。度重なる異動や退職により管理者が不明になってしまった仮想マシンも、このタイミング出てきがちです。

何百台/何千台の仮想マシンを vMotion で移行する際に、ネックになるのが仮想ディスクの移行です。オンプレミスからクラウドへの移行になるので、メモリだけでなく仮想ディスクのデータも合わせてクラウドへ転送する必要があります。しかし、仮想ディスクのデータは 数十 GB ~ 数 TB と通常メモリの何十倍、何百倍もの容量があり、クラウド跨ぎの vMotion のオペレーションを開始してから何日も待たざる終えなくなってしまいます。そこで移行前に仮想マシンの通常運用中から仮想ディスクをバックグラウンドでコピー (レプリケーション) させる方法も提供されています。ここでは vSphere Replication が利用されます。この方法であれば、切替時に仮想マシンの停止が必要とはなってしまいますが、短時間での大量の仮想マシンの移行が可能となります。

多くのケースでは、オンプレミスの環境から VMware Cloud on AWS へ移行することが殆どだと思われます。しかしながら、その逆で VMware Cloud on AWS からオンプレミス環境へ移行するユースケースも見え始めています。例えば、開発環境のバースト利用として VMware Cloud on AWS を利用している際には、VMware Cloud on AWS に逃がしたワークロードを、オンプレミス環境に移行する必要があります。あるいは、オンプレミス側により良い環境が用意できた、他の VMware ベースのクラウドの方が要件にマッチしている等の理由で、VMware Cloud on AWS から引越をするケースもあるかもしれません。

このように VMware Cloud on AWS では、業務システムを止めない無停止でのvMotion による移行、大量のワークロードの移行を可能とする vSphere Replication ベースの移行、そして「オンプレミス環境からクラウドへ」「クラウドからオンプレミス環境へ」と双方向の移行といった幅広いワークロードの移行手段を提供しています。それらを WAN 越しに効率的に実行させるサービスとして VMware Cloud on AWS では、Hybrid Cloud Extension という Add-on サービスを提供されています。

L2 ネットワークの延伸

クラウドへの仮想マシンの移行において、非常に重要なポイントが L2 ネットワークの延伸です。言い換えると IP アドレスを変更せずにクラウドへ移行させる機能です。

クラウドに限らずデータセンターの移行であっても、ユーザーは IP アドレスの変更作業を望みません。SIer が入る場合も同様です。IP アドレスが変わった場合、その IP アドレスでシステムが動作するのかどうかを再テストする必要が出てくるため膨大な工数が掛かるのです。どの設定ファイルに IP アドレスが散在しているのか？DB の特定のレコードに IP アドレスが含まれていないか？さらにはソースコードに IP アドレスが含まれていないか？など危惧することは山のようにあります。より辛い状況としては、前述のようにアプリケーションのインストール方法や動作確認方法が失われてロストテクノロジー化あるいはオーパーツ化してしまうこともあります。SIer 主体で移行する際には、大昔に他の SIer が導入したシステムを移行することを見積もらねばならない、といった痺れる状況が生まれざるを得ません (SoW で条件付けすることになりますが…)。

そして、 IP アドレスを変えずにクラウドに移行できたとしても、まだ問題があります。その IP アドレスが存在するネットワーク セグメント上の仮想マシンすべてが一斉に移行できるわけではないと言うことです。例え一つのセグメント上の仮想マシンを全て移行できたとしても、それらの仮想マシンが他のセグメントにもネットワーク インターフェースを持っていた場合はどうでしょうか？多くのケースでは、その移行期間中に、オンプレミス環境とクラウドに同一セグメントの IP アドレスが散在することになります。ここでは、L2 ネットワークのオンプレミス環境とクラウド環境を跨いだ延伸機能が必要となります。

VMware Cloud on AWS では、IP アドレスを変更せずに移行できるようにするためのソフトウェアによる L2 ネットワークの延伸機能が提供されています。