負載平衡操作指南

簡介

負載平衡器是一個不會直接與 Tomcat 通訊的工作執行緒。它負責管理多個「實際」工作執行緒，稱為負載平衡器的成員或子工作執行緒。

此管理包括

  • 在 Web 伺服器中實例化工作執行緒。
  • 使用工作執行緒的負載平衡因子，執行加權負載平衡（根據目標定義的強度分配負載）。
  • 讓屬於同一個階段的請求在同一個 Tomcat 上執行（階段黏著性）。
  • 識別失敗的 Tomcat 工作執行緒，暫停對它們的請求，並改為轉移到負載平衡器管理的其他工作執行緒上。
  • 透過狀態工作執行緒介面，提供負載平衡器本身和所有成員的狀態和負載指標。
  • 允許透過狀態工作執行緒介面動態重新設定負載平衡。

由同一個負載平衡器工作執行緒管理的工作執行緒會進行負載平衡（根據它們設定的平衡因子和目前的請求或階段負載），並透過提供轉移到同一個負載平衡器的其他成員，來防止失敗。因此，單一 Tomcat 程序死亡不會「殺死」整個網站。

負載平衡器提供的部分功能，即使只使用單一成員工作執行緒（無法進行負載平衡），也很有幫助。

基本負載平衡器屬性

透過將工作執行緒的 type 設定為 lb，可以將工作執行緒設定為負載平衡器。

下表說明用於設定負載平衡器工作執行緒的一些屬性

  • balance_workers 是負載平衡器成員工作站名稱的逗號分隔清單。這些工作站通常為 ajp13 類型。成員工作站本身不需要出現在 worker.list 屬性中，將負載平衡器新增到其中就已足夠。
  • sticky_session 指定是否應將具有 SESSION ID 的要求路由回建立該工作階段的同一個 Tomcat 執行個體。當 Tomcat 使用可以跨多個 Tomcat 執行個體分享工作階段資料的工作階段管理員時，您可以將 sticky_session 設定為 false - 或如果您的應用程式是無狀態的。預設 sticky_session 設定為 true。
  • 可以將 lbfactor 新增到每個成員工作站，以設定成員的個別強度。較高的 lbfactor 會導致更多要求平衡到該工作站。必須以整數提供這些因子，而且負載會依據提供的因子成比例分配。較高的因子會導致更多要求。
# The load balancer worker balance1 will distribute
# load to the members worker1 and worker2
worker.balance1.type=lb
worker.balance1.balance_workers=worker1, worker2
worker.worker1.type=ajp13
worker.worker1.host=myhost1
worker.worker1.port=8009
worker.worker2.type=ajp13
worker.worker1.host=myhost2
worker.worker1.port=8009
工作階段黏著性並非使用追蹤表來實作工作階段。相反地，每個 Tomcat 執行個體都會取得個別名稱，並在其工作階段 ID 的結尾新增其名稱。當負載平衡器看到工作階段 ID 時，它會找出 Tomcat 執行個體的名稱，並透過正確的成員工作站傳送要求。為執行此動作，您必須將 Tomcat 執行個體的名稱設定為每個 Tomcat 的 server.xml 中 Engine 元素的 jvmRoute 屬性的值。Tomcat 的名稱必須等於對應負載平衡器成員的名稱。在上述範例中，主機「myhost1」上的 Tomcat 需要 jvmRoute="worker1"，主機「myhost2」上的 Tomcat 需要 jvmRoute="worker2"。

如需所有負載平衡器設定屬性的完整參考，請參閱工作站 參考。

進階負載平衡器工作站屬性

負載平衡器支援複雜的拓撲和故障移轉設定。使用成員屬性 distance，您可以將成員分組。負載平衡器會始終將要求傳送給距離最短的成員。只有當所有這些成員都中斷時，它才會平衡到距離設定為次短的成員。這允許您在不同資料中心位置的 Tomcat 執行個體之間定義優先順序。

在使用工作階段複製或持續工作階段管理員（例如透過資料庫）處理共用工作階段時，通常會將 Tomcat 農場分割成複製群組。在成員發生故障時，負載平衡器需要知道哪些其他成員共用工作階段。這是使用 domain 屬性設定的。假設所有具有相同網域的工作站都共用工作階段。

為了維護目的，你可以告知負載平衡器不要允許任何新工作階段在某些成員上，甚至完全不使用它們。這由成員屬性 activation 控制。值 Active 允許正常使用成員，disabled 不會在成員上建立新工作階段，但仍允許黏著式要求，而 stopped 將不再向成員傳送任何要求。在維護前一段時間將啟動狀態從「active」切換為「disabled」，將會耗盡工作階段中的工作階段，並將中斷降至最低。根據應用程式的使用模式，耗盡將會花費數分鐘到數小時。在維護前立即將工作階段切換為已停止，將會減少 mod_jk 記錄錯誤日誌的次數。

最後，你也可以透過將 activation 設定為 disabled，並將屬性 redirect 加入其他工作階段，來設定熱備用工作階段

# The advanced router LB worker
worker.list=router
worker.router.type=lb
worker.router.balance_workers=worker1,worker2

# Define the first member worker
worker.worker1.type=ajp13
worker.worker1.host=myhost1
worker.worker1.port=8009
# Define preferred failover node for worker1
worker.worker1.redirect=worker2

# Define the second member worker
worker.worker2.type=ajp13
worker.worker2.host=myhost2
worker.worker2.port=8009
# Disable worker2 for all requests except failover
worker.worker2.activation=disabled

worker1 上的 redirect 旗標會告知負載平衡器，如果 worker1 有問題，則將要求重新導向至 worker2。在所有其他情況下，worker2 都將不會收到任何要求，因此會像熱備用一樣運作。

關於將 activation 設定為 disabled 的最後一個注意事項：隨要求而來的工作階段 ID 會作為要求 URL 的一部分 (;jsessionid=...) 或透過 Cookie 傳送。當使用書籤或已執行一段時間的瀏覽器時，可能會傳送一個要求，其中載有指向已停用成員的舊無效工作階段 ID。由於負載平衡器沒有有效工作階段的清單，因此它會將要求轉發給已停用的成員。因此，耗盡的時間會比預期更長。若要處理此類情況，你可以將 Servlet 篩選器加入你的網路應用程式，用來檢查要求屬性 JK_LB_ACTIVATION。此屬性包含下列字串之一：「ACT」、「DIS」或「STP」。如果你偵測到「DIS」且要求的工作階段不再處於活動狀態，請刪除工作階段 Cookie，並使用自我參照 URL 重新導向。重新導向的要求將不再載有工作階段資訊，因此負載平衡器不會將其傳送給已停用的工作階段。要求屬性 JK_LB_ACTIVATION 已在版本 1.2.32 中加入。

狀態工作階段屬性

狀態工作階段不會與 Tomcat 通訊。相反地，它負責工作階段管理。當與負載平衡器工作階段結合使用時，它特別有用。 

# Add the status worker to the worker list
worker.list=jkstatus
# Define a 'jkstatus' worker using status
worker.jkstatus.type=status

接下來是將要求掛載到 jkstatus 工作階段。對於 Apache HTTP 伺服器，請使用

# Add the jkstatus mount point
JkMount /jkmanager/* jkstatus

若要獲得更高的安全性，請使用

# Enable the JK manager access from localhost only
<Location /jkmanager/>
  JkMount jkstatus
  Require ip 127.0.0.1
</Location>