Azure VMware Solution (AVS) 入門ガイド:基礎から理解


Azure VMware Solution (AVS) 入門ガイド:基礎から理解

はじめに:なぜ今、クラウド上のVMwareなのか?

多くの企業がデジタルトランスフォーメーションを推進する中で、ITインフラストラクチャのクラウドへの移行は避けて通れない道となっています。しかし、長年にわたりオンプレミス環境でVMwareを基盤とした仮想化インフラを運用してきた企業にとって、既存のアプリケーションやワークロードをそのままクラウドに移行することは、大きな課題を伴います。

アプリケーションの再設計(リファクタリング)や再プラットフォーム(リプラットフォーム)は、多大な時間、コスト、そしてリスクを必要とします。特に、既存のVMware環境に密接に依存しているミッションクリティカルなシステムや、VMwareの運用スキルセットを持つITチームにとって、これらの作業は大きな障壁となり得ます。

ここで登場するのが、Azure VMware Solution (AVS) です。AVSは、Microsoft Azureのグローバルインフラストラクチャ上で、ネイティブなVMware環境を提供するサービスです。オンプレミスで慣れ親しんだVMware vSphere、vSAN、NSX-Tといったテクノロジーを、Azureのデータセンター内で実行できます。

このガイドでは、AVSの基礎から、そのアーキテクチャ、主要コンポーネント、利点、ユースケース、ネットワーク、ストレージ、管理、移行、コスト、セキュリティに至るまでを詳細に解説します。AVSがどのようにオンプレミスの課題を解決し、Azureの広範なサービスと連携して新たな価値を生み出すのかを理解することで、クラウド移行やハイブリッドクラウド戦略を検討する上で重要な指針を得られるでしょう。

約5000語のボリュームで、AVSの全体像を深く理解できるように構成しています。ぜひ最後までお読みいただき、AVS活用の第一歩を踏み出すための知識を身につけてください。

第1章:Azure VMware Solution (AVS) とは何か? – 基本概念の理解

1.1 AVSを一言で説明すると?

AVSは、「Microsoft Azureのベアメタルインフラストラクチャ上で動作する、フルマネージドのVMwareクラウド環境」です。

これは、VMwareのソフトウェアスタック(vSphere、vSAN、NSX-T)が、Azureのデータセンター内に構築された専用の物理サーバー(ベアメタルサーバー)上で実行されることを意味します。そして、この環境はMicrosoftによって「フルマネージド」として提供されます。

1.2 「フルマネージド」とはどういうことか?

フルマネージドであるということは、基盤となるハードウェア、VMwareソフトウェアのインストール、パッチ適用、アップグレード、および基本的なヘルスモニタリングはMicrosoftが責任を持って行うということです。お客様は、vCenter Server経由でアクセスし、仮想マシン(VM)の作成、管理、ネットワーク設定(NSX-T経由)、ストレージ設定(vSANポリシー)など、仮想化レイヤーより上の管理に集中できます。

これにより、オンプレミス環境で必要だったハードウェアの調達・保守、VMwareソフトウェアのライフサイクル管理といった運用負荷から解放されます。

1.3 AVSの提供形態:プライベートクラウド

AVS環境は、「AVSプライベートクラウド」という単位で提供されます。1つのAVSプライベートクラウドは、VMwareクラスターを構成する複数のベアメタルサーバーから成り立ちます。最小構成は通常3ノードですが、ワークロードに応じてノードを追加することで、柔軟にスケールアウトできます。

このプライベートクラウドは、お客様専用のテナントとしてAzureデータセンター内に隔離されて構築されます。他のAzureリソース(仮想ネットワーク、ストレージアカウント、データベースサービスなど)とは、ネットワーク接続を通じて連携します。

1.4 なぜ「ベアメタル」なのか?

AVSが仮想化されたAzureインフラストラクチャ(例えば、Azure VM上でVMwareを動かす)ではなく、物理的なベアメタルサーバー上で提供されるのには重要な理由があります。

  1. パフォーマンス: 仮想化レイヤーが二重にならないため、ネイティブに近い高いパフォーマンスが実現できます。
  2. 互換性: VMwareの特定のバージョンや構成が、基盤となるハードウェアと緊密に連携して動作するため、オンプレミスのVMware環境との互換性が高くなります。
  3. VMwareの認定: VMwareが認定したハードウェア上で動作することで、VMwareのサポート体制を享受できます。

1.5 Azureとの連携

AVSの最大の強みの一つは、Azureの広範なサービスとのシームレスな連携です。AVSプライベートクラウドはAzure Virtual Network (VNet) に接続され、そこから他のAzureサービス(Azure Storage, Azure SQL Database, Azure Kubernetes Serviceなど)や、オンプレミス環境と連携できます。

これにより、既存のVMwareベースのワークロードをそのままAVSに移行しつつ、Azureのクラウドネイティブなサービスを活用して、アプリケーションのモダナイゼーションや新しい機能の追加を進めることが可能になります。

第2章:AVSのアーキテクチャと主要コンポーネント

AVSは、オンプレミスのVMware環境と同様に、VMwareの主要コンポーネントと、それらをAzureのインフラストラクチャ上で提供するための要素で構成されています。

2.1 AVSプライベートクラウドの内部構成

AVSプライベートクラウドは、以下のVMwareコンポーネントの統合体です。

  • VMware vSphere (ESXi): 仮想化ハイパーバイザー。各ベアメタルサーバー上で動作し、VMをホストします。
  • VMware vCenter Server: クラスター内のESXiホストとVMを集中管理するためのプラットフォーム。お客様はvCenter Serverにアクセスして日々の運用を行います。
  • VMware vSAN: ソフトウェア定義型ストレージソリューション。クラスター内の各ESXiホストに搭載されたローカルストレージをプール化し、高可用性を持つ共有データストアとしてVMに提供します。
  • VMware NSX-T Data Center: ネットワーク仮想化およびセキュリティプラットフォーム。論理的なネットワークセグメント、分散ファイアウォール、ロードバランシングなどを提供します。AVS環境内のVM間通信や、外部ネットワークとの接続を制御します。

