資料服務

專有名詞資料服務說明的是已配置為在叢集上而不是在單一伺服器上執行的應用程式，例如 Sun Java System Web Server 或 Oracle。資料服務由一個應用程式、專用的 Sun Cluster 配置檔案以及控制應用程式以下動作的 Sun Cluster 管理方法組成。

• 啟動

• 停止

• 監視並採用校正措施

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

圖 3–4 將在單一應用程式伺服器 (單一伺服器模型) 上執行的應用程式與在叢集 (叢集伺服器模型) 上執行的同一應用程式進行比較。這兩種配置之間的唯一差異就是叢集應用程式會執行得更快並且可用性更高。

圖 3–4 標準主從式配置與叢集主從式配置

在單一伺服器模型中，您將應用程式配置為透過特定的公用網路介面 (主機名稱) 存取伺服器。主機名稱與實體伺服器有關。

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

某些資料服務要求您將邏輯主機名稱或共用位址指定為網路介面。邏輯主機名稱和共用位址不能互換。其他資料服務則容許您指定邏輯主機名稱或共用位址。請參考每個資料服務的安裝和配置，以取得有關必須指定的介面類型的詳細資訊。

網路資源不與特定的實體伺服器相關。網路資源可以在實體伺服器之間遷移。

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

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

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

共用位址也與一個節點初始相關。此節點稱為全域介面節點。共用位址 (稱為全域介面) 作為叢集的單一網路介面。

邏輯主機名稱模型和可延伸服務模型之間的差異是︰在後者中，每個節點也都在其迴路介面上主動配置了共用位址。此配置使資料服務的多個實例可以同時在多個節點上處於使用中的狀態。「可延伸的服務」一詞表示，您可藉由新增附加的叢集節點來為應用程式提供更多 CPU 能力，其效能也隨之延伸。

如果全域介面節點發生故障，則可以在也在執行該應用程式實例的其他節點上啟動共用位址 (從而使此節點成為新的全域介面節點)。但共用位址也可能發生故障轉移而移轉至另一個先前未執行應用程式的節點。

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

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

資料服務方法

Sun Cluster 軟體提供了一組服務管理方法。這些方法在 資源群組管理員 (RGM) 的控制下執行，它會使用這些方法啟動、停止和監視叢集節點上的應用程式。這些方法配合叢集框架軟體和多重主機裝置，可讓應用程式成為防故障備用或可延伸的資料服務。

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

除 Sun Cluster 軟體提供的方法之外，Sun Cluster 系統也提供了 API 和數種資料服務開發工具。這些工具使應用程式開發人員可以開發所需的資料服務方法，以使用 Sun Cluster 軟體使其他應用程式作為高度可用的資料服務執行。

故障轉移資料服務

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

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

可延伸的資料服務

可延伸的資料服務具有在多重節點上的使用中實例之潛力。可延伸服務使用以下兩個資源群組︰

• 含有應用程式資源的可延伸資源群組。

• 包含可延伸服務所依賴的網路資源 (共用位址) 的容錯移轉資源群組。

可延伸資源群組可以在多重節點上成為線上，所以即可一次執行多個服務實例。放置共用位址的故障轉移資源群組一次只在一個節點上啟動成為線上。宿主可延伸服務的所有節點均使用相同的共用位址宿主服務。

服務請求透過單一網路介面 (全域介面) 進入叢集。會根據負載平衡策略設定的數個預先定義的演算法之一將這些請求將分配到各節點。叢集可以使用平衡資料流量策略，來均衡各個節點之間的服務負載。存放其他共用位址的不同節點上可以存在多個全域介面。

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

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

---

備註 –

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

---

圖 3–7 顯示了容錯移轉和可延伸資源群組的範例，以及兩者之間存在的可延伸服務的相依性。此範例顯示三個資源群組。容錯移轉資源群組包含高度可用的 DNS 之應用程式資源，以及高度可用的 DNS 和高度可用的 Apache Web Server (僅可在基於 SPARC 的叢集中使用) 所使用的網路資源。可延伸資源群組僅包含 Apache Web Server 的應用程式實例。請注意，可延伸和容錯移轉資源群組 (實線) 之間存在資源群組相依性。此外，所有 Apache 應用程式資源都依賴網路資源 schost-2，該資源為共用位址 (虛線)。

