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

前篇內我們詳盡地就NSX Advanced Load Balancer的授權計價單位Service Unit進行說明。無論客戶是採用地端訂閱授權或雲訂閱授權，購買的Service Unit數量會在NSX ALB的Controller內顯示，而當管理者進行服務引擎 (Service Engine) 部署時，即會由已經購買的授權數量內進行扣除。下圖內即顯示，在Controller的License頁面內，會顯示目前已經購買的授權數量，以及已經使用的Service Units數量。

大家可以看出來這種授權管理方式與傳統硬體負載平衡器，或是虛機型態的Virtual Appliance等，一台一台買的方式相當不同。對應傳統的方式，NSX ALB採用這種授權於Controller集中管理的機制有什麼樣的優勢呢？

授權可以依需求，彈性運用在不同的雲環境，及不同型態的服務引擎配置方式

在授權範圍內，客戶要運作應用遞送服務在私有雲、公有雲、放在不同的地理位置，都是可以的。同樣地，NSX ALB的授權也不會限制Data-Plane的服務引擎必須是什麼形式。管理者可以配置Service Engine虛機，在需要的時候新增服務引擎 (Scale-Out) 或是加大服務引擎虛機 (Scale-Up)。特殊有效能考量時，可以將服務引擎更換成為x86實體機 (Bare-Metal) 形式，或採用限制頻寬方式縮減單一引擎授權的使用亦可。

請與傳統的硬體採購方式進行比較，考慮下列場景：

  • 在地端資料中心有一對非常Powerful的應用遞送設備，但現在因應業務要求要將應用上雲。IT單位可以直接把這對負載平衡器搬到雲上嗎？
  • 原本運作在Azure的負載平衡器虛機，因為商業考量要改轉移到GCP上；或是現有在地端資料中心運作的應用遞送虛機要改到VMware Cloud內。
  • 原本的硬體負載平衡器買得太大，想要拆分成多個效能較小的負載平衡器，放在不同的地點給不同業務使用。

在上述的場景內都可看出是傳統基於硬體或單台Virtual Appliance的方案難以達成的。但在NSX Advanced Load Balancer授權內，對於服務引擎部署的地點、型態沒有任何授權面限制，上述的場景均可輕易滿足：只需要在移轉的環境內進行新服務引擎部署，原本環境內移除舊服務引擎，確保使用授權數量在現有已購的Service Unit內即可，

授權可以彈性在不同應用間依據需求動態配置容量

直接舉個實例，請大家考慮下面的場景：應用部署在主中心，並且另外於公有雲或另一個資料中心進行災備。通常我們在傳統的規劃下，應用遞送部分可能是

  • 對應此重要業務，在主中心的生產環境買一對負載平衡器作Active/Standby保護，提供應用遞送服務
  • 災備中心不需要相同的容量，負載平衡器可以買較小的型號。更進一步，災備中心的負載平衡器不需要A/S備援對吧，買單台就好。

假設一台大機器要兩百萬，對於此業務，中心端要Active/Standby買一對，四百萬。備援中心買一台小型好的，算一百萬。此時

  • 企業花了五百萬買了三台盒子
  • 正常時間有在動的盒子只有裡面的一台值兩百萬，另外三百萬的設備在睡覺

這是一個規劃與保護完整，但並非效益最佳化的機制。但如果是NSX Advanced Load Balancer的機制呢？比如說同樣的應用需要四台，各2個vCPU的服務引擎才能完整提供應用遞送服務，此時

  • 企業花了兩百萬（單純舉例）買了上述的8個Service Unit授權
  • 這四台服務引擎是以Active/Active的方式在運作，每台都在工作
  • 如果單台服務引擎失效，此時的應用遞送容量負載仍然有原本的75%。如果企業不願意容許這樣的效能下降，也可以規劃多一台服務引擎，總共五台、共耗費10個Service Units運作。這樣在單台失效時，也不會影響到應用效能
  • 既然主中心服務用了8個Service Unit授權，那DR也需要買4顆吧？不用，DR不用買。當主中心失效時，這邊也沒有服務引擎了，這8個Service Unit授權完全可以空出來，在DR啟用時直接使用即可
  • 此時，災備中心的應用遞送容量與原本生產環境『一模一樣』，無需有任何犧牲。

在上述的例子內，企業兩百萬購買的八個Service Units是『隨時在工作』，沒人在睡覺。這樣的彈性提供了更低的採購價格，更高的可應用及備援容量，與傳統硬體授權機制間的優劣應該是顯而易見的。

效能不足、授權不夠時，僅需額外購買不足量的授權，無需重買

想像企業對應某個業務的應用遞送需求買了4個Service Unit的授權。真正生產跑起來後，發現有點不夠，可能要6個SU比較安全。此時怎麼辦呢？很單純，多買2個SU的授權補起來就好了。

但反過來在硬體的場景。機器買了跑了一陣子，發現效能不夠了，此時

  • 可以說那多買一點CPU / Memory把機器加大嗎
  • 得換更大的型號，那可以把原本的退貨，補差價買新的嗎

很明顯的都不行吧，此時就得重買了。這邊和NSX ALB的集中授權相比又是一個很大的彈性差異。

其他類似的場景例子還有很多，限於篇幅就不多談了。在但本篇的舉例內希望讓大家可以看到NSX Advanced Load Balancer的集中授權機制提供了企業新型態雲應用非常大的運用彈性，包含在任意地點部署不受限、授權使用彈性、易於配合業務實際交易使用量進行調整的相關好處，都是傳統硬體購買方式難以企及的。

花了兩篇討論何謂Service Units以及集中授權的彈性，但回歸重點：那在『這個案子』裡，我們到底應該買幾顆NSX ALB Service Units呢？下篇內我們繼續討論。