これらのコンポーネントは、お客様がAVSプライベートクラウドをデプロイする際に自動的に構成されます。

2.2 基盤となるAzureインフラストラクチャ

AVSプライベートクラウドは、Azureデータセンター内の専用の物理サーバー(ベアメタルホスト)上で稼働します。これらのホストは、お客様のテナント専用に割り当てられ、他のAzureテナントとは物理的に隔離されています。

  • ベアメタルホスト: AVSを構成する物理サーバー。高性能なCPU、大容量のメモリ、そしてvSAN用のローカルSSDストレージを搭載しています。複数のホストがVMwareクラスターを形成します。ホストの種類は、リージョンや提供時期によっていくつかのオプションがあります(例:AV36、AV36p、AV52など)。それぞれCPUコア数、メモリ容量、vSANストレージ容量が異なります。
  • Azureバックボーンネットワーク: AVSプライベートクラウドは、Azureの広帯域かつ低遅延なバックボーンネットワークに接続されます。これにより、AVSとAzure VNet間の高速な通信が実現されます。

2.3 Azureサービスとの連携アーキテクチャ

AVSプライベートクラウドは、ExpressRouteを介してAzure Virtual Network (VNet) に接続されます。この接続により、以下の連携が可能になります。

  • Azureネイティブサービスとの連携: AVS上のVMは、VNetに接続されたAzure Storage、Azure SQL Database、Azure Kubernetes Service (AKS)、Azure Data Factory、Azure AI/MLサービスなど、様々なAzureネイティブサービスにアクセスできます。これにより、既存のVMwareワークロードを拡張したり、クラウドネイティブなコンポーネントと組み合わせたりすることが容易になります。
  • オンプレミス環境との連携: Azure VNetを介して、既存のオンプレミス環境とAVSプライベートクラウドをExpressRouteやVPNで接続できます。これにより、AVSをデータセンター拡張や災害対策サイトとして活用したり、オンプレミスとAVS間でワークロードをシームレスに移行したりすることが可能になります。
  • インターネット接続: AVS上のVMからインターネットへのアクセスは、Azure VNetを経由して行われます。Azure FirewallやNetwork Virtual Appliances (NVA) を利用して、セキュリティポリシーを適用できます。

2.4 管理プレーン

AVSの管理は、大きく分けて2つのレイヤーで行われます。

  1. Azure管理プレーン: Azure portalを通じて、AVSプライベートクラウドのプロビジョニング、スケーリング(ホストの追加/削除)、削除、課金、監視(Azure Monitor連携)、ログ収集(Azure Log Analytics連携)、およびAzure側のネットワーク設定(VNet接続、ExpressRoute設定)を行います。これはMicrosoftが管理する範囲です。
  2. VMware管理プレーン: お客様は、デプロイされたAVSプライベートクラウドのvCenter Server、NSX-T Manager、vSANの管理インターフェースにアクセスできます。ここでVMの作成、構成、管理、ネットワークセグメントの定義、ファイアウォールルールの設定、ストレージポリシーの適用など、仮想化レイヤーの運用を行います。これはお客様が管理する範囲です。

Microsoftは、基盤となるVMwareソフトウェアのパッチ適用やアップグレードを管理しますが、お客様は計画されたメンテナンスウィンドウ内でこれらの作業が実行されることを承認またはスケジュールします。

第3章:AVSの主要な利点(Benefits)

AVSが多くの企業にとって魅力的な選択肢となるのには、いくつかの重要な利点があります。

3.1 既存のVMwareスキルとツールを活用可能

最も大きな利点の一つは、オンプレミスで培ったVMwareの運用スキルや既存のVMware互換ツール(バックアップ、監視、自動化など)をそのまま活用できる点です。新しいクラウドプラットフォームの学習曲線が緩やかになり、ITチームは迅速にクラウド環境での運用を開始できます。vSphere Clientを使ってVMを管理し、NSX Managerを使ってネットワークを構成するといった、慣れ親しんだ操作で作業を進められます。

3.2 迅速なクラウド移行(リプラットフォーム)

AVSは、オンプレミスのVMware環境からAzureへのワークロード移行を劇的に簡素化します。アプリケーションに変更を加えることなく(リプラットフォーム)、VMware vSphere ReplicationやVMware HCX (Hybrid Cloud Extension) といったツールを使用して、VMをAVS環境に移行できます。これは、「リフト&シフト」に近い感覚で実行でき、大規模な移行プロジェクトの時間とコスト、リスクを大幅に削減します。特に、レガシーアプリケーションや、クラウドネイティブ化が困難なアプリケーションの移行に有効です。

3.3 Azureネイティブサービスとのシームレスな連携

AVSプライベートクラウドがAzure VNetに接続されていることで、Azureの膨大なサービス群(データ分析、AI/ML、マネージドデータベース、コンテナサービス、セキュリティサービスなど)をAVS上のワークロードから容易に利用できます。これにより、既存のVMwareベースのアプリケーションを、Azureの最新技術を活用して拡張したり、データを連携させたりすることが可能になり、段階的なアプリケーションモダナイゼーションを促進できます。

3.4 データセンターの拡張と容量不足の解消

オンプレミスのデータセンターの容量が逼迫している場合、AVSを迅速なデータセンター拡張先として利用できます。物理的なハードウェアの調達やセットアップに比べて、AVSプライベートクラウドのデプロイははるかに迅速に行えるため、ビジネスニーズに合わせた柔軟なキャパシティ拡張が可能です。

3.5 災害対策(DR)と事業継続計画(BCP)

