马哥 38_01 _Linux集群系列之七——高可用集群原理详解 有大用

在基于SSL,需要用到持久连接:

PPC:将来自于同一一个客户端对同一个集群服务的请求，始终定向至此前选定的RS:持久端口连接

PCC:将来白于同一个客户端对所有端口的请求，始终定向至此前选定的RS:持久客户端连接

把所有端口统统定义为集群服务，一律向RS转发:

PNMPP:持久防火墙标记连接

80: RS1

23:同个RS

防火墙标记:

PREROUTING

80: 10

23: 10

10

80, 443

http:

https:

RS: lamp, discuz

LVS基本原理、LVS类型、LVS调度算法、NAT模型的实现、DR模型的实现、VIP和RIP不在同一网段是如何实现.

LVS持久连接:

        持久连接模板,一段内存空间    客户端ip,rip,剩余时间三样,

                -p 600        (倒计时600秒)  600秒到了,但还正在连接当中,自动延长两分钟(120秒),,再正在连接,120秒到了,再自动延长两分钟(120秒).....

        PPC

        PCC

        PNMPP

ipvs:

        -t:TCP

        -u:UDP

        -f:firewall mark

                port affinity:端口姻亲

                #iptables -t mangle -A PREROUTING -d $VIP -p tcp --dport $ClusterPORT -i $interface_card  -j MARK --set-mark 10

Ｐ节点(Passive Standby)发现A节点(Active Primary)挂了,通过ARP向外通告

active/passive

primary/standby

高可用集群的资源: A的vip, ipvs的规则,等等需要在自己挂的时候提供给其它P的东西,叫做资源(Resource)

HA Resource (High Available Resource) 高可用 主服务器(活动的)资源:

        IP,Service,STONITH(一种硬件设备)

        通过资源转移来完成高可用的

        FailOver:故障转移, 资源从主节点移移到备用节点

        FailBack:发现好了,,,,又从备用节点转移回到主节点了

        转移时与客户端的各种连接会断掉的

        A节点故障后恢复,看资源粘性(资源更倾向于在哪个节点上)

            A节点性能可能更好,P节点性能可能差点,所以A节点资源粘性更强

        粘性属于高可用的功能

        A,P两节点,不仅A要提供心跳功能,相互之间还要有更进一点的资源管理的功能,事务协调的功能,事务协调需要传递信息的,比如是否心跳,,资源比较,是否需要转移服务,转移服务的过程

       A,P两节点通信,要通过协议，比如ip什么的，对效率比可用性要求更高,一般要UDP的

        A(资源运行在谁上,谁就是A),另一个(或多个?)就是P

高可用服务提供的能力

     1)集群事务信息层 message layer:两个节点之间专门用于传递集群事务的层次,执行集群事务的功能;双方要实时的监听在某个套接字上(UDP的某个端口上);集群事务信息层为了功能简化,仅用来传递信息(心跳集群事务信息等),不负责后期信息的计算和比较

     2)集群资源管理器 CRM (cluster resource manager):后期信息的计算和比较,统计收集集群上每一个资源的状态,并且根据资源状态,资源服务本身来计算出来资源服务应该运行在哪个集群节点上;;两个节点上都运行CRM;;;;DC(Designated coordinator 推选的事务协调员);;;可能DC所在节点故障,要重新推选DC的,,,DC负责计算和比较?     DC是CRM的一个子功能,DC提供两个组件:

            PE(policy engine 策略引擎)负责计算并得出结果的,PE是CRM的一个子功能,

            TE(transaction engine 事务引擎)如果其它节点比当前节点粘性高,它会负责指挥 down掉当前节点vip,清空ipvs,它会负责指挥把粘性高的节点的vip配置上,ipvsadm规则生效

            LRM(local resource manager 本地资源管理器 )是CRM的组成部分,接受由TE传递过来的指挥,在某一个节点上采取相应的动作的( 粘性低的节点down掉当前节点vip,清空ipvs  )(粘性高的节点的vip配置上,ipvsadm规则生效) 

我们监控不但是监控节点,还要监控资源;还要监控ipvs规则是否正常;;

