在 Sun Cluster 3.0 更新環境中設置 Solaris Resource Manager

有效的拓樸

您可以在 Sun Cluster 3.0 更新環境中安裝 Solaris Resource Manager如需關於有效拓樸的描述，請參閱 Sun Cluster 3.0 12/01 概念。

決定系統需求

當您在一個 Sun Cluster 環境中設置 Solaris Resource Manager 產品時，必須決定您想如何控制與追蹤切換或故障時各個節點的資源。如果您是個別地設置所有群集節點，則在主要及備份節點上的用量限制也會個別地實行。

在所有節點之上的設置檔案中，所有應用程式的設置參數不一定要相同；不過應用程式中所有可能主節點之上的設置檔案都必須至少代表所有的應用程式。例如，如果應用程式 1 由 phys-schost-1 主控但可部分切換或者轉移到 phys-schost-2 或 phys-schost-3，那麼應用程式 1 必須包含在所有三個節點（phys-schost-1、phys-schost-2，以及 phys-schost-3）的設置檔案中。

Solaris Resource Manager 對於用量的設置以及累積的參數上非常有彈性，Sun Cluster 很少對其加以限制。設置的選擇要視網站需要而定。請在設置您的系統之前先考慮下列各節中的綱要事項。

設置記憶體限制參數

將 Solaris Resource Manager 產品與 Sun Cluster 配合使用時，您必須正確地設置記憶體限制，以防止應用程式發生故障以及應用程式的交替切換效果。一般而言：

• 不要將記憶體限制設定得太低。

  當一個應用程式達到其記憶體限制時，就會發生故障。這對資料庫應用程式來說特別重要，因為若達到虛擬記憶體的限制，可能會造成無法預料的後果。

• 不要主要及備份節點上個別設定記憶體的限制。

  相同限制可能會在應用程式達到其記憶體的限制時造成交替切換效應，並且故障為一個有相同記憶體限制的備份節點。在備份節點上設定稍微高的記憶體限制。場地的應用程式、資源，以及喜好設定，決定要設定多高的限制。不同的記憶體限制可以幫助防止交替切換情況，並且讓您在必要時有時間調整參數。

• 請在粗超-精密問題情況的載入平衡中使用 Solaris Resource Manager 記憶體限制。

  例如，您可以使用記憶體限制來防止游離的應用程式消耗過多資源。

使用累積的用量參數

數個 Solaris Resource Manager 參數可以用來記錄系統資源用量的累積：CPU 配分、登入次數以及連線時間。不過在切換或故障的情況下，用量累積資料 (CPU 用量、登入次數以及連線時間) 預設值會在所有切換或故障的應用程式的新主節點之上，由零開始重新啟動。累積資料不會在節點直接動態傳送。

要避免使 Solaris Resource Manager 用量累積報告功能失去準確，您可以建立指令集以便從群集節點來搜集累積資訊。因為在累積期間，一個應用程式可能會在任何可能的主節點上執行。指令集應該從特定應用程式所有可能的主節點來搜集累積資訊。有關詳情，請參閱 第 9章, 使用量資料。

故障的效應

在 Sun Cluster 之上，可以對 Solaris Resource Manager 進行設置，使 lnode 設置 (/var/srm/srmDB) 中說明的資源分配配置，會在正常群集操作以及切換或故障的狀況下保持相同。有關詳情，請參閱 配分配置範例。

以下部分為您提供這些情況的範例。

• 首兩個部分 配合兩個應用程式的雙節點群集 及 配合三個應用程式的雙節點群集，顯示整個節點的故障情況。

• 部分 僅限於資源群組的故障 僅說明應用程式的故障操作。

在群集環境中，應用程式將會設置為資源群組 (RG) 的一部分。在發生故障時，資源群組以及其相關的應用程式將會轉移到另一個節點。在下例中，應用程式 1 (App-1) 設置到資源群組 RG-1 中，應用程式 2 (App-2) 設置到資源群組 RG-2，而應用程式 3 (App-3) 設置到資源群組 RG-3。

