第 10章 進階用量

本章將進一步探討在一個系統之上優先化與管理不同類應用程式的方法。並且提供一個範例以說明這些功能及與 Solaris Resource Manager 軟體有關的其他關鍵性概念。本章最後一節將介紹如何在 Sun Cluster 3.0 12/01（或更新版本）環境中設置 Solaris Resource Manager。

批次工作量

大多數的商業安裝都需要批次處理的功能。批次處理通常在夜間進行，這時日間的線上工作量大量減少。這麼做的原因有二：將一天的交易量匯入報告中，並且防止批次工作量影響到線上作業。

請參見範例中有關控制執行批次工作的環境中一個階層的說明；本節也將介紹處理中使用的 Solaris Resource Manager 指令。

批次工作量所用的資源

批次工作量是線上交易處理 (OLTP) 和決策支援系統 (DSS) 工作量兩者之間的混合體，其對系統造成的影響介於這兩者之間。一個批次工作量可以包括許多可重覆的資料庫交易，而每一個又含有極重的計算工作在內。舉一個簡單的例子，譬如當天總營業額的計算。這時，批次處理會從資料庫中將當天每一筆營業交易都擷取出來，摘取營業總額，持續不斷地計算總數。

批次處理一般上會在處理器與 I/O 資源上放置高的需求，由於需要大量的 CPU 來進行批次處理與供資料庫使用，因此會從後端資料庫為擷取的每個異動生成大量的 I/O。

因為批次處理和資料庫都需要大量的 CPU 和 I/O 的計算率來控制批次工作量。Solaris Resource Manager 可以對 CPU 進行高精密的資源控制，但卻必須為每個工作量配置不同的 I/O 裝置來管理 I/O 資源。

通常有兩種方法可用來阻絕批次資源的影響：

• 在另一個系統之上複製一份資料庫並且在該系統上執行批次和報告工作量。(不過請注意，大部份情況下，批次處理都會更新部份的線上資料庫，而且無法與之分離。)

• 使用 CPU 資源控制.

因為從一個批次工作量所生成的 I/O 量與消耗的 CPU 量成正比，可以利用對 CPU 循環的限制來間接控制批次工作量的 I/O 率。不過請注意，請嚴加謹慎以確保對 CPU 需求不高的工作量不至於生成過量的 I/O。

與批次處理有關的問題

根據定義，批次工作量就是一個工作量不受限制的執行，它會嘗試在最短時間內完成。這表示批次是最差的資源消耗者，因為批次會毫無節制地使用所有的資源，直到被系統瓶頸(一般指系統最小的資料流) 限制為止。

批次會為系統管理員帶來兩種問題；它會影響其他同時執行的批次工作，而且它無法在正常上班時間內，與工作量的線上部份一起執行。

即使批次工作被排在下班時間執行，例如從半夜 12:00 點到早上 6:00 點，任何的系統問題或是某日高營業額都會使批次工作量超出預定時間而影響到上班時間。雖然不像當機時一樣糟糕，第二天上午 10:30 若仍在執行批次工作量的話，可能會使線上的客戶每進行一次交易就要等候數分鐘之久，最後導致交易量的減少。

用資源配置可以控制批次工作量的工作方式，進而限制它們能利用的資源。

鞏固

Solaris Resource Manager 允許系統資源被配置給系統的各個層級，有時要與各部門間機器用量的業務安排成正比。範例 顯示如何使用 Solaris Resource Manager 階層來將此歸檔。

虛擬記憶體及資料庫

Solaris Resource Manager 產品同時也提供另一種功能，限制使用者及工作量所用虛擬記憶體量。此功能並不會管理實際的記憶體；而會有效地限制每位使用者所消耗的全域對調空間量。

當一位使用者或工作量達到為其 lnode 所限制的虛擬記憶體用量時，系統就會將一個記憶體配置錯誤訊息傳給應用程式；亦即，對 malloc() 的呼叫會失敗。此錯誤碼被當作應用程式對調空間不足而呈報給應用程式。

很少有應用程式能夠有效地應付記憶體的配置錯誤。因此，您最好不要冒險讓資料庫伺服器達到其虛擬記憶體的限制。如果真的達到限制，資料庫引擎可能會當機，因而導致資料庫損毀。

請將虛擬記憶體限制設定得高些，在一般情況下不至於輕易達到限制。此外，虛擬記憶體限制可以用來控制整個資料庫伺服器的用量，它會防止發生記憶體外洩的故障資料庫影響到系統上的其他資料庫和工作量。

