みなさま、こんにちは！マイクロソフトの前島です。
前回は Azure VMware Solution (AVS) の課金・ライセンス体系を解説しました。多くの方から参考になった！というお声をいただいていますので、ぜひご興味のある方はご覧いただけると幸いです。 今回は、前回記事の中でも触れた Azure Migrate という移行アセスメントツールについて、もう少し詳しく紹介していきます。
Azure Migrate とは
Azure Migrate は、みなさまのクラウド移行の取り組みを支援するさまざまなツールや機能、移行ガイダンス等を備えた、Azure 移行におけるハブとなるサービスです。サーバー、データ、データベース、Webアプリ、仮想デスクトップなどの既存ワークロードに対して、移行候補の検出、評価、および実際の移行に至るまでの一連の機能を包括的にサポートしています。
現在サポートされる主な移行シナリオには、下記があります。
| 対象 | 提供機能 |
|---|---|
| サーバー (Windows, Linux) | オンプレミスのサーバーを評価し、それらを Azure 仮想マシンまたは Azure VMware Solution (AVS) に移行します。 |
| データベース | オンプレミスのデータベースを評価し、Azure SQL Database または SQL Managed Instance に移行します。 |
| Web アプリケーション | Azure App Service Migration Assistant を使用して、オンプレミスの Web アプリケーションを評価し、Azure App Service に移行します。 |
| 仮想デスクトップ | オンプレミスの仮想デスクトップ インフラストラクチャ (VDI) を評価し、Azure の Windows Virtual Desktop に移行します。 |
| Data | Azure Data Box 製品を使用して、大量のデータを迅速かつコスト効果よく Azure に移行します。 |
このうち AVS が登場するのが、一番上のサーバー移行シナリオです。話が脱線するため今回は省略しますが、データベースやWebアプリケーションの PaaS 移行支援機能も充実していますので、ぜひこれらシナリオでも Azure Migrate をご活用ください！
サーバー移行シナリオでは、既存オンプレミス環境（VMware vSphereやHyper-Vによる仮想マシンおよび物理サーバー）やパブリッククラウド VM などあらゆるタイプのサーバーリソースを検出し、それらを Azure 仮想マシン (IaaS) または AVS の仮想マシンに移行できるかを評価・アセスメントします。
よく聞かれるご質問の一つに、”移行先として Azure 仮想マシンと AVS のどちらがよいのか？”というものがあります。これに対する一律的な回答はなく、お客様それぞれの要件や制約、移行方針などによって最適解は異なりますが、Azure Migrate で技術的な移行可否チェックや大まかな費用試算が簡単にできますので、移行先を判断する材料の一つとしても活用いただけます。
なお移行先が Azure IaaS となる場合、Azure Migrate では実際の移行作業に当たる機能も提供します。一方 AVS への移行シナリオでは、AVS に標準で含まれる HCX を活用した移行が一般的かつ最も使い勝手が良いため、Azure Migrate の中では移行機能を提供していません。既存環境を検出し、移行アセスメント結果を出力するまでが Azure Migrate の範囲となります。 （HCX を利用した移行の詳細は、別トピックとして次回以降の記事で取り上げる予定です）
Azure Migrate 利用ステップ
それでは実際に Azure Migrate を利用するステップを見ていきましょう。大きく分けると、最初に対象リソースの「検出」を行い、次に検出されたデータに基づく「評価」を行うという二段階作業になります。 （ステップバイステップでの手順詳細等は、公式サイトをご参照ください）
1. アセスメント準備と検出
最初に行うのが、既存環境の検出等を行うアプライアンスの展開です。このアプライアンスは、 VMware Open Virtualization Appliance (OVA) 仮想マシンまたはZIPファイルにまとめられたインストーラーとして提供されています。
ほとんどの場合は、OVA ファイルをダウンロードして既存環境にデプロイするのが一番簡単かと思いますが、ZIPファイルに含まれる PowerShell スクリプトを任意の Windows Server 上で実行してインストールすることも可能です。
アプライアンスのデプロイまたはインストール後、vCenter Server への接続などの初期設定を行います。 特に難しいところはありませんが、アプライアンスからインターネット (Azure) に接続できる必要があるため、必要に応じて Proxy や Firewall の構成を行います。具体的な接続先 URL はこちらにまとめられています。
検出では、静的なインベントリデータ（サーバー名、割り当てCPU数やメモリ容量）だけではなく、実際のパフォーマンスデータ（CPU 使用率やメモリ使用率）も収集されます。 後ほどの評価フェーズで解説しますが、Azure Migrate ではこれらリアルなパフォーマンスデータを活用して評価する機能も提供されています。システムごとのピーク/オフピークパフォーマンスを考慮することで、より精緻なサイジングにつながるため、時間に余裕があれば少なくとも数日間はアプライアンスを稼働することをお奨めします。
またオプションとして、各サーバーごとの独立した情報だけではなく、サーバー間の依存関係を特定・分析する機能も提供されています。これにより、たとえば一緒に移行する必要のあるサーバーを特定し、より正確で信頼性の高い移行計画を立てていくことができるようになります。 依存関係の分析の詳細はこちらをご参照ください。なお本機能に限り、エージェントレスで実現する方法（現在プレビュー）と、各仮想マシンにエージェントを導入する方法の2パターンが提供されています。それぞれの違いについては、FAQ にまとめられています。
2. 検出結果の評価
Azure Migrate によって検出・収集されたデータは、Microsoft が管理する Azure 内の領域に安全に格納されます。これら格納されたデータを用いて、移行評価を行うのが次のステップです。
評価は Azure ポータルから簡単に行うことができ、またサイジング時のポイントとなるプロパティを変えて、様々な角度から何度でも評価できます。
AVS への移行評価を行う場合、下図にあるプロパティを変数として設定可能です。
各プロパティの詳細は公式ドキュメントの“Azure VMware Solution (AVS) 評価には何が含まれますか?” というセクションで解説されています。ここでは特に注意が必要な項目に絞って取り上げます。
■ターゲットの場所
AVS を作成する予定のリージョンです。こちらは既知の問題があり、現在は米国東部などの4リージョンしかリストに出てきません。（2021年5月現在、実際には東日本リージョンを含む世界11のリージョンでご利用いただけます）
どのリージョンでも提供されるスペックは同じであるためサイジングへの影響はありませんが、リージョンごとに提供価格が若干異なるため、アセスメント結果の費用に影響します。東日本リージョンのご利用を検討するお客様の場合、お手数ですが一番金額感の近い（＝日本より若干高い）オーストラリア東部を選択いただくと安全です。 今後リストが修正される予定ですが、既知の問題としてご了承ください。
■FTT設定、RAIDレベル
AVS は vSAN をデフォルトストレージとしており、実際には vSAN ストレージポリシーを用いて仮想マシンまたは仮想ディスクごとに任意の FTT / RAID レベルを設定できます。
Azure Migrate の評価では、いずれか一つの可用性レベルで構成する想定で選択いただきます。
■ CPU オーバーサブスクリプション
AVS ノードの 1 つの物理コアに関連付ける仮想コアの数の比率を指定します。企業ごとの方針や稼働するワークロードの特性などによって適正値は異なりますが、Azure Migrate では “4vCPU : 1 物理コア” を規定値としています。
CPU オーバーサブスクリプションの考え方は、少し古い情報になりますが VMwareのガイダンス（Determining an Appropriate vCPU-to-pCPU Ratio）もご参照ください。一概には言えませんが、実際にAVSを本番活用いただいているお客様の稼働状況を伺うと、サイジング時よりも CPU リソース使用率に余裕があり、4:1 はやや保守的なサイジングだったケースが多いようです。
■ メモリのオーバーコミット率
クラスター上でのメモリのオーバー コミット率を指定します。任意の値に変更可能ですが、メモリについてはオーバーコミットによるパフォーマンスへの影響が出やすいため、原則としてデフォルトの1、つまりオーバーコミットしない構成を推奨します。
■ 重複排除と圧縮率
AVS でも、vSAN クラスターが提供するストレージの重複排除や圧縮機能を活用できます。基本的にはオンプレミス環境と同等の削減率が見込まれるため、現行環境での削減率が目安になります。vSAN の場合、vCenter Server から現在の削減率を確認できます。
■ サイズ設定の基準
サイジングの方法として「パフォーマンスベース」「オンプレミス」のいずれかを選択します。
前項で紹介したように、Azure Migrate では実際に稼働している仮想マシンのパフォーマンスデータを収集できます。「パフォーマンスベース」を選択すると、パフォーマンスデータを元にサイジングが行われます。一方「オンプレミス」は、割り当てリソースに基づいたサインジグが行われ、パフォーマンスデータは考慮されません。
たとえば、ある仮想マシンに 4 個の仮想コアが割り当てられており、使用率が 25% だったとします。「オンプレミス」の場合はそのまま4vCPU を割り当てる前提でサイジングしますが、「パフォーマンスベース」の場合は1コアにダウンサイズできる可能性が提示されます。
コスト最適化の観点からは、Azure Migrate で一定期間検出を行い、「パフォーマンスベース」を用いてサイジングするのが望ましいでしょう。
3. 評価レポートの確認
以上のような設定を行うと Azure Migrate がアセスメントを行い、評価結果を確認できます。
ダッシュボード（下図）では、AVS に移行した場合の必要合計ノード数や各リソースの予測使用率、月間コストなどが一覧で表示されます。ここからさらにドリルダウンして、仮想マシンの一覧や詳細データを確認していくこともできます。また、評価レポートは Excel ファイルとしてエクスポートすることもできるようになっています。
なおサイジングロジックにおいて、vCenter、NSX Managerなどの AVS を構成する上で発生する管理オーバーヘッドや、vSAN の操作に必要な 25% のストレージ スラックもあらかじめ考慮されています。
その他詳細な評価ロジックについては Azure Migrate の AVS 評価の計算 で説明されていますので、興味のある方はご参照ください。
CSV ファイルによる検出もサポート
本稿では、リソースの検出やデータ収集を自動化するためにアプライアンスをデプロイする方法を解説してきました。しかし、お客様環境によってはアプライアンスを展開することが難しいケースもあるかと思います。
Azure Migrate では、検出作業は CSV ファイルで代替し、評価フェーズのみご活用いただく形もサポートしています。
CSVファイルのテンプレートは Azure ポータルからダウンロードでき、最低限入力する項目としては “Server name”, “Cores”, “Memory (In MB)”, “OS name” の4項目だけですので、これらを何らかの形で手元に用意できれば Azure Migrate で評価可能です。
将来的には、所定の CSV フォーマットだけではなく、RVTools のエクスポートファイル等その他フォーマットをそのまま読み込む機能も実装される予定です。
なお注意点として、CSV ファイルではパフォーマンスデータの収集はできないため、評価方法（サイズ設定の基準）は常に「オンプレミス」になります。精緻なサイジングや AVS 移行を機にリソースの最適化を図る場合は、アプライアンスによる検出をお奨めします。
まとめ
今回は AVS への移行検討時にご活用いただける、Azure Migrate という無償ツールをご紹介しました。
AVS に限った話ではありませんが、クラウドのメリットの一つは、オンデマンドでリソースの増減ができることにあります。そのため、オンプレミスに比べると事前の精緻なサイジングの必要性は低いかもしれません。とはいえ、予算化などで根拠ある概算が必要！といったケースも多いかと思いますので、その際にはぜひ Azure Migrate を選択肢の一つとしてご検討ください。
