Microsoft Azure Network Adapter (MANA) overviewでまず押さえるべき答えは、MANAが「Azure VM向けの次世代ネットワークインターフェイス」であり、Azure Boostの一部としてVMのネットワーク性能と可用性を高めるための基盤だという点です。管理者が今すぐ確認すべきことは、MANAそのものを手動で有効化するかどうかではなく、対象VMがMANA対応ハードウェアに配置されても問題なく動くOS・ドライバー・カスタムイメージ・DPDK・NVA構成になっているかです。Microsoft Learnの日本語版「Microsoft Azure ネットワーク アダプターの概要」は2026年5月6日に更新されており、MANAの互換性、DPDK要件、性能評価の考え方が整理されています。(Microsoft Learn)
とくに影響を受けやすいのは、高速ネットワークを有効にした既存VMシリーズ、独自のカスタムイメージ、DPDKベースのアプリケーション、ネットワーク仮想アプライアンス（NVA）です。一般的なLinux VMやWindows VMでも、古いカーネルや不足したドライバーを使っている場合は、MANAの性能を十分に使えない可能性があります。この記事では、Azure NetworkingにおけるMicrosoft Azure Network Adapter (MANA) overviewの変更点、影響範囲、管理者や開発者が確認すべき設定・移行・展開上の注意点を、実務で使えるチェックリストとして整理します。
Microsoft Azure Network Adapter (MANA) overviewで何が示されたのか
Microsoft Azure Network Adapter（MANA）は、Azure VM向けにMicrosoftが設計した次世代ネットワークインターフェイスです。公式概要では、MANAはAzure Boostのコンポーネントであり、WindowsおよびLinux向けに安定した前方互換性のあるデバイスドライバーを提供するものと説明されています。つまり、単なるNIC名の変更ではなく、Azureの基盤側ネットワークをより高性能・高信頼にするためのハードウェアとソフトウェアの組み合わせです。(Microsoft Learn)
MANAを理解するうえで重要なのは、「高速ネットワーク（Accelerated Networking）」との関係です。高速ネットワークはSR-IOVを使い、VMのネットワークトラフィックをホストの仮想スイッチ経由ではなく、より直接的なデータパスで処理します。これにより、待ち時間、ジッター、CPU使用率の低減が期待できます。MANAはこの高速ネットワークの次世代ハードウェアとして位置づけると理解しやすいでしょう。(Microsoft Learn)
ただし、MANA対応ハードウェアにVMが配置されたからといって、必ずしもすべての環境で自動的に最大性能が出るわけではありません。公式ドキュメントでは、サポート対象OSを使っていても、Linuxではカーネル更新、Windowsではドライバーのインストールが必要になる場合があると説明されています。また、MANA対象VMはMellanoxの旧世代NICとMANA NICの両方のハードウェアで動作し得るため、既存のmlx4やmlx5のサポートも引き続き必要です。(Microsoft Learn)
2026年5月6日更新で重要なのは「既存VMシリーズへの影響」
今回の確認で特に重要なのは、MANAの概要だけでなく、2026年5月6日に更新された「既存のVMシリーズに対するMANAサポート」の情報です。公式情報では、高速ネットワークを使用している既存VMサイズの利用者向けに、既存VMシリーズがMANA対応ハードウェアに配置される可能性があること、ただし既存シリーズはMANA以前に導入されたため、性能・信頼性・回復性の向上を完全には享受できない場合があることが説明されています。(Microsoft Learn)
実務上のポイントは、既存VMを使い続けられる一方で、ワークロードがMANAと互換性を持つかを確認する必要があることです。既存VMは、停止・割り当て解除後の開始操作や標準的なAzureメンテナンスイベントの後に、MANA対応ハードウェアへ配置される可能性があります。新規作成された対象VMシリーズも、MANA対応ハードウェアに配置される可能性があります。(Microsoft Learn)
一方で、高速ネットワークが有効になっていないVMについては、公式情報では追加アクションは不要とされています。MANA対応ハードウェアに配置される可能性はあっても、ワークロードは変更なしで動作する想定です。つまり、最初の切り分けは「そのVMで高速ネットワークが有効かどうか」です。(Microsoft Learn)
対象になり得るVMシリーズ
既存VMシリーズ向けの公式情報では、MANA対応ハードウェアに配置され得るVMシリーズとして、A、B、D、E、Eb、F、G、Lファミリの一部が挙げられています。対象シリーズに含まれる場合、ネットワーク改善を十分に活用するには追加検証が必要になる場合があります。(Microsoft Learn)
| VMファミリ | 対象例 | 管理者が見るべきポイント |
|---|---|---|
| Aファミリ | Av2 | 提供終了が案内されている系列を使っていないか確認する |
| Bファミリ | Bsv2 | 小規模VMでも高速ネットワーク有効時は確認対象になる |
| Dファミリ | Dv3、Dsv3、Dv4、Dsv4、Dv5、Dsv5、Dpsv6など | 業務アプリ、DB、バッチ基盤で使われやすいため棚卸し優先度が高い |
| Eファミリ | Ev3、Esv3、Ev4、Esv4、Ev5、Esv5、Epsv6など | メモリ最適化ワークロードの性能検証が重要 |
| Ebファミリ | Ebsv5、Ebdsv5 | ストレージ・ネットワーク負荷が高い用途では実測確認を行う |
| Fファミリ | F、Fs、Fsv2 | コンピューティング最適化用途でパケット処理が多い場合に注意 |
| Gファミリ | G、Gs | 旧世代利用時は移行計画もあわせて確認する |
| Lファミリ | Ls | ストレージ最適化ワークロードではアプリ側のネットワーク依存も確認する |
表に含まれる一部のシリーズには提供終了が案内されているものがあります。該当するVMを使っている場合は、MANA対応の確認だけでなく、廃止に伴う移行計画も同時に進めるべきです。公式情報でも、対象の旧VMシリーズを使っている場合は、サービス中断、容量制限、強制的な割り当て解除を避けるため、移行ガイドを参照して置き換えシリーズへ切り替えることが推奨されています。(Microsoft Learn)
影響範囲を判断するための早見表
MANA対応ハードウェアへの配置は、多くの一般的なVMでは問題なく進むことが期待されています。しかし、ネットワークドライバー、SR-IOV、DPDK、NVA、カスタムイメージに依存している環境では、事前確認が欠かせません。
| 環境・ワークロード | 影響の可能性 | 確認すべきこと |
|---|---|---|
| 高速ネットワークが無効なVM | 低い | 原則として追加アクション不要。ただし対象VMの棚卸しはしておく |
| 高速ネットワークが有効な一般的なLinux VM | 中 | MANA対応カーネル、mana.ko、VF統計値の増加を確認する |
| 高速ネットワークが有効なWindows VM | 中 | Microsoft Azure Network Adapterの表示、MANAドライバー、統計値の増加を確認する |
| カスタムイメージ | 高い | MANA、ConnectX系、動的VF失効、ネットワーク管理ツールの競合を確認する |
| DPDKベースのアプリケーション | 高い | MANA向けEAL引数、Linuxカーネル、rdma-core、DPDKバージョンを確認する |
| NVA | 高い | ベンダーのMANA対応状況、必要に応じた一時例外タグ、移行計画を確認する |
| AKSインスタンス | 低い | 公式情報では影響なし。ただし個別のアドオンやNVA連携は別途確認する |
| VNet暗号化 | 低い | 公式情報ではMANAハードウェア配置後も期待どおり動作するとされている |
既存VMシリーズ向けの公式FAQでは、AKSインスタンスは影響を受けず、VNet暗号化もMANAハードウェア上で期待どおり動作するとされています。一方で、DPDKベースのアプリケーションやNVAは影響を受ける可能性があり、MANA対応状況の確認が必要です。(Microsoft Learn)
まず確認すべき設定は「高速ネットワークが有効か」
最初に確認するのは、対象VMのNICで高速ネットワークが有効になっているかです。Linux VM、Windows VMのMANA確認手順では、Azure portalのVM画面から「ネットワーク」を開き、対象NICの概要で高速ネットワークが有効か無効かを確認する手順が示されています。(Microsoft Learn) (Microsoft Learn)
高速ネットワークが有効な場合は、次にVMサイズが高速ネットワークをサポートしているかを確認します。Azure CLIでは、VM SKUのAcceleratedNetworkingEnabled能力を一覧化できます。公式ドキュメントでは、次のようなコマンド例が示されています。(Microsoft Learn)
az vm list-skus \
--location japaneast \
--all true \
--resource-type virtualMachines \
--query '[].{size:size, name:name, acceleratedNetworkingEnabled: capabilities[?name==`AcceleratedNetworkingEnabled`].value | [0]}' \
--output tableここで注意したいのは、確認対象が「VMサイズ」だけでは終わらないことです。同じVMサイズでも、OS、カーネル、ドライバー、アプリケーションのNICバインド方法、カスタムイメージの作り方によって結果が変わります。とくに本番環境では、ポータル上の有効・無効だけで判断せず、VM内でMANAデバイスが見えているか、実際にトラフィックがMANA経由で流れているかまで確認してください。
Linux VMで確認すべきMANA設定
Linux VMでは、MANAが使えるかどうかを「ポータル」「PCIデバイス」「カーネルドライバー」「トラフィック統計」の順に確認します。公式手順では、MANA機能セットにはホストハードウェアとVMソフトウェアの両方が必要であるため、複数のチェックが必要とされています。(Microsoft Learn)
まず、VM内でlspciを実行し、Microsoft CorporationのMANAデバイスが見えるか確認します。
lspci出力例として、次のようなデバイスが表示されます。
7870:00:00.0 Ethernet controller: Microsoft Corporation Device 00ba次に、MANA Ethernetドライバーが入っているか確認します。
grep /mana*.ko /lib/modules/$(uname -r)/modules.builtin || find /lib/modules/$(uname -r)/kernel -name mana*.ko*期待される出力例は次のとおりです。
kernel/drivers/net/ethernet/microsoft/mana/mana.koLinuxでは、MANA用のEthernetドライバーはカーネル5.15以降に含まれています。ただし、InfiniBand/RDMAやDPDKなどの機能は、カーネルのバージョンやバックポート状況によって確認が必要です。公式情報では、カーネル6.2にはInfiniBand/RDMAやDPDKなどに対応するLinuxサポートが含まれ、古いカーネルやフォークされたカーネルではバックポートが必要と説明されています。(Microsoft Learn)
最後に、MANA経由でトラフィックが流れているかを確認します。単にデバイスが見えるだけでは不十分です。ethtoolでVFのパケット数・バイト数が増えているかを見ます。
ethtool -S eth0 | grep -E "^[ \t]+vf"公式手順では、VFに関連する値が0のまま、または増加しない場合は、仮想関数を使用していないと説明されています。つまり、MANAデバイスが存在していても、実際のデータパスで使われていない可能性があります。(Microsoft Learn)
Windows VMで確認すべきMANA設定
Windows VMでは、PowerShellまたはデバイスマネージャーでMANAドライバーの有無を確認します。公式手順では、Get-NetAdapterで「Microsoft Azure Network Adapter」が表示されるかを確認する方法が示されています。(Microsoft Learn)
Get-NetAdapterMicrosoft Azure Network Adapterが表示されない場合は、VMが別のネットワークアダプターを持つハードウェアに配置されているか、OS側がMANAをサポートしていない可能性があります。MANAデバイス自体が存在するかは、次のコマンドで確認できます。
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^PCI\\VEN_1414&DEV_00BA&' }Get-PnpDeviceではMANAデバイスが見えるのに、Get-NetAdapterに表示されない場合は、OS側のMANAドライバーサポートが不足していると判断できます。VMがポータルとハードウェアの両方でMANAをサポートしているにもかかわらずドライバーがない場合は、Windows用ドライバーの導入を検討します。(Microsoft Learn)
実際にMANA経由でトラフィックが流れているかは、次のように統計値で確認します。
Get-NetAdapter |
Where-Object InterfaceDescription -Like "*Microsoft Azure Network Adapter*" |
Get-NetAdapterStatisticsMANAに関連する値が0のまま、または増加しない場合は、仮想関数を使用していない可能性があります。WindowsでもLinuxと同じく、「アダプター名が見えること」と「トラフィックが流れていること」は分けて確認するのが重要です。(Microsoft Learn)
カスタムイメージで失敗しやすいポイント
カスタムイメージを使っている環境では、MANA対応で最もトラブルが起きやすくなります。高速ネットワークをサポートするカスタムイメージには、Azureプラットフォームで使われるNICのSR-IOVを有効にするドライバーが必要です。対象には、NVIDIA ConnectX-3、ConnectX-4 Lx、ConnectX-5に加えて、Microsoft Azure Network Adapter（MANA）が含まれます。(Microsoft Learn)
よくある失敗は、旧世代のMellanox前提で作ったイメージから、不要だと思ってmlx4やmlx5関連のサポートを外してしまうことです。MANA対象VMは、MellanoxとMANAの両方のハードウェアで実行される可能性があるため、MANAだけを入れればよいわけではありません。既存のmlx4、mlx5サポートも残しておく必要があります。(Microsoft Learn)
もう一つの落とし穴は、アプリケーションやネットワーク設定が仮想関数（VF）に直接依存することです。ホストメンテナンスやライブマイグレーションの場面では、VFが動的に失効し、メンテナンス後に復元されることがあります。公式ドキュメントでは、接続を維持するために、アプリケーションはVFではなく合成デバイスにバインドする必要があると説明されています。(Microsoft Learn)
カスタムイメージでは、複数のネットワーク管理ツールを同時に使う構成にも注意が必要です。公式情報では、ifupdownやnetworkdなど複数のネットワークインターフェイス管理ツールを同時に使うこと、複数インターフェイスでdhclientを直接実行することは避けるよう推奨されています。また、azure-vm-utils 0.6.0以降と、SR-IOVデバイスをアンマネージドとして扱うudevルールの確認も重要です。(Microsoft Learn)
DPDKワークロードはMANA向けの初期化変更が必要
DPDKを使っている場合、MANA対応は通常のVMより慎重に扱う必要があります。公式ドキュメントでは、MANAを使うにはDPDK初期化ルーチンの変更が必要であり、従来ハードウェアと比べてPMDのEAL引数が異なること、DPDK初期化前にLinuxカーネルがMANAネットワークインターフェイスの制御を解放する必要があることが説明されています。(Microsoft Learn)
従来のAzure Linux VMでは、mlx4やmlx5ドライバーとハードウェアに依存し、DPDK EALには主にバスアドレスを渡して対象インターフェイスを指定していました。一方、MANAでは「高速ネットワークインターフェイスごとに1つのバスアドレスがある」という前提が成り立たないため、MANA PMDはMACアドレスを使ってバインド対象を決定します。利用可能なVFの一部だけをDPDKで使う場合は、MANAデバイスのバスアドレスとインターフェイスのMACアドレスの両方を--vdev引数に渡す必要があります。(Microsoft Learn)
MANAハードウェア上でDPDKを実行するには、Linuxカーネル6.14以降、またはLinuxカーネル6.14以降のEthernetドライバーとInfiniBandドライバーのバックポートが必要です。加えて、DPDK MANA PMDは直近3つの安定リリース、Libmanaユーザー空間ドライバーはrdma-core v44以降が必要とされています。MANA DPDKはWindowsでは利用できず、Linux VMでのみ動作します。(Microsoft Learn)
DPDKでよくある障害としては、MANAバインドデバイスをDOWNにできずスループットが低下またはゼロになるケース、hugepageが有効化されていないケース、rdma-coreとLinuxカーネルのバージョン不一致によりMANA VFのプローブに失敗するケースがあります。DPDKワークロードでは、単なる疎通確認ではなく、初期化ログ、EALエラー、パケットスループット、rdma-coreとカーネルの整合性まで確認してください。(Microsoft Learn)
NVAはベンダー対応と一時例外タグを必ず確認する
Network Virtual Appliance（NVA）は、MANA対応で特に注意が必要な領域です。公式情報では、既存VMシリーズで実行されているNVAがMANA対応ハードウェアに配置される可能性があるとされています。多くのワークロードは問題なく移行することが期待される一方、NVAは基盤のネットワークハードウェアやドライバーに直接依存するため、固有の影響を受ける可能性があります。(Microsoft Learn)
NVAを運用している場合は、まず利用中のNVAベンダーがMANAを明示的にサポートしているか確認してください。Marketplaceからデプロイした製品だけでなく、ベンダーから直接提供されたイメージ、マネージドサービスとして提供されるNVAも確認対象です。ベンダーのバージョン、推奨VMサイズ、MANA対応ドライバー、アップグレード手順がそろっているかを確認してから本番展開するべきです。(Microsoft Learn)
一時的な回避策として、公式情報ではLegacyVMNVAタグが説明されています。このタグを適用すると、移行が完了するまでNVA VMやVirtual Machine Scale SetsがMANA対応ハードウェアに配置されることを一時的に回避できます。ただし、LegacyVMNVAタグは2026年8月1日より前に適用する必要があり、2027年5月31日以降は無視されます。恒久対策ではなく、移行期間を確保するための一時的な手段として扱うべきです。(Microsoft Learn)
展開・移行時の実務チェックリスト
MANA対応を安全に進めるには、いきなり全VMを更新するのではなく、影響が大きいものから順に棚卸し、検証、展開する流れが現実的です。
| フェーズ | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 棚卸し | 高速ネットワーク有効VM、対象VMシリーズ、OS、カスタムイメージ、NVA、DPDK利用有無を一覧化する | VMサイズだけ見て、OSやアプリ依存を見落とす |
| 互換性確認 | Linuxカーネル、Windowsドライバー、mlx4/mlx5/MANAサポートを確認する | MANAだけ入れて旧世代NICサポートを外す |
| 検証環境 | 本番に近いVMサイズ、NIC数、OS、アプリ設定でテストする | 小さい検証VMだけで判断し、本番の同時接続数を再現しない |
| 性能測定 | 遅延、ジッター、CPU使用率、pps、同時接続、アプリ応答時間を測定する | pingや単純な疎通確認だけで終える |
| 展開 | メンテナンス時間を確保し、停止・割り当て解除、サイズ変更、OS更新を段階的に行う | 高速ネットワークを実行中VMで変更しようとする |
| 監視 | Azure Monitor、アプリログ、NIC統計、DPDKログ、NVAログを確認する | デプロイ直後だけ見て、メンテナンスイベント後の変化を見ない |
高速ネットワークは、実行中のVMで有効にすることはできません。サポートされているVMで高速ネットワークを有効化するには、VMを停止し、割り当て解除した状態にする必要があります。また、AzureプラットフォームはVM内のMellanox NICやMANAドライバーを自動更新しないため、LinuxやFreeBSDではディストリビューションのカーネル更新、Windowsでは必要に応じたドライバー更新を管理者側で行う必要があります。(Microsoft Learn)
既存VMシリーズを使い続ける場合でも、Intelベースのワークロードでは、可能であればIntel v6以降のVMシリーズへサイズ変更することが推奨されています。サイズ変更できない場合やArmベースのワークロードでは、OSをMANA対応に更新し、デプロイまたはサイズ変更後にワークロードの動作を検証する流れが示されています。(Microsoft Learn)
パフォーマンス評価では「VMサイズの上限」と「実ワークロード」を分けて見る
MANA対応ハードウェアに配置されたからといって、VMサイズに設定されたネットワーク上限を超えられるわけではありません。公式情報では、Azureのネットワーク制限は基盤ハードウェアではなくVMサイズに関連付けられており、OSがAzureで使われるすべてのネットワークデバイスをサポートしている場合、MANA対応ハードウェアへの移行で性能変化は想定されないと説明されています。(Microsoft Learn)
一方で、OSがMANAをサポートしていない場合は、ネットワークは自動的にNetVSCネットワークアダプターへフォールバックします。この場合、MANA VFは見えることがあっても、MANAドライバーによってインターフェイスが公開されないことがあります。また、同時接続数が多いワークロードでは性能低下が発生する可能性があります。(Microsoft Learn)
そのため、評価では次のように分けて考えると判断しやすくなります。
| 評価項目 | 見るべき指標 | 判断基準 |
|---|---|---|
| VMサイズ上限 | AzureのVMサイズごとのネットワーク帯域、NIC数、vCPU数 | そもそも必要帯域を満たすサイズか |
| データパス | MANA VF統計、Get-NetAdapterStatistics、ethtool統計 | MANA経由で実トラフィックが流れているか |
| アプリ性能 | p95/p99レイテンシ、同時接続数、エラー率 | 業務影響が出る遅延や切断がないか |
| CPU負荷 | ネットワーク処理時のCPU使用率 | 高速ネットワークの効果がアプリ側で現れているか |
| メンテナンス耐性 | VF失効・復元後の接続維持 | 合成デバイスへのバインドが適切か |
公式概要でも、VMの種類、OS、アプリケーション、チューニングパラメーターの違いがAzureのネットワーク性能に影響するため、期待するネットワーク性能を得るにはワークロードのベンチマークとテストが推奨されています。(Microsoft Learn)
よくあるトラブルと切り分け方法
MANAデバイスは見えるが性能が上がらない
MANAデバイスが見えていても、実際のトラフィックがMANA VFを通っていないことがあります。Linuxならethtool -S eth0でVF関連のパケット数が増えているか、WindowsならGet-NetAdapterStatisticsでMicrosoft Azure Network Adapterの統計値が増えているかを確認してください。値が0のままなら、MANAを使えていない可能性があります。(Microsoft Learn) (Microsoft Learn)
カスタムイメージで再起動後にネットワークが不安定になる
カスタムイメージでは、VFの動的な削除・追加を正しく処理できない構成が問題になります。ホストメンテナンスやライブマイグレーションではVFが一時的に失効することがあるため、アプリケーションをVFへ直接バインドせず、合成デバイスにバインドして接続を維持する設計にしてください。(Microsoft Learn)
DPDKでスループットがゼロまたは低い
DPDKでは、MANAバインドデバイスをDOWNにできていない、hugepageが有効でない、rdma-coreとカーネルのバージョンが合っていない、といった原因が考えられます。公式トラブルシューティングでは、MANAバインドデバイスをDOWNにできない場合にスループット低下や送信キュー関連のEALエラーが起こり得ること、rdma-coreとLinuxカーネルの不一致がMANA VFのプローブ失敗につながることが説明されています。(Microsoft Learn)
NVAがMANA対応かわからない
NVAでは、まずベンダーのMANA対応状況を確認してください。対応バージョンへ更新できない場合は、LegacyVMNVAタグによる一時回避を検討できますが、期限付きの措置です。2026年8月1日より前に適用する必要があり、2027年5月31日以降は無視されるため、最終的にはMANA対応バージョンへの更新または対応VMシリーズへの移行が必要です。(Microsoft Learn)
管理者と開発者が次に取るべき行動
Microsoft Azure Network Adapter (MANA) overviewの更新を受けて、まず行うべきことは、対象VMの棚卸しです。特に、高速ネットワークが有効な既存VMシリーズ、カスタムイメージ、DPDK、NVAを優先して確認してください。
実務では、次の順序で進めると安全です。
- Azure内のVMを棚卸しし、高速ネットワークが有効なVMを抽出する
- 対象VMシリーズに含まれるか、古い提供終了予定シリーズを使っていないか確認する
- Linuxカーネル、Windowsドライバー、MANA・Mellanox両方のサポート状況を確認する
- カスタムイメージでは、VFの動的失効、合成デバイスへのバインド、udevルール、ネットワーク管理ツールの競合を確認する
- DPDKでは、MANA向けEAL引数、Linuxカーネル6.14以降またはバックポート、rdma-core v44以降、DPDK PMDの対応状況を確認する
- NVAでは、ベンダーのMANA対応バージョンを確認し、必要に応じて期限付きの
LegacyVMNVAタグと移行計画を用意する - 本番前に、実ワークロードに近い条件でレイテンシ、pps、CPU使用率、同時接続数、アプリ応答時間を測定する
MANA対応は、単純な「新しいNICへの切り替え」ではなく、Azure VMのネットワークデータパス、OSドライバー、アプリケーションのNIC利用方法を含めた確認作業です。一般的なVMでは大きな問題なく移行できる可能性がありますが、ネットワーク性能に強く依存する環境ほど、事前検証の価値が高くなります。まずは高速ネットワークが有効なVMを抽出し、MANA対応ハードウェアに配置されても安全に動くかを、OS・ドライバー・ワークロード単位で確認してください。
コメント