安装和管理 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 文件中。

可提供匹配表达式自动将匹配进程移到该项目名称中。此表达式是区分大小写的。 

必须提供(这些进程当前所属的)相应的用户名组名

关于设置资源保留(CPU 份额)

在开始使用项目管理应用程序资源之前,您首先必须掌握该应用程序的资源使用率趋势。如果内存容量不足,某些应用程序(如 ORACLE®)的性能将会显著降低。每个项目均须设置资源保留:最小 CPU 份额和最大内存保留(即内存容量,可选)。只有为各种应用程序建立了资源要求之后,您才能开始使用项目来管理这些保留。


注意 – 注意 –

请勿将项目的物理内存容量设置为少于该应用程序一般的使用量。此做法将对该应用程序的性能产生不利的影响,并可能导致显著的延迟,因为该应用程序需要更高的分页和交换处理来使用更多虚拟内存。


在开始使用项目来管理系统资源之前,您必须先完成服务器整合计划。一项重要的相关任务是确定整合计划所含应用程序的资源消耗趋势。一般来讲,在生产环境中实现该整合计划之前,您至少应该花一个月的时间在测试环境中确定该应用程序的资源使用率趋势。在确定了 CPU 和内存消耗的趋势之后,您还应该在一般的内存需求上留出几个百分点。

在设置该项目所需 CPU 份额总量的保留时,可将 CPU 的总数指定为一个整数。例如,25、1 和 37 都是有效的数量。术语份额以量化的形式定义了分配给某项目的那部分系统 CPU 资源。如果您给某项目指定了较大(相对于其他项目)的 CPU 份额,则该项目将从合理分配调度程序接收到较之其他项目更多的 CPU 资源。

CPU 份额不等于 CPU 资源百分比。份额用于定义任务的相对重要性(与其他任务相对而言)。例如:如果销售项目要比营销项目重要两倍,则应该为销售项目指定两倍于营销项目的份额。您指定的份额在数量上是不相关的;销售项目的 2 份对营销项目的 1 份与销售份额的 18 份对营销份额的 9 份是一样的。在这两种情况下,销售项目均被赋予两倍于营销项目的 CPU 数量。

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 份额,因此您可以确定可用的 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 将从该区域获得份额,而不是直接从资源池获得份额。如果给区域 A 中的项目 1 指定了 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 的项目。不计空闲项目(即不含有活动进程的项目)所拥有的份额。

例如,假设您已分别为销售、营销和数据库这三个项目分配了 2、1 和 4 个份额。这三个项目都是活动的。则资源池的 CPU 资源是这样分配的:销售项目获得 2/7 的 CPU 资源;营销项目获得 1/7 的 CPU 资源;数据库项目获得 4/7 的 CPU 资源。如果销售项目是空闲的,则营销项目将获得 1/5,数据库项目将获得 4/5 的 CPU 资源。

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

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

按时间分配调度程序 (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 Services》

使用 Container Manager 预测应用程序的资源消耗情况

您可以在测试环境中借助 Container Manager 来预测应用程序的资源消耗情况,具体步骤如下:

  1. 安装和设置 Container Manager 软件以及所需的其他软件。

    有关信息,请参阅第 2 章,Container Manager 的安装和设置

  2. 在您想监视的所有代理主机上安装性能报告管理器。

    有关详细信息,请参阅第 2 章,Container Manager 的安装和设置以及《Sun Management Center 3.5 性能报告管理器用户指南》

  3. 为要预测的应用程序创建一个基于应用程序的活动容器。在新建容器向导中,只设置最小 CPU 保留。请勿设置内存容量。

    有关详细信息,请参阅创建基于应用程序的项目创建基于应用程序的项目

  4. 使用每天、每周或实时图形来监视资源的使用情况,连续监视几个星期。请重点观察运行在单个主机上的容器的两种图形,即 CPU 和内存资源的使用图形。您也可以查看“进程”表,以监视运行在该应用程序中的进程。

    有关详细信息,请参阅请求活动项目的资源使用情况报告查看项目进程

  5. 确定了该应用程序的最大物理内存需求之后,请修改容器的属性以包含内存容量。请勿将其容量设置得低于该应用程序运行所需的最大内存量。

    有关详细信息,请参阅使用属性表修改项目

  6. 设置相关报警,以便在内存用量超出内存容量设置的时候及时获得通知。使用“属性”表调整内存容量。

    有关详细信息,请参阅设置报警阈值使用属性表修改项目

使用 Container Manager 确定资源使用情况趋势之后,便可以在生产环境中使用容器来整合服务器了。

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