第 10 章 高级用途

本章进一步探讨在系统上按优先顺序排列并管理不相似的应用程序的方法。提供一个范例以说明与 Solaris Resource Manager 相关的这些功能和其它关键概念。本章的最后一部分讨论如何在 Sun Cluster 3.0 12/01（和更高更新版）环境中配置 Solaris Resource Manager。

批工作负荷

大多数的商用安装对批处理都有要求。批处理通常在晚上，在日常联机工作负荷已经减少之后才进行。这样的作法有两个原因：使一天的事务合并到报告之中，并防止批工作负荷去影响联机负载。

有关用以控制在其中运行批作业的环境的分层结构的示例，请参阅示例；这一节还包括了该进程中所使用的 Solaris Resource Manager 命令。

批工作负荷所使用的资源

批工作负荷是联机事务处理 (OLTP) 和决策支持系统 (DSS) 的工作负荷两者的混合物，它们对系统的效用在这两者之间某处。一个批工作负荷可以包括很多向数据库的重复交易，每个交易具有一些繁重的计算工作。举个简单的例子：计算一天的销售总额。在这种情况下，批处理要从数据库检索当天销售的每一笔交易，抽取销售量，并保持随时计算总额。

批处理通常对处理器以及 I/O 资源的要求很高，因为批处理和数据库需要占用大量的 CPU，而且就检索的每一项事务都从末端数据库生成大量的 I/O。

批工作负荷靠有效地限制 CPU 和 I/O 两者的消耗率来控制。Solaris Resource Manager 允许对 CPU 进行微细的资源控制，但是 I/O 资源则必须通过将不同的 I/O 设备分配给各工作负荷进行管理。

通常使用两种方法隔离批资源的影响：

• 在分开的系统上制作数据库的备份，并在这一分开的系统上运行批处理和进行汇报的工作负荷。（但请注意：在大多数情况下，批处理对联机数据库部分进行更新，无法将批处理从其中分离出来。）

• 使用 CPU 资源控制。

由于从批工作负荷中生成的 I/O 的量与消耗的 CPU 的量是成比例的，对 CPU 循环的限制可用于间接地控制批工作负荷的 I/O 率。但请注意：必须小心谨慎，确保那些对 CPU 很少要求的工作负荷上并不生成过量的 I/O。

与批处理有关的问题

按定义而言，批工作负荷是无约束运行的工作负荷，它会试图在尽可能短的时间内完成。这就意味着批是最糟糕的资源消耗者，因为它将占用所需要的一切资源，直至受到系统瓶颈（一般是系统数据流的最小点）的约束。

批对系统管理员提出两个问题；它可能影响正在并发运行的其它批作业，它在营业时间从来不能与该工作负荷的联机部分一起运行。

即使将批作业安排为营业时间之外运行（比方说，半夜 12:00 到早上 6:00），系统问题或一天中的高销售可能导致批工作负荷满溢至营业时间。虽然并不如停机时那样糟糕，如果次日上午 10:30 还在运行批工作负荷则可能使网上的顾客要成交就必须等候数分钟，而最终导致成交的事务较少。

使用资源分配将限制批工作负荷可用的资源量，并以一种有控制的方式来约束它们。

合并

Solaris Resource Manager 允许以系统范围级别对系统资源进行分配，有时侯与各部门之间机器的业务使用安排成正比。示例显示如何使用 Solaris Resource Manager 的分层结构来达到此目的。

虚拟内存和数据库

Solaris Resource Manager 产品还提供限制用户和工作负荷使用虚拟内存量的功能。该功能并不管理实际内存；而是有效地限制每个用户耗用的全局交换空间量。

当一个用户或工作负荷达到他们 lnode 的虚拟内存限制设置时，系统返回内存分配错误给应用程序；即调用 malloc() 失败。将该错误码报告给应用程序，就象该应用程序用完了交换空间一样。

很少有几个应用程序能很好对内存分配错误作出响应。因此，让一个数据库服务器达到其虚拟内存限制是有风险的。万一达到了限制，数据库引擎可能崩溃，导致损坏数据库。

虚拟内存限制应该设置上限，以便在正常情况下不能达到它们。还有，虚拟内存限制可用于将一个上限放在整个数据库服务器上，它将防止有内存泄漏的数据库故障影响系统上其它数据库或工作负荷。

管理 NFS

NFS，Sun 的分布式计算环境，作为 kernel 线程运行，并使用 kernel 调度类 SYS。因为 Solaris Resource Manager SHR 类不管理 NFS 的调度分配，不使用 NFS 的 CPU 资源控制是可能的。在提供广泛的 NFS 服务的系统上，Solaris Resource Manager 产品的分配处理器资源的能力可能会遭到削弱。

然而，使用网络端口资源管理可以控制 NFS。例如，Solaris 带宽管理器可以用于控制服务器上的 NFS 数据包数。在某些情形下，使用处理器组也可以管理 NFS，以限制系统类中可用的 CPU 数。

管理 Web 服务器

通过控制 CPU 和虚拟内存，Solaris Resouce Manager 可用于管理 Web 上服务器上的资源。三种基本的拓扑用于主机 Web 服务器系统。

合并的 Web 服务器的资源管理

