資料服務

資料服務一詞是用來描述已經配置在叢集上 (非單一伺服器) 執行的協力廠商應用程式，例如 Oracle 或 iPlanet Web Server。 資料服務是由應用程式、Sun Cluster 配置檔及控制下列應用程式動作的 Sun Cluster 管理方法所組成。

• 啟動

• 停止

• 監控並採行校正措施

圖 3-4 比較在單一應用程式伺服器 (單一伺服器模型)，與在叢集上執行的同一應用程式 (叢集伺服器模型)。請注意，就使用者的觀點而言，這兩種配置除了叢集應用程式可能執行較快且較為高度可用以外，並無任何差別。。

圖 3-4 標準與叢集用戶端 / 伺服器配置

在單一伺服器模型中，您會配置應用程式 (主機名稱) 來存取伺服器。 主機名稱與實體伺服器有關。

在叢集伺服器模型中，公用網路介面為邏輯主機名稱或共用的位址。網路資源一詞是用來表示邏輯主機名稱與共用位址。

某些資料服務會要求您指定邏輯主機名稱或共用位址來做為網路介面，而它們是不能互相交換的。 其它資料服務則容許您指定邏輯主機名稱或共用位址。 請參閱各資料服務的安裝與配置檔，以取得您必須指定的介面類型的詳細資訊。

網路資源與特定的實體伺服器無關，它可在實體伺服器間遷移。

網路資源最初與一個稱為主要的節點關連。 如果主要節點故障，網路資源和應用程式資源就會發生故障轉移而移轉至不同的叢集節點 (稱為次要節點)。 當網路資源發生故障轉移時，只要稍有延誤，應用程式資源就繼續在次要節點上執行。

圖 3-5 比較單一伺服器模型與叢集伺服器模型。 請注意，在叢集伺服器模型中，網路資源 (在此例中為邏輯主機名稱) 可於兩或多個叢集節點間移動。 應用程式被配置為使用此邏輯主機名稱，而非與特定伺服器相關的主機名稱。

圖 3-5 固定主機名稱與邏輯主機名稱

共用位址最初也與一個節點關連。 此節點稱為「整體介面節點」(Global Interface Node，GIN)。 共用位址被用作叢集的單一網路介面。 稱之為整體介面 (Global Interface)。

邏輯主機名稱模型與可延伸服務模型的差異，在於後者的每個節點在其回送介面中亦主動配置有共用位址。 此配置可使同時在數個節點上作用中的資料服務具有多重實例。 可延伸的服務 一詞表示，您可藉由新增附加的叢集節點來提供更多 CPU 的能力給應用程式，其效能也隨之延伸。

假如 GIN 故障，共用位址可攜至另一個也正在執行應用程式實例的節點 (因而使此另一節點成為新的 GIN)。但共用位址也可能發生故障轉移而移轉至另一個先前未執行應用程式的節點。

圖 3-6 比較單一伺服器配置與叢集可延伸服務配置。 請注意，在可延伸服務配置中，共用位址存在於所有節點上。 與邏輯主機名稱用於移轉資料服務方式類似的是，應用程式被配置為使用此共用位址，而不是與特定伺服器相關的主機名稱。

圖 3-6 固定主機名稱與共用位址

資料服務方法

此 Sun Cluster 軟體提供一套服務管理方法。 這些方法在 Resource Group Manager (RGM) 的控制之下執行，用來啟動、停止和監視叢集節點上的應用程式。 這些方法配合叢集框架軟體和多主機磁碟，讓應用程式變成高可用性資料服務。

RGM 也會管理叢集內的資源，包括應用程式的實例和網路資源 (邏輯主機名稱和共用位址)。

除了 Sun Cluster 軟體提供的方法之外，此 SunPlex 系統亦提供 API 與數個資料服務發展工具。 這些工具可以讓 Sun Cluster 軟體發展出得以使其它應用程式，如高可用資料服務般執行的資料服務方法。

Resource Group Manager (RGM)

RGM 控制資料服務 (應用程式) 如同資源，由資源類型施行管理。這些實作是由 Sun 提供或由 Sun 提供或由開發人員以一般資料服務範本、「資料服務發展檔案庫 API」(Data Service Development Library API，DSDL API)，或是「資源管理 API」(Resource Management API，RMAPI) 所建立的。叢集管理者建立並管理在儲存區中的資源，稱為資源群組 。RGM 停止和啟動所選取節點上的資源群組，以回應叢集成員變更。

RGM 作用於資源及資源群組上。RGM 動作能使資源及資源群組在線上及離顯狀態間移動。 可應用於資源及資源群組的狀態及設定的完整說明，請參閱 "資源及資源群組狀態與設定值" 一節。

故障轉移資料服務

如果正在執行資料服務的節點 (主要節點) 故障，該服務會移轉至其它運作中的節點而不需要使用者介入。 故障轉移服務利用故障轉移資源群組 (failover resource group)，這是應用程式實例資源和網路資源 (邏輯主機名稱) 的儲存區。 邏輯主機名稱是 IP 位址，可以在某個節點配置上線，稍後自動在原始節點配置下線，並在其它節點配置上線。

對於故障轉移資料服務，應用程式實例僅在單一節點上執行。 如果錯誤監視器偵測到錯誤，則會嘗試於同一節點重新啟動實例，或於其它節點啟動實例 (故障轉移)，視資料服務的配置方式而定。

可延伸的資料服務

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

服務要求經由單一網路介面 (整體介面) 進入叢集，並且根據平衡資料流量策略 (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 值來加以設定。

故障回復設定

資源群組因故障轉移，從某個節點移轉至另一個節點。 發生此情況時，原來的次要節點就成為新的主要節點。 故障回復設定指定當原來的主要節點回到線上時會採取的動作。 此選項是要使原來的主要節點再次成為主要節點 (故障回復) 或維持目前的主要節點。 您可使用Failback資源群組屬性設定來指定您要的選項。

在某些情況下，假如放置資源群組的原始節點重複故障和重新開機，設定故障回復可能會造成資源群組的可用性降低。

資料服務錯誤監視器

每個 SunPlex 資料服務均提供了錯誤監視器，定期地測試資料服務以判斷其健康狀態。錯誤監視器會驗證，應用程式常駐程式是否為執行中，以及用戶端是否接受服務。 根據測試所傳回的資訊，可以起始預先定義的動作，如重新啟動常駐程式或進行故障轉移。