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

當在討論於案子內，應該要規劃多少個Service Units的NSX Advanced Load Balancer授權時，當然需要與客戶架構師做實際應用遞送效能需求上的討論。此時會碰到下面的三種狀況之一：

  1. 客戶規劃師很清楚業務需要的應用遞送容量，或許是基於現有或之前生產環境的交易數據進行推估，或在開發時就預先進行假設。客戶能夠很明確地提供推估值，比如說每秒可以支持的新SSL交易量 (SSL TPS) 是多少，業務要能夠提供的對外頻寬是多少，等等。
  2. 客戶無法確認業務需要的應用遞送容量，但能夠提供在之前環境所使用的競爭友商負載平衡器設備型號作為參考比較。
  3. 客戶團隊自己也還無法確認後續需要的應用遞送容量會是多少，也沒有參考數值。比如說現在要開案建立一個私有雲，可是會住進來的應用還未確定，各個業務也尚在開發，還不確定交易量會有多少。

說真的，第一種是理想狀態，但不常碰到，除非是極為重要的核心業務，我的經驗是大部分企業在規劃時其實很難就先預知生產時的業務交易量會是多少。而第二種與第三種的狀況則相當常見佔了大多數，但此時與客戶提出的規劃建議，仍然還是需要相關的理據來進行討論。

因此接下來兩篇的網誌我想要逐一地與大家討論，在已經確定要購買NSX Advanced Load Balancer時，基於上面不同的狀況，Service Unit的數量通常是如何決定。那麼馬上就先討論第一種情況：

全新環境，企業可提出明確交易需求量來進行應用遞送效能估算

通常在硬體負載平衡器的Datasheet內會列出非常多的相關連線數據，比如說L4/L7 Throughput，Connection Per Seconds，HTTP Request Per Seconds，SSL Transaction Per Seconds，SSL Throughput等等。在NSX ALB的效能規劃上比較特別，因為客戶需要付費購買的僅有『CPU效能』（Service Unit），而一台服務引擎上面是有多少的Memory、Storage空間，甚至如果實體機的網卡數量都可以讓客戶自行調整，不佔用授權。因此我們在規劃時僅需要著重在『吃CPU效能』的相關數據。簡單來說，當企業可以提出明確的交易需求量，我們僅看下面這兩個值：

  • SSL TPS （每秒新建立的SSL交易量）。
  • SSL Throughput （服務需要的南北向SSL加密傳輸頻寬）。

因為真正需要大量CPU運算效能的就是上面的SSL加解密部分。而其他比如說L4 Throughput…不足時加網卡就好。L4 / L7 Current Connections…不足時加Memory就好。這些都是客戶自行投資資源即可，不需要耗用授權，就能夠做到的事。

因此很簡單的Guideline是這樣：

  • 如果用戶用於SSL的憑證是採用ECC型態，則一個vCPU可以提供2,000~2,500個SSL TPS。但若客戶用於SSL的憑證是採用RSA型態，一個vCPU僅提供約700~900個SSL TPS。因此在每個案子我們都會與客戶進行說明，並建議他們採用ECC型態憑證
  • 每 1 Gbps 的SSL 南北向傳輸頻寬，需要耗用 1個vCPU來進行傳輸封包的加解密

舉個例子。若客戶告知目前規劃的環境，業務應用遞送的總需求量約是每秒要支持10,000個HTTP/S的新連線，南北向的傳輸量需要3 Gbps，並且憑證可以採用ECC型態。此時一個非常簡單的估算是

  • ECC憑證用比較保守的 1 個vCPU支持2,000個SSL TPS來估算，則10,000個每秒SSL新連線會需要5個vCPU (Service Unit)
  • 3 Gbps的南北向SSL傳輸頻寬，需要 3 Gbps / 1 Gbps = 3 個vCPU (Service Unit)

5+3 合起來是8個Service Unit。但還沒結束，要考慮備援機制。此時有兩種狀況：

  • 如果是HTTP業務，支持採用Active/Active機制，要支持8個vCPU的總效能。此時我們可以規劃部署5台服務引擎做AA，每台服務引擎2個vCPU。這樣即使在單台失效的狀況下，仍然可以提供足夠的總效能。因此考慮備援後，需要的vCPU (Service Unit) 是 5×2 = 10個
  • 如果要採用Active/Standby的話就比較慘，需要兩台服務引擎單台就要能運作8 vCPU。此時需要的vCPU (Service Unit) 是 8×2 = 16 個

那當然應該用Active/Active機制買10個Service Units就好呀～～

好先簡單談到這邊，上面的運算流程應該不會太複雜。但這幾年實際銷售NSX Advanced Load Balancer的狀況是，客戶能夠明確提出『交易量需求就是這樣』的並不多。絕大部分的案子，都會落在本文一開始提出的2/3點這邊，因此我們下篇就繼續進行這兩種狀況的討論。