test

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

可伸缩数据服务

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

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

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

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

注意：

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

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

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

说明： 以上内容说明了该图形。

负载平衡策略

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

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

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

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

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

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

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

例如，在电子商务站点中的顾客通过端口 80 使用普通的 HTTP 在他的购物车中装满商品，但要切换到端口 443 通过 SSL 来发送安全数据，以便通过信用卡支付购物车中的商品。

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

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

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

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