pacemaker集群（CentOS 7下怎么搭建高可用集群）

本文目录

• CentOS 7下怎么搭建高可用集群
• kvm做集群如何
• Pacemaker技术总结
• postgresql 高可用集群搭建资料
• 如何更新GreatDB多调度负载均衡集群对外端口
• 如何实现对OpenStack高可用性的构建
• 如何分分钟创建Linux虚拟集群

CentOS 7下怎么搭建高可用集群

CentOS 7下怎么搭建高可用集群。高可用集群是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度。那么新的centos下怎么来搭建高可用集群。

环境：本文以两台机器实现双集热备高可用集群，主机名node1的IP为192.168.122.168 ，主机名node2的IP为192.168.122.169 。

一、安装集群软件必须软件pcs，pacemaker，corosync，fence-agents-all，如果需要配置相关服务，也要安装对应的软件

二、配置防火墙

1、禁止防火墙和selinux

   修改/etc/sysconfig/selinux确保SELINUX=disabled，然后执行setenforce 0或者reboot服务器以生效

2、设置防火墙规则

   三、各节点之间主机名互相解析分别修改2台主机名分别为node1和node2，在centos 7中直接修改/etc/hostname加入本机主机名和主机表，然后重启网络服务即可。

   配置2台主机的主机表，在/etc/hosts中加入

   四、各节点之间时间同步在node1和node2分别进行时间同步，可以使用ntp实现。

   五、各节点之间配置ssh的无密码密钥访问。下面的操作需要在各个节点上操作。

   两台主机都要互相可以通信，所以两台主机都得互相生成密钥和复制公钥，相互的节点上的hosts文件是都要解析对方的主机名， 192.168.122.168 node1 192.168.122.169 node2

   六、通过pacemaker来管理高可用集群

1、创建集群用户

为了有利于各节点之间通信和配置集群，在每个节点上创建一个hacluster的用户，各个节点上的密码必须是同一个。

   2、设置pcsd开机自启动

   3、集群各节点之间进行认证

   4、创建并启动集群

   5、设置集群自启动

   6、查看集群状态信息

   7、设置fence设备

这个可以参考Red Hat Enterprise Linux 7 High Availability Add-On Reference

corosync默认启用了stonith，而当前集群并没有相应的stonith设备，因此此默认配置目前尚不可用，这可以通过如下命令验证：

   可以通过如下面命令禁用stonith：

   8、配置存储

高可用集群既可以使用本地磁盘来构建纯软件的镜像型集群系统，也可以使用专门的共享磁盘装置来构建大规模的共享磁盘型集群系统，充分满足客户的不同需求。

共享磁盘主要有iscsi或DBRD。本文并没有使用共享磁盘。

9、配置浮点IP

不管集群服务在哪运行,我们要一个固定的地址来提供服务。在这里我选择192.168.122.101作为浮动IP,给它取一个好记的名字ClusterIP 并且告诉集群 每30秒检查它一次。

   10、配置apache服务

***隐藏网址***

***隐藏网址***

   首先我们为Apache创建一个主页。在centos上面默认的Apache docroot是/var/www/html,所以我们在这个目录下面建立一个主页。

node1节点修改如下：

   node2节点修改如下：

***隐藏网址***

   11、创建group

将VIP和WEB resource捆绑到这个group中，使之作为一个整体在集群中切换。(此配置为可选)

   12、配置服务启动顺序

以避免出现资源冲突，语法：(pcs resource group add的时候也可以根据加的顺序依次启动，此配置为可选)

   13、指定优先的 Location （此配置为可选)

Pacemaker 并不要求你机器的硬件配置是相同的,可能某些机器比另外的机器配置要好。这种状况下我们会希望设置:当某个节点可用时,资源就要跑在上面之类的规则。为了达到这个效果我们创建location约束。同样的,我们给他取一个描述性的名字(prefer-node1),指明我们想在上面跑WEB 这个服务,多想在上面跑(我们现在指定分值为50,但是在双节点的集群状态下,任何大于0的值都可以达到想要的效果),以及目标节点的名字:

   这里指定分值越大，代表越想在对应的节点上运行。

14、资源粘性（此配置为可选)

一些环境中会要求尽量避免资源在节点之间迁移。迁移资源通常意味着一段时间内无法提供服务，某些复杂的服务，比如Oracle数据库，这个时间可能会很长。

