test

Sun Cluster 3.0 概念

叢集管理與應用程式設計

這項資訊主要是給使用 Sun Cluster API 和 SDK 的系統管理者和應用程式開發人員參考。叢集系統管理者可以利用這些資訊來輔助安裝、配置和管理叢集軟體。應用程式開發人員可以使用這些資訊來瞭解將要利用的叢集環境。

下圖顯示了叢集管理概念如何對應至叢集架構的高階觀點。

圖 3-1 Sun Cluster 軟體架構

Graphic

管理介面

您可以從多種使用者介面選擇，以便安裝、配置和管理 Sun Cluster 與 Sun Cluster 數據服務。您可以透過具備說明的指令行介面來完成系統管理作業。在指令行介面頂端是可以簡化選取配置作業的部份公用程式集。Sun Cluster 也具有一個模組，此模組可作為 Sun Management Center 的一部份來執行，以提供 GUI 給某些叢集作業。請參照 Sun Cluster 3.0 系統管理手冊 中的介紹章節以取得管理介面的完整說明。

叢集時間

叢集中所有節點的時間均必須同步。您是否以任何外來時間來源同步化叢集節點，對叢集作業並不重要。Sun Cluster 使用網絡時間協定 (NTP) 來同步化節點間的時鐘。

一般而言，系統時鐘在傾刻之間變更並不會造成問題。然而，如果您在作用中的叢集上執行 date(1)、rdate(1M)，或 xntpdate(1M)（交談式，或在 cron 指令集之內），您可以強制進行比傾刻更久的時間變更來同步化系統時鐘與時間來源。這種強制變更可能會導致檔案修改時間戳記有問題或混淆 NTP 服務。

當您在每一個叢集節點上安裝 Solaris 作業環境時，您有機會變更節點的預設時間及日期設定。一般而言，您可以接受出廠預設值。

當您使用 scinstall(1M) 來安裝 Sun Cluster 時，程序中的一個步驟是對叢集配置 NTP。 Sun Cluster 提供一個範本檔案，ntp.cluster（請參閱已安裝之叢集節點上的 /etc/inet/ntp.cluster），該檔案建立了所有叢集節點之間的對等關係，以某一個節點作為"偏好的" 節點。由專用的主電腦名稱和跨叢集交互連接時發生的時間同步化來識別節點。關於如何配置 NTP 的叢集，已納入 Sun Cluster 3.0 安裝手冊。

另外一種方式是，您可以在叢集之外設定一或多部 NTP 伺服器，並變更 ntp.conf 檔案以反映該配置。

在正常作業中，您應該不會需要調整叢集的時間。然而，如果您安裝 Solaris 作業環境時未正確設定時間，而您想要變更時間，其執行程序就在 Sun Cluster 3.0 系統管理手冊 中。

高可用性的組織架構

Sun Cluster 讓使用者和資料間的"路徑"上所有元件具有高度的可用性，包括網路介面、應用程式本身、檔案系統和多重主機磁碟。一般而言，如果系統內有任何單一 (軟體或硬體) 失效，叢集元件就具有高度可用性。

下表顯示 Sun Cluster 元件失效的種類 (硬體和軟體)，以及內建於高可用性架構內的復原種類。

表 3-1 Sun Cluster 失效偵測與復原的層次

失效的叢集資源 

軟體復原 

硬體復原 

數據服務 

HA API，HA 組織架構 

無 

公用網路配接卡 

網路配接卡失效保護 (NAFO) 

多重公用網路配接卡 

叢集檔案系統 

主要與次要複製 

多重主機磁碟 

鏡映多重主機磁碟 

容體管理 (Solstice DiskSuite 和 VERITAS 容體管理者) 

硬體 RAID-5 (例如，Sun StorEdge A3x00) 

整體裝置 

主要與次要複製 

多重裝置路徑，叢集傳輸接點 

私有網路 

HA 傳輸軟體 

多重私有硬體獨立網路 

節點  

CMM，failfast 驅動程式 

多重節點 

Sun Cluster 高可用性組織架構快速地偵測到某個節點失效，並且建立一個新的相等伺服器給 叢集中剩餘節點上的組織架構資源。隨時皆可使用組織架構資源。未受故障節點影響的組織架構資源，在回復時完全可加以使用。此外，已失效節點的組織架構資源一經回復之後，便會成為可使用。已回復的組織架構資源不必等待所有其他的組織架構資源完成回復。

