test

安裝與管理 Solaris Container Manager 3.6.1

第 3 章 關於容器和啟動產品

本章說明容器和專案，以及如何啟動產品。

本章討論下列主題︰

容器簡介

專案是一個與主機建立關聯的容器。專案可協助組織與管理實體系統資源集合。在您實作完整伺服器合併規劃時，專案是很有用的。專案可提供下列功能：

在安裝和設定軟體之後，就會有數個預設專案供您立即使用。您也可以使用引導您進行此程序的精靈來建立自己的專案。每個專案都會與容器建立關聯。此容器可以再次用來建立新專案。專案提供了下列優點：

GUI 是以瀏覽器為基礎，而且還提供了三種管理檢視 (標籤)：一個是從主機來看、一個是從容器來看，而最後一個則是用於已開啟警報。您可以透過建立群組並選取群組應包括的元素來進一步組織主機檢視和容器檢視。

此外，在容器內執行的程序和正在使用的資源可透過此軟體立即進行檢查。您也可以使用數個圖形選項來協助估計每個容器或主機的資源使用情況層級，還可匯出資料到檔案。這些功能可讓您監視並重新估計資源使用量以進行適當的調整。

有了此軟體的警報功能，您就可以在容器的資源使用情況達到設定的臨界值時收到電子郵件通知。警報圖示也可以在主機和容器的 GUI 中看見。

資源變更工作功能可讓您使用一個請求在一個或多個容器上排程目前資源界限的變更。精靈會引導您進行建立或修改資源變更工作所需的步驟。

關於容器特性

容器具有下列特性：

您指定給容器的名稱是永久且不可變更的。專案名稱也是永久的。容器的其他識別資訊則可以變更。

容器會由此軟體儲存，而且可重複使用直到容器被刪除為止。專案為已與主機建立關聯的容器。若專案已與主機建立關聯，而且也設好其資源保留，專案即為使用中。

因為具有相同定義與資源保留的多個專案可以同時在不同的主機上使用，所以容器可以透過資料中心方便地管理專案。在儲存容器之後，就可以隨時在任何適合的主機上用來啟動專案。因此，容器可以用來當作建立新專案的範本。

容器可以當作多個專案的範本。容器會在中心位置儲存專案的一般特性。專案的一般特性如下：

其他特性 (例如 CPU 共用和記憶體限制) 是啟動專案之主機所專用的。在 Solaris Container Manager 3.6，此 (集中式儲存的) 一般特性組即稱為容器。在特定主機上啟動容器時，容器會建立為 Solaris 專案實例，並且儲存在 /etc/project。

例如，公司想要為其電子郵件應用程式設定容器。專案的一般特性可以為：

在特定主機上啟動容器時，公司會為專案建立實例，而且可以立即指定資源儲存池、CPU 共用和記憶體限制。

圖 3–1 容器和專案

容器作為建立多個專案的範本

您可以使用容器在區域和主機間建立多個專案。例如，若您使用單一容器在三個不同的主機上建立三個使用中專案，您可以有一個容器，並在該容器中有三個專案。變更容器中的基本資訊也會變更以該容器為基礎的所有專案。

「專案建立」精靈可讓您選擇建立要在完成所有步驟後才啟動的專案。同時會建立容器，而且其名稱會儲存在 GUI。您也可以選擇只建立容器，並稍後再透過引導您進行此程序的精靈來啟動專案。

若為容器，您可以使用 GUI 來執行下列作業：

若為專案，您可以使用 GUI 執行下列作業：

專案狀態

專案不會實際強制執行您為應用程式所設的資源使用量界限。而是在提供最小 CPU 保留和記憶體容量並啟動專案後，由 Solaris 核心開始強制這些界限。在使用專案之前，您必須知道專案狀態的更多相關資訊。專案可以處於下列三種狀態之一：已定義、使用中和非使用中。

圖 3–2 專案狀態

顯示專案狀態的圖例。四週的文字說明了內容。

專案在其使用期限會在這些狀態間變換。

容器和專案

當專案本身尚未完全形成時，容器會在初始階段建立。每個專案都必須有一個獨特的名稱，而且可以無限次儲存在資料庫中。