为了达到这个效果，Pacemaker 有一个叫做“资源粘性值”的概念，它能够控制一个服务(资源)有多想呆在它正在运行的节点上。

Pacemaker为了达到最优分布各个资源的目的，默认设置这个值为0。我们可以为每个资源定义不同的粘性值，但一般来说，更改默认粘性值就够了。资源粘性表示资源是否倾向于留在当前节点，如果为正整数，表示倾向，负数则会离开，-inf表示负无穷，inf表示正无穷。

   常用命令汇总：查看集群状态：#pcs status

查看集群当前配置：#pcs config

开机后集群自启动：#pcs cluster enable –all

启动集群：#pcs cluster start –all

查看集群资源状态：#pcs resource show

验证集群配置情况：#crm_verify -L -V

测试资源配置：#pcs resource debug-start resource

设置节点为备用状态：#pcs cluster standby node1

这就是小编给大家带来的CentOS 7下怎么搭建高可用集群步骤，是不是很详细。

kvm做集群如何

很多小型组织使用了kvm虚拟化，但却无法在主机发生故障时采取相关措施保证高可用性。本文介绍如何采取简单的方式确保虚拟机的高可用性。
你可以使用任一linux发行版的kvm，但是这些linux发行版在集群功能方面存在差异。pacemaker堆栈源于suse，红帽在最近的版本中才确定其集群实现方式。因此在本文中我将介绍如何在opensuse
13.1
下配置集群。
图1.
kvm高可用架构概览
假定集群中的节点已经连接到了san。如果集群中的节点还没有连接到san，那么将虚拟主机连接到linux
san并不复杂，当然你也可以使用san设备。然而我们在本文中采用的方式—使用ocfs
2共享文件系统构建集群—只有在使用san时才是有效的。
配置kvm高可用集群的步骤如下所示：
创建基础集群
在san共享存储上配置ocfs2集群文件系统
使用san磁盘作为后端存储，安装虚拟机
为虚拟机配置pacemaker集群资源
验证集群配置
创建基础集群
在open
suse
13.1下使用命令zypper
in
pacemaker
ocfs2-tools
lvm2-clvm
安装构建集群所必需的软件包，开始创建基础集群。集群包括两层。较低的层称之为corosync
转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦

Pacemaker技术总结

Openstack&Pacemaker
Pacemaker内部结构
Corosync/totem协议
Pacemaker主要特性
资源代理标准
资源约束
高级资源类型
服务异常监控
虚拟IP功能
负载均衡功能

Openstack的众多组件服务既可以集成到单个节点上运行，也可以在集群中分布式运行。但是，要实现承载业务系统的高可用集群， Openstack服务必须部署到高可用集群上，并在实现 Openstack服务无单点故障的同时，实现故障的自动转移和自我愈合，而这些功能是Openstack的多数服务本身所不具备的。因此，在生产环境中部署 OpenStack高可用集群时，必须引人第三方集群资源管理软件，专门负责 Openstack集群资源的高可用监控调度与管理。

Pacemaker是 Linux环境中使用最为广泛的开源集群资源管理器，Pacemaker利用集群基础架构(如Corosync)提供的消息和集群成员管理功能，实现节点和资源级别的故障检测和资源恢复，从而最大程度保证集群服务的高可用。从逻辑功能而言，pacemaker在集群管理员所定义的资源规则驱动下，负责集群中软件服务的全生命周期管理。Pacemaker在实际应用中可以管理几乎任何规模的集群，由于其具备强大的 资源依赖模型 ，这使得集群管理员能够精确描述和表达集群资源之间的关系（包括资源的顺序和位置等关系）。同时，对于任何形式的软件资源，通过为其自定义资源启动与管理脚本（资源代理），几乎都能作为资源对象而被Pacemaker管理。此外，需要指出的是，Pacemaker仅是资源管理器，并不提供集群心跳信息，Pacemaker的心跳机制主要基于Corosync（或Heartbeat）来实现。

在多个节点组成的集群中，totem实现让一个节点发送消息，其它所有节点都能全部收到，并且有序的提交给上层应用。
totem的节点有四个状态，也是组建集群的4个阶段。
Gather 阶段：
  这个阶段用于每个节点向外界广播自己的存在并收集其它节点的存在
Commit 阶段：
  这个阶段会产生一个代表节点，该节点向其它所有节点收集信息，并将收集的信息传递给其它所有节点，用于后续阶段
