数据服务项目配置

可以将数据服务配置为在使用 RGM 联机时，在 Solaris 项目名称下启动。 该配置将 RGM 管理的资源或资源组与 Solaris 项目 ID 相关联。 从资源或资源组到项目 ID 的映射使您能够使用 Solaris 环境中提供的高级控制来管理群集中的工作量和消耗量。

只有运行具有 Solaris 9 的 Sun Cluster 软件的当前版本时，才能执行此配置。

通过在群集环境中使用 Solaris 管理功能，可以确保大多数重要的应用程序在与其它应用程序共享一个节点时具有优先权。 如果采用统一服务，或者由于应用程序发生失效转移，则多个应用程序可能共享一个节点。 使用此处介绍的管理功能，可以防止其它优先级较低的应用程序过多地消耗系统供应（如 CPU 时间），从而提高重要应用程序的可用性。

有关此功能的 Solaris 文档介绍了 CPU 时间、进程、任务和类似的组件（如资源）。 同时，Sun Cluster 文档采用术语“资源”来说明由 RGM 控制的实体。 以下部分将采用术语“资源”指代由 RGM 控制的 Sun Cluster 实体，并采用术语“供应”指代 CPU 时间、进程和任务。

本部分介绍了将数据服务配置为在指定的 Solaris 9 project(4) 中启动的进程的概念说明。 本部分还介绍了若干失效转移情况，以及规划使用 Solaris 环境提供的管理功能的建议。 有关管理功能的详细概念文档和过程文档，请参见 Solaris 9 System Administrator Collection 中的 System Administration Guide: Resource Management and Network Services。

当在群集中将资源和资源组配置为使用 Solaris 管理功能时，请考虑使用以下高级进程：

1. 将应用程序配置为资源的一部分。

2. 将资源配置为资源组的一部分。

3. 启用资源组中的资源。

4. 使资源组处于管理状态。

5. 为资源组创建一个 Solaris 项目。

6. 配置标准特性，使资源组名称与步骤 5 中创建的项目相关联。

7. 使资源组联机。

要配置标准的 Resource_project_name 或 RG_project_name 特性，以便将 Solaris 项目 ID 与资源或资源组相关联，请使用 -y 选项和scrgadm(1M) 命令。 将特性值设置为资源或资源组。 有关特性定义，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“标准特性”。 有关特性说明，请参阅r_properties(5) 和rg_properties(5)。

指定的项目名称必须存在于项目数据库 ( /etc/project) 中，而 root 用户必须被配置为此命名项目的成员。 有关项目名称数据库的概念信息，请参见 Solaris 9 System Administrator Collection 中 System Administration Guide: Resource Management and Network Services 中的“Projects and Tasks”。 有关项目文件语法的说明，请参见 project( 4)。

当 RGM 将资源或资源组联机时，它将启动项目名称下的相关进程。

用户可以随时将资源或资源组与项目相关联。 但是，必须使用 RGM 将资源或资源组脱机，然后再联机，新的项目名称才有效。

通过启动项目名称下的资源和资源组，您可以配置以下功能，以便在群集中管理系统供应。

• 扩展记帐 – 提供一个用于以任务或进程为基础记录消耗的灵活方式。 扩展记帐用于检查历史使用情况，以及估定将来工作量的容量要求。

• 控制 – 提供一个用于系统供应约束的机制。 可以防止进程、任务和项目消耗大量的指定系统供应。

• 公平共享调度 (FSS) – 可以根据工作量的重要性，控制可用 CPU 时间在工作量之间的分配。 工作量重要性是由分配给每个工作量的 CPU 时间的份额数表示的。 有关将 FSS 设置为缺省调度程序的命令行描述，请参见 dispadmin (1M)。 有关详细信息，请参阅priocntl(1)、ps(1) 和 FSS(7)。

• 池 – 可以根据应用程序的要求使用交互式应用程序的分区。 池可以用于对支持许多不同软件应用程序的服务器进行分区。 使用池可以使每个应用程序的响应更加容易预测。