如果 看到 ipvs down了,再测一次,再再测一次,共测三次,还down的话,就转移

谁来负责检测,检测的结果谁来负责传递信息,都与 Messaging Layer 和 CRM有关

LSB的脚本,Linux Standard Base,.符合 linux 标准库的脚本,含有 start|stop|restart|status

RA: resource Agent 资源代理, 提供linux集群资源管理的,每一个资源都有一个资源管理的脚本

高可用协会所定义的标准,应该具有如下图图一这样的组件,各个组件是可以独立的

图一

资源组: RG (Resource Group)      例如 vip,ipvs 归为一组

HA: (High Available)

    资源粘性:   定义资源与节点之间的倾向性

    资源约束:   约束就是Constraint,

            就是定义资源间的关系,资源间的倾向性        

                    排列约束:collation constraint,

                            资源是否能够运行于同一节点

                                   score:

                                       正值:可以在一起

                                       负值:不能在一起

                    位置约束: location constraint, 一个整数score 

                        正值:倾向于此节点

                        负值:倾向于逃离此节点

                    顺序约束:(order constraint)

                            定义资源启动或关闭时的次序;;;因为资源间有依赖关系  强制谁先谁后,建议谁先谁后

                                    vip,ipvs

                                        启动:假设 ipvs->vip

                                        关闭: 相反 vip->ipvs

score: -inf: 负无穷  ( infinite 无限的;极大的;无穷大的 )

            inf: 正无穷

资源隔离:

            节点级别: STONITH      (shoot the other node in the head)爆头,,例 A节点正常运行,后来A节点故障,P节点抢资源,怕A节点没死透,抢资源,所以P切断A节点的电源,叫爆头

            资源级别: 有很多

        比如FC SAN,光交换机内置功能,只是在某个存储上隔离一个节点的访问能力, switch有这种功能 ( FC SAN switch可以实现在存储资源级别拒绝某节点的访问)

STONITH: (shoot the other node in the head)爆头,,例 A节点正常运行,后来A节点故障,P节点抢资源,怕A节点没死透,抢资源,所以P切断A节点的电源,叫爆头

HA MySQL  当然每个主机需要两个ip,一个ip是mysql间相互通信,另一个ip是提供MySQL服务的

    vip:FIP (Float IP)流动的IP,在各节点之间转移的

    mysql service 

    Filesystem:挂载数据的

        有排列约束

        顺序约束 Filesystem->mysql service->vip(与Filesystem,mysql service,没有顺序关系,无所谓? 先有vip,再有服务,因为服务要监听在某个套接字上;;;;但是有些服务是监听在所有ip地址上)

        位置约束,看两个mysql服务器谁性能好

split-brain:脑裂, 左右无法协调了,,,,(为什么左mysql 与 右mysql 可能同时在线,但是右mysql判断左mysql问题,抢左mysql资源的原因) (原因很多,比如右mysql添加了iptables ,不小心屏蔽了左mysql的心跳信息)

split-brain:脑裂的原因:

        双方无法传递心跳信息 (集群节点无法有效获取其它节点的状态信息)

split-brain:脑裂的后果之一:抢占共享存储

                  脑裂的后果之一:抢占VIP(FIP) ,你抢,我也抢    

避免脑裂的方案:资源隔离

高可用集群:主(使用中的 active)备(备用中的 passive)模型 主/备

如何 active/active: 高可用  (主/主两种不同的服务)

如下图,左边MySQL为主,右边Http为主

我们定义资源粘性,MySQL倾向于运行在左节点,HTTP倾向于运行在右节点

现在高可用完全可以VIP运行在两个节点上

前面有促裁机制,可能会轮流将用户请求转发至不同的节点,右节点故障,服务也不用转移,直接全部请求

重定向至左节点,,这才是真正意义上的 主/主模型

文件系统如何保证两个mysql不冲突?

独特的文件系统,一个节点写的时候,其它节点能看到(锁),这就叫做集群文件系统 Cluster Filesystem

比如 GFS  OCFS2 等

集群文件系统 只能是DAS或SAN 文件系统,不能是NAS文件系统