レガシーシステムをGCPへ移行 — VM on GCE (Nested Virtualization)
TL;DR GCP では VM やベアメタルサーバー上で動いている OS をそのまま持ち込み、GCE (IaaSサービス) 上で動かすことが技術的に可能です。これはレガシーなシステムをクラウド化するというシナリオにおいて、有効な一つの選択肢です。
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 10日目の記事です。
クラウドのメリットと現状
クラウドサービスを利用することにより、CAPEX / OPEX の最適化、ソフトウェア開発効率の向上、コラボレーションの促進といった利点を得ることができます。こういった利点を得るため、94%もの企業がすでにクラウドを何らかの形で利用しております。クラウドを利用する際、新しいシステムにのみ焦点を当て活用を考えることは比較的容易ですが、多くの企業が既にシステムを運用しているため、既存システムの取り扱いについて考慮が必要になります。
既存システムの内、特にレガシーシステムについては取り扱いが非常に難しく、このレガシーシステムとクラウドをどう組み合わせるかという事が大きなチャレンジになります。総務省の調査(2.2.1 DXの足かせとなっているレガシーシステム)によると、レガシーシステムは約8割の企業で使われており、そのうち7割の企業でレガシーシステムがデジタル化の足かせになっていると答えています。クラウドを利用すると、総務省の調査によるレガシーシステムが足かせになっていると感じる理由として挙げられる”性能の限界がある”、”維持運用費が高い”といった問題を解決できる可能性があります。
クラウドへの移行 — リフト＆シフトとは？
既存システムの取り扱いを考える際、クラウドを利用するパターンとしては大きく3つのパターンがあります。今回はリフト＆シフトというパターンにおける課題とそれに対する解決策を紹介します。
1. リフト&シフト
2. 改善と移行
3. 削除して置き換え
リフト&シフトとは既存のシステムに変更を加えず、そのままクラウドへシステムを移行するやり方です。この移行方法は短時間でクラウドへの移行を行うことができますし、新しい専門知識を必要としません。同じツールとスキルを使用できるので、最も簡単な移行タイプといえます。詳細はこちらをご覧ください。リフト＆シフトを実際に行う場合、オンプレミスにあるVMやベアメタルサーバー上で動いているOSをそのままIaaSサービス上 ( Google Cloud Platform = GCP では Google Compute Engine = GCE ) で動かすというアプローチを取る事が多いように感じます。
GCEへリフト&シフトするメリット
一般的なリフト＆シフトのメリットとしては、CAPEX / OPEXの最適化が大きいと思います。GCE を利用することにより、CAPEX / OPEXの最適化にさらなる効果が見込まれます。
・ライブマイグレーションにより、メンテナスによる影響を最小限にできる。
・カスタムマシンタイプにより、VMに割り当てるリソース( vCPU / メモリ ) を利用者が自由に設定できることにより、最適なリソース利用が可能となる。
・継続利用割引により、自動的に利用料金が割引になる。
・確約利用割引により、予測可能なワークロードを大幅な割引で利用可能。コミットを行う対象がvCPU/メモリの総数になるため、自由度が高い。
GCEへリフト＆シフトする方法と課題
既存環境をリフト＆シフトで GCE へ移行する場合、大きく以下3つの方法があります。1. → 2. → 3 の順番で難易度が高く移行後の効率性が悪くなります(1.が1番難易度が低く、移行後の効率も高い)。
1. 移行ツールを利用する
2. VM をインポートする
3. VM をそのまま持ち込む
しかしながら1. 2.は対応している OS に限りがあるといった制限(移行ツールがサポートする OS , VM インポートの要件)があり、バージョンが古いOS は対応していないという問題がありました。レガシーシステムはバージョンが古い OS を使っている事が多いため、今回は3.のやり方によりバージョンが古い OS を GCE 上のVMとして動かす方法をご紹介します。
※ OS や OS 上で動作しているソフトウェアのライセンス規約により、クラウド上での実行が制限されている場合もあります。ライセンス規約に関しては購入元にお問い合わせすることをおすすめします。今回は技術的に実現できるという視点でご紹介します。)
ネストされた仮想化 ( Nested Virtualization )
GCE 上で VM を動かすためには、特殊な設定が必要になります。それがネストされた仮想化という設定になります。この設定を行うことにより、VM を動かす土台となる、GCE のインスタンスが作成できます。具体的な設定方法については以下リンクをご参照ください。
次に VM やベアメタルサーバーで動作している OS を GCE 上で動作するVM へ変換します。このやり方は利用中の環境に大きく依存するため、大きな方向性だけご紹介します。実際にこの方法で移行をお考えの場合は、GCP のエキスパート ( GCPプリセールス、GCP パートナー、など ) にご相談ください。
オンプレミスにある VM を GCE 上へ移行する場合
オンプレミス、GCE 共に VM を動作させるソフトウェア(仮想化ソフトウェア、Xen・ KVM・ VMware ESXiなど)が同一である場合、VM の構成ファイルおよびディスクイメージをそのまま GCE 上に転送するという方法を取ります（ 参考: KVM-Offline Migration）。
異なるプラットフォーム(オンプレミス、GCE で VM を動作させるソフトウェアが異なる)場合、ディスクイメージを対応しているフォーマットに変換する必要があります。こちら(参考1, 参考2)は VMDK をいうフォーマットを QCOW2 という KVM が対応しているフォーマットに変換する方法になります。VM の構成ファイルについては、移行元の情報を元に再度作成を行う必要があります。
オンプレミスにあるベアメタルサーバーを GCE 上へ移行する場合
ベアメタルサーバー上で動いている OS を GCE 上の VM として移行する場合、ベアメタルサーバーが使っているストレージ ( HDD / SAS / SSDなど)を仮想マシンのディスクイメージに変換し、GCE 上の VM としてインポートするという方法を取ります ( P2Vと呼ばれる方法です ) 。
Linux の場合、シングルユーザーモードや Rescue CD / DVD を用いてブートし、ストレージをDDというツールでファイルに変換(抽出)するというやり方を取ります ( 参考 Linux(CentOS) P2V KVM化 )。その後、前述した方法で対応フォーマットへ変換します ( 仮想化ソフトウェアによっては変更が不要な物もあります ) 。
GCP でネストされた仮想化を行う際の Tips
カスタムイメージ作成時に指定できるイメージファミリーを探す
Nested Virtualization が有効な GCE インスタンスを作成する第一歩として、ブートディスクを作成します。作成時にイメージファミリーという、関連するイメージをグルーピングして管理するオプションを選択します。この時オプションとして利用可能なファミリーは以下コマンドで確認する事ができます。
gcloud compute images list 東京リージョンで Nested Virtualization が有効な GCE インスタンスを作成する
前述した方法で Nested Virtualization が有効になった GCE インスタンスが作成できます。GCE インスタンス作成時、Nested Virtualization に対応しているCPU ( Haswell 以降の CPU ) を選択します。サンプルとして示されているコマンド例では Haswell 以降の CPU を指定しますが、Haswell が東京リージョンでは利用できないため、別のオプションを選択する必要があります。こちら例は Broadwell 以降の CPU を利用するオプションになっており、このオプションにより Nested Virtualization が実行可能な GCE インスタンスを起動できます。
$ gcloud compute instances create ... --min-cpu-platform=”Intel Broadwell” ...オーバーコミットにならないように VM を配置する
GCE インスタンスが持っている vCPU やメモリを超えて VM を配置することをオーバーコミットと言います(例、4vCPU を持つ GCE インスタンスの上に 4vCPU 利用する VM を2つ起動する)。オーバーコミットにより、GCE インスタンスのリソース効率を向上できますが、反面 VM のパフォーマンスが劣化する可能性が高まります。そのため、まずは GCE インスタンスが持つリソースを超えないように VM を配置し、リソースの遊休状態を見ながらリソースの増減を行いましょう。
また、パフォーマンスを安定させるために VM が利用する vCPU を固定しましょう ( VMが利用する vCPU を固定することをピンニングと呼びます)。これを行わないと、VM がお互いに干渉しパフォーマンスに影響がでる可能性があります。KVM の場合、以下コマンドでピンニングの設定を行うことが可能です。
$ sudo virsh vcpupin <VM名> —-vcpu 0 --cpulist 1 #VMが利用する0番目のcpuをホスト(GCE)が認識しているCPUの1番めに紐付けるという意味
$ sudo virsh vcpuinfo <VM名> #ピンニングの確認GUI を使った管理を行う
KVM を始めとした仮想化ソフトウェアの多くが CUI での操作に対応しています。しかしながら、GUI を利用した方が視覚的な操作が可能となり、学習コストも下がるためおすすめです。Linux の場合、こちら(参考: GCE@東京でGUI(GNOME)を動かしてみた)にあるような手順によりGUI 環境を構築し、画面上で操作を行うことが可能となります。
まとめ
GCP では VM やベアメタルサーバー上で動いている OS をそのまま持ち込み、GCE ( IaaSサービス ) 上で動かすことが技術的に可能です。これはレガシーなシステムをクラウド化するというシナリオにおいて、有効な一つの選択肢です。
今回は Nested Virtualization という機能を使いレガシーシステムを GCE の上で VM として動かすための方法をご紹介しました。ただしこれ以外の方法で移行することもでき、最適な方法は状況によって異なります。みなさんもぜひこういった技術を使い、クラウドの活用を検討ください。
