Apache 功能模块 mod_proxy_balancer

負載平衡器排程演算法

目前有 4 種負載平衡器排程演算法可供使用：依據要求次數（mod_lbmethod_byrequests）、依據加權流量次數（mod_lbmethod_bytraffic）、依據處理中要求次數（mod_lbmethod_bybusyness）和依據心跳流量次數（mod_lbmethod_heartbeat）。這些演算法可透過「負載平衡器」定義中的 lbmethod 值來控制。有關更多資訊，特別是關於如何設定「負載平衡器」和「負載平衡器成員」的資訊，請參閱 ProxyPass 指令。

負載平衡器的黏著性

此負載平衡器支援黏著性。當要求代理到某個後端伺服器時，來自相同使用者的所有後續要求都應該代理到相同的後端伺服器。許多負載平衡器都是透過表格來實作這項功能，將用戶端 IP 位址對應到後端伺服器。這種方法對用戶端和後端伺服器來說是透明的，但是會產生一些問題：如果用戶端本身藏在代理伺服器後方，則負載分配會不平均；當用戶端在一個工作階段中使用變動的動態 IP 位址時，會發生黏著性錯誤；如果對應表格溢位，黏著性會消失。

針對兩種替代方法（Cookie 和 URL 編碼），模組 mod_proxy_balancer 會在它們之上實作黏著性。提供 cookie 可能是由後端伺服器完成，或是由 Apache 網路伺服器本身完成。URL 編碼通常是由後端伺服器完成。

負載平衡器設定範例

在我們深入探討技術細節之前，以下是一個您可以使用 mod_proxy_balancer 來提供兩個後端伺服器之間的負載平衡的範例

<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80"
    BalancerMember "http://192.168.1.51:80"
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

另一個使用 mod_headers 提供黏著性負載平衡的範例，即使後端伺服器沒有設定合適的階段性 cookie

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=1
    BalancerMember "http://192.168.1.51:80" route=2
    ProxySet stickysession=ROUTEID
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

匯出的環境變數

目前有 6 個已匯出的環境變數

BALANCER_SESSION_STICKY

這會指定用於目前要求的 stickysession 值。這是用於黏著性階段的 cookie 或要求參數的名稱

BALANCER_SESSION_ROUTE

這會指定從目前要求分析出的 route。

BALANCER_NAME

這會指定用於目前要求的負載平衡器名稱。這個值類似於 balancer://foo。

BALANCER_WORKER_NAME

這會指定用於目前要求的作業員名稱。這個值類似於 http://hostA:1234。

BALANCER_WORKER_ROUTE

這會指定將用於目前要求的作業員的 route。

BALANCER_ROUTE_CHANGED

如果工作路徑不符節點路徑（BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE），或節點尚無固定路徑，則設為 1。這可用於判斷是否或何時應在使用黏著性工作階段時向用戶端發送更新路徑。

啟用負載平衡管理員

此模組需要服務 mod_status。負載平衡管理員能夠對負載平衡成員進行動態更新。您可以使用負載平衡管理員來變更特定成員的負載均衡係數，或將其切換到離線模式。

因此，如需取得負載平衡管理功能，主機中必須要有mod_status 和 mod_proxy_balancer。

如需為 example.com 網址中的瀏覽器啟用負載平衡管理，請將此程式碼新增到 httpd.conf 設定檔

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require host example.com
</Location>

您現在可以使用 Web 瀏覽器存取頁面 http://your.server.name/balancer-manager 來存取負載平衡管理員。請注意，管理員只能動態控制在外圍 <Location ...> 容器定義的平衡器。

負載平衡器黏著性的詳細資料

使用以 Cookie 為基礎的黏著性時，您需要設定 Cookie 名稱，Cookie 包含要使用哪個後端資訊。可以透過 stickysession 屬性（已新增到 ProxyPass 或 ProxySet）來設定此內容。Cookie 名稱會區分大小寫。負載平衡器會萃取 Cookie 值，然後尋找 route 等於此值的成員工作階段。route 也必須設定在 ProxyPass 或 ProxySet 中。Cookie 可以由後端設定，或如上述 範例 所示，由 Apache 網頁伺服器本身設定。

