安装和管理 Solaris Container Manager 3.6.1

有关容器创建

每个项目均以容器开始。项目可以有三种类型，具体取决于项目创建过程中所做的选择。项目类型决定了该如何跟踪进程。

项目类型

创建新容器时，必须选择项目类型。项目就是针对相关工作的网络级管理标识符 (ID)。在一个容器中运行的所有进程均具有相同的项目 ID，容器则使用该项目 ID 跟踪正在使用的资源。容器类型取决于创建该容器时所选择的项目类型。

项目名称会始终包含在每个容器的信息中。在主机上激活容器时，此项目名称会添加到该主机的 /etc/project 文件中。只要该容器在该主机上处于活动状态，此条目将一直保留。

同一主机上拥有相同项目名称的两个项目不能同时处于活动状态。这是因为，在容器中运行的所有进程均通过项目 ID 加以跟踪，因此，主机上的每个项目名称都必须唯一。

当创建基于用户或基于组的项目时，用户名或组名将成为项目名称的一部分。对于基于用户的容器，其项目名称变为 user.username 格式。对于基于组的容器，其项目名称变为 group.groupname 格式。因此，当创建基于用户或基于组的项目时，您使用的用户名或组名不能与默认容器的 /etc/project 条目重复。有关更多信息，请参见默认容器。

在创建基于应用程序的容器的过程中，您可以提供一个自己选择的项目名称。项目创建向导允许不同的基于应用程序的项目具有相同的项目名称。但是，两个有相同项目名称的基于应用程序的项目不能同时在同一主机上被激活。仅当您计划在不同主机上激活这些容器时，才能在创建基于应用程序的项目时重复使用项目名称。如果试图在主机上激活第二个项目，而该主机已具有一个相同项目名称的项目，则该激活操作将失败。

下表提供了三种可用项目类型的详细信息，以及基于所做的选择会出现哪些变化情况。

表 3–2 项目类型详细信息


项目类型	OS Version	详细信息
基于用户的	Solaris 8	只受 Solaris 8 操作系统支持的项目类型。 `/etc/project` 文件中的项目名称变为 user.`username` 格式。该项目变成了该用户的主默认项目。
	Solaris 9 和 Solaris 10	`/etc/project` 文件中的项目名称变为 user.`username` 格式，其中包含了可加入此项目的 UNIX 用户列表。有效格式为 `username`。
基于组的	Solaris 9 和 Solaris 10	`/etc/project` 文件中的项目名称变为 group.`groupname` 格式。有效的格式为 `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 份额
（仅适用于 Solaris 10）项目CPU 份额（位于特定区域）

在创建池或项目的过程中指定的 CPU 份额

在运行 Solaris 8 操作系统的主机上，只有 pool_default 一个资源池是可用的。pool_default 拥有 100 个单位的 CPU 份额值。

在运行 Solaris 9 和 Solaris 10 操作系统的主机上，新建资源池时您就确定了该池要使用的 CPU 份额值。Solaris Container Manager 给出了一个默认值，但您可以输入任意整数。有些系统管理员按照惯用原则，为该资源池可用的所有 CPU 指定 100 个 CPU 份额。例如：您可以给具有一个 CPU 的资源池指定 100 个 CPU 份额。

假设此池中含有三个项目：项目 X、项目 Y 和项目 Z。您分配给最重要的项目（项目 X）50 个 CPU 份额；下一个项目（项目 Y）10 个份额；最后一个项目（项目 Z）40 个份额。

图 3–8 项目 CPU 份额

可在使用“新建项目”向导创建项目时为项目分配 CPU 份额。“新建项目”向导显示了该池未保留的 CPU 份额，因此您可以确定可用的 CPU 份额并为该项目分配适当的份额。

图 3–9 CPU 份额

在区域创建过程中指定的 CPU 份额（仅适用于 Solaris 10）

如果您的主机运行的是 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 份额（这些 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 使用合理分配调度程序 (Fair Share Scheduler, FSS) 来确保您设置的最小 CPU 份额。合理分配调度程序是默认的调度程序。通过用项目的份额除以活动项目的份额总数，合理分配调度程序可计算出分配给该项目的 CPU 比例。活动项目就是至少有一个进程在使用 CPU 的项目。用于空闲项目（即不含有活动进程的项目）的份额不适应于该计算。

例如，假设您已分别为销售、市场和数据库这三个项目分配了 2 个、1 个和 4 个份额。所有这些项目都是活动的。该资源池的 CPU 资源是这样分配的：销售项目获得 2/7 的 CPU 资源；市场项目获得 1/7；数据库项目获得 4/7。如果销售项目是空闲的，则市场项目将获得 1/5，数据库项目将获得 4/5 的 CPU 资源。

注意：合理分配调度程序只在出现 CPU 争用时才限制 CPU 使用。如果系统只有一个项目是活动的，则不管该项目持有的份额数是多少，它都可以使用 100% 的 CPU。从而也就不会浪费 CPU 周期。如果因为没有要执行的任务，某项目没有完全使用指定给它的 CPU，则其余的 CPU 资源将分发给其他活动的进程。如果某项目未定义任何 CPU 份额，那么将给它分配 1 个份额。在份额为零的项目中，其进程的系统优先权将是最低的。只有在非零份额项目不使用 CPU 资源时，这些进程才会运行。

按时间分配调度程序 (TS)

按时间分配调度程序根据优先级分配 CPU 时间，尽量让每个进程均可以相对平等地获得可用的 CPU 资源。由于无需管理，所以 TS 使用起来比较轻松。但是，TS 无法保证特定应用程序的性能。因此，应该在不必进行 CPU 分配时使用 TS。

例如：如果两个项目被分配给 FSS 资源池，而且它们分别拥有 2 个份额（运行在这些项目中的进程数是不相关的），则一个项目只能获得 50% 的可用 CPU。这样，如果有 1 个进程在运行销售项目，有 99 个进程在运行市场项目，则运行在销售项目中的那一个进程能够获得 50% 的 CPU；而市场项目中的 99 个进程必须共享 50% 的可用CPU 资源。

在 TS 资源池中，每个进程都分配了 CPU。销售项目中的那一个进程只能获得 1% 的 CPU，而市场项目中的 99 个项目将获得 99% 的可用 CPU 资源。

有关合理分配调度程序或按时间分配调度程序的更多信息，请参见《System Administration Guide: Network Service》。

使用 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 确定资源使用情况趋势之后，就可以在生产环境中使用容器来整合服务器了。

有关如何计划和执行服务器整合的更多信息，请参阅 Sun 蓝皮书《Consolidation in the Data Center》（David Hornby 和 Ken Pepple 著）。有关在运行 Oracle 数据库的系统上进行服务器整合的更多信息，请参阅 Sun 白皮书《Consolidating Oracle RDBMS Instances Using Solaris Resource Manager Software》。