test

Sun Cluster 概念指南（适用于 Solaris OS）

数据服务项目配置

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

注 –

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

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

注 –

在叙及此功能的 Solaris 文档中，CPU 时间、进程、任务和类似的组件均称为“资源”。同时，Sun Cluster 文档使用术语“资源”来说明由 RGM 控制的实体。下一部分将使用术语“资源”指代由 RGM 控制的 Sun Cluster 实体。本部分使用术语“供应”指代 CPU 时间、进程和任务。

本部分提供了配置数据服务以在指定的 Solaris 9 project(4) 中启动进程的概念说明。本部分还介绍了用于规划的若干故障转移方案和建议以使用 Solaris 操作系统提供的管理功能。

有关管理功能的详细概念文档和过程文档，请参阅《System Administration Guide: Network Services》中的第 1  章 “Network Service (Overview)”。

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

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

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

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

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

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

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

  7. 使资源组联机。

要配置标准的 Resource_project_name 或 RG_project_name 属性，以便将 Solaris 项目 ID 与资源或资源组关联，请使用 -y 选项和 scrgadm(1M) 命令。将特性值设置为资源或资源组。有关属性定义，请参见《Sun Cluster Data Services Planning and Administration Guide for Solaris OS》中的附录 A “Standard Properties”。有关属性说明，请参阅 r_properties(5) 和 rg_properties(5)。

指定的项目名称必须存在于项目数据库 (/etc/project) 中，而超级用户必须配置为此命名项目的成员。有关项目名称数据库的概念信息，请参阅《System Administration Guide: Solaris Containers-Resource Management and Solaris Zones》中的第 2  章 “Projects and Tasks (Overview)”。有关项目文件语法的说明，请参阅 project(4)。

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

注 –

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

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

确定项目配置的要求

在 Sun Cluster 环境中配置数据服务以使用由 Solaris 提供的控制之前，必须先确定如何在切换或故障转移过程中控制和跟踪资源。配置新项目之前，请标识群集中的依赖性。例如，资源和资源组依赖于磁盘设备组。

使用通过 scrgadm(1M) 配置的 nodelist、failback、maximum_primaries 和 desired_primaries 资源组属性来标识资源组的节点列表优先级。

使用通过 scrgadm(1M) 和 scsetup(1M) 配置的 preferenced 和 failback 属性来确定磁盘设备组节点列表的优先级。

如果要对所有的群集节点进行同样的配置，则会对主节点和辅助节点强制执行同样的使用限制。对于所有节点配置文件中的所有应用程序，其项目配置参数不必相同。与应用程序相关联的所有项目至少可以在该应用程序的所有潜在主机上由项目数据库访问。假设应用程序 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) 在正常的群集操作中和切换或失效转移情况下进行分配。

以下部分是示例情况。

在 Sun Cluster 环境中，可将应用程序配置为资源的一部分。然后将资源配置为资源组 (RG) 的一部分。当发生故障转移时，资源组及其关联的应用程序将故障转移到另一个节点。以下示例中没有明确显示资源。假设每个资源仅有一个应用程序。

注 –

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

以下示例的约束包括：

虽然分配的份额数相同，但是在失效转移后，分配给每个应用程序的 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 分配到 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 时间的应用程序的份额数。

说明：上文介绍了此图形。