安裝與管理 Solaris Container Manager 3.6.1

關於容器建立

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

專案類型

在建立新容器時，您必須選擇專案類型。專案是一種相關工作的全網路管理識別碼 (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 10) 專案 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 共用並指定適當的數量給專案。

圖 3–9 CPU 共用

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

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

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

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

圖 3–10 區域共用

若資源儲存池擁有的 [可用 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 共用」給專案。在「新專案」精靈的步驟 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。因此，若一個程序在銷售專案中執行，而有 99 個程序在行銷專案中執行，則銷售專案中的該程序可以存取百分之五十的 CPU。在行銷專案中的 99 個程序則必須共用百分之五十的可用 CPU 資源。

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

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

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

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

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

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

如需更多資訊，請參閱第 2 章, Container Manager 安裝和設定和Sun Management Center 3.6.1 Performance Reporting Manager User’s Guide。
為您要得知其趨向的應用程式建立以應用程式為基礎的使用中容器。在「新建」精靈中，僅建立最小 CPU 保留。請勿設定記憶體容量。

如需更多資訊，請參閱建立以應用程式為基礎的專案和建立以應用程式為基礎的專案。
監視數週使用的資源，查看每日、每週或即時圖形。在個別主機上執行的容器可使用兩個圖形，一個是使用的 CPU 和記憶體資源。您也可以檢視 [程序] 表來監視在應用程式中執行的程序。

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

如需更多資訊，請參閱使用特性表修改專案。
設定警報，讓您可以在使用的記憶體開始超出所設的記憶體容量時收到通知。使用特性表以對記憶體容量進行任何調整。

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

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

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