高可用集群_高可用集群软件 - CSDN
精华内容
参与话题
  • 高可用集群

    2018-06-14 18:06:21
    高可用集群 这篇先来认识高可用集群的一些基本概念。1、什么是高可用集群 高可用集群(High Availability Cluster,简称HA Cluster),是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序...

    高可用集群

     

    这篇先来认识高可用集群的一些基本概念。

    1、什么是高可用集群

           高可用集群(High Availability Cluster,简称HA Cluster),是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务,把因软件、硬件、人为造成的故障对业务的影响降低到最小程度。

           简单说就是:保证服务不间断地运行,比如,在淘宝网什么时候都可以上去买东西,微信随时可以打开发消息聊天。

    2、高可用集群的衡量标准

           要保证集群服务100%时间永远完全可用,几乎可以说是一件不可能完成的任务。比如,淘宝在这几年双十一刚开始的时候,一下子进来买东西的人很多,访问量大,都出现一些问题,如下单后却支付不了。所以说只能保证服务尽可能的可用,当然有些场景相信还是可能做到100%可用的。

           通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均故障维修时间(MTTR)来度量系统的可维护性。于是可用性被定义为:HA=MTTF/(MTTF+MTTR)*100%。

          具体HA衡量标准:

    描述

    通俗叫法

    可用性级别

    年度停机时间

    基本可用性

    2个9

    99%

    87.6小时

    较高可用性

    3个9

    99.9%

    8.8小时

    具有故障自动恢复能力的可用性

    4个9

    99.99%

    53分钟

    极高可用性

    5个9

    99.999%

    5分钟

     

    3、高可用集群实现原理

          高可用集群主要实现自动侦测(Auto-Detect)故障、自动切换/故障转移(FailOver)自动恢复(FailBack)。

          简单来说就是,用高可用集群软件实现故障检查和故障转移(故障/备份主机切换)的自动化,当然像负载均衡、DNS分发也可提供高可性。

    3-1、自动侦测(Auto-Detect)/ 故障检查

         自动侦测阶段由主机上的软件通过冗余侦测线,经由复杂的监听程序,逻辑判断,来相互侦测对方运行的情况。

         常用的方法是:集群各节点间通过心跳信息判断节点是否出现故障。

    3-1-1、问题是:当有节点(一个或多个)和另外节点互相接收不到对方心跳信息时,如何决定哪一部分节点是正常运行的,而哪一部分是出现故障需要隔离的呢(避免集群脑裂)?

          这时候通过法定票数(quorum)决定,即当有节点故障时,节点间投票决定哪个节点是有问题的,票数大于半数为合法

    票数:

           每个节点可以设置票数,即决定节点在集群内是否合法(正常)的权限值,这个是可以有多有少的,例如有些节点的性能较好或有其他优势,可以设置较多的票数。

    法定票数(quorum):

           当一个节点能和另一个节点保持心跳信息,该节点就获取得了另一个节点的票数,该节点获得的所有票数就是法定票数。

    3-1-2、比较特殊的是只有两个节点的集群,或两边票数相等

           这时候可以借助另外的参考节点,如ping网关(可以是一个节点),可以和测试点ping通,但不可以和对方通,说明对方节点有问题,或本节点有问题;还有就是通过仲裁设备,如仲裁磁盘,每个节点都间隔一定时间不停往磁盘写数据,若监测到对方不再写入的时候,可能对方节点出故障。

          但最好还是使得组成集群的节点数量为单数台(2n+1),当集群分区脑裂时,节点数量小于一半(>n+1)的分区自动停止对外提供服务。

    3-1-3、Pasox算法和Zookeeper

          关于“投票”,有必要知道著名的Pasox算法和Zookeeper:

    Paxos算法:

          Paxos算法解决的是保证集群中每个节点执行相同的操作序列,可以保证分布式群集中的数据一致性。

          例如,通过投票来对写操作进行全局编号,同一时刻,只有一个写操作被批准,同时并发的写操作要去争取选票,只有获得过半数选票的写操作才会被 批准(所以永远只会有一个写操作得到批准);而其他的写操作竞争失败只好再发起一轮投票,就这样,在日复一日年复一年的投票中,所有写操作都被严格编号排序。

          编号严格递增,当一个节点接受了一个编号为100的写操作,之后又接受到编号为99的写操作(因为网络延迟等很多不可预见原因),它马上能意识到自己数据不一致了,自动停止对外服务并重启同步过程。

          任何一个节点挂掉都不会影响整个集群的数据一致性(总2n+1台,除非挂掉大于n台)。

    Zookeeper:

          Zookeeper是 Hadoop 大数据生态的一个独立组件,是 Google 的 Chubby一个开源的实现,可以说是Paxos算法(类似)的实现。

          Zookeeper主要提供分布式协调服务,分布式应用程序可以基于它实现服务注册(高可用),同步服务,配置维护和命名服务等。

          Zookeeper真正提供的是类似我们普通电脑上的文件系统目录的功能,不过可以原子的进行增/删/改/查操作;具体要实现什么分布式协调服务,需要自己写程序来操作Zookeeper上的“目录”。

          Zookeeper为什么可以作为分布式系统提供协调服务?

          最主要的是Zookeeper本身运行的是一个由多个Zookeeper节点组成的稳定的高可用集群。

           Zookeeper集群的高可用性和各节点“目录”数据的一致性正是基于 类似 Paxos算法实现的投票机制来保证的。

          所以 Zookeeper集群节点数量最好也是单数(2n+1),当集群脑裂分区时,分区节点数量不超过一半的(<n+1),会自动停止对外服务。
           比如:

          5台ZK节点组成ZK集群,当分成2台和3台的两个分区时,2台的分区会自动停止对外服务,3台的分区会继续提供服务。

          另外,如果用6台节点组成ZK集群,当分成3台和3台的两个分区时,这两个分区都自动停止对外服务,所以,容错率和5台节点组成的集群的是一样的,更应该用单数(2n+1)节点数量组成集群。

    3-2、自动切换/故障转移(FailOver)

          自动切换阶段某一主机如果确认对方故障,则正常主机除继续进行原来的任务,还将依据各种容错备援模式接管预先设定的备援作业程序,并进行后续的程序及服务。

          通俗地说,即当A无法为客户服务时,系统能够自动地切换,使B能够及时地顶上继续为客户提供服务,且客户感觉不到这个为他提供服务的对象已经更换。

          通过上面判断节点故障后,将高可用集群资源(如VIP、httpd等,下面详见)从该不具备法定票数的集群节点转移到故障转移域(Failover Domain,可以接收故障资源转移的节点)。

    3-2-1、高可用集群资源(HA Resource)和集群资源类型

    集群资源是集群中使用的规则、服务和设备等,如VIP、httpd服务、STONITH设备等。类型如下:

            1、Primitive:主资源,在某一时刻只能运行在某个节点上,如VIP。

            2、group:组,资源容器,使得多个资源同时停/启等,一般只包含primitive资源。

            3、clone:克隆,可以在多个节点运行的资源,例如stonith设备管理进程、集群文件系统的分布式锁(dlm)作为资源,应运行在所有节点上。

            4、master/slave:特殊的clone资源,运行在两个节点上,一主一从,如:分布式复制块设备drbd(2.6.33之后整合进内核了)。

    3-2-2、转移到哪个节点

    根据资源的倾向(资源粘性、位置约束的分数比较)进行转移;

    资源的倾向(资源定位的依据):

     A、资源粘性:资源对节点倾向程度,资源是否倾向于当前节点。score,正值倾向于当前节点(还要和位置约束结合)。

     B、资源约束(Constraint):资源和资源之间的关系

    a、排列约束 (colocation):资源间的依赖/互斥性,定义资源是否运行在同一节点上。score,正值表示要运行在同一节点上,负值则不可。

    b、位置约束(location):每个节点都有一个score值,正值则倾向于本节点,负值倾向于其他节点,所有节点score比较,倾向于最大值的节点。

    c、顺序约束(order):定义资源执行动作的次序,例如vip应先配置,httpd服务后配置。特殊的score值,-inf 负无穷,inf 正无穷。

           也就是说资源粘性定义资源对资源当前所在节点的倾向性,而位置约束定义资源对集群中所有节点的倾向性。如webip的资源粘性为100,位置约束对node1为200,当webip在node2上时,node1上线资源会转移到node1,因为当前节点node2粘性100小于对node1的位置约束200;如webip的资源粘性为200,位置约束对node1为100,当webip在node2上时,node1上线资源不会转移到node1,继续留在node2上,因为当前节点node2粘性200大于对node1的位置约束100。

    3-3、自动恢复/故障回转(FailBack)

          自动恢复阶段在正常主机代替故障主机工作后,故障主机可离线进行修复工作。在故障主机修复后,透过冗余通讯线与原正常主机连线,自动切换回修复完成的主机上。

    3-3-1、当排除故障后,是否要故障回转?

          根据资源粘性和资源约束的设置,一般备用设备单纯只用于备份,性能低于主设备,所以当主设备恢复时应转回,但故障回转需要资源转移,会影响到正在使用的客户,过程代价较高,所以是否需要回转根据实际判断。

    3-4、其他关注点

    3-4-1、如果节点不再成为集群节点成员时(不合法),如何处理运行于当前节点的资源?

          如果集群没有对其进行Fecning/Stonith隔离前,可以进行相关配置(without_quorum_policy),有如下配置选项:

    1、stop:直接停止服务;

    2、ignore:忽略,以前运行什么服务现在还运行什么(双节点集群需要配置该选项);

    3、Freeze:冻结,保持事先建立的连接,但不再接收新的请求;

    4、suicide:kill掉服务。

    3-4-2、集群脑裂(Split-Brain)和资源隔离(Fencing)

           脑裂是因为集群分裂导致的,集群中有节点因为处理器忙或者其他原因暂时停止响应时,与其他节点间的心跳出现故障,但这些节点还处于active状态,其他节点可能误认为该节点"已死",从而争夺共享资源(如共享存储)的访问权,分裂为两部分独立节点。

           脑裂后果:这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏。

           脑裂解决:上面3-1-1、3-1-2的方法也能一定程度上解决脑裂的问题,但完全解决还需要资源隔离(Fencing)。

           资源隔离(Fencing):

                  当不能确定某个节点的状态时,通过fencing把对方干掉,确保共享资源被完全释放,前提是必须要有可靠的fence设备。

       节点级别:

                STONITH(shoot the other node in the head,爆头。硬件方式),直接控制故障节点的电源,绝对彻底。

        资源级别:

                例如:FC SAN switch(软件方式)可以实现在存储资源级别拒绝某节点的访问

    4、高可用集群工作模型

    4-1、Active/Passive:主备模型

           一个活动主节点,另一个不活动作为备用节点,当主节点故障,转移到备节点,这时备节点就成为了主节点。备节点完全冗余,造成一定浪费。如下图,mysql、DRBD主从节点间还要进行同步:

    4-2、Active/Active:双主模型

           两个节点都是活动的,两个节点运行两个不同的服务,也互为备用节点。也可以提供同一个服务,比如ipvs,前端基于DNS轮询。这种模型可以使用比较均衡的主机配置,不会造成浪费。

    4-3、N+1

          N个活动主节点N服务,一个备用节点。这需要额外的备用节点必须能够代替任何主节点,当任何主节点故障时,备节点能够负责它的角色对外提供相应的服务。如下图,最后一个备用节点可以作为前两台主节点的DRBD和第三台主节点的MYSQL提供备用功能:

    4-4、N+M

          N个活动主节点M个备用节点。像上面的N+1模型,一个备用节点可能无法提供足够的备用冗余能力,备用节点的数量M是成本和可靠性要求之间的折衷。

          也有一种说法:N-M: N个节点M个服务, N>M, 活动节点为N, 备用节点为N-M。

    4-5、N-to-1

          这和N+1一样,也是N个活动主节点,一个备用节点;不同是的备用节点成为主节点只是暂时的,当原来故障的节点修复后,必须回转才能正常工作。

    4-6、N-to-N

          N个节点N个备用节点。这是A/A双主和N + M模型的组合,N节点都有服务,如果一个坏了,剩下的每个节点都可以作为替代提供服务。如下图,当共享存储是可用的,每一个节点都可能会被用于故障切换。起搏器甚至可以运行服务的多个副本,以分散工作量。

    5、高可用集群架构层次

        

    5-1、节点主机层

           这一层主要是正在运行在物理主机上的服务,高可用集群相关的软件运行在各主机上,集群资源也是在各主机上。

    5-2、Messaging and Membership Layer

           信息传递层,传递集群信息的一种机制,通过监听UDP 694号端口,可通过单播、组播、广播的方式,实时快速传递信息,传递的内容为高可用集群的集群事务,例如:心跳信息,资源事务信息等等,只负责传递信息,不负责信息的计算和比较。

           成员关系(Membership)层,这层最重要的作用是主节点(DC)通过Cluster Consensus Menbership Service(CCM或者CCS)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。

    5-3、CRM(Cluster Resource Manager)

          集群资源管理器层,它主要是用来提供那些不具有高可用的服务提供高可用性的。它需要借助Messaging Layer来实现工作,因此工作在Messaging Layer上层。

          资源管理器的主要工作是收集messaging Layer传递的节点信息,并负责信息的计算和比较,并做出相应的动作,如服务的启动、停止和资源转移、资源的定义和资源分配。

          在每一个节点上都包含一个CRM,且每个CRM都维护这一个CIB(Cluster Information Base,集群信息库),只有在主节点上的CIB是可以修改的,其他节点上的CIB都是从主节点那里复制而来的。

           CRM会推选出一个用于计算和比较的节点,叫DC(Designated coordinator)指定协调节点,计算由PE(Policy Engine)策略引擎实现,计算出结果后的动作控制由TE(Transition Engine)事务引擎实现。

           在每个节点上都有一个LRM(local resource manager)本地资源管理器,是CRM的一个子功能,接收TE传递过来的事务,在节点上采取相应动作,如运行RA脚本等。

    5-4、RA(Resource Rgent)

          资源代理层,简单的说就是能够集群资源进行管理的脚本,如启动start,停止stop、重启restart和查询状态信息status等操作的脚本。LRM本地资源管理器负责运行。

          资源代理分为:

    1、Legacy heartbeat(heatbeat v1版本的资源管理);

    2、LSB(Linux Standard Base),主要是/etc/init.d/*目录下的脚,start/stop/restart/status;

    3、OCF(Open Cluster Famework),比LSB更专业,更加通用,除了上面的四种操作,还包含monitor、validate-all等集群操作,OCF 的规范在http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD

    4、STONITH:实现节点隔离

    6、高可用集群软件

    6-1、Messaging Layer 集群信息层软件

    1、heartbeat (v1, v2)

    2、heartbeat v3

    可以拆分为:heartbeat, pacemaker, cluster-glue

    3、corosync

    从OpenAIS分离的项目。

    4、cman

    5、keepalived

    一般用于两个节点的集群

    6、ultramokey

    6-2、CRM集群资源管理器软件

    1、Haresource

    heartbeat v1 v2包含,使用文本配置接口haresources

    2、crm

    heartbeat v2包含,可以使用crmsh或者heartbeat-gui来进行配置

    3、pacemaker

    heartbeat v3分离出来的项目,配置接口:CLI:crm、pcs和GUI:hawk(WEB-GUI)、LCMC、pacemaker-mgmt、pcs

    4、rgmanager

    Cman包含,使用rgmanager(resource group manager)实现管理, 具有Failover Domain故障转移域这一特性,也可以使用RHCS(Redhat Cluster Suite)套件来进行管理:Conga的全生命周期接口,Conga(luci/ricci)先安装后,可用其安装高可用软件,再进行配置。

    6-3、常用组合

    heartbeat v2+haresource(或crm) (说明:一般常用于CentOS 5.X)

    heartbeat v3+pacemaker (说明:一般常用于CentOS 6.X)

    corosync+pacemaker (说明:现在最常用的组合)

    cman + rgmanager (说明:红帽集群套件中的组件,还包括gfs2,clvm)

    keepalived+lvs (说明:常用于lvs的高可用)

    7、共享存储

           高可用集群多节点都需要访问数据,如果各节点访问同一个数据文件都是在同一个存储空间内的,就是说数据共享的就一份,而这个存储空间就共享存储。

           如Web或Mysql高可用集群,他们的数据一般需要放在共享存储中,主节点能访问,从节点也能访问。当然这也不是必须的,如可以通过rsync、DRBD来同步分别存储在主、从节点上的块数据,而且相对共享存储实现成本更低,具体使用什么需要根据实际场景来选择。下面我们就简单说一下共享存储的类型:

    7-1、DAS(Direct attached storage,直接附加存储)

           存储设备直接连接到主机总线上的,距离有限,而且还要重新挂载,之间有数据传输有延时;

           这是设备块级别驱动上实现的共享,持有锁是在节点主机本地上的,无法通知其他节点,所以如果多节点活动模型的集群同时写入数据,会发生严重的数据崩溃错误问题,主备双节点模型的集群在分裂的时候了会出现问题;

           常用的存储设备:RAID 阵列、SCSI 阵列。

    7-2、NAS(network attached storage,网络附加存储)

           文件级别交互的共享,各存储设备通过文件系统向集群各节点提供共享存储服务,是用C/S框架协议来实现通信的应用层服务。

           常用的文件系统:NFS、FTP、CIFS等,如使用NFS实现的共享存储,各节点是通过NFS协议来向共享存储请求文件的。

    7-3、SAN(storage area network、存储区域网络)

            块级别的,将通信传输网络模拟成SCSI(Small Computer System Interface)总线来使用,节点主机(initiator)和SAN主机(target)都需要SCSI驱动,并借助网络隧道来传输SAN报文,所以接入到SAN主机的存储设备不一定需要是SCSI类型的。

            常用的SAN:FC光网络(交换机的光接口超贵,代价太高)、IPSAN(iscsi、存取快,块级别,廉价)。


    经过写这篇文章,对高可用集群有了一个基本的认识,下面将会动手进行应用配置……

     

    【参考资料】

    1、《大型网站技术架构:核心原理与案例分析》

    2、《从Paxos到Zookeeper :分布式一致性原理与实践》

    3、《大话存储Ⅱ—存储系统架构与底层原理极限剖析》

    4、Pacemaker:http://clusterlabs.org/wiki/Pacemaker

    5、High-availability cluster:https://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations|

    6、Linux 高可用(HA)集群基本概念详解:http://www.linuxidc.com/Linux/2013-08/88522.htm

    7、高可用集群基本概念与heartbeat文本配置接口:http://www.178linux.com/10982

    8、高可用集群原理:http://boxinknown.blog.51cto.com/10435935/1673396

    9、理解 OpenStack 高可用(HA) (4): Pacemaker 和 OpenStack Resource Agent (RA):http://www.cnblogs.com/sammyliu/p/5025362.html

    展开全文
  • Linux集群介绍及配置高可用集群

    千次阅读 2018-07-08 15:55:49
    可用:高可用集群即“HA集群”,也常称作“双机热备”,用于关键业务。通常为两台服务器,一台工作,另外一台作为冗余,当提供服务的机器宕机,冗余将接替继续提供服务,实现可用的开源软件有:heartbeat、...

    1.Linux集群介绍

    根据功能划分为两大类:高可用和负载均衡;

    高可用:高可用集群即“HA集群”,也常称作“双机热备”,用于关键业务。通常为两台服务器,一台工作,另外一台作为冗余,当提供服务的机器宕机,冗余将接替继续提供服务,实现高可用的开源软件有:heartbeat、keepalived,核心原来都是通过心跳线连接两台服务器;

    负载均衡:负载均衡集群,需要有一台服务器作为分发器,它负责把用户的请求分发给后端的服务器处理,在这个集群里,除了分发器外,就是给用户提供服务的服务器了,这些服务器数量至少为2,实现负载均衡的开源软件有LVS、keepalived、haproxy、nginx,商业的有F5、Netscaler。

    2.Keepalived介绍

    因为heartbeat软件已经在2010年就停止了更新,所以一般建议使用keepalived来实现HA集群。

           Keepalived通过VRRP(Virtual Router Redundancy Protocl)来实现高可用。VRRP是虚拟路由器冗余协议,广泛应用于边缘网络中,它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱,允许主机使用单路由器,以及及时在第一跳路由器使用失败的情形下,仍能够维护路由器间的连通性。

           在这个协议里会将多台功能相同的路由器组成一个小组,这个小组里会有1个master角色和N(N>=1)个backup角色。master会通过组播的形式向各个backup发送VRRP协议的数据包,当backup收不到master发来的VRRP数据包时,就会认为master宕机了。此时就需要根据各个backup的优先级来决定谁成为新的mater。
           Keepalived要有三个模块,分别是core、check和vrrp。其中core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析>,check模块负责健康检查,vrrp模块用来实现VRRP协议。

    3.Keepalived+Nginx实现Web高可用

    首先准备两台机器128和130,128用作master,130用作backup;

    分别在两台机器上安装keepalived(yum install -y keepalived);

    因为128在之前已经通过编译安装了nginx,在130上使用yum工具安装nginx(yum install -y nginx)。

           这里介绍一下VIP,它的名字是“Virtual IP”,即“虚拟IP”,又叫做“浮动IP”。因为这个IP是有keepalived给服务器上配置的,服务器靠这个VIP对外提供服务,当master机器宕机,VIP就会被分配到backup上。

    3.1 配置master

    编辑master(128)的keepalived的配置文件/etc/keepalived/keepalived.conf;

    global_defs {
       notification_email {
         yu@yulinux.com   #定义接收告警的人
       }
       notification_email_from root@yulinux.com   #定义发送邮件的地址
       smtp_server 127.0.0.1   #定义发邮件地址,若为127.0.0.1则使用本机自带邮件服务器进行发送
       smtp_connect_timeout 30
       router_id LVS_DEVEL
    }
    vrrp_script chk_nginx {   #chk_nginx为自定义名字,后面还会用到
        script "/usr/local/sbin/check_ng.sh"   #自定义脚本,该脚本为监控nginx服务的脚本
        interval 3   #每隔3秒执行一次该脚本
    }
    vrrp_instance VI_1 {
        state MASTER   #角色为master
        interface ens33   #针对哪个网卡监控VIP
        virtual_router_id 51
        priority 100   #权重为100,master要比backup大
        advert_int 1
        authentication {
            auth_type PASS
            auth_pass yulinux>com   #定义密码,这个密码自定义
        }
        virtual_ipaddress {
            192.168.30.100
        }
        track_script {
            chk_nginx   #定义监控脚本,这个上面vrr_script后面的字符串保持一致
        }
    }

    监控脚本如下:

    #!/bin/bash
    #时间变量,用于记录日志
    d=`date --date today +%Y%m%d_%H:%M:%S`
    #计算nginx进程数量
    n=`ps -C nginx --no-heading|wc -l`
    #如果进程为0,则启动nginx,并且再次检测nginx进程数量,
    #如果还为0,说明nginx无法启动,此时需要关闭keepalived
    if [ $n -eq "0" ]; then
            /etc/init.d/nginx start
            n2=`ps -C nginx --no-heading|wc -l`
            if [ $n2 -eq "0"  ]; then
                    echo "$d nginx down,keepalived will stop" >> /var/log/check_ng.log
                    systemctl stop keepalived
            fi
    fi

    设置监控脚本的权限,并启动keepalived服务。

    [root@yuioplvlinux-128 ~]# chmod 755 /usr/local/sbin/check_ng.sh
    [root@yuioplvlinux-128 ~]# systemctl start keepalived   #启动keepalived
    [root@yuioplvlinux-128 ~]# ps aux|grep keep   #查看keepalived是否启动
    root      1912  0.1  0.1 118676  1396 ?        Ss   20:00   0:00 /usr/sbin/keepalived -D
    root      1913  0.3  0.3 129604  3308 ?        S    20:00   0:00 /usr/sbin/keepalived -D
    root      1915  0.1  0.2 129544  2844 ?        S    20:00   0:00 /usr/sbin/keepalived -D
    root      1962  0.0  0.0 112720   972 pts/1    R+   20:00   0:00 grep --color=auto keep
    [root@yuioplvlinux-128 ~]# ps aux|grep nginx   ##查看nginx是否启动
    root       858  0.0  0.1  46064  1168 ?        Ss   17:30   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
    nobody     859  0.0  0.3  48552  3788 ?        S    17:30   0:00 nginx: worker process
    nobody     860  0.0  0.3  48552  3800 ?        S    17:30   0:00 nginx: worker process
    root      2078  0.0  0.0 112724   972 pts/1    R+   20:01   0:00 grep --color=auto nginx

    关闭nginx服务,再去查看nginx发现还是启动的,这是因为在脚本中定义了,当nginx服务挂掉时,就会自动重启。

    [root@yuioplvlinux-128 ~]# /etc/init.d/nginx stop
    Stopping nginx (via systemctl):                            [  确定  ]
    [root@yuioplvlinux-128 ~]# ps aux|grep nginx
    root      2348  0.0  0.1  46064  1276 ?        Ss   20:03   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
    nobody    2352  0.0  0.4  48552  4172 ?        S    20:03   0:00 nginx: worker process
    nobody    2353  8.0  0.3  48552  3916 ?        S    20:03   0:00 nginx: worker process
    root      2355  0.0  0.0 112720   972 pts/1    R+   20:03   0:00 grep --color=auto nginx

    3.2 配置backup

    编辑backup(130)的keepalived的配置文件/etc/keepalived/keepalived.conf;

    global_defs {
       notification_email {
         yu@yulinux.com
       }
       notification_email_from root@yulinux.com
       smtp_server 127.0.0.1
       smtp_connect_timeout 30
       router_id LVS_DEVEL
    }
    vrrp_script chk_nginx {
        script "/usr/local/sbin/check_ng.sh"
        interval 3
    }
    vrrp_instance VI_1 {
        state BACKUP
        interface ens33
        virtual_router_id 51
        priority 90
        advert_int 1
        authentication {
            auth_type PASS
            auth_pass yulinux>com
        }
        virtual_ipaddress {
            192.168.30.100
        }
        track_script {
            chk_nginx
        }
    }

    监控脚本如下:

    #时间变量,用于记录日志
    d=`date --date today +%Y%m%d_%H:%M:%S`
    #计算nginx进程数量
    n=`ps -C nginx --no-heading|wc -l`
    #如果进程为0,则启动nginx,并且再次检测nginx进程数量,
    #如果还为0,说明nginx无法启动,此时需要关闭keepalived
    if [ $n -eq "0" ]; then
            systemctl start nginx
            n2=`ps -C nginx --no-heading|wc -l`
            if [ $n2 -eq "0"  ]; then
                    echo "$d nginx down,keepalived will stop" >> /var/log/check_ng.log
                    systemctl stop keepalived
            fi
    fi

    设置监控脚本的权限,并启动keepalived服务。

    [root@yuioplvlinux-130 ~]# chmod 755 /usr/local/sbin/check_ng.sh
    [root@yuioplvlinux-130 ~]# systemctl start keepalived
    [root@yuioplvlinux-130 ~]# ps aux |grep keep
    root      2036  0.0  0.1 118676  1400 ?        Ss   04:20   0:00 /usr/sbin/keepalived -D
    root      2037  0.4  0.3 129604  3304 ?        S    04:20   0:00 /usr/sbin/keepalived -D
    root      2038  0.0  0.2 129544  2844 ?        S    04:20   0:00 /usr/sbin/keepalived -D
    root      2073  0.0  0.0 112720   968 pts/1    S+   04:21   0:00 grep --color=auto keep
    [root@yuioplvlinux-130 ~]# ps aux |grep nginx
    root      1985  0.0  0.0  46404   968 ?        Ss   03:22   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
    nginx     1986  0.0  0.1  46804  1932 ?        S    03:22   0:00 nginx: worker process
    root      2087  0.0  0.0 112720   968 pts/1    S+   04:21   0:00 grep --color=auto nginx

    在浏览器中分别访问master、backup以及VIP,可以看到VIP是连接到master上的;



    在master上关闭keepalived(systemctl stop keepalived)再去访问VIP,可以看到连接到了backup上。



    展开全文
  • Linux 高可用(HA)集群基本概念详解

    千次阅读 2019-05-29 08:36:13
    一、高可用集群的定义 高可用集群,英文原文为High Availability Cluster,简称HACluster,简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的...

    一、高可用集群的定义

      高可用集群,英文原文为High Availability Cluster,简称HACluster,简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点(node)。
      高可用集群的出现是为了使集群的整体服务尽可能可用,从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效,它的备援节点将在几秒钟的时间内接管它的职责。因此,对于用户而言,集群永远不会停机。
      高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备,即使用两台服务器互相备份。当一台服务器出现故障时,可由另一台服务器承担服务任务,从而在不需要人工干预的 情况下,自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种,高可用集群系统更可以支持两个以上的节点,提供比双机热备更多、更高级的功能,更能满足用户不断出现的需求变化。

    二、高可用集群的衡量标准 

      HA(High Available), 高可用性群集是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。工程上,通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均维修时间(MTTR)来度量系统的可维护性。于是可用性被定义为:HA=MTTF/(MTTF+MTTR)*100%
      具体HA衡量标准:
    99% 一年宕机时间不超过4天

    99.9% 一年宕机时间不超过10小时

    99.99% 一年宕机时间不超过1小时

    99.999% 一年宕机时间不超过6分钟

    三、高可用集群的层次结构

      说明:高可用集群可分为三个层次结构,分别由红色部分的Messaging与Membership层,蓝色部分的Cluster Resource Manager(CRM)层,绿色部分的Local Resource Manager(LRM)与Resource Agent(RA)组成,下面我们就来具体说明(如上图),
    1.位于最底层的是信息和成员关系层(Messaging and Membership),Messaging主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。成员关系(Membership)层,这层最重要的作用是主节点(DC)通过Cluster Consensus Menbership Service(CCM或者CCS)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。
    2.集群资源管理层(Cluster Resource Manager),真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器(CRM,cluster Resource Manager),它能为实现高可用提供核心组件,包括资源定义,属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM(本地资源管理器)组件。对于CIB,只有工作在DC(主节点)上的文档是可以修改的,其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后,是由DC通过PE(策略引擎)和TE(实施引擎)来决定是否抢夺资源。
    3.资源代理层(Resource Agents),集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本),资源代理分为:LSB(/etc/init.d/*),OCF(比LSB更专业,更加通用),Legacy heartbeat(v1版本的资源管理)。

    核心组件的具体说明(如上图):
    1.ccm组件(Cluster Consensus Menbership Service):作用,承上启下,监听底层接受的心跳信息,当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息,并将结果转递给上层,让上层做出决定采取怎样的措施,ccm还能够生成一个各节点状态的拓扑结构概览图,以本节点做为视角,保证该节点在特殊情况下能够采取对应的动作。
    2.crmd组件(Cluster Resource Manager,集群资源管理器,也就是pacemaker):实现资源的分配,资源分配的每个动作都要通过crm来实现,是核心组建,每个节点上的crm都维护一个cib用来定义资源特定的属性,哪些资源定义在同一个节点上。
    3.cib组件(集群信息基库,Cluster Infonation Base):是XML格式的配置文件,在内存中的一个XML格式的集群资源的配置文件,主要保存在文件中,工作的时候常驻在内存中并且需要通知给其它节点,只有DC上的cib才能进行修改,其他节点上的cib都是拷贝DC上。配置cib文件的方法有,基于命令行配置和基于前台的图形界面配置。
    4.lrmd组件(Local Resource Manager,本地资源管理器):用来获取本地某个资源的状态,并且实现本地资源的管理,如当检测到对方没有心跳信息时,来启动本地的服务进程等。
    5.pengine组件:
    PE(Policy Engine):策略引擎,来定义资源转移的一整套转移方式,但只是做策略者,并不亲自来参加资源转移的过程,而是让TE来执行自己的策略。TE(Transition Engine): 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。

    6.stonithd组件
      STONITH(Shoot The Other Node in the Head,”爆头“), 这种方式直接操作电源开关,当一个节点发生故障时,另 一个节点如果能侦测到,就会通过网络发出命令,控制故障节点的电源开关,通过暂时断电,而又上电的方式使故障节点被重启动, 这种方式需要硬件支持。
      STONITH应用案例(主从服务器),主服务器在某一端时间由于服务繁忙,没时间响应心跳信息,如果这个时候备用服务器一下子把服务资源抢过去,但是这个时候主服务器还没有宕掉,这样就会导致资源抢占,就这样用户在主从服务器上都能访问,如果仅仅是读操作还没事,要是有写的操作,那就会导致文件系统崩溃,这样一切都玩了,所以在资源抢占的时候,可以采用一定的隔离方法来实现,就是备用服务器抢占资源的时候,直接把主服务器给STONITH,就是我们常说的”爆头 ”。

    四、高可用集群的分类   

    1.双机热备(Active/Passive)
    官方说明:Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability situations.

    2.多节点热备(N+1)
    官方说明:By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to be combined and share a common backup node.

    3.多节点共享存储(N-TO-N)
    官方说明:When shared storage is available, every node can potentially be used for failover. Pacemaker can even run multiple copies of services to spread out the workload.

    4.共享存储热备 (Split Site)
    官方说明:Pacemaker 1.2 will include enhancements to simplify the creation of split-site clusters.

    五、高可用集群软件

    Messaging and Membership Layer(信息与关系层):
    heartbeat (v1,v2,v3),heartbeat v3 分拆  heartbeat pacemaker cluster-glue

    corosync

    cman

    keepalived

    ultramokey

    Cluster Resource Manager Layer(资源管理层,简称:CRM):
    haresource,crm (heartbeat v1/v2)

    pacemaker (heartbeat v3/corosync)

    rgmanager (cman)

    常用组合:
    heartbeat v2+haresource(或crm) (说明:一般常用于CentOS 5.X)

    heartbeat v3+pacemaker (说明:一般常用于CentOS 6.X)

    corosync+pacemaker (说明:现在最常用的组合)

    cman + rgmanager (说明:红帽集群套件中的组件,还包括gfs2,clvm)

    keepalived+lvs (说明:常用于lvs的高可用)

    总结:我们经常在技术博客中看到,heartbeat+pacemaker实现mysql高可用,或corosync+pacemaker实现mysql高可用等,有的博友会问了,我们到底用什么好呢?经过上面的说明大家应该有所了解!

    六、共享存储

      说到集群, 我们不得不说到,共享存储,因为不管理是Web高可用也,Mysql高可用也好,他们的数据都是共享的就一份,所有必须放在共享存储中,主节点能访问,从节点也能访问。下面我们就简单说一下共享存储。
    1.DAS:(Direct attached storage)直接附加存储
    说明:设备直接连接到主机总线上的,距离有限,而且还要重新挂载,之间有数据传输有延时
    RAID 阵列

    SCSI 阵列

    2.NAS:(network attached storage)网络附加存储 
    说明:文件级别的共享
    NFS

    FTP

    CIFS

    3.SAN:(storage area network)存储区域网络 
    说明:块级别的,模拟的scsi协议
    FC光网络(交换机的光接口超贵,一个差不多2万,如果使用这个,代价太高)

    IPSAN(iscsi)存取快,块级别,廉价

    七、集群文件系统与集群LVM(集群逻辑卷管理cLVM)

    集群文件系统:gfs2、ocfs2
    集群LVM:cLVM
    注:一般用于高可用双主模型中(如下图)

    八、高可用集群的工作原理

    说明:这里主要以主/从节点的高可用来说明工作原理。
      主服务器和从服务器建立双机热备,基本上都是共享一个存储,以mysql为例。通常情况下,数据库文件挂载在主数据库服务器上,用户连接到主服务器上进行数据库操作。当主服务器出现故障时,从服务器就会自动挂载数据库文件,并接替主服务器的工作。用户在未通知的情况下,通过从数据库连接到数据库文件进行操作。等主服务器的故障修复之后,又可以重新提供服务;
      那么,从服务器是如何知道主服务器挂掉了呢,这就要使用一定的检测机制,如心跳检测,也就是说每一个节点都会定期向其他节点通知自己的心跳信息,尤其是主服务器,如果从服务器在几个心跳周期内(可自行设置心跳周期)还没有检测到的话,就认为主服务器宕掉了,而这期间在通告心跳信息当然不能使用tcp传输的,如果使用tcp检测,还要经过三次握手,等手握完了,不定经过几个心跳周期了,所以在检测心跳信息的时候采用的是udp的端口694来进行传递信息的,如果主服务器在某一端时间由于服务繁忙,没时间响应心跳信息,这个时候从服务器要是把主服务资源抢过去(共享数据文件),但是这个时候主服务器还没有宕掉,这样就会导致资源抢占,就这样用户在主从上都能访问,如果仅仅是读操作还没事,要是有写的操作,那就会导致文件系统崩溃,这样一切都玩了,所以在资源抢占的时候,可以采用一定的隔离方法来实现,就是从服务器抢占资源的时候,直接把主服务器给“STONITH”,就是我们常说的“爆头”;
      那么,我们又用什么方式来检测心跳信息呢?就是通过心跳线来检测。运行在从服务器上的Heartbeat可以通过以太网连接检测主服务器的运行状态,一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下,主、从服务器间的心跳连接是一个独立的物理连接,这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态,而其只要能通过其中一个连接收到主服务器处于活动状态的信息,就会认为主服务器处于正常状态。从实践经验的角度来说,建议为Heartbeat配置多条独立的物理连,以避免Heartbeat通信线路本身存在单点故障。
      上面的原理中我们提到了“隔离方法”,下面我们来说一说,隔离方法有两种,一种是节点隔离,另一种是资源隔离。节点隔离就是我们常说的STONITH(Shoot The Other Node In the Head ,俗称“爆头”),意思就是直接切断电源;常用的方法是所有节点都接在一个电源交换机上,如果有故障,就直接导致该节点的电压不稳定,或断电,让有故障的节点重启或关闭。(如下图),而资源隔离,就是 fencing 直接把某种资源截获过来。

      下面我们再来说一说“心路线”的类型,一种是串行电缆,另一种就是我们常看到的以太网线(交叉的双绞线),它们各有优缺点,串行电缆,被认为是比以太网连接安全性稍好些的连接方式,因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序,从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度,因此主、备服务器的距离必须非常短。以太网线连接,使用此方式可以消除串行线缆的在长度方面限制,并且可以通过此连接在主从服务器之间同步文件系统,从而减少了对正常通信连接带宽的占用。(如下图)

    九、如何保障系统的高可用

    我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。方法论上,高可用保证的原则是“集群化”,或者叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

    保证系统高可用,架构设计的核心准则是:冗余。

    有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是通过“自动故障转移”来实现系统的高可用。

    接下来我们看下典型互联网架构中,如何通过冗余+自动故障转移来保证系统的高可用特性。

    十、常见的互联网分层架构

    常见互联网分布式架构分为:

    (1)客户端层:典型调用方是浏览器browser或者手机应用APP

    (2)反向代理层:系统入口,反向代理

    (3)站点应用层:实现核心应用逻辑,返回html或者json

    (4)服务层:如果实现了服务化,就有这一层

    (5)数据-缓存层:缓存加速访问存储

    (6)数据-数据库层:数据库固化数据存储

    整个系统的高可用,又是通过每一层的冗余+自动故障转移来综合实现的。

    十一、分层高可用架构实践

    【客户端层->反向代理层】的高可用
    【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余来实现的。以nginx为例:有两台nginx,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。
    自动故障转移:当nginx挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-nginx,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的

    【反向代理层->站点层】的高可用
    【反向代理层】到【站点层】的高可用,是通过站点层的冗余来实现的。假设反向代理层是nginx,nginx.conf里能够配置多个web后端,并且nginx能够探测到多个后端的存活性。
    自动故障转移:当web-server挂了的时候,nginx能够探测到,会自动的进行故障转移,将流量自动迁移到其他的web-server,整个过程由nginx自动完成,对调用方是透明的。

    【站点层->服务层】的高可用
    【站点层】到【服务层】的高可用,是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。
    自动故障转移:当service挂了的时候,service-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的service,整个过程由连接池自动完成,对调用方是透明的(所以说RPC-client中的服务连接池是很重要的基础组件)。

    【服务层>缓存层】的高可用
    【服务层】到【缓存层】的高可用,是通过缓存数据的冗余来实现的。

    缓存层的数据冗余又有几种方式:第一种是利用客户端的封装,service对cache进行双读或者双写。
    缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

    以redis为例,redis天然支持主从同步,redis官方也有sentinel哨兵机制,来做redis的存活性检测。
    自动故障转移:当redis主挂了的时候,sentinel能够探测到,会通知调用方访问新的redis,整个过程由sentinel和redis集群配合完成,对调用方是透明的。

    说完缓存的高可用,这里要多说一句,业务对缓存并不一定有“高可用”要求,更多的对缓存的使用场景,是用来“加速数据访问”:把一部分数据放到缓存里,如果缓存挂了或者缓存没有命中,是可以去后端的数据库中再取数据的。

    这类允许“cache miss”的业务场景,缓存架构的建议是:
    将kv缓存封装成服务集群,上游设置一个代理(代理可以用集群冗余的方式保证高可用),代理的后端根据缓存访问的key水平切分成若干个实例,每个实例的访问并不做高可用。
    缓存实例挂了屏蔽:当有水平切分的实例挂掉时,代理层直接返回cache miss,此时缓存挂掉对调用方也是透明的。key水平切分实例减少,不建议做re-hash,这样容易引发缓存数据的不一致。

    【服务层>数据库层】的高可用

    大部分互联网技术,数据库层都用了“主从同步,读写分离”架构,所以数据库层的高可用,又分为“读库高可用”与“写库高可用”两类。

    【服务层>数据库层“读”】的高可用
    【服务层】到【数据库读】的高可用,是通过读库的冗余来实现的。

    既然冗余了读库,一般来说就至少有2个从库,“数据库连接池”会建立与读库多个连接,每次请求会路由到这些读库。
    自动故障转移:当读库挂了的时候,db-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的读库,整个过程由连接池自动完成,对调用方是透明的(所以说DAO中的数据库连接池是很重要的基础组件)。

    【服务层>数据库层“写”】的高可用
    【服务层】到【数据库写】的高可用,是通过写库的冗余来实现的。

    以mysql为例,可以设置两个mysql双主同步,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。
    自动故障转移:当写库挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-db-master,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

    十二、总结

    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

    方法论上,高可用是通过冗余+自动故障转移来实现的。

    整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动故障转移来综合实现的,具体的:

    (1)【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

    (2)【反向代理层】到【站点层】的高可用,是通过站点层的冗余实现的,常见实践是nginx与web-server之间的存活性探测与自动故障转移

    (3)【站点层】到【服务层】的高可用,是通过服务层的冗余实现的,常见实践是通过service-connection-pool来保证自动故障转移

    (4)【服务层】到【缓存层】的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性

    (5)【服务层】到【数据库“读”】的高可用,是通过读库的冗余实现的,常见实践是通过db-connection-pool来保证自动故障转移

    (6)【服务层】到【数据库“写”】的高可用,是通过写库的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

    展开全文
  • 高可用集群详解

    千次阅读 2018-09-19 23:45:02
    高可用集群原理详解   资源粘性: 资源约束:Constraint  排列约束: (colocation)  资源是否能够运行于同一节点  score:  正值:可以在一起  负值:不能在一起  位置约束:(location), score(分数)  ...

    高可用集群原理详解

     

    资源粘性:

    资源约束:Constraint
        排列约束: (colocation)
            资源是否能够运行于同一节点
                score:
                    正值:可以在一起
                    负值:不能在一起
        位置约束:(location), score(分数)
            正值:倾向于此节点
            负值:倾向于逃离于此节点
        顺序约束: (order)
            定义资源启动或关闭时的次序
                vip, ipvs
                    ipvs-->vip

      -inf: 负无穷
      inf: 正无穷
    资源隔离:
        节点级别:STONITH
        资源级别:
            例如:FC SAN switch可以实现在存储资源级别拒绝某节点的访问


    STONITH:
        split-brain: 集群节点无法有效获取其它节点的状态信息时,产生脑裂
            后果之一:抢占共享存储
    active/active: 高可用

    高可用集群原理之共享存储

    IDE:(ATA),130M
    SATA:600M
        7200rpm
        IOPS: 100
    SCSI: 320M
    SAS:
        15000rpm
        IOPS: 200
    USB 3.0: 400M

    机械:
        随机读写
        顺序读写
    固态:
        
    IDE, SCSI: 并口
    SATA, SAS, USB: 串口

    DAS:
        Direct Attached Storage
        直接接到主板总线,BUS
            文件:块
    NAS:
        Network Attached Storage
        文件服务器:文件级别
    SAN:
        Storage Area network
        存储区域网络
            FC SAN
            IP SAN: iSCSI
    SCSI: Small Computer System Interface

    高可用集群原理之多节点集群

    crm:使本身不具备高可用的使其具有高可用,rm本身就是一个脚本。

    资源粘性:资源对某点的依赖程度,通过score定义
    资源约束:
        location: 资源对节点倾向程度
        coloation: 资源间依赖性

        order: 资源的采取动作的次序

    Heartbeat v1 自带的资源管理器
        haresources:
    Heartbeat v2 自带的资源管理器
        haresources
        crm
    Heartbeat v3: 资源管理器crm发展为独立的项目,pacemaker
    Resource Type:
        primitive: 主资源,在某一时刻是能运行在某一节点
        clone: 可以在多个节点运行
        group:把多个primitive归为组,一般只包含primitive

        master/slave: drbd只能运行在两个节点

    RA: Resource Agent
    RA Classes:
        Legacy heartbeat v1 RA
        LSB (/etc/rc.d/init.d/) Linux Standard Base
        OCF (Open Cluster Framework)
            pacemaker
            linbit (drbd)

        STONITH:管理硬件stonith设备

    隔离级别:
        节点级别
            STONTIH
        资源级别
            FC SAN Switch

    Stonith设备
    1、Power Distribution Units (PDU)
    Power Distribution Units are an essential element in managing power capacity and functionality for critical network, server and data center equipment. They can provide remote load monitoring of connected equipment and individual outlet power control for remote power recycling.
    2、Uninterruptible Power Supplies (UPS)
    A stable power supply provides emergency power to connected equipment by supplying power from a separate source in the event of utility power failure.
    3、Blade Power Control Devices
    If you are running a cluster on a set of blades, then the power control device in the blade enclosure is the only candidate for fencing. Of course, this device must be
    capable of managing single blade computers.
    4、Lights-out Devices
    Lights-out devices (IBM RSA, HP iLO, Dell DRAC) are becoming increasingly popular and may even become standard in off-the-shelf computers. However, they are inferior to UPS devices, because they share a power supply with their host (a cluster node). If a node stays without power, the device supposed to control it would be just as useless. In that case, the CRM would continue its attempts to fence the node indefinitely while all other resource operations would wait for the fencing/STONITH operation to complete.
    5、Testing Devices
    Testing devices are used exclusively for testing purposes. They are usually more gentle on the hardware. Once the cluster goes into production, they must be replaced
    with real fencing devices.

    stonithd
    stonithd is a daemon which can be accessed by local processes or over the network. It accepts the commands which correspond to fencing operations: reset, power-off, and power-on. It can also check the status of the fencing device.

    The stonithd daemon runs on every node in the CRM HA cluster. The stonithd instance running on the DC node receives a fencing request from the CRM. It is up to this and other stonithd programs to carry out the desired fencing operation.

    STONITH Plug-ins

    For every supported fencing device there is a STONITH plug-in which is capable of controlling said device. A STONITH plug-in is the interface to the fencing device.

    On each node, all STONITH plug-ins reside in /usr/lib/stonith/plugins (or in /usr/lib64/stonith/plugins for 64-bit architectures). All STONITH plug-ins look the same to stonithd, but are quite different on the other side reflecting the nature of the fencing device.

    Some plug-ins support more than one device. A typical example is ipmilan (or external/ipmi) which implements the IPMI protocol and can control any device which supports this protocol.

     

    Heartbeat:udp:694

    高可用集群之heartbeat安装配置

    两个节点:172.16.100.6 172.16.100.7

    vip:172.16.100.1

    1.两个节点互相通信

    2.配置主机名:hostname node1.magedu.com   uname -a

    永久生效:vim /etc/sysconfig/network  HOSTNAME=node1.magedu.com

    3.ssh双机互信:

    4.配置主机名解析

    vim /etc/hosts

    172.16.100.6 node1.magedu.com node1

    172.16.100.7 node2.magedu.com node2

    关闭iptables

    5.时间同步

    ntpdate 172.16.0.1

    service ntpd stop

    chkconfig ntpd off

    为了保证以后尽可能同步:crontab -e

    */5 * * * * /sbin/ntpdate 172.16.0.1 &> /dev/null

    scp /var/spool/cron/root /node2:/var/spool/cron/

     

    epel

    heartbeat - Heartbeat subsystem for High-Availability Linux
    heartbeat-devel - Heartbeat development package
    heartbeat-gui - Provides a gui interface to manage heartbeat clusters
    heartbeat-ldirectord - Monitor daemon for maintaining high availability resources, 为ipvs高可用提供规则自动生成及后端realserver健康状态检查的组件;
    heartbeat-pils - Provides a general plugin and interface loading library
    heartbeat-stonith - Provides an interface to Shoot The Other Node In The Head
    http://dl.fedoraproject.org/pub/epel/5/i386/repoview/letter_h.group.html

    三个配置文件:
    1、密钥文件,600, authkeys
    2、heartbeat服务的配置配置ha.cf
    3、资源管理配置文件

        haresources

    vim authkeys

    vim ha.cf

    logfacility local0

    keepalive 1

    node node1.magedu.com

    node node2.magedu.com

    ping 172.16.0.1

    vim haresources 保证httpd服务没启动,并且chkconfig httpd off

    node1.magedu.com IPaddr::162.16.100.1/16/eth0 httpd

    访问:172.16.0.1

    模拟172.16.100.6故障,访问172.16.0.1出现node2.magedu.com

    mkdir /web/htdocs -pv

    vim /etc/exports

    /web/htdocs 172.16.0.0/16(ro)

    service nfs restart

    showmount -e 172.16.100.10输出结果正常

    关闭服务:mount 172.16.100.10:/web/htdocs /mnt

    ls /mnt index.html

    umount /mnt

    编辑haresources:node1.magedu.com IPaddr::172.16.100.1/16/eth0 Filesystem::172.16.100.10:/web/htdocs::/var/www/html::nfs httpd

    scp haresources node2:/etc/ha.d/

    tail -f /var/log/messages

    高可用集群之heartbeat基于crm进行资源管理

    RA classes:
        OCF
            pacemaker
            linbit
        LSB
        Legacy Heartbeat V1
        STONITH
    RA: Resource Agent
        代为管理资源
    LRM: Local Resource Manager
    DC:TE,PE
    CRM: Cluster Resource Manager
        haresource (heartbeat v1)
        crm, haresource (heartbeat v2)
        pacemaker (heartbeat v3)
        rgmanager (RHCS)
    为那些非ha-aware的应用程序提供调用的基础平台;

    crmd:管理API     GUI,CLI

    web(三个资源):vip,httpd,filesystem

    Resource Type:

        primitive(native)

        group

        clone

           STONISH

           Cluster Filesystem dlm:Distributed Lock Manager

        master/slave:drbd

    资源粘性:资源是否倾向于留在当前节点
            正数:乐意
            负数:离开

    资源约束:

      location:位置约束 colocation:排列约束 order:顺序约束

    heartbeat:
        authkeys
        ha.cf
            node
            bcast、mcast、ucast

        haresource

    HA:
        1、时间同步;2、SSH双机互信;3、主机名称要与uname -n,并通过/etc/hosts解析;
    CIB: Cluster Information Base
        xml格式
        crm --> pacemaker

    crmd   respawn|on

    mcast eth0 255.0.100.19 694 1 0

    原理简介
      组播报文的目的地址使用D类IP地址, 范围是从224.0.0.0到239.255.255.255。D类地址不能出现在IP报文的源IP地址字段。单播数据传输过程中,一个数据包传输的路径是从源地址路由到目的地址,利用“逐跳”(hop-by-hop)的原理在IP网络中传输。然而在ip组播环中,数据包的目的地址不是一个,而是一组,形成组地址。所有的信息接收者都加入到一个组内,并且一旦加入之后,流向组地址的数据立即开始向接收者传输,组中的所有成员都能接收到数据包。组播组中的成员是动态的,主机可以在任何时刻加入和离开组播组。
    组播组分类
      组播组可以是永久的也可以是临时的。组播组地址中,有一部分由官方分配的,称为永久组播组。永久组播组保持不变的是它的ip地址,组中的成员构成可以发生变化。永久组播组中成员的数量都可以是任意的,甚至可以为零。那些没有保留下来供永久组播组使用的ip组播地址,可以被临时组播组利用。
      224.0.0.0~224.0.0.255为预留的组播地址(永久组地址),地址224.0.0.0保留不做分配,其它地址供路由协议使用;
      224.0.1.0~224.0.1.255是公用组播地址,可以用于Internet;
      224.0.2.0~238.255.255.255为用户可用的组播地址(临时组地址),全网范围内有效;
      239.0.0.0~239.255.255.255为本地管理组播地址,仅在特定的本地范围内有效。
    常用预留组播地址
      列表如下:
      224.0.0.0 基准地址(保留)
      224.0.0.1 所有主机的地址 (包括所有路由器地址)
      224.0.0.2 所有组播路由器的地址
      224.0.0.3 不分配
      224.0.0.4 dvmrp 路由器
      224.0.0.5 ospf 路由器
      224.0.0.6 ospf dr
      224.0.0.7 st 路由器
      224.0.0.8 st 主机
      224.0.0.9 rip-2 路由器
      224.0.0.10 Eigrp 路由器
      224.0.0.11 活动代理
      224.0.0.12 dhcp 服务器/中继代理
      224.0.0.13 所有pim 路由器
      224.0.0.14 rsvp 封装
      224.0.0.15 所有cbt 路由器
      224.0.0.16 指定sbm
      224.0.0.17 所有sbms
      224.0.0.18 vrrp
      以太网传输单播ip报文的时候,目的mac地址使用的是接收者的mac地址。但是在传输组播报文时,传输目的不再是一个具体的接收者,而是一个成员不确定的组,所以使用的是组播mac地址。组播mac地址是和组播ip地址对应的。iana(internet assigned number authority)规定,组播mac地址的高24bit为0x01005e,mac 地址的低23bit为组播ip地址的低23bit。
      由于ip组播地址的后28位中只有23位被映射到mac地址,这样就会有32个ip组播地址映射到同一mac地址上。

    高可用集群之基于heartbeat和nfs的高可用mysql


     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 基于VIP的keepalived高可用集群架构

    千次阅读 2019-03-19 13:19:22
    简介 keepalived作用 检测服务器的状态,如果有一台web服务器宕机,或工作出现故障,keepalived将检测到,并将有故障的服务器从系统中剔除,同时使用...1.配置文件简单:可通过简单配置实现高可用功能。 2.稳定性...
  • Linux集群主要分成三大类:高可用集群(High Availability Cluster)、负载均衡集群(Load Balance Cluster)、科学计算集群(High Performance Computing Cluster)。 其中高可用集群具有保障应用程序持续提供服务的能力...
  • linux高可用集群(HA)原理详解

    万次阅读 2018-05-02 10:39:32
    高可用集群一、什么是高可用集群 高可用集群就是当某一个节点或服务器发生故障时,另一个节点能够自动且立即向外提供服务,即将有故障节点上的资源转移到另一个节点上去,这样另一个节点有了资源既可以向外提供服务...
  • 最近研究了下公司的hadoop集群并模仿搭建了一个在本地测试使用的hadoop集群。本文介绍下详细的搭建过程以及各种常见问题的处理解决。 1 , 前期准备 1.0 , 准备Linux环境。 安装vmware linux虚拟机,因为Centos 7...
  • 高可用Kubernetes集群原理介绍

    万次阅读 2016-08-19 08:28:22
    Kubernetes作为容器应用的管理中心,对集群内部所有容器的生命周期进行管理,结合自身的健康检查及错误恢复机制,实现了集群内部应用层的高可用性。 Kubernetes服务本身的稳定运行对集群管理至关重要,影响服务稳定...
  • 集群(Cluster)集群的概念是和单台服务器相对应的,简单来说集群就是部署多台服务器协同完成一项工作。集群可以分为:1,负载均衡(Load Balance)集群:负责均衡服务器根据负载均衡算法(轮询,随机,哈希,权重等)...
  • Zookeeper 集群为什么是高可用的?

    万次阅读 2017-03-26 16:45:36
    我们通常部署zookeeper集群来实现高可用性,那么zookeeper是如何实现高可用性的呢?集群组成要搭建一个高可用的 ZooKeeper 集群,我们首先需要确定好集群的规模。关于 ZooKeeper 集群的服务器组成,相信很多对 ...
  • RabbitMQ如何保证高可用

    千次阅读 2019-04-07 19:13:14
    rabbitMQ对于高可用是基于主从的方式进行实现. 其有三种工作模式: 单机模式、普通集群模式、镜像集群模式 单机模式: 生产模式不可能使用. 普通集群模式: 即在多个服务器上部署多个MQ实例, 每台机器一个实例. ...
  • 有A,B,C三个节点的集群,在没有复制模型的情况下,如果节点B失败了,那么整个集群就会以为缺少5501-11000这个范围的槽而不可用
  • 架构综合-集群、分布式、负载均衡区别与联系(转)

    万次阅读 多人点赞 2019-03-04 00:04:47
    1、Linux集群主要分成三大类( 高可用集群, 负载均衡集群,科学计算集群) 集群是一个统称,他分为好几种,如性能科学群集、负载均衡群集、可用性群集等。科学群集 、性能集群(High performance cluster,HPC...
  • redis-cluster一台机器宕机后集群可用部署现状: 测试环境部署4台机器,每台机器上启动5个redis实例,总共20个实例;创建集群,10个主,10个从;问题呈现: 1.测试过程中,kill掉一台机器,集群正常恢复; 2....
  • 集群存储高可用方法

    万次阅读 2013-05-03 22:18:34
    性能计算、医学影像、石油和天然气勘探、数字媒体和社会化WEB等大量数据密集型应用导致数据的井喷,不断对存储方法提出新的严峻挑战。集群存储是一种横向扩展(Scale-out)存储架构,具有容量和性能线性扩展的优势...
  • 目前,为了使web能适应大规模的访问,需要实现应用的集群部署. 而实现集群部署首先要解决session的统一,即需要实现session的共享机制。  目前,在集群系统下实现session统一的有如下几种方案: (1) 应用服务器...
  •  集群(cluster)技术是一种较新的技术,通过集群技术,可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较的收益,其任务调度则是集群系统中的核心技术。集群是一组相互独立的、通过高速网络互联的...
  • 教程中涵盖的技术点包括 Dubbo分布式服务、ZooKeeper注册中心、Redis3.0分布式缓存集群、MySQL读写分离集群、FastDFS_v5.05分布式文件系统集群、ActiveMQ5.11群集、Keepalived + Nginx实现的高可用Web负载均衡集群、...
  • 什么是集群(cluster)

    万次阅读 2008-02-18 15:43:00
    1、集群 1.1 什么是集群 简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点(node)。一个理想的集群是,用户从来不会意识到集群系统底层的节点...
1 2 3 4 5 ... 20
收藏数 284,325
精华内容 113,730
关键字:

高可用集群