Sun Cluster 資料服務開發者指南 (適用於 Solaris 作業系統)

附錄 E 不支援叢集的應用程式的要求

一般而言,非叢集支援應用程式必須滿足特定的需求,才能成為具有高度可用性 (HA) 的候選應用程式。小節分析應用程式的適當性列出了這些要求。附錄提供了關於該清單中特定項目的附加詳細資訊。

透過將應用程式的資源配置到資源群組,可以使該應用程式具有高可用性。應用程式的資料置於高度可用的叢集檔案系統,在一個伺服器失敗時可由尚存的伺服器存取資料。請參閱「Sun Cluster 概念指南 (適用於 Solaris 作業系統)」中有關叢集檔案系統的資訊。

為了網路上的用戶端進行網路存取,在邏輯主機名稱資源中配置一個邏輯網路 IP 位址,邏輯主機名稱資源與資料服務資源處於相同的資源群組。資料服務資源與網路位址資源一起進行故障轉移,導致資料服務的網路用戶端在其新主機上存取資料服務資源。

本附錄涵蓋以下主題︰

多重主機資料

具有高可用性的叢集檔案系統的裝置是多重主機式的,因此當某實體主機當機時,尚存的主機之一可以存取裝置。若要應用程式具有高可用性,其資料必須具有高可用性。因此,應用程式的資料必須位於可從多個叢集節點存取的檔案系統中。Sun Cluster 支援的高可用性檔案系統的範例包含全域 HA 檔案系統、容錯移轉檔案系統 (FFS),以及使用 Oracle Real Application Clusters 的環境中的 QFS 共用檔案系統。

叢集檔案系統裝載於作為獨立實體建立的裝置群組上。您可以選擇將某些裝置群組作為裝載的叢集檔案系統使用,將其他裝置群組作為原始裝置與資料服務 (例如,HA Oracle 軟體) 搭配使用。

應用程式可能具有指令行選項或指向資料檔案位置的配置檔案。如果應用程式使用固定連線路徑名稱,則您可變更路徑名稱為符號連結 (指向叢集檔案系統中的檔案),無需變更應用程式程式碼。請參閱使用多重主機資料放置的符號連結,以取得有關使用符號連結的更詳細論述。

在最差情況下,必須修改應用程式原始碼以提供用於指向實際資料位置的機制。您可以透過建立附加指令行引數實作此機制。

Sun Cluster 軟體支援在容體管理程式中配置的 UNIX UFS 檔案系統和 HA 原始裝置的使用。當安裝和配置 Sun Cluster 軟體時,叢集管理員必須為 UFS 檔案系統和原始裝置分別指定要使用的磁碟資源。通常,僅資料庫伺服器和多媒體伺服器使用原始裝置。

使用多重主機資料放置的符號連結

有時,應用程式資料檔案的路徑名稱為固定連線的,不具有用於覆寫固定連線路徑名稱的機制。若要避免修改應用程式代碼,有時您可以使用符號連結。

例如,假定應用程式用固定連線路徑名稱 /etc/mydatafile 命名其資料檔。您可以將此路徑從檔案變更為符號連結,此符號連結的值指向其中一個邏輯主機檔案系統中的某檔案。例如,您可以使路徑變更為至 /global/phys-schost-2/mydatafile 的符號連結。

如果應用程式或其管理程序之一修改資料檔名稱及其內容,則使用符號連結將會出現問題。例如,假定應用程式透過首先建立一個新的暫存檔 /etc/mydatafile.new 來執行更新。然後,應用程式透過使用 rename() 系統呼叫 (或 mv 指令) 重新命名暫存檔以具有實際的檔案名稱。透過建立暫存檔並將其重新命名為實際檔案名稱,資料服務將嘗試確保其資料檔案內容始終正常。

但是,rename() 動作會毀壞符號連結。現在,名稱 /etc/mydatafile 為一般檔案且位於與 /etc 目錄相同的檔案系統中,而非位於叢集的叢集檔案系統中。由於 /etc 檔案系統對於每個主機都是專用的,因此在故障轉移或切換保護移轉之後資料將不可用。

基本問題是現有應用程式不支援符號連結,並且未寫入以處理符號連結。若要使用符號連結將資料存取重新導向邏輯主機的檔案系統,必須以不會刪除符號連結的方式來執行應用程式。因此,符號連結不是一個針對將資料置於叢集檔案系統問題的完整修正方法。

主機名稱