AVSは、オンプレミス環境や別の場所にあるAVSプライベートクラウドの災害対策サイトとして理想的です。VMware Site Recovery Manager (SRM) やその他のVMware互換DRソリューションを使用して、AVSをターゲットにリカバリー環境を構築できます。Azureのグローバルなリージョンを活用することで、地理的に離れた場所にDRサイトを構築し、事業継続性を高めることができます。

3.6 VDI (Virtual Desktop Infrastructure) 環境の構築

AVSは、VMware Horizonをデプロイするための優れたプラットフォームとなり得ます。高性能なベアメタルホストとvSANによる高速ストレージにより、快適なVDI環境を提供できます。これにより、オンプレミスのハードウェアリソースに依存せずに、必要な時にVDI環境を柔軟に拡張・縮小できます。

3.7 ハードウェアのライフサイクル管理からの解放

オンプレミス環境では、サーバー、ストレージ、ネットワーク機器といったハードウェアの購入、設置、設定、保守、リプレースといったライフサイクル管理に多大な労力がかかります。AVSでは、これらの物理インフラの管理はMicrosoftが担当します。お客様はハードウェアの障害やリプレースを気にする必要がなくなり、インフラ運用から解放されます。

3.8 サポートとメンテナンスの一元化

AVSは、MicrosoftとVMwareが共同でサポートを提供するサービスです。AVSに関する問題が発生した場合、Microsoft Azureサポートに連絡すれば、必要に応じてMicrosoftとVMwareが連携して対応にあたります。VMwareソフトウェアのパッチ適用やバージョンアップも、Microsoftが計画・実行するため、お客様の運用負担が軽減されます。

第4章:主なユースケース(Use Cases)

AVSは様々なシナリオで活用できます。代表的なユースケースをいくつか紹介します。

4.1 データセンター移行(Data Center Migration)

これはAVSの最も主要なユースケースです。既存のオンプレミスVMware環境にある数千、数万台のVMをAzureに移行したいが、アプリケーションの変更やリプラットフォームに時間やコストをかけたくない場合に最適です。VMware HCXなどのツールを使用することで、アプリケーションを停止する時間を最小限に抑えつつ、効率的かつ大規模な移行を実行できます。移行後も、慣れ親しんだVMware環境で運用を継続できます。

4.2 データセンター拡張(Data Center Extension)

オンプレミスのデータセンターリソースが不足している場合や、一時的にキャパシティを増強したい場合に、AVSをオンプレミス環境の自然な拡張として利用できます。オンプレミスとAVS間を高速なネットワークで接続し、両環境間でワークロードを柔軟に配置したり、ピーク時にAVSを活用したりすることができます。新しいアプリケーションや開発環境をAVS上に迅速にプロビジョニングする用途にも適しています。

4.3 災害対策サイト(Disaster Recovery)

オンプレミス環境のDRサイトとしてAVSを利用することで、物理的なDRサイトの構築・維持にかかるコストと複雑さを削減できます。VMware Site Recovery Manager (SRM) やvSphere Replicationを使用して、オンプレミスのVMをAVSにレプリケーションし、障害発生時にはAVS上で迅速にリカバリーを実行できます。Azureのグローバルなリージョン選択肢は、オンプレミスから十分な距離を確保したDRサイト構築を容易にします。また、異なるリージョンに複数のAVSプライベートクラウドを展開し、AVS間でのDR構成を組むことも可能です。

4.4 アプリケーションのモダナイゼーション支援

AVSに移行した既存のVMwareワークロードを、Azureの各種PaaSやSaaSサービスと連携させることで、段階的にアプリケーションをモダナイズできます。例えば、AVS上のアプリケーションが利用するデータベースをAzure SQL Databaseに移行したり、AVS上のWebサーバーとAzure Application Gatewayを組み合わせたり、AVS上のデータをAzure Data Lake Storageに格納して分析したりすることが可能です。アプリケーション全体を一度に作り変えるのではなく、コンポーネント単位でクラウドネイティブ化を進めることができます。

4.5 Virtual Desktop Infrastructure (VDI) の展開

リモートワークの拡大などに伴い、VDI環境の需要は高まっています。AVSは、VMware Horizonをデプロイするための認定プラットフォームです。オンプレミスでHorizonを運用している企業は、AVS上にHorizon環境を構築し、クラウドのスケールメリットを活かしてVDIを提供できます。

4.6 開発・テスト環境

必要な時に迅速にプロビジョニングでき、不要になったらすぐに削除できるAVSは、開発・テスト環境の構築にも適しています。オンプレミス環境のリソースを消費することなく、本番環境に近いVMware環境をクラウド上に構築し、開発やテストを行うことができます。

4.7 特定のワークロードの移行

SAPやOracleなど、特定のミッションクリティカルなワークロードをVMware上で稼働させている企業にとって、AVSはこれらのワークロードを比較的容易にクラウドに移行できる手段となります。AVSのベアメタルホストは高性能であり、これらのワークロードが要求するリソース要件を満たすことが可能です。

これらのユースケースを通じて、AVSが既存のVMware投資を活かしつつ、クラウドのメリットを享受するための強力なソリューションであることがわかります。

第5章:AVSのネットワークとストレージの詳細

AVSを理解する上で、ネットワークとストレージの構成は非常に重要です。オンプレミスのVMware環境とは異なる点も多いため、しっかりと把握しておく必要があります。

5.1 ネットワーク:NSX-T Data Centerによる柔軟な構成

