作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

在 NSX-T 3.2版正式GA後，一個相當大的架構改變是新出現的構件：NSX Application Platform，簡稱為 NAPP。VMware把許多重要NSX於安全及監控的新功能移轉至NAPP平台上面執行。因應這樣的架構變化，我想用幾篇網誌與大家就NSX Application Platform的平台簡述、可運作的方案、安裝流程與相關準備等議題一一進行介紹。

那麼第一個問題：有什麼新功能會跑在 NSX Application Platform上呢？

後續還會增加，但在 NSX-T 3.2內，需要運作在NAPP內的包含了下面四個服務：

  • Metrics：新功能，用來進行基於時間的持續監控。 比如說客戶希望能夠長時間紀錄如 NSX Edge Uplink / Downlink介面的流量、掉包、error rate，Edge與Manager等的CPU / Memory使用量，此時相關之資訊會不間斷地記錄在NAPP平台內。因為是新功能，目前3.2版本內Metrics相關資訊僅能透過API抓取，後續將會建立UI介面供管理者維運使用。
  • NSX Intelligence：從3.0版開始的功能，之前網誌內我們也簡單與大家介紹過。Intelligence持續收集各個受NSX納管虛機的網路流資訊，顯示虛機間的網路交互連結關係與構件資訊。更進一步，可透過這些資訊提供業務系統間/內的微分段防火牆配置政策建議，同時也可整合NSX不同安全功能顯示異常網路流告警。啟用後，管理者可以由”Plan & Troubleshoot”介面內的”Discover & Plan”介面使用Intelligence功能。
  • NSX Network Detection and Response (NDR)：3.2版後NSX整合Lastline相關功能，由Gateway (Edge) 及 Transport Node (vSphere Host) 收集網路流資訊到NAPP平台，再透過不同Network Traffic Analytics技術對網路流進行正規化整理與學習，更進一步送往VMware ATP (Advanced Threat Prevention) 雲服務進行統合整理與分析。
  • NSX Malware Prevention：同樣是3.2版後NSX整合Lastline相關功能。NSX由雲服務取得惡意檔案相關資訊後，於NAPP平台內進行檔案比對，同時也將未知檔案上傳至VMware ATP (Advanced Threat Prevention) 雲服務內沙箱 (sandbox) 進行檔案安全性驗證

這些新舊應用在運作時都有共通的底層服務需求，包含了訊息傳遞 (Message Queue)，需要資料庫進行組態存放 (Configuration Data)，需要資料庫進行持續物件儲存 (Persistent Object Storage)，基於時間序列的大量資料查詢 (Time-Series Storage and Analytics)，憑證管理 (Certification Management) 等等。更重要的，由於需要分析及儲存的資料量大，整個系統必須要能夠很容易地擴張 (Scale-Out) 提供給大型環境使用。這是各個監控與安全分析新方案在建立時，除了功能本身以外，產品部門於底層系統架構必須要考量的點。

先舉一個實際的例子彰顯原本的問題：NSX Intelligence是由推出開始客戶就相當喜歡的功能。但在3.0/3.1版有一個大問題：Intelligence可支持的範圍太小。即使我們以大型Intelligence Appliance進行部署，最多能支援 100台 vSphere hosts / 5000個虛機，僅一個月的存放資訊。但這個量遠低於NSX-T系統本身的最大支持容量 (1600 vSphere hosts)，即使功能強大，但在實際大型客戶環境內可用性就大幅降低了。

因此，當客戶與前端技術人員不斷對產品部門提出更多新功能、擴充性能的要求時，產品部門必須在新系統架構設計時考慮到：

  • 用共通、穩定、標準化、開放、易於開發的底層服務提供相關應用需求功能。
  • 基於微服務 (Micro-Service) 架構，相關底層服務及上層應用構件必須能夠很容易擴張 (Scale-Out)，提供上層應用更高容量與效能
  • 第三點和目前IT環境的轉變及VMware本身公司策略相關：系統架構不能僅綁定在 vSphere上。必須能夠在不同的雲環境、不同平台也能運作

什麼意思呢？由NSX Application Platform開始，架構上有一個重要的轉變：安裝前，環境內首先必須先有一組資源足夠的Kubernetes環境。然後管理者透過NSX，在K8S內配置需求的底層服務如 kafka, MiniO, contour/envoy, druid, Spark, Corfu, redis等等並搭建NAPP應用平台。此時，基於Kubernetes平台本身及對應服務構件的特性，剛剛提到的『穩定、共用、標準化、開源、效能強化易於擴張、跨平台』等等功能，都能夠更輕易地達到。

回到前面NSX Intelligence的例子：架構改變後，在NSX-T 3.2 GA版本內，初期支持的容量要提升到256 hosts, 10,000個虛機，網路流存放3個月。後續 QA要進一步測試則提升到512 hosts，20,000個虛機，同樣三個月的網路流存放量。可以看到，與原始版本比起來，性能上的提升是相當明顯的。

但有所得就有所失。這邊大家會看到VMware在發布產品上一個重要的轉變：以前我們要安裝新產品新構件時，通常是提供虛機的OVA檔，然後大家在 vCenter / vSphere內匯入並配置這個OVA檔。現在不是了。我們或客戶必須先把Kubernetes的平台準備好，然後把新應用安裝到K8S平台上。各位，時代改變了啊！不會Kubernetes不行啊～～

因此在下一篇，我想和大家討論的是，要進行NSX Application Platform安裝前，相關的底層需求準備。