Recovery 阶段：
  这个阶段用于新旧集群交替时，旧集群成员用新集群传递旧集群的消息，使旧集群成员达到所有节点消息全部有序提交到上层
Operational阶段：
  这个阶段是集群组建完成正常工作的状态，这个状态一个节点发送的消息其它节点都会全部有序提交给上层

协议在工作状态是这样的，token在每个节点循环，节点拿到token之后才能发送消息，节点在拿到token后做这么些事：
(1) 取消token重传定时器
(2) 查看令牌rtr是否有消息记录，如果本节点有那些消息则广播这些消息，并从rtr上删除这些消息
(3) 对比my_aru和令牌的seq，查看是否有消息本节点没有收到，如果有则设置令牌上的aru和rtr以及aru_id
(4) 如果new_message_queue有消息，则广播消息，并修改令牌中的seq
(5) 如果两次token中的aru的值都大于某个值m，则向上提交序号大于m的消息
(6) 发送令牌给下一个节点
(7) 启动token重传定时器，再次收到token或者regular message的时候取消

token有重传机制，用于防止消息丢失和发现网络问题重组集群，本地变量my_aru和token里的aru和seq用于确认所有节点都收到消息，aru_id和rtr用于重传消息给某节点。

***隐藏网址***

LSB(Linux standard Base)

Systemd

OCF(open Cluster Framework)

位置约束(Location)

顺序约束(Order)

捆绑约束(Colocation)

***隐藏网址***

Pacemaker 集群是一个事件驱动系统，其中事件可以是资源失败，或配置更改。 ocf:pacemaker:ClusterMon 资源可监控集群状态，并触发每个集群事件警报。这个资源以常规间隔在后端运行 crm_mon ，它还可以使用 extra_options 参数执行外部程序。

***隐藏网址***

为保证资源正常工作，可在资源定义中添加监控操作。如果没有为资源指定监控操作，默认情况下pcs会创建一个以60秒为间隔的监控操作。所有节点上的LRM进程周期执行状态检查脚本，实现对资源状态的检测，LRM将结果上报本地CRM进程，本地CRM进程再上报master CRM进程，由pengine策略引擎计算监控结果的响应动作，并最终由master CRM按相反路径将动作发送至具体资源，执行对应动作（redis服务支持的动作包括如下图的操作）。

资源监控操作配置示例：

资源操作配置选项：

该功能是由对应的资源代理ocf:heartbeat:IPaddr2提供支持，可以同时创建多个不同ip的IPaddr2资源服务。

由于pacemaker支持的资源代理类型包括了systemd类型服务，如：负载均衡服务haproxy(不仅限于该服务)，因此我们可以配置haproxy服务以提供负载均衡功能。

附：

***隐藏网址***

postgresql 高可用集群搭建资料

多种方案，含zookeeper方案 ： PostgreSQL 流行 HA 方案

有实例 有讲解！ postgresql 高可用集群搭建 ： PostgreSQL_HA_with_primary_standby_2vip

pgpool+Keepalived 实现postgresql 高可用集群： PostgreSQL+pgpooll+Keepalived双机HA方案

利用pgpool 实现postgresql 高可用集群 ： POSTGRESQL主备部署模式

看起来不错 ： 双机热备技术：使用pgpool搭建高可用PostgreSQL HA的步骤

PostgreSQL 流复制 + Pgpool-II 实现高可用 HA

推荐使用pgpool原因： PostgreSQL的集群技术比较

很好的要看corosync+pacemaker： 基于Pacemaker的PostgreSQL一主多从读负载均衡集群搭

可能复杂 ： Pacemaker+corosync搭建PostgreSQL共享存储HA

corosync+pacemaker 有实例 ： postgresql双机热备、高可用方案（采用pacemaker+corosync实现）

需求讲得好 ： PostgresSQL HA高可用架构实战

PostgresSQL HA高可用架构实战

流复制HA（pgpool） ：较简单、易实现

共享存储HA（corosync+pacemaker）：功能完备、学习成本高、复杂

如何更新GreatDB多调度负载均衡集群对外端口