确定项目配置的要求

在 Sun Cluster 环境中配置数据服务以使用由 Solaris 提供的控制之前，必须确定要如何在切换或失效转移过程中控制和跟踪资源。 配置新项目之前请考虑标识群集中的相关性。 例如，资源和资源组依赖于磁盘设备组。 使用通过 scrgadm (1M) 配置的 nodelist、failback 、maximum_primaries 和 desired_primaries 资源组特性来标识资源组的节点列表优先级。 有关资源组和磁盘设备组之间的节点列表依赖性的简要讨论，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“资源组和磁盘设备组之间的关系”。 有关特性的详细说明，请参见 rg_properties (5)。

使用通过 scrgadm( 1M) 和 scsetup( 1M) 配置的 preferenced 和 failback 特性来确定磁盘设备组节点列表的优先级。 有关过程信息，请参阅《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理磁盘设备组”的“如何更改磁盘设备特性”。 有关节点配置以及失效转移和可伸缩数据服务方式的概念信息，请参见SunPlex 系统硬件和软件组件。

如果要对所有的群集节点进行同样的配置，则会对主节点和辅助节点强制执行同样的使用限制。 对于所有节点配置文件中的所有应用程序，其项目配置参数不必相互一致。 与应用程序相关联的所有项目必须至少可以在该应用程序的所有潜在主控主机上由项目数据库访问。 假设应用程序 1 由 phys-schost-1 控制，但是可以切换或失效转移到 phys-schost-2 或 phys-schost-3。 那么必须在这三个节点 (phys-schost-1 、phys-schost-2 和 phys-schost-3) 上都能访问与应用程序 1 关联的项目。

项目数据库信息可以是本地 /etc/project 数据库文件，也可以存储在 NIS 映射或 LDAP 目录服务中。

Solaris 环境允许对使用参数进行灵活配置，而且 Sun Cluster 的限制很少。 配置选项取决于站点的需求。 在对系统进行配置之前，请考虑以下部分中的一般原则。

设置每个进程的虚拟内存限制

设置 process.max-address-space 控制，以便限制以每个进程为基础的虚拟内存。 有关设置 process.max-address-space 值的详细信息，请参见 rctladm( 1M)。

当对 Sun Cluster 使用管理控制时，请正确配置内存限制，以防止不必要的应用程序失效转移和应用程序的“乒乓”效果。 通常情况下：

• 请勿将内存限制设置得过低。

  当应用程序到达内存限制时，可能会发生失效转移。 由于数据库应用程序到达虚拟内存限制时可能出现意外后果，因此此原则对于数据库应用程序尤为重要。

• 请勿对主节点和辅助节点设置相同的内存限制。

  如果设置了相同的内存限制，当应用程序到达内存限制并进行失效转移，切换到具有相同内存限制的辅助节点时，可能导致乒乓效果。 请将辅助节点的内存限制设置得略高一些。 内存限制差别有助于防止乒乓情况的出现，并可以使系统管理员有时间根据需要对参数进行调整。

• 请务必为负载平衡使用资源管理内存限制。

  例如，使用内存限制可以防止错误的应用程序消耗过多的交换空间。

失效转移情况

可以对管理参数进行配置，以便项目配置 (/etc/project) 在正常的群集操作中和切换或失效转移情况下进行分配。

以下部分是示例情况。

• 前两部分，即“具有两个应用程序的双节点群集“和“具有三个应用程序的双节点群集“，显示了整个节点的失效转移情况。

• “仅限资源组的失效转移“部分说明了仅一个应用程序的失效转移操作。

在群集环境中，应用程序配置为资源的一部分，而资源配置为资源组 (RG) 的一部分。 当发生失效转移时，资源组及其关联的应用程序将进行失效转移，切换到另一个节点。 以下示例中没有明确显示资源。 假设每个资源仅有一个应用程序。

按照 RGM 中设置的首选节点列表顺序进行失效转移。

以下示例的约束包括：

