You are here
马哥 40_03 _Linux集群系列之十七——RHCS架构详解 有大用
RHCS: Red Hat Cluster Suite,红帽集群套件,主要是一个高可用集群,内在也包含了像lvs的负载均衡集群的解决方案,还为lvs的前端提供了专用的基于gui界面的配置工具,这个配置工具可以让lvs工作在高可用的环境当中,叫pilaha,当然有很多其它的工具
RHCS的功能有:
LVS:负载均衡集群
HA:高可用
GFS:集群文件系统
cLVM:集群逻辑卷套件
高可用集群的特性:多少节点,每个节点的通信状态如何,成员关系,当前是否具备法定票数
依赖于集群基础架构层(信息层) Cluster Infrastructure,在这个层次传递心跳信息,完成成员关系配置,检查法定票数等
集群基础架构层并不能真正为非具有高可用能力的服务提供高可用功能, (集群基础架构层有 :heartbeat,corosync,cman(红帽早期用的集群基础架构层,cluster manager),keepalived(工作机制与 heartbeat,corosync工作机制是不同的,它们甚至不是同一种实现高可用功能的机制)
所以还需要一个资源管理层 CRM ,可以实现资源的配置,资源的属性,包括资源的管理,资源配置,资源删除,资源添加,资源属性清理,资源迁移等众多功能,还能够完成基于资源代理的方式在相应的节点上启动停止或者重新配置资源,,
crm本身也是一个应用程序: (heartbeat v1本身带有haresources,heartbeat v2用的是crm,heartbeat v3用的是pacemaker)corocync也可以和pacemaker结合起来工作
RA(资源代理),可以有多个,多种 lsb(/etc/init.d下的服务脚本),ocf(providers:heartbeat,pacemaker,linbit),legacy HB v1,stonith
RHCS
cman: 信息层(集群基础架构层)
rgmanager: 提供资源管理功能的资源管理器 resource group manager 资源组管理器
ra
internal 自带的
script 类似于我们在heartbeat中提到的lsb的格式(/etc/rc.d/init.d/*) ,,,我们要配置资源管理服务功能的话,要指明脚本路径
RHCS的信息层,资源管理器概念与heartbeat,corosync概念差不多,ra的概念与heartbeat,corosync的概念有点不一样,,
RHCS也有自带的资源代理,与heartbeat自带的一样
RHCS在红帽4,5,6上实现各不相同
在红帽4上,cman是一个独立的组件,它一个完整的基础架构层;;;;rgmanager是一个独立的完整的资源管理器,有自己的ra的管理机制
在红帽5上,特别是5.3以后,cman充分借鉴了(openais发展起来了,corosync尚未独立出来),,cman发现corosync所实现的底层信息成员节点管理的功能(成员关系管理,心跳信息传递等等)比cman自己提供的还要优秀,,,,openais本身自己所附带的corosync(2008年之前还未独立)...所以说当时cman看到的是openais的功能,(cman本身开发人数少,它是红帽专门提供的,红帽里面一个开发人员开发的),,,,,此时cman不再是完整意义上的底层的基础信息架构层,它是借助于openais来实现成员关系管理,心跳信息传递等,此时cman是作为openais的一个插件,红帽5上cman的基础工作平台已经是openais了,,,,此时的openais的法定票数(投票系统上)的功能还没有一个很好的解决方案,而且openais的法定票数的管理机制的确是以插件的方式进行管理的,,,cman所提供的法定票数的管理功能是非常优秀的,所以保留了cman的这个功能,把cman仅仅作为openais的一个模块来使用了,,,,在红帽5的rhcs当中,它的底层信息架构已经是openais,但是cman是作为openais的插件在工作的,但是此时整个集群的配置文件(底层信息工作机制)并不依赖于openais
/etc/openais/openais.conf #openais的配置文件
/etc/corosync/corosyc.conf #corosyc来了,corosyc的配置文件起主导作用
/etc/cluster/cluster.conf #cman来了,cman的配置文件起主导作用
此时cman虽然是作为插件存在的,但是控制了借助于openais完成cman想要完成功能的机制,,核心控制机制是cman,
在cman的基础之上,提供了资源管理器功能的是rgmanager
cman借助于openais完成了成员关系管理,心跳信息传递等,cman作为插件保留了投票系统(法定票数计算的算法),cman作为一个模块,控制了整个openais的工作机制,
在红帽6上,与红帽5差不多,,,但是cman插件,也完全不用提供了在openais上,因为在红帽6上,rhcs当中,它所使用的底层机制已经不再是openais,(因为此时,openais已经独立出来一个子项目叫corosync),所以在红帽6上的rhcs套件当中,cman插件依然存在,但它所利用的底层信息通道是corosync,而corosync自带已经有投票系统了,虽然其不是特别的好,但是依然以插件的方式工作,,,,此时我们依然可以配置corosync能够使用cman,但是也可以不再使用cman了,,,,,当然有cman更好点,,,,如果不用cman,corosync所使用的配置文件,以前讲过(/etc/corosync/corosyc.conf ),,,,如果使用cman,它的配置机制依然与红帽5一样(/etc/cluster/cluster.conf),,,,,,,如果不用cman的话,,资源管理器,使用pacemaker,,,如果使用cman的话,资源管理器使用rgmanager....借助于pacemaker,它的资源管理功能比rgmanager更强大,但是就算使用了cman,pacemaker无法工作起来,因为此时控制者,主导者是cman,,,因为此时启动的是cman服务,而不是corosync服务,,但是cman却要借助于corosync来工作,
corosync发展到2.3.0(代码叫needle,每个版本都有个专门的代码名称的)以后(目前主流版本??1.4.5和2.3.0两个版本),,,提供了优于cman的投票系统,叫votequorum,,,,,,votequorum是借助于cman发展起来的,所以从此以后,cman退出江湖了,,,,所以,从此以后cman的所有配置文件都被整合进了 /etc/corosync/corosyc.conf 所以cman的原作者说希望大家不要骂他,不要给读来困惑.
rhcs除了有信息层,资源管理层,还有其它组件,如gfs,它是严重依赖于高可用集群的
gfs: Global File System 全局文件系统(又称集群文件系统),,,红帽4上常见,
gfs2: 第二个版本,红帽5上提供了gfs2,兼容gfs, 红帽6上只有gfs2
dlm: 在实现集群文件系统上,还有一个机制,叫dlm,distribute lock manager,是需要运行在各节点上的一个守护进程,这些锁管理器彼此之间要进行通信,基于TCP/IP通信,它们还要借助于高可用集群的功能,来完成其中某一个节点退出以后,要把它fence掉,所以它们要借助于高可用集群实现fence功能的,,,dlm需要在每一个节点上都运行起来,(把它作为资源在各个节点上启动)这就是克隆资源吧,,,,所以说dlm完全整合进了高可用集群,,,,,,
此时它是一个集群文件系统(既然是一个集群文件系统,而且能够被集群中的多个节点同时访问,那它应该就是个共享存储吧,不应该是NAS,应该是 DAS或SAN设备,即块级别的设备)
在一个节点上分区格式化为集群文件系统,三个节点就可以同时挂载了
现在文件系统为了加速文件系统的修复功能,突然断电后,想知道哪些文件正常,哪些不正常,(ext2,ext3区别在日志上)意味着某一个节点挂载集群文件系统以后,它的某些文件,尤其是元数据写入操作,是先写到日志里面,而后再同步到磁盘上去,两个节点挂载同一个文件系统的时候,它不能使用同一个日志区域,每一个节点在实现依赖日志区域的时候,它们完成的修复检查等操作是不完全一样的,所以日志区域各不相同,所以,集群文件系统(尤其是gfs)的重要特点在于,让几个节点能挂载,就要为它们创建几个日志区域(日志文件)
如果要使用双主模式的drbd的话,意味着两个节点有可能同时往同一个drbd设备上写数据,最终这些数据都要合并的,要向对方传递的,所以在传递之前,必须要确保每一个节点所操作的文件,对方没有操作,所以drbd也要借助于分布式锁管理器完成锁信息的传递,所以双主模型的drbd也必须要借助于集群文件系统才能实现的
ocfs2: Oracle Cluster File System 2 , 有人研究发现,ocfs2在io量比较大的场景下,它的性能是非常差的,所以ocfs2没有gfs2流行,oracle官方在布署集群文件系统的时候,也建议使用gfs2,
在搜索引擎里搜gfs的话,得到的答案,未必是我们所想要的,因为目前来讲,gfs还是另外一个文件系统的简称,google file system,它是应用在海量数据处理当中的一个分布式文件系统,分布式文件系统与集群文件系统是两个概念.
我们把一个磁盘分区做成集群文件系统,假设它所占用的空间比较大,50G的分区给它,不够了,很难扩展,,,容易扩展文件系统的机制是一个逻辑意义上的设备,叫lv,提供这样一个组件的叫lvm,( logic volume manager 逻辑卷管理器),如果在集群当中,我们要想使用集群文件系统的话,我们甚至还可以使用集群逻辑卷, clvm,,,它本身并不是一个新的逻辑卷的管理机制,clvm只不过是借助于ha的功能,将某节点上的对LVM的操作通知给其它节点,它实现了将lvm借助于ha的功能,实现了将lvm做成了分布式的这种机制,所以一个节点扩展了一个lvm,另外的节点马上就能够看到,它借助于ha的基础信息架构层,将相关的信息通知给了其它节点,,,所以clvm的逻辑卷管理工具依然都是此前所说的如 pvcreate,vgcreate,lvcreate等相关的一大堆命令,,只不过它借助于集群将某一个节点上的所有操作立即通知给了其它节点,,,,而且在操作之前加了锁,避免其它节点也发起同样的操作,所以借助于集群逻辑卷还可以(比如在共享的文件系统上创建一个分区,把这个分区创建成了pv,vg,lv),当然在某一个节点上创建的时候,必须立即通知给其它节点,所以我们必须要把lvm做成高可用集群中的一个具有分布式功能的lvm,所以称为clvm,我们只需要在原有的lvm的基础上,让它启用集群的功能就可以了
马哥建议使用gfs2,
集群文件系统可以让多个节点使用同一个文件系统,(ext2,ext3,xfs,risefs等都是单机文件系统,在某一时刻只能为一个节点所使用,如果多个节点同时挂载使用的话,由于每一个节点在实现使用其数据,元数据的时候,都是载入到内存中进行管理,所以会导致文件最终写到磁盘上时,会导致文件错乱的),,,多个节点要想同时挂载使用同一个文件系统,必须要使用全局文件系统(它能够将一个节点持有的文件锁信息状态通知给另外的节点,,,,,,通知要借助于高可用集群的基础架构层来实现)高可用集群的基础架构层上面实现了分布式文件锁管理器,,,,,文件锁管理器仅是借助于ha的基础信息架构层来完成其某些必要信息的(包括持有锁信息的)传递,也要完成成员节点关系的管理
由于大家使用同一个集群文件系统,为了避免集群分裂以后仍然有可能产生资源争用,它必须要实现节点 fence 的,想要实现fence的功能,它依然要借助于高可用的底层信息架构层(集群基础架构层)来完成,,,,所以DLM要依赖于它来完成
[root@node1 ~]# cd /etc/lvm/
[root@node1 lvm]# ls
archive backup cache lvm.conf
[root@node1 lvm]# vim lvm.conf
....................
# Type of locking to use. Defaults to local file-based locking (1). #基于本地使用的
# Turn locking off by setting to 0 (dangerous: risks metadata corruption
# if LVM2 commands get run concurrently).
# Type 2 uses the external shared library locking_library. #使用外部的共享库中所提供的锁库
# Type 3 uses built-in clustered locking. #使用内在的集群锁 #这里我们要改为3,并启动clvm的功能,还要装上个clvm的插件,启动clvm服务,它就完全工作为集群逻辑卷了,然后在集群逻辑卷上,格式化为集群文件系统,就可以让多个节点同时挂载了;;;;将来发现文件系统大小不够了,只需要将逻辑卷扩展一下(把卷组扩展一下,把逻辑卷扩展一下,把文件系统再扩展一下,就可以了)
# Type 4 uses read-only locking which forbids any operations that might
# change metadata.
locking_type = 1 #锁类型 锁定类型,默认为1,表示它只是在基于本地文件进行锁定的
....................
红帽4上cman是工作在内核空间的,
在内核空间当中,如下图图一,我们的rhcs提供的套件,cman,dlm,lock_dlm(锁),gfs(文件系统)等都是在内核当中实现的,它借助于共享存储来完成gfs,gfs所提供的使用的各种接口要通过vfs来输出给应用程序(linux当中,所有对文件系统的操作都要借助于vfs接口来实现)
应用程序对文件系统的文件想持有锁要借助于libdlm库,对某个文件施加锁,并且施加锁以后,它要通过dlm(借助于cman的机制)将我们的持有锁的信息通知给其它节点,万一发现其它节点出现故障了,我们要fenced掉(隔离掉)
所以要实现fenced的功能,要借助于fenced服务(资源),但是这个资源在采取操作的时候,必须借助于服务才能去fence其它节点上的设备的,,,,
ccsd: cluster configuration system(services) daemon,集群配置系统守护进程,这是红帽rhcs上的一个套件,,专门负责实现集群配置文件管理的,在任何一个节点上改变了配置文件,它能够自动的同步到其它节点上去
我们只需要在一个节点上创建修改配置文件之后,不用做任何操作,只需要启动 cman 服务,(告诉cman,有几个节点,它会自动的将这个服务同步到其它节点上去)(这个时候,同步之前,其它节点上只需要启动cman服务就行)
ccs: cluster configuration system 集群配置系统
在rhcs当中,cman的核心配置文件/etc/cluster/cluster.conf,在一个节点上面改,改完以后(像corosync一样),每个节点必须要一模一样,,,我们此前改corosync配置文件以后,我们是scp复制过去的,cman不需要这样,cman在每一个高可用集群的节点上,都运行一个叫做ccsd的服务(守护进程),一旦我们在某个节点上改了/etc/cluster/cluster.conf配置文件,ccsd会立刻监控着这种变化,并且通过我们的底层信息通道层(我们通常是多播的)将配置文件同步到了其它节点,,,,,,,,
红帽4
图一
fenced与ccsd的功能的工作机制是近似的,,,红帽4上cman是工作在内核当中的;;;比较复杂,比较难于管理,
红帽5,cman是借助于openais来工作的,openais是设计了尽可能在用户空间工作的服务,右下角是内核中的功能,只有gfs和分布式文件锁,(锁功能与文件系统功能相关,一定要在内核当中),大多数功能都移到了用户空间当中去了,如openais的核心功能(aisexec,corocync也会启动它的),aisexec完成基本心跳传递,成员关系管理(有几个节点),需要不需要 fence节点等等,,,,cman是一个插件(为了完成投票系统的),cman要想完成资源管理,要借助于rgmanager(与pacemaker差不多)(corosync要启动pacemaker的功能,它要启动一个pacemaker的服务进程的crmd(pacemakerd));;;而这里cman启动的是groupd(可以理解成资源管理器的守护进程);;;;;;;同时ccsd和fenced依然在工作, 由下图图一我们看到高可用信息传递层次在用户空间了,
dlm_controld,守护进程,dlm的控制器,分布式锁的控制器,,,,,是完成对于锁本身的管理的(持有锁之后要释放锁之类的,在组管理(groupd)中,借助于dlm_controld完成锁本身的管理,就是表示锁的施加和释放等等)
lock_dlmd,守护进程,锁管理器,,,,,
一个应用程序想持有锁,需要借助于库libdlm,借助于dlm的机制,通过lock_dlm对文件施加锁,一个系统施加锁之后,要通知另外一个文件系统(就是通过lock_dlmd与另外一个节点上的lock_dlmd完成锁通知的)
红帽5 图一
红帽5中,大多数功能都移到了用户空间
红帽6中,定义高可用资源的时候,架构就更明晰了,完全借助于类似此前corosync的机制,cman此时借助于corosync(不再借助于openais),,,资源管理都完全依赖于rgmanager,没有ccsd了,说明rgmanger自己内部就可以完成配置的传递了,我们在使用corosync的时候pacemaker(我们使用crm的所有配置,资源配置,不是基础信息架构层的配置文件的配置),我们配置完成后,不需要手动往其它节点上同步,rgmanager也有这种功能,,,,,,也不再借助于ccsd完成配置文件的传递,,,,,,而且把配置分开了,资源管理的配置,基础信息架构层的配置不再是同一个配置,,,,,,,,,,,,在红帽6上,它的所有机制都使用dlm来完成了,而在内核中没有lock_dlm这个机制了,它把lock_dlm这个机制完全移到了dlm_controld当中来实现了,而对gfs的文件系统管理使用gfs_controld来完成,而对ocfs文件系统使用dlm_controld,,,,,,,dlm_controld和 gfs_controld这两个子系统看上去是两个独立的系统,其实gfs_controld可以没有,只不过为了能够实现对gfs文件系统的管理,红帽专门提供了一个专用的优化的控制工具(这是一个组件,控制进程)gfs_controld来实现,,,,而ocfs2文件系统借助于dlm_controld来完成的,,,,,这里没有gfs_controld,也照样可以工作的,,,,,,,,如果用不到集群文件系统的话,dlm_controld和gfs_controld这两个组件是不需要启动的,,,只要有cman,有rgmanager,就足够了
红帽6 图二
下图 图三是红帽官方所提供的图,rhcs套件当中,所提供的整个架构,是下图图三的方式来工作的,客户端访问我们的集群的高可用服务,两类客户端,(一类是直接访问集群中的高可用服务)(另一类是大量的来自外网的客户端,因为访问量非常大,所以我们使用lvs做负载均衡,负衡均衡将用户的请求到集群的各节点上,这些节点上有可能用的是同一个服务(有的时候两个节点上运行的可能是同一个服务),这个时候我们要实现多主模型或双主模型的集群了,,,这些高可用集群里面所提供的组件有:cman/dlm,fencing,ccs,rgmanager,gfs,clvm等),,,,,,,而在lvs这个层次上,还有一个piranha,piranha是为lvs提供高可用的功能,并且提供一个gui配置界面(打开网页后,直接定义好哪个是realserver,要使用什么算法,在web界面上就可以指定了,当然得明白背后的原理,,,使用piranha还没有使用ipvs简单,)
图三
站在高可用集群的角度,多个节点之间如果需要用到共享文件系统的话,可能要基于fc的交换机连到共享存储上,,,,,同时,有可能使用以太网交换机,连到一个内部网络上,这个内部网络有一个叫网络电源交换机(用来控制电源的),所以所有这些节点的电源都连到这个交换机上,来供电,万一某个节点发生故障,通过这个交换机向电源交换机发送控制指令,就可以stonith了,,,,,,,,,通过另外的外网的网络接口就可以向客户端提供服务了
这是rhcs套件的整体结构
微观结构,cman/dlm cman是基础信息架构层,在每个节点上都要运行起来,它们要完成心跳信息传递的,在红帽5上,cman要借助于openais来提供,(在红帽6上,cman要借助于corosync来提供,),,,它有可能要提供clvm,gfs,,,,,,,,gfs要为管理共享文件系统基础组件的
为了完成这样一个集群的运作,需要用到很多组件,我们的集群在每个节点上为了对全局有个掌握,大家要有配置文件,/etc/cluster/cluster.conf,,,,,在一个节点上修改了这个配置文件以后,所有的节点都得一样,ccs负责自动通知,,,ccs是一个用户空间的进程,ccs要借助于底层信息通道层来工作,
Failover Domains,这是rgmanager所独有的概念,故障切换域(故障转移域)
rhcs当中有一个概念叫 Failover Domain ,当一个节点发生故障以后,运行在A节点上的服务,要转移到其它节点,转移到哪个节点上去???(corosync中有对称集群和非对称集群,可以转移到所有节点上,或者哪个节点都不能转移,但是可以开放一些节点给它) 在红帽rhcs当中,使用故障转移域的概念,明确说明,当A节点故障,A节点上的服务都要只能转移到B节点上,,,,,,(当一个节点发生故障时,这个节点上的资源或服务所能够转移的目标节点)它进而限定了一个节点上的资源或服务所能够转移的节点范围.......如下图图三,把BCD做成第二个转移域,如果B上面的服务出现故障以后,它可以转到A或C或D上,因为B与A在同一个域内,B也与C,D在同一个域内,,,,,,B上的资源到底应该转到哪个节点呢??(B往哪个节点上转,要看是哪个服务了,如下图图三,如果B节点上X服务出现故障了,X服务要往A上转,,,,Y服务出现故障了,会转向C或者D,,,,,,需要定义一个策略,可以无限制的转移到C或D,也可以按优先级进行转移,)(比如定义故障转移域,1号故障转移域为A,B,2号故障转移域其包含的节点为B,C,D,,,,,service Y,只能在B,C,D中转移(即2号故障转移域内转移),,,,,,rhcs当中必须要定义一个故障转移域,故障转移域是一个独立的概念,,,)B,C,D是有优先次序的,先转到哪个节点,再转到哪个节点,最后转到哪个节点,,,根据次序来设定优先级
如果B节点上Y服务发生故障,B节点没问题,心跳信息依然在传递,,是尽可能的转移到C或者D上,还是尽可能的让B上的Y服务重启一下,(我们惯常做法,先在本机B上重启一下),,,,,,,,到底是重启还是转移, 这些策略我们是需要定义的
我们定义服务(或者故障转移域?)的时候,就要定义服务发生故障的时候,它的优先次序,先采取什么动作(比如重启)重启不成功的话,就要转移出去了(relocate),如果没有其它节点可用的话,这个服务只能停了
故障转移域其实与服务相关的
corosync中:服务,HA Server,一个高可用服务应该由很多资源组成,如vip,httpd,Filesystem,,它们组成了一个服务,,,,rhcs中的服务是同样的概念,包含了多个资源,这些资源独立的提供了某一种类型的或者说某一种高可用应用的
故障转移是与服务相关的,我们定义一个服务的时候,必须要给这个服务定义一个其所能够转移的节点范围,,,所以是服务故障转移域,不是节点故障转移域
图三
一般高可用集群,至少三个节点
cman中尤其如此,cman中建议每个节点都有票数,还要决定看看某个节点是否满足法定票数,不满足法定票数,还要被 fenced, 被 stonith 的,假如打算把三个节点做成高可用集群,,,我们在三个节点上要完成的操作:要安装集群软件,,,,,,要配置服务,,,,,,将来要用到共享存储的话,尤其对SAN(FC SAN,IP SAN),必须要让每个节点发现SAN设备,并且把它们当作本地设备一样来使用,这些在每个节点上都要同时执行的,假如每个节点都要同时执行一遍,我们可以通过管理机,基于ssh信任的方式,直接能够操作这些目标节点的具有管理权的用户(比如root用户),,,,,那么管理机的安全性很重要,,,,,我们在管理机上完成目标操作的分发,可能需要的目标操作有:
1) 软件安装,甚至部署操作系统(拿光盘装太麻烦,,,pxe机制,把主机接到网络上,一开机,自动会加载引导程序,自动会装载ks文件,自动完成安装,但是pxe本身功能很有限,专门有一个系统cobbler专门负责部署操作系统到每一个节点,cobbler是fedora的一个项目)
(cobbler OpenQRM和Spacewalk都能实现提供实现比pxe本身的机制更完善的系统,能够让我们完成linux的安装升级等功能)
cobbler是linux的安装服务器,能够快速的基于网络环境的安装,想大批量部署系统的话,可能要用到cobbler了,它所能提供的功能不仅仅包括软件包的安装,还包括软件包的升级,电源管理,配置的统一管理等,,,这是实现自动化运维的一个很重要的工具 cobbler这个东西不讲了,只要知道它是干什么的,摸索起来,应该很简单
2)命令: for(也可以是while或until循环),ssh 有一个著名的开源项目(马哥想不起来了),它本身提供了类似的机制,让你能够简单的在一个节点上提供命令,它会自动的联系到每个节点上去执行命令的
3)配置文件管理:puppet,这是一个重量级的部署工具,它既能够实现软件安装,也能实现软件管理,还能实现软件的分发(软件包的安装),功能强大,能够适用于非常大的环境当中,应用起来繁琐,麻烦
这里仅演示以for循环的方式来看看怎么能够实现有些命令的统一执行,软件的集中安装,服务的统一启动,停止等等,,,,,,这里需要一个专用的管理机,rhcs也恰恰借助了这种特性来实现,rhcs当中有两个组件,专门让我们去实现集群节中的节点的软件的安装,服务的启动以及额外的其它相关功能的 luci/ricci luci安装在管理机上,ricci安装在集群的各个节点上
luci是需要我们事先安装到每一个节点上???的代理,这个代理能够代为接收服务端发来的指令???,并在客户端执行的???,,,luci是一个统一命令分发界面(统一管理机制分发工具),这个分发工具提供了一个web界面,只需要打开浏览器,登录到luci上来,告诉luci哪些节点已经安装好了ricci,,ricci是我们打算安装集群的节点,,,,,,在此之后,我们只需要在ruci上发送指令,比如在这些节点上安装集群软件,就会把软件自动装在这些节点上,在这些节点上启动集群服务,它也会启动好,,,,当这些集群安装好以后,它会让我们等待,等待每一个节点的安装,安装配置并加入到集群里面来,当安装配置加入完成之后,在管理机上会提供上一个配置界面,在这个界面里面,可以定义服务,定义故障转移域,定义fence设备,并且管理各种服务的启动策略,(比如某个服务发生故障的话,是优先重启,还是转移,还是停止,,,,,,,这一切的操作都可以通过luci的界面来完成,,luci本身在接到指令以后,点确定,把指令都分发到相应的节点上进行配置)(它可能涉及到的操作包括修改配置文件,包括显示当前集群状态的属性,包括集群节点上相关软件的安装等等)
红帽5和红帽6的界面区别比较大,提供的功能区别也比较大,但是概念都是一样的,框架也基本是一样的,当然 luci/ricci只是提供给我们的管理接口,我们不用它,所有的操作在命令行下也都能完成
在红帽6.4上,也提供了pcs(整合进了系统上),pcs是一个非常强大的工具,它提供了一个具有命令行工具,能够完成集群的所有操作的命令行工具,提供了web GUI,此前我们使用的是crm执行的命令(使用pcs也能,pcs还提供了web GUI)
如果还没有摸索rcmc,马哥建议试试pcs
我们可以准备好三个节点,外加一个跳板机,但凡需要在每个节点上同时执行的命令,而且可以通过循环在跳板执行的命令都在跳板机上执行, 比如软件安装,在跳板机上for循环yum install,服务的启动都可以,,,,,至于那些不能在各节点上统一执行的(只需要在一个节点上执行的,我们再连到这个节点上执行就可以了,,,,,只要能够自动同步到其它节点上就行,或者我们必须要分开在每个节点上独立执行的,我们可以在跳板机上挨个的连接,挨个的执行)(比如cman服务的启动比较独特,,,,,,,cman要求必须挨个的启动,,,,,,一般不能使用for循环启动一个,再启动一个,因为for循环只能在一个节点上执行以后,才能执行每二个节点的,,)
如果我们不打算基于ruci/ricci 来管理安装rhcs的话,我们的rhcs套件,提供了很多命令行工具,
ccs_tool: 管理ccs的,管理集群配置文件的
cman_tool: 管理cman的,
fence_tool: 执行fence功能的( 执行fence设备的)
clustat: cluster state 显示集群状态的
clusvcadm: cluster service admin 集群服务的管理工具 高可用服务的管理器 包括启动一个服务,启用一个服务,禁用一个服务,转移一个服务,重启一个服务等
等一会儿演示rhcs的配置,我们借助于上面所说的几个工具,并借助于rhcs套件当中所提供的另外一个类似于heartbeat GUI的工具 (打开一个窗口,定义一个资源,定义一个约束);;;;;;;;;而红帽5(不止于红帽5)的rhcs里面提供了system-config-cluster来实现的,只需要在其中一个节点上装上system-config-cluster就行,而后在这一个节点上打开它进行配置,而后它会自动的通过ccs同步到其它节点
讲完rhcs套件以后,讲iscsi,之后演示到底如何部署使用gfs文件系统,甚至如何使用clvm集群逻辑卷
把负载均衡的系统和高可用系统组合起来工作,
高可用时,一般情况下,某一个服务只能运行在某一个节点上,
n个节点运行m个服务,可能有用
如果我们的director能够检查后端服务(负载均衡的rs上的服务)的健康状况,服务故障了,干脆不让它启动了,将所有请求重新分发到其它节点上去,也行的吧,也能提供后面的服务高可用的吧,,,这些节点用不用做成高可用的服务集群???,把web都要做成服务,在每个节点上都克隆一份,,,,,都启动起来,,,,,,,,,,,,,,,,,这样管理起来非常麻烦,,,光是资源定义,资源约束都是非常麻烦的,,,,将来很可能在任何地方出故障的,,,对web服务器集群来讲,通常不应该这么做的,,
在下图图五中,director,不要成为单点故障点,是可以用到高可用的,,,,,,,下面的rs服务器,如果允许写操作的话,(比如某请求转到第二个rs上来,对第二个rs执行了写操作,我们期望请求无论被定向到哪一个rs上,所得到的内容都是一样的,所以我们统一使用一个数据库,将数据都保存在数据库里面,所有的请求都通过同一个数据库取得数据,,,,但是并不是所有数据都保存在数据库里面的,比如论坛里面的附件,假设rsync+inotify同步,,,此时我们以第一个节点为主节点,意味着只要用户上传,意味着只能操作第一个节点,同步,像dns同步一样,一主多从是没有问题的,但是只有主才能修改,才能写操作的,,,文件系统也是如此,,,,,所以只要是上传操作,都必须让它通过主节点(这里是第一个节点)来执行,保存在主节点上),,,要在前端director上做一个专门的操作检测,(lvs没有检测功能),需要借助于七层的转发(分发)工具,比如haproxy
lvs的操作能力很小,只能做转发,如果需要做重定向的话,使用haproxy或nginx,,,,,,, 能够发现用户使用put或post(上传操作),我们在director前端给它做重定向,必须要访问第一个real server,不再向其它 real server 转发,
第一个节点写一次,要向其它三个节点同步三次,第一个节点的硬盘很繁忙,第一个节点如果故障了,上传操作就不能完成了,所以第一个节点可能会成为单点故障,,所以对第一个rs做高可用吧,会很麻烦的,,,,以前讲过共享存储,比如使用NAS设备(如果是SAN设备,多个节点可以同时使用了,但是同时使用时,第一个节点正在上传这个文件,第二个节点(或者本地)正在修改这个文件,文件系统会崩溃的,为了避免崩溃,加锁,所以把几个rs做成高可用集群,只不过只在这个高可用集群上使用这个集群文件系统,,,,,因为集群文件系统自身依赖于高可用集群)(我们并不把web定义成高可用服务,但我们把几个rs做成高可用集群的目的在于集群文件系统,)(web服务还是各自独立运行的服务,跟高可用没有关系,所以这个时候,你通过任何一个web服务上传数据的时候,只要保存在集群文件系统上,其它节点可以立即看到的,不会导致读写文件系统的时候,造成文件系统崩溃的)
此时就能够实现了高可用和负载均衡的搭配,,,我们只高可一部分服务,另一部分服务通过负载均衡来实现的机制(同时运行的机制),,这种架构设计对于我们来说,来根据你的实际业务需要,来组合我们的软件,来完成我们共同的任务的
将来我们在生产环境中组建一个生产可用架构的时候,比这个要复杂,层次还要多,尤其是非常大的系统的时候,
在讲完haproxy和nginx之后,以及mysql的复制之后,我们重新继续说相关的功能
分布式大规模高性能的web集群到底该如何实现
图五
集群文件系统gfs本身最多支持16个节点,再多性能很差,因为无论如何写的是同一个设备,集群文件系统未必是最好的解决方案,,,对于读写操作(尤其是写操作)非常大的场景下,我们还有分布文件系统可用
分布式文件系统与集群文件系统不同,
分布式文件系统的开源项目有很多,有的适合存大文件,有的适合存零碎的小文件,它们各自适用场景不同
分布式文件系统有: mfs, mosfs,hdfs
如下图图六,
其中一个节点是主节点,另外一堆主机是从节点,以hadoop (hdfs)分布式文件系统来介绍
主节点namenode(名称节点),所有文件的元数据(文件名称,大小,存储路径等等),都在这个节点上,
后面的一堆节点叫 数据节点 datanode ,真正的数据在这些节点上存储
当我们需要存储一个文件的时候(尤其非常大的单个大文件,比如几十个G),最适合这样来存,,我们只需要向namenode 请求存储,namenode会把请求分割成(比如每512M一个)的块,然后各往每个datanode上存512M,这样子把数据分散的存在各个节点上,将来我们要想读取这个数据,怎么办??元数据在 namenode上,先联系namenode节点,看有没有这个文件,如果有namenode会告诉我,数据在哪些节点上,,把 datenode上的相应的数据都读进来,在本地合并一下再做处理,,,,,,,,(几十个G,需要的内存太大),,,,,,,所以分布式文件系统还得解决文件大的情况下,如何获取文件的相关内容的,让每一个分布的文件(结构化的数据,半结构化的数据,无(非)结构化的数据),,,,,这些都能处理,对于不同类型的数据来讲,它的处理机制是不一样的,面对于那些非结构化的数据,比如日志,比如日志里面的数据很难结构化,里面都是一行一行的文本,可以解开,把一个500G的日志文件,解成500个1G的文件,,,每一个1G的文件还可以单独的进行查看的,所以想找要处理相关内容的时候,可能定向到某一个块上面进行处理,,,,不需要把所有数据都载入进来,
分布式文件系统 可以把数据分布的存储在多个节点上,所以叫做分布式文件系统,但是其中有一个节点称为名称节点, 名称节点保存有元数据,读写的时候,先去联系名称节点,如果名称节点挂了,数据就不能访问了,所以更重要的是名称节点上为了保证数据的访问速度足够快,这些名称的元数据很可能在内存里面,如果数据崩溃了,元数据可能会丢失的,所以我们必须要采取机制保证数据不会丢失,至少元数据不能丢失,丢失的话,文件就找不着了,因此 namenode还需要高可用的
所以高可用,分布式,负载均衡这些概念都联系到一块了,
高可用,分布式,负载均衡概念意思都不一样,
所以需要存储大量文件,有着大量写操作的时候,这种机制,它把磁盘IO分布到多个节点上去了,所以有着众多客户端请求传数据的时候,这种机制可能比较理想
图六