通过控制整个 Web 服务器能使用的资源量，可以管理单个服务器。这在与其它工作负荷合并的 Web 服务器的环境中是有用的。这是资源管理的最基本形式，并可避免其它工作负荷影响 Web 服务器的性能，反之亦然。例如，如果 Web 服务器中的 CGI 脚本因内存泄漏而无法控制，这整个系统将不会用完交换空间；只有 Web 服务器将受到影响。

在这个例子中，一个 Web 服务器可分成 20 份，它意味着如果数据库在处理器上投入过量要求，则至少给它保证百分之二十的处理器资源。

有关另一个 Web 服务器的示例，请参阅增加万维网前端进程。

单个 Web 服务器的细微管理

经常要求使用资源管理来控制单个 Web 服务器的性能。例如，许多用户可以共享单个 Web 服务器，每个用户有他们自己的 cgi-bin 程序。

一个 cgi-bin 程序中的错误可导致整个 Web 服务器运行减慢，或在内存泄漏情况中，甚至导致 Web 服务器停止运行。要避免这种情况发生，可以使用每个过程限制。

多个虚拟 Web 服务器的资源管理

单台计算机经常用于以多个合并方式处理多台虚拟 Web 服务器。在这种情形中，存在有多个 httpd Web 服务器进程，通过 Solaris Resource Manager 可以更好的控制资源。

通过设置 Web 服务器配置文件中的参数，有可能将每个 Web 服务器作为不同的 UNIX UID 运行。这将把每个 Web 服务器有效地与 Solaris Resource Manager 层次结构中的不同 lnode 连接起来。

例如，Sun WebServer^TM 在配置文件 /etc/http/httpd.conf 中拥有以下参数：

# Server parameters
 server  {
   server_root                   "/var/http/"
   server_user                   "webserver1"
   mime_file                     "/etc/http/mime.types"
   mime_default_type             text/nlain
   acl_enable                    "yes"
   acl_file                      "/etc/http/access.acl"
   acl_delegate_depth            3
   cache_enable                  "yes"
   cache_small_file_cache_size   8                       # megabytes
   cache_large_file_cache_size   256                     # megabytes
   cache_max_file_size           1                       # megabytes
   cache_verification_time       10                      # seconds
   comment                       "Sun WebServer Default Configuration"

   # The following are the server wide aliases

   map   /cgi-bin/               /var/http/cgi-bin/              cgi
   map   /sws-icons/             /var/http/demo/sws-icons/
   map   /admin/                 /usr/http/admin/

 # To enable viewing of server stats via command line,
 # uncomment the following line
   map   /sws-stats              dummy                           stats
 }

通过配置要作为不同 UNIX UID 运行的 Web 服务器，您可以在每个 Web 服务器上设置不同的限制。这对在一台运行多个 Web 服务器的计算机上进行资源使用的控制和计费特别有用。

在这种情形，您可以利用多个或所有的 Solaris Resource Manager 资源控制和限制：

Shares [cpu.shares]

cpu.shares 可用于按比例地给不同的 Web 服务器分配资源。

Mem limit [memory.limit]

memory.limit 可用于限制 Web 服务器可以使用的虚拟内存量，它将防止任何一个 Web 服务器因内存分配而导致另一个失败。

Proc mem limit [memory.plimit]

每个过程内存限制可用于限制单个 cgi-bin 过程可使用的虚拟内存量，它将防止任何 cgi-bin 过程导致其相应的 Web 服务器停止运行。

Process limit [process.limit]

允许连接到一台 Web 服务器最大的过程总数可以有效地限制 cgi-bin 过程的并行数。

处理器组的作用和效能

即使使用 Solaris Resource Manager 软件，处理器组仍然能在资源分配中发挥重要作用。有时，系统必须对资源政策实行严格限制。例如，某家公司可能购买一套 24 个处理器的系统，然后用同一个主机为两个不同的业务单位服务。每个业务单位按比例支付主机使用费，例如 40% 和 60%。在这种情况下，管理员可能需要规定支付 40% 主机使用费的单位不可超过其分享额。

使用处理器组时，可以很方便地分配工作量，例如将 10 个处理器分配给享有 40% 配额的单位，将其余 14 个处理器分配给享有 60% 配额的另一个单位。

处理器组和 Solaris Resource Manager 产品连用时，必须充分了解这两种技术之间的互动作用。在某些情况下，实际效果可能和预期的不一样。

简单示例

下面的图例显示 Solaris Resource Manager 和处理器组的简单组合。在该示例中，处理器组和 Solaris Resource Manager CPU 共享权混合。

1 号用户有 25 个 Solaris Resource Manager 共享权，规定使用处理器组 A（1 个 CPU）。2 号用户有 75 个 Solaris Resource Manager 共享权，规定使用处理器组 B（1 个 CPU）。

在这个示例中，2 号用户将占用其整个处理器组（系统的 50%）。由于 2 号用户只使用 50%（而不是分配给他的 75%），因此 1 号用户能使用其余的 50%。结果，每个用户都被给予系统的 50%。

较为复杂的示例

下面的示例是一个比较复杂的情况，处理器组和 Solaris Resource Manager CPU 共享权混合。

