Red Hat Cluster Suite 概览
这是一个开源集群的多种技术的组合解决方案，要深入研究则需要对各种底层技术进行深入学习。
Red Hat Cluster Suite (RHCS) 是部署高性能、高可用、负载平衡、可伸缩、文件共享的集群软件组合。
RHCS包含以下组件：
- Cluster Infrastructure – 提供集群的各节点工作基础：配置文件管理，管理管理，锁管理和fence管理（类似IPMI远程重启或关闭故障节点释放节点资源）
- HA服务管理 – 在一个节点不能正常工作的情况下提供failover服务到另外一个节点
- Cluster管理工具 – 配置和管理Red Hat群集
- Linux Virtual Server （LVS） – 通过IP负载平衡方式，提供将客户端请求分发到集群的各个真实节点上。
为支持Red Hat Cluster Suite可选的组件有：
- GFS (Global File System) 和 GFS2 (Global File System 2) – 为提供集群提供一个集群文件系统。 GFS/GFS2 允许多个节点在块级别上访问一个共享存储，就如同存储是连接在每个群集节点的本地一样。
- Cluster Logical Volume Manager （CLVM） – 在群集存储上提供卷管理。
- Global Network Block Device（GNBD） – 辅助GFS/GFS2在以太网上输出块级别存储的组件。这是对 Red Hat GFS 提供一种经济的块级别存储的方式。
Cluster基础构架
Red Hat Cluster Suite集群基础构架提供了服务器组的基本功能以便节点能够作为整体集群进行工作。一旦一个集群使用cluster infrastructure构建，就能够使用其他Red Hat Cluster Suite组件来实现集群功能，例如设置一个集群在GFS文件系统上共享文件或设置service failover。
Cluster Infrastructure实现以下功能：
- 集群管理
- 锁管理
- Fencing
- 集群配置管理
Red Hat Cluster支持的最大节点数量是16个。
Cluster Management（集群管理）
Cluster management管理cluster quorum（集群仲裁）和 cluster membership（集群关系）。CMAN（集群管理的缩写）执行集群管理，是一个分布式集群管理软件，运行在每个集群节点上。
CMAN通过监控集群节点的数量来跟踪集群仲裁。如果有超过半数节点是激活的，则群集具备仲裁。如果只有半数（或更少）节点是激活的，则集群没有仲裁，并且所有集群活动都停止。集群仲裁是为了防范”裂脑”现象发生（split-brain） – 这种情况下同一个集群中会运行2个会话。此时一个集群会话的各个节点是不知道另一个集群各个节点访问集群资源，这将导致集群完整性遭到破坏。
集群仲裁（Quorum）是通过以太网中各个集群节点相互通讯来完成的。可选的方式是，仲裁结合以太网传递消息和通过一个仲裁磁盘来实现。当通过以太网进行仲裁，仲裁包含节点数量的一半加上1。当通过仲裁磁盘实现仲裁，则仲裁可以以用户指定条件来实现。
默认情况下，每个节点只有一个仲裁票，不过，也可以配置每个节点有多个仲裁票。
CMAN 跟踪群集其他节点的监控消息。如果一个节点A加入集群并且挂载节点B和节点C已经挂载的GFS文件系统，则节点A需要附加的日志和锁管理来使用GFS文件 系统。如果群集节点没有在规定时间周期内发送消息，则该节点将被集群管理器删除，而其他集群节点将不再视此节点为集群成员。
锁管理
锁管理是一个通用的cluster-infrastructure服务提供一种对于其他cluster构架组件用于同步节点访问共享资源的机制。在Red Hat Cluster中，采用分布式锁管理（DLM, Distributed Lock Manager）。这种DLM锁管理在每个集群节点上运行。GFS和CLVM依赖锁管理提供的锁来运行。GFS使用锁来管理对位于共享存储上的文件系统元 数据（file system metadata）进行同步访问。CLVM使用锁来同步更新LVM卷和卷组（也位于共享存储）。
Fencing
Fencing是将一个节点从集群共享存储断开的机制。Fencing切断共享存储的I/O，然后确保数据一致性。集群构架通过fence服务，fenced，来执行fencing。
当CMAN侦测到一个节点故障，它将通知其他cluster-infrasturcture组件该节点故障。fenced在得知该节点故障时，将隔离这个故障节点。其他cluster-infrasturcture组件检测到节点故障将执行必要的恢复动作。例如，DLM和GFS当注意到节点故障，挂起活动直到检测到fenced完成了隔离故障节点的工作。在确认故障节点被隔离后，DLM和GFS就执行recovery。DLM释放故障节点的锁，GFS恢复故障节点日志。
Fencing程序通过集群配置文件来确定需要采用的fencing方式。在集群配置文件中，有两个关键因素决定了一个fencing方式： fencing agent 和 fencing device。
Fencing程序根据集群配置文件来调用fencing agent。fencing代理，则通过一个fencing设备隔离节点。当fencing完成后，fencing程序就通知集群管理器。
Red Hat Cluster Suite提供以下fencing方式：
- Power fencing – 使用电源控制器关闭故障节点
- Fibre Channel switch fencing – 关闭连接到故障节点的光纤交换机接口
- GNBD fencing – 禁止故障节点访问GNBD服务器
- 其他fencing – 其他fencing方式包括禁止I/O或切断故障节点电源，包括IBM Bladecenters, PAP, DRAC/MC, HP ILO, IPMI, IBM RSA II 等
可以配置一个节点使用一种fencing方式也可以配置多种fencing方式。后者可以在一种fencing方式失效情况下依次采取其他fencing方式。
Cluster配置系统
Cluster配置系统（CCS）管理集群配置和提供配置信息给Red Hat Cluster其他集群组件。CCS运行在每个集群节点上并确保集群所有节点的配置都是最新的。例如，当集群管理员更新节点A上配置，CCS将保证更新同步到集群的其他节点。
其他Cluster组件，例如CMAN是通过CCS来访问集群配置信息的。
集群配置文件（/etc/cluster/cluster.conf）是一个XML文件描述集群特性：
- 集群名称 － 显示集群名称，集群配置文件修改级别，和基本的fence定时属性（节点加入或隔离的计时）
- 集群 － 显示集群的每个节点，指定节点名称，节点ID，仲裁投票数量和fencing模式
- fence设备 － 显示集群的fence设备。该参数根据fence设备类型不同而不同。
- 受管理资源 － 显示用于创建集群服务的依赖资源。受管理的资源包括failover domain定义，资源（例如IP地址）和服务。
High-availability 服务管理
高可用服务管理提供了创建和管理高可用集群服务的能力。在Red Hat集群中高可用的关键模块是rgmanager，实现冷切换应用程序。一个高可用集群服务可以从一个节点failover到另外一个节点而不会明显中断集群客户端的访问。
要创建一个高可用服务，不需在集群配置文件中配置。一个集群服务包括集群资源。集群资源是在集群配置文件中构建的配置部分 － 例如，一个IP地址，一个应用程序初始化脚本，或Red Hat GFS共享分区。
可以把一个集群服务结合到failover服务上。一个failover服务是集群节点的一个子集，被选作运行部分集群服务。
一个集群服务在一个时间点只能运行在一个节点上，这样可以保证一致性。可以在failover服务设置failover属性。指定failover属性包含 在一个failover domain中设置每个节点的优先级别。这个优先级别决定了failover的顺序。如果没有指定failover优先级别，则集群服务会随机 failover到该failover域的任何节点上。
以下案例，Failover Domain 1配置限制了域内的failover，这样Cluster服务X只能在节点A和节点B之间failover。类似配置Failover Domain 2 和 Failover Domain 3。
Red Hat GFS
在Red Hat Cluster Suite中有两种GFS文件系统： GFS 和 GFS2。
GFS/GFS2是使用Linux内核文件系统接口（VFS层）直接实现的native型文件系统。一个GFS/GFS2可以作为一个独立系统也可以作为群集配置的一部分。当作为一个集群文件系统，GFS/GFS2采用分布式metadata和多日志。
GFS/GFS2是基于64位构架的，理论上可以存取8EB文件系统。然而当前GFS/GFS2最大支持25TB。如果要支持大于25TB，则需要联系Red Hat服务。
当配置Red Hat Cluster Suite，Red Hat GFS/GFS2节点可以配置为由Red Hat Cluster Suite来配置和管理。Red Hat GFS/GFS2然后提供数据共享给集群节点。
GFS/GFS2文件系统必须创建在一个linear或mirrored的LVM卷上。在集群中，LVM卷是通过CLVM来管理的，这是一个集群范围内实现LVM，通过CLVM服务clvmd来实现的。该clvmd服务可以使用LVM2来管理集群中的逻辑卷，允许集群所有节点共享逻辑卷。
集群逻辑卷（Cluster Logical Volume Manager）
集群逻辑卷（CLVM）提供了一个集群范围的LVM2。CLVM在单个节点上提供了和LVM2相同的功能，但是在一个Red Hat Cluster中该逻辑卷可以提供给所有节点使用。使用CLVM创建的逻辑卷对所有节点可访问。
在CLVM中关键的模块是clvmd服务。clvmd服务是一个对标准LVM2工具集提供集群扩展，并允许LVM2命令管理共享存储。clvmd运 行在集群的每个节点上并且负责在集群中分发LVM的metadata更新，这样每个保持每个集群节点具有相同的逻辑卷视图。在共享存储上使用CLVM创建 的逻辑卷可以由所有节点存取。CLVM允许用户通过锁定访问已配置逻辑卷的物理存储来配置共享存储上的逻辑卷。CLVM使用集群基础构架中的锁管理服务。
全局网络块设备（Global Network Block Device）
全局网络块设备（GNBD）在TCP/IP之上为Red Hat GFS提供了块设备存储。GNBD类似NBD，然而，GNBD是针对GFS调优过。当不需要更具备鲁棒性 － 光纤通道或简单初始化SCSI － 或需要便宜的部署，则可以考虑使用GNBD。
GNBD 包含两个主要组件： GNBD客户端和GNBD服务器。一个GNBD客户端运行在使用GFS的节点上并且导入由GNBD服务器输出的块设备。一个GNBD服务器是运行在另外一 个节点并且将其本地存储（本地直连存储或SAN存储）输出为块级别存储。多个GNBD客户端可以访问一个GNBD服务器输出的设备，这样可以通过运行 GFS的一组节点创建一个GNBD系统。
Linux Virtual Server
Linux虚拟服务器（LVS）是通过负载平衡IP在一组实际服务器上实现集群。LVS运行在一对相同配置的主机上：其中一个是active LVS路由器另外一个是backup LVS路由器。
active LVS路由器执行两个角色：
- 将负载分发到实际服务器上
- 检查每个真实服务器的服务监控情况
backup LVS路由器则监控active LVS路由器，并且在active LVS路由器故障的时候接管服务。
pulse服务运行在active和passive LVS 路由器上。在backup LVS路由器上，pulse服务向active路由器的公共接口发送心跳数据包以确定active LVS路由器正常工作。在active LVS路由器上，pulse服务启动lvs服务并响应从backup LVS路由器发来的心跳数据包。
一旦启动，lvs服务调用ipvsadm应用程序来配置和维护内核中的IPVS（IP Virtual Server）路由表并且针对每个实际服务器的每个已配置虚拟服务器启动一个nanny（中文意为“保姆”）进程（也就是每个虚拟服务器需要一个nanny监控服务）。每个nanny进程检查这个配置虚拟服务器对应的每个实际服务器上的服务是否正常，如果某台实际服务器上的服务不能正常工作，则nanny进程就会告诉lvs进程。当检测到故障节点的服务异常，则lvs服务调用ipvsadm从IPVS路由表中删除该实际服务器。
如果后备LVS路由器不能从活跃LVS路由器接收到响应，则后备LVS路由器通过调用send_arp将所有虚拟IP地址对应网卡MAC地址都设置为后备LVS路由器的接口，通过公共和私有网卡接口发送一个命令给活跃LVS路由器，命令活跃LVS路由器关闭其节点上的lvs服务，然后在后备LVS路由器上启动lvs服务来接收发给配置的虚拟服务器的请求。
对于外部访问服务的客户端，LVS就像一个服务器。实际上，用户访问的是LVS路由器之后隐藏的实际服务器群。
由于LVS没有内建的在实际服务器间共享数据的机制，所以需要采用以下方法之一来同步数据：
- 在实际服务器之间同步数据（类似rsync）
- 增加一个第三层来访问共享数据
对于前一种方案适合少量用户数据上传或数据修改，如果真实服务器需要修改大量的数据，类似电子商务网站，则建议使用方案二。
Two-Tier LVS拓扑
以下是一个简单的双层（Two-Tier） LVS构架。活跃LVS路由器采用NAT方式来分发请求给内网的正是服务器，所有的流量都从真实服务器经过。
注意，在failover过程中，虚拟服务器VIP地址从一台LVS路由器迁移到另外一台LVS路由器以维持VIP地址，称为 floating IP addresses。
VIP地址可能在LVS路由器的公网接口的相同设备上采用别名（alias）实现。例如，如果eth0连接Internet，则虚拟服务器可以设置为eth0:1。
每个虚拟服务器可以通过独立的设备提供服务。例如，HTTP流量由 eth0:1 处理，而FTP流量由 eth0:2 处理。
一旦LVS路由器激活，活跃的LVS路由器将重定向对虚拟服务器的服务器请求给实际服务器。这个重定向基于以下8种负载平衡算法之一：
- Round-Robin － 在相同服务器池中的每个实际服务器平均获得服务请求，而不管服务器实际能力或实际负载。
- 权重Round-Robin － 通过人为指定的权重（设置服务器不同的权重）来分发负载。这要求管理员估算不同服务器的负载能力和负载情况。由于是人为指定，所以不能动态根据服务器负载情况调整权重。
- 最少连接 － 对较少活跃连接的服务器分发更多请求。这是一种动态调整算法，对于根据请求负载有较大负载变化的环境比较适合。
- 权重最少连接（默认算法） － 管理员设置服务器权重，但同时也根据动态情况采用连接数进行调整请求分发。
- 基于本地的最小连接 － 对于较少的活跃连接分发更多请求。这种算法适合proxy-cache服务器集群。
- 基于本地的带复制调度的最小连接 － 根据服务器连接到目标服务器的最少连接数量来分发更多的请求。这个算法也是适合proxy-cache服务器集群。
- 源地址Hash调度 － 根据在一个固定hash表中的原地址IP来分发请求。这种算法适合带有多个防火墙的LVS路由器。
Three-Tier LVS拓扑
以上三层LVS拓扑构架适合繁忙的FTP服务器，访问集中化的高可用服务器，并通过NFS目录或Samba共享来提供real server数据。这个拓扑推荐用于访问集中化的高可用数据库的web网站。
NAT路由
对于采用NAT模式的LVS路由器。针对Internet的网卡eth0上配置了一个真实IP地址，并且通过alias设置了一个浮动IP地址给eth0:1。而私有内网eth1上也设置一个真实IP地址，并且也设置一个浮动的IP alias给eth1:1。
当发生failover时，两个网卡上的alias IP将同时由后备LVS路由器接管。所有的内网真实服务器都使用NAT路由器上的浮动IP作为它们的默认网关以相应Internet的服务请求。
LVS路由器采用网络地址转换方式实现VIP地址的替换，也称为IP masquerading，因为对于请求客户端是不知道实际服务器的IP地址的。
使用NAT路由，真实服务器可以使用任何操作系统。这种NAT拓扑的缺点是LVS路由器可能称为网络中的瓶颈，因为不论进出流量都需要经过LVS路由器处理。
Direct Routing
Direct Routing方式比NAT方式提高了性能。直接路由允许真实服务器和路由包直接发送给请求客户端而不需要通过LVS路由器处理。这种Direct Routing模式减轻了网络复旦，因为LVS路由器只需要处理进入的数据包。
在典型的direct-routing LVS配置中，一个LVS路由器通过一个虚拟IP（VIP）接收到进入的服务器请求，然后使用一个预定算法路由请求给实际服务器。每个实际服务器处理请求 并直接发送响应给客户端，绕过了LVS路由器。Direct Routing增强了实际服务器的扩展性，不会增加LVS路由器处理外出流量的负载，避免了高网络负载的瓶颈。
虽然有很多优点，但是也有限制。最常见的限制是direct routing带来的ARP问题。
在典型的环境下，客户端发出对一个IP地址的请求。网络路由器通常会发送请求给连接的和IP地址相关MAC地址的主机。ARP请求被广播给所有网络上连接的 主机，并且具有正确的IP/MAC地址组合的主机将接收数据包。这个IP/MAC关联被存储在一个ARP缓存中，并且周期性释放（通常15分钟）并且重新 以相关联IP/MAC组合进行填充。
在direct-routing模式下的LVS配置对ARP请求存在困难，因为客户端发送的IP地址必须有 一个响应的MAC地址来处理请求，然而，在LVS路由器上的虚拟IP地址必须和这个MAC地址绑定。但是由于LVS路由器和实际服务器都具有相同的 VIP，这个ARP请求被广播到所有绑定这个VIP的实际服务器节点。这会导致一些问题，例如VIP被分配给一台实际服务器来处理直接的请求，完全绕过 LVS路由器并且和LVS配置冲突。使用更快CPU的LVS路由器可以更快速响应客户端请求来减轻这个问题。但是如果LVS负载很大，可能比底层的实际服务器响应要慢，则实际服务器快速响应的IP/MAC组合会被请求客户端缓存而导致问题。
要解决这个问题，则要求进入的请求只和LVS路由器的VIP相关联，然后被发送给实际服务器。这种要求可以使用 arptalbes 包过滤工具来实现。
持续性和防火墙标记
在一些环境下，可能需要一个客户端请求秩序被发送到相同的实际服务器，而不是采用LVS负载平衡算法发送到最佳可用服务器。例如多屏幕web forms，cookies，SSL和FTP连接。LVS提供了两种不同的功能来处理持续性和防火墙标记。
当激活了persistence，这个持续性类似一个计时器。当一个客户端连接一个服务，LVS将在一段时间周期内记住最近的连接。如果相同的客户端IP地址在这个周期内再次连接，则会把这个请求发送给相同服务器，而忽略负载平衡算法。当连接超出了这个计时窗口，则响应开始采用负载平衡算法分发请求。
持续性也允许指定一个子网掩码来用于客户端IP地址作为控制工具，以在一个较高层次维持持续性。
组合指向不同端口的连接对于某些要求多端口的协议应用非常重要，例如FTP。然而，持续性并不是最有效的处理组合连接的方法。对于这些情况，最好采用firewall marks。
防火墙标记是费用易于使用并且有效的组合端口用于特定协议的方式。例如，如果LVS部署在电子商务网站，firewall marks可以用户捆绑HTTP连接到端口80和安全端口https端口443。通过设置相同的firewall mark到虚拟主机，状态信息被持续化，因为LVS路由器将所有请求都发送给一个连接处于打开状态的相同的实际服务器。
由于易于使用和高效率，LVS管理员更愿意使用firewall marks而不是持续性设置。
客户端管理工具
Red Hat Cluster Suite提供了一系列工具用于管理和配置集群。
Conga
Conga是一个软件集合提供了中心管理配置集群和存储的方式：
- WEB接口方式管理集群和存储
- 自动部署集群数据和支持软件包
- 易于集成现有的集群
- 不需要重新授权
- 集成的集群状态和日志
- 在用户权限层次定义控制
最主要的Gonga组件是luci和ricci，两者可以分开安装。其中，luci是运行在某个主机的服务器并且通过ricci和多个集群和主机进行通讯。ricci是一个代理，运行在所有由Conga管理的主机上。
luci通过一个web浏览器提供以下三个主要功能：
- homebase – 提供添加和删除主机，添加和删除用户，配置用户权限
- cluster – 提供配置和创建集群功能。每个luci的会话列出被luci设置的集群。一个系统管理员可以在面板管理所有集群。而另外一些用户可以中管理起被允许管理的集群。
- 存储 – 提供远程管理存储的工具。
当刚安装的luci会话初始化，需要管理员注册主机，也可以导入luci服务器。
当加入luci的服务器被管理，认证只需要一次。就可以进行远程管理（除非其证书被CA所回收）。
Cluster Administration GUI
通过system-config-cluster集群管理图形界面可以用于管理cluster构架和高可用服务。包括：
Cluster Configuration Tool
维护cluster配置组件的配置文件 /etc/cluster/cluster.conf ，以层次图形方式显示。
- cluster nodes – 显示节点
- fence devices
- Managed Resources -
- Failover Domains
- Resources
- Services
Cluster Status Tool
可以使用Cluster Status Tool来enable，disable，restart或relocate一个高可用服务。
命令行管理工具
- ccs_tool – Cluster Configuration System Tool
- cman_tool – Cluster Management Tool
- fence_tool – Fence Tool
- clustat – Cluster Status Utility
- clusvcadm – Cluster User Service Administration Utility
Linux Virtual Server Administration GUI
Red Hat 提供了LVS的WEB管理工具Piranha Configuration Tool。这是一个web方式的GUI用于创建LVS的配置文件 /etc/sysconfig/ha/lvs.cf。
要访问 Piranha Configuration Tool 需要在active LVS服务器上运行 piranha-gui 服务。可以通过 http://localhost:3636 来访问配置。