AVSプライベートクラウドのネットワーク機能は、VMware NSX-T Data Centerによって提供されます。NSX-Tはソフトウェア定義型ネットワーク (SDN) プラットフォームであり、物理的なネットワークインフラストラクチャから独立した論理的なネットワーク環境を構築できます。

  • セグメント (Logical Segments): NSX-Tでは、「セグメント」と呼ばれる論理的なスイッチを作成します。VMはこのセグメントに接続され、同じセグメント内のVMはL2通信(ブロードキャスト含む)が可能です。オンプレミスでいうところのポートグループやVLANに相当しますが、物理ネットワーク構成に縛られずに自由に作成・構成できます。
  • Tier-1 ゲートウェイ: セグメント間のルーティングや、外部ネットワークとの接続にはTier-1ゲートウェイを使用します。各AVSプライベートクラウドには、デフォルトでTier-0ゲートウェイとTier-1ゲートウェイがプロビジョニングされます。お客様は通常、Tier-1ゲートウェイの下にセグメントを接続し、必要なルーティングやNAT、ファイアウォール設定を行います。
  • 分散ファイアウォール (Distributed Firewall – DFW): NSX-TのDFWは、VMware vSphereのDistributed Switch (VDS) レイヤーで動作するステートフルファイアウォールです。これにより、VM単位でのマイクロセグメンテーション(VM間の通信を細かく制御する)が可能になります。オンプレミスのVMware環境でNSXを使っている場合と同様のセキュリティポリシーをAVSに適用できます。
  • NSX-T Manager: NSX-T環境を一元管理するためのWebインターフェースです。お客様はNSX-T Managerにアクセスして、セグメントの作成、ルーティング設定、ファイアウォールルールの定義などを行います。

5.2 AVSと外部ネットワークとの接続

AVSプライベートクラウドは、Azure VNetを経由して様々なネットワークと接続されます。

  • AVSプライベートクラウド <=> Azure Virtual Network (VNet): AVSプライベートクラウドは、高速なExpressRoute接続を通じてAzure VNetに接続されます。この接続は、お客様がAVSをデプロイする際に自動的に確立されます。AVS上のVMは、この接続を経由してVNet内の他のリソース(Azure VM、PaaSサービスなど)や、VNetに接続されたオンプレミスネットワークと通信します。この接続は、AVS専用のExpressRoute回線(ExpressRoute Gatewayを介さない)で提供され、非常に高速です。
  • Azure VNet <=> オンプレミス環境: お客様のオンプレミス環境は、既存または新規のExpressRoute回線やVPN Gatewayを通じて、AVSが接続されているAzure VNetに接続します。これにより、オンプレミスとAVS/Azure間でハイブリッドネットワークを構築できます。
  • AVS上のVM <=> インターネット: AVS上のVMからインターネットへのアウトバウンド通信は、Azure VNetを経由して行われます。通常、VNetにデプロイされたAzure FirewallやNVAを経由させることで、セキュリティポリシーを適用し、通信を制御します。インバウンド通信(インターネットからAVSへのアクセス)が必要な場合は、Azure Application GatewayやAzure Load Balancer、Public IPアドレスを持つNVAなどをVNetに配置し、NATやポートフォワーディングを利用してAVS上のVMにアクセスさせます。
  • Azure Virtual WAN (VWAN) との連携: 大規模なハイブリッドネットワーク環境では、VWANを活用することで、オンプレミス、AVS、複数のAzure VNet、ブランチオフィスなどを効率的に相互接続できます。AVS ExpressRoute回線をVWANハブに接続することで、ルーティング管理を簡素化できます。

5.3 IPアドレス設計の重要性

AVS導入において、IPアドレス設計は非常に重要です。

  • AVS管理ネットワーク: AVSプライベートクラウドをデプロイする際に、管理ネットワーク(vCenter, NSX Manager, HCXなど)用のIPアドレス範囲を指定する必要があります。この範囲は、お客様のオンプレミスやAzure VNetで使用しているIPアドレス範囲と重複してはなりません。
  • ワークロードネットワーク: AVS上のVMに割り当てるIPアドレスは、NSX-Tのセグメント上で構成します。これらのアドレス範囲も、オンプレミスやAzure VNetと重複しないように設計する必要があります。
  • ルーティング: AVS、Azure VNet、オンプレミス間の通信はルーティングによって制御されます。オンプレミス環境からAVS上のVMにアクセスできるように、オンプレミス側ルーターにAVSのワークロードネットワークへのルートを追加したり、Azure VNetのルートテーブルを設定したりする必要があります。

5.4 ストレージ:vSANによる高性能・高可用性ストレージ

AVSプライベートクラウドのプライマリストレージは、VMware vSANによって提供されます。vSANは、VMwareクラスターを構成する各ESXiホストに搭載されたローカルSSD(キャッシュ層とキャパシティ層)をソフトウェア的にプール化し、単一の共有データストアとして提供します。

  • 分散ストレージ: vSANデータストアは、クラスター内のすべてのホストからアクセス可能な分散ストレージプールです。VMの仮想ディスクは、このvSANデータストア上に配置されます。
  • 高可用性: vSANは、ストレージポリシーに基づいてデータの冗長性を確保します。デフォルトでは、「許容しうる障害数(FTT – Failures To Tolerate)」が1に設定されており、データのコピーがクラスター内の別のホストに配置されるため、1台のホストに障害が発生してもVMは稼働を継続できます。FTTを増やすことで、より高いレベルの可用性を実現できます(必要なホスト数も増加します)。
  • パフォーマンス: 各ホストのローカルSSDを活用するため、非常に高いI/Oパフォーマンスを発揮します。また、分散構成によりスループットも向上します。
  • ストレージポリシー (SPBM – Storage Policy Based Management): vSANでは、VMDK(仮想ディスク)単位でストレージポリシーを適用できます。ポリシーでは、FTT、ストライピング幅、キャッシュ予約などのパラメータを指定し、ワークロードの要件に合わせた可用性やパフォーマンスを設定できます。

5.5 ストレージの拡張性

AVSのストレージ容量は、クラスター内のホスト数に依存します。ホストを追加すれば、vSANデータストアの容量とパフォーマンスが自動的にスケールアウトします。

5.6 Azure Storageとの連携

AVSのvSANデータストアはプライマリストレージですが、バックアップターゲットや大容量ファイル共有など、特定のユースケースではAzure Storage (Blob Storage, Azure Files) と連携することがあります。例えば、AVS上のバックアップソフトウェアからAzure Blob Storageにバックアップデータを保存したり、AVS上のVMからAzure FilesをNFS/SMB共有としてマウントしたりすることが可能です。