1 号用户和 3 号用户各有 10 个 Solaris Resource Manager 共享权，规定使用处理器组 A（1 个 CPU）。2 号用户有 80 个 Solaris Resource Manager 共享权，规定使用处理器组 B（1 个 CPU）。

在这个示例中，2 号用户将占用其整个处理器组（系统的 50%）。由于 2 号用户只使用 50%（而不是分配给他的 80%），因此 1 号用户和 3 号用户能使用其余的 50%。结果，尽管 1 号用户和 3 号用户各自只分配到 10 个共享权，他们分别得到系统的 25%。

应避免的情况

应该避免出现下面的情况。

在这种情况下，一个用户在两个处理器组中都有处理程序。1 号用户有 20 个 Solaris Resource Manager 共享权，并在每个处理器组中都有处理程序。2 号用户有 80 个 Solaris Resource Manager 共享权，规定使用处理器组 B（1 个 CPU）。

在这个示例中，1 号用户的第一个处理程序将占用其整个处理器组（系统的 50%）。由于 2 号用户被给予 80 个共享权，2 号用户的处理程序将占用其整个处理器组（系统的 50%）。于是，1 号用户的第二个处理程序将得不到 CPU 共享权。

示例

这一部分的示例说明 Solaris Resource Manager 的系统资源及分配控制功能和信息显示功能。

服务器合并

第一个示例说明这些命令：

liminfo

打印一名或多名用户的属性以及限制终端窗口

limadm

为一组用户改变限制属性或为其删除限制在数据库中的入口

srmadm

显示或设定操作模式和 Solaris Resource Manager 系统级别的可调节参数

srmstat

显示 lnode 节点活动信息

假设有两个服务器，每一个都在运行一个数据库应用程序，现在要将这两个服务器合并在一台机器上。简单地运行单台机器上的两个应用程序会得到工作系统。在没有 Solaris Resource Manager 的情况下，Solaris 系统在平等使用的基础上将资源分配给应用程序，而且并不保护一个应用程序不受另一个应用程序所提出的竞争请求的影响。Solaris Resource Manager 却可提供适当机制，防止应用程序遭受资源缺乏。若使用 Solaris Resource Manager，可通过启动附加到与数据库（ db1 和 db2）相关的 lnode 节点的每一个数据库来达到此目的。若要这样做，必须创建三个新的管理位置标识符用户，例如， databases、db1 和 db2。这三个用户被添加到限制数据库；由于 lnode 与 UNIX UID 对应，因此也必须将这三个用户添加到 passwd 文件（如果系统使用 NIS 或 NIS+ 之类的名称服务，则添加到口令映射）。假定 UID 被添加到 passwd 文件或口令映射，则使用以下命令将位置标识符用户 db1 和 db2 分配到 databases lnode 组：

# limadm set sgroup=0 databases
# limadm set sgroup=databases db1 db2

并假设 /usr/srm/bin 在用户路径中。

图形 10-1 服务器合并

由于没有其它被定义的组，databases 组目前占用整台机器。与数据库关联的两个 lnode 在运行，而运行数据库应用程序的进程则通过数据库例程的启动脚本中的 srmuser 命令附加到相应的 lnode。

# srmuser db1 /usr/bin/database1/init.db1
# srmuser db2 /usr/bin/database2/init.db2

当启动数据库 db1 或 db2 时，请使用 srmuser 命令以确保数据库附加到正确的 lnode 并正确收费（srmuser 不影响执行此操作的进程的拥有权）。要运行以上命令，用户必须拥有运行 init.db1 所需的 UNIX 许可和将进程附加到 lnode db1 的管理许可。当用户登入和使用数据库时，数据库执行的活动被传送至 lnode 节点 db1 和 db2。

使用每个 lnode 节点一个共享权的缺省分配，databases 组的使用将会逐渐平均，以便确保数据库 db1 和 db2 平均分配机器的使用。尤其是，有一个剩余共享权-适用于 databases 组-；而且 databases 拥有该共享权。lnode 节点 db1 和 db2 也被分别给予一个共享权的缺省分配。在 databases 组内，有两个剩余共享权，因此 db1 和 db2 获得 databases 资源之外的平等分配（在这个简单的示例中，没有竞争分配，因此 databases 拥有对整个系统的访问权）。

如果 1 号数据库需要机器 CPU 容量的 60%，而 2 号数据库需要其容量的 20%，管理员可以规定系统必须至少提供这些容量（假设应用程序有这样的要求），其方法是增加 cpu.shares 的数目，分配给 db1:

# limadm set cpu.shares=3 db1

现在，有四个剩余共享权在 databases 组；db1 有三个，而 db2 有一个。执行上述命令之后，这个改变立即生效。将有一段过渡时间，然后 lnode 节点 db1（1 号数据库）才会真正得到大于机器资源 60% 的分配部分，因为 Solaris Resource Manager 需要逐步平均机器使用。但是，视乎衰变总参数，这段时间不会太长。

若要在任何时候监视这项活动，可使用命令 liminfo（请参阅典型的应用程序服务器）和 srmstat，它们在不同的窗口里。注意，命令 srmstat 定期提供更新的显示。有关 srmstat 的更多信息，请参阅 srmstat(1SRM)。

