test

Sun Cluster 概念指南 (適用於 Solaris 作業系統)

叢集管理和應用程式開發

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

管理介面

您可以選擇從數個使用者介面安裝、配置和管理 SunPlex 系統的方式。 您可以透過 SunPlex Manager 圖形使用者介面 (GUI) 或透過歸檔指令行介面來完成系統管理作業。 在指令行介面的頂端是一些公用程式 (例如 scinstall 與 scsetup)，可簡化所選安裝與配置作業。 SunPlex 系統也有一個模組，它作為 Sun Management Center 的一部分來執行，為特定叢集作業提供 GUI。 此模組僅可在基於 SPARC 的叢集中使用。 請參閱 Sun Cluster 系統管理指南 中的介紹章節，以取得管理介面的完整說明。

叢集時間

叢集中所有節點的時間均必須同步。 是否使叢集節點與任何外部時間來源同步，對於叢集作業並不重要。 SunPlex 系統使用「網路時間通訊協定 (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 軟體安裝指南。

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

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

高可用性框架

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

下表顯示了 SunPlex 元件故障 (硬體故障與軟體故障) 的種類，以及建立在高可用性框架中的恢復種類。

表 3–1 SunPlex 故障偵測與恢復的層次

故障的叢集元件 

軟體恢復 

硬體恢復  

資料服務  

HA API、HA 框架  

N/A 

公用網路配接卡 

IP Network Multipathing 

多重公用網路配接卡  

叢集檔案系統 

主要與次要複製 

多重主機磁碟 

鏡像的多重主機磁碟  

容體管理 (Solaris Volume Manager 與 VERITAS Volume Manager，後者僅可在基於 SPARC 的叢集中使用) 

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

整體裝置 

主要與次要複製 

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

私有網路 

HA 傳輸軟體  

多重私有硬體獨立網路 

節點 

CMM，failfast 驅動程式 

多重節點 

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

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

叢集成員身份監視器

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

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

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

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

請參閱法定數目與法定裝置，以取得有關叢集如何保護自身不被分割為多個獨立叢集的詳細資訊。

Failfast 機制

如果 CMM 偵測到某節點發生緊急問題，則它會呼叫叢集框架以強制關閉 (當機) 節點，然後從叢集成員身份中移除該節點。 發生此情況的機制稱為 failfast。 Failfast 會導致節點以兩種方式關閉。

當叢集常駐程式的失效導致節點當機時，在該節點的主控台上會顯示類似下列內容的訊息。 


panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
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

在當機之後，該節點可能重新啟動並嘗試重新連結叢集，或者停留在 OpenBootTM PROM (OBP) 提示符號處 (如果叢集由基於 SPARC 的系統組成)。 採用的動作由 auto-boot? 參數的設定所決定。 您可以在 OpenBoot PROM ok 提示符號處，使用 eeprom(1M) 來設定 auto-boot?。

叢集配置儲存庫 (CCR)

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

Caution – Caution –

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

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

整體裝置

SunPlex 系統使用整體裝置來提供全叢集、高可用性存取叢集中任何裝置 (從任意節點)，不管裝置實體連接的位置。 一般而言，如果節點是在提供整體裝置的存取時發生故障，Sun Cluster 軟體會自動探尋該裝置的其他路徑，並將存取重新導向到此路徑。 SunPlex 整體裝置包含磁碟、CD-ROM 與磁帶。 然而，磁碟是唯一支援多埠的整體裝置。 這代表 CD-ROM 和磁帶裝置目前不是高可用性裝置。 每部伺服器上的本機磁碟亦不是多埠式，因此不是高可用性裝置。

叢集可以自動為叢集中的各磁碟、CD-ROM 和磁帶裝置指定唯一的 ID。 這項指定可以讓人從叢集的任何節點一致存取各個裝置。 整體裝置名稱空間是保存於 /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 軟體的控制。 您首先要在多重主機磁碟上建立容體管理程式磁碟群組 — Solaris Volume Manager 磁碟組或者 VERITAS Volume Manager 磁碟群組 (僅在基於 SPARC 的叢集中可用)。 然後，將容體管理程式磁碟群組註冊為磁碟裝置群組。 磁碟裝置群組是一種整體裝置類型。 此外，Sun Cluster 軟體自動為叢集中的每個磁碟和磁帶裝置建立原始的磁碟裝置群組。 不過這些叢集裝置群組仍會維持離線狀態，除非您以整體裝置來存取它們。

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

註解 –

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

使用磁碟裝置群組，容體管理程式磁碟群組將成為「整體」群組，因為它提供對基礎磁碟的多重路徑支援。 實體連接到多重主機磁碟的每一個叢集節點，均提供了一個磁碟裝置群組的路徑。

磁碟裝置群組故障轉移

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

圖 3–1 磁碟裝置群組故障轉移

圖例： 前述上下文說明圖形。

多埠式磁碟裝置群組

本節說明了可讓您平衡多埠式磁碟配置中的效能與可用性的磁碟裝置群組屬性。 Sun Cluster 軟體提供了用來配置多埠式磁碟配置的兩個屬性︰ preferenced 與 numsecondaries。 您可以使用 preferenced 屬性來控制當發生故障轉移時節點嘗試採用控制的順序。 使用 numsecondaries 屬性，可為裝置群組設定所需數目的次要節點。

若主要節點當機，並且沒有合格的次要節點可以提昇為主要節點，則高度可用的服務將被視為失效。 如果發生服務故障轉移，並且 preferenced 屬性為 true，則節點將按照節點清單中的順序選取一個次要節點。 設定的節點清單定義了節點將嘗試採用主要控制的順序或採用從備用節點至次要節點之轉換的順序。 您可以使用 scsetup(1M) 公用程式動態變更裝置服務的個人喜好。 與獨立服務提供者關聯的個人喜好 (如全域檔案系統)，將成為裝置服務的個人喜好。

在正常作業期間，次要節點是主要節點的核對點。 在多埠式磁碟配置中，對每個次要節點進行核對點作業將導致叢集效能降低和記憶體的耗用。 已執行備用節點支援，以最小化由核對點作業導致的效能降低程度和記憶體耗用。 依預設，磁碟裝置群組將具備一個主要節點和一個次要節點。 其餘可用的提供者節點將以備用狀態在線上提供。 如果發生故障轉移，次要節點將成為主要節點，節點清單中優先權最高的節點將成為次要節點。

需要的次要節點數目，可以設定為介於一與裝置群組中作業非主要提供者節點數目之間的任何整數。

註解 –

如果您使用的是 Solaris 容體管理程式，必須先建立磁碟裝置群組，然後才可以將 numsecondaries 屬性設定為非預設值的數目。

預設的所需裝置服務次要節點數目為 1。 複製框架保留的次要提供者實際數目為需要的數目，除非作業非主要提供者的數目少於需要的數目。 如果您要在配置中新增或移除節點，需要更改 numsecondaries 屬性並仔細檢查節點清單。 保留節點清單以及需要的次要節點數目將防止已配置次要節點數目與框架允許的實際數目之間發生衝突。將 metaset(1M) 指令用於 Solaris Volume Manager 裝置群組，如果您使用 Veritas Volume Manager，則將 scconf(1M) 指令用於 VxVM 磁碟裝置群組，並配合使用 preferenced 與 numsecondaries 屬性設定，管理在配置中加入和移除節點。 請參閱Sun Cluster 系統管理指南 (適用於 Solaris 作業系統)中的「管理叢集檔案系統概觀」，以取得有關變更磁碟裝置群組屬性的程序資訊。

全域名稱空間

啟用整體裝置的 Sun Cluster 軟體機制稱為全域名稱空間。 全域名稱空間包括 /dev/global/ 階層以及容體管理程式名稱空間。 全域名稱空間反映多重主機磁碟和本機磁碟 (以及任何其他的叢集裝置，如 CD‐ROM 和磁帶)，並提供多重主機磁碟的多重故障轉移路徑。 實際連接多重主機磁碟的每一個節點，均提供一條儲存體路徑給叢集中的任何節點。

通常，對於 Solaris Volume Manager 而言，容體管理程式名稱空間位於 /dev/md/diskset/dsk (與 rdsk) 目錄中。 對於 Veritas VxVM 而言，容體管理程式名稱空間位於 /dev/vx/dsk/disk-group 與 /dev/vx/rdsk/disk-group 目錄中。 這些名稱空間由各自在整個叢集匯入的每個 Solaris Volume Manager 磁碟組和每個 VxVM 磁碟群組之目錄組成。 每個目錄對該磁碟組或磁碟群組中的每個 metadevice 或容體均含一個裝置節點。

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

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

本機和全域名稱空間範例

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

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

元件/路徑  

本機節點名稱空間  

全域名稱空間 

Solaris logical name (Solaris 邏輯名稱) 

/dev/dsk/c0t0d0s0

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

DID name (DID 名稱)  

/dev/did/dsk/d0s0

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

Solaris Volume Manager 

/dev/md/diskset/dsk/d0

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

SPARC: VERITAS Volume Manager 

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

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

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

叢集檔案系統

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

您可以藉由全域的 mount -g 或藉由本機的 mount 在整體裝置上裝載檔案系統。

程式可以透過相同的檔案名稱 (例如，/global/foo)，從叢集中的任何節點來存取叢集檔案系統中的檔案。

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

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

使用叢集檔案系統

在 SunPlex 系統中，所有多重主機磁碟均置於磁碟裝置群組中，群組可以為 Solaris Volume Manager 磁碟組、VxVM 磁碟群組或不受基於軟體的容體管理程式所控制的個別磁碟。

要使叢集檔案系統為高度可用，基礎的磁碟儲存體必須連結一個以上的節點。 因此，成為叢集檔案系統的本機檔案系統 (即儲存於節點本機磁碟上的檔案系統) 並不具有高度可用性。

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

註解 –

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

HAStoragePlus 資源類型

HAStoragePlus 資源類型的設計是要讓非全域的檔案系統配置 (例如 UFS 及 VxFS) 具有高度可用性。 使用 HAStoragePlus 即可將您的本機檔案系統整合到 Sun Cluster 環境中，並讓檔案系統具有高度可用性。 HAStoragePlus 提供額外的檔案系統功能 (如檢查、裝載以及強制卸載)，可讓 Sun Cluster 在本機檔案系統上進行故障轉移。 本機檔案系統必須位於已啟動切換保護移轉的全域磁碟群組中，才能進行故障轉移。

請參閱「Data Services Installation and Configuration Guide」中的個別資料服務章節，或第 14 章「Administering Data Services Resources」中的「Enabling Highly Available Local File Systems」，以取得有關如何使用 HAStoragePlus 資源類型的資訊。

HAStoragePlus 也可用於同步化資源與其依賴的磁碟裝置群組的啟動。 如需詳細資訊，請參閱資源、資源群組與資源類型。

Syncdir 裝載選項

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

如果您使用的是基於 SPARC 的叢集，則 Veritas VxFS 不具有同 UFS 的 syncdir 裝載選項對等的裝載選項。 未指定 syncdir 裝載選項時，VxFS 的行為會與 UFS 的行為相同。

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

磁碟路徑監視

目前版次的 Sun Cluster 軟體支援磁碟路徑監視 (DPM)。 本節提供了有關 DPM、DPM 常駐程式的概念資訊，以及用於監視磁碟路徑的管理工具。 請參閱Sun Cluster 系統管理指南 (適用於 Solaris 作業系統)，以取得有關如何監視、取消監視和檢查磁碟路徑狀態的程序資訊。

註解 –

在執行 Sun Cluster 3.1 4/04 軟體 之前發行的舊版本的節點上不支援 DPM。 當進行滾動升級時，請勿使用 DPM 指令。 在升級了所有節點後，節點必須在線上才能使用 DPM 指令。

概述

DPM 可以透過監視次要磁碟路徑的可用性，來提昇故障轉移和切換保護移轉的整體可信賴性。 使用 scdpm 指令來驗證某個資源在切換之前所使用的磁碟路徑之可用性。 藉由 scdpm 指令提供的選項，可讓您監視叢集中單一節點或所有節點的磁碟路徑。 請參閱 scdpm( 1M) 線上援助頁，以取得有關指令行選項的詳細資訊。

DPM 元件是從 SUNWscu 套件安裝的。 SUNWscu 套件是依照標準 Sun Cluster 安裝程序安裝的。 請參閱 scinstall (1M) 線上援助頁，以取得安裝介面詳細資訊。 下表說明了 DPM 元件的預設安裝位置。

位置 

元件 

常駐程式 

/usr/cluster/lib/sc/scdpmd

指令行介面 

/usr/cluster/bin/scdpm

共用檔案庫 

/user/cluster/lib/libscdpm.so

常駐程式狀態檔 (在執行期間建立) 

/var/run/cluster/scdpm.status

多重執行緒 DPM 常駐程式在每個節點上執行。 當節點啟動時，DPM 常駐程式 (scdpmd) 將由 rc.d 程序檔啟動。 如果出現問題，則此常駐程式將由 pmfd 管理並自動重新啟動。 下列清單說明初始啟動時 scdpmd 的工作方式。

註解 –

在啟動時，每個磁碟路徑的狀態都將初始化為 UNKNOWN。

  1. DPM 常駐程式可從上一個狀態檔或 CCR 資料庫中收集磁碟路徑與節點名稱資訊。 請參閱叢集配置儲存庫 (CCR)，以取得關於 CCR 的詳細資訊。 啟動 DPM 常駐程式之後，可以強制此常駐程式從指定的檔案名稱讀取受監視磁碟的清單。

  2. DPM 常駐程式可初始化通訊介面 (如指令行介面)，以回應來自此常駐程式外部元件的要求。

  3. DPM 常駐程式可使用 scsi_inquiry 指令，每隔 10 分鐘在受監視的清單中偵測每個磁碟路徑。 將鎖定每個項目，以防止通訊介面存取被修改項目的內容。

  4. DPM 常駐程式可通知 Sun Cluster 事件框架，並透過 UNIX syslogd(1M) 機制來記錄路徑的新狀態。

註解 –

關於此常駐程式的所有錯誤均由 pmfd (1M) 報告。 API 的所有功能均傳回 0 表示成功，傳回 -1 表示發生任何故障。

DPM 常駐程式可監視透過多重路徑驅動程式 (如 MPxIO、HDLM 與 PowerPath) 可看到的邏輯路徑的可用性。 將不監視這些驅動程式管理的個別實體路徑，因為多重路徑驅動程式可遮罩 DPM 常駐程式的個別故障。

監視磁碟路徑

本節說明了監視叢集內磁碟路徑的兩種方法。 第一種方法由 scdpm 指令提供。 使用該指令，可監視、取消監視或顯示叢集內磁碟路徑的狀態。 此指令對於列印故障磁碟的清單以及從檔案監視磁碟路徑也很有用。

SunPlex Manager 圖形使用者介面 (GUI) 提供了監視叢集內磁碟路徑的第二種方法。 SunPlex Manager 提供了叢集內受監視磁碟路徑的拓撲檢視。 此檢視每 10 分鐘更新一次，以提供關於失敗偵測的數目。 請將 SunPlex Manager GUI 提供的資訊與 scdpm(1M) 指令配合使用，來管理磁碟路徑。 請參閱Sun Cluster 系統管理指南 (適用於 Solaris 作業系統)中的「使用圖形使用者介面管理 Sun Cluster」，以取得有關 SunPlex Manager 的資訊。

使用 scdpm 指令監視磁碟路徑

scdpm(1M) 指令提供了可讓您執行下列作業的 DPM 管理指令︰

從任何作用中節點發出具有磁碟路徑引數的 scdpm(1M) 指令，以便對叢集執行 DPM 管理作業。 磁碟路徑引數總是由節點名稱與磁碟名稱構成。 如果未指定任何節點，則不需要節點名稱，而預設為 all。 下列表格說明了磁碟路徑的命名慣例。

註解 –

極力建議您使用全域磁碟路徑名稱，因為全域磁碟路徑名稱在整個叢集中是一致的。 UNIX 磁碟路徑名稱在整個叢集中是不一致的。 一個磁碟的 UNIX 磁碟路徑在叢集節點之間可以不同。 磁碟路徑可以在一個節點上為 c1t0d0，而在另一個節點上為 c2t0d0。 如果您使用 UNIX 磁碟路徑名稱，請在發出 DPM 指令之前，使用 scdidadm -L 指令將 UNIX 磁碟路徑名稱對應至全域磁碟路徑名稱。 請參閱 scdidadm( 1M) 線上援助頁。

表 3–3 範例磁碟路徑名稱

名稱類型  

範例磁碟路徑名稱  

說明  

整體磁碟路徑  

schost-1:/dev/did/dsk/d1

schost-1 節點上的磁碟路徑 d1

all:d1

叢集內所有節點上的磁碟路徑 d1

UNIX 磁碟路徑  

schost-1:/dev/rdsk/c0t0d0s0

schost-1 節點上的磁碟路徑 c0t0d0s0

schost-1:all

schost-1 節點上的所有磁碟路徑

所有磁碟路徑 

all:all

叢集中所有節點上的全部磁碟路徑 

使用 SunPlex Manager 監視磁碟路徑

SunPlex Manager 可讓您執行下列基本的 DPM 管理作業︰

請參閱 SunPlex Manager 線上說明，以取得關於如何使用 SunPlex Manager 來執行磁碟路徑管理的程序資訊。

法定數目與法定裝置

由於叢集節點共用資料與資源，因此永遠不得將叢集分割為同時作用的獨立分割區。 CMM 保證即使叢集交互連結已做了分割，在任何時刻只會有一個叢集在運作。

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

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

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

法定數目投票計數

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

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

您可以在叢集安裝期間或稍後，使用Sun Cluster 系統管理指南中說明的程序來配置法定裝置。

註解 –

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

法定數目配置

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

圖 3–2 法定裝置配置範例

圖例： 前述上下文說明圖形。

法定數目準則

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

故障隔離

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

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

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

SunPlex 系統使用 SCSI 磁碟保留來實施故障隔離。 使用 SCSI 保留時，會將發生故障的節點與多重主機磁碟「隔離」開，防止節點存取這些磁碟。

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

當叢集成員偵測到另一個節點在叢集交互連接上已經不再進行通訊，即會起始隔離程序來防止其他節點存取共用磁碟。 發生此故障隔離時，被隔離的節點會當機，並在其主控台上顯示「保留衝突」訊息，這很正常。

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

故障隔離的 Failfast 機制

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

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

MHIOCENFAILFAST ioctl 會使驅動程式檢查由節點發佈給磁碟的每次讀取與寫入的錯誤傳回，以取得 Reservation_Conflict 錯誤碼。 ioctl 會在背景中定期地對磁碟發出測試作業，以檢查 Reservation_Conflict。 如果傳回 Reservation_Conflict，前景與背景的控制流路徑都會當機。

對於 SCSI-2 磁碟而言，保留不是永久性的。節點重新啟動後，這些保留將不再存在。 對於包含永久群組保留 (PGR) 的 SCSI-3 磁碟而言，保留資訊儲存在磁碟上，節點重新啟動後會存留下來。 不管您是否有 SCSI-2 磁碟或 SCSI-3 磁碟，failfast 機制的運作都一樣。

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

在當機之後，該節點可能重新啟動並嘗試重新連結叢集，或者停留在 OpenBootTM PROM (OBP) 提示符號處 (如果叢集由基於 SPARC 的系統組成)。 採用的動作由 auto-boot? 參數的設定所決定。 您可以在基於 SPARC 的叢集中，於 OpenBoot PROM ok 提示符號處，使用 eeprom(1M) 來設定 auto-boot?，或者在基於 x86 的叢集中，於 BIOS 啟動後使用您所選擇執行的 SCSI 公用程式來設定。

資料服務

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

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

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

故障回復設定

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

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

資料服務故障監視器

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

開發新的資料服務

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

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

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

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

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

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

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

此類型儲存體的另一個範例是後端資料庫，如高度可用的 Oracle 或基於 SPARC 叢集的 Oracle Parallel Server/Real Application Clusters。 請注意，此類型的後端資料庫伺服器透過資料庫查詢或更新異動，可提供內建的同步化，因此多重伺服器實例不需要實施它們自己的同步化。

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

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

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

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

Sun Cluster Data Services Planning and Administration Guide說明了如何安裝和配置 SunPlex 系統提供的資料服務。 Sun Cluster 資料服務開發者指南說明了如何導入將在 Sun Cluster 框架下具有高可用性的其他應用程式。

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

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

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

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

要在節點之間使用叢集交互連接進行通訊，應用程式必須使用安裝叢集時配置的專用主機名稱。 例如，如果節點 1 的專用主機名稱是 clusternode1-priv，請使用該名稱以透過節點 1 的叢集交互連接進行通訊。使用此名稱開啟的 TCP 插槽透過叢集交互連接進行路由，並可在出現網路故障時透明式地重新路由。

請注意，由於專用主機名稱可以在安裝時配置，因此叢集交互連接可使用當時選取的任何名稱。 可使用 scha_privatelink_hostname_node 引數從 scha_cluster_get(3HA) 取得實際名稱。

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

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

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

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

請注意，透過叢集交互連接接受連接、然後出於安全性原因而驗證 IP 位址的應用程式，必須檢查從 gethostbyname 傳回的所有 IP位址，而不僅僅檢查第一個 IP 位址。

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

資源、資源群組與資源類型

資料服務利用了多種類型的資源： 應用程式，例如 Sun Java System Web Server (以前稱為 Sun Java System Web Server) 或 Apache Web Server，均使用這些應用程式所依賴的網路位址 (邏輯主機名稱與共用位址)。 應用程式和網路資源形成受 RGM 管理的基本單位。

資料服務式資源類型。 例如，Sun Cluster HA for Oracle 屬於 SUNW.oracle-server 資源類型；而 Sun Cluster HA for Apache 屬於 SUNW.apache 資源類型。

註解 –

資源類型 SUNW.oracle-server 僅在基於 SPARC 的叢集中使用。

資源是在整個叢集中定義的資源類型的個體化。 有數種已定義的資源類型。

網路資源屬於 SUNW.LogicalHostname 或 SUNW.SharedAddress 資源類型。 Sun Cluster 軟體將預先註冊這兩種資源類型。

SUNW.HAStorage 及 HAStoragePlus 資源類型用來將資源的啟動與該資源所依賴之磁碟裝置群組的啟動同步化。 它可確保在資料服務啟動之前，叢集檔案系統裝載點的路徑、整體裝置和裝置群組名稱是可用的。 如需詳細資訊，請參閱「Data Services Installation and Configuration Guide」中的「Synchronizing the Startups Between Resource Groups and Disk Device Groups」。 (在 Sun Cluster 3.0 5/02 中已經可以使用 HAStoragePlus 資源類型，並在此資源中新增了另一項可讓本機檔案系統具備高可用性的功能。 如需有關此功能的詳細資訊，請參閱HAStoragePlus 資源類型。)

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

註解 –

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

Resource Group Manager (RGM)

RGM 可控制資料服務 (應用程式) 作為資源 (由資源類型實作來管理)。 這些實施由 Sun 提供，或由開發人員以一般資料服務範本、資料服務開發檔案庫 API (DSDL API) 或 Sun Java System Web Server 資源管理 API (RMAPI) 所建立。 叢集管理員可建立和管理儲存區中的資源，稱為資源群組。 RGM 停止和啟動所選取節點上的資源群組，以回應叢集成員身份變更。

RGM 作用於資源及資源群組。 RGM 動作可使資源及資源群組在線上狀態與離線狀態之間移動。 可套用至資源與資源群組的狀態與設定之完整說明列於資源和資源群組的狀態與設定一節中。 請參閱資源、資源群組與資源類型，以取得關於如何在 RGM 控制下啟動資源管理專案的資訊。

資源和資源群組的狀態與設定

管理者將靜態設定值套用到資源與資源群組中。 這些設定值只可經由管理動作來變更。 RGM 在動態的「狀態」間移動資源群組。 這些設定值與狀態的說明列於下述清單中。

資源及資源群組屬性

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

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

RGM 延伸屬性提供了諸如應用程式二進位檔案及配置檔案之位置的資訊。 您要依照資料服務的配置方式來修改延伸屬性。 在Sun Cluster Data Services Planning and Administration Guide中，關於資料服務的個別章節描述了延伸屬性集。

資料服務專案配置

可將資料服務配置為：使用 RGM 上線時，於 Solaris 專案名稱下啟動。 此配置可將 RGM 管理的資源或資源群組與 Solaris 專案 ID 關聯起來。 若將資源或資源群組對應至專案 ID，便可讓您使用 Solaris 環境中可用的複雜控制，以管理叢集內的工作量與耗用量。

註解 –

僅當您將目前版次的 Sun Cluster 軟體與 Solaris 9 配合執行時，才可以執行此配置。

在叢集環境中使用 Solaris 管理功能，可讓您確定已經為最重要的應用程式提供了優先權 (當它與其他應用程式共用節點時)。 如果您已經合併了服務或應用程式已經進行了故障轉移，則應用程式可能會共用一個節點。 若使用此處所述的管理功能，可能會透過防止其他低優先權應用程式過度耗用系統供給品 (如 CPU 時間)，來提高重要應用程式的可用性。

註解 –

此功能的 Solaris 說明文件說明了 CPU 時間、程序、作業以及與「資源」相似的元件。 同時，Sun Cluster 說明文件使用「資源」一詞來說明處於 RGM 控制下的實體。 以下一節將使用「資源」一詞來表示處於 RGM 控制下的 Sun Cluster 實體，使用「供給品」一詞來表示 CPU 時間、程序以及作業。

本節提供配置資料服務以啟動所指定 Solaris 9 project(4) 中程序的概念性說明。 本節也說明了幾種故障轉移方案與建議，以計劃使用 Solaris 環境提供的管理功能。 如需有關管理功能的概念與程序詳細說明文件，請參閱Solaris 9 System Administrator Collection中的System Administration Guide: Resource Management and Network Services。

若配置資源及資源群組以在叢集內使用 Solaris 管理功能，請考慮使用以下高階程序︰

  1. 將應用程式配置為資源的一部分。

  2. 將資源配置為資源群組的一部分。

  3. 啟用資源群組中的資源。

  4. 使資源群組受管理。

  5. 為資源群組建立 Solaris 專案。

  6. 配置標準屬性以將資源群組名稱與步驟 5 中建立的專案關聯起來。

  7. 讓資源群組上線運作。

若要配置標準的 Resource_project_name 或 RG_project_name 屬性，以將 Solaris 專案 ID 與資源或資源群組相關聯，請將 -y 選項與 scrgadm(1M) 指令配合使用。 將屬性值設定為資源或資源群組。 請參閱 Sun Cluster Data Services Planning and Administration Guide for Solaris OS 中的「Standard Properties」，以取得屬性定義。 請參閱 r_properties(5) 與 rg_properties(5)，以取得屬性說明。

指定的專案名稱必須存在於專案資料庫 (/etc/project) 中，超級使用者必須配置為已命名專案的成員。 請參閱Solaris 9 System Administrator Collection內System Administration Guide: Resource Management and Network Services中的「Projects and Tasks」，以取得關於專案名稱資料庫的概念資訊。 請參閱 project( 4)，以取得專案檔案語法的說明。

若 RGM 使資源或資源群組線上運作，它便啟動了專案名稱下的相關程序。

註解 –

使用者可以隨時將資源或資源群組與專案關聯起來。 不過，只有使用 RGM 將資源或資源群組離線，然後重新使其線上運作，新的專案名稱才可會有效。

啟動專案名稱下的資源與資源群組可讓您配置下列功能，以便在整個叢集內管理系統供給品。

確定專案配置的需求

在配置資料服務以在 Sun Cluster 環境中使用 Solaris 提供的控制之前，您必須決定要如何在整個切換保護移轉或故障轉移中控制與追蹤資源。 請先考慮識別叢集內的相依性，然後再配置一個新專案。 例如，資源與資源群組依賴磁碟裝置群組。 請使用 nodelist、failback、maximum_primaries 與 desired_primaries 資源群組屬性 (用 scrgadm (1M) 配置) 來識別資源群組的 nodelist 優先權。 請參閱Sun Cluster Data Services Planning and Administration Guide for Solaris OS中的「Relationship Between Resource Groups and Disk Device Groups」，以取得資源群組與磁碟裝置群組之間節點清單相依性的簡短論述。 如需詳細的屬性說明，請參閱 rg_properties (5)。

請使用 preferenced 與 failback 屬性 (用 scrgadm( 1M) 與 scsetup( 1M) 配置) 來確定磁碟裝置群組的節點清單優先權。 如需程序資訊，請參閱Sun Cluster 系統管理指南 (適用於 Solaris 作業系統)的「管理磁碟裝置群組」中的「如何變更磁碟裝置屬性」。請參閱SunPlex 系統的硬體與軟體元件，以取得關於節點配置與故障轉移及可延伸資料服務之行為的概念資訊。

如果您以相同方式配置所有的叢集節點，將在主要節點與次要節點上以相同方式執行使用限制。 在所有節點上的配置檔案中，所有應用程式的專案配置參數無需完全相同。 與應用程式關聯的所有專案必須至少可透過該應用程式所有潛在主控者上的專案資料庫來存取。 假設應用程式 1 由 phys-schost-1 主控，但可以潛在地切換至或故障轉移至 phys-schost-2 或 phys-schost-3。 與應用程式 1 關聯的專案必須可在所有三個節點上 (phys-schost-1、phys-schost-2 與 phys-schost-3) 存取。

註解 –

專案資料庫資訊可以為本機的 /etc/project 資料庫檔，也可以儲存在 NIS 對應或 LDAP 目錄服務中。

Solaris 環境允許靈活配置使用參數，並且 Sun Cluster 施加極少的限制。 配置選項取決於網站的需要。 在配置系統之前，請考慮下列章節中的一般準則。

設定每個程序的虛擬記憶體限制

請將 process.max-address-space 控制設定為以每個程序為基礎來限制虛擬記憶體。 請參閱 rctladm( 1M)，以取得關於設定 process.max-address-space 值的詳細資訊。

在 Sun Cluster 中使用管理控制時，請適當配置記憶體限制，以防止應用程式發生不必要的故障轉移以及「交替」效果。 一般而言︰

故障轉移方案

您可以配置管理參數，以便專案配置 (/etc/project) 中的分配可在一般的叢集作業中以及在切換保護移轉或故障轉移情形下運作。

下列章節為方案範例。

在叢集環境中，可將應用程式配置為資源的一部分，並將資源配置為資源群組 (RG) 的一部分。 發生故障時，資源群組及其關聯的應用程式會將故障轉移至另一個節點。 在下列範例中不明確顯示資源。 假定每個資源僅有一個應用程式。

註解 –

故障轉移以 RGM 中設定的個人喜好節點清單順序發生。

下列範例具有這些限制︰

雖然指定的份額數相同，但分配給每個應用程式的 CPU 時間百分比將在故障轉移後發生變更。 此百分比取決於節點上執行的應用程式數目，以及指定給每個作用中應用程式的份額數。

在這些情形下，假定下列配置。

具有兩個應用程式的兩個節點叢集

您可以在包含兩個節點的叢集上配置兩個應用程式，以確保各實體主機 (phys-schost-1、phys-schost-2) 作為一個應用程式的預設主要節點。 每個實體主機可作為另一個實體主機的次要節點。 與應用程式 1 及應用程式 2 關聯的所有專案必須在兩個節點的專案資料庫檔案中提供。 當叢集正常執行時，每個應用程式將在其預設主控者上執行，在此位置上將藉由管理設備為每個應用程式分配所有 CPU 時間。

發生故障轉移或切換保護移轉之後，兩個應用程式將在單一節點上執行，在該節點上將按照配置檔案中的指定為它們分配份額。 例如，在 /etc/project 檔案中，此項目指定了為應用程式 1 分配了 4 個份額，為應用程式 2 分配了 1 個份額。 

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

下圖說明此配置的一般作業與故障轉移作業。 指定的份額數沒有變更。 然而，每個應用程式可用的 CPU 時間之百分比可以變更，這要取決於指定給要求 CPU 時間的每個程序之份額數。

圖例： 前述上下文說明圖形。

具有三個應用程式的兩個節點叢集

在具有三個應用程式的兩個節點叢集上，您可以將一個實體主機 (phys-schost-1) 配置為一個應用程式的預設主要節點，將第二個實體主機 (phys-schost-2) 配置為其餘兩個應用程式的預設主要節點。 假定每個節點上都有以下範例專案資料庫檔案。 當發生故障轉移或切換保護移轉時，專案資料庫檔案不會變更。 

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

當叢集正常執行時，將在應用程式 1 的預設主控者 phys-schost-1 上為其分配 5 個份額。 此數相當於 CPU 時間的 100%，因為它是該節點上需要 CPU 時間的唯一應用程式。 應用程式 2 與 3 在各自的預設主控者 phys-schost-2 上分別分配了 3 個與 2 個份額。 在一般作業期間，應用程式 2 將收到 60% 的 CPU 時間，應用程式 3 將收到 40% 的 CPU 時間。

如果發生故障轉移或切換保護移轉，並將應用程式 1 切換至 phys-schost-2，所有三個應用程式的份額將保持相同。 不過，將依據專案資料庫檔案重新分配 CPU 資源的百分比。

下圖展示了此配置的一般作業與故障轉移作業。

圖例： 前述上下文說明圖形。

僅資源群組的故障轉移

在多個資源群組使用同一個預設主控者的配置中，資源群組 (及其關聯應用程式) 可以發生故障轉移或切換至次要節點。 同時在叢集內執行預設主控者。

註解 –

在故障轉移期間，將按照次要節點上配置檔案中的指定，為發生故障轉移的應用程式分配資源。 在此範例中，主要節點與次要節點上的專案資料庫檔案具有相同的配置。

例如，此範例配置檔案指定為應用程式 1 分配 1 個份額，為應用程式 2 分配 2 個份額以及為應用程式 3 分配 2 個份額。 

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)

