Nutanix AHV環境におけるntopを用いた East-West 通信フロー監視構成

はじめに

Nutanix AHV はシンプルな運用と高い安定性を兼ね備えた仮想化基盤として、多くの企業で採用されています。一方で、運用フェーズに入ると次のような声をよく耳にします。

  1. 「VM間通信(East-West通信)が見えない」
  2. 「アプリが遅いが、ネットワークが原因か分からない」
  3. 「内部で何が起きているのか説明できない」

本記事では、4ホスト・1クラスタ構成の Nutanix AHV 環境を例に、ntopng+nProbe を用いて East-West 通信をフローとして可視化する構成を紹介します。

East-West通信とは

East-West通信とは、データセンター内部で発生する横方向の通信を指します。

  1. Web → AP
  2. AP → DB
  3. VM → VM(同一ホスト内を含む)

Nutanix AHV では、これらの通信の多くが 仮想スイッチ(OVS)内で完結するため、物理スイッチのSPANやTAPでは取得できません。

想定する環境構成(4ホスト・1クラスタ)

項目内容
Nutanixクラスタ4ホスト
ハイパーバイザーAHV(Open vSwitch)
VM数約30~80台
通信対象VM間(East-West) + 一部North-South
Flow方式IPFIX
監視基盤専用VMnProbe+ntopng

全体アーキテクチャ概要

図1 Nutanix IPFIXエクスポートのイメージ

この構成のポイント

  • 各AHVホストがIPFIXをエクスポート
  • nProbe VMが高負荷IPFIXを集約・正規化
  • ntopng VMは可視化と分析

※nProbeとntopngは、同一のVMでも構いません

Nutanix AHV 側の設定概要(考え方)

Nutanix AHV では、Open vSwitch(OVS)から IPFIXエクスポートが可能です。

設計時の考慮点

  • Export先:nProbe VMのIPアドレス
  • 送信元:各AHVホスト

実際のNutanix IPFIXエクスポート設定方法

API v4.0でAPI経由でIPFIXのエクスポートを設定することが可能です。こちらのAPIリファレンスにあるCreate an IPFIX Exporter部分です。リファレンスの例ではTCPを利用しておりますが、2055/udpでnProbeが待ち受けるといったシナリオで実際の設定方法例を以下に記載します。実行環境は、Nutanix AHV上の1VMでntopng+nProbeをインストールしたUbuntu上でcurlを実行しております。コマンド内のE.F.G.Hは、Prism CentralのIPアドレスであることにご注意ください。A.B.C.Dは、ntopng+nProbeをインストールし、IPFIXを待ち受けるIPアドレスを設定します。

$REQID=$(cat /proc/sys/kernel/random/uuid)

$curl -k -u admin:pass \
  -X POST \
  'https://E.F.G.H:9440/api/networking/v4.0/config/ipfix-exporters' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H "NTNX-Request-Id: $REQID" \
  --data '{
    "$objectType": "networking.v4.config.IPFIXExporter",
    "name": "LB-stats-exporter",
    "collectorIp": "A.B.C.D",
    "collectorPort": 2055,
    "protocol": "UDP",
    "exportScopes": [
      {
        "$objectType": "networking.v4.config.ExportScope",
        "scopeType": "PE",
        "uuid": "000645b8-42b1-beac-0000-0000000297f5"
      }
    ]
  }'

※uuidは、Prism Element(PE)で取得したuuidとなります。uuidの取得方法は、以下です。

$ curl -k -u admin:pass \
  https://I.J.K.L:9440/PrismGateway/services/rest/v2.0/cluster | egrep -i 'uuid|cluster_uuid|name|version'

※I.J.K.Lは、PEのIPアドレスであることに注意してください。

設定が完了したかは、以下のAPIで確認可能です。