现在，一台机器运行两个数据库应用程序，一个得到 75% 的资源，另一个得到 25% 的资源。请记住，root 是最高层群组长用户。处理程序作为 root 运行，若有需要，可使用整个系统。因此，应该建立更多的 lnode 节点，用于运行后援程序、守护程序和其它脚本，使 root 处理程序不能占用整个机器。若按传统方式运行，则有可能占用。

添加计算批处理应用程序用户

本示例介绍的是下列命令：

srmkill

用于中止附加到某一 lnode 的所有活动进程

财务部门拥有数据库系统，但来自工程部门的一个用户 (Joe) 必须运行一个计算任务，想在系统通常空闲的非高峰时间使用财务部门的机器。财务部门断定 Joe 的任务没有数据库重要，同意只在其不干扰系统的主要工作的条件下才可以运行他的工作。如要强制执行该策略，需将一个新的组 (batch) 加到 lnode database，并将 Joe 添加到服务器 lnode 分层结构中的新的 batch 组：

# limadm set cpu.shares=20 databases
# limadm set cpu.shares=1 batch
# limadm set cpu.shares=1 joe
# limadm set sgroup=batch joe

图形 10-2 添加计算批处理应用程序

该命令序列改变份额分配，以使 databases 组拥有 20 个份额，而使 batch 组只拥有一个。这就指定 batch 组的成员（只有 Joe），在 databases 组活动时最多只能使用机器的 1/21。而 databases 组收到 20/21 或者说百分之 95.2，多于以前确定为足够用来处理数据库工作的 60% + 20% = 80%。如果 databases 没有要求得到其全部分配，则 Joe 所收到的将多于分配给他的百分之 4.8。如果 databases 完全不活动，则 Joe 的分配可能会达到百分之 100。但分配给 databases 的未决份额的数目从 1 增加到 20 时，就没有必要对 db1 和 db2 的份额分配进行任何更改。在 databases 组内部，仍然有四个未决份额，其分配比率为 3:1。调度树的不同层次之间是完全独立的；关键是同级组之间的份额比率。

即使有了这些把握，财务部门仍旧想确保 Joe 无法在白天高峰时间登录。这在 batch 组上放置一些控制就可以办到。鉴于控制对一天内的时间敏感，实现起来可以是在一天开始和结束时运行一个脚本，从而改变 batch 组所允许的登录数目。例如，可以借助 crontab 条目加以实现，诸如：

0 6 * * * /usr/srm/bin/limadm set flag.nologin=set batch
0 18 * * * /usr/srm/bin/limadm set flag.nologin=clear batch

在早晨 6 点钟，batch 没有登录的许可，而在 18 点钟（下午 6 点钟），该限制被去除。

还可以实现一个更为严格的策略，方法是将另一行添加到 crontab 条目：

01 6 * * * /usr/srm/bin/srmkill joe

这使用的是 srmkill(1MSRM) 命令，用于在早晨 6 点零 1 分时中止任何附加到 lnode Joe 的进程。如果该任务所需的唯一资源正是 Solaris Resource Manager 所控制的资源的话，就没有这个必要。如果有理由认为 Joe 的任务可能会独占其它资源从而对正常工作造成干扰的话，就可以使用上述操作。例如某个任务使某个关键性的数据库锁定或者独占某个 I/O 通道。

现在 Joe 只能在夜间登录运行其任务了。由于 Joe（以及整个 batch 组）所拥有的份额比其它应用程序少得多，他的应用程序运行时只能使用百分之 5 的机器。同理， nice(1) 可以用来降低附加在该任务上的进程的优先级，从而使其运行时所拥有的优先级低于正在运行的其它拥有同等 Solaris Resource Manager 份额的任务。

现在，财务部门就确信其数据库应用程序可以对其系统进行足够的访问，且其工作不会互相干扰了。他们在提供 Joe 连夜批处理负载的同时，还确保他的工作不会干扰其关键任务的处理。

增加万维网前端进程

假设业已决定在 Database1 上放置一个万维网前端，但将该应用程序限制为只能 10 个用户同时登录。使用进程限制功能就能办到。

首先，创建一个名为 ws1 的新 lnode。您通过在 ws1 lnode 下启动 Webserver（万维网服务器）应用程序，就可以控制其可用的进程的数目，也就是活动 http 会话的数目。

图形 10-3 添加万维网前端进程

鉴于 Webserver 是 Database1 应用程序的一部分，您可以给予它一个 db1 lnode 份额，并允许它与 Database1 争用资源。给 Webserver 分配百分之 50 的计算机资源，而给 Database1 应用程序自身分配百分之 40：

# limadm set cpu.shares=6 ws1
# limadm set sgroup=db1 ws1
# limadm set cpu.myshares=4 db1
# srmuser ws1 /etc/bin/Webserver1/init.webserver 

最后一行启动 Webserver，并将应用程序装载到 ws1 lnode。注意，为 Database1 的 cpu.myshares 分配了 4。这就为 db1 与其子进程 Webserver 竞争份额设置了 4:6 的比率。

cpu.shares 显示分层结构中同级资源分配的比率，而 cpu.myshares 显示的是父节点正在积极运行应用程序时父:子节点的资源分配比率。Solaris Resource Manager 根据所有活动 lnode 在其各自层次上的未决份额的比率来进行资源分配，其中“各自层次”包括所有组父节点和所有子节点的 my.shares 。

