適用於 Solaris 2.6 的 Solaris Resource Manager 1.0 系統管理指南(SPARC 平台版)

Solaris Resource Manager 簡介

其主要組織目標

商業界通常要求 IT 機構控制成本並且保證企業應用程式的服務水準。資源管理提供數種程序,降低所有權的總成本,更準確地控制使用系統的人及方法,有時甚至可以同時符合兩種目標。

藉由使用 Solaris Resource Manager 軟體來分類與優先化資源的使用,管理員可以在離峰期間有效地利用保留的功能,減少對額外處理功能的需求。

Solaris Resource Manager 藉由系統來分別工作量,好讓系統管理員執行與管理單一系統之上的各類應用程式,而不是將整個具有最尖峰功能-的系統-分配給每個應用程式。傳統而言,確保可靠的服務以及回應時間最常見的方式是讓每個系統作為一個功能的主機。這個方法行得通,但是不斷擴張資料中心的系統卻是昂貴又難於管理。

資料中心管理者希望能夠在單一 UNIX 伺服器之上整合多重應用程式,以充分利用所有可用的資源。同時所有的使用者必須根據他們的服務層級及其工作的重要性來接收資源。

使用 Solaris Resource Manager 的時機

Solaris Resource Manager 可以提供各種情況之下的有效資源控制,包括伺服器整合,Internet 服務供應商 (ISP) 網路主機,管理擁有大量或多元性的使用者人口的網站,並且建立策略以確保重要的應用程式都能取得所需的回應時間。

Solaris Resource Manager 對在單一伺服器之上整合多重應用程式的環境來說,是一種理想的選擇。管理數個機器的成本和複雜度會促使系統管理者嘗試在可以繼續擴大的大型系統上整合應用程式。Solaris Resource Manager 可以輕易地達成這些規模經濟的考量。

舉例來說,一個單一SunTM 伺服器可以為各種不同的客戶機、傳訊/郵件服務、全球資訊網服務以及以任務為考量的資料庫應用程式提供應用程式、檔案以及列印服務。由於 Sun EnterpriseTM 伺服器包含 1 到 64 個處理機不等,一個伺服器可以設置為供數個部門共用或整個機構來使用。拿其他的伺服器整合方案來說,其發展、協定和生產環境都結合在一個單一的大型機器之上,例如 Sun Enterprise 10000 或是 Sun Enterprise 6500,而不是由三個個別的伺服器來負責。其他整合專案還是與單一機器或是多重資料交易站結合資料庫及應用程式伺服器。無論應用程式類型或設置為何,Solaris Resource Manager 有助於根據既定的策略,確保將系統資源配置給所有的使用者、應用程式及群組。重要的應用程式會受到保護,因為要保證它們取得所需的可得系統資源。

相同地,ISP 也可以利用 Solaris Resource Manager 來在單一機器上主持許多(也許上千個)網路伺服器。Solaris Resource Manager 允許管理員控制與每個網站有關的資源佔用,防止它們每一個因超出使用量而影響到其他的網站。Solaris Resource Manager 也能防止出錯的 CGI 指令集耗盡 CPU 資源,或防止使用者應用程式釋出所有可用的虛擬記憶體。過去 ISP 必須為每個客戶機指派一個專屬機器,造成極大的花費和麻煩。

Solaris Resource Manager 可以管理任何擁有大量使用者的系統資源。教育機構是這類網站一個很好的例子,作為一個大型而多樣化的使用者基礎。(事實上,Solaris Resource Manager 最早起源於雪梨和新南威爾斯大學所開發的 CPU 資源排程器。)每當出現許多類型的工作量時,Solaris Resource Manager 就可以被設置來優先考量某些特定的使用者。在大型的證券公司,交易商會不定期地需要快速存取權,以執行一個查詢或是一個計算動作。不過其他系統的使用者工作量則會比較持續性。 Solaris Resource Manager 可以保證交易商取得較大量的處理能力,確保他們得到所需的回應。

主要功能

Solaris Resource Manager 提供管理系統中各種重要資源佔用情況的功能,例如處理機時間、虛擬記憶體、處理計數、登入計數以及連結時間。Solaris Resource Manager 管理模式又新增了靈活度,可以在一個階層之間授權管理權限,資料中心的員工便不需要參與群組內部的管理交易。此外,Solaris Resource Manager 提供搜集資源使用資料的機制,可被應用於功能規劃或是收費等的目的。

作業系統最基本的工作之一就是仲裁哪一項處理可以取得系統資源的存取權。內定的 Solaris 分時排程試圖讓每個處理存取大約相等的系統資源。沒有實體記憶體資源的處理會受到對存取的限制,因為這些處理不會被允許執行;有等候中 I/O 要求的處理也會因為被阻礙而受到存取限制。