下圖展示了此配置的一般作業與故障轉移作業，其中包含應用程式 2 的 RG-2 可將故障轉移至 phys-schost-2。 請注意指定的份額數不會變更。 然而，每個應用程式可用的 CPU 時間之百分比可以變更，這要取決於指定給需要 CPU 時間的每個應用程式的份額數。

圖例： 前述上下文說明圖形。

公用網路配接卡與 IP Network Multipathing

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

Sun Cluster 上的 Solaris 網際網路協定 (IP) 網路多重路徑軟體提供監視公用網路配接卡並將 IP 位址故障從一個配接卡轉移至另一個配接卡 (當偵測到錯誤時) 的基本機制。 每一個叢集節點均擁有自己的 IP Network Multipathing 配置，該配置可能與其他叢集節點上的此種配置不同。

可將公用網路配接卡組織到 IP 多重路徑群組 (多重路徑群組) 中。 每個多重路徑群組均有一個或多個公用網路配接卡。 多重路徑群組中的每個配接卡都可以處於作用中，或者您可以配置備用介面 (除非發生故障轉移，否則處於非作用中)。 in.mpathd 多重路徑常駐程式使用測試 IP 位址來偵測故障並進行修復。 如果透過多重路徑常駐程式在其中一個配接卡上偵測到錯誤，將發生故障轉移。 所有網路存取都可將故障從發生錯誤的配接卡轉移到多重路徑群組中另一個功能正常的配接卡，從而維護節點的公用網路連接性。 如果配置了備用介面，常駐程式將選擇此備用介面。 否則，in.mpathd 將選擇具有最少 IP 位址數目的介面。 因為失效保護是發生在配接卡介面層次，所以較高層次的連接 (如 TCP) 不受影響，但是在失效保護期間的短暫延遲除外。 若 IP 位址的故障轉移成功完成，將發送免費的 ARP 廣播。 由此將維護與遠端用戶端的連接性。