如要控制 Webserver 可以运行的进程的数目，就为 ws1 lnode 放置一个进程限制。示例使用的是 20，因为一个 Webserver 查询通常产生 2 个进程，因而这实际上将活动 Webserver 查询的数目限制在 10：

# limadm set process.limit=20 ws1

现在业已将又一应用程序作为某个活动 lnode 下的一个叶节点添加到了调度树。如要在活动的父节点和子节点之间分布 CPU 资源，就使用 cpu.myshares 来将某些部分的可用资源分配给父节点，将某些分配给子节点。采用了进程限制，以便对一个 lnode 上的活动会话期间的数目加以限制。

添加更多有特殊内存要求的用户

本示例实现的是 CPU 共享、进程限制和登录控制等资源控制机制，并涉及到用于打印 lnode 和显示活动 lnode 的显示工具。

srmadm

管理 Solaris Resource Manager

limreport

输出关于所选用户的信息

limdaemon

指示守护程序在到达任何限制时发送消息

另一用户 Sally ，也为其应用程序要求在夜间使用机器。鉴于她的应用程序是 CPU 密集型的，为确保 Joe 的应用程序不受损害，需给 Sally 的虚拟内存利用率放置一个限制，既包括她的总利用率，也包括她的“每一进程”利用率：

# limadm set memory.limit=50M sally
# limadm set memory.plimit=25M sally

图形 10-4 添加更多的用户

如果 Sally 的应用程序试图超过她的总虚拟内存限制或者进程内存限制，limdaemon 命令将通过控制台通知 Sally 和系统管理员，业已超过了限制。

使用 limreport 命令来生成一个报告，显示正在系统上的人及其到目前为止的利用率。limreport 的一个典型运用就是在任意时刻查看谁在使用机器及其在用户分层结构中的状态如何。

% limreport 'flag.real' - uid sgroup lname cpu.shares cpu.usage |sort +1n +0n

limreport 拥有多个参数。在此示例中，对 'flag.real' 执行检查（仅查找 'real' lnode/UID）；破折号 ( -) 用来表示应使用的输出格式的缺省最佳推测，而参数表 'uid sgroup lname cpu.shares cpu.usage' 表示 limreport 应为每个将 flag.real 设为 TRUE 的 lnode 输出这五个参数。输出在第二列上被导向一个 UNIX 主排序，而在第一列上被导向一个次排序，从而提供一个谁正在使用服务器的简单报告。

任何拥有正确路径和许可的人，均可以在任意时刻借助 srmadm show 命令来检查 Solaris Resource Manager 的状态。这将输出一个格式化报告，显示 Solaris Resource Manager 及其主要配置参数的当前操作状态。这可以用于检查 Solaris Resource Manager 正在活动且所有的控制参数正在活动。还可以用于显示全局参数的值，诸如衰变速率以及 Solaris Resource Manager 数据仓库的位置。

在不让限制活动以及不让 CPU 调度活动的情况下，是有可能运行 Solaris Resource Manager 的，这一点对在启动时对 Solaris Resource Manager 进行调试和初始配置很有价值：

# srmadm set share=n:limits=n

跨部门共享机器

另外一个开发组想要购买此机器的升级产品（增加处理器和内存），以便可以在系统空闲时进行访问。两个组都可以从中受益。如要进行设置，需再建立一个新的组，名为 development，且是在与 databases 和 batch 相同的层次上。为 development 分配机器的百分之 33，因为是他们为原来的机器添置了另外百分之 50 的 CPU 能力和内存。

图形 10-5 共享机器，步骤 1

开发组拥有成百上千的用户。为了避免卷入对其资源的分散，需使用 Solaris Resource Manager 的管理标志功能，以便使开发系统管理员可以分配其资源。您依照多方联合商定的方案对操作和开放层次的限制加以设置，然后你们双方开始操作，对各自部分的机器进行控制。

如要为分层结构添加新的层次，请作为一个新的 lnode 添加 operations 组，并将 batch 和 databases 的父组改为 operations：

# limadm set sgroup=operations batch databases

如要设置管理标志：

# limadm set flag.admin=set operations development

鉴于在正常的环境下，所有的服务器都需要运行守护程序和备份程序，因而应当在另外的高层 lnode 上进行上述添加。

不要使用 root lnode，因为其没有限制。

图形 10-6 共享机器，步骤 2

正如在示例中所看到的那样，您可以使用 Solaris Resource Manager 来将多个不同类型的用户和应用程序整合在同一机器上。通过审慎使用 CPU 份额控制、虚拟内存限制、进程限制以及登录控制，您可以确保这些各式各样的应用程序只收到其需要且要求得到的资源。限制用于确保没有任何应用程序或者用户会对任何其他用户的或者用户组的应用程序构成不良影响。Solaris Resource Manager 支持一些简单的汇报工具，用于向用户和系统管理员显示任意时刻以及一段时间以来所发生的确切情况。报告生成功能可以用来跨应用程序和组显示资源利用的细节，以便进行容量规划和计费。

典型的应用程序服务器

在上面一节示例的结尾处用 liminfo 得出的 db1 列表会显示本输出。键入：

