平衡資料流量策略

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

有兩種可延伸數據服務的類別：pure 和 sticky。 Pure 服務是，它的任何實例均可回應用戶端要求。Sticky 服務是用戶端傳送要求給相同實例的服務。那些要求不會將方向轉至其它實例。

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

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 值來加以設定。