在 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 时间的应用程序的份额数量。