平衡資料流量可以在回應時間及產量上增進可延伸服務的效能。可延伸資料服務有兩類。
Pure 服務可以使其任何實例回應用戶端請求。Sticky 服務可以使一個用戶端向同一實例傳送請求。那些要求不會重新導向至其他實例。
Pure 服務使用加權平衡資料流量策略。在此平衡資料流量策略下,依預設用戶端要求會平均地分配給叢集中的伺服器實例。例如,在一個三節點叢集中,假定每個節點的權重為 1。則每個節點將代表服務處理所有來自用戶端的請求的 1/3。管理員可以透過 scrgadm(1M) 指令介面或 SunPlex Manager GUI 隨時變更權重。
Sticky 服務具有兩種類型︰ordinary sticky 和 wildcard sticky。Sticky 服務使在多個 TCP 連線上的並行應用程式級階段作業可以用 in-state 記憶體 (應用程式階段作業狀態)。
Ordinary sticky 服務使用戶端可以共用多個並行 TCP 連線之間的狀態。稱該用戶端對偵聽單一連接埠的伺服器實例「sticky」。只要實例維持啟動與可存取的狀態,且此服務處於線上狀態時負載平衡策略為變更,便可保證用戶端的所有請求均傳送至同一伺服器實例。
例如,用戶端上的 Web 瀏覽器使用三個不同的 TCP 連線透過連接埠 80 連線至的共用 IP 位址。然而,連線會在服務中交換它們之間快取的階段作業資訊。
Sticky 策略的一般化會延伸至在背景中並且在同一實例上交換階段作業資訊的多個可延伸服務。當這些服務在背景中並且在同一實例上交換階段作業資訊時,則稱該用戶端對同一節點上偵聽不同連接埠的多個伺服器實例「sticky」。
例如,電子商務網站上的某位顧客透過在連接埠 80 上使用 HTTP 將購物車裝滿商品。然後該顧客切換至連接埠 443 上的 SSL 來傳送安全資料以使用信用卡支付購物車內的商品。
Wildcard sticky 服務使用動態指定的連接埠號碼,但仍然希望用戶端請求傳送到同一節點。用戶端在具有同一 IP 位址的連接埠上「sticky wildcard」。
這種策略的典型範例是被動模式 FTP。例如,某用戶端連線至連接埠 21 上的 FTP 伺服器。伺服器則會指示該用戶端連線回動態連接埠範圍內的偵聽程式埠伺服器。此 IP 位址的所有請求均轉發至同一節點伺服器透過控制資訊通知用戶端。
依預設,對於其中的每個 sticky 策略,加權式負載平衡策略均有效。因而,會將用戶端的初始請求導向至負載平衡器指定的實例。用戶端為實例正在其上執行的節點建立關聯之後,會有條件地將以後的請求導向至該實例。節點必須可以存取且負載平衡策略必須未變更。
有關特定的負載平衡策略的其他詳細資訊如下。
加權式。這項載入會按照指定的加權值來分配到各種節點。此策略可以透過使用 Load_balancing_weights 特性的 LB_WEIGHTED 值設定。如果節點的權重未明確設定時,則此節點的權重將預設為「一」。
加權策略可將一定百分比的用戶端通訊重新導向某個特定節點。假定 X=權重且 A=所有使用中節點的總權重,則使用中的節點的所有新連線中大約 X/A 的連線將會導向至該使用中的節點。然而,連線的總數必須足夠大。此策略不針對個別的要求。
請注意,此策略並非全體循環式。round-robin 策略總是會使來自某個用戶端的每個請求都傳送至其他節點。例如,第一個請求會傳送至節點 1,第二個請求會傳送至節點 2,以此類推。
Sticky。在此策略中,會於配置應用程式資源時知道通訊埠集合。此策略可以透過使用 Load_balancing_policy 資源特性的 LB_STICKY 值設定。
Sticky-wildcard。此策略是一般「Sticky」策略的超集合。對於透過 IP 位址識別的可延伸服務,由伺服器為其指定連接埠 (並且事先並不知道)。通訊埠可能會變更。此策略可以透過使用 Load_balancing_policy 資源特性的 LB_STICKY_WILD 值設定。