管理 NFS

NFS是 Sun 的分布計算環境，可作為 kernel 執行緒來執行，並且使用 kernel 排程類別 SYS。因為 NFS 的排程配置不受 Solaris Resource Manager SHR 類別的管理，因此不可能進行 NFS 的 CPU 資源控制。Solaris Resource Manager 產品配置處理機資源的功能，在提供密集 NFS 服務的系統之上可能效果不彰。

不過 NFS 可以使用網路連接埠的資源管理方式來加以控制。例如， Solaris 頻寬管理員可以用來控制伺服器上 NFS 分封資料的數目。也可以利用處理機組來限制系統類別中可用的 CPU 數目，以便管理 NFS。

管理網路伺服器

軟體可以藉由控制 CPU 及虛擬記憶體量，來管理網路伺服器之上的資源。有三種基本的拓樸學可在作為網路伺服器主機的系統上使用。

結合的網路伺服器資源管理

您可以藉由控制整個網路伺服器能用的資源總量，來管理一個單一網路伺服器。這對一個與其他工作量互相結合的網路伺服器環境而言是非常有用的。這也是最基本的資源管理形式，可以有效地防止其他工作量影響到網路伺服器的執行，反之亦然。舉例來說，如果網路伺服器中的一個 CGI 指令集由於記憶體外洩而用盡了控制，整個系統不至於用盡對調空間；而只有網路伺服器會受到影響。

在此範例中，一個網路伺服器會被配置 20 個配分，表示一旦資料庫要求大量的處理機資源，可以保證至少有百分之 20 的處理機資源可供使用。

請參見放置一個網路 (Web) 前端處理 中其他有關網路伺服器的範例。

單一網路伺服器的精密資源管理

經常會有人要求使用資源管理來控制一個單一網路伺服器之上的行為。舉例來說，單一網路伺服器可以被許多使用者共享，每一位使用者都有其各自的 cgi-bin 程式。

單一 cgi-bin 程式中的一個錯誤可能會導致整個網路伺服器執行緩慢，或是碰到記憶體外洩的情況時，甚至會使整個網路伺服器當機。為了防止這種問題發生，最好是使用每個處理的限制。

多個虛擬網路伺服器的資源管理

通常會利用結合的方式，使單一機器作為多個虛擬網路伺服器的主機。這時，會存在多個 httpd 網路伺服器處理的實例，而且在 Solaris Resource Manager 中也有更多機會能夠充分利用資源控制。

也可能藉由在網路伺服器設置檔案中設定參數，將每個網路伺服器作為一個不同的 UNIX UID 來執行。這會有效地將每個網路伺服器附加至 Solaris Resource Manager 階層中一個不同的 lnode 之上。

例如，Sun WebServer^TM 在設置檔案 /etc/http/httpd.conf 中具有下列參數：

# Server parameters
 server  {
   server_root                   "/var/http/"
   server_user                   "webserver1"
   mime_file                     "/etc/http/mime.types"
   mime_default_type             text/nlain
   acl_enable                    "yes"
   acl_file                      "/etc/http/access.acl"
   acl_delegate_depth            3
   cache_enable                  "yes"
   cache_small_file_cache_size   8                       # megabytes
   cache_large_file_cache_size   256                     # megabytes
   cache_max_file_size           1                       # megabytes
   cache_verification_time       10                      # seconds
   comment                       "Sun WebServer Default Configuration"

   # The following are the server wide aliases

   map   /cgi-bin/               /var/http/cgi-bin/              cgi
   map   /sws-icons/             /var/http/demo/sws-icons/
   map   /admin/                 /usr/http/admin/

 # To enable viewing of server stats via command line,
 # uncomment the following line
   map   /sws-stats              dummy                           stats
 }

藉由設置每個網路伺服器，使其作為不同的 UNIX UID 來執行，您可以在每個網路伺服器上設定不同的限制。這對您控制與計算在作為許多網路伺服器的主機之一個機器上的資源用量時會非常有用。

這時您可以利用許多或是所有的 Solaris Resource Manager 資源控制和限制功能：

Shares [cpu.shares]

cpu.shares 可以用來成比例地將資源配置給不同的網路伺服器。

Mem limit [memory.limit]

memory.limit 可以用來限制網路伺服器能用的虛擬記憶體量，以防止任何一個網路伺服器造成另一個伺服器因為記憶體配置的問題而故障。

