資料服務

資料服務一詞說明協力廠商應用程式，例如 Sun Java System Web Server (以前稱為 Sun Java System Web Server)；對於基於 SPARC 的叢集而言，說明 Oracle，它已被配置為在叢集上執行，而不是在單一伺服器上執行。 資料服務包含一個應用程式、專用的 Sun Cluster 配置檔案以及 Sun Cluster 管理方法，可控制應用程式的下列動作。

• 啟動

• 停止

• 監視並採用校正措施

• 如需有關資料服務類型的資訊，請參閱Sun Cluster 簡介 (適用於 Solaris 作業系統)中的「資料服務」。

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

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

在單一伺服器模型中，可配置應用程式，以透過特定的公用網路介面 (一個主機名稱) 來存取伺服器。 主機名稱與該實體伺服器關聯。

在叢集伺服器模型中，公用網路介面是一個邏輯主機名稱或一個共用位址。 網路資源一詞用於指代邏輯主機名稱和共用位址。

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

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

網路資源最初與一個節點 (主要節點) 相關聯。 如果主要節點發生故障，則網路資源與應用程式資源會故障轉移至其他叢集節點 (次要節點)。 當網路資源發生故障轉移時，只要稍有延誤，應用程式資源就繼續在次要節點上執行。

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

圖 3–4 固定主機名稱與邏輯主機名稱

共用位址最初也與一個節點相關聯。 此節點稱為整體介面節點。 共用位址用來作為叢集的單一網路介面。 稱之為整體介面。

邏輯主機名稱模型與可延伸服務模型的差異，在於後者的每個節點在其回送介面中亦主動配置有共用位址。 此配置可使同時在數個節點上作用中的資料服務具有多重實例。 「可延伸服務」一詞意味著您可以透過加入其他叢集節點為應用程式增加 CPU 處理能力，從而延伸效能。

如果整體介面節點發生故障，可將共用位址提供到也在執行應用程式實例的另一個節點上 (從而使此另一個節點成為新的整體介面節點)。 但共用位址也可能發生故障轉移而移轉至另一個先前未執行應用程式的節點。

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

圖 3–5 固定主機名稱與共用位址

資料服務方法

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

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

除了 Sun Cluster 軟體提供的方法，SunPlex 系統還提供了 API 與數種資料服務開發工具。 這些工具可讓應用程式設計師藉由 Sun Cluster 軟體來開發讓其他應用程式作為高度可用資料服務執行所需的資料服務方法。

故障轉移資料服務

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

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

可延伸資料服務

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

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

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

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

---

註解 –

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

---

圖 3–6 顯示的範例是可延伸服務的故障轉移和可延伸資源群組，以及它們之間的相依性。 此範例顯示三個資源群組。 故障轉移資源群組包含高可用性 DNS 的應用程式資源，以及高可用性 DNS 和高可用性 Apache Web Server (僅可在基於 SPARC 的叢集中使用) 所使用的網路資源。 可延伸資源群組僅包含 Apache Web Server 的應用程式實例。 請注意，可延伸的資源群組與故障轉移資源群組之間存在資源群組相依性 (實線)，並且所有 Apache 應用程式資源都依賴作為共用位址的網路資源 schost-2 (虛線)。

圖 3–6 SPARC: 故障轉移與可延伸的資源群組範例

平衡資料流量策略

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

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

故障回復設定

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

在某些情況下，如果主控資源群組的原始節點多次失敗並重新啟動，設定故障回復可能會造成資源群組的可用性降低。

資料服務故障監視器

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