test

Sun Cluster 3.0 概念

數據服務

數據服務一詞是用來描述已經配置在叢集上 (非單一伺服器) 執行的協力廠商應用程式。而數據服務包括應用軟體軟體，及可啟動、停止和監視此應用程式的 Sun Cluster 軟體。

Sun Cluster 提供數據服務方法來控制和監督叢集內的應用程式。這些方法在 Resource Group Manager (RGM) 的控制之下執行，用來啟動、停止和監督叢集節點上的應用程式。這些方法配合叢集組織架構軟體和多主機磁碟，讓應用程式變成高可用性數據服務。 作為高可用性的數據服務，它們可以在叢集內發生任意單一失效之後，防止應用程式明顯中斷。 失效可能是有關節點、介面元件或應用程式本身。

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

Sun Cluster 亦提供 API 和數據服務設計工具，讓應用程式程式設計師開發使其它應用程式作為高可用性數據服務來執行 Sun Cluster 所需要的數據服務方法。

Resource Group Manager (RGM)

Sun Cluster 提供環境讓應用程式具有高可用性或可延伸性。RGM 會影響 resources，這些邏輯元件可以被：

RGM 控制數據服務 (應用程式) 如同資源，由 resource type施行管理。 這些施行是由 Sun 提供或由設計人員以一般數據服務範本、數據服務發展檔案庫 API (DSDL API)，或是 Sun Cluster 資源管理 API (RMAPI) 所建立的。叢集管理者建立和管理稱為資源群組 (resource groups) 之容器中的資源， 形成失效保護和切換的基本單元。RGM 停止和啟動所選取節點上的資源群組，以回應叢集成員變更。

失效保護數據服務

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

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

可延伸的數據服務

可延伸的數據服務具有在多重節點上的作用中實例之潛力。可延伸的服務利用 可延伸的資源群組 (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 失效保護和可延伸資源群組範例

Graphic

可延伸服務架構

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

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

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

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

Graphic

沒有放置整體介面的節點 (代理節點) 將共用位址放在其迴圈介面。 進入 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 策略，預設都會使用加權平衡資料流量策略，因此用戶端的起始要求會被導向平衡資料流量程式所指定的實例。在用戶端建立與執行實例之節點的關係之後，只要該節為可存取，且載入平衡策略未變更，則後續的 要求會被導向該實例。

特定平衡資料流量策略的其它明細討論如下。

失效回復設定

資源群組因失效保護，從某個節點移轉至另一個節點。您可以指定，當發生資源群組移轉至另一個節點時，在先前執行資源群組的節點返回叢集之後，資源群組將會「失效回復」至原來的節點。這個 選項是使用 Failback 資源群組性質設定值來設定的。

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

數據服務錯誤監視器

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