平衡資料流量策略

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

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

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

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

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

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

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

例如，電子商務網站上的客戶使用通訊埠 80 上的一般 HTTP，在他的購物車中裝滿物品，但要切換至通訊埠 443 上的 SSL 來傳送安全資料，以便能使用信用卡為該購物車中的物品付款。

Wildcard Sticky 服務使用動態指定的通訊埠編號，但是仍然希望用戶端要求會到達相同的節點。 用戶端在相關的同一 IP 位址之通訊埠為「Sticky wildcard」。

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

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

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

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

  加權策略可將一定百分比的用戶端通訊重新導向某個特定節點。 如果指定 X=權重與 A=所有作用中節點的總權重，當連接總數足夠大時，作用中的節點便可預期將新連接總數的大約 X/A 導向作用中節點。 此策略不針對個別的要求。

  請注意，此策略並非全體循環式。 全體循環式策略一定會將用戶端的每個要求送至不同的節點： 將第一個要求送到節點 1，將第二個要求送到節點 2，以此類推。

• Sticky。 在此策略中，會於配置應用程式資源時知道通訊埠集合。 可使用 Load_balancing_policy 資源屬性的 LB_STICKY 值來設定此策略。

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