$curl -k -u admin:pass \
     --request GET \
     --url "https://E.F.G.H:9440/api/networking/v4.0/config/ipfix-exporters?$filter=string_sample_data&$limit=50&$orderby=string_sample_data&$page=0"
{"data":[{"$reserved":{"$fv":"v4.r1","ETag":0},"$objectType":"networking.v4.config.IPFIXExporter","extId":"e0eb9c92-16be-48b5-a7fb-26dabf1750c0","metadata":{"$reserved":{"$fv":"v1.r0"},"$objectType":"common.v1.config.Metadata","ownerReferenceId":"00000000-0000-0000-0000-000000000000","ownerUserName":"admin"},"name":"LB-stats-exporter","collectorIp":"A.B.C.D","protocol":"UDP","collectorPort":2055,"exportScopes":[{"$reserved":{"$fv":"v4.r1"},"$objectType":"networking.v4.config.ExportScope","uuid":"000645b8-42b1-beac-0000-0000000297f5","scopeType":"PE"}]}],"$reserved":{"$fv":"v4.r1"},"$objectType":"networking.v4.config.ListIPFIXExportersApiResponse","metadata":{"flags":[{"$reserved":{"$fv":"v1.r0"},"$objectType":"common.v1.config.Flag","name":"hasError","value":false},{"$reserved":{"$fv":"v1.r0"},"$objectType":"common.v1.config.Flag","name":"isPaginated","value":false},{"$reserved":{"$fv":"v1.r0"},"$objectType":"common.v1.config.Flag","name":"isTruncated","value":false}],"$reserved":{"$fv":"v1.r0"},"$objectType":"common.v1.response.ApiResponseMetadata","totalAvailableResults":1}}

nProbe の役割(なぜ必須なのか)

nProbe は単なる「中継」ではありません。

nProbe が担う役割

  • 高速 IPFIX Collector
  • Flowの正規化・拡張
  • ntopng 向け最適化
  • 将来的な NDR / SIEM 連携の起点

ntopng で可視化できる内容

VM間通信の可視化

  • どのVMが
  • どのVMと
  • どれくらい通信しているか

アプリケーションレベル分析

  • Zoom, Teams, Windows Update など
  • 想定外プロトコルの検出

性能・遅延分析

  • RTT(応答時間)
  • 通信量の時間変化

異常検知

  • 突発的な通信増加
  • 内部スキャン挙動
  • 不審な East-West 通信

実運用でのユースケース

ケース①:アプリが遅い

  • Web → AP → DB のどこで遅延しているか可視化
  • ネットワーク or アプリ切り分けが容易

ケース②:セキュリティ調査

  • 夜間に急増する VM間通信を検知
  • ラテラルムーブメントの兆候把握

ケース③:構成最適化

  • 通信量の多いVM配置を見直し
  • AHVホスト間トラフィックの削減

設計・導入時の注意点

サイジングの考え方(目安)

  • 4ホスト構成 → nProbe 1台で十分
  • ntopng は専用VM推奨
  • 保存期間に応じてストレージ設計

よくある落とし穴

  • IPFIX量の過小見積
  • ntopng 単体受信(nProbeなし)
  • 保存期間を考慮しない設計

まとめ

Nutanix AHV 環境では、East-West通信こそが最も重要で、最も見えにくい通信です。

4ホスト・1クラスタ規模であっても、

  • IPFIX による低負荷可視化
  • nProbe による安定した収集
  • ntopng による直感的な分析

を組み合わせることで、
「なんとなく運用」から「説明できる運用」へ進化させることができます。

ntopのお問い合わせ

ntop社製品にご興味のある方は、以下リンクよりいつでも弊社までお問い合わせください。

こんな記事も読まれています

最新記事

おすすめ記事

  1. 特権アカウント管理の方法:Syteca を例とする実動作イメージ [PAM/PASM]

  2. 「リモートデスクトップの操作が遅い!」の原因を高速特定!ntopngによる輻輳原因の究明アプローチを実例でご紹介

  3. Windowsイベントログから不正侵入を暴く

製品カテゴリー

その他の情報

TOP