数据服务

数据服务这个术语用来描述诸如 Oracle 或 iPlanet Web Server 之类的第三方应用程序，该应用程序已配置为在群集上运行，而不是在一个单独的服务器上运行。数据服务包括应用程序、专用的 Sun Cluster 配置文件，以及控制下列应用程序操作的 Sun Cluster 管理方法。

• 启动

• 停止

• 监视并采取纠正措施

图形 3-4 将运行于单个应用程序服务器（单服务器模型）之上的应用程序与运行于群集（群集服务器模型）之上的同一应用程序进行比较。注意：从用户的观点来看，这两种配置没有任何区别，只是群集的应用程序可能运行速度更快、可用性更高而已。

图形 3-4 标准客户机/服务器配置与群集客户机/服务器配置

在单服务器模型中，可以对应用程序进行配置，以便通过公共网络接口（主机名）来访问该服务器。 主机名与物理服务器有关。

在群集服务器模型中，公共网络接口为逻辑主机名或共享地址。 术语网络资源通常是指逻辑主机名和共享地址。

某些数据服务要求将逻辑主机名或共享地址指定为网络接口 - 它们不可互换。 其他数据服务允许您指定逻辑主机名或共享地址中的一个。 有关必须指定的接口类型的详细信息，请参阅每项数据服务的安装与配置信息。

网络资源与具体的物理服务器无关 - 它可以在物理服务器之间进行移植。

最初，网络资源仅与一个节点（即主节点）有关联。 如果主节点出现故障，网络资源及应用程序资源将切换到另一群集节点（辅助节点）。 进行网络资源故障切换后，经过短暂延迟，应用程序资源就可以在辅助节点上继续正常运行。

图形 3-5 将单服务器模型与群集服务器模型进行比较。 注意：在群集服务器模型中，网络资源（即本例中的逻辑主机名）可以在两个或多个群集节点之间移动。 该应用程序已配置为使用这一逻辑主机名，而不使用与特定服务器相关的主机名。

图形 3-5 固定主机名与逻辑主机名

共享地址最初也仅与一个节点相关联。 这个节点被称为全局接口节点 (GIN)。 共享地址被用作与群集之间的单一网络接口。 这就是全局接口。

逻辑主机名模型与可伸缩服务模型之间的区别在于，在后一种模型中，每个节点在其回送接口上还配置有共享地址。 这种配置使同一数据服务的多个实例可以同时在几个节点上使用。 术语"可伸缩服务"是指可以通过添加额外的群集节点，为应用程序增加 CPU 方面的能力，从而增强性能。

如果 GIN 出现故障，将在另一个也在运行该应用程序的实例的节点上启用共享地址（因此这个节点就成为新的 GIN）。 或者，可以将共享地址可转移到之前未运行该应用程序的另一个群集节点上。

图形 3-6 将单服务器配置与可伸缩群集服务配置进行比较。 注意：在可伸缩服务配置中，共享地址出现在所有节点上。 与逻辑主机名用于故障转移数据服务的方式类似，应用程序已配置为使用这个共享地址，而不使用与特定服务器相关联的主机名。

图形 3-6 固定主机名与共享地址

数据服务方法

Sun Cluster 软件提供了一套服务管理方法。 这些方法在 Resource Group Manager (RGM) 的控制下运行，RGM 使用它们来启动、停止和监视群集节点上的应用程序。 这些方法连同群集框架软件和多主机磁盘一起，使应用程序能够实现故障转移或可伸缩的数据服务。

RGM 也管理群集中的资源，包括应用程序实例和网络资源（逻辑主机名和共享地址）。

除 Sun Cluster 软件提供的方法之外，SunPlex 系统还提供一个 API 和多种数据服务开发工具。 这些工具使应用程序编程人员能够开发所需要的数据服务方法，以使其他应用程序作为高度可用的数据服务与 Sun Cluster 软件一起运行。

Resource Group Manager (RGM)

RGM 将数据服务（应用程序）作为资源进行控制，而资源是由资源类型实现所管理的。 这些实现或者由 Sun 提供，或者由具有一个普通数据服务模板、数据服务开发库 API (DSDL API) 或资源管理 API (RMAPI) 的开发者创建。 群集管理员在称为资源组的容器中创建和管理资源。 RGM 根据群集成员关系的变化停止和启动所选节点上的资源组。

RGM 对资源和资源组进行操作。RGM 操作导致资源和资源组在联机和脱机状态之间进行转换。 "资源和资源组状态与设置"中提供了适用于资源和资源组的各种状态与设置的完整说明。