註解 –

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

多重路徑群組可提供邏輯主機名稱與共用位址資源的建置區塊。 您也可以另外建立邏輯主機名稱與共用位址資源的多重路徑群組，來監視叢集節點的公用網路連接性。 節點上的相同多重路徑群組可以擁有任意數目的邏輯主機名稱或共用位址資源。 如需有關邏輯主機名稱與共用位址資源的詳細資訊，請參閱Sun Cluster Data Services Planning and Administration Guide。

註解 –

IP Network Multipathing 機制的設計是為了偵測和遮罩配接卡故障。 其設計目的不是為了使用 ifconfig(1M) 從管理員回復以移除其中一個邏輯 (或共用) IP 位址。 Sun Cluster 軟體將邏輯與共用 IP 位址檢視為 RGM 管理的資源。 管理員加入或移除 IP 位址的正確方式，是使用 scrgadm(1M) 來修改包含資源的資源群組。

如需關於 IP 網路多重路徑 Solaris 實作的詳細資訊，請參閱安裝在叢集上的 Solaris 作業環境之適當說明文件。

作業環境版次 

如需相關說明，請參閱... 

Solaris 8 作業環境 

IP Network Multipathing Administration Guide

Solaris 9 作業環境 

System Administration Guide: IP Services 中的「IP 網路多重路徑主題」

