Linux HA Cluster-HeartBeat

Linux HA Cluster HeartBeat
    HA Cluster可以解决单点故障问题，增加应用服务的可用性；
    故障场景：
        设计缺陷(bug)：软件或服务器硬件设计或者制造时固有的问题；
        使用过久，硬件损耗；
        认为故障：管理人员的误操作，或者遭受攻击；
        ……
    可用性公式：可用性=平均无故障时间/(平均无故障时间+平均修复时间)
        通常我们使用百分比来描述某服务的可用性：90%，95%，99%，99.9%，99.99%，99.999%；
    heartbeat，心跳：集群中的各个主机间检测彼此是否处于理想状态，即用来探测对方是否在线，如果不在线自己就会取而代之；
    HA中的各个节点无法探测彼此的心跳信息时，就会误以为对方故障掉线，从而自己取而代之，这种状态我们称之为partitioned cluster（split brain）；
    如果集群中的主机为单数（大于等于3个）时，如果发生脑裂一般会采用少数服从多数的机制（投票机制：每个主机有一票），将资源分给分裂后子集群中主机个数多的一方，而另一方就会被down掉；如果是双节点的集群可以通过引入仲裁机制来决定分裂后将资源分配给哪一方，比如当heartbeat信息无法互通时，可以让两台主机ping网关，谁可以ping通，谁就多一票；
    当一台主机宕机，其他主机顶上之后，如果之前的主机修好上线以后是否会将资源重新转回去呢？根据情况的不同，处理方法不同，如果两台主机性能一样的话就无需转移资源，因为资源的切换会导致延迟和抖动，造成连接中断；但是有时候我们因为成本问题，一般都是使用一台性能一般的主机来当做备用主机，它的性能是不如主主机的，所以我们要进行资源转移；当原来活动主机发生故障，而导致资源转移至备用主机的过程我们称之为：failover；而当原来活动主机上线以后，要将资源要回的过程我们称之为failback；
    上面说的都是主机硬件的可用性，其实我们在生产环境中发生的大多数问题都是出现在各种服务上的，比如当web服务出现问题了，我们通过这种ping网关的机制可以检测到web故障吗？显然是不能的，所以我们就需要一种能检测应用程序的状态信心的机制来解决这个问题；（各种服务、IP地址、文件系统等在Cluster中都可称之为资源）
其实Cluster中的各个主机之间探测心跳信息可以理解成在各个主机上都运行一个程序，这些程序彼此之间可以互相通信（互相通过向对方的地址和端口来发送心跳信息），完成各主机状态信息的检测；我们可以将这些程序统一起来看做一个公共层（集群事务信息层，message layer），然后我们就可以通过这个层来传递信息，从而实现当服务故障时进行资源的转移；但是这只是提供了各个主机中间传递心跳信息的方法而已，并没有说明当服务出现故障以后怎么转移资源的具体过程，根据什么信息（比如cpu的性能，内存的大小等）将资源转移到哪台合适的主机上等等的细节过程；所以必须要有一种机制来判定资源在最开始时和活动节点故障后应该运行在那个节点上，这种机制需要依赖集群事物信息层来收集各种信息，但是各种应用服务程序本身并不支持这个集群事务信息层（也就是说设计的时候没有调用这个层提供的API接口），也就是无法运行在集群中，实现高可用的，比如httpd；为了解决这个问题，有人就在这个集群事务信息层之上又提供了一个层次，这个层可以帮助各种服务调用集群事务信息层提供的API接口，实现发送心跳信息的功能，从而使之支持高可用功能，这个层我们称之为集群资源管理器（CRM）；这个CRM可以根据管理员指定的配置将服务运行在某一指定节点上，它还会通过定时发送探测信息监控这个资源（服务）是否可用，如果经过指定次数的探测以后没有得到回应，则将资源（ip、文件系统、服务等）转移至其他节点；从而使这些不具有高可用功能的服务，也能够在高可用集群上运行了；
集群中主机之间可以通过单播、组播、广播来传递心跳信息，使用组播或者广播时主机可以主动发送通告信息，来通知其他主机自己还“活着”；
服务资源类型：
    HA-aware：资源自身可直接调用HA集群底层的HA功能；
    none-HA-aware：必须借助于CRM来完成在HA集群上实现HA功能；
资源的约束关系：
    location：位置约束，定义资源更倾向于运行在哪个节点上；使用数值来表示这个倾向性：-∞（无论如何也不会被选择），+∞（只要可运行就选择）
    colocation：排列约束，定义多个资源运行于同一节点上的倾向性；依然是-∞（不能在一起的，互相排斥），+∞（必须在一起的）
        group：分组，将过个资源定义在一个组中，然后将这个组约束在某个节点上；先定义组后添加各个资源；
    order：顺序约束，定义资源在同一个节点上的启动顺序；