Proc mem limit [memory.plimit]

每個處理記憶體限制可以用來限制一個單一 cgi-bin 處理可以使用的虛擬記憶體量，以便防止任何 cgi-bin 處理造成其各自的網路伺服器當機。

Process limit [process.limit]

允許附加至一個網路伺服器上的最大處理總數，可以有效地限制同時進行的 cgi-bin 處理數目。

處理機組的角色及功效

即使有了 Solaris Resource Manager 軟體的幫助，處理機組仍然可以在配置資源時扮演重要的角色。可能在某些情況下，一個系統必須在資源政策上套用硬性限制。舉例來說，某公司可能會購買一個擁有 24- 個處理機的單一系統，然後以同一部機器作為兩個不同業務單位的主機。每一個業務單位負擔機器的一部份費用，譬如分別是百分之 40 和 60。這時，管理員最好是將系統設定為，負擔機器百分之 40 費用的單位所得配分永遠不得超過此百分比。

您可以利用處理機組，配置 10 個處理機給百分之 40 的單位，以及 14 個處理機給百分之 60 的單位，來將工作量分為百分之 40 和 60。

當您與 Solaris Resource Manager 產品配合使用處理機組時，請務必要瞭解這兩種技術間的互動。在某些時候，淨效應可能會與預期的有所不同。

簡單範例

下圖將顯示 Solaris Resource Manager 與處理機組的簡單結合方式。在此範例中，將處理機組與 Solaris Resource Manager CPU 配分互相混合。

使用者 1 有 25 個 Solaris Resource Manager 配分，被限制於使用處理機組 A (1 個 CPU)。使用者 2 有 75 個 Solaris Resource Manager 配分而且被限制於使用處理機組 B (1 個 CPU)。

在此範例中，使用者 2 將會消耗其整個的處理機組 (百分之 50 的系統)。因為使用者 2 只使用系統的百分之 50 (而非其配置的百分之 75)，使用者 1 就能使用剩餘的百分之 50。簡言之，每位使用者都會被賦予百分之 50 的系統資源。

較為複雜的範例

下列範例將顯示一個比較複雜的情況，此時處理機組及 Solaris Resource Manager CPU 配分互相混合。

使用者 1 及 3 各有 10 個 Solaris Resource Manager 配分，而且被限制於使用處理機組 A (1 個 CPU)。使用者 2 有 80 個 Solaris Resource Manager 配分而且被限制於使用處理機組 B (1 個 CPU)。

在此範例中，使用者 2 將會消耗其整個的處理機組 (百分之 50 的系統)。因為使用者 2 只使用百分之 50 (而非配置的百分之 80)，使用者 1 和 3 就能使用剩餘的百分之 50。這表示使用者 1 和 3 會取得百分之 25 的系統，即使他們所配置的只有 10 個資源配分。

應該避免的情況

請您務必避免下列情況。

此時有一位使用者在兩個處理機組上都有處理。使用者 1 有 20 個 Solaris Resource Manager 配分，並且在每個處理機組上都有處理。使用者 2 有 80 個 Solaris Resource Manager 配分而且被限制於使用處理機組 B (1 個 CPU)。

在此範例中，使用者 1 的第一個處理會消耗其整個的處理機組 (百分之 50 的系統)。因為使用者 2 被允許取得 80 個配分，所以使用者 2 的處理將消耗其整個的處理機組 (百分之 50)。因此使用者 1 的第二個處理就無法取得任何 CPU 的資源配分。

範例

本節中的範例可以說明 Solaris Resource Manager 用來控制系統資源及配置，以及顯示資訊的各項功能。

伺服器結合

第一個範例將說明下列這些指令：

liminfo

在一個終端機視窗中列印一或多位使用者的使用者屬性及限制資訊

limadm

變更一組使用者的限制屬性或是刪除限制資料庫的項目

srmadm

顯示或設定操作模式及擴及整個系統的 Solaris Resource Manager 可調參數

srmstat

顯示 lnode 活動資訊

