test

Sun Cluster 3.0 概念

数据服务

术语数据服务是用来描述诸如 Apache Web Server 之类的第三方应用 程序，该应用程序已被配置在群集上运行，而不是在一个单独的服务器上运行。数据服务包括启动、关闭和监视应用程序的应用程序软件和 Sun Cluster 软件。

Sun Cluster 提供在群集内控制和监视应用程序的数据服务方法。这些方法在 Resource Group Manager (RGM) 的控制下 运行，RGM 使用它们来启动、停止和监视群集节点上的应用程序。这些方法在与群集框架软件和多主机磁盘一起时，使应用程序 能够成为高可用性的数据服务。作为高可用性的数据服务，它们防止了在群集内任何单独的故障后发生显著的 应用程序中断。故障可能发生在一个节点上、一个接口组件上，或者发生在应用程序本身。

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

Sun Cluster 也提供了 API 和数据服务开发工具，使应用程序编程人员能够开发所需要的数据服务方法， 以使其他应用程序作为高可用性的数据服务与 Sun Cluster 一起运行。

Resource Group Manager (RGM)

Sun Cluster 提供使应用程序变得高可用性和可伸缩的环境。RGM 作为资源运行，资源是具有下面特性的逻辑组件：

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

失败切换数据服务

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

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

可伸缩数据服务

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

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

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

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

注意：

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

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

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

Graphic

可伸缩服务体系结构

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

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

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

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

Graphic

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

负载平衡策略

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

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

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

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

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

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

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

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

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

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

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

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

失败返回设置

资源组从一个节点失败切换到另一个。您可以指定，如果一个资源组失败切换到另一个节点，在它先前在上面运行的那个节点 回到群集以后，它就会“失败返回”到原始的节点。这一选项是使用 Failback 资源组属性设置进行设定的。

在某些情况下，例如，如果以资源组为主机的原始节点正在重复地发生故障并重新引导，设置失败返回可能会导致资源组减少可用性。

数据服务故障监视器

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