SPARC: 動態重新配置支援

正在以遞增方式分階段地開發 Sun Cluster 3.1 4/04 對動態重新配置 (DR) 軟體功能的支援。 本節說明關於 Sun Cluster 3.1 4/04 支援 DR 功能的概念與注意事項。

請注意，為 SolarisDR 功能形成文件的所有需求、程序及限制，也適用於 Sun Cluster DR 支援 (作業環境暫停運作除外)。 因此，在使用 Sun Cluster 軟體的 DR 功能之前，請先複查 Solaris DR 功能的說明文件。 此外，還需特別注意DR 分解作業時會影響非網路 IO 裝置的問題。 Sun Enterprise 10000 Dynamic Reconfiguration User Guide與Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual(從Solaris 8 on Sun Hardware或Solaris 9 on Sun Hardware集合中) 都可從 http://docs.sun.com 進行下載。

SPARC: 動態重新配置一般說明

DR 功能允許在執行中的系統內執行諸如移除系統硬體的作業。 DR 程序用於確保連續的系統作業，無需停止系統或中斷叢集可用性。

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

移除包含作用中元件的板將導致系統錯誤。 在移除板之前，DR 子系統可查詢其他子系統 (如 Sun Cluster)，以確定是否正在使用板上的元件。 如果 DR 子系統發現一個板正在使用中，將不執行 DR 移除板的作業。 由於 DR 子系統不對包含作用中元件的板執行作業，因此執行 DR 移除板作業永遠是安全的。