# liminfo db1

输出：

图形 10-7 liminfo 列出的内容

本节的其余部分描述图 9-7 中所产生的 liminfo 输出。请参考 liminfo(1SRM) 和 srm(5SRM) 以了解更多有关下面所描述的字段的信息。

• 来自 liminfo 命令的输出的前两行涉及 lnode UID 及其在 lnode 树中的位置等方面：

登录名称

来自于与所附加的 lnode 的 UID 相对应的口令映射的登录名称和初始 GID。每个 lnode 均与一个系统 UID 相关联。强烈建议为每个 lnode 创建一个系统帐户。在本实例中，一个占位 UID， db1 被用于数据库 1。

注意，Solaris Resource Manager 下的缺省 PAM 配置为登录时没有 lnode 的任何用户创建一个 lnode。按缺省值，由超级用户或者由某个设置了 uselimadm 标志的用户创建的 lnodes，在创建时以 lnode srmother 作为其父节点，如不存在，就将 root lnode 作为父节点。可以借助用于更改 lnode 属性的一般命令， limadm，对 lnode 的父节点进行更改。

Uid

附加到当前进程的 lnode 的 UID。通常与进程（已登录用户）的真实的 UID 相同，但在某些情况下（后面有描述），可能有所不同。

Gid

附加到当前进程的 lnode 的 GID。

R,Euid 和 R,Egid

当前进程的真实和有效 UID 和 GID。这与标准系统 id(1M) 命令所提供的信息相同。这不是严格与 Solaris Resource Manager 有关，而只是为了方便才加以显示的。如果 liminfo 是在显示有关某个用户的信息，而不是缺省的信息（即，是用登录名称或者 UID 作为变量提供的），则不显示这些字段。

Sgroup (uid) [sgroup]

lnode 树分层结构中父 lnode 的名称和 UID。如果是 root lnode，则为空。许多 Solaris Resource Manager 特性取决于某一 lnode 在树分层结构中所处的位置，因而这有助于用户跟踪连续的父 lnode，一直回到树的根。

• 在空白行之后，liminfo 的下面三行显示与 CPU 调度有关的字段。

Shares [cpu.shares]

这是分配给该用户的 CPU 权利份额的数目。这只能与有相同父节点的其它用户以及与该父节点本身的 Myshares 的值直接比较。管理员通常可以将某一具体调度组中的所有用户的份额设置为同一值（给予这些用户平等的权利）。该值通常为大于 1 的某个数，从而留有余地，使管理员可以在适当的时候减少某些用户的份额。

Myshares [cpu.myshares]

只有该用户有正在活动（即，附加有进程）的子 lnode 时才使用该值（即，如果其它 lnode 拥有该用户的 sgroup 值）。如果情况确实是这样，则该值给出的是附加到该 lnode 的相关的 CPU 值的份额，可以与附加到其子 lnode 的 CPU 值的份额进行对比。

Share

计算得出的当前用户有权使用的系统 CPU 资源的百分比。随着其他用户登录和注销（或者 lnode 变为活动或者不活动），该值也将发生变化，原因在于计算只会将活动的用户计算在内。该计算并不包含当前用户的最近利用率。

E-share

这是该用户的有效份额（即，只要该用户要求且其他用户也在要求得到各自的份额，该用户就可以在短期内得到的系统 CPU 资源的实际百分比）。可以将此看作当前 Solaris Resource Manager 愿意分配给该 lnode 的 CPU 资源。该值会随着时间的推移，用户使用（或者不使用）CPU 资源，而发生变化。活动但空闲（即，所附加的进程休眠），因而利用率较低的 lnode 将拥有一个高效的份额值。相应地，对于所附加的进程正在积极使用 CPU 的用户来讲，其有效份额十分小。

Usage [cpu.usage]

用于确定调度优先权的累计系统资源利用率。其典型情况是指示最近的 CPU 利用率，但有可能还将其他参数考虑在内。可以借助 srmadm 命令查看参数混成情况。该值的每一增量随着时间的推移而发生指数衰变，从而最终 Solaris Resource Manager 将资源利用率“忘记”。用半衰期表示该衰变的速率则非常容易，可以借助 srmadm 命令进行查看。

Accrued usage [cpu.accrue]

这与 cpu.usage 是同一资源累计衡量尺度，但是它从不衰变。Solaris Resource Manager 不直接采用它，但是它可被用于计费管理。不像利用率，这一值代表应组内和当前所有 lnodes 的计利用率的总和。

• 在第二个空白行之后，liminfo 的下面四行所显示的是与虚拟内存和终端利用率有关的四个字段：

Mem usage [memory.usage][memory.myusage]

这是所有附加到该 lnode 的进程的综合内存利用率。

如果所显示的是两个值，中间用斜杠 (/) 符号隔开，则该 lnode 是一个组长。而第一个值是整个调度组的利用率，而第二个值只是当前用户的利用率。

Mem limit [memory.limit]

附加到该 lnode 及其成员（如果确实有的话）的所有进程所允许有的最大内存利用率。即，组内所有进程以及附加到该组的所有进程的内存利用率总计不得超过该值。注意，在这个实例中，零 (0) 值指示没有限制。

Proc mem limit [memory.plimit]