资源类型：
    primitive：只能运行于集群内的某单个节点上；（也称作native资源）
    group：类似一种容器，组中包含一个或多个资源，可以通过调度这个组来统一管理这些资源；
    clone：这种资源在同一集群中的多个节点上都会运行一份；
    master/slave：主从资源，在同一集群内部的两个节点上运行两份资源，一个为主，一个为辅；
因为不同的资源启动的方式不同，我们配置的方式可能不同，比如：ip地址是通过配置命令ifconfig或者ip配置到网卡上的，各种服务程序可以直接使用服务器本身提供的二进制程序启动或者使用/etc/init.d/中的服务脚本来启动，文件系统通过mount和umount来挂卸载等；所以我们就又面临一个麻烦了，就是使用CRM无法对这些不同资源的不同使用方法来进行统一的配置，为了避免这种麻烦的配置，在CRM上面又提供了一个层次，叫做本地资源管理器（LRM）；本地资源管理器依然不能直接决定一个资源该如何启动和关闭，而是借助于资源代理（RA）的协助来实现；资源代理就是帮助启动、关闭、监控资源的脚本，这些脚本有的是安装的集群软件自带的，它就可以实现自动配置以及删除ip地址操作；可以将RA看做是运行在LRM上的又一个层次； 
一般当节点故障以后，运行在这个节点上的资源就要做fireover，并且确定其是否真的故障了，如果主活动节点没“死透”，替代的别用节点还要去“补一刀”；这就是下面的资源隔离机制；
资源隔离：
    级别：
        节点级别的隔离：STONITH，Shooting The Other Node In The Head
            power switch ：可以实现直接将节点断电来down掉这个节点；
        资源级别的隔离：fencing
            FC SAN switch ：切断某种资源正常使用所必须的行为，比如通过将交换机上连接web服务器的接口阻塞，从而达到阻止web服务访问文件系统的行为；
解决方案：各层的实现方法
    Message layer：实现传递心跳信息，完成主机状态信息的检测；
        heartbeat：v1，v2，v3
        corosync（主流）
        cman（Redhat，RHCS）
        keepalived（工作方式完全不同于上述三种）
    CRM：负载在哪个节点上激活资源
        heartbeat v1 ：haresources
            通过同名配置文件来实现功能；
        heartbeat v2 ：crm
            在各个节点上运行一个crmd进程，通过命令行工具crmsh，或者GUI工具hb_gui来配置各种资源关系；
        heartbeat v3 ：pacemaker
            可以以独立服务运行，也可以以插件形式运行（corosync）；通过命令行工具crmsh，pcs或者GUI工具hawk（web页面的），LCMC，pacemaker-mgmt；
        cman ：rgmanager
            通过命令行工具clustat，cman_tool或者GUI工具Conga（luci+ricci）
    LRM：一般CRM都会附带LRM，类似CRM的一个子组件；负责激活RA脚本
    组合方式：
        heartbeat v1 ：全栈的，v1版本本身就可以完成所有功能；
        heartbeat v2 ：也可以独立完成所有功能；
        heartbeat v3 + pacemaker ：因为pacemaker后来被独立出来了，所以来另行安装；
        corosync + pacemaker
        cman + rgmanager（RHCS）
        cman + pacemaker
    RA：实现资源的启动，关闭，状态查看等等
        heartbeat legacy：heartbeat传统类型的RA，通常位于/etc/ha.d/haresources.d/目录下，根据安装方式不同可能位于其他目录中；
        LSB：Linux Stardard Base，位于/etc/rc.d/init.d/目录中的服务脚本；这些脚本一般都有四个参数：{start|status|stop|restart}；→Centos6
        OCF：Open Cluster Framework，开放集群框架
            子类别：provider
        STONITH ：专用于实现调用STONITH设备功能的资源；通常为clone类型；
HeartBeat心跳信息传递机制：
可以通过以太网网线或者串口；最好是使用专门的一条网线来实现心跳信息的传递；不太推荐串口；只有两个节点时可以使用UDP Unicast来发送心跳信息，如果是多节点的话建议使用UDP Multicast来发送心跳信息，不建议使用广播（UDP Broadcast）；
        组播地址：用于标识一个IP组播域；IANA将D类地址空间分配给组播使用，其范围时224.0.0.0-239.255.255.255；
        永久组播地址：224.0.0.0-224.0.0.255，用来给某种协议或程序使用
        临时组播地址：224.0.1.0-238.255.255.255，可以自定义使用的，构建高可用集群时就是使用这一块的地址；
        本地组播地址：239.0.0.0-239.255.255.255，只在特定场景下有用