大多數可用性頗高的組織架構資源會回復到使用此資源的應用程式（數據服務）。會在各項節點失效時完整保留組織架構資源存取的語義學。應用程式無法辨識出組織架構資源伺服器已移到另一個節點。只要從另一節點到磁碟存在著另一個替代的硬體路徑，對於在使用檔案、裝置以及連接到 此節點的磁碟容體上的程式而言，單一節點的失效便是完全的透通。其中的一項範例便是使用具有連到多重節點的連接埠的多重主機磁碟。

叢集成員監視器

「叢集成員監視器 (CMM)」是一組分散式的代理程式，每個叢集成員一個代理程式。 代理程式透過叢集交互連接來交換訊息，達到：

與先前的 Sun Cluster 版次不同，CMM 完全在核心程式中執行。

叢集成員

CMM 的主要功能，是建立在任何時候參與叢集之節點集合的全叢集協議。Sun Cluster 稱此限制 為cluster membership。

若要決定叢集全體成員，並在最後確保資料完整性，CMM 會：

請參閱 "法定人和法定裝置" 以取得有關叢集如何保護自，以免分割成多重個別叢集的其它資訊。

叢集成員監視器重新配置

為了使資料免於毀損，所有的節點必須對叢集成員達成一致的協議。 必要時，CMM 會為了回應失效而協調叢集服務 (應用程式) 的叢集重新配置。

CMM 從叢集傳輸層接收有關連接到其它節點的資訊。在重新配置期間，CMM 使用叢集交互連接來交換狀態資訊。

在偵測到叢集成員變更之後，CMM 會執行叢集的同步化配置，此時可能會根據新的叢集成員而重新分配叢集資源。

叢集配置儲存庫 (CCR)

「叢集配置儲存庫 (CCR)」是一個私有、全叢集式的資料庫，用來儲存專屬於叢集配置與狀態 的資訊。CCR 是分散式分散式資料庫。每一個節點保有一個完整的資料庫複製。CCR 確保所有的節點 均具有一致的叢集「世界」視區。為了避免毀損資料，每一個節點都需要知道叢集資源的現行狀態。

CCR 是實作於核心程式中的一個高可用性服務。

CCR 對於更新作業是使用二階段式確定 (two-phase commit) 演算法：必須在所有的叢集成員均順利完成更新，否則更新就會被回復。CCR 使用叢集交互連接來應用分散式更新。

小心 - 小心 -

雖然 CCR 是由文字檔所組成，請絕對不要手動編輯 CCR 檔案。每一個檔案均含有總和檢查紀錄，以確保一致性。手動更新 CCR 檔案會導致節點或整個叢集停止運作。

CCR 依賴 CMM 來保證叢集只有在到達法定數目時才能執行。CCR 負責驗證整個叢集的資料一致性、依需要執行復原，以及便利資料的更新。

整體裝置

Sun Cluster 使用整體裝置來提供全叢集、高可用性存取叢集中的任何裝置 (從任意節點)， 不管裝置是否為實體連接。一般而言，如果節點是在提供整體裝置的存取時失效，Sun Cluster 自動探尋該裝置的其它路徑並將存取重新導向至該路徑。Sun Cluster 整體裝置包括磁碟、CD-ROM 和磁帶。然而，磁碟是唯一支援多埠的整體裝置。 這代表 CD-ROM 和磁帶裝置目前不是高可用性裝置。每部伺服器上的區域磁碟亦不是多埠式，因此不是高可用性裝置。

叢集自動指定唯一的 ID 給叢集中的每個磁碟、CD-ROM 和磁帶裝置。這項指定可以讓人從叢集的任何節點一致存取各個裝置。整體裝置名稱空間是保存於 /dev/global 目錄。請參閱 "整體名稱空間" 以取得其他資訊。

多埠式整體裝置提供一條以上的裝置路徑。如果是多主機磁碟，因為磁碟是由一個節點以上所共有之磁碟裝置群組的一部份，所以多主機磁碟具備高可用性。

裝置 ID (DID)

Sun Cluster 藉由建構裝置 ID (DID) 虛擬驅動程式來管理整體裝置。此驅動程式是用來自動指定唯一的 ID 給叢集中的每個裝置，包括多主機磁碟、磁帶機和 CD-ROM。

裝置 ID (DID) 虛擬驅動程式是叢集的整體裝置存取功能的主要部份。 DID 驅動程式會測試叢集的所有節點，並建置唯一磁碟裝置的清單，指定每個裝置唯一的主要號碼和次要號碼，在叢集的所有節點間是一致的。 整體裝置的存取是利用由 DID 驅動程式所指定的唯一裝置 ID 來執行的，而不是傳統的 Solaris 裝置 ID，如磁碟的 c0t0d0。