第6章:AVSの管理と運用

AVSの運用は、Microsoftによる基盤管理とお客様によるVMwareレイヤー管理の組み合わせで行われます。

6.1 Microsoftが管理する範囲

  • 基盤となるベアメタルハードウェア: サーバー、ネットワーク機器のセットアップ、パッチ適用、ハードウェア障害時の交換など。
  • AVSプライベートクラウドのデプロイとスケーリング: Azure portalからの操作に基づいて、新しいクラスターの作成、ホストの追加/削除を行います。
  • VMwareソフトウェアのライフサイクル管理: ESXi、vCenter Server、NSX-T、vSANのソフトウェアのインストール、パッチ適用、バージョンアップグレード。これらのメンテナンス作業は、お客様が事前に定義したメンテナンスウィンドウに基づいて実行されます。
  • AVSプライベートクラウド全体の可用性監視: 基盤インフラストラクチャレベルでの監視を行います。

6.2 お客様が管理する範囲

  • vCenter Server、NSX-T Manager、vSANの運用: vSphere ClientやNSX ManagerのGUI/APIを通じて、以下の作業を行います。
    • 仮想マシンの作成、構成、起動/停止、削除
    • リソースプール、フォルダ、権限設定などのvCenter管理
    • NSX-Tによる論理セグメントの作成、ルーティング設定、NAT設定
    • NSX-Tによる分散ファイアウォールルールの設定
    • vSANストレージポリシーの設定と適用
  • ワークロード(仮想マシン)のOSおよびアプリケーション管理: 仮想マシン内のオペレーティングシステムやインストールされたアプリケーションのパッチ適用、構成、監視、トラブルシューティングなど。
  • バックアップとリカバリー: AVS上のVMのバックアップ。VMware互換のバックアップソフトウェアをAVS上またはAzure VNetにデプロイして実行します。
  • 監視とログ収集: AVS上のVMやVMwareコンポーネント(vCenter, NSX-Tなど)から、ゲストOSレベルやアプリケーションレベルのログ、パフォーマンスメトリクスを収集し、Azure MonitorやLog Analyticsなどに連携させて監視・分析を行います。
  • セキュリティ: NSX-Tによるネットワークセキュリティ設定、ゲストOSレベルのセキュリティ強化、IAM(Identity and Access Management)によるvCenter/NSX-Tへのアクセス制御など。

6.3 監視とログ収集の連携

AVSはAzure MonitorやLog Analyticsと連携し、AVSプライベートクラウドのリソース使用率やパフォーマンスに関するメトリクス、VMwareコンポーネント(vCenter, NSX-Tなど)からのログを収集できます。これにより、Azureの監視ツールを使ってAVS環境とAzureネイティブサービスを統合的に監視できます。

6.4 自動化

VMware PowerCLI、vRealize Automation、Terraform、Azure Automationなど、様々なツールを使ってAVS環境のプロビジョニングや管理作業を自動化できます。既存のVMware環境で利用している自動化スクリプトやワークフローを、大きな変更なくAVSに適用できる場合が多くあります。

第7章:AVSへのワークロード移行(Migration)

AVSの主要なユースケースであるデータセンター移行において、ワークロードを効率的にAVSに移動させる方法は非常に重要です。主に以下の方法があります。

7.1 VMware HCX (Hybrid Cloud Extension)

VMware HCXは、AVSへのワークロード移行を最も推奨される方法です。HCXは、オンプレミスのVMware環境とAVSプライベートクラウド間にハイブリッド性を実現するためのテクノロジーです。

HCXの主な機能:

  • レイヤー2延伸 (Layer 2 Extension): オンプレミスとAVS間で、ネットワーク(VLAN/セグメント)をL2レベルで延伸できます。これにより、移行元のVMと移行先のVMが同じサブネット上に存在できるようになり、IPアドレスの変更や複雑なルーティング設定なしに移行が可能になります。これは、アプリケーションへの影響を最小限に抑える上で非常に強力な機能です。
  • 多様な移行方法:
    • vMotion (Live Migration): アプリケーションを停止せずに、実行中のVMをオンプレミスからAVSへ(またはその逆へ)移行できます。大規模な環境でも、個々のVMをダウンタイムなしに移行する場合に利用します。
    • Bulk Migration: 複数のVMをまとめて移行できます。計画的なダウンタイムが必要ですが、vMotionよりも効率的です。移行をスケジュールしたり、一括で管理したりするのに適しています。
    • Replication Assisted vMotion (RAV): vSphere ReplicationとvMotionを組み合わせた方法です。ディスクデータを事前にレプリケーションしておき、カットオーバー時のみvMotionで差分データ転送とVMの実行移行を行います。大規模なVMや長距離の移行で、ダウンタイムを最小限にしつつ効率的に移行したい場合に有効です。
    • Cold Migration: VMをシャットダウンしてから移行します。ダウンタイムが許容される場合に利用します。
  • WAN最適化: オンプレミスとAVS間のWAN回線に対して、帯域幅の最適化や圧縮機能を提供し、移行パフォーマンスを向上させます。
  • データ重複排除: 移行中のデータ重複排除を行い、必要な帯域幅を削減します。
  • 組み込みのセキュリティ: 移行トラフィックは暗号化されます。

HCXは、オンプレミス環境にHCX Connector OVFをデプロイし、AVS側にHCX Cloud Managerがプロビジョニングされることで利用可能になります。大規模かつ複雑なVMware環境からの移行には、HCXの活用が不可欠と言えます。

7.2 vSphere Replication

