LINUX 集群学习一

Posted 2020-10-31

            服务器中的集群与网络中的集群虽然都是为了提供冗余的服务能力，但是在实现上有一定的差异，主要原因为网络冗余只需要实现流量有冗余路径，当主的链路故障后，流量可以通过备的链路通行即可。对于有状态的如TCP协议，某些设备如防火墙需要对其进行状态检测，那么只需要在主备设备之间开启会话同步功能即可。但是对于服务器而言较为复杂，主要原因是因为服务器作为流量的终结点，是需要直接对外提供服务的，其上存储的数据则需要被服务访问，不再是流量穿越就可以。本人一起从事网络相关的工作，在第一次接触服务器集群时，对其实现原理机制完全不了解，在反复学习后才有一些粗浅的认识，本篇先简单的介绍一下服务器集群原理，后续慢慢对学习中的实验进行总结。
            服务器集群主要实现服务的冗余能力以及高性能，从目前我所了解到的来看，主要有两种类型：

1. 通过类似负载均衡设备将服务请求向后续的多个真实服务器转发，可以实现多台服务器对外提供服务，以达到服务的高并发能力；
2. 多台服务器自身冗余对外提供服务，这多台服务器之间构成一个高可靠集群，正常情况下只有主节点响应请求，当主节点设备故障后，服务需要立即由备份的节点进行接管，并且对外提供服务。
   如下图所示，这两种类型可以共同组合起来，前面多台设备由第2种情况组成集群对外提供服务，这里是master以及backup，两台设备组成一个虚拟节点VS，由该虚拟VS节点对外提供服务，实际承担VS功能的节点作为master。正常情况下由master将外面进来的响应接收下来，然后再将请求向后端转发。当前端接收服务的主节点master故障后，由备份节点backup继续接收请求向后端转发，这样可以实现前端高可靠接受请求以及后端的高并发服务响应能力。
   
   这里我们着重讲第二种情况，即多台设备对外提供冗余能力的集群。通俗来讲，这种服务器集群实际上就是要实现当主节点在提供服务时启用服务相关的资源，而备节点停用相关的资源；当主节点故障后，备节点启用服务相关的资源对外提供服务，而主节点停止相关的服务。
   在集群系统中，这些相关的资源不再由服务器自身管理，而由一个统一的软件来管理，这里我们称为CRM（cluster resource manager），其主要作用是用于对每个成员节点的信息进行收集，并且计算出来哪一个节点应当对外提供服务，而后由节点上的LRM（local resource manager）进行资源的具体处理。这些具体的服务我们称为RA(resource agent)
   CRM计算所依赖的资源如何而来呢？这里引入集群事务信息层message layer，主要用于各节点之间相互通信以及收集集群的相关信息。所以，集群的结构我们可以粗略的表示为如下图所示：
   
   这些资源如何组合在一起运行呢？是否可以放一起呢？是否必须放在一起运行呢？这里就讲到资源的粘性。同时资源粘性也是为了解决某些情况下，主备节点性能不一样，资源应该运行在性能较优的节点上，应该让资源对性能高的设备更具有粘性。
   资源粘性：资源对某节点的依赖程度，通过score进行定义。
   资源组：resource group，将各种资源归为一组，实现资源的同时转移。
   资源约束：除了资源组以外，可以使用资源间的约束关系进行定义。
   排列约束：资源间的依赖性，定义资源是否能够放在一起使用，是否可以运行于同一个节点，score
   正值：资源可以放在一起
   负值：资源不可以放在一起
   位置约束：location，score得分衡量：资源对节点的依赖倾向程度
   正值：倾向于运行于此节点
   负值：倾向于逃离此节点
   顺序约束：order，定义资源启动或者关闭时的次序
   Core都是正整数或者负整数形式，也可以是如下的形式：
   -INF：负无穷
   INF：正无穷
   当主备切换后，防止故障设备在正常、不正常之间来回切换，需要进行资源隔离。
   资源隔离：
   节点级别：STONITH
   资源级别：
   例如：FC SAN switch可以实现在存储资源级别拒绝某节点的访问

Split brain：集群节点无法有效获取其他节点的状态信息时，产生脑裂，出现资源抢占情况。这种情况在网络中我们称其为双主状态。
脑裂最严重的后果是抢占共享存储导致数据损坏。

当集群主出现故障时，备设备需要取代主设备的功能，但是如何确认是对端故障，而不是自身故障呢？

1. 两个节点：借助第三方，如网关
2. 借助仲裁磁盘，主节点往磁盘上写数据，其他节点监控是否有主节点往该磁盘上写数据
3. 奇数个节点：引入法定票数quorum的概念，可以是每个节点1票，当集群分裂后，票数多的胜出，也可以是每个节点的票数不相等，如高性能的节点可以占多票。

具体实现：
Massage Layer：
Heartbeat：v1（古老版本）,v2（成熟版本）,v3 ，监听UDP协议的694号端口
Heartbeat v3分裂为多个独立项目：
Heartbeat v3：MessageLayer层
Pacemaker：
cluster-glue
Corosync：Redhat6.0以后默认使用的软件：corosync，性能比heartbeat优越，但是不具有pacemaker的功能，需要配合使用，组合后相当于heartbeat v3
Cman：redhat5.0，cluster manager：红帽上有专门的RHCS套件，cman是RHCS的核心组件
Keepalived：本身为了LVS的DC高可用而设计
Ultramonkey：

CRM：
Heartbeat v1自带管理器功能，haresources，为heartbeat v1提供CRM；
Heartbeat v2 自带的资源管理器，为heartbeat v2提供CRM；
Haresources:兼容V1版本
Crm：需要监听在某个接口，可以通过图形界面管理
Heartbeat v3：
Pacemaker：Heartbeat v3 中CRM 发展为独立的项目。为heartbeatv3或者corosync提供CRM功能。
Rgmanager:资源组管理器，cman专门提供的CRM

Resource Type：资源类别
Primitive:主资源，某一个时刻只能运行在一个节点上，比如说对外提供服务的虚拟IP地址；
Clone:将主资源克隆一份，资源必须同时运行在多个节点上，比如STONITH管理的RA；
Group:多个资源归为一类，当作一个容器，同进同退；
Master/save:一种特殊的clone资源，只能运行在两个节点上，资源具有主从关系。

RA 类别：接收LRM传递过来的指令，完成对资源的控制
Legacy heartbeat v1 RA：专用于heartbeat v1
LSB:(/etc/rc.d/init.d/)遵循linux SHELL编程风格，可以接收四种参数：start|stop|restart|status.
OCF：open cluster framework，除了上述四种参数，还可以接受类似monitor等参数，可能由不同的vendor提供
Pacemaker
Linbit(drbd)
STONITH:专门管理硬件 STONITH设备。