- ライター：新林 辰則
- 2007年にネットワンシステムズに入社
ロードバランサー製品の製品技術担当を経て、現在はSDN・仮想化の製品・技術領域を担当し製品や技術の評価検証、お客様への提案の技術支援等を行っている。
最近はプログラマブルネットワークにも注目し、情報収集活動、セミナーでの発表などを実施。
目次
AWSのマネージドサービスとしてNetApp ONTAPを使用したストレージをクラウド上で利用できる、Amazon FSx for NetApp ONTAPがVMware Cloud on AWSのNFSデータストアとしてマウント可能になり、VMware CloudTM on AWSでサポートされるVMware vSANTM以外のデータストアとして選択の幅が広がりました。
今回、Amazon FSx for NetApp ONTAPで作成したストレージをVMware Cloud on AWSのSDDCにマウントし、オンプレミスからその領域に対してVMware HCX®を使用した仮想マシンの移行とNetApp SnapMirrorを使用したデータ移行を検証いたしました。
Amazon FSx for NetApp ONTAP自体の性能・障害試験なども実施しており、そちらは別のBlog記事にて紹介予定ですので是非ご覧ください。
VMware Cloud on AWS＋Amazon FSx for NetApp ONTAP構成の概要とメリット
今までのVMware Cloud on AWSのSDDC環境はデータストアとしてvSANのみをサポートしていたため、ストレージ領域のみを拡張することができませんでした。そのため、配置される仮想マシンが大量のストレージ領域を必要とする場合、CPUやメモリといった他のリソースよりも先にストレージ領域がSDDCクラスタ全体で足りなくなり、その拡張のためにホストを丸ごと追加するという手段を取らざるを得ませんでした。
その結果CPUやメモリリソースが余ってしまい、実質ストレージの容量のためにホスト丸ごと追加した分の料金がかかるというアンバランスな状況が生まれてしまう可能性がありました。
そこに今回、VMware Cloud on AWS (SDDCバージョン1.20) よりAmazon FSx for NetApp ONTAPがサポートされたことでストレージ領域のみをオンデマンドに拡張可能になり、さらにNetApp ONTAPが持つ圧縮/重複排除機能による容量削減効果を適用することも可能となっております。
図1 Amazon FSx for NetApp ONTAPをSDDCから利用可能に
また、Amazon FSx for NetApp ONTAPはONTAP CLIによるコマンドラインでの操作、管理も可能なため、VMware Cloud on AWSと同様にオンプレミスでの使い勝手をそのままに利用することも可能となっております。
今回の検証構成と検証内容、検証結果
Amazon FSx for NetApp ONTAP＋VMware Cloud on AWS環境の構成手順や留意点等につきましては、VMware様のVMware Japan Blogの下記リンク先記事のほうに詳しい内容をご記載いただいておりますため、そちらをご参考いただければと思います。
Amazon FSx for NetApp ONTAP で NFS データストアを構成する方法
検証構成
構成としては下記のように、弊社ラボであるテクニカルセンターをオンプレミス側とし、AWSと弊社クラウドHUBサービスのDirect Connect（1Gbps）を利用して接続しております。AWSリージョンは既存環境を利用する関係上、オレゴンリージョンを使用しており、オンプレ‐クラウド間の遅延として100ms程度かかる状況ではありますが、逆に言えばそれだけの遅延がかかる状況でも移行が問題なく行えるか確認できた形となります。
VMware Cloud on AWSはVMware Transit ConnectTMを利用し、FSx for ONTAPが構成されたVPCとDirect Connect Gatewayにそれぞれ接続しております。
また、移行テストに用いる仮想マシンを3台用意し、合計で約15GBほどのデータ量となります。
図2 検証構成
検証内容
- VMware HCXを使用した仮想マシンの移行
オンプレミスとVMware Cloud on AWSのSDDC間で、VMware HCXを用いてサイトペアリングとService Meshの作成を行います。その上でオンプレミス上のVLANポートグループをSDDC側へL2延伸し、下記3種類のHCXで行える移行方法を試しました。
・HCX vMotion
・HCX Bulk Migration
・HCX Replication Assisted vMotion（RAV）
移行を実施する手順としてはシンプルで、VMware HCXのGUI上から移行したい仮想マシンを選択し、移行方法や移行先クラスタ、データストアなどの必要情報を入力するのみとなっております。
それぞれの移行方法の主な特徴は以下になります。
図3 VMware HCX移行方法の特徴
VMware vSphere® vMotionとRAVに関してはオンプレミス側のゲートウェイにPingを打ち続け、通信断の有無を確認します。
- SnapMirrorを使用した仮想マシンの移行
オンプレミス側のONTAP（NetApp AFF）からSnapMirrorを利用してFSx for ONTAPとデータを同期。その後、SDDC側のVMware vSphere® ClientTMから仮想マシンをVMware vCenter Server®のインベントリに登録し、起動できるか確認しました。また、SnapMirrorの実行方法として下記2種類の方法を確認しました。
・ONTAP CLI
・NetApp BlueXP™
ONTAP CLIではオンプレミスと変わらない感覚でSnapMirrorを設定および実行できます。NetApp BlueXPの場合はGUI上からドラッグアンドドロップでSnapMirrorを開始できるようになり、シンプルな操作感を実現できます。
SnapMirrorによる移行についてはデータをクラウド側へ同期し、仮想マシンをインベントリ上へ登録した後に、オンプレミス側の仮想マシンをパワーオフしクラウド側の仮想マシンをパワーオンする切り替え方法になるため、Pingによる通信断確認は行っておりません。
- 実際のデータ転送量と移行にかかった時間の計測
VMware HCXとSnapMirrorによる移行方法それぞれで、移行におけるデータ転送量の最適化機能（圧縮・重複排除・キャッシュ等）が適用された、実際のデータ転送量の計測と移行にかかった時間を計測いたしました。
また、VMware HCXに関しては一度移行を実施すると、WAN最適化を実行するオプションアプライアンス内にキャッシュが残ります。そのため次回の移行の際にそのキャッシュが使用され、想定以上に最適化効果が出てしまうため、移行を始める前に再デプロイを実施するようにしております。
検証結果
前項でご紹介した検証内容に沿って仮想マシンの移行を行い、結果としてはすべての移行方法において問題なく仮想マシンのデータをSDDC上にマウントしたFSx for ONTAPのストレージ領域に同期することができ、仮想マシンとして正常に起動することができました。
また、それぞれの移行における計測データの表は以下となります。
図4 各移行方法の計測値
データ転送時間はオンプレミスからクラウドへのデータ転送・同期に要した時間です。スイッチオーバー時間はVMware HCX側での仮想マシン切り替えにかかった時間を表しております。CleanUp時間は移行完了後のVMware HCX側クリーンアップ処理の時間となります。
VMware HCXでの移行に関しては、サイト間で情報の連携を行いながら移行プロセスを進め、仮想マシンの切り替え部分までシステム側でカバーしてくれる関係上、総合的な移行完了までの時間はSnapMirrorよりも大きくなりました。データの実転送量はSnapMirrorよりも少なくなる結果が見て取れます。
SnapMirrorでの移行は切り替え方式の都合上ダウンタイムが発生し、切り替えプロセスも手動で実行する必要がありますが、データ転送時間については最も短い結果となりました。
今回の検証結果と、それぞれの移行方法の特徴を加味した比較は下記になります。
図5 各移行方法の比較
Snap Mirrorに関しましては、今回の検証ではタイムライン的に合わず盛り込めておりませんが、仮想マシン切り替えをカバーするDisaster Recovery Orchestratorという自動化ツールがリリースされてきておりますので、今後システム側での仮想マシン切り替え機能の充実が期待できます。
いずれの移行方法にも特徴があり、主に下記のような要素によってどの方法を採用するかを検討いただく形になると考えております。
・移行期間中のサービス停止が許容されるか否か
サービス停止なしがマストな場合はVMware HCXによる移行が必要。ただしサービス停止を無くすためには、単純なデータとしての移行以外にもVMware HCXによるL2延伸などネットワークの観点を含め、他要素も要検討。
・移行する環境の規模と移行完了までの時間的猶予
1度に移行しなければならない規模が大きい場合はVMware HCXだと移行に長時間要する可能性がある。データ転送のみで見た場合、SnapMirrorのほうが速い。
・移行失敗時の切り戻し
HCX vMotion・RAVについてはオンプレミス側に元データが残らないため、移行完了後の確認で問題発覚した場合の切り戻しに時間を要する。
SnapMirrorやHCX Bulk Migrationであれば移行後にもオンプレミスにデータが残るため、切り戻しが容易。
まとめ
本記事では、VMware Cloud on AWS＋Amazon FSx for NetApp ONTAP環境で仮想マシンの移行を検証し、それぞれの移行方法の特徴を整理・比較してみました。VMware Cloud on AWSでサポートするNFSデータストアには、Amazon FSx for NetApp ONTAP以外にもVMware Cloud Flex Storageが2月より東京リージョンでサポート開始されております。また、前項で紹介のとおりSnapMirrorもDisaster Recovery Orchestratorによるシステム側での仮想マシン切り替え自動化を実現するなど、各種アップデートが頻繁に行われている領域となります。
引き続き、弊社も検証など含め技術キャッチアップを行い、最適な提案をお客様へ提供できるよう努めてまいります。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
