数据服务

数据服务这个术语用来说明已配置为在群集上运行、而不是在一个单独的服务器上运行的应用程序，如 Sun Java System Web Server 或 Oracle。数据服务由应用程序、专用的 Sun Cluster 配置文件以及控制以下应用程序操作的 Sun Cluster 管理方法组成。

• 启动

• 停止

• 监视并采取纠正措施

有关数据服务类型的信息，请参见《Sun Cluster 概述（适用于 Solaris OS）》中的“数据服务”。

图 3–4 比较了在单个应用服务器上运行的应用程序（单服务器模型）与在群集（群集服务器模型）上运行的相同应用程序。这两种配置之间的唯一区别是群集应用程序运行速度更快、可用性更高。

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

在单服务器模型中，可以将应用程序配置为通过特定的公共网络接口（一个主机名）访问服务器。主机名与物理服务器有关。

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

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

网络资源与特定的物理服务器无关。网络资源可以在物理服务器之间进行迁移。

网络资源初始与一个节点（主节点）相关联。如果主节点发生故障，网络资源和应用程序资源将故障转移到另一个群集节点（辅助节点）上。进行网络资源故障转移后，经过短暂延迟，应用程序资源就可以在辅助节点上继续正常运行。

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

图 3–5 固定主机名与逻辑主机名

共享地址初始与一个节点相关联。这个节点被称为全局接口节点。共享地址（也称为全局接口）被用作群集的单一网络接口。

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

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

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

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

数据服务方法

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

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

除 Sun Cluster 软件提供的方法之外，Sun Cluster 系统还提供了 API 和若干数据服务开发工具。这些工具使应用程序开发者能够开发所需要的数据服务方法，以使其他应用程序作为高可用性数据服务与 Sun Cluster 软件一起运行。

故障转移数据服务

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

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

可伸缩数据服务

可伸缩数据服务对多个节点上的活动实例有潜能。可伸缩数据服务使用以下两个资源组：

• 可伸缩资源组，包含应用程序资源。

• 故障转移资源组，包含可伸缩服务依赖的网络资源（共享地址）。

可伸缩资源组可以在多个节点上联机，因此服务的多个实例可以立刻运行。以共享地址为主机的失效转移资源组每次只在一个节点上联机。提供可伸缩服务的所有节点使用同一共享地址来提供该服务。

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

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

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

---

注 –

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

---

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

图 3–7 SPARC: 失效转移和可伸缩资源组示例

负载平衡策略

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

• 纯粹

• 粘滞

纯粹服务可以使任何实例都可以对客户机的请求作出响应。粘滞服务使客户机将请求发送到同一实例。那些请求不被重定向到其它实例。

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

粘滞服务有两种：普通粘滞服务和通配粘滞服务。粘滞服务使多个 TCP 连接上并发的应用程序级会话可以共享状态内内存（应用程序会话状态）。

普通粘滞服务使客户机可以在多个并发的 TCP 连接之间共享状态。相对于服务器实例在单个端口上侦听的情况，称该客户机是“粘滞”的。如果实例保持打开状态并可访问，并且在服务处于联机状态时未改变负载平衡策略，则可以保证该客户机的所有服务请求都传给相同的服务器实例。

例如，客户机上的 Web 浏览器在端口 80 使用三种不同的 TCP 连接连接到共享 IP 地址。但在服务时，这些连接将在它们之间交换缓存的会话信息。

可以将粘滞策略的本义延伸到在后台在相同实例上交换会话信息的多个可伸缩服务。当这些服务在后台在相同实例上交换会话信息时，可以说客户机相对于在不同端口上侦听的同一节点上的多个服务器实例是“粘滞的”。

例如，顾客在电子商务站点中通过在端口 80 使用 HTTP 向其购物车中添加商品。然后该顾客切换到端口 443 通过 SSL 来发送安全数据，以便通过信用卡为购物车中的商品进行支付。

通配粘滞服务使用动态分配的端口号，但仍期望客户机请求去往相同的节点。客户机就是端口（具有相同 IP 地址）上的“粘滞通配”。

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

默认情况下，对于每种粘滞策略，加权的负载平衡策略都是有效的。因此，客户的最初请求被定向到由负载平衡器指定的实例。在客户机为正运行实例的节点建立一种关联之后，以后的请求就会条件性地被定向到此实例。该节点必须可访问并且负载平衡策略未被更改。

有关特定的负载平衡策略的其他详细信息如下所示。

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

  这种加权策略将来自客户机的一定比例的流量重定向到特定的节点。如果 X=加权值，A=所有活动节点的总加权值，则大约 X/A 的新连接总数将定向到该活动节点。但是，此连接总数必须足够大。此策略不对个别请求寻址。

  注意，这一策略不是循环共享的。循环（共享）策略总是会使来自客户机的每个请求到达不同的节点。例如，第一个请求到达节点 1，第二个请求到达节点 2，以此类推。

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

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

故障返回设置

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

如果托管资源组的原始节点再三地发生故障和重新引导，则设置故障返回可能会降低资源组的可用性。

数据服务故障监视器

每个 Sun Cluster 数据服务都具有一个故障监视器，该监视器定期探测数据服务以确定其运行情况是否良好。故障监视器将验证应用程序守护进程是否正在运行，还将验证客户机是否正接受服务。基于由探测返回的信息，可以启动一些预定义的操作，比如重新启动守护进程或引起故障转移。