安装和管理 Solaris Container Manager 3.6

有关容器创建

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

项目类型

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

每个容器都拥有属于信息中永久性部分的项目名称。在某主机上激活容器时，将把该项目名称添加到此主机的 /etc/project 文件中。只要该容器在此主机上处于活动状态，此条目将一直保留。

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

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

在基于应用程序容器的创建过程中，您可以提供一个自己选择的项目名称。该项目创建向导允许基于应用程序的不同项目具有相同项目名称。但是两个基于应用程序的项目具有相同的项目名称时，不能同时在同一台主机上处于活动状态。只有计划在不同的主机上激活这些容器时，才能在创建基于应用程序的项目时重复使用这些项目名称。如果试图在所含项目已经拥有相同项目名称的主机上激活下一个项目，该激活操作将失败。

下表介绍了有关三种可用项目类型的详细信息以及基于所作的选择会出现哪些变化的详细信息。

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


项目类型	操作系统版本	详细信息
基于用户的	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 only 是一个可用的资源池。pool_default 拥有 100 个单位的 CPU 份额值。

在运行 Solaris 9 和 Solaris 10 操作系统的主机上，新建资源池时您就确定了该池要使用 CPU 份额值。 Solaris 容器管理器给出了一个默认值，但是可以输入任意一个整数。一些系统管理员按照惯用原则，为该资源池可用的所有 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 份额（如果资源池被分为 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)

按时间分配调度程序 (Timesharing Scheduler, 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 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。