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

接續前篇內容，我們說明了當客戶能夠很明確地提出對應業務的應用遞送相關效能需求時，規劃Service Unit授權數量的方式。但絕大部分情況，客戶架構師通常難以提供一個明確的效能要求，會反過來問我們的建議為何。此時狀況通常分為下面兩類，同樣依序進行討論：

規劃更換現有硬體負載平衡器，客戶可提供之前採用應用遞送方案之廠商及型號

這是很常見的狀況，尤其是在之前的應用遞送方案硬體設備已經超過使用年限，或是雖然是新業務，但有類似其他業務的架構可拿來參考。通常客戶願意告知之前的設備是哪個廠牌，什麼型號，安裝了幾對，甚至更進一步還能透過設備介面資訊來提供相關的效能等等。

通常大部分架構規劃師的直覺反應，接下來會需要這樣做：

  • 找出這個設備的Datasheet，然後去查詢相關的應用遞送流量資訊，像是L4/L7新流量數、Throughput、SSL處理能力等等。
  • 翻找NSX Advanced Load Balancer的Datasheet，找上面的相關效能數據如果是對應到NSX ALB的服務引擎，要幾個vCPU多少虛機才能符合。

如果大家是要用另一個廠牌的硬體負載平衡器來更換現有的負載平衡器，這確實是種做法。但如果是採用NSX Advanced Load Balancer，上述的方式一定會Over-Spec，授權數目估算過高（而導致成本過高）。理由是：

  • 傳統硬體負載平衡器無法在效能不足時進行擴充，因此企業在購買時會考量安全性，以業務峰值再加上成長可能性估算，採購過大的機器
  • 絕大部分客戶端的負載平衡器，利用率低於20% 甚至許多在 10% 以下。

但上述因為設備無法隨意擴充的擔憂，在NSX ALB採用軟體部署，採用Active/Active架構，可以在需求時快速進行Scale-Up / Scale-Out的方式下大幅緩解。因此這邊我們的建議是，在與客戶架構師充分討論下，採用現有設備『30% 的效能』來進行規劃。這邊的『30% 效能』是基於大部分環境內，硬體負載平衡器利用率低於15~20%，再加上成長考量來建議。

舉一個很簡單的例子：客戶那邊的現有設備，提供了型號後，查詢相關Datasheet，發現這個設備

  • SSL TPS 在使用 RSA憑證可跑到4.5K/sec。
  • SSL Throughput 可運作至 6 Gbps。

我們抓三成的容量，此時SSL TPS相當於1.4 K 每秒新連線數，若仍必須採用RSA型態憑證（而非在NSX ALB架構下效能較好的ECC型態），以一個vCPU支持750個SSL-TPS來抓需要至少2個vCPU。SSL Throughput要能支持1.8 Gbps，以一個vCPU支持1 Gbps來看需要至少2個vCPU。再加上Active/Active機制的備援考量，另外準備1個vCPU。此時要取代這一對現有的硬體設備，我們可估算 2+2+1=5 個Service Unit的授權即足夠。

上面簡單展示了在客戶可提供現有設備的廠牌及型號下的規劃方式。而另一方面，VMware內部也有相關工具來協助進行相關換算。如果大家有需要討論，歡迎與我們的業務代表及代理商聯繫。

全新環境，客戶規劃師目前也無法確認後續應用遞送效能需求量

這情況也很常碰到，尤其是在企業建立新的私有雲 / 虛擬化環境時。有時可能在客戶進行規劃時，哪些業務會搬進來都還沒確定，唯一明確的需求是後續這個雲環境內得提供負載平衡、網頁代理、Web Application Firewall等服務。那目前在沒有任何可估算的基礎下，建議怎麼做授權規劃呢？

VMware對應到全球不同客戶相關的經驗，建議下面的初始建議值：

  • 估算目前在新的虛擬化環境內的實體伺服器CPU Socket數目
  • 將上面的數目除以四，是目前在此環境內的初期建議NSX ALB Service Unit規劃數目。

比如說新建私有雲環境內，初期規劃vSphere伺服器總共會有16台，共32個CPU Sockets。此時我們會建議在預算允許下，先規劃32/4 = 8 個Service Units作為後續應用遞送服務使用

到此，這兩篇網誌內我們討論了在售前階段，對於NSX Advanced Load Balancer授權數量規劃的三種機制。不敢和大家說上面的估算方式絕對非常『準』，實務上，當然企業能夠提供的資訊越多，我們能夠提供越詳盡的規劃討論。但實際上更重要的，這裡的估算一定要『絕對準確』嗎？

下篇是本系列文的最後一篇，我會以FAQ方式回應於售前階段進行授權規劃，客戶常詢問的相關問題，當然也會就上段這邊的準不準問題，一併提供說明。