這種方式可以確保使用磁碟裝置的應用程式 (如容體管理者或使用原始裝置的應用程式) 可以使用一致的裝置存取路徑。這種一致性對多主機磁碟而言特別重要，因為每個裝置的區域主要號碼和次要號碼會隨著節點不同而改變，因此也會變更 Solaris 裝置命名慣例。 例如，node1 可能將多主機磁碟視為 c1t2d0，node2 可能將同一磁碟視為完全不同的其它名稱 c3t2d0。DID 驅動程式會指定一個整體名稱 (如 d10)，而節點則改用此名稱，提供了每個節點一致的多主機磁碟對應。

您是透過 scdidadm(1M) 和 scgdevs(1M) 來更新和管理裝置 ID。請參閱相關的線上援助頁，以取得其他資訊。

磁碟裝置群組

在 Sun Cluster 中，所有的多主機磁碟必須受 Sun Cluster 組織架構的控制。首先您在多主機磁碟上建立磁碟群組-或 Solstice DiskSuite 磁碟組或是 VERITAS 容體管理者 磁碟群組。然後，註冊容體管理者磁碟群組為 Sun Cluster 碟機裝置群組 (disk device groups)。磁碟裝置群組是一種整體裝置類型。 此外，Sun Cluster 會將各項個別的磁碟登錄為磁碟裝置群組。

註解 -

磁碟裝置群組與資源群組無關。某個節點可以主控一個資源群組 (代表一群數據服務處理程序)，而另外一個節點則可以主控數據服務所存取的磁碟群組。 然而，最佳的方式是將儲存特定應用程式之資料的磁碟裝置群組，以及包含應用程式之資源 (應用程式常駐程式) 的資源群組保存在同一節點上。請參照 Sun Cluster 3.0 Data Services Installation and Configuration Guide 中的概觀章節，以取得有關磁碟裝置群組和資源群組關聯的資訊。

利用磁碟裝置群組，容體管理者磁碟群組會變成「整體」，因為其提供了基礎磁碟的多重路徑支援。 實際連接置多主機磁碟的每一個叢集節點，均提供了一個磁碟裝置群組的路徑。

註解 -

整體裝置如果是由一個以上的叢集節點所共有之裝置群組的一部份，則具備高可用性。

磁碟裝置失效保護

因為磁碟外殼連接至一個以上的節點，當目前主控裝置群組的節點失敗時，仍可透過替代路徑來存取該外殼中的所有磁碟裝置群組。 主控裝置群組的節點失效不會影響裝置群組的存取，但是在執行復原與一致性檢查的期間除外。 在這段期間內，所有的要求均會暫停執行 (對於應用程式為透通的)，直到系統恢復使用裝置群組為止。

圖 3-2 磁碟裝置群組失效保護

Graphic

整體名稱空間

讓整體裝置可行的 Sun Cluster 機制稱為整體名稱空間 (global namespace)。 整體名稱空間包括 /dev/global/ 階層以及容體管理者名稱空間。 整體名稱空間反映多主機磁碟和區域磁碟 (以及任何其它的叢集裝置，如 CD-ROM 和磁帶)，並提供 多主機磁碟的多重失效保護路徑。實際連接多主機磁碟的每一個節點，均提供了一條儲存體路徑給叢集中的任何節點。

一般而言，容體管理者名稱空間是位於 /dev/md/diskset/dsk (和 rdsk) 目錄 (Solstice DiskSuite)；以及 /dev/vx/dsk/disk-group 和 /dev/vx/rdsk/disk-group 目錄 (VxVM)。這些名稱空間是由各自在整個叢集匯入的每個 Solstice DiskSuite 磁碟組和每個 VxVM磁碟群組之目錄所組成。每個 目錄對該磁碟組或磁碟群組中的每個 metadevice 或容體均含一個裝置節點。

在 Sun Cluster 中，區域容體管理者名稱空間中的每個裝置節點均會被置換為 /global/.devices/node@nodeID 檔案系統 中裝置節點的符號連接，其中 nodeID 是在叢集中代表節點的整數。Sun Cluster 仍繼續在其標準位置表示容體管理者裝置，如符號連結。整體名稱空間和標準容體管理者均可由任何叢集節點使用。

整體名稱空間的優點包括：

區域和整體名稱空間範例

下表顯示多主機磁碟的區域和整體名稱空間之間的對應，c0t0d0s0。

表 3-2 區域和整體名稱空間對應

元件/路徑 

本端節點名稱空間 

整體名稱空間 

Solaris 邏輯名稱 

/dev/dsk/c0t0d0s0