圖 3–2 顯示容器在與主機建立關聯後，專案變成使用中狀態。非使用中專案在被關閉且不再與主機建立關聯後，會變回已定義狀態。

專案啟動

使專案變成使用中的首要步驟即是將其容器與一個主機建立關聯。第二個步驟為設定資源界限，即指定專案的最小 CPU 保留和記憶體容量。專案必須與可支援這些資源界限的主機建立關聯。使用中專案也可被視為已部署，即專案已被推出並常駐於主機。

在使用「新專案」精靈建立以應用程式為基礎的專案時，可提供識別與應用程式相關的符合表示式。然後，與符合表示式對應的所有程序會自動移至此容器之下。在專案啟動時，會在與容器建立關聯的主機上建立/etc/project 資料庫中的項目。同樣地，相符的程序之後也會移到容器的專案名稱之下。在移動程序之後，會收集所有的資源使用情況資料，並儲存以供專案使用。

非使用中專案

關閉專案時，就不再強制執行資源界限。已關閉的專案會變成非使用中狀態，並從主機的 /etc/project 檔中刪除。在非使用中狀態時，專案仍然存在於軟體的資料庫中，擱置以供日後啟動。在重新啟動非使用中專案後，會再次強制容器的資源界限。

所有在專案使用時與專案資源使用相關的收集資料會保留在資料庫中。在關閉專案後，您仍然可以請求非使用中專案的使用情況報告，最多 30 天。

Container Manager GUI

Container Manager 軟體並不支援 Solaris 軟體資源管理中的標準指令行指令。您應該從 Container Manager 圖形化使用者介面 (GUI) 來管理容器。GUI 是從 Java Web 主控台由瀏覽器啟動。可支援下列瀏覽器：

Procedure啟動 Container Manager GUI

步驟

  1. 若您的 UNIX 使用者 ID 沒有出現在 /var/opt/SUNWsymon/cfg/esusers 檔，請建立此項目。

    您還必須指定給 esadm 或 esdomadm 群組。

    如需關於建立項目和指定給群組的指示，請參閱「Sun Management Center 3.6 安裝和配置指南」的「設定使用者」。

  2. 啟動瀏覽器。

    如需支援的瀏覽器清單，請參閱 Container Manager GUI。

  3. 要進入 Container Manager GUI，請輸入：


    https://sunmc-server_machine_name:6789/containers

    會顯示 Java Web Console 登入頁面。

    圖 3–3 Java Web Console 登入頁面

    Java Web Console 登入頁面有三個欄位：伺服器名稱、使用者名稱和密碼。

    若未顯示登入頁面，您可能需要重新啟動 Java Web Console。請參閱重新啟動 Java Web Console 以取得說明。

    提示 –

    若已進入主控台頁面，請按一下 [系統] 一區下的 Solaris Container Manager 3.6.1 連結便可存取 GUI。

  4. 使用您的 UNIX 使用者 ID 和密碼登入 Java Web Console。

    之後會出現 Container Manager GUI。螢幕包含三個標籤：主機、容器和開啟的警報。

    圖 3–4 Container Manager 主頁面

    Container Manager 主頁面包含三個標籤：主機、容器、開啟的警報。

Procedure重新啟動 Java Web Console

若您無法存取 Java Web Console，請使用此指令行以將其重新啟動。

步驟

    以超級使用者身份 (su -) 輸入下列指令以重新啟動 Java Web Console：


    # /usr/sbin/smcwebserver restart

Container Manager GUI 標籤

下表提供了關於出現在 Container Manager GUI 右側窗格的標籤資訊。

表 3–1 Container Manager GUI 標籤

定位點(B) 

標籤名稱 

內容 

主機 (檢視) 

內容 

提供關於選取主機上資源儲存池的資訊。 
 

特性 

提供關於選取主機、區域、專案或資源儲存池的特性資訊。 
 

使用情況 

提供關於主機、區域、專案或資源儲存池的每日、每週或每月資源使用情況資訊。還可提供使用中專案的即時使用情況資料。已安裝效能報告管理程式軟體時才能看見此標籤。 
 

專案 

提供關於與主機建立關聯的專案資訊。 
 

區域 