這種體系是大多數現代作業系統的基礎,比較適合"人人公平存取"的組織策略。然而,其他的策略可能就需要實施更加精密的機制才行。例如製造部門擁有一個經常沒有完全利用的大型系統,因為不斷上上下下的季節性需求。同時工程部門幾乎總是需要更多的電腦計算循環。雖然不充分利用大型機器的資源是件非常浪費的事,傳統上來說要與工程部門共用製造系統是非常困難的。簡單的排程策略無法指示作業系統如何分辨製造部門的使用者比相同系統上的工程部門還要來得重要。如果製造有一項需要佔用系統資源的百分之 75 的重要工作,此工作在其他所有工作只要求百分之 25 的系統或更少的情況下就可以順利進行。然而,如果一個工程任務需要百分之 50 的系統,那麼這項重要的製造工作就可能無法取得保持進度所需的資源,因為系統會為了公平而嘗試滿足兩種工作的需求。

假定管理員決定製造部門的普通處理需求可以利用百分之 80 的機器功率來達成。系統管理員可以使用 Solaris Resource Manager 來指定製造部門的使用者,只要提出要求的話,就可以取得多達百分之 85 的系統處理能力;而排程器會將剩餘的資源分配給其他任何使用者。另一種極端但有效的設置可以指定製造部門使用者於必要時取得百分之百的系統,而當製造部門確實需要整個系統的時候完全不讓其他群組的處理執行。

Solaris Resource Manager 提供一種新的 CPU 排程類別,取代標準的分時排程器。這個模組稱為 SHR 排程器類別,採行一種稱為公平分享的排程器。"公平"這個字有一點誤導,因為實際上是系統管理員負責決定什麼才是 "公平"。在上面一例中,"公平"指的是製造部門可以取得百分之百的系統。SHR 排程器負責根據管理概要檔中的規劃來分配資源。

Solaris Resource Manager 可以維護資源取用和相關限制的資料庫。

SHR 排程器會考慮資源保證的管理規格。它可以管理可更新的(例如 CPU 時間)或固定的(例如登入計數)資源。

其他 Solaris Resource Manager 模組進行各種資源的佔用情況限制。例如連結時間和使用者登入計數是藉由一個可插式辨證模組 (PAM) 來管理。PAM 模組會在每一次有一個使用者嘗試登入時向 Solaris Resource Manager 資料庫求證。一旦系統辨證該使用者(一般是核對其密碼),就會核對使用者的連結時間和目前登入的計數是否符合限制規定。如果超過其中一項限制,登入就會被拒。

與其他 Solaris 資源控制功能的關係

Solaris 作業環境包括數種其他功能,可以提供對特定類型資源的控制。某些功能,如即時排程、nice(1)、配額以及處理機群集等,都是基本 Solaris 作業系統的一部分。

頻寬配置器是不附屬於產品的一種套裝軟體,動態系統領域是 Sun Enterprise 10000 系統平台的功能,而動態重新設置則是 Sun Enterprise 系統平台的一種功能。

所有這些元件都提供各種的資源管理,但是它們或多或少和 Solaris Resource Manager 的功能不同。

標準的 Solaris 作業系統都是使用分時 (TS) 排程類別來進行最一般性的工作。不過它也為擁有充分權限的使用者提供即時 (RT) 排程的功能。RT 排程類別採行一種非常不同的(而且故意強調其重要性)排程策略以確保特定的工作量或處理總是可以立即存取處理機。Solaris Resource Manager 可以和 RT 排程類別同時存在於相同的系統之上,但是它不能控制任何以 RT 類別執行的處理。Solaris Resource Manager 公平分享排程器只能管理那些不以 RT 排程類別執行的處理的 CPU 時間資源。例如,在一個擁有四個處理機的系統上,單一線串處理可以佔用一整個處理機;事實上如果提出要求的處理受到 CPU 限制的話也會如此。如果這個系統也執行 Solaris Resource Manager,經常性的使用者處理會爭相使用被即時處理所佔用的三個 CPU。(請注意,RT 處理可能不會持續使用 CPU。當它被閑置時,Solaris Resource Manager 會控制全部四個處理機。)

nice(1) 指令允許使用者操控其執行優先順序。沒有超級使用者權限,這個指令只能允許使用者降低其優先順序。這個有時會是一種有用的功能(例如當一個使用者從其互動式登入階段作業開始一項低優先順序的批次工作),但是它有賴於使用者採取合作態度。Solaris Resource Manager 仍然可以在使用者不合作的情況下強制執行其管理策略。