/global/.devices/node@ID/dev/dsk/c0t0d0s0

DID 名稱 

/dev/did/dsk/d0s0

/global/.devices/node@ID/dev/did/dsk/d0s0

Solstice DiskSuite 

/dev/md/diskset/dsk/d0

/global/.devices/node@ID/dev/md/diskset/dsk/d0

VERITAS 容體管理者 

/dev/vx/dsk/disk-group/v0

/global/.devices/node@ID/dev/vx/dsk/disk-group/v0

整體名稱空間是在安裝和更新的每次重新配置重新開機時自動產生。 您也可以執行 scgdevs(1M) 指令來產生整體名稱空間。

叢集檔案系統

叢集檔案系統是某個節點上的核心程式和基礎檔案系統，以及在擁有實體連接到磁碟之節點上的容體管理者間的代理。

叢集檔案系統是相依於與一或多個節點實體連線的整體裝置 (磁碟、磁帶 CD-ROM)。整體裝置 可以從叢集中的任何節點，透過相同的檔名來存取 (例如，/dev/global/)，不管 該節點是否實體連線儲存裝置。您可以像使用一般裝置一樣地使用整體裝置，亦即，您可以使用 newfs 及/或 mkfs 來建立檔案系統。

您可以使用 mount -g 以全域方式裝設檔案系統於整體裝置， 或 mount 以區域方式裝設。程式可以從叢集的任何節點，透過相同的檔名存取叢集檔案系統 中的檔案 (例如，/global/foo)。您可以裝設叢集檔案系統於所有的節點上。您不能裝設叢集檔案系統於叢集成員的子集上。

使用叢集檔案系統

在 Sun Cluster 中，所有的多主機磁碟均配置為磁碟裝置群組，可以是 Solstice DiskSuite 磁碟組、VxVM 磁碟群組，或是不受軟體式容體管理者控制的個別磁碟。此外，也將區域磁碟配置為磁碟裝置群組：路徑從每個節點通到每個區域磁碟。 這種設定不表示從所有的節點一定可以使用磁碟上的資料。當磁碟上的檔案系統已裝設為叢集檔案系統時，才會將資料給所有節點使用。

被納入叢集檔案系統的區域檔案系統只有一個單一的磁碟儲存體連接。如果實體連接到磁碟儲存體的節點失效，其它的節點就無法再存取叢集檔案系統。您在無法從其它節點直接存取的單一節點上，可以擁有區域檔案系統。

設定 HA 數據服務，這樣一來，服務的資料就會儲存在叢集檔案系統中的磁碟裝置群組。 這種設定有許多優點。首先，資料具高可用性；亦即，因為磁碟是多主機式，如果該節點的目前主要路徑失效，就會將存取切換至可以直接存取同一磁碟的另一個節點。第二，因為資料是在叢集檔案系統上， 可以從任何的叢集節點直接檢視-您不需要登入目前主控磁碟裝置群組的節點，就可以 檢視資料。

代理檔案系統 (PXFS)

叢集檔案系統是根據具有下列特性的代理檔案系統 (PXFS)：

PXFS 不是另外的檔案系統類型。亦即，用戶端可以看見基礎檔案系統 (例如，UFS)。

叢集檔案系統獨立性

叢集檔案系統與基礎檔案系統和容體管理者無關。 目前，您可以使用 Solstice DiskSuite 或 VERITAS 容體管理者 在 UFS 上建置叢集檔案系統。

至於一般檔案系統，您可以用兩種方式裝設叢集檔案系統：

註解 -

因為 Sun Cluster 沒有強制叢集檔案系統的命名策略，您可以建立所有叢集檔案系統的裝載點在同一目錄下以簡化管理作業，如 /global/disk-device-group。 請參閱 Sun Cluster 3.0 安裝手冊 和 Sun Cluster 3.0 系統管理手冊 以取得其餘資訊。

Syncdir 裝設選項

syncdir 裝設選項可以用於叢集檔案系統。然而，如果您不指定 syncdir，效能就會明顯改善。如果您指定 syncdir，此項寫入便保證相容於 POSIX。如果沒有指定， 您將會有與 UFS 檔案系統看到的相同行為。例如，在某些情況下，沒有 syncdir，一直到關閉檔案，您才會發覺出現空間不足的狀況。利用 syncdir (和 POSIX 行為)，在關閉之前，便可查覺空間不足的狀況。因為您沒有指定 syncdir 而發生問題 的機會非常小，所以我們建議您不要加以指定，以獲得效能上的益處。

請參閱 "檔案系統 常問問題" 以取得有關整體裝置和叢集檔案系統的常見問題。