提供關於與主機建立關聯的區域資訊。 

容器 (檢視) 

內容 

提供專案相關資訊。 
 

特性 

提供關於選取主機、容器、專案或資源儲存池的特性資訊。 
 

使用情況 

提供關於主機、區域、專案或資源儲存池的每日、每週或每月資源使用情況資訊。還可提供使用中專案的即時使用情況資料。已安裝效能報告管理程式軟體時才能看見此標籤。 
 

工作 (資源變更工作) 

提供已排程資源變更工作的相關資訊。您也可以從此標籤建立新資源變更工作。注意，預設容器無法與資源變更工作建立關聯。 

開啟的警報 

 

提供關於已開啟警報的資訊，包括嚴重性、訊息、受管理物件、開始時間和確認。 

資源儲存池 (向下擷取) 

內容 

提供關於選取資源儲存池上的區域資訊。 
 

特性 

提供關於選取資源儲存池上的特性資訊。 
 

使用情況 

提供關於資源儲存池的每日、每週或每月的資源使用情況資訊。已安裝效能報告管理程式軟體時才能看見此標籤。 
 

專案 

提供關於與選取資源儲存池建立關聯的專案資訊。 

區域 (向下擷取) 

內容 

提供關於選取區域上的專案資訊。 
 

特性 

提供關於選取區域的特性資訊。 
 

使用情況 

提供關於區域的每日、每週或每月的資源使用情況資訊。已安裝效能報告管理程式軟體時才能看見此標籤。 

專案 (向下擷取) 

特性 

提供關於選取專案的特性資訊。 
 

使用情況 

提供關於專案的每日、每週或每月的資源使用情況資訊。已安裝效能報告管理程式軟體時才能看見此標籤。 
 

程序 

提供關於選取專案的程序資訊。 
 

警報臨界值 

用來設定或移除警報臨界值。 

[主機] 檢視

[主機] 檢視會從主機方面組織資訊。您正在管理的所有代理程式機器會出現在瀏覽視窗中。當您按一下主機名稱旁的展開三角形符號，就會顯示每個主機可用的資源儲存池。您也可以從此檢視管理與主機建立關聯的容器。

已安裝此軟體的所有代理程式主機會被自動探索並新增到 [主機] 檢視。此檢視是從瀏覽視窗的左側標籤存取。探索到的所有代理程式主機原來是位於名為「Hosts」的預設群組之下。您可以藉由建立新群組並將主機移到相關群組來進一步組織此檢視。

備註 –

只有屬於 Sun Management Center 伺服器環境一部分和已安裝 Solaris Container Manager 3.6 的那些代理程式機器才會載入 [主機] 檢視。關於伺服器環境的更多資訊，請參閱「Sun Management Center 3.6.1 使用者指南」中的「Sun Management Center 架構」。

表 3–1 列出可在 [主機] 檢視看到的標籤和資訊。

[專案] 表中列出了與主機建立關聯之每個專案實例的相關資訊。

下圖顯示 [主機] 檢視和與預設池建立關聯的專案表。

圖 3–5 範例：顯示專案表的 [主機] 檢視

[主機] 檢視中的專案表螢幕擷取。四週的文字說明了內容。

[專案] 表提供了關於每個專案的資訊，詳細說明每列的一個專案。[專案] 表提供下列資料：

專案名稱

專案的名稱

容器名稱

容器的名稱。

狀況

專案的狀態：使用中和非使用中

資源儲存池名稱

專案連結的資源儲存池

區域名稱

專案所在的區域名稱若為 Solaris 8 和 Solaris 9 主機，區域名稱一定是全域名稱。

CPU 保留 (CPU 共用)

專案的最小 CPU 共用組

CPU 使用率 (CPU)

專案正在使用的 CPU 量

記憶體容量 (MB)

記憶體容量上限 (以 MB 為單位)

記憶體使用率 (MB)

專案使用的記憶體，以 MB 為單位

共用記憶體 (MB)

允許可由在此專案內執行之程序所使用的記憶體總量，以 MB 為單位

[資源儲存池] 表提供了每個資源儲存池的相關資訊。[資源儲存池] 表提供下列資料：

資源儲存池名稱

資源儲存區名稱