考慮在單一機器之上結合兩個伺服器的情況，每個伺服器執行一個資料庫應用程式。在單一機器上同時執行兩個應用程式將形成一個工作系統。不使用 Solaris Resource Manager，Solaris 系統會以同等使用為基礎，將資源分配給應用程式，並且不會保護應用程式不受其他應用程式的需求競爭。不過，Solaris Resource Manager 卻提供了一種防止應用程式資源匱乏的有效機制。有了 Solaris Resource Manager 之後，可先啟動與對應的 lnode 結點相連接的每個資料庫 db1 和 db2。要這麼做，必須建立三個新的管理位置保留符號使用者。例如： databases、 db1及 db2。將它們新增至限制資料庫；因為 lnode 與 UNIX UID 對應，這些也必須被新增至 passwd 檔案（或如果系統使用一個如 NIS 或 NIS+ 的名稱服務，則是密碼映射）中。假設 UID 被新增至 passwd 檔案或密碼對映中，位置保留符號使用者 db1 和 db2 會被以下列指令指派給 databases lnode 群組：

# limadm set sgroup=0 databases
# limadm set sgroup=databases db1 db2

其中假設 /usr/srm/bin 位於使用者的路徑當中。

圖 10-1 伺服器結合

因為沒有其他定義的群組，databases 群組目前可以完全自由使用機器。與資料庫有關的兩個 lnode 會被執行，而執行資料庫應用程式的處理會被附加至正確的 lnode，以 srmuser 指令在資料庫實例的啟動指令集之中。

# srmuser db1 /usr/bin/database1/init.db1
# srmuser db2 /usr/bin/database2/init.db2

當您啟動資料庫 db1 或是 db2 時，請使用 srmuser 指令以確保資料庫附加至正確的 lnode 之上並且正確地計費 (srmuser 這麼做不會影響處理的所有權) 。要執行上述指令，使用者必須擁有執行 init.db1 所需的 UNIX 權限以及管理權限才能將處理附加至 lnode db1 之上。當使用者登入並使用資料庫時，資料庫所進行的活動會累積到 lnode db1 和 db2 之上。

藉由在每個 lnode 上使用一個配分的預設配置，databases 群組中的用量會在一段時間之後平均下來以確保資料庫 db1 和 db2 都能收到相等的機器配置。特別是 databases 群組有一個尚未使用的配分，而且 databases 擁有它。每一個 lnode db1 和 db2 也都被賦予一個配分的預設配置。在 databases 群組中，有兩個尚未使用的配分，因此 db1 及 db2 都取得 databases 資源之相等分配（在此簡單範例中，並沒有競爭分配的情況，所以 databases 可使用整個系統）。

如果後來發現 Database1 上的活動需要機器百分之 60 的 CPU 功率而 Database2 需要百分之 20 的話，管理員可以藉由增加配置給 db1 的 cpu.shares 數目，以指定系統提供至少這麼多的資源 (假設應用程式提出要求)：

# limadm set cpu.shares=3 db1

現在 databases 群組中有四個尚未使用的配分；db1 有三個，而 db2 有一個。這個變更會在執行上述指令之後立即受到影響。當 lnode db1 (Database1) 實際收到多於其應得的百分之 60 之機器資源之前，會有一段適應期，因為 Solaris Resource Manager 必須在一段時間內平均用量。不過視消減全球參數而定，此時期不會持續太久。

要隨時監控此活動，請在分開的視窗當中使用 liminfo (請參見 一個典型的應用程式伺服器) 及 srmstat 指令。請注意，srmstat 會提供一個定期更新的顯示畫面。欲知更多有關 srmstat 的額外資訊，請參見 srmstat(1SRM)。

現在您有一部執行兩個資料庫應用程式的機器，其中一個收到百分之 75 的資源，而另一個則收到百分之 25。請記住，root 是最高階的群組標頭使用者。因此作為 root 執行的處理，如果想要的話，便可取得整個系統的存取權。因此，應該建立額外的 lnode 以便執行備份、常駐程式及其他指令集，而讓 root 處理不可能佔用整個機器的資源。這是如依照傳統方式來執行的話很可能會發生的狀況。

新增一個計算批次應用程式使用者

本範例將對下列指令加以介紹：

srmkill

殺掉附加至一個 lnode 所有使用中的處理

財務部門擁有資料庫系統，但 Joe 是一位工程部的使用者，必須執行一個計算批次工作，而且想要在下班時間系統通常被閑置時，利用財務部的機器來工作。財務部認為 Joe 工作的重要性不如資料庫，因此同意只要他的工作不會干擾系統的主要工作就可以進行。要實施這個政策，必須新增一個群組 (batch) 至 lnode 資料庫，並且將 Joe 新增至伺服器 lnode 階層的新 batch 群組中：