有些後端會使用稍有不同的形式的黏著性 Cookie，例如 Apache Tomcat。Tomcat 會將 Tomcat 執行個體名稱新增到其工作階段 id Cookie 的結尾，並以句點（.）與工作階段 id 分隔。因此，如果 Apache 網頁伺服器在黏著性 Cookie 值中找到句點，它只會使用句點後的部份來搜尋路徑。如需讓 Tomcat 知道其執行個體名稱，您需要將 Tomcat 設定檔 conf/server.xml 內的 jvmRoute 屬性設定為連接至相關 Tomcat 的工作階段的 route 值。Tomcat 使用的工作階段 Cookie 名稱（以及通常使用 Servlet 的 Java 網頁應用程式）是 JSESSIONID（大寫），但可以設定為其他值。

實作黏著性的第二個方法是 URL 編碼。網路伺服器會在請求的 URL 搜尋查詢參數。參數名稱會再度使用 stickysession 指定。參數值會用來查詢 route 等於該值的成員工作人員。由於從回應中擷取並操作所有 URL 連結並不容易，所以通常會由產生內容的後端來執行將參數加入每個連結的工作。有時可以透過網路伺服器使用 mod_substitute 或 mod_sed 來達成。不過這可能會對效能造成負面影響。

Java 標準是以略有不同的方式實作 URL 編碼。他們會將附加到 URL 的路徑資訊使用分號 (;) 當作分隔元件，並將會話 ID 加在後面。與 Cookie 情況相同，Apache Tomcat 可以將配置的 jvmRoute 納入此路徑資訊。若要讓 Apache 找到這類型的路徑資訊，您需要在 ProxyPass 或 ProxySet 中將 scolonpathdelim 設定為 On。

最後，您可以透過在垂直線 (|) 分隔 Cookie 名稱和 URL 參數名稱來同時支援 Cookie 和 URL 編碼，如下面的範例所示

ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=node1
    BalancerMember "http://192.168.1.51:80" route=node2
</Proxy>

如果 Cookie 和請求參數同時提供同樣請求的路由資訊，請求參數的資訊會優先使用。

負載平衡器黏著性疑難排解

如果您遇到黏著性錯誤，例如使用者的應用程式會話中斷且需要重新登入，您首先需要檢查這是否是因為後端有時不可用，或是因為您的設定錯誤所造成的。若要找出後端可能發生的穩定性問題，請在 Apache 錯誤記錄中查看代理伺服器錯誤訊息。

若要驗證設定，請首先檢查黏著性是基於 Cookie 還是 URL 編碼。下一步會是透過使用加強的 LogFormat 記錄存取記錄中的適當資料。下列欄位很有用

%{MYCOOKIE}C

包含在名稱為 MYCOOKIE 的 Cookie 中的值。名稱應與在 stickysession 屬性中提供的一樣。

%{Set-Cookie}o

這會記錄後端設定的任何 Cookie。您可以追蹤後端是否設定您預期的會話 Cookie，以及設定為哪個值。

%{BALANCER_SESSION_STICKY}e

用於查詢路由資訊的 Cookie 或請求參數名稱。

%{BALANCER_SESSION_ROUTE}e

在請求中找到的路由資訊。

%{BALANCER_WORKER_ROUTE}e

所選工作人員的路由。

%{BALANCER_ROUTE_CHANGED}e

如果請求中的路由與工作者的路由不同時，則設定為 1，亦即請求無法被處理成黏著情況。

發生遺失工作階段的常見原因是工作階段逾時，這通常可以在後端伺服器上設定。

如果記錄等級設定為 debug 或更高，則平衡器也會將有關黏著處理的詳細資訊記錄至錯誤記錄。這是排除黏著問題的容易方法，但對於負載過高的生產伺服器而言，記錄的數量可能過高。