目前的 CPU

目前為資源儲存池所設的 CPU 數量

未保留的 CPU 共用

未指定給資源儲存池中的區域或專案的 CPU 共用

排程程式

為資源儲存池所設的排程程式：時間共用排程程式或公平公用排程程式

CPU 共用

為資源儲存池所設的 CPU 共用

最小 CPU 保留

為資源儲存池所設的最小 CPU 數量

最大 CPU 保留

為資源儲存池所設的最大 CPU 數量

[區域] 表提供了每個區域的相關資訊。[區域] 表提供下列資料：

區域名稱

區域名稱

區域狀態

區域的狀態：已配置、未完成、已安裝、就緒、執行中、關機或當機

區域主機名稱

作為虛擬主機之區域的唯一名稱

區域路徑

從 root (/) 目錄開始的絕對路徑

IP 位址

區域的 IP 位址

專案 CPU 共用

分配給區域中專案的 CPU 共用數量

未保留的 CPU 共用

可分配給與此區域建立關聯之專案的 CPU 共用數量

保留的 CPU 共用

已分配到資源儲存池中此區域的 CPU 共用數量

資源儲存池

區域的資源儲存池

容器檢視

[容器] 檢視會從容器方面組織資訊。所有的容器和專案會出現在瀏覽視窗中。因為容器可重複用來建立新專案，所以您可以立即從此檢視存取容器和執行其他管理作業。

在完成安裝和設定之後， [容器] 檢視會自動新增「Containers」群組為預設群組。您可從 [容器] 檢視管理容器。

下圖顯示 [容器] 檢視。

圖 3–6 範例：顯示與預設容器建立關聯的 [容器] 檢視

[容器] 檢視的螢幕擷取。四週的文字說明了內容。

表 3–1 列出 [容器] 檢視中可用的資訊。

使用群組組織主機和容器

[主機] 檢視包含預設群組「Hosts」。在安裝此軟體後探索到的所有主機都會被置於此群組。同樣地， [容器] 檢視也具有一個預設群組「Default」，內含了所有預設的主機容器。您可以在每個檢視建立其他群組來組織主機和容器。

您也許可以使用群組來組織存放在資料中心的十個或數百個系統。例如，您可以將位置相同的主機放在一個群組。您可以將相同客戶 (內部或外部) 或部門擁有的容器放在一個群組中。同樣地，您可以將具有相似應用程式的容器放在一個群組中。

Procedure建立容器群組或主機群組

步驟

  1. 若 Container Manager GUI 尚未開啟，請依啟動 Container Manager GUI 中所述來進行存取。

  2. 從瀏覽視窗選擇適當的檢視。

    • 若為新的容器群組，請選擇 [容器] 檢視。[容器] 表會顯示在右側窗格中。

    • 若為新的主機群組，請選擇 [主機] 檢視。[主機和群組] 表會顯示在右側窗格中。

  3. 按一下 [新群組] 按鈕。

    會出現一個對話方塊。

  4. 提供群組的名稱，然後按一下 [確定]。

    名稱不得超過 32 個字元。

    新群組會出現在選取檢視中。

Procedure將容器或主機移到不同的群組

步驟

  1. 若 Container Manager GUI 尚未開啟，請依啟動 Container Manager GUI 中所述來進行存取。

  2. 從瀏覽視窗選擇適當的檢視。

    • 若要將容器移到不同的群組，請選擇 [容器] 檢視。[容器] 表會顯示在右側窗格中。

    • 若要將主機移到不同的群組，請選擇 [主機] 檢視。[主機和群組] 表會顯示在右側窗格中。

  3. 若要啟用表格中的 [移動] 按鈕，請選擇要移動之容器或主機的核取方塊。

  4. 在右側窗格中，按一下 [移動] 標籤。

    對話方塊會列出可用的群組。

  5. 選擇容器或主機要移動到的目標群組。

  6. 按一下 [確定] 。

    容器或主機會移動到選取群組。

預設容器

在設定軟體之後， [容器] 檢視會初始載入一個群組「Default」。此群組擁有下列在執行 Solaris 9 或 Solaris 10 作業系統 (OS) 之主機上的五個預設容器：

