集群概念介绍，Cluster的原理模型与构建实例
高可用集群
1 概述
Linux HA Cluster的原理模型与构建实例（1）
一、什么是高可用集群
高可用集群就是当某一个节点或服务器发生故障时，另一个节点能够自动且立即向外提供服务，即将有故障节点上的资源转移到另一个节点上去，这样另一个节点有了资源既可以向外提供服务。高可用集群是用于单个节点发生故障时，能够自动将资源、服务进行切换，这样可以保证服务一直在线。在这个过程中，对于客户端来说是透明的。
二、高可用集群衡量标准
高可用集群一般是通过系统的可靠性(reliability)和系统的可维护性(maintainability)来衡量的。通常用平均无故障时间（MTTF）来衡量系统的可靠性，用平均维护 时间（MTTR）来衡量系统的可维护性。因此，一个高可用集群服务可以这样来定义：HA=MTTF/(MTTF MTTR)*100%
一般高可用集群的标准有如下几种：
99%：表示 一年宕机时间不超过4天
99.9% ：表示一年宕机时间不超过10小时
99.99%： 表示一年宕机时间不超过1小时
99.999% ：表示一年宕机时间不超过6分钟
三、HA Cluster 相关特性
1、提供冗余系统：HA Cluster：为提升系统调用性，组合多台主机构建成为的集群
2、vote system投票系统：HA中的各节点无法探测彼此的心跳信息时，必须无法协调工作；此种状态即为partitioned cluster；
投票原则：
（1）少数服从多数原则：quorum
whit quorum（拥有法定票数） > total1/2
without quorum（无法定票数）<= total1/2
当HA节点数为奇数时，通过判断投票数来仲裁，当HA节点数为偶数时，就需要使用其他仲裁设备
（2）仲裁设备
quorum disk （qdisk）：qdisk 是一个小于 10MB 导入所有集群节点的共享磁盘设备。qdiskd 是运行在集群的所有节点上用来定期评估自身的健康情况的后台服务,它定期将其节点的状态信息放 入到 qdisk 上。 每 qdiskd 服务在提交其节点信息后,接着查看 qdisk 上其他节点的状态，权重为(N / 2)；
ping node：同时ping某个网关或设备，通过通不通来仲裁
3、failover: 失效转移，故障转移，failback：失效转回，故障转回，通过配置ha.cf文件中的auto_failback on启用
4、心跳信息传递机制
（1）Serail cable：串形接口连接，作用范围有限，不建议使用；
（2）Ethernet cable：网线连接，通过网络接口（中间可通过交换机）将主机连接起来；
（3）UDP Unicast：UDP单播方式
UDP Multicast：UDP组播方式（相对比较常用）
UDP Broadcast：UDP广播方式
说明：组播地址：用于标识一个IP组播域；IANA(Internet Assigned number authority)把D类地址空间分配给IP组播使用；其范围是：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 Cluster的工作模型
1、主从方式（非对称）A/P：两节点集群，active, passive，工作于主备模型；
集群包含2个节点和一个或多个服务器，备份节点随时都在检测主节点的健康状态信息，当主节点发生故障时，服务会自动切换到备份节点保证运行，平时备份节点不会运行（感觉会让费资源）
2、对称方式：A/A：两节点集群，active/active，工作于双主模型；
集群包含2个节点和一个或多个服务，其中每一个节点都运行着不同的服务且相互作为备份，两个节点互相检测对方的健康状况，这样当其中一个节点发生故障时，该节点上的服务会自动切换到另一个节点上去，保证服务运行
3、多机模型：M-N（M个节点，N个服务，M>N）或M-M（M个节点，M个服务）
集群包含多个节点和多个服务。每一个节点都可能运行和不运行服务，每台服务器都监视着几个指定的服务，当其中的一个节点发生故障时，会自动切换到这组服务器中的一个节点上去。
五、HA Cluster的架构层次与解决方案
1、Messaging Layer：主要为信息层，作用是传递当前节点的心跳信息，告知其他节点是否在线，如果不在线，可根据相关机制实现资源转移，同时传递集群相关事务消息（每个节点安装相关心跳软件，通过网线连接起来，相互监听在相关IP地址和端口上）
解决方案：
（1）heartbeat V1,V2（稳定版）,V3
（2）corosync（openAIS的子项目分出研发，功能强大）
（3）keepalive
（4）cman
2、CRM（Cluster Resource Messager）：集群资源管理器
主要用来提供那些不具有高可用的服务提供高可用性的，调用Messaging Layer来实现工作。因此工作在Messaging Layer上层。资源管理器的主要工作是根据messaging Layer传递的健康信息来决定服务的启动、停止和资源转移、资源的定义和资源分配。在每一个节点上都包含一个CRM，且每个CRM都维护这一个CIB（Cluster Internet Base，集群信息库），只有在主节点上的CIB是可以修改的，其他节点上的CIB都是从主节点那里复制而来的。在CRM中还包含LRM和DC等组件
解决方案：
（1）heartbeat v1 haresources (配置接口：配置文件，文件名为haresources)
（2）heartbeat v2 crm (在各节点运行一个crmd进程，配置接口：命令行客户端程序crmsh，GUI客户端：hb_gui)；
（3）heartbeat v3, pacemaker (pacemaker可以以插件或独立方式运行；配置接口，CLI接口：crmsh, pcs; GUI: hawk(webgui), LCMC, pacemaker-mgmt)；
（4）rgmanager (配置接口，CLI：clustat, cman_tool; GUI: Conga(luci ricci))
组合方式：
（1）heartbeat v1
（2）heartbeat v2
（3）heartbeat v3 pacemaker
（4）corosync pacemaker
（5）cman rgmanager (RHCS)
（6）cman pacemaker
3、LRM（Local Resource Messager）：本地资源管理器，属于CRM的组件，用来获取某个资源状态，并且管理本地资源，例如：当检测到对方没有心跳信息时，则会启动本地相关服务
4、DC：理解为事务协调员，当集群节点发生故障，出现分组的情况时，由于可能都运行着相关服务，会发生资源抢夺的情况，因此事务协调员DC会根据每个组的法定票数来决定哪些节点启动服务，哪些节点停止服务
5、资源隔离组件：如果主节点出现相关故障，此时备份节点立即抢占资源，而主节点正在执行写操作，备份节点一旦也执行相应的写操作，会导致文件系统错乱和服务器崩溃，因此隔离机制此种情况需要采用资源
（1）节点级别隔离
STONITH(Shoot The Other Node in the Head，”爆头“)通过控制电源开关断电，上电来使节点重启或关机
（2）资源级别
FC SAN switch可以实现在存储资源级别拒绝某节点的访问
6、资源代理RA（Resource Agent）：RA实际复制启动相关资源的，是一个脚本文件，一个节点可以有多个RA
（1）heartbeat legacy：heartbeat传统类型的RA，通常位于/etc/ha.d/haresources.d/目录下；
（2）LSB：Linux Standard Base, /etc/rc.d/init.d目录下的脚本，至少接受4个参数：{start|stop|restart|status}；
（3）OCF：Open Cluster Framework，子类别：provider
STONITH：专用于实现调用STONITH设备功能的资源；通常为clone类型
7、资源：资源就是启动一个服务需要的子项目。例如启动一个httpd服务，需要ip，也需要服务脚本、还需要文件系统（用来存储数据的），这些我们都可以统称为资源
（1）资源类型：
（a）primitive：主资源，只能运行于集群内的某单个节点；(也称作native)；
（b）group：组资源，容器，包含一个或多个资源，这些资源可通过“组”这个资源统一进行调度；
（c）clone：克隆资源，可以在同一个集群内的多个节点运行多份克隆；
（d）master/slave：主从资源，在同一个集群内部于两个节点运行两份资源，其中一个主，一个为从；
（2）资源约束
（a）location：位置约束，定义资源对节点的倾向性；用数值来表示，-oo, oo；
（b）colocation：排列约束，定义资源彼此间“在一起”倾向性；-oo, oo
group（分组）：亦能实现将多个资源绑定在一起；
（c）order：顺序约束，定义资源在同一个节点上启动时的先后顺序；例如：首先应该先挂载共享存储，在启动httpd或mysqld服务才行吧。
HA Cluster的原理模型与构建实例（1） 一、什么是高可用集群 高可用集群就是当某一个节点或服务器发生故障时，另一个节点能够自动且...
一、高可用集群
集群Cluster
备注：本文主要结合自己的学习笔记，以及参考博客集群（cluster）原理（转）整理而成。
（一）提升系统高可用性的解决方案：冗余(redundant)
工作模式
- active/passive：主备
- active/active：双主
以心跳方式通告
- active --> HEARTBEAT --> passive
- active <--> HEARTBEAT <--> active
故障处理
- failover：故障切换，即某资源的主节点故障时，将资源转移至其它节点的操作
- failback：故障移回，即某资源的主节点故障后重新修改上线后，将之前已转移至其它节点的资源重新切回的过程
集群类型：
LB lvs/nginx（http/upstream, stream/upstream）
HA 高可用性
SPoF: Single Point of Failure
HPC
集群（cluster）就是一组计算机，他们作为整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点（node）。一个理想的集群是，用户从不会意识到集群系统底层的节点，在他/她们看来，集群是一个系统，而非多个计算机系统。并且集群系统的管理员可以随意的增加和删除集群系统的节点。
（二）HA Cluster实现方案
ais：应用接口规范完备复杂的HA集群
RHCS：Red Hat Cluster Suite红帽集群套件
heartbeat
corosyncvrrp协议实现：虚拟路由冗余协议
keepalived
系统可用性的公式：A=MTBF/（MTBF MTTR）
(0,1), 95%
几个9（指标）: 99%, ..., 99.999%，99.9999%；
2Linux Cluster类型
二、KeepAlived基本介绍
系统故障：
硬件故障：设计缺陷、wear out（损耗）、自然灾害……
软件故障：设计缺陷
a）高可用性（High Availability）集群
（一）VRRP(Virtual Router Redundancy Protocol)协议术语
虚拟路由器：Virtual Router，多个物理路由器对外以一个IP地址提供服务，仿佛一台路由器
- 虚拟路由器标识：VRID(0-255)，唯一标识虚拟路由器
- VIP：Virtual IP，虚拟IP
- VMAC：Virutal MAC (00-00-5e-00-01-VRID)，虚拟MAC
物理路由器
master：主设备
backup：备用设备
priority：优先级
提升系统高用性的解决方案之降低MTTR：
手段：冗余redundant
active/passive 主备
active/active双主
active --> HEARTBEAT --> passive
active <--> HEARTBEAT <--> active
HA集群致力于提供高度可靠的服务，避免SPOF单点失败（single Point Of failure）的问题。就是利用集群系统的容错性对外提供7*24小时不间断的服务，如高可用的文件服务器、数据库服务等关键应用。
（二）KeepAlived的工作特性
通告：心跳，优先级等；周期性
工作方式：抢占式，非抢占式
安全认证：
- 无认证
- 简单字符认证：预共享密钥
- MD5
工作模式：
- 主/备：单虚拟路由器
- 主/主：主/备（虚拟路由器1），备/主（虚拟路由器2）
高可用的是“服务”：
HA nginx service：
vip/nginx process[/shared storage]
资源：组成一个高可用服务的“组件”
(1) passive node的数量
(2) 资源切换
b）负载均衡(Load Balancing）集群：
（三）KeepAlived的功能
vrrp协议完成地址流动
为vip地址所在的节点生成ipvs规则(在配置文件中预先定义)
为ipvs集群的各RS做健康状态检测
基于脚本调用接口通过执行脚本完成脚本中定义的功能，进而影响集群事务，以此支持nginx, haproxy等服务
shared storage：
NAS：文件共享服务器；
SAN：存储区域网络，块级别的共享
使任务可以在集群中尽可能平均的分摊不同计算机处理，充分利用集群的处理能力，提高对任务的处理效率。在实际应用中这几种集群类型可能混合使用，以提供更高稳定的服务，如在一个使用网络流量负载均衡的集群中，就会包含高可用的网络文件系统、高可用的网络服务。
三、KeepAlived的配置
Network partition：网络分区
quorum：法定人数
with quorum： > total/2
without quorum: <= total/2
隔离设备： fence
node：STONITH = Shooting The Other Node In The Head，断
电重启
资源：断开存储的连接
其中负载均衡服务器的高可用性是指为了屏蔽负载均衡服务器失效，需要建立一个备份机。主服务器和备份机上都运行High Availability监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器IP并继续提供服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，他就释放IP地址，这样的主管理器就开开始再次进行集群管理的工作了。为在主服务器失效的情况下系统能正常工作，我们在主、备份机之间实现负载集群系统配置信息的同步和备份，保持两者系统的基本一致。
（一）HA Cluster配置准备：
各节点时间必须同步：ntp服务（CentOS 6）, chrony（CentOS 7）
// 由于ntp/chrony服务不能同步差距过大的时间，需要先使用ntpdate命令同步一次，再开启服务 ntpdate ntp_server_ip // 开启chronyd服务（CentOS 7） vim /etc/chrony.conf server 172.18.0.1 iburst systemctl enable chronyd systemctl start chronyd // 开启ntp服务（CentOS 6） vim /etc/ntp.conf server 172.18.0.1 iburst chkconfig ntpd on service ntpd start确保iptables及selinux不会成为阻碍
各节点之间可通过主机名互相通信（对KA并非必须），建议使用/etc/hosts文件实现
各节点之间的root用户可以基于密钥认证的ssh服务完成互相通信（对KA并非必须）
ssh-keygen ssh-copy-id destination_ip
TWO nodes Cluster
辅助设备：ping node, quorum disk
.LB Cluster分类
（二）KeepAlived的程序环境
主配置文件：/etc/keepalived/keepalived.conf
主程序文件：/usr/sbin/keepalived
Unit File：/usr/lib/systemd/system/keepalived.service
Unit File的环境配置文件：/etc/sysconfig/keepalived
Failover：故障切换，即某资源的主节点故障时，将资源转移至其它节点的操作
四层：lvs,nginx(stream)，haproxy(modetcp)
（三）KeepAlived的配置文件结构
GLOBAL CONFIGURATION：全局设置
Global definitions
Static routes/addressesVRRPD CONFIGURATION：VRRP设置
VRRP synchronization group(s)：vrrp同步组
VRRP instance(s)：即一个vrrp虚拟路由器LVS CONFIGURATION：LVS设置
Virtual server group(s)
Virtual server(s)：ipvs集群的vs和rs
Failback：故障移回，即某资源的主节点故障后重新修改上线后，将之前已转移
至其它节点的资源重新切回的过程
七层：基于http，如nginx(http),haproxy(mode http), httpd（apache）...
（四）配置虚拟路由器
语法：
vrrp_instance <STRING> { .... }专用参数：
- state MASTER | BACKUP
当前节点在此虚拟路由器上的初始状态；只能有一个是MASTER，余下的都应该为BACKUP - interface IFACE_NAME
绑定为当前虚拟路由器使用的物理接口 - virtual_router_id VRID
当前虚拟路由器惟一标识，范围是0-255 - priority 100
当前物理节点在此虚拟路由器中的优先级；范围1-254 - advert_int 1
vrrp通告的时间间隔，默认1s - authentication：认证机制
authentication { auth_type AH|PASS auth_pass <PASSWORD> 仅前8位有效 }- virtual_ipaddress：虚拟IP
virtual_ipaddress { <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL> }- track_interface：配置监控网络接口，一旦出现故障，则转为FAULT状态实现地址转移
track_interface { eth0 eth1 … }- nopreempt：定义工作模式为非抢占模式
- preempt_delay 300：抢占式模式，节点上线后触发新选举操作的延迟时长，默认模式
- 定义通知脚本：
notify_master <STRING> | <QUOTED-STRING>：
当前节点成为主节点时触发的脚本
notify_backup <STRING> | <QUOTED-STRING>：
当前节点转为备节点时触发的脚本
notify_fault <STRING> | <QUOTED-STRING>：
当前节点转为“失败”状态时触发的脚本
notify <STRING> | <QUOTED-STRING>：
通用格式的通知触发机制，一个脚本可完成以上三种状态的转换时的通知
- state MASTER | BACKUP
实验1：实现主/备虚拟路由器
- 实验环境：
物理路由器1：ip: 192.168.136.230, 主机名: node1, MASTER
物理路由器2：ip: 192.168.136.130, 主机名: node2, BACKUP
VIP：192.168.136.100
// 配置物理路由器1 vim /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost } notification_email_from node1@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 // vrrp中的路由器主机名 vrrp_mcast_group4 224.0.0.58 // 设置组播ip地址 } vrrp_instance VI_1 { state MASTER interface ens37 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 // openssl rand -hex 4 生成8位16进制密码 } virtual_ipaddress { 192.168.136.100/24 } } systemctl start keepalived // 配置物理路由器2 vim /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost } notification_email_from node2@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node2 vrrp_mcast_group4 224.0.0.58 } vrrp_instance VI_1 { state BACKUP interface ens37 virtual_router_id 51 priority 90 //作为BACKUP优先级比MASTER要低 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 // 密码与node1相同 } virtual_ipaddress { 192.168.136.100/24 } } systemctl start keepalived- 测试
node1的ip地址已经出现VIP
监听组播地址的tcp连接
tcpdump -i ens37 -nn host 224.0.0.58，此时关闭node1的keepalived服务systemctl stop keepalived，自动由node2接管并开始声明自身拥有虚拟路由器的IP
VIP此时已经被node2接管
- 实验环境：
- 实验2：实现keepalived日志
vim /etc/sysconfig/keepalived
KEEPALIVED_OPTIONS="-D -S 3" // -D:详细日志，-S 3: 设置日志facility为local3
vim /etc/rsyslog.conf
local3.* /var/log/keepalived.log // 设置日志存储路径
systemctl restart rsyslog
systemctl restart keepalived
tail -f /var/log/keepalived.log
实验3：实现主/主虚拟路由器，并且当节点发生变化时主动发送邮件
- 实验环境
物理路由器1：ip: 192.168.136.230, 主机名: node1
物理路由器2：ip: 192.168.136.130, 主机名: node2
虚拟路由器1：MASTER: node1, BACKUP: node2, VIP: 192.168.136.100
虚拟路由器2：MASTER: node2, BACKUP: node1, VIP: 192.168.136.200
// 配置物理路由器1（虚拟路由器1的MASTER，虚拟路由器2的BACKUP） vim /etc/keepalived/keepalived.conf smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.0.0.58 } // 虚拟路由器1的设置 vrrp_instance VI_1 { state MASTER interface ens37 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 } virtual_ipaddress { 192.168.136.100/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } // 虚拟路由器2的设置 vrrp_instance VI_2 { state BACKUP interface ens37 virtual_router_id 61 priority 80 advert_int 1 authentication { auth_type PASS auth_pass a56c19be } virtual_ipaddress { 192.168.136.200/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } systemctl restart keepalived // 配置物理路由器2（虚拟路由器1的BACKUP，虚拟路由器2的MASTER） vim /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost } notification_email_from node2@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node2 vrrp_mcast_group4 224.0.0.58 } // 虚拟路由器1的设置 vrrp_instance VI_1 { state BACKUP interface ens37 virtual_router_id 51 priority 90 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 } virtual_ipaddress { 192.168.136.100/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } // 虚拟路由器2的设置 vrrp_instance VI_2 { state MASTER interface ens37 virtual_router_id 61 priority 100 advert_int 1 authentication { auth_type PASS auth_pass a56c19be } virtual_ipaddress { 192.168.136.200/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } // 在物理路由器1,2上添加脚本文件 vim /etc/keepalived/notify.sh #! /bin/bash contact='root@localhost' notify() { mailsubject="$(hostname) to be $1, vip floating" mailbody="$(date '%F %T'): vrrp transition, $(hostname) changed to be $1" echo "$mailbody" | mail -s "$mailsubject" $contact } case $1 in master) notify master ;; backup) notify backup ;; fault) notify fault ;; *) echo "Usage: $(basename $0) {master|backup|fault}" exit 1 ;; esac chmod x /etc/keepalived/notify.sh- 测试
监听组播地址的tcp连接tcpdump -i ens37 -nn host 224.0.0.58，可以看到node1, node2分别声明拥有虚拟路由器1(vrid 51)、虚拟路由器2(vrid61)的IP地址
分别查看node1和node2的网卡IP地址，进一步确认上述结果
此时，断开node1的网络连接
虚拟路由器1的VIP立即由node2的网卡接管
恢复node1的网络连接，在node1和node2上都可以看到相应的邮件通知：
node1上通知出错，很快通知自身被切换为BACKUP，恢复网络连接后通知自身重新变为MASTER；
node2上通知自身切换为MASTER，恢复网络连接后通知自身切换为BACKUP
- 实验环境
HA Cluster实现方案:
c）性能计算（High Perfervidmance Computing）集群
（五）Keepalived支持IPVS
- 语法：
virtual_server {IP port | fwmark int}
{
...
real_server{
...
}
...
}
virtual_server常用参数
- delay_loop <INT>
检查后端服务器的时间间隔 - lb_algo rr|wrr|lc|wlc|lblc|sh|dh
定义调度方法 - lb_kind NAT|DR|TUN
集群的类型 - persistence_timeout <INT>
持久连接时长 - protocol TCP
服务协议，仅支持TCP - sorry_server<IPADDR> <PORT>
所有RS故障时，备用服务器地址
- delay_loop <INT>
real_server <IPADDR> <PORT>常用参数
- weight <INT>
RS权重 - notify_up <STRING>|<QUOTED-STRING>
RS上线通知脚本 - notify_down <STRING>|<QUOTED-STRING>
RS下线通知脚本 - HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }
定义当前主机的健康状态检测方法
- weight <INT>
HTTP_GET|SSL_GET：应用层健康状态检测
HTTP_GET|SSL_GET { url { path <URL_PATH> // 定义要监控的URL status_code <INT> // 判断上述检测机制为健康状态的响应码 digest <STRING> // 判断为健康状态的响应的内容的校验码 } connect_timeout <INTEGER> // 连接请求的超时时长 nb_get_retry <INT> // 重试次数 delay_before_retry <INT> // 重试之前的延迟时长 connect_ip <IP ADDRESS> // 向当前RS哪个IP地址发起健康状态检测请求 connect_port <PORT> // 向当前RS的哪个PORT发起健康状态检测请求 bindto <IP ADDRESS> // 发出健康状态检测请求时使用的源地址 bind_port <PORT> // 发出健康状态检测请求时使用的源端口 }TCP_CHECK参数
- connect_ip <IP ADDRESS>
向当前RS的哪个IP地址发起健康状态检测请求 - connect_port <PORT>
向当前RS的哪个PORT发起健康状态检测请求 - bindto <IP ADDRESS>
发出健康状态检测请求时使用的源地址 - bind_port <PORT>
发出健康状态检测请求时使用的源端口 - connect_timeout <INTEGER>
连接请求的超时时长
- connect_ip <IP ADDRESS>
实验4：实现主/备模型的IPVS集群
- 实验环境：
LB1(master)/VS：IP: 192.168.136.230
LB2(backup)/VS：IP: 192.168.136.130
VIP：192.168.136.100
RS1：IP: 192.168.136.229
RS2：IP: 192.168.136.129
// 配置LB1的keepalived设置 vim /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost } notification_email_from node1@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.0.0.58 } vrrp_instance VI_1 { state MASTER interface ens37 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 } virtual_ipaddress { 192.168.136.100/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } virtual_server 192.168.136.100 80{ delay_loop 3 lb_algo wrr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 192.168.136.229 80{ weight 2 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } real_server 192.168.136.129 80{ weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } } // 配置LB2的keepalived设置 vim /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost } notification_email_from node2@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node2 vrrp_mcast_group4 224.0.0.58 } vrrp_instance VI_1 { state BACKUP interface ens37 virtual_router_id 51 priority 90 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 } virtual_ipaddress { 192.168.136.100/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } virtual_server 192.168.136.100 80{ delay_loop 3 lb_algo wrr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 192.168.136.229 80{ weight 2 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } real_server 192.168.136.129 80{ weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } } // 配置LB1, LB2的sorry server服务 echo sorry on LB1 > /var/www/html/index.html // LB1上操作 echo sorry on LB2 > /var/www/html/index.html // LB2上操作 systemctl start httpd // 配置RS1, RS2的Web服务 echo RS1 homepage > /var/www/html/index.html // RS1上操作 echo RS2 homepage > /var/www/html/index.html // RS2上操作 systemctl start httpd // 编辑脚本实现：禁止RS响应ARP请求，并将网卡绑定VIP vim lvs_dr_rs.sh #! /bin/bash vip='192.168.136.100' mask='255.255.255.255' dev=lo:1 rpm -q httpd &> /dev/null || yum -y install httpd &>/dev/null service httpd start &> /dev/null && echo "The httpd Server is Ready!" case $1 in start) echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig $dev $vip netmask $mask broadcast $vip up echo "The RS Server is Ready!" ;; stop) ifconfig $dev down echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce echo "The RS Server is Canceled!" ;; *) echo "Usage: $(basename $0) start|stop" exit 1 ;; esac chmod x lvs_dr_rs.sh bash lvs_dr_rs.sh start // LB1, LB2启动KeepAlived服务，进行测试 systemctl start keepalived访问VIP(192.168.136.100)的Web服务，正常工作
停止RS2的Web服务，自动进行健康检查，全部调度至RS1
停止RS1的Web服务，自动进行健康检查，调度至LB1的sorry server
停止LB1的KeepAlived服务，自动切换至LB2
- 实验环境：
实验5：实现主/主模型的IPVS集群
- 实验环境：
LB1/VS1：IP: 192.168.136.230，后端RS: RS1, RS2
LB2/VS2：IP: 192.168.136.130，后端RS: RS3, RS4
LB1 VIP：192.168.136.100
LB2 VIP：192.168.136.200
RS1：IP: 192.168.136.229
RS2：IP: 192.168.136.129
RS3：IP: 192.168.136.240
RS4：IP: 192.168.136.250
LB之间互为MASTER与BACKUP的关系
MASTER：LB1，BACKUP：LB2
MASTER：LB2，BACKUP：LB1
// 配置LB1, LB2的keepalived设置 global_defs { notification_email { root@localhost } notification_email_from node1@localhost // LB1上操作 notification_email_from node1@localhost // LB2上操作 smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 // LB1上操作 router_id node2 // LB2上操作 vrrp_mcast_group4 224.0.0.58 } vrrp_instance VI_1 { state MASTER // LB1上操作 state BACKUP // LB2上操作 interface ens37 virtual_router_id 51 priority 100 // LB1上操作 priority 90 // LB2上操作 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 } virtual_ipaddress { 192.168.136.100/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } vrrp_instance VI_2 { state BACKUP // LB1上操作 state MASTER // LB2上操作 interface ens37 virtual_router_id 61 priority 80 // LB1上操作 priority 100 // LB2上操作 advert_int 1 authentication { auth_type PASS auth_pass a56c19be } virtual_ipaddress { 192.168.136.200/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" } virtual_server 192.168.136.100 80{ delay_loop 3 lb_algo wrr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 192.168.136.229 80{ weight 2 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } real_server 192.168.136.129 80{ weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } } virtual_server 192.168.136.200 80{ delay_loop 3 lb_algo wrr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 192.168.136.240 80{ weight 2 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } real_server 192.168.136.250 80{ weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 1 nb_get_retry 3 delay_before_retry 1 } } } // 配置LB1, LB2的sorry server服务 echo sorry on LB1 > /var/www/html/index.html // LB1上操作 echo sorry on LB2 > /var/www/html/index.html // LB2上操作 systemctl start httpd // 配置RS1, RS2, RS3, RS4的Web服务 echo RS1 homepage > /var/www/html/index.html // RS1上操作 echo RS2 homepage > /var/www/html/index.html // RS2上操作 echo RS3 homepage > /var/www/html/index.html // RS3上操作 echo RS4 homepage > /var/www/html/index.html // RS4上操作 systemctl start httpd // 编辑脚本实现：禁止RS响应ARP请求，并将网卡绑定VIP vim lvs_dr_rs.sh #! /bin/bash vip='192.168.136.100' // RS1, RS2上操作 vip='192.168.136.200' // RS3, RS4上操作 mask='255.255.255.255' dev=lo:1 rpm -q httpd &> /dev/null || yum -y install httpd &>/dev/null service httpd start &> /dev/null && echo "The httpd Server is Ready!" case $1 in start) echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig $dev $vip netmask $mask broadcast $vip up echo "The RS Server is Ready!" ;; stop) ifconfig $dev down echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce echo "The RS Server is Canceled!" ;; *) echo "Usage: $(basename $0) start|stop" exit 1 ;; esac chmod x lvs_dr_rs.sh bash lvs_dr_rs.sh start // LB1, LB2启动KeepAlived服务，进行测试 systemctl start keepalived- 实验环境：
使用ipvsadm -Ln命令查看ipvs调度策略，与KeepAlived的配置吻合
访问VIP1, VIP2(192.168.136.100, 192.168.136.200)的Web服务，正常工作
停止RS1的Web服务，自动进行健康检查，全部调度至RS2
停止RS2的Web服务，自动进行健康检查，调度至LB1的sorry server
停止LB1的KeepAlived服务，自动切换至LB2
停止RS3的Web服务，自动进行健康检查，全部调度至RS4
停止RS4的Web服务，自动进行健康检查，调度至LB2的sorry server
ais：应用接口规范 完备复杂的HA集群
RHCS：Red Hat Cluster Suite红帽集群套件
heartbeat
corosync
HPC集群，也称为计算集群。在这种集群运行的是专门开发的并行应用程序，它可以把一个问题的数据分不到多台计算机上，利用这些计算机的共同资源来完成任务，从而可以解决单机不能胜任的工作（如果问题规模太大，单机计算速度太慢）。
（六）Keepalived调用脚本进行资源监控
keepalived调用外部的辅助脚本进行资源监控，并根据监控的结果状态实现优先动态调整
vrrp_script：自定义资源监控脚本，vrrp实例根据脚本返回值，公共定义，可被多个实例调用，定义在vrrp实例之外
track_script：调用vrrp_script定义的脚本去监控资源，定义在实例之内，调用事先定义的vrrp_script
- 分两步：(1) 先定义一个脚本；(2) 调用此脚本
格式：
// 定义脚本，定义在实例外 vrrp_script <SCRIPT_NAME> { script "" // 引号内为脚本命令 interval INT weight -INT } // 调用脚本，定义在实例内 track_script { SCRIPT_NAME_1 SCRIPT_NAME_2 }- 分两步：(1) 先定义一个脚本；(2) 调用此脚本
实验6：实现主/主模型的高可用Nginx反向代理
- 实验环境：
LB1/VS1：IP: 192.168.136.230，后端RS: RS1, RS2
LB2/VS2：IP: 192.168.136.130，后端RS: RS3, RS4
LB1 VIP：192.168.136.100
LB2 VIP：192.168.136.200
RS1：IP: 192.168.136.229
RS2：IP: 192.168.136.129
RS3：IP: 192.168.136.240
RS4：IP: 192.168.136.250
LB之间互为MASTER与BACKUP的关系
MASTER：LB1，BACKUP：LB2
MASTER：LB2，BACKUP：LB1
// 配置LB1, LB2的KeepAlived设置 vim /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost } notification_email_from node1@localhost // LB1上操作 notification_email_from node2@localhost // LB2上操作 smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 // LB1上操作 router_id node2 // LB2上操作 vrrp_mcast_group4 224.0.0.58 } vrrp_script chk_nginx { script "killall -0 nginx && exit 0 || exit 1;" interval 1 weight -20 fall 3 rise 3 } vrrp_instance VI_1 { state MASTER // LB1上操作 state BACKUP // LB2上操作 interface ens37 virtual_router_id 51 priority 100 // LB1上操作 priority 90 // LB2上操作 advert_int 1 authentication { auth_type PASS auth_pass dd73f9d6 } virtual_ipaddress { 192.168.136.100/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" // 下面的脚本引用仅在LB1的配置文件出现 track_script { chk_nginx } } vrrp_instance VI_2 { state BACKUP // LB1上操作 state MASTER // LB2上操作 interface ens37 virtual_router_id 61 priority 90 // LB1上操作 priority 100 // LB2上操作 advert_int 1 authentication { auth_type PASS auth_pass a56c19be } virtual_ipaddress { 192.168.136.200/24 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault" // 下面的脚本引用仅在LB2的配置文件出现 track_script { chk_nginx } } // 配置LB1,LB2的nginx反向代理 vim /etc/nginx/nginx.conf http { upstream websrvs1 { server 192.168.136.229:80 weight=2; server 192.168.136.129:80 weight=1; } upstream websrvs2 { server 192.168.136.240:80 weight=2; server 192.168.136.250:80 weight=1; } server { listen 192.168.136.100:80; location / { proxy_pass http://websrvs1; } } server { listen 192.168.136.200:80; location / { proxy_pass http://websrvs2; } } } nginx -t systemctl start nginx // 配置RS1, RS2, RS3, RS4的Web服务 echo RS1 homepage > /var/www/html/index.html // RS1上操作 echo RS2 homepage > /var/www/html/index.html // RS2上操作 echo RS3 homepage > /var/www/html/index.html // RS3上操作 echo RS4 homepage > /var/www/html/index.html // RS4上操作 systemctl start httpd // LB1, LB2启动KeepAlived服务，进行测试 systemctl start keepalived登录192.168.136.100和192.168.136.200的web服务，确实按照设置要求调度
停止RS2的httpd服务，全部调度至RS1
停止RS3的httpd服务，全部调度至RS4
关闭LB2的nginx反向代理服务，通过
tcpdump -i ens37 -nn host 224.0.0.58查看组播情况。三个红框依次表达：
（1）未关闭nginx前的组播状态
（2）关闭nginx后，LB2的vrid 61权重减去20变作80，而LB1vrid 61的权重为90
（3）由于LB1的权重高，VIP2的所有权被LB1接管
关闭LB1的nginx反向代理服务，通过
tcpdump -i ens37 -nn host 224.0.0.58查看组播情况。三个红框依次表达：
（1）未关闭nginx前的组播状态
（2）关闭nginx后，LB1的vrid 51权重减去20变作80，而LB2的vrid 51权重为90
（3）由于LB2的权重高，VIP1的所有权被LB2接管
由于此时两个nginx反向代理均关闭，故访问192.168.136.100和192.168.136.200的web服务全部失败
打开LB2的nginx反向代理服务，通过
tcpdump -i ens37 -nn host 224.0.0.58查看组播情况。三个红框依次表达：
（1）未打开nginx前的组播状态
（2）打开nginx后，LB2的vrid 61权重增加20变作100，而LB1的vrid 61权重为90
（3）由于LB2的权重高，VIP2的所有权被LB2接管
此时VIP1和VIP2均由LB2上的nginx服务器进行反向代理，192.168.136.100和192.168.136.200的web服务全部恢复
- 实验环境：
vrrp协议实现：虚拟路由冗余协议
keepalived
这类集群致力于提供了单个计算机所不能提供的强大的计算能力。如天气预报、石油勘探与油藏模拟、分子模拟、生物计算等。
（七）Keepalived同步组
LVS NAT模型VIP和DIP需要同步，需要同步组
格式：
vrrp_sync_group VG_1 { group { VI_1 # name of vrrp_instance(below) VI_2 # One for each moveable IP. } } vrrp_instance VI_1 { eth0 vip } vrrp_instance VI_2 { eth1 dip }
3 集群的优点
a)高扩展性
b)高可用性HA:集群中的一个节点失效，它的任务可传递给其他节点。可以防止单点失效
c)高性能：负载平衡集群允许系统同时接入更多的用户
d)高性能价比：可以采用廉价的复合工业标准的硬件来构造高性能的系统
4 集群分类
4.1基于软硬件分类
.硬件：
F5 Big-IP
Citrix Netscaler
A10 A10
.软件：
lvs：LinuxVirtual Server，不能识别应用层数据
nginx：支持四层调度，也可以支持7层调度
haproxy：支持四层调度，也支持7层调度
应用层的调度器，需要对发过来的请求进行解开数据包，然后再封装。有一个问题是，socket一台机器上只能是65536个，并发请求太多，主机将不能正常提供请求。解决方案是把后台服务拆分开，对服务进行分类。把不同的服务拆开，独立提供服务
ats：apachetraffic server，yahoo捐助
perlbal：Perl编写
pound
4.2基于工作的协议层次划分：
.传输层（通用）：DPORT
LVS：
nginx：stream机制
haproxy：mode tcp机制
实际工作中，生产环境用nginx和haproxy进行调度
.应用层（专用）：针对特定协议，自定义的请求模型分类
proxy server：
http：nginx,httpd, haproxy(mode http), ...
fastcgi：nginx,httpd, ...
mysql：mysql-proxy,...
5 集群相关概念介绍
5.1 HA概念介绍
计算机系统的可用性（availability）是通过系统的可靠性（reliability）和可维护性（maintainability）来度量的。工程上通常采用平均无故障时间（MTBF:MeanTime Between Failure）来度量系统的可靠性，用平均恢复时间（MTTR：MeanTime To Restoration（repair））来度量系统的可维护性。于是可用性定义为:A=MTTF/(MTBF MTTR)*100%。可用性百分比范围是(0,1)，如99%,99.5%, 99.9%, 99.99%, 99.999%, 99.9999%。其中99.999%表示一年内允许5分钟的故障时间
系统故障：
硬件故障：设计缺陷、wear out（损耗）、自然灾害……
软件故障：设计缺陷
5.1.1 HA的容错备援运作过程
自动侦测（Auto-Detect）阶段 由主机上的软件通过冗余侦测线，经由复杂的侦听程序。逻辑判断，互相侦测对方运行情况，所检查的项目有：主机硬件（CPU和周边）、主机网络、主机操作系统、数据引擎以及其他应用程序、主机与磁盘阵列连线。为确保侦测的正确性，而防止错我的判断，可设定安全侦测时间、包括侦测时间间隔、侦测次数以调整安全系数，并且由主机的冗余通信连线，将所汇集的讯息记录下来，以供维护参考。
自动切换（Auto-Switch）阶段 某一主机如果确认对方故障，则正常主机继续进行原来的任务，还将依据各种容错备援模式接管预先设定的备援作业程序，并进行后续的程序以及服务。
自动恢复（Auto-Recovery）阶段 在正常主机代替故障机工作后，故障机可离线进行修复工作。在故障主机修复后，通过冗余通讯线与原来主机连线，自动切换回修复完成的主机上。整个回复过程完成有EDI-HA自动完成，亦可依靠预先配置，选择回复动作为半自动或不回复。
5.1.2 HA三种工作方式
a) 主从方式（非对称方式）
工作原理：主机工作，备机处于监控状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
b) 双机双工方式（互备互援）
工作原理：两台主机同时运行各自的服务工作且互相检测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
c) 集群工作方式（多服务器互备方式）
工作原理：多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。
5.1.4 HA集群实现方案
keepalived: vrrp协议，和lvs配合使用。keepalive实现高可用，lvs实现调度。
ais:应用接口规范
heartbeat
cman rgmanager(RHCS)
coresync_pacemaker
5.2会话保持：负载均衡（LB）
(1) session sticky：同一用户调度固定服务器
Source IP：LVS sh算法（对某一特定服务而言）
注意，基于源地址调度不太靠谱，因为可能IP经过NAT转换，该源IP后端可能有很多机器发起请求，如果将这些请求都集中调度到
同一台机器，可能会会后端该服务器造成较大的负担
Cookie：服务器分发给客户端的
cookie用来表示客户端的身份的。早期用重cookie，包含了所有的信息。
后来用轻cookie，主要有session的id.session是在服务器端的。
根据cookie的信息来决定分发给哪台机器上。cookie属于应用层的数据。因此要使用应用层的调度器，如Ngnix或haproxy
(2) session replication：每台服务器拥有全部session，如session multicastcluster
(3) session server：专门的session服务器,如Memcached，Redis
6高可用的实现
有如下6种方法实现高可用
1）共享存储（shared storage）
NAS：网络附属存储（NetworkAttached Storage），文件共享服务器
SAN：存储区域网络，（Storage Area Network）,块级别的共享
2）网络分区（Networkpartition）
有以下两个方式：
a)法定人数（quorum）：
with quorum：> total/2
without quorum: <= total/2
b)隔离设备：fence，有两种手段
当监测到有设备异常是，可以通过以下两个方法隔离异常设备
断电重启：STONITH = ShootingThe Other Node In The Head，
隔离资源：断开存储的连接
3）双节点集群(TWO nodes Cluster)
4）Failover：故障切换，即某资源的主节点故障时，将资源转移至其它节点的操作
5）Failback：故障移回，即某资源的主节点故障后重新修改上线后，将之前已转移至其它节点的资源重新切回的过程
6）HACluster实现方案:
有以下两个方案：
vrrp协议的实现:轻量级解决方案，如keepalived
ais：重量级的解决方案，应用接口规范完备HA集群，逻辑比较复杂。有三个解决方案
RHCS：Red Hat Cluster Suite红帽集群套件，完整解决方案
heartbeat
corosync
版权声明：本文由可提现彩票app-支持提现彩票app-10元可提现的彩票app发布于首页,转载请注明出处：集群概念介绍，Cluster的原理模型与构建实例