Linux HA Cluster-HeartBeat

时间 2019-11-12

原文原文链接

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 &
               键入刚才设置的密码就能够开始设置啦！
node

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

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中选择各类约束类型，对其进行详细设置；
shell

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

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