這五個預設容器 在 /etc/project 檔中都具有對應的項目。這五個項目是對應到 default、noproject、user.root、system 和 group.staff。

備註 –

在執行 Solaris 8 發行版本的主機上，具有群組成員的使用者 (Users with Group Staff (group.staff)) 容器不存在。或者，預設的容器是相同的。

圖 3–7 範例：顯示容器的系統容器群組

顯示內容的系統容器群組螢幕擷取。四週的文字說明了內容。

每個預設容器是處於使用中狀態，而且界限是設為 1 最小 CPU 保留 (CPU 共用) 和無記憶體容量。預設容器一定是與主機的預設資源儲存池 (pool_default) 連結。若已安裝效能報告管理程式，您就可以監視資源使用情況，並在每個預設容器上執行報告。

這些預設容器無法被關閉、編輯或刪除。因此每個容器被標示為「唯讀」。

每個 UNIX 使用者會被指定給一個預設專案，而且會對應指定給一個預設容器。預設容器初始會擁有在系統上執行的所有程序。在建立專案時，會從對應的預設容器將程序移到您建立的專案。

關於容器建立

每個專案會以容器啟動。視您在建立專案期間選取的專案類型而定，專案可以是三種類型其中之一。專案類型決定了追蹤程序的方法。

專案類型

在建立新容器時，您必須選擇專案類型。專案是一種相關工作的全網路管理識別碼 (ID)。在容器執行的所有程序都具有相同的專案 ID，而且容器會利用專案 ID 來追蹤使用的資源。容器類型是以建立容器時選取的專案類型為主。

每個容器都具有一個專案名稱，而該名稱會永久成為其資訊的一部分。在主機上啟動容器時，專案名稱會新增到該主機的 /etc/project 檔中。只要容器仍在該主機上使用，就會保留這個項目。

您無法同時在主機上讓兩個具有相同專案名稱的專案處於使用中。這是因為在容器執行的程序是以專案 ID 來追蹤，所以每個主機上的專案名稱都必須是唯一的。

在建立以使用者為基礎和以群組為基礎的專案時，使用者或群組名稱會變成專案名稱的一部分。若為以使用者為基礎的容器，專案名稱就會變成「使用者.使用者名稱」。若為以群組為基礎的容器，專案名稱就會變成「群組.群組名稱」。因此，在建立以使用者為基礎或以群組為基礎的專案時，您無法使用與預設容器的 /etc/project 項目中相同的使用者名稱或群組名稱。如需更多資訊，請參閱預設容器。

在建立以應用程式為基礎的容器時，您會提供選取的專案名稱。「專案建立」精靈會接受不同的以應用程式為基礎之專案使用相同的專案名稱。但是具有相同專案名稱的這兩個以應用程式為基礎之專案不能同時在相同的主機上使用。僅在您想要在不同主機上啟動這些容器時，才在建立以應用程式為基礎的專案時重複使用專案名稱。若您嘗試在已啟動具有第一個相同專案名稱之專案的主機上啟動第二個專案，此專案的啟動則會失敗。

下表提供可用之三種專案類型的詳細資訊，其會依選擇之不同而變更。

表 3–2 專案類型詳細資訊

專案類型 

作業系統版本 

詳細資訊 

以使用者為基礎 

Solaris 8 

Solaris 8 發行版本中唯一支援的專案類型。 

/etc/project 檔中的專案名稱會變成「使用者..使用者名稱」。專案會變成使用者的主要預設專案。

 

Solaris 9 和 Solaris 10 

/etc/project 檔中的專案名稱會變成「使用者.使用者名稱」，與可加入此專案的 UNIX 使用者清單。

有效格式為 username。

以群組為基礎 

Solaris 9 和 Solaris 10 

/etc/project 檔中的專案名稱會變成「群組.群組名稱」。

有效格式為 groupname。

以應用程式為基礎 

Solaris 9 和 Solaris 10 

專案名稱可以是應用程式名稱或其他任一選取的名稱。提供的名稱會新增到 /etc/project 檔。

可提供符合表示式以自動將符合的程序移到專案名稱。此表示式是有區分大小寫的。 

必須提供程序目前在其下執行的對應 username 或 groupname。

