みなさま、こんにちは！ マイクロソフトの前島です。
第三回となる今回は、Azure VMware Solution (AVS) の全体システム構造を解説します。技術的な情報にも踏み込んでいきますが、サービスのコンセプトとシステム構造をご理解いただくことで、AVS をより効果的に活用いただけるようになると考えています。
下図は、AVS の基本システムアーキテクチャを一枚に表したものです。この一枚にはさまざまなメッセージが込められていますが、今回は特に重要な3つのポイントを見ていきましょう。
1. Azure Resource Manager 準拠のサービス
第一回の記事で、AVS は Microsoft Azure が提供するファーストパーティサービスであり、サポートの一貫性やライセンス上のメリットがあることをお伝えしました。 ファーストパーティサービスであることは、技術視点でもメリットがあります。
たとえば Microsoft Azure ではすべてのサービスに共通する ARM (Azure Resource Manger) というリソース管理の概念があり、一貫性のあるリソースの展開や管理ができるようになっています。ARM を利用することで、複数の Azure サービスやリソースをグループとしてまとめたり、宣言型のテンプレートで一貫したデプロイ/再デプロイを実現したり、タグ付けによるリソースの整理を行えたりと、システムの規模や複雑性を問わず Azure 上のリソースを柔軟に管理できます。
AVS も ARM に準拠したサービスであるため、Azure ポータルはもちろんのこと、一貫性のあるコマンドライン (Azure CLI / PowerShell) や ARM テンプレートによる管理を実現します。 たとえば AVS のキャパシティが不足してきたのでノード数を増やしたい（または減らしたい）という場合に、コマンドからでもポータルからでも簡単に実現できるようになっているのは、ARM というリソース管理の仕組みがあるためです。
AVS を単体で利用しているとあまり意識する場面はありませんが、他の Azure サービス (IaaS/PaaS) と組み合わせるようになると、ARM による一貫性のあるリソース管理の重要性が増してくるでしょう。
2. VCF ベースのプライベートクラウド
AVS を展開すると、お客様ごとに占有の VMware ソリューションによるプライベートクラウド (SDDC) が構成されます。このプライベートクラウドは VMware Cloud Foundation (VCF) に基づいて設計されており、VMware 社の実績と経験に裏付けされた基盤設定が行われた状態で展開されます。
オンプレミスでプライベートクラウドを自社展開する場合、ハードウェアやクラスタに対する細かなチューニングを行うことも一般的かと思いますが、AVS は VMware ソリューションによるプライベートクラウドを提供する “サービス” であるという違いがあります。お客様が下回りの設計やテストあるいは運用で工数を費やさずに済むようにすることを基本コンセプトとしています。
この点は見方を変えると、オンプレミスでは当然のように実施していた細かなパラメーター設定変更等が、 AVS でも同様に変更できるとは限らない、と言えます。前回記事でも触れましたが、たとえば ESXi に対する root 権限や SSH アクセスは開放しておらず、CloudAdmin ロールを割り当てる運用になっていることにつながってきます。
もう少し具体的に、AVS で展開されるコンポーネントを見てみましょう。
2-a) vSphere クラスタ
AVS を展開する際の必須パラメータの一つが、ESXi ホストのノード数です。ノード数は、クラスタあたり3から16の範囲で任意に指定できるようになっており、指定した数の ESXi ホストで構成された vSphere クラスタが自動展開されます。 このクラスタはデフォルトで vSphere HA や DRS などが有効になっており、リソースの可用性やキャパシティの最適化が図られていますので、すぐにご利用開始いただけます。一方、これらクラスタ全体の構成はサービスレベルを確保するという観点でも重要なため、基本的にお客様の判断で無効化することはできない点はご留意いただく必要があります。
2-b) プライベートクラウド管理サーバー
AVS を展開すると、vSphere クラスタの管理に必要なサーバー群も一緒に展開されます。具体的には、vCenter (vCSA) や NSX Managerが展開され、オンプレミスと同様の感覚でプライベートクラウドを管理いただけます。
これら管理サーバーは、AVS プライベートクラウドごとに展開されます。AVSでは、単一プライベートクラウド内で複数の vSphere クラスタを展開できますが、その場合は最初に展開したクラスタ上でこれら管理サーバーが稼働します。
また AVS では HCX も追加料金なしでご利用いただけるようになっており、HCX 用のクラウド側コンポーネント（例：HCX Manager）もデフォルトで展開されています。ただし HCX を実際にご利用いただくためには、対向となるオンプレミス側への HCX Connector の導入や接続設定が必要です。具体的な手順は、チュートリアル – VMware HCX をデプロイして構成する – Azure VMware Solution をご参照ください。
2-c) vSAN ストレージ
AVS はデータストアとして vSAN を利用します。各ノードには 3.2TB の NVMe キャッシュ用ストレージと15.20TB のキャパシティ用ストレージが搭載されており、これらローカルストレージを用いた vSAN が構成された状態で展開されます。重複除去や圧縮がデフォルトで有効化されており、また保存データは Azure Key Vault を用いて暗号化されています。 つまり、ストレージに関しても展開後に何か追加作業をする必要はなく、すぐにご利用いただける状態です。
vSAN はノード数に応じてキャパシティが自動拡張し、可用性 (RAID) の選択肢も広がりますが、AVS でも同様です。典型的なストレージポリシーがデフォルトで定義されているため、仮想マシンごとの耐障害性要件に応じた可用性を簡単に確保できるようになっています。
AVS におけるストレージの詳細は、概念 – ストレージ – Azure VMware Solution にまとめられています。
2-d) NSX-T ネットワーク
オンプレミスで VMware ソリューションによるプライベートクラウドをご利用中の方にとって、AVS で一番大きな違いとなるのがネットワークかもしれません。AVS はオーバーレイネットワークを NSX-T で実装するように構成されており、従来型の VLAN 等はご利用いただけません。
vCenter 同様、 AVS プライベートクラウド作成時に NSX Manager も自動展開され、すぐにログオンできるようになっています。ただし仮想マシンを配置するためのオーバーレイネットワークは未構成の状態ですので、最初に Tier-1 ゲートウェイやセグメントの作成を行っていただく必要があります。 具体的な手順は チュートリアル – Azure VMware Solution で NSX-T ネットワーク セグメントを追加する – Azure VMware Solution をご参照ください。
話が少し脱線しますが、NSX-T ベースの AVS と連携するにあたって、オンプレミス側は NSX でなくても構いません。詳細は別の回で解説したいと思いますが、HCX がネットワークアーキテクチャの差異も吸収し、原則としてオンプレミス側ネットワーク構成を変更することなく、AVS とのハイブリッドクラウドを実現可能です。
3. AVS 以外との連携は ExpressRoute 経由
AVS はお客様ごとに完全に占有・分離されたプライベートクラウドであり、デフォルトではネットワーク的にも隔離された状態です。多くの場合、オンプレミスや他の Azure サービスと連携すると思いますが、ここで登場するのが高速閉域ネットワークサービスである ExpressRoute です。 このネットワーク連携に関しては技術的解説ポイントが多くあるので、次回まとめる予定です。基本的な概念を知りたいという方は 概念 – ネットワークの相互接続性 – Azure VMware Solution をご参照ください。
今回は Azure VMware Solution の基本的なシステムアーキテクチャをご紹介しました。次回は、本日最後に少し触れた「AVS とオンプレミス、および AVS と他の Azure サービスとのネットワーク接続」を掘り下げて解説する予定です。
