虛擬雲網路

網路虛擬化NSX 技術文章系列二百五十六: NSX Application Platform簡介與配置流程(一)

作者: 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安裝前,相關的底層需求準備。

相关文章

评论

发表评论

电子邮件地址不会被公开。

This site uses Akismet to reduce spam. Learn how your comment data is processed.