HCXを使用しない場合でも、VMware vSphere Replicationを利用してVMを移行できます。これは、VMware標準の非同期レプリケーション機能です。オンプレミスのvCenter環境にvSphere Replicationアプライアンスをデプロイし、AVSのvCenter環境(既にvSphere Replicationが構成済み)をターゲットにレプリケーションを設定します。計画的なカットオーバー時にレプリケーションを停止し、AVS側でVMをリカバリー(パワーオン)することで移行を完了します。ダウンタイムは必要ですが、比較的シンプルに移行したい場合に利用できます。

7.3 その他の移行ツール

サードパーティ製のVMware互換移行ツール(例:Zerto, Veeamなど)も、AVSをターゲットとして利用できる場合があります。これらのツールは、特定の機能(例:継続的なレプリケーション、オーケストレーション機能)が必要な場合に検討できます。

7.4 移行計画の重要性

どの移行方法を選択するにしても、詳細な移行計画を立てることが成功の鍵となります。

  • インベントリ収集: 移行対象のVM、アプリケーション、依存関係、リソース要件、ネットワーク構成などを正確に把握します。
  • サイジング: 移行後のAVS環境に必要なホスト数やリソース容量を正確に見積もります。
  • ネットワーク設計: オンプレミス、AVS、Azure VNet間のネットワーク接続、IPアドレス設計、ルーティング計画を慎密に行います。特にL2延伸を利用するかどうかは重要な決定事項です。
  • 移行波の定義: 全てのワークロードを一度に移行することは稀です。アプリケーションの依存関係やビジネスインパクトを考慮して、移行するワークロードのグループ(移行波)とスケジュールを定義します。
  • テスト計画: 移行前のテスト、移行中のテスト、移行後のテスト(アプリケーション動作確認など)を詳細に計画し、実行します。
  • ロールバック計画: 問題発生時のロールバック手順を確立します。

データセンター移行は複雑なプロジェクトですが、AVSとHCXを活用することで、その複雑さとリスクを大幅に軽減することが可能です。

第8章:AVSのコスト

AVSのコストは、主に以下の要素によって決まります。

8.1 ホストベースの料金

AVSの主要なコストは、AVSプライベートクラウドを構成するベアメタルホストの時間貸し料金です。ホストの料金は、ホストの種類(AV36, AV36pなど)や、購入方法(従量課金またはリザーブドインスタンス)によって異なります。

  • 従量課金: ホストを利用した時間に対して課金されます。一時的な利用や、需要の変動が大きいワークロードに適しています。
  • リザーブドインスタンス (Reserved Instances – RI): 1年または3年の契約期間でホストを予約購入することで、従量課金に比べて大幅な割引が適用されます。継続的に稼働するワークロードや、大規模な移行後の環境に適しています。通常、RIはAVSコスト最適化の最も効果的な手段となります。

8.2 その他の関連コスト

AVSプライベートクラウド自体のホスト料金以外にも、以下の関連コストが発生する可能性があります。

  • Azure ExpressRoute 回線料金: オンプレミス環境からAVSが接続されているAzure VNetへのExpressRoute接続を使用する場合の料金。
  • Azure Virtual Network (VNet) データ転送料金: AVS上のVMとAzure VNet内のリソース間のデータ転送、およびVNetからインターネットやオンプレミスへのデータ転送に対して料金が発生する場合があります(リージョン内転送は無料、リージョン間やインターネットへの転送は有料など、Azureの一般的なネットワーク料金体系に従います)。
  • Azure サービス利用料: AVS上のワークロードが利用するAzureネイティブサービス(Azure Storage, Azure SQL Database, Azure Firewallなど)の利用料。
  • パブリックIPアドレス料金: インターネットからAVS上のVMにアクセスするために使用するパブリックIPアドレスの料金(Azure FirewallやNVAに割り当てる場合など)。
  • バックアップ/リカバリーソフトウェア料金: サードパーティ製のバックアップソフトウェアなどを利用する場合のライセンス料や利用料。
  • HCX 利用料: 基本的なHCX機能はAVSに含まれていますが、AdvancedやEnterprise Editionの機能には追加費用が発生する場合があります(AVSのライセンスに含まれている場合もありますので、最新情報を確認してください)。

8.3 コスト最適化のポイント

  • リザーブドインスタンスの活用: 安定稼働するワークロードには積極的にRIを適用します。
  • 適切なサイジング: 不要なリソースへの支払いを避けるため、ワークロードに必要なホスト数と種類を正確に見積もります。移行前後のパフォーマンスモニタリングが重要です。
  • VMの最適化: AVSに移行する前に、不要なVMを整理したり、VMのサイズを最適化したりすることで、必要なホスト数を削減できる可能性があります。
  • ストレージポリシーの最適化: vSANのストレージポリシー(特にFTT)は、必要なストレージ容量に大きく影響します。ワークロードの要件に合わせて適切なポリシーを設定します。
  • ネットワークコストの理解: Azure VNet経由のデータ転送コストを理解し、可能な限りAzure内部で通信を完結させる、またはコスト効率の良いネットワーク構成を選択します。
  • Azure Hybrid Benefitの適用: Windows ServerやSQL Serverなどのライセンスを保有している場合、Azure Hybrid BenefitをAVS上のVMに適用することで、ソフトウェアライセンスコストを削減できます。

AVSのコストは、オンプレミスのハードウェア購入・維持コストやデータセンターコストと比較して評価する必要があります。CAPEXからOPEXへの移行によるキャッシュフローへの影響も考慮が必要です。

第9章:AVSのセキュリティ

クラウド環境、特に既存のエンタープライズワークロードを移行するAVSにおいて、セキュリティは最優先事項です。AVSは、Azureの堅牢なセキュリティ基盤の上に、VMwareのセキュリティ機能が組み合わされています。