法定人和法定裝置

因為叢集節點共用資料和資源，叢集必須採取步驟來維護資料和資源完整性。 當節點不符合叢集成員規則時，叢集必須拒絕節點參與叢集。

在 Sun Cluster 中，決定節點參與叢集的機制稱為 quorum。 Sun Cluster 使用多票數演算法來實作法定程序。叢集節點和 quorum devices， (二或多個節點之間共用的磁碟) 投票來形成法定人。在 quorum device 中可包含使用者資料。

法定程序演算法是動態運作：當叢集事件 觸發其計算時，計算的結果會變更變更的生命週期。法定人可以防止兩種潛在的演算法 問題-split brain 和 amnesia-這兩種均會造成用戶端取得不一致的資料。 下表說明這兩種問題以及法定人程序如何解決它們。

表 3-3 叢集法定人程序，Split-Brain 與 Amnesia 問題

問題 

說明 

法定人程序解決方案 

Split brain 

在節點之間的叢集交互連接遺失，而且叢集分割為子叢集時發生，每個子叢集相信自己是唯一的分割區 

只允許具有多數票的分割區 (子叢集) 作為叢集執行 (在這樣的多數票情況下，最多只存在一個分割區) 

Amnesia 

發生時間，是在關機後叢集重新啟動，其中叢集資料比關機時還舊 

保證在啟動叢集時，至少有一個節點是最近叢集全體成員中的成員之一 (因此具有最近的配置資料) 

法定人票數

叢集節點和法定裝置 (二或多個節點之間共用的磁碟) 票選出法定人。依預設，當叢集節點 啟動和成為叢集成員時，叢集節點會獲得一票的法定人票數。節點也可能會是零票，例如，當安裝節點或管理者將節點置於維護狀態時。

法定裝置根據節點與裝置的連接數會獲得法定人票數。當設定法定裝置時，它會獲得最大票數 N-1，其中 N 是非零票數、和以連接埠至 法定裝置之節點的數目。例如，連接至兩個非零票數之節點的法定裝置，擁有一票法定人票數 (二減一)。

您是在叢集安裝期間或者稍後，使用 Sun Cluster 3.0 系統管理手冊 中說明的程序來配置法定裝置。

註解 -

只有當目前連接的節點中至少有一個節點是叢集成員時，才會增加法定裝置票數。 此外，在叢集啟動期間，只有當目前連接的節點中至少有一個節點正在啟動中，而且在此節點上次 關機時是最近啟動之叢集的成員時，才會增加法定裝置票數。

法定人程序配置

法定人配置是根據叢集中的節點數而定：

圖 3-3 法定裝置配置範例

Graphic

法定人準則

設定法定裝置時請使用下列準則：

提示 -

在一組節點之間配置一個以上的法定裝置。使用來自不同機殼的磁碟，以及在每組節點 之間配置奇數個法定裝置。如此便可防止個別法定裝置的失效。

失效隔離

叢集的主要議題是造成叢集出現分割的失效 (稱為 split brain)。發生此情形時，不是所有的節點均可通訊，所以個別節點或節點子集可能會嘗試形成個別或子集叢集。 每個子集或分割區可能相信，自己擁有唯一的多主機磁碟存取和所有權。 嘗試寫入磁碟的多個節點會導致資料毀損。

失效隔離藉由實際地防止磁碟存取，限制節點存取多主機磁碟。 當節點離開叢集時 (失效或被分割)，失效隔離可確保節點不會再存取碟。只有目前的成員可以存取 磁碟，因此維持了資料的完整性。

磁碟裝置服務提供失效保護功能給使用多主機磁碟的服務。當目前是磁碟裝置群組的主要 (所有者) 叢集成員失效或無法到達時，會選出新的主要成員，繼續提供磁碟裝置群組的存取，期間只出現輕微的中斷時間。 處理程序期間，在啟動新的主要成員之前，舊的主要成員會放棄存取裝置。然而，當成員退出叢集且接觸不到時，叢集就無法通知該主要節點釋放裝置。因此，您需要 一個方法讓存活的成員可以從失效的成員接手控制和存取整體裝置。

Sun Cluster 使用 SCSI 磁碟保留來實作失效隔離。使用 SCSI 保留，失效的節點會「隔離」多主機磁碟，以防止存取這些磁碟。

SCSI-2 磁碟保留支援一種保留形式，授與存取權給所有連接磁碟的節點 (沒有保留存在) 或限制單一節點的存取權 (握有保留的節點)。

