数据服务

术语数据服务指被配置为在群集而不是在单一服务器上运行的第三方应用程序，如 Sun Java System Web Server（以前的 Sun Java System Web Server），以及基于 SPARC 的群集上的 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 软件提供的方法之外，SunPlex 系统还提供一个 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 浏览器连接到使用三种不同 TCP 连接，连接到端口为 80 的共享 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 值设置的。

恢复设置

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

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

数据服务故障监视器

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