9.1 Azureによるセキュリティ基盤

  • 物理セキュリティ: Azureデータセンターは、厳格な物理セキュリティ対策が施されています。
  • インフラセキュリティ: Microsoftは、AVSを稼働させる基盤となるハードウェアとAzureネットワークのセキュリティを管理しています。
  • コンプライアンス認証: AVSは、ISO 27001, SOC 2, HIPAAなどの主要なコンプライアンス認証を取得しています。
  • Azure Security Center / Azure Defender: Azure Security Center (現在はMicrosoft Defender for Cloudに統合) を利用して、AVS上のVM(エージェントをインストールした場合)を含むAzureリソース全体のセキュリティ状態を可視化し、脅威の検出や脆弱性管理を行うことができます。

9.2 VMware NSX-T Data Centerによるネットワークセキュリティ

NSX-Tは、AVS環境内のネットワークセキュリティの核となります。

  • マイクロセグメンテーション: 前述のNSX-T分散ファイアウォール (DFW) により、VM間の通信を細かく制御できます。これにより、脅威がネットワーク内で横方向に拡散するのを防ぐことができます(Lateral Movementの防止)。アプリケーションのティア(Web, App, DBなど)に基づいて、それぞれの間の通信を必要最低限に制限することが可能です。
  • エッジファイアウォール: AVSプライベートクラウドの外部との通信は、NSX-TのTier-0またはTier-1ゲートウェイに設定されたファイアウォールルールによって制御できます。Azure VNetやオンプレミス、インターネットとの境界にセキュリティポリシーを適用します。

9.3 アクセス制御とアイデンティティ管理

  • Azure Role-Based Access Control (RBAC): Azure portalでのAVSプライベートクラウドの管理(デプロイ、スケーリングなど)は、Azure RBACによって制御されます。
  • vCenter Server権限: AVS環境内のvCenter Serverへのアクセスは、VMwareの組み込みロールやカスタムロールを使用して制御します。Azure Active Directory (AAD) と連携させて、AADユーザーやグループにvCenterの権限を割り当てることが可能です。これにより、既存のID管理システムを活用してAVS環境へのアクセスを管理できます。
  • NSX-T Manager権限: NSX-T Managerへのアクセスも、ロールベースのアクセス制御によって管理されます。

9.4 暗号化

  • vSAN ストレージ暗号化: vSANに保存されるデータは、保存時に自動的に暗号化されます。暗号化キーは、Azure Key Vaultと連携して管理できます。
  • ネットワーク通信の暗号化: AVSプライベートクラウドとAzure VNet間のExpressRoute接続は、通常暗号化されません。必要に応じて、IPsecトンネルなどの追加の暗号化を構成できます。オンプレミスとAzure間のExpressRouteも同様です。HCXを利用する場合、移行トラフィックはデフォルトで暗号化されます。

9.5 ログと監視

Azure MonitorやLog Analyticsと連携して、AVS環境でのイベントログ(vCenterイベント、NSX-Tログなど)やパフォーマンスデータを収集し、不審なアクティビティの検出やセキュリティインシデントの分析に活用できます。

9.6 お客様の責任範囲

Microsoftが基盤インフラとVMwareソフトウェアのライフサイクルを管理する一方、お客様はAVS環境内のセキュリティ構成(NSX-Tファイアウォールルール、vCenter権限設定)、仮想マシン内のセキュリティ(OSパッチ、アンチウイルス、アプリケーションセキュリティ)、データのバックアップ、および全体的なコンプライアンス確保に責任を持ちます。これは、クラウドにおける共有責任モデルに基づいています。

第10章:AVSのデプロイと利用開始までの流れ

AVSを実際に利用開始するまでの大まかなステップを紹介します。

10.1 事前準備と計画

  1. 要件定義: 移行したいワークロードや実現したいユースケース(移行、DR、拡張など)を明確にします。
  2. サイジング: ワークロードのリソース要件(CPU、メモリ、ストレージ容量、IOPS)に基づいて、必要なAVSホスト数、ホストの種類、およびクラスター構成を見積もります。VMware vRealize Operations (vROps) などのサイジングツールが役立ちます。
  3. ネットワーク設計: AVS管理ネットワークとワークロードネットワークのIPアドレス範囲を決定します。オンプレミス、AVS、Azure VNet間の接続方法(ExpressRoute, VPN)とルーティング計画を設計します。
  4. Azureサブスクリプションの準備: AVSサービスを利用可能なAzureサブスクリプションを準備します。クォータの確認と必要に応じた増加申請を行います。
  5. Azure VNetの準備: AVSプライベートクラウドを接続するAzure VNetを準備または作成します。

10.2 AVSプライベートクラウドのデプロイ

  1. Azure portalからデプロイ: Azure portalにログインし、「Azure VMware Solution」サービスを検索します。
  2. プライベートクラウドの作成: 新しいAVSプライベートクラウドを作成します。この際に、リージョン、リソースグループ、プライベートクラウド名、AVS管理ネットワーク用IPアドレス範囲、ホストの種類、および初期ホスト数(通常3ノード以上)を指定します。
  3. デプロイ実行: デプロイプロセスを開始します。これにより、Azureデータセンター内に指定した構成のベアメタルサーバーがプロビジョニングされ、VMwareソフトウェアスタック(ESXi, vCenter, vSAN, NSX-T)が自動的にインストール・構成されます。このプロセスには数時間かかる場合があります。

10.3 初期設定

  1. vCenter ServerとNSX-T Managerへの接続: デプロイ完了後、Azure portalからvCenter ServerとNSX-T Managerのアクセス情報(URL、ユーザー名、パスワード)を取得します。オンプレミスやVNet上の管理用ジャンプホストなどから、vSphere ClientやNSX Manager GUIに接続します。
  2. Azure VNetとの接続確認: AVSプライベートクラウドとAzure VNet間のExpressRoute接続が確立されていることを確認します。
  3. オンプレミスとの接続設定: 必要に応じて、Azure VNetを経由してオンプレミス環境とのExpressRouteまたはVPN接続を設定し、ルーティングを構成します。
  4. NSX-Tネットワーク構成: AVS上のワークロード用ネットワークセグメントを作成し、ルーティングやファイアウォールルールなど、必要なNSX-Tネットワーク設定を行います。
  5. Active Directory連携: vCenter ServerとActive Directory (AD) を連携させ、既存のADユーザー/グループによるvCenterへのアクセス制御を設定します。
  6. Azureサービス連携設定: Azure StorageなどのAzureサービスとの連携に必要なネットワークや認証設定を行います。

