HAProxy 與負載平衡概念：基礎知識

簡介

高可用性代理 (HAProxy)，是一款熱門的開源代理與 TCP/HTTP 負載平衡器 解決方案，能夠運行於 Solaris, FreeBSD、以及 Linux。它最常用於藉由在多台伺服器之間均衡分配工作負載，來提升伺服器環境的可靠性與效能。這類工具被廣泛應用於許多知名環境中，例如 Instagram、GitHub、Twitter 和 Imgur。

本指南將向您介紹 HAProxy，讓您熟悉負載平衡的相關術語，並提供如何利用它來增強伺服器環境效能與可靠性的範例。

HAProxy 重要術語

在深入探討 負載平衡 與 代理 的細節之前，有一些重要的術語和概念需要先熟悉。我們將在以下章節中先複習這些概念。

ACL (存取控制清單)

在負載平衡中，ACL 被用於測試特定條件並根據結果執行對應的操作。這提供了根據後端連線、模式比對等多種因素來最佳化轉發流量的能力。以下是使用 ACL 的範例：

在這種情況下，如果使用者請求的路徑以 /blog 開頭，則該 ACL 匹配成功。例如，此匹配請求將指向 http://yourdomain.com/blog/blog-entry-1。 HAProxy 設定手冊 包含有關 ACL 使用方式的詳細指南。

後端 (Backend)

轉發的請求由一組被稱為後端（backend）的伺服器接收。這些請求是在 HAProxy 設定檔的 backend 區段中定義的。最簡單來說，後端可以透過要使用的負載平衡演算法以及連接埠和伺服器的列表來定義。後端可以由單一伺服器或多台伺服器組成。隨著更多伺服器加入後端，潛在的負載能力也會增加，處理工作會分散到多台伺服器上。如果某些後端伺服器離線，其他伺服器將作為備份來處理請求。

讓我們來看一個包含兩個後端的設定範例。在此範例中，它們是 blog-backend 和 web-backend。每個後端都有兩台網頁伺服器，監聽連接埠 80：

balance roundrobin 這行是用來指定負載平衡演算法。詳細資訊可以在接下來的 負載平衡演算法 章節中找到，而 mode http 則是設定使用第 7 層代理。我們將在 負載平衡類型 章節中對此進行說明。此外，伺服器指令後面的 check 選項表示將對這些特定的後端伺服器觸發健康檢查。

前端 (Frontend)

定義請求如何轉發到後端的部分被稱為前端（frontend）。這些請求是在 HAProxy 設定檔的 frontend 區段中定義的。它們由 ACL、連接埠、一組 IP 位址以及一個根據滿足哪些 ACL 條件來定義要使用哪些後端的規則（稱為 use_backend 規則）所組成。此外，還存在一個 default_backend 規則以處理任何其他情況。下一節將說明如何針對各種網路流量類型設定前端。

負載平衡類型

在確立了用於負載平衡的基本元件之後，我們現在可以繼續探討負載平衡的基本類型。

無負載平衡

在最基本的的形式中，缺乏負載平衡的情況可以用下圖來表示：

在這種情況下，使用者會直接連線到位於 yourdomain.com 的網頁伺服器。此處沒有任何負載平衡。由於只有一台資料庫伺服器，如果它離線，對其上資訊的存取就會完全中斷。如果許多使用者同時嘗試連線到單一網頁伺服器，而該伺服器無法處理所產生的負載，則所有連線都會變慢或完全無法連線。

負載平衡（第 4 層）

將網路流量平衡到多台伺服器最簡單、最實用的方法之一，是使用傳輸層或第 4 層平衡方法。這種負載平衡方式會根據連線使用者 IP 地址所屬的 IP 範圍和連接埠來引導使用者。換句話說，如果 http://yourdomain.com/anything 是請求的來源，則定義為處理這些請求的後端將是最終處理它們的後端。它會將 yourdomain.com 的請求轉發到連接埠 80。

第 4 層負載平衡的基本結構如下所示：

當使用者存取負載平衡器時，他們的請求會被轉發到網頁後端（web-backend）伺服器群組。設定好的後端伺服器將直接回應使用者的請求。為了避免使用者遇到不一致的資料，所有網頁後端伺服器都應該提供相同的內容。如上圖所示，兩台網頁伺服器最終都連結回同一個資料庫伺服器。

負載平衡（第 7 層）

還有另一種更複雜的網路流量負載平衡方法。那就是使用第 7 層（或應用層）負載平衡。這種方法允許根據使用者請求的內容，將使用者請求轉發到不同的後端伺服器。此方法允許透過相同的連接埠和網域在多個網頁應用程式伺服器之間進行負載平衡。有關此層的更多詳細資訊，請參閱我們 網路的本質：了解術語、介面與協定 教學課程中的 HTTP 小節。