故障转移数据服务

如果正在运行数据服务的节点（主节点）发生故障，那么该服务会被移植到另一个工作节点而无需用户干预。 故障转移服务利用了故障转移资源组，它是一个用于应用程序实例资源和网络资源（逻辑主机名）的容器。逻辑主机名是一些可以配置到节点上的 IP 地址，然后自动在原始节点解除配置，并配置到另一节点上。

对于故障转移数据服务，应用程序实例仅在一个单独的节点上运行。 如果故障监视器检测到一个故障，它或者试图在同一节点上重新启动该实例，或者在另一个节点上启动实例（故障转移），这取决于该数据服务是如何配置的。

可伸缩数据服务

可伸缩数据服务对多个节点上的活动实例有潜能。 可伸缩服务使用两个资源组：利用可伸缩资源组来保存应用程序资源，利用故障转移资源组来保存可伸缩服务所依赖的网络资源（共享地址）。可伸缩资源组可以在多个节点上联机，因此服务的多个实例可以立刻运行。 以共享地址为主机的故障转移资源组每次只在一个节点上联机。 以可伸缩服务做主机的所有节点使用相同的共享地址来主持该服务。

服务请求通过一个单独的网络接口（全局接口）进入群集，并依据由负载平衡策略设置的几个预定义算法之一来将这些请求分发到节点。 群集可以使用负载平衡策略来平衡几个节点间的服务负载。 注意：在包含其他共享地址的不同节点上可以有多个全局接口。

对于可伸缩服务来说，应用程序实例在几个节点上同时运行。 如果拥有全局接口的节点出现故障，全局接口将切换到其他节点。 如果一个正在运行的应用程序实例发生故障，则该实例尝试在同一节点上重新启动。

如果应用程序实例不能在同一节点上重新启动，而另一个未使用的节点被配置运行该服务，那么该服务会切换到这个未使用的节点。 否则，它继续运行在那些剩余节点上，并且很可能会降低服务吞吐量。

---

注意：

每个应用程序实例的 TCP 状态与该实例一起保存在此节点上，而不是在全局接口节点上。 因此，全局接口节点上的故障不影响连接。

---

图形 3-7 显示了故障转移和可伸缩资源组的一个示例，以及在它们之间存在的对于可伸缩服务的依赖性。 此示例显示了三个资源组。 故障转移资源组包括高可用性的 DNS 应用程序资源，以及由高可用的 DNS 和 Apache Web 服务器共同使用的网络资源。 可伸缩资源组仅包括 Apache Web 服务器应用程序实例。 注意，资源组在可伸缩和故障转移资源组（实线）之间存在依赖性，而所有的 Apache 应用程序资源都依赖于网络资源 schost-2，这是一个共享地址（虚线）。

图形 3-7 故障转移与可伸缩资源组示例

可伸缩服务体系结构

群集联网的主要目标是为数据服务提供可伸缩性。 可伸缩性意味着随着提供给服务的负载的增加，在新的节点被添加到群集并运行新的服务器实例的同时，数据服务面对这种增加的工作负载能保持一个不变的响应时间。 我们将这样的服务称为可伸缩数据服务。 Web 服务是可伸缩数据服务的一个很好的示例。 通常，可伸缩数据服务由几个实例组成，每一个实例运行在群集的不同节点上。 在该服务的远程客户机看来，这些实例一起构成了一个单独的服务，并实现了该服务的功能。例如，我们可能会有一个由几个 httpd 守护程序组成的 Web 服务，并且这些守护程序在不同的节点上运行。 任何 httpd 守护程序都服务于一个客户请求。 服务于请求的守护程序依赖于负载平衡策略。 对客户机的回复看起来是来自该服务，而不是来自为该请求提供服务的特定守护程序。因此，整个情形看起来仍像一个单独的服务。

可伸缩服务由以下功能组成：

• 对可伸缩服务的联网基础结构支持

• 负载平衡

• 对联网和数据服务的支持（使用 Resource Group Manager）

下图描绘了可伸缩服务的体系结构。

图形 3-8 可伸缩服务体系结构

当前不作为全局接口主机的节点（代理节点）与它们的回送接口共享地址。 进入到全局接口的软件包被分发到基于可配置负载平衡策略的其他群集节点上。 下面介绍了可能的负载平衡策略。

负载平衡策略

负载平衡在响应时间和吞吐量上同时提高了可伸缩服务的性能。

