可延伸的資料服務

可延伸的資料服務具有在多重節點上的作用中實例之潛力。可延伸的服務使用兩種資源群組：利用 可延伸的資源群組來包含相關的應用程式資源，以及故障轉移資源群組來包含與可延伸服務相關的網路資源 ( 共用地址)。可延伸資源群組可以在多重節點上成為線上，所以即可一次執行多個服務實例。放置共用位址的故障轉移資源群組一次只在一個節點上啟動成為線上。放置可延伸服務的所有節點，均使用相同的共用位址來放置服務。

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

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

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

每個應用程式實例的 TCP 狀態是保存在具有該實例的節點上，而不是在整體介面節點上。因此，整體介面節點的故障並不會影響連接。

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

圖 3-7 故障轉移和可延伸資源群組範例

可延伸服務的架構

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

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

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

• 平衡資料流量

• 網路和資料服務的支援 (使用 Resource Group Manager)

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

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

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

平衡資料流量策略

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

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