當叢集成員偵測到另一個節點在叢集交互連接上已經不再進行通訊， 即會起始隔離程序來防止其它的節點存取共用磁碟。當發生此失效隔離時， 一般會令隔離節點混亂，並在其主控台上出現「保留衝突」訊息。

偵測到個節點不再是叢集成員時，會放置 SCSI 保留在此節點與其它節點之間共用的所有磁碟上，所以就發生保留衝突的狀況。隔離節點可能不知道，自己已被隔離，而且如果它嘗試存取其中一個共用磁碟，就會偵測到保留和混亂。

容體管理者

Sun Cluster 使用容體管理軟體，藉由鏡映和緊急備件磁碟來增加資料的可用性，以及處理磁碟失效和更換。

Sun Cluster 沒有自己的內部容體管理元件，但是依賴下列容體管理者：

叢集中的容體管理軟體提供支援：

當設定容體管理者於 Sun Cluster 時，您配置多主機磁碟為 Sun Cluster 磁碟裝置，容體管理者磁碟群組的外層。裝置可以是 Solstice DiskSuite 磁碟組或 VxVM 磁碟群組。

您必須將使用於數據服務的磁碟群組配置鏡映，才能讓磁碟於叢集內具備高可用性。

您可使用「metadevices」或「plexes」來做為原始裝置（資料庫應用程式），或是用以保留 UFS 檔案系統。

容體管理物件-metadevices 和容體-受叢集的控制，因此變成磁碟裝置群組。 例如，在 Solstice DiskSuite 中，當您在叢集中建立磁碟組時 (使用 metaset(1M) 指令)，會建立相同名稱的對應磁碟裝置群組。然後，當您在該磁碟組中建立 metadevices 時，即變成整體裝置。因此，磁碟組是磁碟裝置 (DID 裝置) 和所有裝置連接之主機的集合。磁碟組中必須具有一部以上 的主機來達到 HA，才能建立叢集中所有的磁碟組。類似的狀況會發生於您使用 VERITAS 容體管理者 的時候。設定每一個容體管理者的詳細資訊，附於 Sun Cluster 3.0 安裝手冊 的附錄。

在規劃您的磁碟組或磁碟群組時，有一個重要考慮事項，就是瞭解相關的磁碟裝置群組 如何關聯叢集內的應用程式資源 (資料)。請參照 Sun Cluster 3.0 安裝手冊 和 Sun Cluster 3.0 Data Services Installation and Configuration Guide 以取得這些議題的討論資訊。

數據服務

數據服務一詞是用來描述已經配置在叢集上 (非單一伺服器) 執行的協力廠商應用程式。而數據服務包括應用軟體軟體，及可啟動、停止和監視此應用程式的 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 數據服務均提供了錯誤監視器，定期地測試數據服務以判斷其健康狀態。 錯誤監視器會驗證，應用程式常駐程式是否為執行中，以及用戶端是否接受服務。根據測試所傳回的資訊， 可以起始預先定義的動作，如重新啟動常駐程式或進行失效保護。

開發新的數據服務

Sun 提供軟體，可讓您將各種應用程式當作叢集內可用性極高的數據服務來操作。 如果您要當作高可用性數據服務來執行的應用程式，目前不是由 Sun 所提供，您可以使用 API 或 DSDL API，將您的應用程式配置成為高可用性數據服務。 數據服務有兩類，亦即失效保護和可延伸。有一組 基準規則可用來判斷您的應用程式是否可以使用這些數據服務種類。特定的基準規則在 Sun Cluster 文件中有說明，其中說明了可用於您的應用程式的 API。

在此，我們提供一些準則來協助您瞭解，您的服務是否可以利用可延伸數據服務架構。 檢閱 "可延伸的數據服務" 節以取得可延伸服務的其它一般資訊。

滿足下列準則的新服務，則可以使用可延伸服務。如果現存的服務不完全符合這些準則， 可能需要改些某些部份，使服務能夠符合準則。

可延伸數據服務具有下列性質。首先，服務是由一或多個 伺服器 instances 所組成。每一個實例執行於不同的叢集節點上。同一節點無法執行相同服務的兩或多個實例。

第二，如果服務提供外部邏輯資料儲存處，從多部伺服器對此儲存處作並行存取時，必須同步化，以避免將之變更時遺失更新或讀取資料。請注意，我們強調「外部」，是為了區分 in-memory state 的儲存處與「邏輯」，因為儲存處是以單一實體呈現，雖然它本身可能會被複製。此外，此邏輯資料儲存處具有當任何伺服器實例更新儲存處時， 其它實例會立即看到更新的特性。