HA案例：web services
    资源：ip，httpd，filesystem
    约束关系：使用group资源，或者通过排列约束让资源运行在同一节点；
              顺序约束，有次序的启动资源，ip-filesystem-httpd
    使用heartbeat v2 + haresources搭配 → heartbeat v1
    配置HA集群的前提：
        1.节点间时间必须同步，使用ntp协议同步;
            crontab -e
        */2 * * * * /usr/sbin/ntpdate ntp.api.bz &> /dev/null
    实验环境中可以这么操作，如果是生产环境中建议使用ntp服务同步时间，因为ntpdate同步时间时是跳跃性的，比如你的时间比服务器上的时间慢了五分钟，那么他会直接将你的时间增加五分钟，这五分钟的间隔是瞬间设置上的，这样会给你的服务器造成五分钟的空档期，服务器不会有任何关于这五分钟的记录；如果是使用ntp服务同步的话，如果你慢了，它会将你的时间设置的走快一点，慢慢赶上，如果你快了，它会将你的时间走慢一点，等待它赶上；
        2.节点需要通过主机名互相通信，必须能解析主机名至IP地址；
            a.建议名称解析使用hosts文件来实现；如果使用DNS服务的话，DNS就是一个单点，还会给整体架构添加维护上的不便；任何时候依赖的外部资源越少越好；
                vim /etc/hosts
                    192.168.80.133 clone6
                    192.168.80.131 clone5
            b.通信中使用的名字与节点名字必须保持一致，也就是hostname命令输出的结果要和hosts文件中的配置相同；
            c.如果是两节点的集群，要考虑引入仲裁设备；
            d.建议各节点之间的root用户能够基于秘钥认证完成自动登录；
                ssh-keygen –t rsa
                cd .ssh/
                touch authorized_keys
                chmod 600 authorized_keys
                ssh-copy-id –i .ssh/id_rsa.pub root@IP_ADDR
        Note：定义成为集群服务中的资源，一定不能开机自动启动；因为他们将由crm管理；
    安装程序包：Centos6
        依赖关系：
            yum install net-snmp-libs.x86_64  libnet.x86_64 PyXML.x86_64
        安装程序包：
            rpm -ivh heartbeat-2.1.4-12.el6.x86_64.rpm heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm
    配置文件：
        /etc/ha.d/目录下
            ha.cf：主配置文件，定义各节点上的heartbeat HA集群的基本属性；
            authkeys：集群内各节点间彼此传递消息时使用的加密算法及秘钥；
            haresources：heartbeat v1版本的资源管理器（CRM）配置接口；v1专用；
        Note：默认安装以后上面的三个文件在/etc/ha.d/目录中是没有的，可以将/usr/share/doc/heartbeat-2.1.4/中的案例复制到本目录中，对其进行配置；
        cp /usr/share/doc/heartbeat-2.1.4/{haresources,ha.cf,authkeys} /etc/ha.d/
        cd /etc/ha.d/
        chmod 600 authkeys
        vim authkeys
            #auth 2
            #2 sha1 HI!     
            将2和auth之前的“#”去掉；其中2表示序号，sha1表示加密算法，HI!为秘钥，可以更换，建议换一个随机得、复杂一点的（openssl rand -base64 16）；auth 2 表示启用2号加密方式对传递的消息加密，想使用哪种加密算法auth后面就填写其前面的序号；
        vim ha.cf
            logfacility     local0
            mcast eth2 225.12.12.12 694 1 0
                如果你的网卡不支持组播，可以通过ip link set eth2 multicast on启用；
            node    clone5
            node    clone6       添加节点
            ping 192.168.80.130    仲裁机制
        vim /etc/rsyslog.conf
            local0.*                /var/log/heartbeat.log
        service rsyslog restart
        vim haresources
            clone5  192.168.80.12/24/eth2/192.168.80.255 httpd   设置主节点，以及集群所使用的IP地址等资源；其中IP地址为fip（流动IP），网卡根据主机的不同设置不同，主节点是不变的；
        将这个节点的配置文件复制到其他节点一份，然后根据情况做细微修改；
        scp -p ha.cf authkeys haresources clone5:/etc/ha.d/
        在各个节点上启动资源服务和heartbeat：
        service httpd start
        service httpd stop      测试httpd是否可用
        service heartbeat restart ; ssh clone6 'service heartbeat restart'     
        可以通过停止heartbeat来查看资源是否转移至备用节点；
    HA Cluster的工作模型：
        A/P：两节点集群，active，passive；工作于主备模式；
            HA Service通常只有一个，HA Resource可能会有多个；
        A/A：两节点集群，active/active，工作于双主模式；
            每个节点运行不同的服务，当其中一个服务出错时，可以转移至其他节点继续工作；也可以是运行相同的服务，使用DNS做负载均衡，当其中一个节点上的服务出错时，将其IP地址转移到另一台运行相同服务的节点上继续工作；
        N/M：N个节点，M个服务，通常N>M；
            这种模型适可以多个节点运行不同服务，留一个节点作为备用，当有节点出现故障时，就将其转移至备用节点上；
        Note资源转移方式：当一个节点发生故障时，我们以上做的实验都是使其转移到另一个节点上，但是我们还要考虑一种情况：也就是如果执行资源转移，那么运行在故障节点内存中的数据就会丢失，会给我们在成损失的；所以我们通过以下几种方式提供了一些是否转移的选择：
            stopped：使故障节点停止运行，暂时不做转移；如果有需要再做转移
            ignore：忽略故障，继续运行；可能会造成资源征用
            freeze：冻结，此前被分配到这个节点上的用户还可以继续访问，直到其推出为止，但是不会接收新请求进来；
            suicide：自杀，一旦故障就直接退出；
    资源运行的倾向性：
        rgmanager：
            failover domain：为故障资源的转移指定范围，即故障节点上的资源只能转移到指定范围内的节点上；
            node priority：节点优先级；
        pacemaker：
            资源粘性：运行于当前节点的倾向性；
            资源约束：上面已经提过了；
    DC：Designated Coordinator
        由启动集群后选举产生，可以控制节点故障后是否转移，怎么转移，转移至哪个节点上，集群分裂后由哪个子集群继续提供服务等等的操作；
    使用heartbeat v2（crm）
        crm默认在每个节点上运行一个守护进程（mgmtd，监听在5560端口上），通过命令行工具还进行设置，并通过DC（首先会通过投票系统来选出DC）来向各节点进行同步设置；
        信息传递过程：假设本节点被选为DC，DC通过crm向message layer通知信息，然后让本节点的message layer向其他节点的message layer发送信息，其收到信息后会通过message mayer通过crm，在由crm将消息传递给lrm，使其调用ra完成资源的启用；
        配置：每个节点都要配置
            在配置文件中添加以下一行就可以启用crm
            vim ha.cf
                crm on
            Note：启用crm后需要禁用v1版的haresources资源管理器；
            service heartbeat start
        工具：
            rpm -ivh heartbeat-gui-2.1.4-12.el6.x86_64.rpm
            可以通过crm_mon查看节点状态
            由于其他命令行工具使用比较麻烦所以建议使用hb_gui这个GUI图形工具配置集群信息；
            使用xshell（需要配套安装xmanager）和Centos6自己的图形界面都可以打开这个图形界面，但是其他的貌似就不可以了；
            使用hb_gui需要给用户（hacluster）设置一个密码：
                echo “admin” | passwd --stdin hacluster
            hb_gui &
                键入刚才设置的密码就可以开始设置啦！
 