可伸缩数据服务有两类： 纯粹服务和粘滞服务。纯粹服务就是它的任何实例都可以对客户机的请求作出响应的服务。 粘滞服务是客户机将请求发送到相同实例的那种服务。 那些请求不被重定向到其他实例。

纯粹服务使用加权的负载平衡策略。 在这种负载平衡策略下，客户机请求按缺省方式被均衡地分配到群集内的服务器实例之上。 例如，在具有三个节点的群集中，假设每个节点的加权为 1。 每个节点将代表该服务为来自客户机的请求中的 1/3 提供服务。 加权可以在任何时候由管理员通过 scrgadm(1M) 命令界面或通过 SunPlex Manager GUI 进行修改。

粘滞服务有两种风格：普通粘滞服务和通配粘滞服务。粘滞服务允许多个 TCP 连接上并行的应用程序级会话来共享状态内内存（应用程序会话状态）。

普通粘滞服务允许客户机在多个并行的 TCP 连接之间共享状态。 相对于正在监听单个端口的服务器实例，可以把该客户机说成是"粘滞的"。 假定实例保持打开状态并可访问，并且在服务处于联机状态时负载平衡策略不更改，将保证该客户机的所有服务请求都传给相同的服务器实例。

例如，客户机的 Web 浏览器通过三种不同 TCP 连接，连接到端口为 80 的共享 IP 地址，但在服务时这些连接正在相互交换各自缓存的会话信息。

粘滞策略的普遍化延伸到在相同实例场景后面交换会话信息的多个可伸缩服务。 当这些服务在相同实例场景后面交换会话信息时，相对于在不同端口上监听的相同节点上的多个服务器实例来说，可以说客户机是"粘滞的"。

例如在一个电子商务站点上，顾客使用端口 80 上的普通 HTTP 购买了许多商品并放入到购物车中，但是要切换到端口 443 上的 SSL，以发送安全数据，使用信用卡付款。

通配粘滞服务使用动态分配的端口号，但仍期望客户机请求去往相同的节点。 相对于相同的 IP 地址来说，客户机就是端口上的"粘滞通配"。

被动模式 FTP 是这一策略的一个好例子。 客户机连接到端口 21 上的 FTP 服务器，并接着被服务器通知须连接回动态端口范围中的收听器端口服务器。 此 IP 地址的所有请求都被转发到服务器通过控制信息通知客户的相同节点上。

请注意，对于每个粘滞策略，加权的负载平衡策略都是缺省生效的，从而使客户的最初请求被定向到由负载平衡程序指定的实例。 在客户机已经为正运行着实例的节点建立一种亲密关系之后，只要该节点可访问并且负载平衡策略未更改，以后的请求就会定向到此实例。

关于特定的负载平衡策略的补充详细信息在下面进行讨论。

• 加权的。 根据指定的加权值在各种节点间分配负载。 此策略是使用 Load_balancing_weights 特性的 LB_WEIGHTED 值设置的。 如果一个节点的加权未明显地设置，则会使用此节点的缺省加权值 1。

  注意，这一策略不是循环共享的。 循环共享策略总是会使来自客户机的每个请求到达不同的节点：第一个请求到达节点 1，第二个请求到达节点 2，以此类推。 这种加权策略保证了来自客户机的一定比例的流量直接到达特定的节点。 此策略不对个别请求寻址。

• 粘滞的。 在此策略中，端口的设置在配置应用程序资源时就已经知道了。 此策略是使用 Load_balancing_policy 资源特性的 LB_STICKY 值设置的。

• 粘滞通配符。 此策略是普通"粘滞"策略的超集。 对于由 IP 地址识别的可伸缩服务，端口由服务器来分配（并且事先不知道）。 端口可能会变化。 此策略是使用 Load_balancing_policy 资源特性的 LB_STICKY_WILD 值设置的。

故障返回设置

资源组在一个节点出现故障时转移到另一个节点。 出现这种情况时，原始的辅助节点成为新的主节点。 故障返回设置指定了在原始主节点恢复联机状态时将进行的操作。 选项包括使原始的主节点重新恢复为主节点（故障返回）或仍保留当前的主节点。 使用故障返回资源组特性设置指定需要的选项。

在某些情况下，如果包含资源组的原始节点正在反复地发生故障并重新引导，则设置故障返回可能会降低资源组的可用性。

数据服务故障监视器

每个 SunPlex 数据服务都提供一个故障监视器来定期探测数据服务，确定其是否完好。 故障监视器检验应用程序守护程序是否在运行并且客户机正在接受服务。 基于探测所返回的信息，可以启动一些预定义的操作，比如重新启动守护程序或进行故障转移。