VMwareからVPCへのVIrt-V2V+VDDKを利用した移行時間の検証結果

はじめに

本稿では以下の記事を参考にVMware上の仮想サーバーをVPCへVirt-V2Vで移行した際の移行時間について、条件を変えながら検証した結果をまとめます。

結論として、移行時間を早くするための条件として以下の要素が影響を与えることが確認できました。

• 移行元VMware環境のストレージ容量及び使用量
• 移行先サーバーのストレージ帯域
• 移行元VMware環境の外部ストレージのI/O性能

以降検証の結果について詳細に記載します。

検証環境

今回検証で利用する環境は以下の通りです。

VMware環境には10GB/sのPrivate VLAN2つと10GB/sのPublic VLAN1つが繋がっており、VPCとの接続はTransit Gateway経由で接続しています。

本検証環境はVMwareの環境としてDal09のものを利用しているため、移行先のVPC環境とゾーンが異なっています。そのため、同ゾーンで移行を実施することができれば本検証の結果よりも早く移行が可能です。

検証項目

本検証では移行期間短縮のためのボトルネック特定のため、いくつか条件を変えて検証を実施しました。

以下に、検証項目とその要点をまとめます。詳細な結果については後述します。

1. ストレージ使用率・ストレージ全体容量
   • ストレージ使用率および全体容量が増加するほど、移行時間も比例して増加する
2. 移行先ストレージの帯域
   • ストレージ使用率が低い場合は、帯域増強による移行時間短縮効果が大きい
   • ストレージ使用率が高い場合は、帯域を増やしても効果は限定的
   • 旧世代ストレージ(General Purpose)では393Mbpsまでしか出ないので、新しいsdpプロファイルの利用を推奨
3. 移行元VMwareの外付けストレージIOPS(並列移行時)
   • 並列移行時、一定数までは 1 台あたりの移行効率を維持したまま同時移行が可能
   • 効率的な並列数は、VMware 側外付けストレージの IOPS に比例する

検証結果

1. 移行先sdpストレージの帯域およびストレージ使用量の検証

前提環境

ストレージ容量と移行時間の関係を見るために以下の条件でそれぞれ移行時間を確認しました。
共通の条件として以下の環境を利用しています。

• 移行元サーバー：2 core, 8GB RAM の Windows Server 2019
• 外付けストレージ：2000IOPS

また、移行時の転送速度に関しては、Cloud Portalにある移行用サーバーの「Monitoring」から確認できます。

本稿ではVirt-V2V実行中にネットワーク転送が発生している時間を「転送時間」、ネットワーク転送が終わってからVirt-V2Vが完了するまでの時間を「書き込み時間」と表現します。

なお、現時点では sdp プロファイルの書き込み速度はモニタリング対象外のため、直接確認することはできません。

検証結果

sdpプロファイル1000Mbps

以下の構成の移行用サーバーを用い、移行データ量を変えて比較しました。

• 移行用サーバー：2core, 8GBのFedoraサーバー
  • 移行先ストレージ：sdp プロファイル（1000Mbps、3000 IOPS）
  • Volume bandwidth：2Gbpsに変更

	Storage全体	Storage利用	移行時間	転送時間	転送速度
Case 1	200GB	20GB	1741s	300s	65MB/s
Case 2	200GB	100GB	2432s	1570s	65MB/s
Case 3	200GB	200GB	3199s	3190s	65MB/s

この結果から、ストレージ使用量に応じてデータ転送時間が増加しており、未使用領域については移行先ストレージへの書き込み時間のみが発生していることが分かります。

実際にケース１の例で計算してみると

300s $\times$ 65MB/s = 19,500MB $\simeq$ 20GB
(1741s - 300s) $\times$ 125MB/s = 18,125MB $\simeq$ 180GB

となっているので、結果が妥当なものであると確認できます。

sdpプロファイル8192Mbps

