test

Sun Cluster 3.0 12/01 概念

叢集管理與應用程式設計

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

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

圖 3-1 Sun Cluster 軟體架構

Graphic

管理介面

您可以選擇要如何從不同的使用者介面來安裝、配置與管理 SunPlex 系統。 您可以透過具備說明的指令行介面來完成系統管理作業。 在指令行介面的上層，尚有一些可簡化配置作業的公用程式。 SunPlex 系統亦有一個模組，是當作 Sun Management Center 的一部分來執行，其提供 GUI 給某些叢集作業。 請參照 Sun Cluster 3.0 12/01 系統管理手冊 中的介紹章節，以取得管理介面的完整說明。

叢集時間

叢集中所有節點的時間均必須同步。 不論您是否將叢集節點與任何外在的時間來源同步化，對於叢集操作而言並不重要。 SunPlex 系統使用「網路時間通訊協定」(Network Time Protocol，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 12/01 軟體安裝手冊 一書中。

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

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

高可用性框架

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

下表顯示 SunPlex 元件故障的種類 (硬體和軟體)，以及內建於高可用性框架內的復原種類。

表 3-1 SunPlex 故障偵測與復原的層次

故障的叢集元件 

軟體復原 

硬體復原 

資料服務 

HA API, HA 框架 

N/A 

公用網路配接卡 

網路配接卡故障轉移 (NAFO) 

多重公用網路配接卡 

叢集檔案系統 

主要與次要複製 

多重主機磁碟 

鏡像的多重主機磁碟 

容體管理 (Solstice DiskSuite 和 VERITAS Volume Manager) 

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

整體裝置 

主要與次要複製 

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

私有網路 

HA 傳輸軟體 

多重私有硬體獨立網路 

節點 

CMM，failfast 驅動程式 

多重節點 

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

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

叢集成員監視器

「叢集成員監視器」(Cluster Membership Monitor，CMM) 是一組分散式的代理 代理程式透過叢集交互連接來交換訊息，以：

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

叢叢集成員

CMM 的主要功能是在任何指定的時間參與叢集的一組節點上，建立全叢集的協議。 此限制稱為叢集成員。

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

請參閱 "法定數目和法定裝置"，以取得有關叢集如何保護自己以免於分割成多個個別叢集的詳細資訊。

叢叢集成員監視器重新配置

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

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

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

Failfast 機制

如果 CCM 偵測到節點的嚴重問題，它會呼叫叢集框架強制關掉 (混亂的) 節點，並將其從叢集成員中移除。 發生此情況的機制稱為 failfast。Failfast 會導致節點以兩種方式關閉。

當由於叢集常駐程式掛掉而產生混亂時，類似下列訊息會顯示在該節點的主控台上。


panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
(由於「pmfd」在 35 秒之前掛掉而中斷。)
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7:1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

混亂過後，節點可能重新啟動並嘗試重新連接叢集，或停留於 OpenBoot PROM (OBP) 提示處。 所採取的行動取決於 OBP 中 auto-boot? 參數的設定。

叢集配置儲存庫(Cluster Configuration Repository，CCR)

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

OCR 使用兩階段確定演算法作為更新之用：更新必須在所有叢集成員上成功完成，否則更新會轉返。 CCR 使用叢集交互連接來套用分散式更新。

小心 - 小心 -

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

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

整體裝置

SunPlex 系統使用整體裝置來提供全叢集、高可用性存取叢集中的任何裝置 (從任意節點)，不管裝置是否為實體連接。一般而言，如果節點是在提供整體裝置的存取時故障，Sun Cluster 軟體會自動探尋該裝置的其它路徑並將存取重新導向後的路徑。SunPlex 整體裝置包括磁碟、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。 請參閱相關的線上援助頁，以取得詳細資訊。

磁碟裝置群組

在 SunPlex 系統中，所有的多主機磁碟必須受 Sun Cluster 軟體的控制。 首先，您要在多主機磁碟上建立容體管理者磁碟群組，如 VERITAS Volume Manager 磁碟組，或是 - 磁碟群組。 然後，將容體管理者磁碟群組註冊為碟機裝置群組。 磁碟裝置群組是一種整體裝置類型。 此外，Sun Cluster 軟體自動為叢集中的每個磁碟和磁帶裝置建立原始的磁碟裝置群組。然而，這些叢集裝置群組會在您把它們當作整體裝置來存取之前，一直維持離線的狀態。

註冊提供 SunPlex 系統資訊，是有關何種節點具有指向哪個容體管理者磁碟群組的路徑。 在此，容體管理者磁碟群組會變成可由叢集內做全域存取。 如果一個以上的節點可以寫至 (主控) 磁碟裝置群組，儲存在此磁碟裝置群組上的資料就變得高度可用了。 高度可用的磁碟裝置群組可用來包含磁碟檔案系統。

註解 -

磁碟裝置群組與資源群組無關。 某個節點可以主控一個資源群組 (代表一群資料服務處理程序)，而另外一個節點則可以主控資料服務所存取的磁碟群組。 然而，最佳的方式是將儲存特定應用程式之資料的磁碟裝置群組，以及包含應用程式之資源 (應用程式常駐程式) 的資源群組保存在同一節點上。 請參照 Sun Cluster 3.0 12/01 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 或容體均含一個裝置節點。

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

全域名稱空間的優點包括：

本機和全域名稱空間範例

下表顯示多主機磁碟 (c0t0d0s0) 的本機和全域名稱空間之間的對應，。

表 3-2 本機和全域名稱空間對應

元件/路徑 

本機節點名稱空間 

全域名稱空間 

Solaris logical name (Solaris 邏輯名稱) 

/dev/dsk/c0t0d0s0

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

DID name (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 Volume Manager 

/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) 來存取叢集檔案系統中的檔案。

叢集檔案系統會裝載於所有叢集成員上。 您不能將叢集檔案系統裝載於叢集成員的子集上。

叢集檔案系統並非不同的檔案系統類型。 亦即，用戶端可以看見基礎檔案系統 (例如，UFS)。

使用叢集檔案系統

在 VERITAS Volume Manager 中，所有的多主機磁碟均配置為磁碟裝置群組，可以是SunPlex 磁碟組、Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide 磁碟群組，或是不受軟體式容體管理者控制的個別磁碟。 要使叢集檔案系統為高度可用，基礎的磁碟儲存體必須連結一個以上的節點。 因此，納入叢集檔案系統中的本機檔案系統 (儲存在節點本機磁碟上的檔案系統) 就不是高度可用了。

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

註解 -

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

叢集檔案系統的功能

叢集檔案系統具備下述功能：

Syncdir 裝載選項

syncdir 裝載選項可用於將 UFS 作為基礎檔案系統的叢集檔案系統。 syncdir然而，如果您不指定 syncdir，效能就會明顯改善。 如果您指定 syncdir，此項寫入便保證相容於 POSIX。 如果沒有指定，您所看到的功能，將會與 UFS 檔案系統相同。 例如，在某些情況下，沒有 syncdir，一直到關閉檔案為止，您才會發覺出空間不足的狀況。 利用 syncdir (和 POSIX 行為)，便可在寫入作業期間察覺空間不足的狀況。 由於您未指定 syncdir 就會有問題的情況極少發生，因此我們建議您不要指定，並可享有效能上的優勢。

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

法定數目和法定裝置

由於叢集節點共用資料與資源，因此很重要的一點是，叢集不可分成個別的且同時作用中的分割區。 CMM 保證即使叢集交互連結已做了分割，在任何時刻只會有一個叢集在運作。

來自磁碟分割區的問題有兩種： split brain 和 amnesia。Split Brain 發生於節點之間的叢集交互連接遺失，以及叢集分割為子叢集時，每個子叢集都相信自己是唯一的分割區 這是叢集節點間的通訊問題所致。 Amnesia 發生的時間是，在關機後叢集重新啟動，其中叢集資料比關機時還要舊。 這會發生在有多重版本的框架資料儲存於磁碟上，而且新型的叢集又在無最新版本的時候啟動之時。

藉由給每個節點一票，並強制給予運作中的叢集多數票，便得以避免 Split Brain 與 Amnesia 的狀況發生。 有多數票的分割區具有法定數目，並且是允許運作的。 此多數投票機制只要在叢集中有二個以上的節點時，就會運作得極好。 在兩個節點的叢集中，票數為兩票。 如果這樣的叢集被分割了，就需要進行外部投票以使其分割區取得法定數目。 此外部投票乃由法定裝置所提供。法定裝置可以是任何在兩節點之間共用的磁碟。 用作法定裝置的磁碟可含有使用者資料。

表 3-3 說明 Sun Cluster 軟體如何使用法定數目來避免 Split Brain 與 Amnesia 的發生。

表 3-3 叢集法定數目以及 Split-Brain 與 Amnesia 問題

分割區類型 

法定數目解決方案 

Split Brain 

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

Amnesia 

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

法定數目演算法是動態運作：當叢集事件觸發計算時，計算結果是可以變更叢集的生命週期。

法定票數

叢集節點與法定裝置會投票以形成法定數目。 依預設，當叢集節點啟動和成為叢集成員時，叢集節點會獲得一票的法定票數。 節點也可能會是零票，例如，當安裝節點或管理者將節點置於維護狀態時。

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

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

註解 -

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

法定數目配置

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

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

Graphic

法定數目準則

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

提示 -

為了保護個別法定裝置免於故障，請在各組節點間配置不只一個法定裝置。 使用來自不同機殼的磁碟，以及在每組節點之間配置奇數的法定裝置。

故障隔離

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

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

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

SunPlex 系統使用 SCSI 磁碟保留來實作故障隔離。 使用 SCSI 保留，故障的節點會"隔離"多主機磁碟，以防止存取這些磁碟。

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

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

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

用於故障隔離離之 Failfast 機制

叢集框架用來確保故障的節點無法重新啟動，並開始寫入至共用儲存體的機制稱為 failfast。

叢集成員的節點對於它們有存取權的磁碟，包括法定數目的磁碟，會連續啟用特定的 ioctl，也就是 MHIOCENFAILFAST。 此 ioctl 為磁碟驅動式的指示詞，會讓節點在無法存取已被保留為其它節點之用的磁碟時，有能力自我混亂。

MHIOCENFAILFAST ioctl 會使驅動程式檢查 Reservation_Conflict 錯誤碼讀寫至磁碟所傳回的錯誤。ioctl 會在背景中定期地對磁碟發出測試作業，以檢查Reservation_Conflict。 如果傳回 Reservation_Conflict 時，前景與背景的控制流路徑都會混亂。

對於 SCSI-2 磁碟而言，保留並不持久，它們並不能在節點重新啟動時存活。 對於具有 Persistent Group Reservation (PGR) 的 SCSI-3 磁碟而言，保留資訊是儲存在磁碟上，並且在節點重新啟動後仍會保留。 不管您是否有 SCSI-2 磁碟或 SCSI-3 磁碟，failfast 機制的運作都一樣。

如果節點在叢集中失去與其它節點的連接，並且也不是可達法定容量的分割區，它會被其它節點強制從叢集中移除。 另一可達法定容量之分割區部分的節點，在共用磁碟上放置了保留，且當沒有法定容量的節點嘗試存取共用磁碟時，它會收到保留衝突並且由於 failfast 機制而混亂。

混亂過後，節點可能重新啟動並嘗試重新連接叢集，或停留於 OpenBoot PROM (OBP) 提示處。 所採取的行動取決於 auto-boot? 的設定。OBP 中的參數。

容體管理者

SunPlex 系統使用容體管理軟體，藉由鏡映和緊急備件磁碟來增加資料的可用性，以及處理磁碟的故障和更換。

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

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

當容體管理物件為叢集所控制時，它們就成為磁碟裝置群組。 有關容體管理者的資訊，請參閱您的容體管理者軟體文件。

註解 -

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

資料服務

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

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

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

Graphic

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

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

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

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

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

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

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

Graphic

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

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

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

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

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

Graphic

資料服務方法

此 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 故障轉移和可延伸資源群組範例

Graphic

可延伸服務的架構

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

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

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

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

Graphic

沒有放置整體介面的節點 (代理節點) 將共用位址放在其回送介面上。 進入整體介面的封包會根據配置的平衡資料流量策略，來分送至其它叢集節點。 可能的平衡資料流量策略說明如後。

平衡資料流量策略

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

可延伸資料服務的類別有兩種： 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 策略，依預設都會使用加權平衡資料流量策略，因此用戶端的起始要求會被導向平衡資料流量程式所指定的實例。 在用戶端建立與執行實例之節點的關係之後，只要該節點是可存取的，且平衡資料流量策略未變更，則後續的要求會被導向該實例。

特定平衡資料流量策略的其它詳細資訊如下。

故障回復設定

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

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

資料服務錯誤監視器

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

發展新的資料服務

Sun 提供配置檔案與管理方法範本，讓您得以使各種應用程式在叢集中以故障轉移或可延伸的服務來運作。 如果您要當作故障轉移或可延伸服務來執行的應用程式，目前不是由 Sun 所提供，您可以使用 API 或 DSDL API，將您的應用程式配置成為故障轉移或可延伸的服務。

有一套準則可用來斷定應用程式是否可成為故障轉移服務。 特定的基準規則在 SunPlex 文件中有所說明，其中說明了可用於您的應用程式的 API。

在此，我們提供一些準則來協助您瞭解，您的服務是否可以利用可延伸資料服務架構。 請參閱 "可延伸的資料服務" 一節，以取得有關可延伸服務的一般資訊。

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

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

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

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

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

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

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

資料服務 API 與資料服務檔案庫 API

SunPlex 系統提供下列項目，可以使應用程式具備高可用性：

Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide 說明如何安裝和配置 SunPlex 系統提供的資料服務。 Sun Cluster 3.0 12/01 Data Services Developer's Guide 說明如何導入其它應用程式，以便在 Sun Cluster 框架下具備高可用性。

這些 Sun Cluster API 讓應用程式設計師能發展啟動及停止資料服務實例的錯誤監視器及程序檔。利用這些工具，應用程式可以變成具備故障轉移和可延伸資料服務。 此外， 系統可提供 一般 資料服務，可用來快速產生應用程式需要的啟動和停止方法，使其作為高可用性資料服務來執行。

使用資料服務通訊的叢集交互連接

叢集在節點之間必須具備多網路連接，以形成叢集交互連接。 叢集軟體可使用多重交互連接來達到高可用性以及增進效能。 對於內部通訊 (例如，檔案系統資料或可延伸服務資料)，訊息是以輪流的方式分送到所有可用的交互連接。

叢集交互連接也可以用於應用程式，以便在節點之間建立高可用性通訊。 例如，分散式應用程式可能會有元件在多個需要通訊的節點上執行。 如果使用叢集交互連接而不是公用傳輸，可以防制個別連結的故障。

要在節點之間使用叢集交互連接進行通訊，應用程式必須使用安裝叢集時配置的專用主機名稱。 例如，如果節點 1 的專用主機名稱是 clusternode1-priv，請使用該名稱當作節點 1 的叢集交互連接的通訊。

使用這個名稱開啟的 TCP 插槽可在叢集交互連接中被傳遞 (route)，如果網路故障還可以再被傳遞。 請注意，由於專用主機名稱可以在安裝時配置，因此叢集交互連接可使用當時選取的任何名稱。 而實際名稱可從 scha_cluster_get(3HA)，使用 scha_privatelink_hostname_node 引數來取得。

在應用程式層次使用叢集交互連接時，每一對節點之間使用單一的交互連接，但若可能的話，不同的節點配對之間應使用個別的交互連接。 例如，考慮到有應用程式在三個節點上執行，而且透過叢集交互連接來進行通訊的狀況。 節點 1 與 2 之間的通訊可能透過 hme0 介面，節點 1 與 3 之間的通訊則可能透過介面 qfe1。 也就是說，任意二個節點之間的應用程式通訊將限制於單一交互連接，內部叢集通訊則散置在所有的交互連接。

請注意，應用程式和內部叢集通訊共用交互連接，因此應用程式可用的頻寬是由其它叢集通訊所使用的頻寬來決定。 在發生故障時，內部通訊可以在其餘交互連接中循環 (round robin)，而在故障的交互連接上的應用式也可以切換到運作的交互連接。

有兩種類型的位址支援叢集交互連接，而 gethostbyname(3N) 上的專用主機名稱通常會傳回兩個 IP 位址。第一個位址稱為邏輯 pairwise 位址，第二個位址稱為邏輯 pernode 位址。

每一對節點會被指派個別的邏輯 pairwise 位址。 這個小型邏輯網路支援連接的故障轉移。 每一個節點還會被指派一個固定的 pernode 位址。 也就是說，每一個節點上的 clusternode1 priv 的邏輯 pairwise 位址都不一樣，而每一個節點上的 clusternode1 priv 的邏輯 pernode 位址則都相同。節點本身沒有 pairwise 位址，，因此節點 1 上的 gethostbyname (clusternode1 priv) 將只傳回邏輯 pernode 位址。

請注意，接受透過叢集交互連接之通訊，並依安全理由而驗證 IP 位址的應用程式，必須針對 gethostbyname 傳回的所有 IP 位址進行檢查，而不只是針對第一個 IP 位址。

如果您要求應用程式在各個點都是一致的 IP 位址，請將應用程式配置為在用戶端以及伺服器都是連結到 pernode 位址，這樣所有的連接看起來都會是透過 pernode 位址往來。

資源與資源類型

資料服務利用了數種類型的資源。 應用程式諸如 Apache Web Server 或 iPlanet Web Server 使用應用程式所賴以運作的網路位址 (邏輯主機名稱及共用位址)。應用程式和網路資源形成受 RGM 管理的基本單位。

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

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

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

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

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

註解 -

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

資源及資源群組狀態與設定值

管理者將靜態設定值套用到資源與資源群組中。 這些設定值只可經由管理動作來變更。

資源和資源群組屬性

您可以配置您的 SunPlex 資料服務的資源和資源群組之屬性值。 標準屬性常見於所有資料服務中。 延伸屬性則特定於個別的資料服務。 部份標準和延伸屬性是以預設值配置的，所以您不需要修改它們。 其它屬性則需要在建立和配置資源時加以設定。 各資料服務的文件會指定可設定哪些資源屬性，及設定的方式。

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

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

公用網路管理 (PNM) 和網路配接卡故障轉移 (NAFO)

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

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

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

註解 -

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

NAFO 群組提供邏輯主機名稱和共用位址資源的建置區塊。 如果有必要的話，scrgadm(1M) 指令會自動為您建立 NAFO 群組。 您也可以另外建立邏輯主機名稱和共用位址資源的 NAFO 群組，來監視叢集節點的公用網路連接性。 節點上的相同 NAFO 群組可以擁有任意數目的邏輯主機名稱或共用位址資源。有關邏輯主機名稱和共用位址資源的詳細資訊，請參閱 Sun Cluster 3.0 12/01 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 12/01 系統管理手冊 中變更公用網路參數和變更方法的程序。

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

當成功完成 IP 位址的故障轉移時，就會送出無償的 (gratuitous) ARP 廣播。 也就維持了與遠端用戶端的連接。

動態重新配置支援

Sun Cluster 3.0 支援動態重新配置 (DR) 軟體功能正積極發展當中。本節說明有關 Sun Cluster 3.0 12/01 對 DR 功能支援的概念和考量。

請注意，所有關於 Solaris 8 DR 功能的要求、程序和限制的文件說明亦適用於 Sun Cluster DR 支援 (但作業環境靜態作業除外)。 因此，在使用 Sun Cluster 軟體的 DR 功能之前，請查看 Solaris 8 DR 功能的說明文件。 尤其您應該查看有關 DR 中斷作業期間對非網路 IO 裝置影響的議題。 Sun Enterprise 10000 Dynamic Reconfiguration User Guide 和 Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual (從 Solaris 8 on Sun Hardware 系列) 均可從 http://docs.sun.com 下載。

動態重新配置一般說明

DR 功能所允許的作業諸如在系統執行中移除系統硬體。 DR 程序的設計是為確保系統持續作業，而無需停止系統的作業或中斷叢集的可用性。

DR 的作業是在主機板的層次。因此，DR 作業影響主機板上的所有元件。每個主機板可以包含多個元件，包括 CPU、記憶體以及磁碟機、磁帶機和網路連接的周邊介面。

移除主機板會讓系統無法使用主機板上的任何一個元件。 在移除主機板之前，DR 子系統會決定是否要使用主機板上的元件。若移除使用中的裝置會導致系統發生錯誤。 如果 DR 子系統發覺有裝置在使用中，就會拒絕 DR 的移除主機板作業。因此，可放心發出 DR 移除主機板作業。

DR 新增主機板作業也可放心進行。 新增到主機板上的 CPU 和記憶體會自動被系統帶入進行服務。然而，系統管理員必須手動配置叢集，如此才能積極使用新增到主機板上的其它元件。

註解 -

DR 子系統有數個層級。如果較低的層級報告有錯誤，較高階的層級也會報告錯誤。

然而，當較低層級報告特定錯誤時，較高的層級只會報告"不明錯誤。"系統管理員可不用理會較高層級所報告的"不明錯誤"。下節說明 DR 對於不同裝置類型的考量。

DR 對 CPU 裝置的叢集考量

當 DR 移除主機板作業影響到主機板上的 CPU 時，DR 子系統會允許該項作業並自動讓節點停止使用這些受影響的 CPU。

當 DR 新增主機板作業影響到主機板上的 CPU 時，DR 子系統會自動讓節點停止使用這些受影響的 CPU。

DR 對記憶體的叢集考量

針對 DR的目的，有兩種類型的記憶體要加以考量。這兩種類型僅在用途上有所不同。實際的硬體則並無差別。

一種是由作業系統所使用的記憶體，稱為核心記憶卡 (kernel memory cage)。Sun Cluster 軟體並不支援在包含有核心記憶卡的主機板上進行移除機板作業，並且會拒絕這樣的作業。當 DR 移除主機板作業影響記憶體，而非核心記憶卡時，DR 子系統會允許該項作業並自動讓節點停止使用這些受影響的記憶體。

當 DR 新增主機板作業影響記憶體時，DR 子系統會自動讓節點開始使用新的記憶體。

DR 對磁碟和磁帶機的叢集考量

DR 移除作業在主要節點中的作用中裝置上是不被允許的。DR 移除作業只能夠在主要節點中的非作用中裝置上以及次要節點的裝置上進行。 不論在 DR 作業之前或之後，均可持續存取叢集資料。

註解 -

會影響法定裝置可用性的 DR 作業是不被允許的。有關法定裝置執行 DR 作業的考量和程序，請參閱 "DR 對法定裝置的叢集考量"。

下述步驟簡述在磁碟或磁帶機上執行 DR 移除作業的程序。請參閱 Sun Cluster 3.0 U1 System Administration Guide，以取得有關執行這些動作的詳細指示。

  1. 判斷磁碟或磁帶機是否為作用中裝置群組的一部分。

    • 如果該裝置並非作用中裝置群組的一部分，便可在其上執行 DR 移除作業。

    • 如果 DR 移除主機板作業會影響作用中磁碟或磁帶機，系統就會拒絕該項作業並辨識出會受該項作業影響的裝置。 如果裝置是作用中裝置群組的一部分，請參閱 步驟 2。

  2. 判斷裝置是否為主要節點或次要節點的一個元件。

    • 如果裝置是次要節點的一個元件，便可在其上執行 DR 移除作業。

    • 如果裝置是主要節點的一個元件，您就必須在該裝置上執行 DR 移除作業之前，切換主要節點為次要節點。

小心 - 小心 -

如果您在次要節點上執行 DR 作業時目前的主要節點故障，則叢集的可用性會受到影響。因為主要節點沒有地方可供進行故障轉移，除非提供新的次要節點。

DR 對法定裝置的叢集考量

DR 移除作業無法在目前被配置為法定裝置的裝置上執行。如果 DR 移除主機板作業會影響法定裝置，則系統會拒絕該項作業並辨識出會受該項作業影響的法定裝置。 您必須停止將該裝置做為法定裝置，才能夠在該裝置上執行 DR 移除作業。

下述步驟簡述在法定裝置上執行 DR 移除作業的程序。請參閱 Sun Cluster 3.0 U1 System Administration Guide，以取得有關執行這些動作的詳細指示。

  1. 啟用一個您沒有在上面執行 DR 作業的裝置作為法定裝置。

  2. 停用使用您在上面執行 DR 作業的裝置做為法定裝置。

  3. 在裝置上執行 DR 移除作業。

DR 對專用交互連接介面的叢集考量

DR 作業無法在作用中的專用交互連接介面上執行。 如果 DR 移除主機板作業會影響作用中專用交互連接介面，則系統會拒絕該項作業並辨識出會受該項作業影響的介面。在您移除之前必須先停用該作用中的介面 (亦請參閱下述警告)。當介面被置換成為專用交互連接時，它的狀態仍然不變，所以請避免額外的 Sun Cluster 重新配置步驟。

下述步驟簡述在專用交互連接介面上執行 DR 移除作業的程序。請參閱 Sun Cluster 3.0 U1 System Administration Guide，以取得有關執行這些動作的詳細指示。

小心 - 小心 -

Sun Cluster 需要叢集節點至少有一條作業路徑通往每一個其它叢集節點。請勿停用支援通往任何叢集節點最後一條路徑的專用交互連接介面。

  1. 停用您正在其交互連接介面上執行 DR 作業的傳輸電纜。

  2. 在實體的專用交互連接介面上執行 DR 移除作業。

DR 對公用網路介面的叢集考量

DR 移除作業可以在非作用中的公用網路介面上執行。 如果 DR 移除主機板作業會影響作用中公用網路介面，則系統會拒絕該項作業並辨識出會受該項作業影響的介面。 任何一個作用中公用網路介面，首先必須從網路配接卡故障轉移 (NAFO) 群組中的作用中配接卡實例狀態移除。

小心 - 小心 -

如果您在停用的網路配接卡上執行 DR 移除作業時，作用中的網路配接卡故障，則可用性會受到影響。因為作用中的配接卡在 DR 作業期間沒有地方可供其進行故障轉移。

下述步驟簡述在公用網路介面上執行 DR 移除作業的程序。 請參閱 Sun Cluster 3.0 U1 System Administration Guide，以取得有關執行這些動作的詳細指示。

  1. 將作用中配接卡切換為備用的配接卡，如此才能將其從 NAFO 群組中移除。

  2. 從 NAFO 群組移除配接卡。

  3. 在公用網路介面上執行 DR 作業。