每一进程内存限制是附加到该 lnode 及其成员的任意单个进程所允许有的最大内存利用率。

Mem accrue [memory.accrue]

memory.accrue 值是以字节-秒为单位进行测量的，指示的是一段时间以来所使用的内存资源总和。

Term usage [terminal.usage]

当前对组的连接时间进行收费的秒数。

Term accrue [terminal.accrue]

组所使用的连接时间的秒数。

Term limit [terminal.limit]

所允许的 terminal.usage 属性的最大值。如果为零，则无限制，除非受到继承的限制。

• 在第三个空白行之后，liminfo 显示输出的下面两行显示的是与用户和进程有关的字段：

Processes [process.usage][process.myusage]

这是附加到 lnode 的进程的数目。注意，这是进程，而不是某一进程内部的计数线程。

如果所显示的是两个值，中间用斜杠 (/) 符号隔开，则该 lnode 是一个组长。而第一个值是整个调度组的利用率，而第二个值只是当前用户的利用率。

Process limit [process.limit]

允许附加到此 lnode 节点及其成员的最大进程数量。

Current logins [logins]

该用户的同时 Solaris Resource Manager 登录会话期间的当前数目。当某个用户借助标准系统登录机制中的任意一个进行登录时（其中包括 login(1)，rlogin(1)-；等等，基本上任何使用 PAM 来进行鉴别并创建一个 utmp(4) 条目的机制），该计数器增加。当会话期间结束是则该计数器减少。

如果某个用户的 flag.onelogin 标志值为设置，则只允许该用户拥有一个 Solaris Resource Manager 登录会话期间。

• 在第四空白行之后，liminfo 的下面四行显示下列各字段：

Last used [lastused]

该字段显示的是 lnode 最后活动的时间。通常是用户最后注销的时间。

Directory

该用户的主目录（出于方便，所显示的是来自口令映射的项目，而不是来自 Solaris Resource Manager 的项目）。

Name

db1 (finger) 信息，通常是用户的名称（出于方便，所显示的是来自口令映射的项目，而不是来自 Solaris Resource Manager 的项目）。

shell

用户的初始登录 shell（出于方便，所显示的是来自口令映射的项目，而不是来自 Solaris Resource Manager 的项目）。

• 在第五空白行之后，liminfo 的最后一行显示下面这个字段：

Flags

这里显示的是值为设置的标志或者 lnode 中的组。所显示的每个标志都跟有后缀字符，指示设置标志的值和方式（例如，是明确来自本 lnode(+)，还是继承 (^) 得来的）。

在 Sun Cluster 3.0 Update 环境中配置 Solaris Resource Manager

有效拓扑

您可以在有效的 Sun Cluster 3.0 Update 拓扑上安装 Solaris Resource Manager。有关有效拓扑的描述，请参阅《Sun Cluster 3.0 12/01 概念》。

确定要求

在 Sun Cluster 环境中配置 Solaris Resource Manager 产品之前，您必须决定您想如何跨切换移交或故障移交来控制或跟踪资源。如果您将所有的群集节点配置为相同情形，则将以相同情形在主和备份节点上强制施行利用率限制。

在所有节点上的配置文件中，所有应用程序的配置参数不必相同，但所有的应用程序必须至少在该应用程序的所有的可能主机上的配置文件中予以表示。例如，如果应用程序 1 由 phys-schost-1 掌管，但可能被切换或因故障而移交给 phys-schost-2 或 phys-schost-3，则应用程序 1 必须包含在所有三个节点（phys-schost-1、phys-schost-2 和 phys-schost-3）的配置文件中。

Solaris Resource Manager 在利用率和应计参数方面十分灵活，Sun Cluster 几乎没有任何限制。配置选择取决于网站的需要。在配置您的系统之前，请考虑下列各节中的一般原则。

配置内存限制参数

当将 Solaris Resource Manager 产品用于 Sun 群集时，您应当恰当地配置内存限制，以避免应用程序不必要的故障移交或应用程序的来回反弹。原则上：

• 不要将内存限制设定得过低。

  当一个应用程序达到其内存限制时，其会因故障而被移交。这对于数据库应用程序特别重要，此时达到一个虚拟内存限制可能会产生不可预料的后果。

• 不要在主和备份节点上将内存限制配置为相同情形。

  在应用程序达到其内存限制且故障移交到一个带有相同内存限制的备份节点时，相同限制有可能会导致一种乒乓效应。在备份节点上，将内存限制设置得稍高一些。网站上的应用程序、资源和优先选择决定可以设置多高的限制。内存限制的不同有助于避免乒乓情况，并给予您按需要调整参数的时间。

• 务必要使用 Solaris Resource Manager 的内存限制功能来处理粗糙问题情况的负载平衡。

  例如，您可以使用内存限制来避免错误的应用程序耗用过量的资源。

使用应计利用率参数

有多个 Solaris Resource Manager 参数被用于跟踪系统资源的利用率应计:CPU 份额、登录数目和连接时间。但是，对于切换移交或故障移交的情形，在新的主机上，利用率应计数据（CPU 利用率、登录数目和连接时间）均将为所有得到切换移交或故障移交的应用程序缺省从零重新开始。应计数据并非自动跨节点得到转移。