關於建立資源保留 (CPU 共用)

在開始使用專案來管理應用程式的資源之前，您必須先瞭解該應用程式的資源趨向。若記憶體容量的數量不適當，特定應用程式 (例如 ORACLE®) 的效能就會大幅下降。每個專案都必須設定資源保留：最小 CPU 共用和選用的最大記憶體保留 (記憶體容量)。在建立了應用程式的資源要求之後，您應僅開始使用專案來管理這些保留。

注意 – 注意 –

為專案設定的記憶體容量不得小於應用程式一般使用的容量。此實作會大幅影響應用程式的效能，而且可能會在應用程式要求使用更多虛擬記憶體時，因較高的分頁和交換導致嚴重的延遲。

您必須先完成伺服器合併規劃，才能開始使用專案來管理系統資源。一項重要的相關作業為識別您包含在合併規劃中之應用程式的資源使用量趨向。最佳方式是於您的產品環境中實作您的規劃之前，請在您的測試環境中先識別應用程式資源的使用情況趨向至少一個月的時間。在建立 CPU 和記憶體使用量趨向之後，您應至少允許超過一般記憶體要求的一些百分比點。

在為專案所需的 CPU 共用量建立保留時，您會指定一整數值的 CPU 量。例如，25、1 和 37 都是有效的量。共用 一詞是用來定義分配給某專案的系統 CPU 資源比例。與其他專案相比，若您指定較多的 CPU 共用量給某專案，該專案就會從公平共用排程程式收到較多的 CPU 資源。

CPU 共用與 CPU 資源百分比無關。共用是用來定義某工作負荷量與其他工作負荷量相較之下的相對重要性。例如，若銷售專案比行銷專案重要兩倍，銷售專案被指定的共用就應該是行銷專案的兩倍。您指定的共用數是不相關的；銷售專案的 2 份共用對行銷專案的 1 份共用，和銷售專案的 18 份共用對行銷專案的 9 份共用是相同的。在這兩個案例中，銷售專案獲得的 CPU 量都是行銷專案 CPU 量的兩倍。

CPU 共用可以再進一步分成兩個類別：

在建立資源儲存池或專案期間指定的 CPU 共用

在執行 Solaris 8 作業系統的主機上，僅可使用一個資源儲存池，即 pool_default。pool_default 的 CPU 共用值為 100。

在執行 Solaris 9 和 Solaris 10 作業系統的主機上，當您建立新的資源儲存池時，也會建立該池的 CPU 共用值。Solaris Container Manager 會提供一個預設值，但是您也可以自行輸入任何整數。某些系統管理員會在資源儲存池可用的每個 CPU 使用 100 份 CPU 共用的公式。例如，您可以指定 100 份 CPU 共用給具有一個 CPU 的資源儲存池。

假設此資源儲存池有三個專案：專案 X、專案 Y 和專案 Z。您指定 50 份 CPU 共用給最重要的專案「專案 X」、10 份共用給下一個專案「專案 Y」，而 40 份共用給下一個專案「專案 Z」。

圖 3–8 專案 CPU 共用

專案的 CPU 共用

您會在建立專案時使用「新專案」精靈將 CPU 共用指定給專案。「新專案」精靈會顯示資源儲存池的 [未保留 CPU 共用]，讓您可以判定可用的 CPU 共用並指定適當的數量給專案。

圖 3–9 CPU 共用

指定 CPU 共用給專案

(僅限 Solaris 10) 在建立區域期間指定的 CPU 共用

若主機是在 Solaris 10 作業系統上執行，您就可以建立區域，並指定區域的完整 CPU 共用和區域中專案的專案 CPU 共用。這些是相關的實體。

您會在建立區域時使用「新區域」精靈指定 CPU 共用和專案 CPU 共用。在「新區域」精靈的步驟 4 中，您會選擇一個資源儲存池。精靈會顯示該池的 [CPU 共用總數] 和該池的 [可用 CPU 共用總數]。

您輸入要從資源儲存池分配給此區域的 CPU 共用值。此整數必須小於或等於該池的 [可用 CPU 共用總數]。

圖 3–10 區域共用

指定 CPU 共用給區域