"1.?停止dbservice资源组(选择任意一个pacemaker节点执行)
#?pcs?resource?disable?dbservice
2.?关闭dbscale
停止dbscale(每个dbscale节点都执行)?执行如下命令:
#?sgrdb?-uroot?-p密码?-h127.0.0.1?-P19100?-e?“DBSCALE?FLUSH?CONFIG?TO?FILE;”
#?cd?/app/dbcluster/sgrdb/dbscale?#?sh?daemon/stopper.sh
确认dbscale进程退出
#?ps?-ef?|grep?dbscale
保存最新dbscale.conf配置
#?export?LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/app/dbcluster/sgrdb/dbscale/libs?#?./fetch_config_file_from_zoo
#?mv?dbscale.conf?dbscale-bak.conf
#?mv?generated_dbscale.conf?dbscale.conf
3.?清理zookeeper上的配置信息(任选一个dbscale节点执行)
在任意一个dbscale节点上执行如下命令
#?cd?/app/dbcluster/sgrdb/dbscale
#?export?LD_LIBRARY_PATH=$LD_LIBRARY_PATH:`pwd`/libs?#?./clean_zookeeper
4.?相关配置文件
1)?/etc/ha.d/ldirectord.cf文件
修改其中的集群对外端口(每个pacemaker节点都要执行)
例如,将原来的端口19100更改为集群新端口为20000,每个dbscale的19100端口更改为新的20000端口
virtual=172.16.90.100:20000?real=172.16.90.102:20000?gate?real=172.16.90.103:20000?gate
确认无误后,将更改好的/etc/ha.d/ldirectord.cf拷贝到其他pacemaker节点
2)?dbscale.conf文件(每个dbscale节点都要执行)?#?cd?/app/dbcluster/sgrdb/dbscale
#?vi?dbscale.conf
i.?更改端口
?port?=?19100
type?=?MySQLDriver?bind-address?=?0.0.0.0
将port?=?19100更改为port?=?20000
确认检查,更改符合预期:
#?grep?""^port""?dbscale.conf
ii.?将config-version?配置项这一行删除例如:
删除行:
config-version?=?49
5.?启动dbscale(所有dbscale节点执行)
执行如下命令:
#?cd?/app/dbcluster/sgrdb/dbscale?#?python?daemon/dbscale_daemon.py?确认lvs_dest.sh脚本位置
#?cd?/app/dbcluster/sgrdb/lvs?#?sh?lvs_dest.sh?stop
#?sh?lvs_dest.sh?start
6.?启动dbservice资源组并查看状态(选择任意一个pacemaker节点执行)
#?pcs?resource?enable?dbservice?#?pcs?status
7.?通过ipvsadm?-l命令查看信息是否正常
本命令在vip所在节点上执行?如果更改了集群端口,信息如下:
#?ipvsadm?-l
IP?Virtual?Server?version?1.2.1?(size=4096)?Prot?LocalAddress:Port?Scheduler?Flags
-》?RemoteAddress:Port?TCP?test1:20000?rr
更,集群端口
-》?test1:20000
更,dbscale端口
-》?test2:20000
更,dbscale端口
-》?test3:20000
更,dbscale端口
"

如何实现对OpenStack高可用性的构建

控制节点的高可靠性是主要问题，而且对于不同的组件都有自己的高可靠性需求和方案。
　　（1）由于CotrolNode只有1个，且负责整个系统的管理和控制，因此当Cotrol Node不能提供正常服务时，怎么办？这就是常见的单节点故障（SPoF，single point of failure）问题。
　　高可用性基本上是没办法通过一台来达到目标的，更多的时候是设计方案确保在出问题的时候尽快接管故障机器，当然这要付出更大的成本。
　　对于单点问题，解决的方案一般是采用冗余设备或者热备，因为硬件的错误或者人为的原因，总是有可能造成单个或多个节点的失效，有时做节点的维护或者升级，也需要暂时停止某些节点，所以一个可靠的系统必须能承受单个或多个节点的停止。
　　常见的部署模式有：Active-passive主备模式，Active-active双主动模式，集群模式。
　　（2）那么如何构建冗余的控制节点？或者什么其它方法实现高可靠的控制？
　　很多人可能想到实现active-passive模式，使用心跳机制或者类似的方法进行备份，通过故障转移来实现高可靠性。Openstack是没有多个控制节点的，Pacemaker需要多种服务各自实现这种备份、监听和切换。
仔细分析控制节点提供的服务，主要就是nova-api、nova-network、nova-schedule、nova-volume，以及
glance、keysonte和数据库mysql等，这些服务是分开提供的。nova-api、nova-network、glance等可以分别在每
个计算节点上工作，RabbitMQ可以工作在主备模式，mysql可以使用冗余的高可用集群。