# limadm set cpu.shares=20 databases
# limadm set cpu.shares=1 batch
# limadm set cpu.shares=1 joe
# limadm set sgroup=batch joe

圖 10-2 新增一個計算批次應用程式

此指令序列會變更配分的配置，使 databases 群組擁有 20 個配分，而 batch 群組則只有一個配分。這會指定 batch 群組的成員 (只有 Joe 一人) 會使用至少 1/21 的機器，這時 databases 群組必須正在使用中。 databases 群組收到 20/21 或百分之 95.2 ，遠比先前決定足夠處理資料庫工作的 60% + 20% = 80% 還多。如果 databases 不需要其完全的配置資源，Joe 就會收到較其百分之 4.8 的配置還多的資源。如果 databases 處於完全停用中的狀態，則 Joe 的配置可能會達到百分之 100。當配置給 databases 尚未使用的配分數目從 1 增為 20 時，沒有必要對 db1 和 db2 配分的配置做任何變更。在 databases 群組之中，仍然有四個尚未使用的配分，依照 3:1 的比率配置。排程樹的不同層級彼此是互相獨立的，重要的是同層群組之間的配分比率。

儘管有了這些保證，財務部還是要進一步確保 Joe 無法在日間顛峰工作時間登入系統。要這麼做，就必須對 batch 群組加以某種登入控制。因為這些控制要視一天的時間而定，請執行一個只允許 batch 群組在特定時間登入的指令集。舉例來說，您可以採用 crontab 項目來實行這個限制，例如：

0 6 * * * /usr/srm/bin/limadm set flag.nologin=set batch 
0 18 * * * /usr/srm/bin/limadm set flag.nologin=clear batch

在早晨 6 時，batch 沒有登錄的許可，爾在 18 時（下午 6 時），限制被移除。

您也可以實行更為嚴厲的政策，請新增另一行至 crontab 項目中：

01 6 * * * /usr/srm/bin/srmkill joe

這會使用 srmkill(1MSRM) 指令在上午 6:01 時殺掉任何附加至 lnode Joe 的處理。如果工作所需的唯一資源都由 Solaris Resource Manager 所控制的話，就不需要這麼做。此動作只有在 Joe 的工作有可能會佔用其他資源因而影響到正常工作時才派得上用場。例如一項握有關鍵性資料庫鎖定或是掌控一個 I/O 管道的重要工作。

那麼現在 Joe 就只能在夜間登入並且執行他的工作。因為 Joe (和整個 batch 群組) 比其他應用程式所得的配分要少許多，他的應用程式將會以少於百分之 5 的機器資源來執行。同樣地，可以使用 nice(1) 來降低附加至此工作的處理優先順序，使它以低於其他擁有相等 Solaris Resource Manager 配分的工作之順序來執行。

這時財務部已經確保了其資料庫應用程式對此系統有足夠的存取權，並且不會互相影響到對方的工作。財務部同時也在滿足 Joe 的隔夜批次處理工作量的同時，確保了他的工作也不會干擾到與該部門任務息息相關的重要處理。

放置一個網路 (Web) 前端處理

假設您決定要在 Database1 之上放置一個網路前端處理，但又要限制這個應用程式一次不超過 10 位使用者。請使用處理限制功能來達成此目的。

首先，建立一個稱為 ws1 的新 lnode。藉由啟動 ws1 lnode 之下的 Webserver 應用程式，您便可控制可用的處理數目，因此而控制使用中的 http 作業階段數目。

圖 10-3 新增一個網路前端處理

因為 Webserver 是 Database1 應用程式的一部份，您可以賦予它一個 db1 lnode 的配分，並且允許它與 Database1 共享資源。配置百分之 60 的電腦資源給 Webserver 並且配置百分之 40 給 Database1 應用程式本身：

# limadm set cpu.shares=6 ws1
# limadm set sgroup=db1 ws1
# limadm set cpu.myshares=4 db1
# srmuser ws1 /etc/bin/Webserver1/init.webserver 

最後一行文字會啟動 Webserver 並且對 ws1 lnode 計費應用程式。請注意，對 Database1 來說，cpu.myshares 配置為 4，因而將 db1 與其子處理 Webserver 相爭的配分比率設定為 4:6。

cpu.shares 會顯示一個階層中同層資源配置的比率，而 cpu.myshares 會顯示雙親正積極執行應用程式時，親子層級的資源配置比率。Solaris Resource Manager 會依照所有使用中的 lnode 在其各自層級之尚未使用的配分來配置資源比率，而此 '各自層級' 包括群組雙親及所有子的 my.shares 。