Sun Cluster 透過其叢集檔案系統與其整體原始分割區來提供這類的外部儲存體。例如，假設服務會寫入新的資料到外部登錄檔，或就地修改現存的資料。當執行此服務的多個實例時， 每個實例均存取此外部登錄，而且可能同時存取此登錄。每一個實例必須將此登錄的存取同步化， 否則實例會互相干擾。服務可以透過 fcntl(2) 和 lockf(3C) 的一般 Solaris 檔案鎖定，來達到所需的同步化。

這種儲存處的另一個範例是後端資料庫，例如高可用性的 Oracle 或 Oracle Parallel Server。請注意， 這種後端資料庫伺服器使用資料庫查詢或更新異動來提供內建的同步化，因此多重伺服器實例 不需要實作自己的同步化。

目前不是可延伸服務的服務範例，是 Sun 的 IMAP 伺服器。 服務會更新儲存處，但是該儲存處是私有的，而且當多個 IMAP 實例寫入此儲存處時，會因為未同步化而彼此覆寫。 IMAP 伺服器必須要改寫以同步化並行存取。

最後請注意，實例可能會具有與其它實例的資料區隔的私有資料。在此情況下，服務不需要關心自己的同步化並行存取，因為資料是私有的，而且只有該實例可以操作資料。因此，您必須慎防將此私有資料儲存在叢集檔案系統之下，因為它可能會變成可全域存取。

數據服務 API 與數據服務檔案庫 API

Sun Cluster 提供下列項目，可以使應用程式具備高可用性：

Sun Cluster 3.0 Data Services Installation and Configuration Guide 說明如何安裝和配置 Sun Cluster 提供的數據服務。Sun Cluster 3.0 Data Services Developers' Guide 說明如何導入其它應用程式，以便在 Sun Cluster 組織架構下具備高可用性。

此項 Sun Cluster API 和「數據服務檔案庫 API」，可讓應用程式程式設計師開發錯誤監視器和啟動及停止數據服務 實例的指令集。利用這些工具，應用程式可以變成具備失效保護和可延伸數據服務。此外，Sun Cluster 可提供 " 一般" 數據服務，可用來快速產生應用程式需要的啟動和停止方法，使其執行為高可用性數據服務。

資源與資源類型

數據服務利用數種 resources 類型：應用程式，如 Apache Web 伺服器或 iPlanet Web 伺服器，以及應用程式所仰賴的網路位址（邏輯名稱和共用位址）。應用程式和網路資源形成受 RGM 管理的基本單位。

資源是在全叢集式定義之 resource type 的個體化。 有數種已定義的資源類型。

數據服務式資源類型。例如，Sun Cluster HA for Oracle 是資源類型 SUNW.oracle， Sun Cluster HA for Apache 是資源類型 SUNW.apache。

網路資源為 SUNW.LogiclaHostname 或 SUNW.SharedAddress 資源類型。有兩種資源類型是由 Sun Cluster 產品預先登錄。

此項 SUNW.HAStorage 資源類型是用於將資源的啟動與資源所仰賴的磁碟裝置群組進行同步化。它可確保在數據服務啟動之前，叢集裝載檔案系統點路徑，整體裝置，整體裝置名稱可獲得。

RGM 管理的資源會分成群組，稱為資源群組，讓群組可以一個單位的方式來管理。 如果在資源群組起始了失效保護或切換保護移轉，則資源群組會被當作一個單位來移轉。

註解 -

當您將包含應用程式資源的資源群組啟動為線上時，即會啟動應用程式。數據服務啟動方法會等到應用程式啟動並執行之後，才順利結束。 判斷應用程式何時啟動與執行的方式，與數據服務錯誤監視器判斷數據服務是否仍在服務用戶端的方式相同。 請參照 Sun Cluster 3.0 Data Services Installation and Configuration Guide 以取得此處理程序的其他資訊。

資源和資源群組性質

您可以配置您的 Sun Cluster 數據服務的資源和資源群組之性質值。有一組標準的性質值是適用所有的數據服務，另外一組延伸性質是專為每一個數據服務。 部份標準和延伸性質是配置內定值，所以您不需要修改它們。其它性質則需要在建立和配置資源時設定。 每個數據服務的文件指定，資源類型使用哪些性質，以及應該如何加以配置。

標準性質是用來配置通常與任何特定數據服務無關的資源和資源群組性質。 Sun Cluster 3.0 Data Services Installation and Configuration Guide 的附錄中說明了這組標準性質。

