test

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

資料服務專案配置

當使用 RGM 使資料服務上線運作後，可以將其配置為以 Solaris 專案名稱啟動。此配置可將 RGM 管理的資源或資源群組與 Solaris 專案 ID 關聯起來。從資源或資源群組至專案 ID 的對映使您可以使用 Solaris 作業系統中提供複雜的控制項，以管理叢集內的工作負荷量和消耗量。

備註 –

僅當您所執行的 Sun Cluster 軟體當前的發行版本不低於 Solaris 9 時才可以執行此配置。

在 Sun Cluster 環境中使用 Solaris 管理功能，可以保證在與其他應用程式共用節點時，最重要的應用程式獲得優先權。如果您已經合併了服務或應用程式已經進行了故障轉移，則應用程式可能會共用一個節點。使用此處說明的管理功能可以防止低優先權的應用程式過度消耗系統資源 (如 CPU 時間)，以提高重要應用程式的可用性。

備註 –

此功能的 Solaris 文件將 CPU 時間、程序、作業和類似元件稱為「資源」。同時，Sun Cluster 文件將受 RGM 控制的實體稱為「資源」。在下一節中，專有名詞「資源」是指受 RGM 控制的 Sun Cluster 實體。在該節中，專有名詞「供應」是指 CPU 時間、程序和作業。

本節提供配置資料服務以在指定的 Solaris 9 project(4) 中啟動程序的概念說明。本節還說明數種容錯移轉分析藍本和有關打算使用 Solaris 提供的管理功能的建議。

如需有關該管理功能詳細的概念和程序文件，請參閱「System Administration Guide: Network Services」中的第 1 章「Network Service (Overview)」。

當配置資源和資源群組以在叢集中使用 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」中的附錄 A「Standard Properties」，以瞭解特性定義。請參閱 r_properties(5) 和 rg_properties(5)，以取得特性說明。

指定的名稱必須在專案資料庫 (/etc/project) 中，並且必須將超級使用者配置為已命名的專案之成員。請參閱「System Administration Guide: Solaris Containers-Resource Management and Solaris Zones」中的第 2 章「Projects and Tasks (Overview)」，以取得有關專案名稱資料庫的概念資訊。請參閱 project(4)，以取得專案檔案語法的說明。

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

備註 –

使用者可以隨時將資源或資源群組與專案關聯起來。然而，直到資源或資源群組離線並使用 RGM 重新使其線上運作之後，新的專案名稱才會生效。

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

確定專案配置的需求

在您配置資料服務以在 Sun Cluster 環境中使用 Solaris 提供的控制項之前，您必須決定如何在切換移轉或容錯移轉間控制和追蹤資源。在配置新的專案之前識別叢集中的相依性。例如，資源與資源群組依賴磁碟裝置群組。

使用由 scrgadm(1M) 配置的 nodelist、failback、maximum_primaries 和 desired_primaries 資源群組特性識別資源群組之節點清單特性。

使用由 scrgadm(1M) 和 scsetup(1M) 配置的 preferenced 特性和 failback 特性確定磁碟裝置群組節點清單優先權。

如果您以相同方式配置所有的叢集節點，將在主要節點與次要節點上以相同方式執行使用限制。對於所有節點上配置檔案中所有的應用程式，專案的配置參數無需相同。至少該應用程式所有潛在主要節點上的專案資料庫必須可以存取所有與應用程式相關聯的專案。假定應用程式 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) 中的分配可在一般的叢集作業中以及在切換保護移轉或故障轉移情形下運作。

下列章節為方案範例。

在 Sun Cluster 環境中，將應用程式配置為資源的一部分然後將資源配置為資源群組 (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 上，分別為應用程式 2 和 3 配置 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 時間的應用程式指定的份額數。

圖例：前面的文字內容說明該圖形。