可延伸的數據服務

可延伸的數據服務具有在多重節點上的作用中實例之潛力。可延伸的服務利用 可延伸的資源群組 (scalable resource group) 來包含相關的應用程式資源，以及失效保護資源群組 來包含相關的網路資源 (共享地址)。 可延伸資源群組可以在多重節點上成為線上，所以即可一次執行多個服務實例。放置共用位址的失效保護資源群組一次只在一個節點上啟動線上。放置可延伸服務的所有節點，均使用相同的共用位址來放置服務。

服務要求經由單一網路介面 (global interface 或 GIF) 進入叢集， 並且根據平衡資料流量策略 (load-balancing policy) 所設定的預先定義演算法的其中一種演算法 來分配給各節點。叢集可以使用平衡資料流量策略，來均衡各個節點之間的服務負載。請注意，在不同的節點上可能有多重的 GIFs 在主控其他共用的位址。

對於可延伸服務，應用程式實例是同時執行於多個節點上。如果放置整體介面的節點失效， 該整體介面會轉移至另一個節點。如果此項應用程式實例失敗時，此實例會嘗試在同一節點上重新啟動。

如果無法在同一節點上重新啟動應用程式實例，就會配置另一個未使用的節點來執行此服務，該服務轉移至未使用的節點。否則，服務會繼續在剩餘的節點上執行，可能造成服務產量的降低。

每個應用程式實例的 TCP 狀態是保存在具有該實例的節點上，而不是在 GIF 節點。 因此，GIF 節點的失效並不會影響連接。

圖 3-4 顯示，對於可延伸服務而言，失效保護和可延伸資源群組的範例， 以及兩者之間的相依關係。此範例顯示三個資源群組。失效保護資源群組包含高可用性 DNS 的應用程式資源，以及高可用性 DNS 和高可用性 Apache Web Server 所使用的網路資源。可延伸資源群組 僅包含 Apache Web Server 的應用程式實例。請注意，可延伸和失效保護資源群組之間的 相依關係 (實線)，以及所有的 Apache 應用程式資源，取決於網路資源 schost-2，它是共用位址 (虛線)。

圖 3-4 失效保護和可延伸資源群組範例

可延伸服務架構

叢集網路的主要目標是提供數據服務的可延伸性。可延伸性表示，當服務的負載增加時，因為將新的節點加入叢集，且執行新的伺服器實例， 所以數據服務在面臨這項增加的工作負擔，能維持不變的回應時間。 我們稱這樣的服務是可延伸數據服務。可延伸數據服務的典型範例是全球資訊網服務。 通常，可延伸數據服務是由許多實例所組成，每一個實例執行於叢集的不同節點上。 整合起來，這些實例便可作為從此服務的遠端從屬站觀點而來的單一服務，並且建置此項服務的功能性。例如，我們可擁有由在不同節點上執行的數個 httpd 常駐程式所組成的可延伸性 Web 服務。任一個 httpd 常駐程式可能服務一項從屬站的要求。此項服務要求的常駐程式所依據的，便是平衡資料流量策略。 對用戶端的回答顯然是來自服務，不是服務該要求的特定常駐程式，因此保留了單一服務的外觀。

可延伸服務是由下列組成：

• 支援可延伸服務的網路基礎架構

• 平衡資料流量

• 網路和數據服務的 HA 支援 (使用 Resource Group Manager)

下圖說明了可延伸服務的架構。

圖 3-5 可延伸服務的架構

沒有放置整體介面的節點 (代理節點) 將共用位址放在其迴圈介面。 進入 GIF 的封包會根據配置的平衡資料流量策略，來分送至其它叢集節點。 可能的平衡資料流量策略說明如後。

平衡資料流量策略

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

有兩種可延伸數據服務的類別：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 值來加以設定。