下圖說明了第 7 層負載平衡：

在這種情況下，使用者請求 yourdomain.com/blog，其請求會被轉發到部落格後端（blog backend）。這是專門分配用於執行部落格應用程式的後端伺服器組。同時，其他請求將被轉發到網頁後端（web-backend）。然而，這兩個後端最終都會存取同一個資料庫伺服器。

第 7 層負載平衡的一小段前端設定範例會類似於以下指令。它們設定 http 前端以處理通過連接埠 80 的傳入流量：

如果使用者請求的路徑以 /blog 開頭，則 acl url_blog path_beg /blog 將會比對該請求。

use_backend blog backend if url_blog 會利用 ACL 將流量代理至 blog-backend。

defaut_backen web_backend 會將所有其他流量轉發引導至 web-backend。

負載平衡演算法

進行負載平衡時，是由負載平衡演算法來決定選擇哪台後端伺服器。HAProxy 提供了多種演算法選項。此外，還可以為伺服器分配權重參數，以調整某台伺服器相對於其他伺服器被選中的頻率。由於可用的演算法實在太多，無法一一描述。因此，本指南將僅專注於最常見的演算法。您可以參考 HAProxy 文件轉換器 以查看完整清單。最常用的演算法包括：

• roundrobin：依序選擇伺服器的預設演算法。
• leastconn：自動選擇連接數最少的伺服器。然而，同一個後端內的這些伺服器應以輪詢方式進行輪替。
• source：該演算法根據發起用戶請求的來源 IP 地址來選擇伺服器。這是一種確保用戶始終連接到同一台伺服器的方法。

黏性工作階段

對於某些應用程式，要求連線的用戶必須始終連結到同一台伺服器。透過「黏性工作階段」並在需要它的後端中使用 appsession 參數，即可實現這種持久性。

處理健康檢查

HAProxy 需要一種方法來確定後端伺服器處理請求的能力。這可用於在伺服器離線時將其從後端中移除。系統會執行預設的「健康檢查」以嘗試建立 TCP 連線。它是透過監聽設定的 IP 地址和連接埠來實現的。

如果伺服器的健康檢查未通過，該伺服器將無法處理傳送的請求。此時，該伺服器會在後端自動停用，並且不再向其轉發流量，直到它重新啟動並正常運行（健康）。然而，在某些情況下，僅透過預設健康檢查來確定伺服器的健康狀況是不夠的。

替代解決方案

對於您的特定需求，HAProxy 可能顯得過於複雜。在這種情況下，有幾個不錯的替代方案可能會更有效率：

• Nginx：這是一款可靠且快速的網頁伺服器，可用於負載平衡和代理用途。事實上，Nginx 通常與 HAProxy 搭配使用，以利用其壓縮和快取功能。
• Linux Virtual Servers (LVS)：這是一個簡單的第 4 層負載平衡器，內建於許多 Linux 系統中。

高可用性

到目前為止，我們已經討論了第 4 層和第 7 層負載平衡。兩者都利用負載平衡器來決定由眾多後端伺服器中的哪一台來負責回應外部用戶的請求。但請務必記住負載平衡器的局限性。也就是說，它’是一個單點故障。這意味著如果它宕機或因用戶請求過多而超載，將分別導致服務中斷或請求處理延遲。然而，HA（高可用性）架構提供了一種沒有任何單一故障點的基礎設施。這透過在系統架構的每個層級引入冗餘，來防止因伺服器故障而導致的停機事件。雖然負載平衡器有助於實現後端的冗餘，但負載平衡器本身也需要具備冗餘機制。

下圖展示了高可用性設定的基本形式：

此基礎設施有多個負載平衡器（一個處於活動狀態，其餘處於被動狀態）綁定到一個靜態 IP 地址。如果情況需要，可以將此 IP 地址重新對應到不同的伺服器。用戶請求透過外部 IP 地址傳送到目前處於活動狀態的負載平衡器。如果此時該負載平衡器離線，容錯機制將檢測其狀態，並將 IP 地址重新分配給被動伺服器。

結論

對負載平衡的基本理解，以及了解 HAProxy 滿足系統負載平衡需求的一些方式，應該能為您在開始優化目前伺服器環境的可靠性與效能時奠定堅實的基礎。您也可以查看我們的教學課程 Nginx HTTP 代理、負載平衡、緩衝與快取：概述 以深入了解 Nginx 的負載平衡特性。

祝您運算愉快！