DR 加入板作業也永遠是安全的。 新加入板上的 CPU 與記憶體會由系統自動納入服務中。 然而，系統管理員必須手動配置叢集，以便主動使用新加入板上的元件。

註解 –

DR 子系統具有數個層次。 如果較低層次報告一個錯誤，則較高層次也將報告一個錯誤。 然而，較低層次報告特定錯誤時，較高層次將報告「未知的錯誤」。 系統管理員應該忽略由較高層次報告的「未知的錯誤」。

下列章節說明了用於不同裝置類型的 DR 注意事項。

SPARC: CPU 裝置的 DR 叢集注意事項

由於存在 CPU 裝置，因此 Sun Cluster 軟體不會拒絕執行 DR 移除板作業。

若接著執行 DR 加入板作業，加入板上的 CPU 裝置將自動納入系統作業中。

SPARC: 記憶體的 DR 叢集注意事項

出於 DR 目的，需要考慮兩種類型的記憶體。 這兩種類型僅在用法上不同， 其實際硬體相同。

作業系統使用的記憶體稱為核心記憶體機架。 在包含核心記憶體機架的板上，Sun Cluster 軟體不支援移除板作業，並將拒絕執行任何此種作業。 若 DR 移除板作業關係到記憶體而非核心記憶體機架，則 Sun Cluster 將不會拒絕此作業。