圖 3–7 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」。只要實例維持啟動與可存取的狀態，且此服務處於線上狀態時負載平衡策略為變更，便可保證用戶端的所有請求均傳送至同一伺服器實例。

例如，用戶端上的 Web 瀏覽器使用三個不同的 TCP 連線透過連接埠 80 連線至的共用 IP 位址。然而，連線會在服務中交換它們之間快取的階段作業資訊。

Sticky 策略的一般化會延伸至在背景中並且在同一實例上交換階段作業資訊的多個可延伸服務。當這些服務在背景中並且在同一實例上交換階段作業資訊時，則稱該用戶端對同一節點上偵聽不同連接埠的多個伺服器實例「sticky」。

例如，電子商務網站上的某位顧客透過在連接埠 80 上使用 HTTP 將購物車裝滿商品。然後該顧客切換至連接埠 443 上的 SSL 來傳送安全資料以使用信用卡支付購物車內的商品。

Wildcard sticky 服務使用動態指定的連接埠號碼，但仍然希望用戶端請求傳送到同一節點。用戶端在具有同一 IP 位址的連接埠上「sticky wildcard」。

這種策略的典型範例是被動模式 FTP。例如，某用戶端連線至連接埠 21 上的 FTP 伺服器。伺服器則會指示該用戶端連線回動態連接埠範圍內的偵聽程式埠伺服器。此 IP 位址的所有請求均轉發至同一節點伺服器透過控制資訊通知用戶端。

依預設，對於其中的每個 sticky 策略，加權式負載平衡策略均有效。因而，會將用戶端的初始請求導向至負載平衡器指定的實例。用戶端為實例正在其上執行的節點建立關聯之後，會有條件地將以後的請求導向至該實例。節點必須可以存取且負載平衡策略必須未變更。

有關特定的負載平衡策略的其他詳細資訊如下。

• 加權式。這項載入會按照指定的加權值來分配到各種節點。此策略可以透過使用 Load_balancing_weights 特性的 LB_WEIGHTED 值設定。如果節點的權重未明確設定時，則此節點的權重將預設為「一」。

  加權策略可將一定百分比的用戶端通訊重新導向某個特定節點。假定 X=權重且 A=所有使用中節點的總權重，則使用中的節點的所有新連線中大約 X/A 的連線將會導向至該使用中的節點。然而，連線的總數必須足夠大。此策略不針對個別的要求。

  請注意，此策略並非全體循環式。round-robin 策略總是會使來自某個用戶端的每個請求都傳送至其他節點。例如，第一個請求會傳送至節點 1，第二個請求會傳送至節點 2，以此類推。

• Sticky。在此策略中，會於配置應用程式資源時知道通訊埠集合。此策略可以透過使用 Load_balancing_policy 資源特性的 LB_STICKY 值設定。

• Sticky-wildcard。此策略是一般「Sticky」策略的超集合。對於透過 IP 位址識別的可延伸服務，由伺服器為其指定連接埠 (並且事先並不知道)。通訊埠可能會變更。此策略可以透過使用 Load_balancing_policy 資源特性的 LB_STICKY_WILD 值設定。

故障回復設定

資源群組因故障轉移，從某個節點移轉至另一個節點。發生容錯移轉時，原來的次要節點將成為新的主要節點。故障回復設定可以指定當原來的主要節點回到線上後將發生的動作。此選項是要使原來的主要節點再次成為主要節點 (故障回復) 或維持目前的主要節點。您可以使用 failback 資源群組特性設定指定要使用的選項。

如果原來存放資源群組的節點發生故障並反復重新啟動，則設定故障回復會導致資源群組的可用性降低。

資料服務錯誤監視器

每個 Sun Cluster 資料服務均提供一個故障監視器，可定期探測資料服務以確定其運作狀態。故障監視器驗證應用程式常駐程式是否在執行，以及用戶端是否正在接受服務。根據探測傳回的資訊，可以啟動預先定義的動作，如重新啟動常駐程式或進行容錯移轉。