可伸缩数据服务

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

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

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

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

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

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

图形 3-4 失败切换与可伸缩资源组实例

可伸缩服务体系结构

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

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

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

• 负载平衡

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

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

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

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

负载平衡策略

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

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

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

粘滞服务有两种风格，普通粘滞和通配粘滞。粘滞服务允许多个 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 值设置的。