若接著執行關係到記憶體的 DR 加入板作業，加入板上的記憶體將自動納入系統作業中。

SPARC: 磁碟與磁帶機的 DR 叢集注意事項

Sun Cluster 會拒絕主要節點之作用中磁碟機上的 DR 移除板作業。 DR 移除板作業可以在主要節點的非作用中磁碟機以及次要節點的任何磁碟機上執行。 DR 作業完成後，叢集資料存取會像之前一樣繼續。

註解 –

Sun Cluster 會拒絕影響法定裝置可用性的 DR 作業， 如需關於法定裝置與在其上執行 DR 作業之程序的注意事項，請參閱SPARC: 法定裝置的 DR 叢集注意事項。

請參閱Sun Cluster 系統管理指南，以取得有關如何執行這些動作的詳細說明。

SPARC: 法定裝置的 DR 叢集注意事項

如果 DR 移除板作業掛細到包含裝置 (為法定數目配置) 介面的板，Sun Cluster 將拒絕此作業並識別將受此作業影響的法定裝置。 您必須先將此裝置作為法定裝置停用，然後才可以執行 DR 移除板作業。

請參閱Sun Cluster 系統管理指南，以取得有關如何執行這些動作的詳細說明。

SPARC: 叢集交互連接介面的 DR 叢集注意事項