1.    点击上面的那个“+”开始添加资源
可以选择native（基本资源），group（组资源），location（位置），order（顺序），colocation（排序）
 

2.Resource ID为资源名称，Belong to group 指定所属组，Type指定资源种类（ip，各种服务（比如httpd）；通过Name选择其对应的RA，Class/Provider建议使用lsb），Parameter指定资源的属性（比如如果资源为IP地址，就会要求输入IP地址，可以手动指定网卡设备，子网掩码等）；
 

3.点击添加以后就会回到之前的主页面，在Resources选项中会出现刚才设置的资源名称；默认资源是未启动的，可以点击右键然后选择启动，并且默认运行在DC上；
    使用ifconfig命令在DC上就可以看见一个地址资源已经设置完毕了；
4.循环以上过程，添加需要的资源种类；比如集群的是web服务就需要添加IP、FileSystem、httpd；
5.接下来可以通过group或者各种约束条件来限制资源运行在哪个节点上，哪些资源要在同一个节点上，以及资源的启动顺序为何；如果使用group需要先定义组后添加资源；
    操作：在Constraints中选择各种约束类型，对其进行详细设置；
 

6.ID指定约束类型的名字，From指定之前设置的资源的名字，To也是之前设置的资源的名字，Score指定资源在同一节点的的倾向性；From为跟随者，To为被跟随者；Symmetrical指定集群的类型是够为对称结构（默认不运行在任何节点上，只能运行在指定节点），默认为非对称（可以运行在任何节点）；←Colocation
    Note：Order（启动顺序）以及Location（启动在哪个节点上）设置与Colocation类似；

   

    注：根据马哥视频做的学习笔记，如有错误，欢迎指正；侵删；

转载于:https://www.cnblogs.com/guowei-Linux/p/11072866.html