若資源儲存池擁有的 [可用 CPU 共用總數] 為 100，您就可以指定全部 100 份共用或部分共用給此區域。在此範例中，假設我們從資源儲存池指定 20 份 CPU 共用給區域。

在建立區域期間指定的專案 CPU 共用

在「新區域」精靈的步驟 4 中，您也可以輸入 [專案 CPU 共用]。此欄位指出在區域中分配給專案的 CPU 共用數量。在建立此值時，您也建立了區域的 [專案 CPU 共用] 值。您可以輸入任何整數。您輸入的整數決定了您要達到的精細度。

例如，假設我們指定給區域 A 的 [專案 CPU 共用] 為 1000。在某個實體層級上，1000 份 [專案 CPU 共用] 是 20 份 CPU 共用，其是從資源儲存池繼承並分成 1000 份共用。此為顯示在此範例中 1 份 [專案 CPU 共用] 和 [CPU 共用] 之間關係的公式：

1 份 [專案 CPU 共用] = 20 (分配給區域的 CPU 共用數) /1000 ([專案 CPU 共用] 數) = 0.02 份 [CPU 共用]

在建立專案時，例如，在區域 A 中建立專案 1，專案 1 會從區域取得共用，而非直接從資源儲存池取得共用。若專案 1 在區域 A 中被指定了 300 份共用，就表示其獲得了 300 份 [專案 CPU 共用] 或 300/1000 x 20/100 = 0.06 [CPU 共用]。

圖 3–11 區域 CPU 共用

區域的 CPU 共用

您會在呼叫「新專案」精靈時指定「專案 CPU 共用」給專案。在「新專案」精靈的步驟 7 [為專案提供資源保留] 中，您會在標示為 CPU 保留 (CPU 共用) 的欄位內輸入專案 CPU 共用。上述情況只有當您僅在 Solaris 10 主機上的區域中建立一個專案時才會成立。

圖 3–12 專案 CPU 共用

指定專案 CPU 共用給專案

備註 –

在 Solaris 8 或 Solaris 9 主機上建立專案時，會使用 [未保留的 CPU 共用] 欄位來輸入 CPU 共用 (而非專案 CPU 共用)。

注意 – 注意 –

請勿使用指令行 (zonecfg 指令) 來手動變更 CPU 共用。這將會干擾 Solaris Container Manager 的計算。

全域區域與其專案

全域區域是唯一一個不只與一個資源儲存池連結的區域。此區域可以從任何資源儲存池取得 CPU 資源。在全域區域中的專案可以從主機上的每個資源儲存池取得 CPU 資源，因為在主機上的每個資源儲存池都有一個隱藏的全域區域。

例如，資源儲存池 Pool_default 具有 4 個 CPU，並已部署了 zone_1 和 zone_2。Pool_default 擁有 10 份 CPU 共用。Zone_1 擁有 5 份 CPU 共用、zone_2 擁有 4 份 CPU 共用，而全域區域則有 1 份 CPU 共用。

另一個資源儲存池 Pool_1 具有 2 個 CPU 和 10 份 CPU 共用。Pool_1 只有部署一個區域，即 zone_3。Zone_3 擁有 9 份 CPU 共用。全域區域擁有 1 份 CPU 共用。

全域區域中的專案都可從其被部署的資源儲存池之 1 份 CPU 共用取得其 CPU 資源。

在 Solaris Container Manager 中，全域區域中的專案必須部署到 pool_default。

公平共用排程程式 (FSS)

Container Manager 使用公平共用排程程式 (FSS) 來確保您所設定的最小 CPU 共用。公平共用排程程式是預設的排程程式。公平共用排程程式會計算分配給某專案的 CPU 比例，方法為依據使用中專案的共用總數來為專案分割共用。使用中專案是至少有一個程序在使用 CPU 的專案。閒置專案 (即沒有使用中程序的專案) 的共用不會包含在計算中。

例如，三個專案「銷售」、「行銷」和「資料庫」分別被分配到兩份、一份和四份共用。所有的專案都為使用中。資源儲存池的 CPU 資源是以下列方式分配：銷售專案接收到 2/7、行銷專案接收到 1/7，而資料庫專案則接收到 4/7 的 CPU 資源。若銷售專案為閒置中，則行銷專案會接收到 1/5，而資料庫專案會接收到 4/5 的 CPU 資源。

