黑基网 首页 服务器 Linux 查看内容

Sun Cluster 3.0 重要概念 管理和应用程序开发

2005-6-7 04:10| 投稿: Linux

摘要: 本章介绍了 Sun 群集配置的软件组件的一些相关的重要概念。包括下列主题: 管理接口 ...
本章介绍了 Sun 群集配置的软件组件的一些相关的重要概念。包括下列主题: 管理接口 群集时间 高可用性框架 全局设备 磁盘设备组 全局名称空间 群集文件系统 定额和定额设备 卷管理器 数据服务 开发新的数据服务 资源和资源类型 公共网络管理 (PNM) 和网络适配器失败切换 (NAFO) 群集管理和应用程序开发 此信息主要面向使用 Sun Cluster API 和 SDK 的系统管理员和应用程序开发人员。系统管理员可以将此信息作为安装、配置和管理群集软件的背景知识。应用程序开发人员可以通过此信息来了解他们工作的群集环境。 下图从较高的层次上显示了群集管理概念与群集体系结构之间的映射关系。 6 - Sun Cluster 软件体系结构 管理接口 您可以从几个用户界面中选择一个来安装、配置和管理 Sun Cluster 和 Sun Cluster 数据服务。还可以通过命令行接口来完成系统管理任务。在命令行接口顶部有一些实用程序可用来简化选定的配置任务。Sun Cluster 还有一个模块作为 Sun Management Center 的一部分运行,可为某些群集任务提供 GUI。关于管理接口的完整说明,可参见 Sun Cluster 3.0 系统管理指南 中包括介绍性内容的一章。 群集时间 群集中的所有节点之间的时间必须同步。是否让群集节点与外部时间源同步对群集运行来说并不重要。Sun Cluster 采用 “网络时间协议 (NTP)”来同步节点间的时钟。 通常,系统时钟一秒种的时间改变不会造成问题。然而,如果要在活动的群集中运行 date(1) 、 rdate(1M) 或 xntpdate(1M) (以交互方式或在 cron 脚本内)命令,就会强制执行远大于一秒钟这一时间片断的时间改变,以使系统时钟与时间源同步。这一强制改变会给文件修改时间戳记带来问题,或造成 NTP 服务混乱。 在每个群集节点上安装 Solaris 操作环境时,您有机会改变节点的缺省时间和日期设置。一般情况下,可以接受出厂缺省设置。 使用 scinstall(1M) 来安装 Sun Cluster 时,其中有一步是配置群集的 NTP。Sun Cluster 提供一个模板文件 ntp.cluster (参见安装的群集节点上的 /etc/inet/ntp.cluster ),它建立了所有群集节点间的同等关系,其中有一个节点是“首选”节点。节点由它们的专用主机名标识,时间同步发生在群集互连上。关于如何配置 NTP 的群集方面的说明包括在 Sun Cluster 3.0 安装指南 中。 或者您也可以在群集之外设置一个或多个 NTP 服务器,并更改 ntp.conf 文件使之能反映出这一配置。 正常运行时,绝不需要调整群集的时间。然而,如果安装 Solaris 操作环境时时间设置不正确,现在想更改时间,可在 Sun Cluster 3.0 系统管理指南 中找到操作步骤。 高可用性框架 Sun Cluster 使用户和数据间“路径”上的所有组件都高度可用,这些组件包括网络接口、应用程序本身、文件系统和多主机磁盘。一般情况下,如果一个群集组件可从系统中的任何单一(软件或硬件)故障中恢复,则它是高度可用的。 下表显示了 Sun Cluster 组件故障种类(硬件和软件)和高可用性框架中建立的恢复种类。 2 - Sun Cluster 故障检测和恢复级别 群集资源故障 软件恢复 硬件恢复 数据服务 HA API,HA 框架 N/A 公共网络适配器 网络适配器失败切换 (NAFO) 多个公共网络适配器卡 群集文件系统 主要和辅助复制 多主机磁盘 镜像多主机磁盘 卷管理(Solstice DiskSuite 和 VERITAS 卷管理器) 硬件 RAID-5(例如 Sun StorEdge A3x00) 全局设备 主要和辅助复制 到设备、群集传输结点的多个路径 专用网 HA 传输软件 多个专用硬件独立网络 节点 CMM,失败快速保护驱动程序 多个节点 Sun Cluster 高可用性框架可迅速检测到节点故障,并在群集中的其余节点上为该框架资源创建一个新的等效服务器。不会出现所有框架资源都不可用的情况。在恢复期间,未受崩溃节点影响的框架资源是完全可用的。而且,故障节点的框架资源一恢复就立即可用。已恢复的框架资源不必等待其他所有框架资源都完全恢复。 可用性最高的框架资源恢复过程对于使用它的应用程序(数据服务)来说是透明的。框架资源访问的语义在整个节点故障期间得到全面的保护。应用程序根本不知道框架资源已转移到另一节点。单个节点的故障对于在使用着该节点上的文件、设备和磁盘卷的其他节点上的程序来说,是完全透明的。多主机磁盘的使用就是一个例证,这些磁盘具有连接多个节点的端口。 群集成员监视器 群集成员监视器 (CMM) 是一个分布式代理程序集,每个群集成员有一个代理程序。这些代理程序在群集互连中交换信息,以便: 在所有节点上保持一致的成员视图(定额) 使用注册的回叫来驱动同步重新配置,以响应成员更改 处理群集划分(群集分割,失忆) 保证所有群集成员间的充分连通性 与 Sun Cluster 的上一发行版不同,CMM 是完全在内核中运行的。 群集成员 CMM 的主要功能是,在任一给定时间加入群集的节点集上建立一个群集范围的协议。Sun Cluster 将此约束称作 群集成员 。 为确定群集成员并最终保证数据的完整性,CMM: 说明群集成员的更改,如某个节点加入或脱离群集 保证“故障”节点脱离群集 保证“故障”节点在修复前不进入群集 防止群集将自身划分一些节点子集 有关群集如何防止自身划分多个独立群集的详细信息,请参见 定额和定额设备 。 群集成员监视器重新配置 为确保数据免遭破坏,所有节点必须在群集成员上达成一致协议。需要时,CMM 将协调群集服务(应用程序)的群集重新配置,以作为对故障的响应。 CMM 会从群集传输层接收到关于与其他节点连通性的信息。CMM 使用群集互连在重新配置期间交换状态信息。 检测到群集成员有更改后,CMM 执行群集的同步配置,这时群集资源可能会按群集新的成员被重新分配。 群集配置库 (CCR) 群集配置库 (CCR) 是专用的群集范围的数据库,用于保存与群集的配置和状态有关的信息。CCR 是一个分布式数据库。每个节点上都有该数据库的完整副本。CCR 可保证所有节点都有该群集“世界”的一致视图。为避免破坏数据,每个节点都要知道群集资源的当前状态。 CCR 是在内核中实现的,是一种高度可用的服务。 CCR 使用两阶段提交算法用于更新:更新必须在所有群集成员上都成功完成,否则此更新将被回退。CCR 使用群集互连来应用分布式更新。 è----- - 尽管 CCR 是由文本文件组成的,但也绝不要手动编辑 CCR 文件。每个文件都有一个校验和来保证一致性。手动更新 CCR 文件可能会导致某个节点或整个群集不能工作。 CCR 靠 CMM 来保证群集只有在定额建立后才能运行。CCR 负责跨群集验证数据的一致性,需要时执行恢复,并为数据更新提供工具。 全局设备 Sun Cluster 使用 全局设备 提供群集范围内的高可用性访问,这种访问可以是对群集中的任一设备,自任意节点,而不用考虑设备的物理连接位置。通常,如果一个节点未能提供到某一全局设备的访问,则 Sun Cluster 自动找到到该设备的另一路径,并将访问重定向到此路径。Sun Cluster 全局设备包括磁盘、CD-ROM 和磁带。不过,磁盘是唯一支持的多端口全局设备。这意味着 CD-ROM 和磁带设置目前还不是高可用性的设备。每个服务器上的本地磁盘也不是多端口的,因而也不是高可用性设备。 群集会给群集中的每个磁盘、CD-ROM 和磁带设备分配唯一的标识。这种分配使得从群集中任何节点到每个设备的访问都保持一致性。全局设备名称空间保存在 /dev/global 目录下。有关详细信息请参见 全局名称空间 。 多端口全局设备可为一个设备提供多个路径。至于多主机磁盘,因为这些磁盘是以一个以上节点作为主机的磁盘设备组的一部分,所以它们是高可用性设备。 设备标识 (DID) Sun Cluster 通过一种叫做设备标识 (DID) 伪驱动程序的结构来管理全局设备。此驱动程序可自动给群集中的每个设备分配唯一的标识,包括多主机磁盘、磁带驱动器和 CD-ROM。 设备标识 (DID) 伪驱动程序是群集的全局设备访问功能的基本构成部分。DID 驱动程序探测群集中的所有节点并建立唯一磁盘设备列表,给每个磁盘设备分配唯一的主/次编号,这些编号在群集中所有节点上都是一致的。执行对全局设备的访问时使用的是 DID 驱动程序分配的唯一设备标识,而非传统的 Solaris 设备 ID(如某一磁盘的标识 c0t0d0 )。 这一措施可保证任何使用磁盘设备的应用程序(如卷管理器或使用原始设备的应用程序)都可使用一致的路径访问设备。此一致性对多主机磁盘尤为重要,因为每个设备的本地主/次编号在各节点上都可能不相同,因而也就改变了 Solaris 设备命名约定。例如,节点 1 可能将一个多主机磁盘看作 c1t2d0 ,而节点 2 可能会完全不同,将同一磁盘看作是 c3t2d0 。DID 驱动程序则会分配一个全局名称,如 d10,供节点使用,这样就为每个节点提供了到多主机磁盘的一致映射。 您可以通过 scdidadm(1M) 和 scgdevs(1M) 更新和管理设备标识。有关详细信息,请参见相应的手册页。 磁盘设备组 在 Sun Cluster 中,所有多主机磁盘都必须受 Sun Cluster 框架的控制。您首先在多主机磁盘上创建卷管理器磁盘组--或者是 Solstice DiskSuite 磁盘集,或者是 VERITAS 卷管理器 磁盘组。然后将卷管理器磁盘组注册为 Sun Cluster 磁盘设备组 。磁盘设备组是一种全局设备。此外,Sun Cluster 将每一个单个磁盘注册为一个磁盘设备组。 note: 磁盘设备组独立于资源组。一个节点可以控制资源组(代表一组数据服务进程),而另一个节点可以控制正被数据服务访问的磁盘组。不过最好的做法是,让存储特定应用程序数据的磁盘设备组和包含此应用程序资源(应用程序守护程序)的资源组保持在同一节点上。有关磁盘设备组和资源组之间关系的详细信息,请参见 Sun Cluster 3.0 Data Services Installation and Configuration Guide 中包含概述性内容的那一章。 有了磁盘设备组,卷管理器磁盘组就成了“全局”的,因为它对基础磁盘提供了多路径支持。物理连接到多主机磁盘的每个群集节点都提供了一条到磁盘设备组的路径。 note: 如果全局设备是以一个以上群集节点为主机的设备组的一部分,则它是高可用的。 磁盘设备失败切换 因为磁盘群组连接着一个以上的节点,所以群组中的所有磁盘设备组在当前控制它的节点出现故障时,都可以通过备用路径访问。控制设备组的节点出现故障不会影响对此设备组的访问,但在执行恢复和一致性检查时除外。在这段时间,所有请求都被阻挡(对应用程序是透明的),直到系统使该设备组可用为止。 7 - 磁盘设备组失败切换 全局名称空间 Sun Cluster 启用全局设备的机制是通过 全局名称空间 。全局名称空间包括 /dev/global/ 分层结构和卷管理器名称空间。全局名称空间可以反映多主机磁盘和本地磁盘(及所有其他群集设备,如 CD-ROM 和磁带),并提供到多主机磁盘的多条失败切换路径。物理连接到多主机磁盘的每个节点都为群集中的任何节点提供了到存储器的路径。 正常情况下,卷管理器名称空间的驻留位置是:对于 Solstice DiskSuite,在 /dev/md/ diskset /dsk (和 rdsk )目录下;对于 VxVM,在 /dev/vx/dsk/ disk-group 和 /dev/vx/rdsk/ disk-group 目录下。这些名称空间分别由整个群集中引入的各 Solstice DiskSuite 磁盘集和各 VxVM 磁盘组的目录组成。每一个这样的目录中都有此磁盘集或磁盘组中每个元设备或卷的设备节点。 在 Sun Cluster 中,本地卷管理器名称空间中的每个设备节点都被替换成 /global/.devices/node@ nodeID 系统文件中到某个设备节点的符号链接,其中 nodeID 是一个整数,代表群集中的节点。Sun Cluster 还会将卷管理器设备在标准位置显示为符号链接。全局名称空间和标准卷管理器名称空间两者在任何群集节点上都可以找到。 全局名称空间的优点有: 每个节点可保持相当的独立性,不需要对设备管理模型做什么改动。 可以有选择地使设备变成全局设备。 第三方链接产生器可继续工作。 只要给出本地设备名称,就会有一个简单的映射用以获得其全局名称。 本地和全局名称空间实例 下表显示的是一个多主机磁盘 c0t0d0s0 的本地名称空间和全局名称空间之间的映射关系。 3 - 本地和全局名称空间映射 组件/路径 本地节点名称空间 全局名称空间 Solaris 逻辑名称 /dev/dsk/c0t0d0s0 /global/.devices/node@ ID /dev/dsk/c0t0d0s0 DID 名称 /dev/did/dsk/d0s0 /global/.devices/node@ ID /dev/did/dsk/d0s0 Solstice DiskSuite /dev/md/ diskset /dsk/d0 /global/.devices/node@ ID /dev/md/ diskset /dsk/d0 VERITAS 卷管理器 /dev/vx/dsk/ disk-group /v0 /global/.devices/node@ ID /dev/vx/dsk/ disk-group /v0 全局名称空间在安装时自动生成,并在每次重新配置后重新引导时自动更新。您也可以运行 scgdevs(1M) 命令来生成全局名称空间。 群集文件系统 群集文件系统是一个节点上的内核与某个和磁盘有物理连接的节点上运行的基础文件系统及卷管理器之间的代理。 群集文件系统依赖于和一个或多个节点有物理连接的全局设备(磁盘、磁带、CD-ROM)。全局设备可从群集中任何节点上通过同一个文件名称(如 /dev/global/ )访问,而不用管此节点与存储设备是否有物理连接。可以像常规设备那样使用全局设备,也就是说,您在它上面可以用 newfs 和/或 mkfs 命令创建文件系统。 您可以在全局设备上用 mount -g 命令安装全局文件系统,或用 mount 创建本地文件系统。程序可以使用同一文件名(如 /global/foo ),从群集中的任意节点访问群集文件系统中的文件。所有群集成员上都安装了一个群集文件系统。不可以在群集成员的子集上安装群集文件系统。 使用群集文件系统 在 Sun Cluster 中,所有多主机磁盘都配置为磁盘设备组,这些多主机磁盘可以是 Solstice DiskSuite 磁盘集、VxVM 磁盘组或不受基于软件的卷管理器控制的独立磁盘。另外,本地磁盘都配置为磁盘设备组:从每个节点引向每个本地磁盘的路径。此设置并不意味着一个磁盘上的数据必须能被所有节点访问。只有在磁盘上的文件系统安装为全局性的群集文件系统时,这些数据才能被所有节点访问。 成为群集文件系统的本地文件系统与磁盘存储器只有单一的连接。如果与磁盘存储器有物理连接的节点出现故障,则其他节点就不再能够访问群集文件系统。您可以在一个节点上创建不能由其他节点直接访问的本地文件系统。 HA 数据服务经过设置后,服务所用的数据存储在群集文件系统中的磁盘设备组上。这种设置有几个优点。首先,数据是高可用的;也就是说,因为磁盘是多主机的,如果当前主节点的路径出现问题,访问就切换到可直接访问这些磁盘的另一节点。其次,因为数据在群集文件系统上,所以可以从任何群集节点上直接查看它--不必登录到当前控制着该磁盘设备组的节点来查看数据。 代理文件系统 群集文件系统基于代理文件系统 (PXFS),后者有下列功能: PXFS 使文件访问位置透明。一个进程可打开位于系统中任何位置的文件,而且所有节点上的进程都可以使用同样的路径名定位文件。 PXFS 使用相关协议来保留 UNIX 文件访问的语义,即使从多个节点并行访问文件时也是如此。 PXFS 可提供大范围的高速缓存和零复制批量 I/O 移动,以便有效地移动大数据对像。 PXFS 可提供对数据的连续访问,即使发生故障时也是如此。只要到磁盘的路径仍然有效,应用程序就检测不到故障。对于原始磁盘访问和所有文件系统操作,也可保证。 PXFS 独立于基础文件系统和卷管理软件。PXFS 使所有磁盘上文件系统具有全局性。 PXFS 是在 vnode 接口处建立在现有 Solaris 文件系统之上的。此接口使得不用进行大量的内核修改就可以实现 PXFS。 PXFS 不是一种独特的文件系统类型。也就是说,客户机看到的是基础文件系统(如 UFS)。 群集文件系统独立性 群集文件系统独立于基础文件系统和卷管理器。目前,您可以用 Solstice DiskSuite 或 VERITAS 卷管理器 在 UFS 上建立群集文件系统。 与一般的文件系统一样,您可以以两种方式安装群集文件系统: 手动 -- 使用 mount 命令和 -g 选项从命令行安装群集文件系统,例如: # mount -g /dev/global/dsk/d0s0 /global/oracle/data 自动 -- 在 /etc/vfstab 文件中用 global 安装选项创建一个条目,以在引导时建立群集文件系统。接着就可以在所有节点上的 /global 目录下创建一个安装点。目录 /global 是推荐的位置,不是必需的。下面是 /etc/vfstab 文件中一个群集文件系统的实例行: /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/data ufs 2 yes global,logging note: Sun Cluster 不强制使用群集文件系统的命名策略,所以您可以通过在同一目录下(如 /global/ disk-device-group )为所有群集文件系统创建一个安装点来使管理更容易。有关详细信息,请参见 Sun Cluster 3.0 安装指南 和 Sun Cluster 3.0 系统管理指南 。 Syncdir 安装选项 群集文件系统可使用 syncdir 安装选项。不过,如果不指定 syncdir ,性能会有明显提高。如果您指定 syncdir ,则保证写入的数据符合 POSIX 标准。如果不指定,您会看到与 UFS 文件系统一样的行为。例如,在某些情况下,如果不指定 syncdir ,就只能在关闭一个文件后才发现空间不足。有了 syncdir (和 POSIX 行为),空间不够的情况应该在写入操作期间就已发现了。在不指定 syncdir 时出现问题的情形是很少见的,所以我们建议您不指定它,以便在性能方面受益。 有关全局设备和群集文件系统的常见问题,请参见 文件系统 FAQ 。 定额和定额设备 因为群集节点共享数据和资源,所以群集必须采取措施保持数据和资源的完整性。当一个节点不符合群集的成员规则时,群集必须禁止该节点加入群集。 在 Sun Cluster 中,决定节点是否可加入群集的机制叫做 定额 。Sun Cluster 采用一种多数票算法来实现定额机制。群集节点和 定额设备 (两个或更多节点间共享的磁盘)都参加投票,形成定额。一个定额设备可以包含用户数据。 定额算法自动执行:当群集事件触发其计算时,计算结果在群集的生命周期内会发生变化。定额可防止发生两种潜在的群集问题 -- 群集分割和失忆 -- 二者均可造成使不一致的数据提供给客户机。下表描述了这两种问题以及它们是如何解决的。 4 - 群集定额与群集分割和失忆问题 问题 描述 定额的解决方案 群集分割 在节点间失去群集互连并且群集划分为若干子群集时发生,每个分区都认为自己是唯一分区 仅允许获得多数选票的分区(子群集)作为群集(其中最多仅能有一个拥有多数选票的分区) 失忆 群集关闭后又重新启动时,此时的群集数据比关闭时旧 在群集引导时,保证至少有一个节点是最新的群集成员之一(因而有最新的配置数据) 定额投票计数 群集节点和定额设备(在两个或更多节点之间共享的磁盘)两者都通过投票来形成定额。缺省情形下,群集节点在引导并成为群集成员时获取其中一个的定额投票计数。节点的投票数可以是零,例如当正在安装节点时,或当管理员将节点置于维护状态时。 定额设备获取定额投票计数基于设备的节点连接数。在设置定额设备时,它需获取一个最大投票数 N -1,其中 N 是有非零投票数的节点数,并且这些节点有到定额设备端口。例如,连接到两个投票数非零的节点的定额设备有其中一个的定额数(二减一)。 您要在在群集安装期间,或以后通过使用在 Sun Cluster 3.0 系统管理指南 中描述的过程来配置定额设备。 note: 仅在当前连接的节点中至少有一个是群集成员时,定额设备才对投票数起作用。同时,在群集引导期间,仅在当前连接的至少一个节点正在引导,并且在关闭时它是最近刚刚引导的群集成员的情况下,定额设备才对投票数起作用。 定额配置 定额配置依赖于群集中节点的数目: 双节点群集 - 要形成双节点群集,需要两个定额投票。这两个投票可以来自于两个群集节点,或者只来自一个节点和一个定额设备。然而,在双节点群集中,必须配置一个定额设备,以确保在一个节点发生故障时另一单个节点可以继续工作。 多于两个节点的群集 - 您应在共享对磁盘存储器群组访问的每对节点间指定一个定额设备。例如,假定您有一个由三个节点组成的群集,类似于 8 中展示的群集那样。在此图中,nodeA 和 nodeB 共享对同一磁盘群组的访问权,而 nodeB 和 nodeC 共享对另一磁盘群组的访问权。总共会有五个定额选票,其中三个来自节点,两个来自节点共享的定额设备。一个群集需要多数定额投票,即三个,才能形成。 Sun Cluster 不要求也不强迫在共享对磁盘存储器群组访问的每对节点间指定一个定额设备。但是,对于 N+1 配置降级为一个双节点群集并且紧接着对两个磁盘群组都有访问权的节点也发生故障的情况,它可以提供所需要的定额选票。如果您在每对节点之间配置了定额设备,则其余的节点仍可作为一个群集来运行。 关于这些配置的实例请参见 8 。 8 - 定额设备配置实例 定额准则 在设置定额设备时,请使用下列准则: 在连接相同共享磁盘存储器群组的所有节点间建立定额设备。在共享群组内添加一个磁盘作为定额设备以确保在任何节点发生故障时,其他节点可以维持定额并可以控制共享群组上的磁盘设备组。 必须将定额设备连接到至少两个节点上。 定额设备可以是用作双端口定额设备的任何 SCSI-2 或 SCSI-3 磁盘。连接到超过两个节点的磁盘必须支持 SCSI-3 持久性组保留 (PGR),而不论磁盘是否用为作定额设备。有关详细信息,请参见 Sun Cluster 3.0 安装指南 中有关计划的章节。 您可以使用包含用户数据的磁盘作为定额设备。 ----¤- - 在节点集之间配置一个以上定额设备。使用来自不同群组的磁盘,并在每个节点集之间配置奇数的定额设备。这可以避免在单个定额设备发生故障。 故障防护 群集的一个主要问题是引起群集分区的故障(称作 群集分割 )。当此故障发生时,并不是所有节点都可以通信,所以个别节点或节点子集可能会尝试组成个体或群集子集。每个子集或分区都可能以为它对多主机磁盘的唯一访问权和所有权。多个节点试图写入磁盘会导致数据损坏。 故障防护通过以物理方式防止对磁盘的访问,限制了节点对多主机磁盘的访问。当节点脱离群集时(它或是发生故障,或是分区),故障防护确保了该节点不再能访问磁盘。只有当前成员节点有权访问磁盘,以保持数据的完整性。 磁盘设备服务为使用多主机磁盘的服务提供了失败切换能力。在当前担当磁盘设备组主节点(属主)的群集成员发生故障或变得无法访问时,一个新的主节点会被选中,使得对磁盘设备组的访问得以继续,而只有微小的中断。在此过程中,旧的主节点必须放弃对设备的访问,然后新的主节点才能启动。然而,当一个成员从群集断开并变得无法访问时,群集无法通知那个节点释放那些将该节点作为主节点的设备。因而,您需要一种方法来使幸存的成员能够从失败的成员那里控制并访问全局设备。 Sun Cluster 使用 SCSI 磁盘保留来实现故障防护。使用 SCSI 保留,故障节点被与多主机磁盘“隔离”起来,使它们无法访问那些磁盘。 SCSI-2 磁盘保留支持一种保留形式,它或者授权给所有连接到磁盘的节点访问权(当没有保留上时),或者限制对单个节点(即拥有该保留的节点)的访问权。 当群集成员检测到另一个节点不再通过群集互连进行通信时,它启动故障防护措施来避免另一个节点访问共享磁盘。当发生此故障防护时,通常将防护的节点处于应急状态,并在其控制台上显示“保留冲突”的消息。 发生保留冲突是因为在节点已被检测到不再是群集成员后,一个 SCSI 保留被置于在此节点与其他节点间共享的所有磁盘上。防护节点可能不会意识到它正在被防护,并且如果它试图访问这些共享磁盘之中的一个,它会检测到保留和应急状态。 卷管理器 Sun Cluster 使用卷管理软件通过镜像和热备份磁盘来增加数据的可用性,并处理磁盘故障和更换。 Sun Cluster 没有它自己的内部卷管理器组件,而依赖于下面的卷管理器: Solstice DiskSuite VERITAS 卷管理器 群集中的卷管理软件提供对如下功能的支持: 节点故障的失败切换处理 来自不同节点的多路径支持 对磁盘设备组的远程透明访问 当在 Sun Cluster 中设置卷管理器时,您将多主机磁盘配置作为 Sun Cluster 磁盘设备,它是卷管理器磁盘组的一个包装。设备既可以是一个 Solstice DiskSuite 磁盘集,也可以是一个 VxVM 磁盘组。 您必须将磁盘组配置为用于数据服务,以镜像映射来使该群集内的磁盘变得高可用。 您可以使用元设备或复用设备作为一个原始设备(数据库应用程序),或者保持 UFS 文件系统。 卷管理对像 -- 元设备和卷 -- 来自群集的控制之下,从而成为磁盘设备组。例如,在 Solstice DiskSuite 中,当您在群集中创建磁盘集时(通过使用 metaset(1M) 命令),会创建一个相应的同名磁盘设备组。接着,当您在该磁盘集中创建元设备时,他们变成了全局设备。因而,磁盘集是磁盘设备(DID 设备)和主机的集合,集合中的所有设备都移植到主机中。群集中的所有磁盘集在创建时都需要在集合中有一个以上的主机,以便归档 HA。在使用 VERITAS 卷管理器 也时会发生相同的情况。设置每个卷管理器的详细信息包含在 Sun Cluster 3.0 安装指南 的附录中。 在规划磁盘集或磁盘组时一个重要的考虑事项就是要了解他们的关联磁盘设备组是如何在群集内与应用程序资源(数据)相联系的。关于这些问题的讨论,请参考 Sun Cluster 3.0 安装指南 和 Sun Cluster 3.0 Data Services Installation and Configuration Guide 。 数据服务 术语 数据服务 是用来描述诸如 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 框架管理 在单独节点(失败切换方式)或多个节点(可伸缩方式)上作为主机 RGM 将数据服务(应用程序)作为资源控制,资源是由 资源类型 实现所管理的。这些实现或者由 Sun 提供,或者由具有一个类属数据服务模板、数据服务开发库 API (DSDL API) 或 Sun Cluster 资源管理 API (RMAPI) 的开发者创建。群集管理员在称为 资源组 的容器中创建和管理资源,这些容器形成失败切换和切换的基本单元。RGM 根据群集成员关系的变化来停止或启动选定节点上的资源组。 失败切换数据服务 如果正在运行数据服务的节点(主节点)发生故障,那么该服务会被移植到另一个工作节点而无需用户干预。失败切换服务利用了 失败资源组 ,它是一个应用程序实例资源和网络资源( 逻辑主机名 )容器。逻辑主机名是一些可以配置到节点上的 IP 地址,然后自动在原始节点解除配置,并配置到另一节点上。 对于失败切换数据服务,应用程序实例仅在一个单独的节点上运行。如果故障监视器检测到一个故障,它或者试图在同一节点上重新启动该实例,或者在另一个节点上启动实例(失败切换),这取决于该数据服务是如何配置的。 可伸缩数据服务 可伸缩数据服务对多个节点上的活动实例有潜能。可伸缩服务利用 可伸缩资源组 来保持应用程序资源,利用失败切换资源组来保持可伸缩服务所依赖的网络资源( 共享地址 )。可伸缩资源组可以在多个节点上联机,因此服务的多个实例可以立刻运行。以共享地址为主机的失败切换资源组每次只在一个节点上联机。以可伸缩服务做主机的所有节点使用相同的共享地址来主持该服务。 服务请求通过一个单独的网络接口( 全局接口 或 GIF)进入群集,并依据由 负载平衡策略 设置的几个预定义算法之一来将这些请求分发到节点。群集可以使用负载平衡策略来平衡几个节点间的服务负载。注意,在不同的节点上可能有多个 GIF 以其他共享地址为主机。 对于可伸缩服务来说,应用程序实例在几个节点上同时运行。如果拥有全局接口的节点出现故障,全局接口将切换到其他节点。如果一个正在运行的应用程序实例发生故障,则该实例尝试在同一节点上重新启动。 如果应用程序实例不能在同一节点上重新启动,而另一个未使用的节点被配置运行该服务,那么该服务会切换到这个未使用的节点。否则,它继续运行在那些剩余节点上,并且很可能会降低服务吞吐量。 note: 每个应用程序实例的 TCP 状态与该实例一起保存在此节点上,而不是在 GIF 节点上。因此,GIF 节点上的故障不影响连接。 9 显示了失败切换和可伸缩资源组的一个实例,以及在它们之间存在的对于可伸缩服务的依赖性。此实例显示了三个资源组。失败切换资源组包括高可用性的 DNS 应用程序资源和,以及由高可用的 DNS 和 Apache Web 服务器共同使用的网络资源。可伸缩资源组仅包括 Apache Web 服务器应用程序实例。注意,资源组在可伸缩和失败切换资源组(实线)之间存在依赖性,而所有的 Apache 应用程序资源都依赖于网络资源 schost-2 ,这是一个共享地址(虚线)。 9 - 失败切换与可伸缩资源组实例 可伸缩服务体系结构 群集联网的主要目标是为数据服务提供可伸缩性。可伸缩性意味着随着提供给服务的负载的增加,在新的节点被添加到群集并运行新的服务器实例的同时,数据服务面对这种增加的工作负载能保持一个不变的响应时间。我们将这样的服务称为可伸缩数据服务。Web 服务是可伸缩数据服务的一个很好的实例。通常,可伸缩数据服务由几个实例组成,每一个示例运行在群集的不同节点上。这些实例在一起,作为来自该服务远程客户机的基准点的一个单独的服务,并实现该服务的功能。比如,我们可能会有一个由几个 httpd 守护程序组成的 Web 服务,并且这些守护程序在不同的节点上运行。任何 httpd 守护程序都服务于一个客户请求。服务于请求的守护程序依赖于 负载平衡策略 。对客户机的回复看起来是来自该服务,而不是服务于请求的特定守护程序,从而保留单个服务的外观。 可伸缩服务由以下功能组成: 对可伸缩服务的联网基础结构支持 负载平衡 对联网和数据服务的 HA 支持(使用 Resource Group Manager) 下图描绘了可伸缩服务的体系结构。 10 - 可伸缩服务体系结构 当前不作为全局接口主机的节点(代理节点)与它们的回送接口共享地址。进入到 GIF 的软件包被分发到基于可配置负载平衡策略的其他群集节点上。可能的负载平衡策略在下一步说明。 负载平衡策略 负载平衡在响应时间和吞吐量上同时提高了可伸缩服务的性能。 有两类可伸缩数据服务: 纯粹 和 粘滞 。纯粹服务就是它的任何实例都可以对客户机的请求作出响应的服务。粘滞服务是客户机发送请求到相同实例的那种服务。那些请求不被重定向到其他实例。 纯粹服务使用加权的负载平衡策略。在这种负载平衡策略下,客户机请求按缺省方式被均衡地分配到群集内的服务器实例之上。例如,在一个三节点群集中,让我们来假设每个节点的加权为 1。每个节点将代表该服务对所有客户机请求的 1/3 进行服务。加权可以在任何时候由管理员通过 scrgadm(1M) 命令接口进行修改。 粘滞服务有两种风格, 普通粘滞 和 通配粘滞 。粘滞服务允许多个 TCP 连接上并行的应用程序级会话来共享“状态内”内存(应用程序会话状态)。 普通粘滞服务允许客户机在多个并行的 TCP 连接之间共享状态。相对于正在监听单个端口的服务器实例,可以该客户机说成是“粘滞的”。假定实例保持打开状态并可访问,并且在服务处于联机状态时负载平衡策略不更改,将保证该客户机的所有服务请求都传给相同的服务器实例。 例如,客户机的 Web 浏览器连接到使用三种不同 TCP 连接,连接到端口为 80 的共享 IP 址,但连接在服务时正在它们之间交换已缓存的会话信息。 粘滞策略的普遍化延伸到在相同实例场景后面交换会话信息的多个可伸缩服务。当这些服务在相同实例场景后面交换会话信息时,相对于在不同端口上监听的相同节点上的多个服务器实例来说,可以说客户机是“粘滞的”。 例如在一个电子商务站点上,顾客使用端口 80 上的普通 HTTP 购买了许多商品并放入到购物车中,但是要切换到端口 443 上的 SSL,以发送安全数据,使用信用卡付款。 通配粘滞服务使用动态分配的端口号,但仍期望客户机请求去往相同的节点。相对于相同的 IP 地址来说,客户机就是端口上的“粘滞通配”。 被动模式 FTP 是这一策略的一个好例子。客户机连接到端口 21 上的 FTP 小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册黑基账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!



免责声明:本文由投稿者转载自互联网,版权归原作者所有,文中所述不代表本站观点,若有侵权或转载等不当之处请联系我们处理,让我们一起为维护良好的互联网秩序而努力!联系方式见网站首页右下角。


鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论


新出炉

返回顶部