如何分分钟创建Linux虚拟集群

首先需要有两个Red Hat Enterprise Linux或CentOS 7节点，并配置正确的转发及反向域名系统，由于Red Hat 6及7之间有些变化，显著降低了集群管理的复杂度。
集群设置主要依靠两种技术：Pacemaker 和 Corosync。Pacemaker运行集群管理端，Corosync管理更低级别的集群项目以确保连通性。
使用如下命令同时安装Pacemaker 和 Corosync：
yum install –y pcs fence-agents-all
该命令将会下载配置集群所需要的所有依赖包，请注意必须在两个节点上执行上述命令。
你还需要增加一个防火墙规则以允许通过必需的流量。只需要运行如下命令：
firewall-cmd --permanent --add-service=high-availability
***隐藏网址***
firewall-cmd --reload
启动集群设备
接下来的步骤是启用并启动集群服务。需要运行如下命令：
systemctl enable pcsd.service
systemctl start pcsd.service
第一行命令在启动时启用集群服务，第二行命令在当前会话启动集群服务。
图A 启用并开启集群服务
如果你有兴趣，可以查看/var/logs/cluster/目录下日志确认发生了什么。此时，我们已经启动了集群服务，但还没有真正构建集群设置。
采用最新版本的RHEL或CentOS，可以在命令行下使用pcs命令——“Pacemaker/Corosync配置系统”的简称——直接进行配置，这比之前的安装过程更简单。
安装完集群配置后，创建了一个名为hacluster的用户管理虚拟集群。为了能够使用该账号，必须更改密码，因此在两个节点上使用如下命令重置密码：passwd hacluster
管理虚拟集群
完成上述配置后，就可以开始管理虚拟集群与节点了。第一个步骤是授权包含在虚拟集群中的节点。命令如下：pcs cluster auth node1 node2
如果一切按计划进行，屏幕看起来应该与图B类似。
图B 授权集群节点
创建集群资源
下一个步骤是创建集群资源。可以使用pcs cluster setup命令创建集群资源：pcs cluster setup --start --name myapp node1 node2
此时，集群资源控制器将刷新现有配置，同步新配置数据并构建一个包括两个指定节点的新配置。接下来就是使用如下命令启用虚拟集群： pcs cluster enable --all
结果应该会显示两个节点已经启用了。为检查整个集群的状态，可以使用命令pcs cluster status，该命令将显示当前集群状态的概要信息。
图C 检查当前集群状态
理解共享存储的作用
在处理虚拟集群节点时需要牢记的一个重要事项是确保已关闭了hypervisor级的文件锁定系统。不这样做可能会带来很多问题，包括导致有问题的磁盘变为只读的。应该在操作系统级完成锁定。为覆盖该设置，请检查hypervisor文档。
在本示例中，我们仅设置相关配置。我们需要做的一件事是对服务器如何决定虚拟集群内什么是“活的”以及什么是“死的”进行管理。这可以通过称之为fencing的进程完成。当节点没有完全出故障并出现问题时，Fencing允许每个节点停止其他节点以保持集群的完整性。
没有有效的fencing配置，客户端将无法启动。fencing命令是pcs stonith。stonith是“关闭其他节点”首字母的缩略词，是一个能够关闭未在正常运行的节点的Linux服务。
有一些fence方法可用，但我们在示例中使用的是内置的虚拟fencing方法。在任何一个节点上运行如下命令：
pcs stonith create newfence fence_virt pcmk_host_list=f1
此时，我们可以使用如下命令重新启用集群组件：pcs cluster start --all
如果你使用的是pcs status命令，应该显示正在正常运行的服务。
启用虚拟IP
完成上述配置后，我们需要启用虚拟IP。虚拟IP是没有物理连接的地址。其用意是充当虚拟集群提供服务的容错前端。例如，如果一个节点出故障，不需要任何手动配置或者明显的停机时间，所有的流量将会路由到另一个集群节点。
根据需要取代如下命令中的IP地址，然后执行：
pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 ip=192.168.0.100 cidr_netmask=24 op monitor interval=20s
集群现在应该处于活动状态。在开始使用集群前你需要增加集群资源。
***隐藏网址***
望采纳