若您維運的系統達到一定的規模便會開始覺得伺服器不堪負荷，通常都會採取垂直擴充的方法(升級原有的伺服器硬體)。一旦現有的伺服器達到擴充上限，那麼您就勢必通過增加更多的伺服器來分散負載。今天就讓我們來介紹身為程式開發人員或者是系統管理員必須懂得的負載平衡技術吧。

之前已經寫過介紹的投影片，就讓我偷懶直接拿來用吧。

General Architecture of Clusters
一般來說，稍具規模的系統都會採用叢集架構如下

• Load Balancer 前端的負載平衡伺服器做為服務的單一入口
• Server Cluster 一群提供服務運算資源的伺服器
• Shared Storage 讓每台伺服器提供的服務擁有相同內容的共用儲存體

我們習慣把 Server Cluster 稱之為 Real Server 意即實際提供運算資源的伺服器，共用儲存體則是看您的應用而決定，最常見的就是各種類型的資料庫與網路儲存裝置(NAS)或者分散式檔案系統。

Layer 4 and Layer 7 Load Balancing
負載平衡的運作方式主要區分為 Layer 4 與 Layer 7 兩種模式

What is Layer 4 Load Balancing?
只在 Transport Layer 進行處理，就像 NAT 一樣儘管負責傳送到後端，不去理會收到的封包內容是甚麼，只要看到目的端的 IP 就直接丟過去，故稱之為 Layer 4，但也因此擁有很好的處理效能。

What is Layer 7 Load Balancing?
負載平衡伺服器會解析封包的標頭內容，再根據所設定的規則來進行路由。由於是運作在 OSI 模型的最高層，故稱之為 Layer 7。

Benefits of Layer 7 Load Balancing
儘管與 Layer 4 相比因為要進行封包標頭解析，所以會比較消耗 CPU 的硬體資源，但以現代伺服器的規格來說影響微乎其微。

透過 Layer 7 可以使用更聰明的路由方式，例如透過封包標頭得知使用者的瀏覽器版本來決定導向的伺服器，或者根據阻斷式服務攻擊（DDoS）的封包特性進行分析與阻擋。

The Top 6 Open Source Load Balancers
當然也並非一定得用 HAProxy 來當作負載平衡伺服器，開源社群仍舊有非常多的選擇，通常我們會依據運作方式是否支援 Layer 4 與 Layer 7 來進行區分以及本身是否直接支援 SSL 憑證自動更新。

例如 NGINX 也是一個很不錯的選擇，同時它也很常被用來當作反向代理伺服器(Reverse proxy)。

The History of HAProxy
我們只列出一些重大的發展版本

• HAProxy 1.1 支援 Round-Robin 調度、服務狀態的檢查與 Cookie
• HAProxy 1.2 支援 maxconn 避免資源耗盡造成當機與後續的骨牌效應
• HAProxy 1.4 支援 HTTP Keep-Alive 減少 TCP 連接，降低擁塞控制
• HAProxy 1.6 支援 SSL 增加安全性
• HAProxy 1.7 支援 Runtime API 可在運行時更改幾乎所有的設置
• HAProxy 1.8 支援多執行緒，速度提高了約 2.5 倍
• HAProxy 1.9 支援 HTTP/2 加快網路載入速度
• HAProxy 2.0 支援 Kubernetes Ingress Controller

詳細的歷史進程請參考下列連結
https://www.haproxy.com/blog/the-history-of-haproxy/

Discovering Its Strengths
慣例來說，防火牆通常由基礎設施團隊(Infrastructure Team)負責，只有他們能夠看到防火牆的日誌。負責開發的團隊(Application Team)則認為大部分的服務失效都是網路或者防火牆設定不良所導致。

網路團隊(Network Team)只負責網路設備的正常運作，不需要處理任何與 HTTP Layer 或流量日誌相關的事情。當發生問題的當下，開發的團隊只能求助於他們，只因他們擁有網路封包擷取的設備，同時他們又很難證明問題不在他們這邊。

基礎設施團隊有了 HAPrxoy 之後，一切都變得簡單起來。它產生的日誌立即表明了連結的來源，發送到哪裡，等待伺服器花了多長的時間，以及伺服器端與使用者端哪一方先關閉了它，顯著地改善解決問題所需的時間。

Case Study：Terminal Quit Unexpectedly
以下就是我實際經歷的真實案例

情境描述：用戶使用一般電腦透過遠端桌面連線至終端機伺服器(Terminal Server)開啟 Excel 工作時發生不定時斷線問題，嚴重影響工作進度。

網路團隊(Network Team)：我們查了該區域負責連線的交換機，沒有發生任何的封包遺漏，而且反應時間都正常。

基礎設施團隊(Infrastructure Team)：使用者連線到的端機伺服器也都正常運作，看看其他線上用戶跑得好好的。

服務台團隊(Helpdesk Team)：窩不知道 peko，我們也是照著標準作業流程使用相同映像檔安裝作業系統的。

馬上打開筆電一頓操作猛如虎

首先找到該台電腦的 MAC Address，登入 DHCP 伺服器剖析日誌檔找到當下該 MAC 到底發配了哪個 IP 。

再登入 HAProxy 伺服器剖析日誌檔，透過 IP 找到當下的 Session 紀錄，該筆紀錄明確表明中斷是在使用者端發生的。

藉由 Term Code 便可得知是從哪一方斷開的，例如 CD 代表是使用者端不預期的中斷資料傳輸。

The client unexpectedly aborted during data transfer. This can be caused by a browser crash, by an intermediate equipment between the client and haproxy which decided to actively break the connection, by network routing issues between the client and haproxy, or by a keep-alive session between the server and the client terminated first by the client.

進一步確認終端伺服器查看系統與應用程式日誌檔，該時段內的確無任何異常發生。在使用者的電腦系統日誌檔發現錯誤訊息，主要原因是網路卡發生異常，最後更新驅動就沒再發生了。

分析根本原因，雖然服務台團隊(Helpdesk Team)依照標準作業流程進行系統的安裝。但即使是同型號的電腦隨著時間的推移，不同批次的電腦也有可能因為物料短缺而改採其他零組件，使得映像檔裡的網卡驅動不符合現實的狀況所導致。

最後我問了一下使用者這張 Ticket 開了多久 他說：快三個月...

今天簡單的介紹負載平衡的觀念與架構，下一篇會教大家如何在 Ubuntu 上面安裝 HAProxy 並架設 Keepalive 建置屬於自己的負載平衡伺服器。

參考文件

1. https://docs.haproxy.org/1.7/configuration.html
2. https://www.haproxy.com/blog/the-history-of-haproxy/