雖然指定的配分數量保持相同，分配給每個應用程式的 CPU 資源百分比將會在發生故障時變更，根據節點上執行的應用程式數量以及指定到每個現用應用程式的配分數量而定。

在這些情況中，假設使用下列設置。

• 所有應用程式在共同的父代 lnode 下設置。

• 這些應用程式是該節點上的唯一現用處理。

• 限制資料庫在群集之每個節點上的設置都相同。

配合兩個應用程式的雙節點群集

你可以在一個雙節點群集上配置兩個應用程式，其中每一個實體主機（phys-schost-1、phys-schost-2）對一個應用程式是一個預設主機。每一個實體主機作為另一實體主機的備份節點。兩個節點之上的 Solaris Resource Manager 限制資料庫檔案中必須代表所有的應用程式。當群集正常執行時，每個應用程式會在其預設的主節點上執行，並且由 Solaris Resource Manager配置所有的 CPU 資源。

在發生故障或切換時，兩個應用程式會同時在單一的節點上執行，並且如設置檔案中指定的配置來配分資源。例如，此設置檔案指定應用程式 1 獲配 80 份，應用程式 2 獲配 20 份。

# limadm set cpu.shares=80 App-1 
# limadm set cpu.shares=20 App-2 
...

下列圖表解釋此類配置的正常和失敗運作。請注意，雖然指定的配分數量保持相同，分配給每個應用程式的 CPU 資源百分比將會在發生故障時變更，根據指定到每個處理需求之 CPU 時間的配分數量而定。

配合三個應用程式的雙節點群集

在一個有三個應用程式的雙節點群集之上，您可以將它設置為一個實體主機 (phys-host1) 作為一個應用程式的預設主節點，而第二個實體主機 ( phys-host2) 則為剩下兩個應用程式的預設節點。假設下例是每個節點上的限制資料庫檔案。限制資料庫檔案不會在發生故障或切換時變更。

# limadm set cpu.shares=50	 App-1
# limadm set cpu.shares=30	 App-2
# limadm set cpu.shares=20	 App-3 
...

當群集正常執行時，應用程式 1 會被配置在其預設的主節點 phys-host1 上的 50 份。這相等於 CPU 資源的 100%，因為它是該節點上唯一需求 CPU 資源的應用程式。應用程式 2 及 3 將在其預設的主節點 phys-schost-2 上分別獲配 30 及 20 份。在正常操作下，應用程式 2 可收到 60% 而應用程式 3 則可收到 40% 的 CPU 資源。

在發生故障或切換時，而應用程式 1 切換到 phys-schost-2，所有三個應用程式的配份將保持不變，但是 CPU 資源的百分比將會根據限制資料庫檔案重新配置。

• 應用程式 1，具有 50 份，將收到 CPU 的 50%。

• 應用程式 2，具有 30 份，將收到 CPU 的 30%。

• 應用程式 3，具有 20 份，將收到 CPU 的 20%。

下列圖表解釋此類配置的正常和失敗運作。

僅限於資源群組的故障

在具有相同預設主節點的多個資源群組設置中，資源群組（及其相關應用程式） 可能會發生故障或被切換為備份節點，而預設的主節點仍能保持運作並且在群集中執行。

在發生故障期間，故障的應用程式會依照備份節點上設置檔案所指定的來配置資源。在此範例中，主節點及備份節點上的限制資料庫檔案必須具備相同的設置。

例如，此樣本設置檔案指定應用程式 1 獲配 30 份，應用程式 2 獲配 60 份，而應用程式 3 獲配 60 份。

# 
limadm set cpu.shares=30 App-1
# limadm set cpu.shares=60 App-2
# limadm set cpu.shares=60 App-3
... 

下列圖表解釋此類配置的正常和失敗運作，其中的 RG-2 包含應用程式 2，它轉移到 phys-schost-2。請注意，雖然指定的配分數量保持相同，分配給每個應用程式的 CPU 資源百分比將會在發生故障時變更，根據指定到每個應用程式需求之 CPU 時間的配分數量而定。