管理員可以利用 Solaris 檔案系統的配額機制來限制個別使用者的磁碟佔用情況。這種功能和 Solaris Resource Manager 並無直接關係。

Solaris 2.6 中新增了處理機群集。管理員可以利用這個特性來將多處理機系統分為邏輯群組,並且讓使用者啟動這些群組內的處理。其好處在於一個處理機群集之內執行的工作量不受任何其他的處理機群集中 CPU 活動的干擾。在某一方面而言,這個功能和 Solaris Resource Manager 類似,不過這兩種特點是基於完全不同的基礎之上。處理機群集只控制 CPU 操作。此種控制屬於一種不太精確的硬體層級,因為處理機一次可以完全屬於一個處理機群集。特別是在比較小型的系統上,精確度可能會比較差﹕在一個擁有四個處理機的系統上,可以指派的最基本的資源量是系統的百分之 25。

Solaris Resource Manager 擁有比較精確的控制;每位使用者都可以配置到一部分的系統。可以依照非常精確的標準來分配分享的分,而且排程器也可據此以配置資源。舉例來說,如果賦予 50 個分,而一位使用者擁有其中的 40 個,則該使用者會取得百分之 40 / 50 = 80 的資源。同樣地,如果總共賦予 67 個分,一位擁有 57 個分的使用者就會取得百分之 85 的資源。此外,Solaris Resource Manager 還可以控制 CPU 之外的資源。

Sun Enterprise 10000 有一個稱為動態系統領域的特點,可以讓管理員邏輯式地將單一系統機架分為一或多個獨立系統,每個都執行其自己的 Solaris 版本。例如,一個在八個系統轉接板上擁有三十二個 CPU 的系統,可以作為一個擁有十六個 CPU 的系統,以及兩個分別擁有八個 CPU 的系統來執行。每一個系統上分別有三個 Solaris 版本。動態系統領域功能可以讓經過控制的資源移動進出每個 Solaris 執行影像,因此建立一個較為不精確的機制來管理實體資源。(領域內部配置最基本的單位是一整個系統轉接板。)Solaris Resource Manager 和動態系統領域類似之處,在於它提供管理員配置資源的機制,但是方法卻大不相同。Solaris Resource Manager 在一個單一的 Solaris 實例內執行,並且對系統資源進行高精確度的管理控制。而動態系統領域則將一件硬體分為多個 Solaris 的實例;它具有管理同一個 Sun Enterprise 10000 框架中執行的各個 Solaris 實例之間資源轉移的工具。Solaris Resource Manager 是獨立在動態系統領域之外,但又可以用來與之配合使用。Solaris Resource Manager 可以在一個 Sun Enterprise 10000 系統之內的每個 Solaris 實例執行。

Sun Enterprise 伺服器的動態重新設置功能可以讓使用者動態式地新增與刪除系統轉接板,其中包含如處理機、記憶體和 IO 裝置等硬體資源。記憶體之上的動態再設置操作無法對於 Solaris Resource Manager 記憶體限制檢查產生任何影響。

頻寬配置器屬於一種獨立式的套裝模組,可以與 Solaris kernel 配合使用來限制網路頻寬的佔用情況。頻寬配置器是一種資源管理軟體,可以應用於不同類別的資源。Solaris Resource Manager 及頻寬配置器有不同而分立的管理領域﹕Solaris Resource Manager 是在一個每位-使用者或每位-應用程式的基礎上操作的,而頻寬配置器則是在一個每個-連結埠、每次-服務或每個-協定的基礎之上來進行管理。

Solaris Resource Manager 與類似產品間的不同之處

Solaris Resource Manager 和系統中所含的許多其他軟體元件有關,但是它並不能取代其中任何一種。正如上述所說,頻寬配置器可以管理一種不同的資源。雖然 Solaris Resource Manager 可以被視為具有系統管理與監控功能,它仍舊不像 Sun Enterprise SyMONTM 2.0 一樣可以作為一種系統監視器。Solaris Resource Manager 也不是一種真正的功能規劃工具﹕它具有管理員管理功能,而且其會計功能可以限制管理人員可能用來進行趨勢分析的使用記錄,但它不能執行傳統式的功能規劃。Solaris Resource Manager 也不是一種工作排程器;它可以控制一個處理在其主機系統之上的執行方式,但不管其執行時間或地點。最後,因為 Solaris Resource Manager 只能在單一系統之上操作,也不是採行群集成員之間負載平衡的良好機制。不過 Solaris Resource Manager 很適於用來有效管理群集中每個成員的個別工作量。例如,可以安排將高可得性群集中一個當機的成員上的工作優先提到一個待命的成員上執行的背景工作量之前。