延伸性質提供了諸如應用程式二進位檔案、配置檔和資源相依項目位置的資訊。您要依照數據服務的配置方式來修改性質。Sun Cluster 3.0 Data Services Installation and Configuration Guide 的個別數據服務章節說明了這組延伸性質。

公用網路管理 (PNM) 和網路配接卡失效保護 (NAFO)

用戶端透過公用網路來將要求送至叢集。每一個叢集節點透過公用網路配接卡至少連接到一個公用網路。

「Sun Cluster 公用網路管理 (PNM)」軟體提供監視公用網路配接卡、以及在偵測到失效時將 IP位址從某個配接卡移轉至另一個配接卡的基本機制。每一個叢集節點均擁有自己的 PNM 配置，這些配置可以和其它叢集節點上的 PNM 配置不同。

公用網路配接卡會組成 Network Adapter Failover groups (NAFO 群組)。 每一個 NAFO 群組均有一或多個公用網路配接卡。任何時候，針對指定的 NAFO 群組，只能一個配接卡為作用中，相同群組內的其它配接卡，則作為作用中配接卡上的 PNM 常駐程式偵測到錯誤而進行配接卡失效保護的備份配接卡。失效保護會令作用中配接卡相關的 IP 位址移到備份配接卡，因而保持了節點的公用網路連接性。因為失效保護是發生在配接卡介面層次，所以較高層次的連接 (如 TCP) 不受影響， 但是在失效保護期間的短暫延遲除外。

註解 -

因為 TCP 的壅塞回復特性，TCP 端點在失效保護成功之後可以承受更進一步的延遲，其中部份區段可能會在失效保護期間遺失，因而啟動 TCP 的壅塞控制機制。

NAFO 群組提供邏輯主機名稱和共用位址資源的建置區塊。如果有必要的話，scrgadm(1M) 指令會自動為您建立 NAFO 群組。您也可以另外建立邏輯主機名稱和共用位址資源的 NAFO 群組來 監視叢集節點的公用網路連接性。節點上的相同 NAFO 群組可以擁有任意數目的邏輯主機名稱或共用位址資源。 有關邏輯主機名稱和共用位址資源的其他資訊，請參閱 Sun Cluster 3.0 Data Services Installation and Configuration Guide。

註解 -

NAFO 機制的設計是為了偵測和遮罩配接卡失效。其設計目的不是為了回復管理者使用 ifconfig(1M) 移除其中一個邏輯 (或共用) IP 位址的情形。Sun Cluster 設計將 邏輯和共用 IP 位址視為受 RGM 管理的資源。管理者增加或移除 IP 位址的正確方式，是使用 scrgadm(1M) 來修改包含資源的資源群組。

PNM 錯誤偵測和失效保護處理程序

PNM 定期檢查作用中配接卡的封包計數器，假設正常配接卡的封包計數器將會 因為正常網路流量通過配接卡而變更。如果封包計數器經過一段時間後並沒有變更， PNM 會進入 ping 序列，以強制流量通過作用中配接卡。 PNM 會在每次的序列結束時檢查封包計數器是否有任何變更，如果在重複幾次 ping 序列動作之後 封包計數器仍然不變，則宣告配接卡故障。只要有一個備份配接卡可以使用，這些事件會觸發失效保護以備份配接卡。

PNM 會監視輸入和輸出封包計數器，所以當任一或兩者的計數器有一段時間沒有變更時， 即會起始 ping 序列。

ping 序列包含測試 ALL_ROUTER 廣播位址 (224.0.0.2)、ALL_HOST 廣播位址 (224.0.0.1) 和 區域子網路廣播位址。

Ping 的結構，是以花費最少為優先考量的方式，所以如果有一個花費較少的 ping 成功時，花費較多的 ping 就不會執行。此外，ping 只是作為在配接卡上產生流量的方法。其退出狀態不會 作為配接卡是否為可運作或故障的決策。

此演算法中有四個可調參數：inactive_time、ping_timeout、 repeat_test 和 slow_network。這些參數提供了錯誤偵測的速度和正確性之間的取捨選擇。請參照 Sun Cluster 3.0 系統管理手冊 中變更公用網路參數和變更方法的程序。

在 NAFO 群組的作用配接卡上偵測到錯誤之後，如果無法使用備份配接卡，群組會宣告為 「當機 (DOWN)」，而所有其備份配接卡的測試會持續。否則，如果有備份配接卡可以使用，失效保護 會發生至備份配接卡。當故障的作用配接卡被關閉和停用時，邏輯位址與其關聯的旗號會「轉移」至備份配接卡。

當 IP 位址失效保護順利完成時，會送出無償式 ARP 廣播，所以可維持與遠程用戶端的連接。