corosync+pacemaker高可用集群

Posted 2020-12-08 douhua7458

高可用集群，是指以减少服务中断（如因服务器宕机等引起的服务中断）时间为目的的服务器集群技术。简单的说，集群就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点。

高可用集群的出现是为了减少由计算机硬件和软件易错性所带来的损失。它通过保护用户的业务程序对外不间断提供的服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。

高可用集群框架图：

架构整体说明：

随着互联网技术的迅速发展很多大中小型公司已经离不开互联网办公及其提供服务，例如淘宝、美团等网站宕机几个小时损失是致命的，很多网站对其高可用性越来越强，这就意味着运维人员需做到从硬件和软件两方面保证服务器的平均无故障时间减小，才能提高其可用性。

corosync是一个集群管理套件的部分，它在传递信息的时候可以通过一个简单的配置来定义信息传递的方式和协议等，能实现资源间的高可用。目前，corosync功能和特性已经非常完善了，所以pacmaker独立出来之后通常都将pacmaker和corosync结合来使用，corosync并没有通用的资源管理器，因此要借助pacmaker来实现，pacemaker是作为corosync的插件来使用的，所以只需要在corosync配置文件中启动pacemaker插件即可;但是真正启动corosync并且配置它需要命令行接口进行调用，没配置pcs那么这里我们只能使用crm工具来对其进行资源的管理。

架构详细说明图：

corosync集群常见的组合方式及配置接口：

heartbeat v1 + hasource

heartbeat v2 + crm

heartbeat v3 + pacemaker + crmsh(corosync v1版本时没有投票系统，corosync v2有投票系统，当系统发生网络分区、脑裂时则将会将所有的资源转移至可用的其他主机之上)

corosync v1 + pacemaker corosync v2 + pacemaker

cman +rgmanager corosync v1 + cman + pacemaker

CRM：集群资源管理

资源类型：

primitive:基本资源，主资源，仅能运行一个节点

group:组，将组成一个高可用服务所需要的所有资源集合在一起

clone:克隆，同一资源科出现多份，可运行在多个节点

multi-state(master/slave):多状态类型，是克隆资源的特殊表现，副本间可存在主从的关系

RA：资源代理

资源代理类别:

LSB:位于/etc/rc.d/init.d/*,支持start，stop，restart，reload，status，force-reload

注意：使用LSB资源类型的不能开机自动运行

OCF(open cluster framework)：
/usr/lib/ocf/resource.d/provider/,类似于LSB的脚本，但仅支持start，stop，status，monitor，meta-data

STONITH:调用stonith设备的功能，systemd:unite ifle,/usr/lib/systemd/system/

注意：必须设置enable，设置为开机自动启动

资源约束方式：

位置约束：定义资源对节点的倾向性

排序约束：定义资源彼此能否运行在同一个节点的倾向性

顺序约束：多个资源启动顺序的依赖关系

HA集群常用的工作模型：

A/P：两节点，active/passive，工作于主备模型

A/A：两节点，active/active，工作于主主模型

N-M：N>M，N个节点，M个服务，假设每个节点运行一个服务，活动节点数为N，备用节点数为N-M

在集群分裂(split-brain)时需要使用到资源隔离，有两种隔离级别：

STONITH：节点级别的隔离，通过断开一个节点的电源或者重新启动节点

fencing：资源级别的隔离，类似通过向交换机发出隔离信号，特意让数据无法通过此接口

当集群分裂，即分裂后的一个集群的法定票数小于总票数一半时采取对资源的控制策略

corosync安装及其配置

要求：1.基于主机名之间进行相互解析 2.各个节点之间时间需同步

安装：yum -y install pacemaker (CentOS7)

corosync配置详解：corosync的主要配置分为totem、logging、quorum、nodelist配置段

完成上诉配合后需生成密码：corosync-kegen -l

将上诉配置文件和秘钥文件拷贝至另一台cluster即可。

启动服务：

systemctl start corosync

systemctl start pacemaker

安装crmsh接口工具来管理集群资源及其配置：yum -y install
crmsh-2.1.4-1.1.x86_64.rpm pssh-2.3.1-4.2.x86_64.rpm
python-pssh-2.3.1-4.2.x86_64.rpm

corosync+pacemaker+nfs实现高可用案例

此实验需将另一台服务器启动nfs服务并挂载至两节点上配置同样的页面文件

实验测试图：

将节点一手动设置为standby模式，则资源会自动转移至节点二

上诉配置可用排列约束和顺序约束实现并且能实现节点之间的粘性和启动顺序

定义资源监控配置如下：当httpd服务停止时，将自动重启httpd,如重启失败则将资源转移至可用的节点

总结：

综合上诉的配置总体感觉corosync+pacemaker的方式实现高可用比lvs略微复杂，corosync同样可实现对RS的健康状态检测，可借助ldirectory实现自动生成ipvs规则。

好文推荐：

「警惕」避免失误！不要让你的代码说谎

这应该是最全的K8s-Pod调度策略了

整整127页！这是一份阿里云内部超全K8s实战手册