安裝和管理 Solaris Container Manager 1.1

關於建立容器

每個專案皆使用容器啟動。專案有三種類型，視建立期間選取的專案類型而定。專案類型決定如何追蹤程序。

專案類型

建立新容器時，您必須選取專案類型。專案為相關工作的網路內管理識別器 (ID)。執行在容器的所有程序具有相同的專案 ID，且容器會使用此專案 ID 追蹤已使用的資源。容器類型是根據建立容器時所選取的專案類型。

每個容器具有永久性資訊的專案名稱。容器在主機中啟動時，此專案名稱會增加到該主機的 /etc/project 檔案。只要容器在該主機中維持啟動狀態，此項目便會存在。

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

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

在建立以應用程式為基礎的容器時，需提供您選擇的專案名稱。建立專案精靈可接受不同的以應用程式為基礎的專案具有重複的名稱。但具有相同專案名稱的應用程式為基礎的專案無法同時在主機中啟動。僅在您計劃在不同的主機中啟動這些容器，才可在建立以應用程式為基礎的專案時重複使用專案名稱。若您嘗試在已具有相同專案名稱的專案之主機中啟動第二個專案，啟動將會失敗。

下表提供可用的三種專案類型之詳細資訊，且其根據選擇會發生變更。

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


專案類型	作業系統版本	詳細資訊
以使用者為基礎	Solaris 8	Solaris 8 發行版本僅支援此專案類型。 `/etc/project` 檔案中的專案名稱會變成 user.`使用者名稱`。專案會變成使用者的主要預設專案。
	Solaris 9 和 Solaris 10	`/etc/project` 檔案的專案名稱會變成 user.`使用者名稱`，並具有可加入此專案的 UNIX 使用者清單。有效的格式為`使用者名稱`。
以群組為基礎	Solaris 9 和 Solaris 10	`/etc/project` 檔案的專案名稱會變成 group.`群組名稱`。有效格式為`群組名稱`。
以應用程式為基礎	Solaris 9 和 Solaris 10	專案名稱可以是應用程式名稱或任何其他選擇的名稱。您提供的名稱會增加到 `/etc/project` 檔案。可提供符合表示式以自動移動符合程式到專案名稱。此表示式為大小寫相符的。必須提供目前程序執行在其下之相對應的`使用者名稱`或`群組名稱`。

關於設定資源保留

使用專案管理應用程式的資源前，您必須先知道應用程式的資源趨勢。若記憶體容量不適當，某些應用程式的效能 (例如 ORACLE®) 將大打折扣。每個專案必須設定資源保留：最小 CPU 共用以及可選擇是否設定的最大記憶體保留 (記憶體容量)。在建立應用程式的資源需求後，才可開始使用專案來管理這些保留。

注意 –

為專案設定實體記憶體容量時，請勿小於應用程式一般所使用的。由於分頁和交換時應用程式需要使用較多的虛擬記憶體，此動作可能會負面地影響應用程式的效能且可能會導致重大的延遲。

您必須完成伺服器合併計算規劃，才開始使用專案來管理系統資源。有一項重要的相關作業為確認您的合併計算計劃中應用程式的資源消耗趨勢。理想狀況下，您需在測試環境中至少確認一個月內應用程式的資源使用情況的趨勢，才開始在生產環境中實作您的計劃。建立 CPU 和記憶體消耗趨勢後，您應該允許您的需求高於一般記憶體的需求幾個百分點。

設定專案所需的 CPU 共用數量的保留時，請指定 CPU 數量為整數。例如，25、1 和 37 皆為有效的數量。共用字詞是用來定義分配到專案的系統 CPU 資源的比例。若您指定較大的 CPU 共用數量到專案 (相對於其他專案)，此專案會從公平共用排程程式得到較多的 CPU 資源。

CPU 共用不等於 CPU 資源的百分比。共用是用來定義關於其他工作負載量之工作負載量的相對重要性。例如，若銷售專案比市場專案重要兩倍，則應指定銷售專案的共用為市場專案的兩倍。而這與您指定的共用數目無關，2 份共用的銷售專案與 1 份共用的市場專案，和 18 份共用的銷售專案與 9 份共用的市場專案是相同的。在這兩個情況中，銷售專案的 CPU 數量皆為市場專案的兩倍。

