Coreosync在传递信息的时候可以通过一个简单的配置文件来定义信息传递的方式和协议等。它是一个新兴的软件，2008年推出，但其实它并不是一个真正意义上的新软件，在2002年的时候有一个项目Openais它由于过大，分裂为两个子项目，其中可以实现HA心跳信息传输的功能就是Corosync ,它的代码60%左右来源于Openais. Corosync可以提供一个完整的HA功能，但是要实现更多，更复杂的功能，那就需要使用Openais了。Corosync是未来的发展方向。在以后的新项目里，一般采用Corosync，而hb_gui可以提供很好的HA管理功能，可以实现图形化的管理。另外相关的图形化有RHCS的套件luci+ricci.
pacemaker是一个开源的高可用资源管理器(CRM)，位于HA集群架构中资源管理、资源代理(RA)这个层次，它不能提供底层心跳信息传递的功能，要想与对方节点通信需要借助底层的心跳传递服务，将信息通告给对方。通常它与corosync的结合方式有两种：
准备工作：
1、两台主机时间同步，最好做ntp服务以获得更加精准的时间；
2、两台主机名要与uname -n 输出的名字相同；
3、配置hosts本地解析，要与 uname -n 一致；
4、两台主机 root 用户能够基于密钥进行通信；
注意：因为一旦配置上高可用以后，资源都是受CRM所控制的，所以要将各资源的开机启动关闭
实验环境：
IP：172.16.4.22 hostname：node2
IP：172.16.4.33 hostname：node3
注：为了保证两个节点间的资源一致性，两台主机间的时差最好不要超过 1s。
安装corosync、pacemaker：
yum -y install corosync pacemaker;ssh node2 'yum -y install corosync pacemaker'
corosync配置文件位于 /etc/corosync/目录下：
如果想让pacemaker在corosync中以插件方式启动，需要 在corosync.conf文件中加上如下内容：
生成多播信息密钥：
注意：
corosync-keygen命令生成密钥时会用到 /dev/random
/dev/random是 Linux系统下的随机数生成器，它会从当前系统的内存中一个叫熵池的地址空间中根据系统中断来生成随机数，加密程序或密钥生成程序会用到大量的随机数，就会出现随机数不够用的情况，random 的特性就是一旦熵池中的随机数被取空，会阻塞当前系统进程等待产生中断会继续生成随机数；
由于此处会用到1024位长度的密钥，可能会存在熵池中的随机数不够用的情况，就会一直阻塞在生成密钥的阶段，两种解决办法：
1、手动在键盘上输入大量字符，产生系统中断(产生中断较慢，不建议使用)
2、通过互联网或FTP服务器下载较大的文件（产生中断较快，建议使用）
密钥生成过程：
# 监听在 172.16.4.22 5404与5405端口，组播地址 239.255.4.1 的5405端口发送心跳
启动完成后要进行一系列的确认，看各组件工作是否正常：
，这可以通过如下命令验证：
注：Stonith 即shoot the other node in the head使Heartbeat软件包的一部分，该组件允许系统自动复位一个失败的服务器使用连接到一个健康的服务器的遥远电源设备，简单的说Stonith设备可以接受一台主机发来的信号从而切断不能传递心跳信息的节点电源，从而避免产生资源争用的设备；
此时我们将node2 节点停掉，因为node2没办法传递心跳信息，node3以为node2出了故障，马上就变成了DC 而且两个节点都不具备法定票数(partition WITHOUT quorum)，再将node2启动起来，就都具有法定票数 (partition quorum)；
安装crmsh软件包：
What 是 crmsh？
pacemaker本身只是一个资源管理器，我们需要一个接口才能对pacemker上的资源进行定义与管理，而crmsh即是pacemaker的配置接口，从pacemaker 1.1.8开始，crmsh 发展成一个独立项目，pacemaker中不再提供。crmsh提供了一个命令行的交互接口来对Pacemaker集群进行管理，它具有更强大的管理功能，同样也更加易用，在更多的集群上都得到了广泛的应用，类似软件还有 pcs；
注：在crm管理接口所做的配置会同步到各个节点上；
Centos 6官方并没有提供crmsh软件包：
corosync 2.x及crmsh for centos 6下载地址：
注：crmsh依赖于四个包：
pssh.noarch 0:2.3.1-5.el6 python-dateutil.noarch 0:1.4.1-6.el6
python-lxml.x86_64 0:2.2.3-1.1.el6 redhat-rpm-config.noarch 0:9.0.3-42.el6.centos
crm的特性：
1、任何操作都需要commit提交后才会生效；
2、想要删除一个资源之前需要先将资源停止
3、可以用 help COMMAND 获取该命令的帮助
4、与Linux命令行一样，都支持TAB补全
crm命令的两种工作方式：
1、命令行模式：
2、交互式模式
常用子命令介绍：
resource 子命令 # 定义所有资源的状态
configure 子命令 # 资源粘性、资源类型、资源约束
node子命令 # 节点管理和状态
ra子命令 # 资源代理类别都在此处
show xml 显示完整的xml格式信息
禁用stonith设备：
1、尝试配置VIP：
# VIP 地址已经配置成功，crm定义的资源就会传到各个节点，并在各个节点上生效，此时将node2节点转换成standby，VIP就会转移到其它节点上；
# 此时在 node3 节点上查看会发现VIP已经转移过来了；
# 将其中一个节点停止，资源就会消失而不是转移到另一个节点上，因为当前是两节点的集群，任何一个节点损坏，其它节点就没办法进行投票，status 中就会变成 WITHOUT quorum，而此时要解决这个问题有两种办法：
1、配置一个仲裁节点；
2、当不具备法定票数时忽略；
注意：忽略法定票数，可能会导致集群的分裂，在生产环境中不建议使用；
注：no-quorum-policy={stop|freeze|suicide|ignore} 默认是stop；改成 ignore忽略即可
ip addr show eth0 查看会发现资源已经生效；
删除一个资源：
注：show 中显示的各行都是CIB对象；也可以 edit 打开vim编辑模式直接删除；
monitor 监控资源
monitor <rsc> [:<role>] <interval>[:<timeout>]
监控 哪个资源 哪个角色 多长时间监控一次 监控超时时长是多少
例：
monitor apcfence 60m:60s 监控apcfence 这个资源 60分钟监控一次 60s 超时
注：每一个资源都有它的默认监控法则，我们所定义的时长，不应该小于它的默认法则时长；
例如：(获取IPaddr资源的默认监控法则)
定义IP：
2、两个节点上分别安装上http，并提供不同的主页，将httpd开启启动关闭；
定义httpd资源：
注意：现在webip与webserver是分别运行在不同的节点上的，默认情况下资源是尽可能均衡的运行在各节点上的；
两种解决办法：
group 组资源，将两个资源定义在一起，做为一组资源而运行；
colocation 也可以定义排列约束，也叫协同约束，两个资源必须在一起；
定义顺序约束：
注：mandatory 代表强制，webip、webserver 这两个资源必须按照我所给定的顺序启动；
此时就可以用客户机测试，访问 172.16.4.88 会访问到节点2上的web页面；
crmnode standby # 将 node2 节点转换成备用节点
再重新用浏览器访问测试，此时访问的就是node3 节点上的web页面了；
crm onde online # 此时将 node2 节点重新上线，资源也不会流转回来
定义节点倾向性：
configure
help location # 获取 location 使用帮助
crm(live)configure# location webip_prefer_node1 webip rule 100: #uname eq node2.zhangjian.com # 约束名 资源名 约束为100 节点名为 node2
crm(live)configure# commit
此时在用浏览器访问web页面就会变成 node2上的页面，因为资源对node2 的倾向性更大，即使将node2 变成备用模式，资源转移出去了，在让node2重新上线，它立马就会流转回来，因为我们定义了webip对于node2的倾向性是100，默认对所有节点的倾向性都是0，所以只要node2在，它就会运行在节点2上；
粘性：每一个资源对于当前节点的粘性；
pacemaker是一个开源的高可用资源管理器(CRM)，位于HA集群架构中资源管理、资源代理(RA)这个层次，它不能提供底层心跳信息传递的功能，要想与对方节点通信需要借助底层的心跳传递服务，将信息通告给对方。通常它与corosync的结合方式有两种：
准备工作：
1、两台主机时间同步，最好做ntp服务以获得更加精准的时间；
2、两台主机名要与uname -n 输出的名字相同；
3、配置hosts本地解析，要与 uname -n 一致；
4、两台主机 root 用户能够基于密钥进行通信；
注意：因为一旦配置上高可用以后，资源都是受CRM所控制的，所以要将各资源的开机启动关闭
实验环境：
IP：172.16.4.22 hostname：node2
IP：172.16.4.33 hostname：node3
注：为了保证两个节点间的资源一致性，两台主机间的时差最好不要超过 1s。
安装corosync、pacemaker：
yum -y install corosync pacemaker;ssh node2 'yum -y install corosync pacemaker'
corosync配置文件位于 /etc/corosync/目录下：
如果想让pacemaker在corosync中以插件方式启动，需要 在corosync.conf文件中加上如下内容：
生成多播信息密钥：
注意：
corosync-keygen命令生成密钥时会用到 /dev/random
/dev/random是 Linux系统下的随机数生成器，它会从当前系统的内存中一个叫熵池的地址空间中根据系统中断来生成随机数，加密程序或密钥生成程序会用到大量的随机数，就会出现随机数不够用的情况，random 的特性就是一旦熵池中的随机数被取空，会阻塞当前系统进程等待产生中断会继续生成随机数；
由于此处会用到1024位长度的密钥，可能会存在熵池中的随机数不够用的情况，就会一直阻塞在生成密钥的阶段，两种解决办法：
1、手动在键盘上输入大量字符，产生系统中断(产生中断较慢，不建议使用)
2、通过互联网或FTP服务器下载较大的文件（产生中断较快，建议使用）
密钥生成过程：
# 监听在 172.16.4.22 5404与5405端口，组播地址 239.255.4.1 的5405端口发送心跳
启动完成后要进行一系列的确认，看各组件工作是否正常：
，这可以通过如下命令验证：
注：Stonith 即shoot the other node in the head使Heartbeat软件包的一部分，该组件允许系统自动复位一个失败的服务器使用连接到一个健康的服务器的遥远电源设备，简单的说Stonith设备可以接受一台主机发来的信号从而切断不能传递心跳信息的节点电源，从而避免产生资源争用的设备；
此时我们将node2 节点停掉，因为node2没办法传递心跳信息，node3以为node2出了故障，马上就变成了DC 而且两个节点都不具备法定票数(partition WITHOUT quorum)，再将node2启动起来，就都具有法定票数 (partition quorum)；
安装crmsh软件包：
What 是 crmsh？
pacemaker本身只是一个资源管理器，我们需要一个接口才能对pacemker上的资源进行定义与管理，而crmsh即是pacemaker的配置接口，从pacemaker 1.1.8开始，crmsh 发展成一个独立项目，pacemaker中不再提供。crmsh提供了一个命令行的交互接口来对Pacemaker集群进行管理，它具有更强大的管理功能，同样也更加易用，在更多的集群上都得到了广泛的应用，类似软件还有 pcs；
注：在crm管理接口所做的配置会同步到各个节点上；
Centos 6官方并没有提供crmsh软件包：
corosync 2.x及crmsh for centos 6下载地址：
注：crmsh依赖于四个包：
pssh.noarch 0:2.3.1-5.el6 python-dateutil.noarch 0:1.4.1-6.el6
python-lxml.x86_64 0:2.2.3-1.1.el6 redhat-rpm-config.noarch 0:9.0.3-42.el6.centos
crm的特性：
1、任何操作都需要commit提交后才会生效；
2、想要删除一个资源之前需要先将资源停止
3、可以用 help COMMAND 获取该命令的帮助
4、与Linux命令行一样，都支持TAB补全
crm命令的两种工作方式：
1、命令行模式：
2、交互式模式
常用子命令介绍：
resource 子命令 # 定义所有资源的状态
configure 子命令 # 资源粘性、资源类型、资源约束
node子命令 # 节点管理和状态
ra子命令 # 资源代理类别都在此处
show xml 显示完整的xml格式信息
禁用stonith设备：
1、尝试配置VIP：
# VIP 地址已经配置成功，crm定义的资源就会传到各个节点，并在各个节点上生效，此时将node2节点转换成standby，VIP就会转移到其它节点上；
# 此时在 node3 节点上查看会发现VIP已经转移过来了；
# 将其中一个节点停止，资源就会消失而不是转移到另一个节点上，因为当前是两节点的集群，任何一个节点损坏，其它节点就没办法进行投票，status 中就会变成 WITHOUT quorum，而此时要解决这个问题有两种办法：
1、配置一个仲裁节点；
2、当不具备法定票数时忽略；
注意：忽略法定票数，可能会导致集群的分裂，在生产环境中不建议使用；
注：no-quorum-policy={stop|freeze|suicide|ignore} 默认是stop；改成 ignore忽略即可
ip addr show eth0 查看会发现资源已经生效；
删除一个资源：
注：show 中显示的各行都是CIB对象；也可以 edit 打开vim编辑模式直接删除；
实验：
定义一个高可用集群：(包含以下三个资源)
1、VIP：172.16.4.88
2、配置httpd 服务
3、FileSystem（NFS）
4、定义约束，保证资源的先后启动顺序，且三个资源需要运行在同一个节点上；
monitor 监控资源
monitor <rsc> [:<role>] <interval>[:<timeout>]
监控 哪个资源 哪个角色 多长时间监控一次 监控超时时长是多少
例：
monitor apcfence 60m:60s 监控apcfence 这个资源 60分钟监控一次 60s 超时
注：每一个资源都有它的默认监控法则，我们所定义的时长，不应该小于它的默认法则时长；
例如：(获取IPaddr资源的默认监控法则)
定义IP：
2、两个节点上分别安装上http，并提供不同的主页，将httpd开启启动关闭；
定义httpd资源：
注意：现在webip与webserver是分别运行在不同的节点上的，默认情况下资源是尽可能均衡的运行在各节点上的；
两种解决办法：
group 组资源，将两个资源定义在一起，做为一组资源而运行；
colocation 也可以定义排列约束，也叫协同约束，两个资源必须在一起；
定义顺序约束：
注：mandatory 代表强制，webip、webserver 这两个资源必须按照我所给定的顺序启动；
此时就可以用客户机测试，访问 172.16.4.88 会访问到节点2上的web页面；
crmnode standby # 将 node2 节点转换成备用节点
再重新用浏览器访问测试，此时访问的就是node3 节点上的web页面了；
crm onde online # 此时将 node2 节点重新上线，资源也不会流转回来
定义节点倾向性：
configure
help location # 获取 location 使用帮助
crm(live)configure# location webip_prefer_node1 webip rule 100: #uname eq node2.zhangjian.com # 约束名 资源名 约束为100 节点名为 node2
crm(live)configure# commit
此时在用浏览器访问web页面就会变成 node2上的页面，因为资源对node2 的倾向性更大，即使将node2 变成备用模式，资源转移出去了，在让node2重新上线，它立马就会流转回来，因为我们定义了webip对于node2的倾向性是100，默认对所有节点的倾向性都是0，所以只要node2在，它就会运行在节点2上；
粘性：每一个资源对于当前节点的粘性；
2069
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