続いて、移行用サーバーの帯域を最大値である 8192Mbps まで増加させ、同様に 3 パターンの移行を実施しました。

使用した移行用サーバーは以下の通りです。

• 移行元サーバー：8core, 32GBのFedoraサーバー
  • 移行先ストレージ：sdpプロファイル(8192Mbps, 3000IOPS)
  • Volume bandwidth：9Gbpsに変更

ストレージ帯域を増加させるには、移行先ストレージの帯域だけでなく、移行用サーバー側の Volume bandwidth もあわせて拡張する必要があります。

	Storage全体	Storage利用	移行時間	転送時間	転送速度
Case 1	200GB	20GB	583s	369s	68MB/s
Case 2	200GB	100GB	1698s	1610s	68MB/s
Case 3	200GB	200GB	3102s	3100s	68MB/s

結果を見ると、転送速度には大きな変化がなく、ストレージ使用率が高いケースでは、帯域を増加させても大きなメリットは見られませんでした。

一方で、ストレージ使用率が低い場合は、データ転送以外の時間、すなわち空き領域を書き込む時間が大きく短縮されるため、帯域増強の効果が大きいことが分かります。

帯域を上げても転送速度にまったく影響がないわけではありません。

最大帯域が 393Mbps の第一世代ストレージ（General Purpose）を利用した場合、転送速度は 47MB/s まで低下しました。

そのため、移行時には sdp ストレージの利用を推奨します。

2. 移行元VMwareの外付けストレージIOPS(並列移行時)

VMware環境からの移行効率を上げるために移行用サーバーを複数台用意し、並列移行する場合の移行時間について検証しました。

前提環境

こちらの検証において、以下の環境は共通なものとします。

• 移行元サーバー：2 core, 8GB RAM の Windows Server 2019
• ストレージ容量：200GB（使用率 100% となるようダミーファイルを作成）
• 移行用サーバー：2 core / 8GB RAM の Fedora
  • 移行先ストレージ：sdp（2000Mbps、3000 IOPS）
  • Volume bandwidth：3Gbpsに変更

検証結果

2000IOPSの外付けストレージからの移行

まず、VMware 上の移行元サーバーのストレージとして 2000IOPS (2IOPS/GB x 1000GB)のストレージを使用し、並列移行を実施しました。

	並列数	移行時間	転送速度
Case 1	1	3102s	68MB/s
Case 2	2	3100s	68MB/s
Case 3	3	4831s	44MB/s
Case 4	4	6430s	33MB/s

2000 IOPS の場合、全体で約 135〜140MB/s 程度の転送性能となり、2 並列までは効率を維持したまま移行可能であることが分かります。それ以上並列数を増やすと、1 台あたりの移行効率が低下しました。

6000IOPSの外付けストレージからの移行

続いて、VMware 上の移行元サーバーのストレージを 6000IOPS(2IOPS/GB x 3000GB) に変更し、再度並列移行を実施しました。

	並列数	移行時間	転送速度
Case 1	1	3102s	68MB/s
Case 2	2	3110s	68MB/s
Case 3	4	3130s	68MB/s
Case 4	5	3112s	68MB/s
Case 5	6	3432s	60MB/s

6000 IOPS の場合、全体で約 360〜370MB/s の転送性能となり、5 並列（6 並列もほぼ同等）までは効率を維持した移行が可能であることが確認できました。

まとめ

本稿では、Virt-V2V を利用した移行において、移行時間短縮に影響する条件を検証しました。

結論として、最も手軽かつ効果的な移行時間短縮手法は、外付けストレージの IOPS を考慮した上での並列移行であると考えられます。

並列数は外付けストレージの IOPS に依存しますが、場合によっては移行用のストレージを別途用意し、移行対象サーバーを Clone したうえで移行することで、さらに効率化できる可能性があります。

また、Virt-V2V で一度全データを移行した後に、rsync や robocopy などのデータ同期コマンドを用いて差分同期を行う構成も有効です。