要控制 Webserver 可以執行的處理數目，請在 ws1 lnode 之上加以處理限制。範例中使用 20，因為通常一個 Webserver 查詢會生成 2 個處理，所以事實上會將使用中的 Webserver 查詢數目限制為 10 個：

# limadm set process.limit=20 ws1

現在另一個應用程式也被新增至排程樹當中，作為使用中 lnode 之下的一個節點。要在使用中的雙親及子 lnode 之間分配 CPU 資源，請使用 cpu.myshares 來將某部份的可用資源配置給雙親，以及某部份給子 lnode 。程序限制可用來限制一個 lnode 之上正使用中的作業階段的數目。

新增更多有特殊記憶體需求的使用者

此範例將實施資源控制機制 CPU 共享、處理限制及登入控制，並且會說明用來列印 lnode 與顯示使用中 lnode 的顯示工具。

srmadm

管理 Solaris Resource Manager

limreport

輸出有關選定使用者的資訊

limdaemon

指示常駐程式在達到任何限制時傳送訊息

另一位使用者 Sally，也要求晚間使用機器來執行她的應用程式。因為她的應用程式需要大量的 CPU，為了確保不影響到 Joe 的應用程式，就必須限制 Sally 對虛擬記憶體的使用，包括她的總用量以及"每次處理"的用量：

# limadm set memory.limit=50M sally
# limadm set memory.plimit=25M sally

圖 10-4 新增更多使用者

如果當 Sally 的應用程式試著超出其總虛擬記憶體限制或是處理記憶體的限制， limdaemon 指令就會透過主控台來通知 Sally 及系統管理員，告知他們已經超出限制範圍。

使用 limreport 指令來生成一份報告，說明誰在使用系統及其到目前為止的使用情況。最典型的 limreport 使用方法是隨時查看使用機器的人以及他們屬於使用者階層的何處：

% limreport 'flag.real' - uid sgroup lname cpu.shares cpu.usage |sort +1n +0n

limreport 有數個參數。在此範例中，核選「flag.real」（僅查看「真實」的 lnodes/UIDs）；破折號 ( -) 用於標示輸出格式應該是使用的預設最佳猜測，而「uid sgroup lname cpu.shares cpu.usage」清單標示 limreport 應該為將 flag.real 設定為 TRUE 的每一個 lnode 輸出這五個參數。輸出會被導入第二欄的 UNIX 主要排序以及第一欄的次要排序，作出一份簡單的報告，說明使用伺服器的人是誰。

任何擁有正確路徑及權限的人都可以使用 srmadm show 指令來隨時檢查 Solaris Resource Manager 的狀態。這會輸出 Solaris Resource Manager 及其主要的設置參數目前操作狀態的一份格式化報告。可以用來檢查 Solaris Resource Manager 以及所有的控制參數是否都在作用。它也顯示全域參數的值，例如消減率及內存 Solaris Resource Manager 資料的位置。

您可以在不啟用限制以及 CPU 排程的情況下執行 Solaris Resource Manager；這對於啟始、除錯以及 Solaris Resource Manager 產品的初始設置而言都很重要：

# srmadm set share=n:limits=n

跨部門共享一部機器

有另一個開發群組希望購買這部機器的升級 (更多處理機和記憶體)，以便交換系統閒置時的存取權。這樣一來兩個群組都會受益。如要進行設定，需再建立一個名為 development 的新群組，而且是在與 databases 和 batch 的相同級別上。配置給 development 百分之 33 的機器，因為原始系統上已經新增了百分之 50 的 CPU 功能及記憶體。

圖 10-5 共享一部機器，步驟 1

開發群組擁有上百位使用者。為避免涉及其資源的分配，請使用管理 Solaris Resource Manager 的旗標功能，好讓開發系統管理員能夠配置其資源。您可以依照雙方的同意來設定操作及開發層級的限制，然後各自設法控制機器屬於您自己的部份。

要為階層新增新的層級，請將群組 operations 新增為一個新的 lnode，並且將 batch 和 databases 的雙親群組變更為 operations：

# limadm set sgroup=operations batch databases

要設定管理旗標：

# limadm set flag.admin=set operations development

在一般狀況之下，所有的伺服器都必須執行常駐程式及備份處理，它們應被新增至另一個高階的 lnode。

