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

以前當大家要買負載平衡器的時候是怎麼做？一對一對買對吧。我們需要買負載平衡器的『盒子』，上架、接線、配置。而且基本上一定是買一對，因為擔心單台硬體失效，此時另一台要馬上進行接手。

 

我以前當網路Presale要負責規劃用戶應用架構內的負載平衡方案時，盒子是一對對的啪拉啪拉地賣。比如說客戶要導個新應用像是新行動網銀。這個時候，Web業務的前端需要一對Load Balancer吧。Application Server比如說Websphere前面也要一對吧。這是重要應用需要測試區摟，那測試區內 Web / AP 前也要各一台。需要DR吧，那也要各一台。數一數，8個盒子就賣出去了～～啊好，那接下來我們換個銀行賣，或是改賣其他業務系統比如CRM。那時真是應用遞送方案的黃金時代啊～～

 

所以通常在客戶端就會像下面這樣，有好多對負載平衡器擺這邊擺那邊：

這種傳統架構從負載平衡器面世到現在快二十年了都是這樣子，功能上當然沒問題。但從以前到現在，有幾點常常會需要與客戶討論的：

 

  1. 我們花了大錢買了負載平衡器，但都只能用一半耶！

 

對的，在生產環境，你就是只能用一半。負載平衡器後面就是最重要的核心業務，斷幾個小時責任誰來擔？沒有人會冒這個險的。給錢！

 

  1. 那我們的應用要買多大的型號才撐得住？

 

標準答案是這樣：那親愛的客戶，你們的業務規劃的容量是多少呢？同時最多連線數大概多少？每秒新增連線數大概多少？頻寬大概是多少？基於這些假設就可以配置對應的型號喔。

 

根據我十餘年的實際與客戶討論經驗，大概十個客戶頂多一個答得出來。其他九個回頭去問應用開發Team，他們也不知道。

 

那這樣，如果你設備買太小，結果應用的流量比想像的大，這時會撐不住怎麼辦？加CPU加RAM嗎？沒有喔，要重買新的喔。你要冒這個險嗎？其他家銀行都是買這台大的喔。好那就這麼定了，給錢！

 

（然後型號估太大，平常應用的用量大概只佔設備能力的5% 吧。但反正董事會錢也批了，案子也結了，那就這樣子，可喜可賀可喜可賀）

 

  1. 總經理下令發動399促銷，或是雙十一，或是雙十二，結果真的設備撐不住了，怎麼辦？

 

啊這是重要的業務需求，就再買大的啊，給錢摟～

 

（結果明明其他業務其他台負載平衡器還有很多運算能力，但是沒法用）

 

（然後決定買了個大冰箱，裡面插了好多張板卡，結果一年只用得到那幾天會有大流量）

 

  1. 錢是一回事，我們現在要導自動化流水線，負載平衡也要整合在應用部署流程內，怎麼做？

 

標準答案大概是下面這個樣子：

 

  • 我們有API

 

  • 怎麼用這個API呢？請買我們原廠的專業服務，這是報價單。

 

  • 這個功能在API裡面沒有？嗯應該以後Roadmap會有吧。

 

  • 有很多台負載平衡器要怎麼集中配置？嗯現在不行，應該以後Roadmap會有吧。

 

  • 這API配置很複雜，有沒有宣告式 (Declarative) 的架構？你在說什麼我聽不懂。

 

其實說實話，買賣東西是一個願打一個願挨，也沒有什麼特別好批評。但確實在目前的新應用架構內，早期的容量估算方式早就不合適了。新的雲原生應用會有下面這幾種特性：

 

  • 應用的流量與以前相比更難估算。能快速因應業務需求擴充（Scale Up / Scale Out）越來越重要

 

  • 業務上線下線異動頻繁，支援自動化編排機制已經不再是加分項目，而是必要需求

 

  • 應用不再僅部署於私有雲與虛機，也需要在不同的公有雲環境可以支援，也可能是虛機或容器。

 

因此一個支援雲原生方案，可以快速因應變化的應用遞送架構可以說是企業越來越需要的。下一篇開始我們來討論Avi Networks的方案與傳統的架構有何不同，而且如何回應本篇前面所提到的各個常見問題。