10.4 ワークロード移行

  • HCXの構成: HCXを利用する場合、オンプレミス環境にHCX Connectorをデプロイし、AVSのHCX Cloud Managerとペアリング設定を行います。その後、ネットワーク延伸や移行計画に基づいた移行タイプ(vMotion, Bulk Migrationなど)を選択し、ワークロードの移行を実行します。
  • その他の方法: vSphere Replicationなど、他の移行方法を選択した場合は、それぞれの方法に応じた設定と移行作業を行います。

10.5 運用開始

移行完了後、AVS環境での本格的な運用を開始します。監視、バックアップ、セキュリティ管理、パッチ管理(OS/アプリ)、キャパシティ管理などの運用タスクを実施します。必要に応じて、ホストの追加/削除によるスケーリングを行います。

第11章:オンプレミスVMwareとの違い

AVSはオンプレミスのVMware環境と非常に似ていますが、いくつかの重要な違いがあります。これらの違いを理解しておくことは、運用上の期待値を適切に設定する上で役立ちます。

  • 基盤ハードウェアへの直接アクセス不可: お客様はAVSプライベートクラウドを構成する物理サーバー(ESXiホスト)に直接ログインして管理することはできません。ハードウェアのメンテナンスやトラブルシューティングはMicrosoftが行います。
  • VMwareソフトウェアのライフサイクル管理: ESXi、vCenter Server、NSX-T、vSANのバージョンアップグレードやパッチ適用は、お客様の承認またはスケジュールに基づきMicrosoftが行います。お客様はソフトウェアのインストールや基盤設定を変更することはできません。
  • ハードウェア選択の制限: 利用可能なホストの種類は、Microsoftが提供するオプションに限られます。オンプレミスのように自由にハードウェアを選定することはできません。
  • ストレージの制約: プライマリストレージはvSANに限定されます(外部ストレージの直接接続はできません)。ただし、Azure Storageとの連携は可能です。vSANの構成パラメータにも一部制限がある場合があります。
  • ネットワークの統合: NSX-TがAzure VNetと統合されている点が、オンプレミス環境とは異なります。外部ネットワークとの接続はAzure VNetを経由します。
  • ライセンスモデル: AVSはホストベースの従量課金またはリザーブドインスタンスとして提供され、VMwareソフトウェアライセンスは含まれています。オンプレミスのような永続ライセンス購入モデルとは異なります。
  • サポート体制: MicrosoftとVMwareの共同サポートモデルとなります。

これらの違いは、AVSが「フルマネージドサービス」であることに起因します。お客様は基盤管理から解放される代わりに、一部の自由度が制限されます。しかし、エンタープライズワークロードをクラウドに移行し、運用負担を軽減するという目的においては、これらの違いはメリットとして捉えられることが多いでしょう。

第12章:まとめと次のステップ

Azure VMware Solution (AVS) は、既存のVMware環境をMicrosoft Azure上に拡張または移行するための強力なソリューションです。オンプレミスで培ったスキル、ツール、プロセスを最大限に活用しながら、Azureのグローバルインフラストラクチャ、スケーラビリティ、そして広範なネイティブサービスとの連携というクラウドのメリットを享受できます。

このガイドでは、AVSの基本概念から始まり、アーキテクチャ、利点、ユースケース、ネットワーク、ストレージ、管理、移行、コスト、セキュリティ、そしてオンプレミスとの違いまで、幅広い側面を詳細に解説しました。AVSがデータセンター移行の課題を解決し、災害対策やデータセンター拡張、アプリケーションモダナイゼーションの基盤となりうることをご理解いただけたかと思います。

AVSは、特に以下のような組織に検討価値があります。

  • 大規模なVMware環境を所有しており、迅速かつ低リスクでクラウド移行を進めたい。
  • VMwareの運用スキルセットが社内に豊富にある。
  • アプリケーションのリファクタリングやリプラットフォームに多大な工数をかけたくないレガシーシステムを抱えている。
  • オンプレミスのデータセンター容量に限界がきている。
  • 物理的なDRサイト構築・維持のコストや複雑さを削減したい。
  • VMware HorizonによるVDI環境をクラウドで提供したい。

AVSの導入は、Azureへの旅の始まりに過ぎません。AVSに移行したワークロードとAzureネイティブサービスを組み合わせることで、ITインフラストラクチャの最適化と、新たなデジタルサービスの創出を加速させることができます。

次のステップとして、以下の行動を推奨します。

  1. Azure VMware Solutionの公式ドキュメントを確認する: Microsoft Docsには、最新の情報、詳細な技術仕様、チュートリアル、価格情報などが掲載されています。
  2. AVSサイジングツールを利用する: 移行したいワークロードの要件を入力し、必要なAVSホスト数を見積もります。
  3. Azureの専門家またはパートナーに相談する: AVSの導入経験を持つMicrosoftの担当者や認定パートナーから、具体的な計画策定やPoC(概念実証)の支援を受けます。
  4. 小規模なPoCを実施する: 実際のワークロードの一部を使ってAVS環境を構築し、ネットワーク接続、移行、基本的なアプリケーション動作などをテストします。
  5. トレーニングやウェビナーに参加する: AVSに関する公式またはパートナー提供のトレーニングに参加し、さらに知識を深めます。

AVSは、オンプレミスVMwareのパワーとAzureクラウドの柔軟性・拡張性を組み合わせた、ハイブリッドクラウド戦略における重要なピースです。このガイドが、皆様のAVS理解と活用に向けた第一歩となることを願っています。


コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

上部へスクロール