請勿使用 root lnode，因為它沒有任何限制。

圖 10-6 共享一部機器，步驟 2

如例中所述，您可以使用 Solaris Resource Manager 來整合相同的機器上數種不同類型的使用者及應用程式。您可以明智地使用 CPU 配分控制、虛擬記憶體限制、處理限制及登入控制等功能，確保這些不同的應用程式只接收它們所需的資源。這些限制可以防止應用程式或使用者對任何其他的使用者或使用者群組的應用程式產生不良的影響。Solaris Resource Manager 支援某些簡單的報告製作工具，以讓使用者及系統管理員瞭解在任何一刻和一段時間之內所發生的實際狀況。報告生成的功能可以用來顯示應用程式及群組的資源分割利用，以達到功能規劃及計費目的。

一個典型的應用程式伺服器

這個輸出會在前一節範例最後 db1 的 liminfo 列表中顯示出來。鍵入：

# liminfo db1

會產生：

圖 10-7 liminfo 列表

本節剩餘的部份將說明圖 9-7 中所產生的 liminfo 輸出。請參閱 liminfo(1SRM) 及 srm(5SRM) 中有關下述欄位的其他資訊。

• 從 liminfo 指令輸出的前兩行結果與 lnode UID 及其在 lnode 樹中的位置有關：

登入名稱

登入名稱及初始 GID 來自與附加 lnode 的 UID 對應的密碼對映。每個 lnode 都與一個系統 UID 有關。建議您為每個 lnode 的 UID 建立一個系統帳號。此實例使用一個位置保留符號 UID 給 db1 的 Database1。

請注意，Solaris Resource Manager 之下的預設 PAM 設置會為任何登入時沒有 lnode 的使用者建立一個 lnode。根據預設值，由超級使用者或某個設置了 uselimadm 旗標的使用者建立的 lnode，在建立以使用者 srmother 的 lnode 作為其父節點，如不存在，就將 root lnode 作為父節點。一個 lnode 的雙親可以利用一般變更 lnode 屬性的指令 limadm 來加以變更。

Uid

附加至目前處理的 lnode UID 。一般而言，它應該和處理的真正 UID（登入的使用者）相同，不過在某些情況下（稍後會加以說明）可能會有所不同。

Gid

附加至目前處理的 lnode 的 GID。

R,Euid 和 R,Egid

目前處理的真正和有效的 UID 和 GID。它和標準系統 id(1M) 指令所提供的資訊相同。並不是只與 Solaris Resource Manager 有關，在此為了方便起見將它顯示出來。如果 liminfo 在顯示有關一個非預設（亦即以登入名稱或 UID 為一個引數而提供）使用者的資訊的話，便不會顯示下列欄位。

Sgroup (uid) [sgroup]

lnode 樹階層中雙親 lnode 的名稱及 UID。此處 root lnode 會是空白。許多 Solaris Resource Manager 的功能都取決於 lnode 在樹階層中的位置，因此使用者最好利用接續的方式，一直上溯雙親 lnode 回到樹形的 root。

• 在空行之後，liminfo 顯示的下三行文字即為與 CPU 排程有關的欄位。

Shares [cpu.shares]

這是配置給這個使用者 CPU 權利的配分數。它會直接與有同樣雙親 lnode 的其他使用者，以及雙親 lnode 本身的 Myshares 數值來做比較。管理員通常可能會將一個特定排程群組之內的所有使用者設定為相同的數值（賦予那些使用者相等的權利）。此數值通常會大於 1，所以管理員有機會可以在適當的時機減少特定的使用者配分。

Myshares [cpu.myshares]

如果這位使用者擁有作用中（有附加的處理）的子 lnode（若有其他 lnode 擁有這個使用者的一個 sgroup 數值的話)，才要使用這個值。這樣一來，此值便可賦予附加至此 lnode 的處理相對的 CPU 配分（與附加至其子 lnode 的 lnode 相較）。

Share

目前的使用者有權使用的計算式系統 CPU 資源百分比。當其他的使用者登入及登出時（或 lnode 成為作用中或未作用的），此值會跟著變更，因為計算只有包括作用中的使用者。目前使用者最近的用量不包括在計算當中。

E-share