如要避免使 Solaris Resource Manager 利用率应计报告特性的精确度失效，您可以创建脚本来从群集节点收集应计信息。因为在某一应计期间，一个应用程序有可能在其可能的主机中的任意一台上运行，该脚本应当从某一给定应用程序的所有可能的主机收集应计信息。有关更多信息，请参阅 第 9 章，利用率数据。

故障移交情形

在 Sun Cluster 上，Solaris Resource Manager 可以被配置为，无论是在正常的群集操作，还是在切换移交或故障移交情况下，lnode 配置 ( /var/srm/srmDB) 中所描述的资源分配配置保持不变。有关更多信息，请参阅份额分配示样。

以下章节为示例情况。

• 前两节（带有两个应用程序的的两节点群集和带有三个应用程序的两节点群集）显示整个节点的故障移交情况。

• 仅限于资源组的故障移交一节说明仅用于应用程序的故障移交操作。

在群集环境中，应用程序配置为资源组 (RG) 的部分。故障发生时，资源组及其关联的应用程序一起将故障移交至另一个节点。在以下示例中，在资源组 RG-1 中配置应用程序 1 (App-1)，在资源组 RG-2 中配置应用程序 2 (App-2)，在资源组 RG-3 中配置应用程序 3 (App-3)。

虽然分配份额的数目保持相同，但是分配给每个应用程序的 CPU 资源百分比将在故障移交后发生变化，这取决于运行在节点上的应用程序数和分配给每个活动的应用程序的份额数。

在这种情况下，假定以下配置。

• 所有应用程序配置在共同的父 lnode 之下。

• 应用程序是节点上仅有的活动进程。

• 限制数据库在群集的每个节点上配置相同。

带有两个应用程序的的两节点群集

您可以在一个两节点群集上配置两个应用程序，以便每个物理主机（phys-schost-1、phys-schost-2）均作为一个应用程序的缺省主机。每个物理主机均作为另一物理主机的备份节点。所有的应用程序必须在两个节点的 Solaris Resource Manager 限制数据库文件中得到表示。当群集正常运行时，每个应用程序在其缺省的主机上运行并由 Solaris Resource Manager 分配所有的 CPU 资源。

在一个故障移交或切换移交发生后，两个应用程序在单独一个节点上运行，其分配有配置文件中所指定的份额。例如，此配置文件指定为应用程序 1 分配 80 个份额，为应用程序 2 分配 20 个份额。

# limadm set cpu.shares=80 App-1 
# limadm set cpu.shares=20 App-2 
...

下图说明该配置的正常和故障移交操作。请注意，虽然分配的份额数量没有改变，但是每个应用程序的可用 CPU 资源百分比可以改变，这取决于分配到每个请求 CPU 时间的进程的份额数量。

带有三个应用程序的两节点群集

在一个带有三个应用程序的两节点群集上，您可以将其配置为，一个物理主机 (phys-schost-1) 是一个应用程序的缺省主机，而第二个物理主机 ( phys-schost-2) 是其余两个应用程序的缺省主机。假定以下示例限制每个节点上的数据库文件。当发生故障移交或切换移交时，限制数据库文件不改变。

# limadm set cpu.shares=50	 App-1
# limadm set cpu.shares=30	 App-2
# limadm set cpu.shares=20	 App-3
...

当群集正常运行时，应用程序 1 在其缺省主机 phys-schost-1 上获分配 50 个份额。这等于 100% 的 CPU 资源，因为在此节点上只有这一个应用程序请求 CPU 资源。在其缺省主机 phys-schost-2 上，应用程序 2 和 3 分别获分配 30 个和 20 个份额。在正常操作过程中，应用程序 2 将接收 60%，而应用程序 3 将接收 40% 的 CPU 资源。

如果发生故障移交或切换移交，且应用程序 1 切换移交至 phys-schost-2，则所有三个应用程序的份额保持相同，但是根据限制数据库文件，CPU 资源百分比将重新分配。

• 拥有 50 个份额的应用程序 1 接收 50% 的 CPU 资源。

• 拥有 30 个份额的应用程序 2 接收 30% 的 CPU 资源。

• 拥有 20 个份额的应用程序 3 接收 20% 的 CPU 资源。

下图说明该配置的正常和故障移交操作。

仅限于资源组的故障移交

在一个多个资源组拥有同一缺省主机的配置中，有可能让一个资源组（及其相关联的应用程序）故障移交或被切换移交到一个备份节点，而缺省的主机在群集中保持运行。

在故障移交过程中，故障移交的应用程序将依照备份节点上的配置文件中所指定的情形分配资源。在此示例中，主要节点和备份节点上的限制数据库文件拥有相同的配置。

例如，此样本配置文件指定应用程序 1 获分配 30 个份额，应用程序 2 获分配 60 个份额。

#
limadm set cpu.shares=30 App-1
# limadm set cpu.shares=60 App-2
# limadm set cpu.shares=60 App-3
... 

下图说明此配置的正常和故障移交操作，其中 RG-2（包含应用程序 2）将故障移交到 phys-schost-2。请注意，虽然分配的份额数量没有改变，但是每个应用程序的可用 CPU 资源百分比可以改变，这取决于分配到每个请求 CPU 时间的应用程序的份额数量。