您必須確定資料服務是否需要知道執行它的伺服器的主機名稱。如果需要,可能需要修改資料服務以使用邏輯主機名稱,而非實體主機名稱。從此種意義而言,邏輯主機名稱是配置為位於邏輯主機名稱資源 (與應用程式資源位於相同的資源群組中) 中的主機名稱。

有時,在用於資料服務的主從式協定中,伺服器會將其主機名稱作為至用戶端的部分訊息內容傳回至用戶端。對於這樣的協定,用戶端可能會依賴此傳回主機名稱作為聯絡伺服器時使用的主機名稱。對於故障轉移後或切換保護移轉後要使用的傳回主機名稱,主機名稱應該是資源群組的邏輯主機名稱,而不是實體主機的名稱。在這種情況下,必須修改資料服務代碼,以將邏輯主機名稱傳回用戶端。

多重主目錄主機

專有名詞多重主目錄主機說明位於多個公用網路上的主機。這樣的主機具有多個主機名稱和 IP 位址。每個網路有一個主機名稱–IP 位址對。Sun Cluster 被設計為允許主機出現在任意數目的網路上,包括只出現在一個網路上 (非多重主目錄的的情況)。正像實體主機名稱具有多個主機名稱–IP 位址對一樣,每個資源群組也可具有多個主機名稱–IP 位址對,每個公用網路有一個主機名稱–IP 位址對。當 Sun Cluster 在實體主機之間移動資源群組時,將會移動該資源群組的主機名稱–IP 位址對的完整集合。

資源群組的主機名稱–IP 位址對集合配置為包含在資源群組中的邏輯主機名稱資源。當建立和配置資源群組時,叢集管理員會指定這些網路位址資源。Sun Cluster 資料服務 API 包含查詢這些主機名稱–IP 位址對的功能。

大多數為 Solaris 作業系統撰寫的常用資料服務常駐程式已經能正確處理多重主目錄主機。許多資料服務透過連結至 Solaris 萬用字元位址 INADDR_ANY 來進行所有的網路通訊。該連結自動使資料服務處理所有網路介面的全部 IP 位址。INADDR_ANY 有效地連結至目前在機器上配置的所有 IP 位址。通常,無需變更使用 INADDR_ANY 的資料服務常駐程式,即可處理 Sun Cluster 邏輯網路位址。

連結至 INADDR_ANY,而非連結至特定 IP 位址

即使使用非多重主目錄主機,Sun Cluster 邏輯網路位址概念也可使機器具有多個 IP 位址。機器自己的實體主機具有一個 IP 位址,其目前控制的每個網路位址 (邏輯主機名稱) 資源均具有附加 IP 位址。當機器成為網路位址資源的主控者後,它將動態地取得其他 IP 位址。當機器放棄網路位址資源的主控地位後,它將動態地放棄 IP位址。

如果某些資料服務連結至 INADDR_ANY,則其無法在 Sun Cluster 環境中正常工作。當資源群組被主控或取消主控時,這些資料服務必須將 IP 位址集動態地變更至其所連結的 IP 位址集。實現重新連結的一個策略是終止這些資料服務的啟動和停止方法,並重新啟動資料服務的常駐程式。

Network_resources_used 資源特性允許一般使用者配置應用程式資源應該連結到的特定網路位址資源集。對於需要此功能的資源類型,必須在該資源類型的 RTR 檔案中宣告 Network_resources_used 特性。

當 RGM 使資源群組上線或離線時,關於 RGM 何時呼叫資料服務資源方法,其將遵循特定的順序來探索、取消探索以及配置網路位址為可用或不可用。請參閱決定使用哪些 StartStop 方法

在傳回資料服務的 Stop 方法時,必須使用資源群組的網路位址停止資料服務。同樣地,到 Start 方法返回時,資料服務必須已經開始使用網路位址。

如果資料服務連結至 INADDR_ANY 而非個別 IP 位址,則呼叫資料服務資源方法的次序與呼叫網路位址方法的次序無關。

如果資料服務的停止和啟動方法透過終止並重新啟動資料服務常駐程式來完成工作,則資料服務將使用網路位址在恰當的時間停止和啟動。

用戶端重試

對於網路用戶端,故障轉移和切換保護移轉表現為邏輯主機當機之後快速重新啟動。理想做法為,用戶端應用程式和主從式協定合力進行一定量的重試作業。如果應用程式和協定已處理了單一伺服器當機和重新啟動的情況,則它們也將處理接管或移轉資源群組的情況。某些應用程式可能選擇不斷重試。較複雜的應用程式將通知使用者長時間的重試正在進行中,並讓使用者選擇是否繼續。