平衡資料流量策略

平衡資料流量可以在回應時間及產量上增進可延伸服務的效能。

可延伸資料服務的類別有兩種： pure 及 sticky. Pure 服務是，它的任何實例均可回應用戶端要求。 Sticky 服務是用戶端傳送要求給相同實例的服務。 那些要求不會重新導向至其它實例。

Pure 服務使用加權平衡資料流量策略。 在此平衡資料流量策略下，依預設用戶端要求會平均地分配給叢集中的伺服器實例。 例如，在三節點的叢集中，我們假設每一個節點的權重是 1。 每一個節點代表該服務，分別服務 1/3 的任何用戶端要求。 權重隨時可以由管理者透過 scrgadm(1M) 指令介面或 SunPlex 管理者 GUI 來加以變更。

Sticky 服務有兩種方式，Ordinary Sticky 和 Wildcard Sticky。Sticky 服務允許在多個 TCP 連接上並行處理應用程式層次階段作業，以共用 in-state 記憶體 (應用程式階段作業狀態)。

Ordinary Sticky 服務允許用戶端共用多個並行 TCP 連接之間的狀態。 用戶端被稱為 Sticky 是因為該伺服器實例監聽單一埠。 只要該實例維持啟動與可存取的狀態，且當此服務在線上時，平衡資料流量策略未曾改變，即可保證用戶端的所有要求均會到達相同的伺服器實例。

例如，用戶端上的網際網路瀏覽器使用三種不同的 TCP 連線連接到共用 IP 位址的 80 通訊埠，但是連線是在服務時交換快取的階段作業資訊。

一般化的 Sticky 策略擴展至多重可延伸服務，在相同實例上進行幕後交換階段作業資訊。 當這些服務在相同實例上於幕後交換階段作業資訊時，用戶端稱為 Sticky 是同一節點上的多個伺服器實例監聽不同的埠。

例如，電子商務網站上的客戶使用一般的 HTTP (80 通訊埠) 將物品填入其購物車，但是會切換至 SSL (443 通訊埠) 傳送安全性資料，以使用信用卡付購物車中物品的帳款。

Wildcard Sticky 服務使用動態指定的埠號，但是仍然希望用戶端要求會到達相同的節點。 此用戶端在相關的同一 IP 位址的連接埠上呈現 Sticky Wildcard 。

這種策略的典型範例是被動模式 FTP。 用戶端連接至 FTP 伺服器的 21 通訊埠，然後被伺服器通知以動態埠範圍連接回至接收埠伺服器。 對此 IP 位址的所有要求，均會轉遞至伺服器經由控制資訊通知用戶端的同一節點。

請注意，對此每一種 Sticky 策略，依預設都會使用加權平衡資料流量策略，因此用戶端的起始要求會被導向平衡資料流量程式所指定的實例。 在用戶端建立與執行實例之節點的關係之後，只要該節點是可存取的，且平衡資料流量策略未變更，則後續的要求會被導向該實例。

特定平衡資料流量策略的其它詳細資訊如下。

• 加權式。 這項載入會按照指定的加權值來分配到各種節點。 此策略是使用 Load_balancing_weights 屬性的 LB_WEIGHTED 值。 如果節點的權重未明確設定時，則此節點的權重將預設為「一」。

  請注意，此策略並非全體循環式。 全體循環式策略一定會將用戶端的每個要求送至不同的節點：第一個要求送到節點 1，第二個要求送到節點 2，以此類推。 加權策略保證一定百分比的用戶端流量會被導向某個特定節點。 此策略不針對個別的要求。

• Sticky。 在此策略中，配置應用程式資源時會知道一組通訊埠。 此策略已使用 Load_balancing_policy 資源屬性的 LB_STICKY 值來加以設定。

• Sticky-wildcard。 此策略是一般 Sticky 策略的超集合。 對於以 IP 位址來識別的可延伸服務而言，是由伺服器來指定通訊埠 (而且事先無法知道)。 通訊埠可能會變更。 此策略已使用 Load_balancing_policy 資源屬性的 LB_STICKY_WILD 值來加以設定。