CPU 共用可分為下列兩種：

CPU 共用
(僅限 Solaris 10) 專案 CPU 共用 (在特定區域)

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

在執行 Solaris 8 的作業系統中，僅可取得一個資源儲存池 (pool_default)。pool_default 具有 100 份 CPU 共用的值。

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

假設此儲存池具有三個專案：專案 X、專案 Y 和專案 Z。您可以為最重要的專案 X 指定 50 份 CPU 共用，而專案 Y 有 10 份共用，專案 Z 有 40 份共用。

圖 3–8 專案 CPU 共用

在使用新專案精靈建立專案時，您可以為專案指定 CPU 共用。新專案精靈會顯示儲存池的未保留的 CPU 共用，所以您可以判定可用的 CPU 共用並為專案指定適當的數量。

圖 3–9 CPU 共用

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

若您的主機執行 Solaris 10 作業系統，您可以建立區域並為各區域指定 CPU 共用總數，且為區域中的專案指定專案 CPU 共用。這些為相關的實體。

您可以在使用新區域精靈建立區域期間指定 CPU 共用和專案 CPU 共用。在新區域精靈的步驟 4，請選取一個資源儲存池。精靈會顯示儲存池的 CPU 共用總數以及可用的 CPU 共用總數。

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

圖 3–10 區域共用

若儲存池的可用 CPU 共用總數為 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 會從區域取得共用，而不是直接從資源儲存池。若指定區域 A 的專案 1 有 300 份共用，則其取得 300 份專案 CPU 共用或 300/1000 x 20/100 = 0.06 份 CPU 共用。

圖 3–11 區域 CPU 共用

呼叫新專案精靈時，可為專案指定專案 CPU 共用。在新專案精靈的步驟 7，提供專案的資源保留，在標示為 CPU 保留 (CPU 共用) 的欄位中輸入專案 CPU 共用。若您僅在 Solaris 10 主機的區域中建立專案，才會出現此步驟。

圖 3–12 專案 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 的 50%。因此，若 1 個程序執行在銷售專案，99 個程序執行在市場專案，則這 1 個銷售專案可存取 CPU 的 50%。市場專案中的 99 個程序必須共用 50% 的可用 CPU 資源。

在 TS 資源儲存池中，每個程序會分配 CPU。銷售專案中的 1 個程序僅可存取 1% 的 CPU，而市場專案中的 99 個程序可存取 99% 的可用 CPU 資源。

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

使用 Container Manager 以取得應用程式資源消耗的趨勢

您可以在測試環境中使用 Container Manager 為工具執行下列作業，以取得應用程式資源消耗的趨勢：

在安裝和設定任何所需的軟體時一起安裝和設定 Container Manager 軟體。

如需更多資訊，請參閱第 2 章, Container Manager 安裝和設定。
在您想要監視的所有代理程式機器上安裝性能報告管理程式。

如需更多資訊，請參閱第 2 章, Container Manager 安裝和設定和「Sun Management Center 3.5 性能報告管理程式使用者指南」。
建立您想要取得其趨勢的應用程式之以應用程式為基礎的使用中容器。在新建精靈中，僅設定最小 CPU 保留。請勿設定記憶體容量。

如需更多資訊，請參閱建立以應用程式為基礎的專案和建立以應用程式為基礎的專案。
監視幾個禮拜的每日、每週或即時圖表中所使用的資源。執行在個別主機中的容器可取得兩個圖表 (一個為已使用的 CPU 和記憶體資源)。您還可檢視 [程序] 表以監視執行在應用程式中的程序。

如需更多資訊，請參閱請求使用中專案的資源使用情況報告和檢視專案程序。
在建立應用程式的最大實體記憶體需求後，,請修改容器的特性以包含記憶體容量。設定容量時，請勿設定小於應用程式使用的最大記憶體容量。

如需更多資訊，請參閱使用特性表修改專案。
若使用的記憶體開始超出設定的記憶體容量，請設定警示以提醒您。使用特性表以調整記憶體容量。

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

在使用 Container Manager 建立資源使用情況的趨勢後，您可以使用容器在您的生產環境中合併計算伺服器。

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