注意，若發生 CPU 的競爭情況，公平共用排程程式僅會限制 CPU 使用量。系統上唯一為使用中的專案可以使用百分之百的 CPU，不論其擁有的共用數為何。CPU 循環不會被浪費掉。若某專案因為沒有要執行的工作而沒有使用其應享有的所有 CPU，其餘的 CPU 資源就會分配給其他使用中的程序。若專案沒有定義任何 CPU 共用，就會為其指定一份共用。具有零 (0) 份共用之專案中的程序會以最低的系統優先權執行。當具有非零份共用的專案沒有在使用 CPU 資源時，這些程序才能執行。

時間共用排程程式 (TS)

時間共用排程程式會嘗試提供每一個處理器至可用 CPU 的相對平等存取，其按照優先權來分配 CPU 時間。因為 TS 不需要受到管理，所以很容易使用。但是，TS 無法保證特定應用程式的效能。若不需要 CPU 分配，您就應該使用 TS。

例如，若兩個專案被指定給一個 FSS 資源儲存池，而且它們都分別具有兩份共用，在這些專案中執行的程序數量則沒有任何關係。一個專案僅可以存取百分之五十的可用 CPU。因此，若一個程序在銷售專案中執行，而有 99 個程序在行銷專案中執行，則銷售專案中的該程序可以存取百分之五十的 CPU。在行銷專案中的 99 個程序則必須共用百分之五十的可用 CPU 資源。

在 TS 資源儲存池中，會為每個程序分配 CPU。在銷售專案中的一個程序只能存取百分之一的 CPU，而行銷專案中的 99 個程序則可以存取百分之九十九的可用 CPU 資源。

如需關於公平共用排程程式或時間共用排程程式的更多資訊，請參閱「System Administration Guide: Network Services」。

使用 Container Manager 來得知應用程式資源使用量趨向

您可以在測試環境中使用 Container Manager 執行下列作業，以協助得知應用程式資源使用量的趨向：

  1. 安裝和設定 Container Manager 軟體與任何必要的軟體。

    如需相關資訊，請參閱第 2 章, Container Manager 安裝和設定。

  2. 在所有您要監視的代理程式機器上安裝效能報告管理程式。

    如需更多資訊，請參閱第 2 章, Container Manager 安裝和設定和Sun Management Center 3.6.1 Performance Reporting Manager User’s Guide。

  3. 為您要得知其趨向的應用程式建立以應用程式為基礎的使用中容器。在「新建」精靈中，僅建立最小 CPU 保留。請勿設定記憶體容量。

    如需更多資訊，請參閱建立以應用程式為基礎的專案和建立以應用程式為基礎的專案。

  4. 監視數週使用的資源，查看每日、每週或即時圖形。在個別主機上執行的容器可使用兩個圖形，一個是使用的 CPU 和記憶體資源。您也可以檢視 [程序] 表來監視在應用程式中執行的程序。

    如需更多資訊，請參閱請求使用中專案的資源使用情況報告和檢視專案程序。

  5. 在建立應用程式的最大實體記憶體需求後，請修改容器的特性以包含記憶體容量。設定的記憶體容量不得低於應用程式使用的最大記憶體容量。

    如需更多資訊，請參閱使用特性表修改專案。

  6. 設定警報，讓您可以在使用的記憶體開始超出所設的記憶體容量時收到通知。使用特性表以對記憶體容量進行任何調整。

    如需更多資訊，請參閱設定警報臨界值和使用特性表修改專案。

在使用 Container Manager 建立資源使用情況趨向之後，您就可以使用容器在產品環境中合併伺服器。

如需關於如何計劃和執行伺服器合併的更多資訊，您可以閱讀由 David Hornby 和 Ken Pepple 所著的 Sun Blueprints 書籍「Consolidation in the Data Center」。如需關於在執行 ORACLE 資料庫的系統上合併伺服器的更多資訊，您可以閱讀 Sun 白皮書「Consolidating Oracle RDBMS Instances Using Solaris Resource Manager Software」。