如果 DR 移除板作業關係到包含作用中叢集交互連接介面的板，Sun Cluster 會拒絕該作業，並指出可能會被該作業影響的介面。 您必須使用 Sun Cluster 管理工具來停用作用中介面，然後 DR 作業才可以接著執行 (另請參閱下面的警告)。

請參閱Sun Cluster 系統管理指南，以取得有關如何執行這些動作的詳細說明。

Caution – Caution –

Sun Cluster 要求每個叢集節點和其他所有叢集節點至少要有一個作業路徑。 請勿停用私有交互連接介面支援任何叢集節點的最後路徑。

SPARC: 公用網路介面的 DR 叢集注意事項

如果 DR 移除板作業關係到包含作用中公用網路介面的板，Sun Cluster 會拒絕該作業，並指出可能會被該作業影響的介面。 在使用提供的作用中網路介面移除一個板之前，必須透過 if_mpadm(1M) 指令，首先將該介面上的所有通訊切換至多重路徑群組中另一個功能正常的介面。

Caution – Caution –

如果您在停用的網路配接卡上執行 DR 移除作業時其餘網路配接卡發生故障，則可用性會受到影響。 其餘的配接卡沒有空間可以為 DR 作業的持續時間進行故障轉移。

請參閱Sun Cluster 系統管理指南，以取得有關如何在公用網路介面上執行 DR 移除作業的詳細說明。