• 应用程序 1 (App-1) 配置于资源组 RG-1 中。

• 应用程序 2 (App-2) 配置于资源组 RG-2 中。

• 应用程序 3 (App-3) 配置于资源组 RG-3 中。

虽然分配的份额数相同，但是在失效转移后，分配给每个应用程序的 CPU 时间的比例将发生变化。 此比例取决于节点上运行的应用程序数，以及分配给每个活动的应用程序的份额数。

在以上情况下，假设采用了以下配置。

• 所有应用程序均在通用项目下配置。

• 每个资源都仅有一个应用程序。

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

• 群集中每个节点上的项目数据库配置相同。

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

您可以在双节点群集上配置两个应用程序，以确保每个物理主机（phys-schost-1 和 phys-schost-2）都充当一个应用程序的缺省主节点。 每个物理主机都充当另一个物理主机的辅助节点。 两个节点上的项目数据库文件中必须表示与应用程序 1 和应用程序 2 关联的所有项目。 当群集正常运行时，每个应用程序均运行在各自的缺省主控主机上，在其中管理设备为其分配了所有的 CPU 时间。

发生失效转移或切换后，两个应用程序均运行在一个节点上，在该节点上，应用程序会分配到配置文件中所指定的相应份额。 例如，/etc/project 文件中的相应项指定应用程序 1 分配到 4 份份额，应用程序 2 分配到 1 份份额。

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

下图说明了此配置的正常操作和失效转移操作。 分配的份额数不变。 但是，根据分配给每个请求 CPU 时间的进程的份额数不同，每个应用程序可用的 CPU 时间比例可能发生变化。

具有三个应用程序的双节点群集

在具有三个应用程序的双节点群集上，您可以将一个物理主机 (phys-schost-1) 配置为一个应用程序的缺省主节点，而将第二个物理主机 (phys-schost-2) 配置为其余两个应用程序的缺省主节点。 假设在每个节点上采用以下示例项目数据库文件。 当发生失效转移或切换时，该项目数据库文件不发生变化。

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)  

当群集正常运行时，应用程序 1 在其缺省主控主机（phys-schost-1）上分配到 5 份份额。 此份额数相当于 100% 的 CPU 时间，因为应用程序1 是该节点上唯一一个请求 CPU 时间的应用程序。 应用程序 2 和应用程序 3 分别在缺省主控主机（phys-schost-2 ）上分配到 3 份和 2 份份额。 正常操作过程中，应用程序 2 将分配到 60% 的 CPU 时间，而应用程序 3 将分配到 40% 的 CPU 时间。

如果发生了失效转移或切换，且应用程序 1 切换到 phys-schost-2，则三个应用程序的份额都相同。 但是，CPU 资源的比例将根据项目数据库文件重新进行分配。

• 应用程序 1 拥有 5 份份额，分配到 50% 的 CPU。

• 应用程序 2 拥有 3 份份额，分配到 30% 的 CPU。

• 应用程序 3 拥有 2 份份额，分配到 20% 的 CPU。

下图说明了此配置的正常操作和失效转移操作。

仅限资源组的失效转移

在多个资源组具有相同的缺省主控主机的配置中，资源组（及其关联的应用程序）可以进行失效转移或切换到辅助节点。 同时，缺省主控主机运行于群集中。

失效转移过程中，发生失效转移的应用程序分配到的资源与辅助节点上的配置文件所指定的资源相同。 在此示例中，主节点和辅助节点上的项目数据库文件具有相同的配置。

例如，此样例配置文件指定应用程序 1 分配到 1 份份额，应用程序 2 分配到 2 份份额，应用程序 3 分配到 2 份份额。

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

下图说明了此配置的正常操作和失效转移操作，其中包含应用程序 2 的 RG-2 进行失效转移，切换到 phys-schost-2。 请注意，分配的份额数不变。 但是，根据分配给每个请求 CPU 时间的应用程序的份额数不同，每个应用程序可用的 CPU 时间比例可能发生变化。