一、什么是高可用一、高可用集群(High Availability Cluster)高可用HA（High
二、如何保障系统的高可用
Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
假设系统一直能够提供服务，我们说系统的可用性是100%。
如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。
很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。
百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com
能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。
总结：
保证系统高可用，架构设计的核心准则是：冗余。
有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。
接下来我们看下典型互联网架构中，如何通过冗余+自动故障转移来保证系统的高可用特性。高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
方法论上，高可用是通过冗余+自动故障转移来实现的。
整个互联网分层系统架构的高可用，又是通过每一层的冗余+自动故障转移来综合实现的，具体的：
（1）【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual
IP自动故障转移
（2）【反向代理层】到【站点层】的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移
（3）【站点层】到【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移
（4）【服务层】到【缓存层】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性
（5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移
（6）【服务层】到【数据库“写”】的高可用，是通过写库的冗余实现的，常见实践是keepalived + virtual IP自动故障转移
集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。每一个单个的计算机系统都叫集群节点（node）。随着业务的增长，集群通过添加新的节点，满足资源的高可扩展性。
如何实现集群？由于我们要实现集群所以我们至少要两台机子
安装所需要的的软件：
yum install -y pacemaker pcs psmisc policycoreutils-python
安装完成之后要注意关闭你的火墙和selinux
启动pcsd服务让它开机自启
systemctl enable --now pcsd.service
启动完成之后我们可以看到系统默认为我们创建了一个用户（hacluster）
cat /etc/shadow 可以查看
修改用户的密码
echo westos | passwd --stdin hacluster
创建两个集群
pcs cluster auth pcmk-1 pcmk-2
pcs cluster setup --name mycluster pcmk-1 pcmk-2
pacemakerd --features
查看所有用户状态（启动集群）
pcs cluster start --all
启动
pcs cluster start
或者
systemctl start corosync.service
systemctl start pacemaker.service
启动服务
检查集群通讯是否正常
corosync-cfgtool -s
检查成员和法定人数
corosync-cmapctl | grep members
检查起搏器的安装
ps axf
如果ok检查pc状态输出
pcs status
确保没有启动错误
journalctl | grep -i error
检查配置有效性
注意：在做任何更改之前都要检查
crm_verify -L -V
禁用STONITH，将STONITH设置为false
pcs property set stonith-enabled=false
crm_verify -L
添加一个资源
pcs resource create ClusterIP ocf: heartbeat:IPaddr2
ip=172.25.15.100 cidr_netmask=32 op monitor interval=30s
资源加载完成后用pcs status查看加载情况
１． 我们的第一个资源将是一个惟一的IP地址，集群可以在任何一个节点上打开这个IP地址。无论集群服务运行在何处，最终用户都需要一个一致的地址来与之联系。这里，我将选择172.25.15.100作为浮动地址，将其命名为ClusterlP，并告诉集群检查它是否每30秒运行一次。
２． 这里的另一个重要信息是ocf: heartbeat:lPaddr2。这告诉了Pacemaker关于你想要添加的资源的三件事:第一个字段(本例中为ocf)是资源脚本遵循的标准以及查找它的位置。第二个字段(在本例中为心跳)是特定于标准的;对于OCF资源，它告诉集群资源脚本在哪个OCF名称空间中第三个字段(本例中为IPaddr2)是资源脚本的名称要获取可用资源标准的列表(ocf: heartbeat:IPaddr2的ocf部分)，运行:
获取可用资源列表
pcs resource standards
要获取可用的OCF资源提供者列表(OCFIPaddr2的心跳部分)，运行:
pcs resource providers
如果您想看到特定OCF提供者(OCFlPaddr2的IPaddr2部分)的所有资源代理，运行:
pcs resource agents ocf:heartbeat
添加一个web资源
pcs resource create Web systemd:httpd op monitor interval=30s
创建一个资源群组
pcs resource group add Webgroup VIP Web
注意：配置资源组，组中资源会在同一节点运行并且写在前面的将会被先启动
关闭所有pcs
pcs cluster stop --all