這個使用者的有效配分（如果使用者和所有其他作用中的使用者都同時要求其配分時，此使用者會在短期間取得的系統 CPU 資源的實際百分比）。也可以比作 Solaris Resource Manager 目前將 CPU 資源設置給該 lnode 的意願。此值會隨著使用者使用（或不使用）CPU 資源的時間而變更。作用中但閑置的 lnode（附加的處理處於睡眠狀態）用量會比較低，因而擁有較高的有效配分值。相對地，積極地使用 CPU 的附加處理的使用者，其有效配分就可能非常地小。

Usage [cpu.usage]

用來決定排程優先順序的系統資源累積的用量。一般而言，這表示最近的 CPU 用量，不過也會同時考慮其他的參數。所用的混合參數可以利用 srmadm 指令來查看。此值會隨著時間呈倍數消減，因此 Solaris Resource Manager 最終會完全將資源用量完全"忘記"。消減率最能以其半減期來加以說明， srmadm 指令可以用來查看半減期。

Accrued usage [cpu.accrue]

這個衡量數值和 cpu.usage 的資源累積相同，只不過它是不會消減的。Solaris Resource Manager 並不直接使用它，但是可以被用來作為會計管理的目的。不像 usage，這個值代表群組內部所有 lnode 以及目前 lnode 的累計用量總數。

• 在第二個空行之後，liminfo 所顯示的下四行文字即為與虛擬記憶體有關的四個欄位：

Mem usage [memory.usage][memory.myusage]

為附加至此 lnode 所有處理的合併記憶體用量。

如果出現兩個以一個斜線 (/) 字元分開的數值，那麼此 lnode 就是一個群組標頭。第一個數值是整體排程群組的用量，而第二個數值則是目前的使用者用量。

Mem limit [memory.limit]

附加至此 lnode 及其成員（如果有的話）的所有處理可得的最大記憶體用量。也就是說，群組內所有處理，加上附加至群組標頭的處理的記憶體使用總合不得超出此數值。請注意此例中，零 (0) 數值代表沒有任何限制。

Proc mem limit [memory.plimit]

每次處理記憶體限制為附加至此 lnode 及其成員的任何單一處理最大記憶體用量。

Mem accrue [memory.accrue]

memory.accrue 數值是以每秒位元組為單位，而且可以指出一段時間內的整體記憶體資源情況為何。

Term usage [terminal.usage]

就目前用量計費的連線時間秒數。

Term accrue [terminal.accrue]

用量所使用的連線時間秒數。

Term limit [terminal.limit]

terminal.usage 屬性所允許的最大數值。如果為零，便沒有任何限制，除非受承繼的限制。

• 在第三個空行之後，liminfo 所顯示的下四行文字即為與使用者及處理有關的欄位：

Processes [process.usage][process.myusage]

附加至此 lnode 的處理數。請注意這是處理，不考慮一個處理中的線串。

如果出現兩個以斜線 (/) 字元分開的數值，那麼這個 lnode 便是一個群組標頭，第一個值是整個排程群組的使用狀況，而第二個值則單單只是目前使用者的使用狀況。

Process limit [process.limit]

允許被附加至此 lnode 及其成員的最大處理數。

Current logins [logins]

目前使用者以 Solaris Resource Manager 同時登入階段作業的數目。當一位使用者透過任何標準的系統登入機制（包括 login(1), rlogin(1)-等等）來登入，幾乎任何使用 PAM 進行辨證，並且建立一個 utmp(4) 項目)，此計數器會開始遞增。當階段作業結束時，計數便會遞減。

如果一位使用者的 flag.onelogin 旗標求值到 set，使用者只被允許一次單一的 Solaris Resource Manager 登入階段作業。

• 在第四個空行之後，liminfo 的下面四行文字會顯示下列欄位：

Last used [lastused]

此欄位顯示上一次作用中的 lnode。通常也這就是使用者上一次的登出。

Directory

使用者的主目錄 (來自密碼對映而非 Solaris Resource Manager 的項目會顯示在此以便參考)。

Name

db1 (finger) 資訊，通常就是使用者姓名（為了方便起見，在此顯示密碼映射中的項目而非 Solaris Resource Manager 項目）。

Shell

使用者的初始登入 shell（為了方便起見，在此顯示密碼映射中的項目而非 Solaris Resource Manager 項目）。

• 在五個空白線後，最後一條線 liminfo 顯示這欄位。

Flags

此處顯示求值到 lnode 中的 set 或 group 的旗標。每個旗標後都接著字尾字元，指明數值以及旗標的設定方式（例如，是否是完全來自此 lnode (+) 或是承繼的 (^)）。

在 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 時間的配分數量而定。