pacemaker corosync 概念
1、概念
在传统Linux集群种类，主要分了三类，一类是LB集群，这类集群主要作用是对用户的流量做负载均衡，让其后端每个server都能均衡的处理一部分请求；这类集群有一个特点就是前端调度器通常是单点，后端server有很多台，即便某一台后端server挂掉，也不影响用户的请求；其次就是HA集群，所谓ha集群就是高可用集群，这类集群的主要作用是对集群中的单点做高可用，所谓高可用就是在发生故障时，能够及时的将故障转移，从而使故障修复时间最小；这类集群的特点是在多台节点上，各空闲节点会一直盯着工作节点，工作节点也会基于多播或广播的方式把自己的心跳信息发送给其他空闲节点，一旦工作节点的心跳信息在一定时间内空闲节点没有收到，那么此时就会触发资源抢占，先抢到资源的成为新的工作节点，而其他节点又会一直盯着新的工作节点，直到它挂掉，然后再次触发资源抢占；这类集群的特点就是一个节点工作，其他节点看着它工作，一旦工作节点挂了，立刻会有其他节点上来顶替它的工作；最后就是HP集群，HP集群主要用于在复杂计算中场景中，把多台server的算力综合一起，对复杂计算要求比较高的环境中使用；在生产环境中常见的LB和HA集群较多；
2、衡量系统的可用性
A=MTBF/(MTBF+MTTR)
MTBF（Mean Time Between Failure）平均无故障工作时间；MTTR（Mean Time to Repair）平均修复时长；也就是说衡量一个系统的可用性是系统无故障运行时间除以系统无故障运行时间+故障修复时间；我们知道一个系统完全没有故障，这是不可能的，这也意味着A的取值是小于1；如果说一个系统的可用性为0，那么我们会认为该系统没有任何用，所以系统可用性通常是大于0小于1，通常我们用一个百分比来描述系统的可用性；从上面的公式，如果我们要提升系统的可用性我们有两种办法，第一种就是无限提升mtbf的值，让mtbf的值大到可以忽略mttr的值，当然这种方式理想中可行，在现实中，我们的系统一旦发生故障，修复的时间都不会是很少，也就说这种增大MTBF的方式，不是可行的；其次就是降低MTTR的值，降低MTTR的值就是缩短故障修复时间；通常我们降低MTTR的方式是通过冗余主机的方式；就是在容易发生故障的关键性业务上，提前给它配置好相同的服务，然后这台空闲的server就一直盯着工作的server，一旦工作server发生故障，此时空闲的server就立刻把工作的server的IP 地址给抢过来，然后把服务启动了，后端如果有共享存储，此时把共享存储挂载到自己对应的目录；如果有必要我们还需要通过某些机制让之前的server“爆头”，以免发生死灰复燃的场景；
3、HA解决方案
我们知道高可用的是服务，但是通常一个服务该有的多组件也会高可用，比如httpd服务，对于httpd对外它一定会有一个ip地址在对外提供服务，其次就是httpd服务自身的进程，如果业务需要，我们可能还会用到共享存储；通过上述描述，对于高可用httpd服务，我们需要在备份节点上对httpd的ip地址做高可用，服务进程，以及后端的共享存储；对于ip地址的高可用通常是在备份节点上探测到活动节点故障时，第一时间把活动节点的ip地址配置到备份节点上，通常这个ip地址是一个虚拟的ip地址，所以我们叫它vip；对应用程序进程的高可用，通常是我们在备份节点上直接把对应服务提前启动起来；后端共享存储的高可用也是通过某种机制探测活动节点发生故障后，然后把共享存储挂载到备份节点，使得整个httpd服务可用；我们把httpd从一个节点迁移到另一个节点的过程叫故障转移（failover）；这里需要注意，在发生故障转移后，之前活动节点有可能发生故障恢复的情况，此时为了不让之前活动的节点对现有的服务资源发生争用，我们在发生故障转移时，应该让其之前的节点“死”的更彻底一些，我们会让备份节点对活动节点“开一枪”，让发生故障的节点更彻底的故障；这种是为了避免资源争用而导致服务的不可用；
vrrp协议的实现：keepalived
基于OpenAIS规范的实现：corosync；所谓AIS（application interface standard）是指用来定义应用程序接口标准，openais就是开放的应用程序接口标准，它是由SA Forum发布的一套规范；这些规范的主要目的就是为了提高中间件可移植和应用程序的高可用；
4、corosync+pacemaker架构
corosync的主要作用是提供messaging Layer，这个消息传递层的主要作用是，把个主机间的各状态信息，空闲信息等等一系列信息通过消息传递层互相传递，使得托管在corosync上的服务能够根据底层各主机传递的消息来决定，该服务该运行到那台主机上，一旦运行服务的主机发生故障时，它们又能够根据消息传递层的消息，来判断该把服务迁移到那台主机上运行；这样一来托管在corosync上的服务，就实现了高可用；简单点讲，托管在corosync之上的服务对底层主机是不可见的，这也意味着托管在corosync上的服务是能够调用和理解Messaging Layer中的消息；这样一来托管在上面的服务就必须得提供接口来调用messaging Layer对外提供的接口，然后实现服务的迁移；而对于大多数程序来讲，它根本就没有这样的接口，这样一来我们要使用corosync实现服务高可用就变得困难；为了解决托管在corosync的服务能够调用corosync提供的接口，我们需要开发一个中间件，让这个中间件能够向下理解和调用coroysnc提供的接口，向上能够托管服务；这个中间层就是pacemaker；它的主要作用是通过调用corosync提供的接口，来判断把集群资源该怎么分配，服务该怎么迁移和运行；同时pacemaker还提供一个管理界面，能够让管理员来管理这些集群资源；而对于pacemaker来讲，它主要有3个层次，其中CRM（cluster resource manager）的主要作用是通过调用messaging Layer提供的接口和各节点的状态信息来决策集群资源的管理；然后通过接口把决策信息传递给LRM（local resource manager）；LRM的主要作用是对本地的资源做各种管理；而对于LRM来讲，它要怎么管理本地资源呢？它通常不会自己去管理本地资源，而是通过委派RA去管理，所谓RA（resource agent）就是资源代理；它会根据LRM发送的信息来对本地资源进行管理，而这种管理通常是基于各种服务提供的起停脚本来实现的；比如，我们要把httpd服务托管在corosync+pacemaker这个架构上，首先我们得提供一个管理httpd的服务的脚本，比如centos7上的httpd.service，centos6上的/etc/init.d/httpd来实现；而这些脚本通常在我们使用yum安装都会提供，这样一来，我们要托管httpd服务就变得简单，我们只需要在pacemaker上配置，把httpd识别成集群资源即可；只要配置httpd为集群的资源，此时我们就可以在各主机上迁移httpd服务来实现httpd服务的高可用；要实现httpd服务在各节点上迁移，我们需要注意各节点上必须有httpd服务；对于其他服务也是同样的逻辑；简单讲corosync主要提供底层各主机消息状态，集群状态信息，而pacemaker主要对托管在其上的服务进行管理；当然pacemaker也可以通过调用corosync的接口来管理底层的主机，比如让某一台主机下线上线等等操作；
5、corosync集群的投票系统
在集群发生网络分区以后，怎样确定该那一方继续代表集群工作呢？所谓集群网络分区是指集群中的某一台主机或一些主机在规定的时间内不能通过网络检测到其他主机的心跳；当集群网络发生分区以后，到底哪一方能够继续代表集群工作呢？如果是2台主机组成的集群，当其中一台主机不能够正常检测到另一台主机的心跳时，它们都会认为对方故障了，此时就会存在一个资源争用的问题，A认为B挂了，B认为A挂了，此时集群资源就会在A和B之间来回飘动，使得整个服务都不可用；为了解决这样的问题，我们必须有一个系统来决定到底谁该代表集群工作；通常情况在一个分布式系统中，投票系统尤为重要，它决定了整个集群是否能够正常工作；假如我们的集群由3台主机组成，当其中一台主机挂掉了，集群是否能够正常工作呢？到底谁来代表集群工作呢？如果是A来代表集群工作，那么整个集群将不可用，如果是B C来代表集群工作，那么谁来当领导呢？这个时候就需要投票系统来决策了；默认情况集群各主机都会有一定数量的选票在自己手中，当发生分区以后，各主机会根据自己是否检测到心跳信息发送给集群其他节点，根据选票的数量来决定谁故障了，谁能够代表集群工作，如上面的例子，如果是A挂了，那么B会把对A的心跳检测信息，发送给C，然后C也会把对A的心跳检查信息发送给B，此时投票就是A挂了2票，而整个集群总共3票，已经有过半的选票都认为A挂了，那么A此时就不会继续代表集群工作了；剩下的B和C是可继续代表集群工作；我们把能够继续代表集群工作的一方叫with quorum，就是选票大于总选票一半的一方；而对于选票小于或等于总选票的一方我们称为without quorum；此时A就是without quorum一方，它会遵循no_quorum_policy指定的行为，通常no_quorum_policy默认是stop行为，意思就是without quorum一方会停止代表集群工作，当然它还有ignore、suicide、freeze行为；ignore表示忽略自己是without quorum一方的选票结果，继续代表集群工作，suicide表示自杀，就是一旦不是with quorum一方就自我毁灭，freeze表示冻结，所谓冻结就是继续服务老的请求，拒绝新的请求；B和C就是with quorum一方，它们会利用某种机制来挑选出一个领导，然后根据消息传递层的消息来决定，运行在A上的资源该跑在那个节点上继续代表集群工作；而对于BC来讲它们只是联系不到A，A是否真的挂了呢？如果A没有真的挂，那么BC此时把A上的ip地址抢过来，继续代表集群工作，A可能再把ip地址抢过去，这样一来集群就不能够正常工作，为了解决BC的后顾之忧，BC会通过其他机制把A干掉（比如爆头，stonith机制“shoot the other node in the head”），让A即便是存活的也让其挂掉，这样做的目的就是为了保证集群资源不再受A的干扰，正常提供服务；在corosync+pacemaker这种架构中，领导的角色称为DC（disignated coordinator指派的协调员）；DC的主要作用是接收管理员的配置信息和更新集群各状态事务信息，并指派对应节点上的LRM对其集群资源操作，并通过消息传递层把管理配置信息同步给集群其他节点；这样一来，在下一次集群网络发生分区以后，能够在集群其他节点上选出新的DC，从而继续代表集群工作；集群中的各状态事务、配置信息，通常保存在CIB（cluster information base）中，而对于CIB中的各状态事务信息由DC去更新，然后再同步到集群各节点中去；通常DC节点上会运行CRM、CIB、PE（policy engine）、LRM这四个组件；而非DC节点会运行CRM、CIB、LRM这三个组件；而PE的作用就是调度指挥DC把配置信息应用后的结果，通过消息传递层发送给其他非DC节点并保存至各非DC节点的CIB中；
6、资源类型
在corosync+pacemaker架构上，最为核心的就是资源，前边说了那么多，最终目的是为了管理托管在上面的资源；而对于资源来讲资源是有类型的；简单讲就是可以用来调配的服务称为资源，比如一个httpd服务，一个ip地址，一个后端共享存储等等，这些都叫做资源；而对于一个完整的服务来讲，它是由多个单一的资源组合而成；比如一个完整的httpd服务它应该由ip地址、httpd服务进程、在特殊场景中很有可能会有后端共享存储；而这些资源在corosync+pacemaker上，每个资源是有类型的，不同类型的资源运行方式各不相同；
primitive：基本资源，主资源；通常仅能运行为一份，运行在单个节点上的资源；
group：组；将一个或多个资源组织成一个可统一管理的单一单位资源；什么意思呢？默认情况托管在corosync+pacemaker上的资源会均衡的运行在多个主机之上，如果我们不将这些资源逻辑的关联在一起，就会存在，ip地址在A主机上，服务进程在B主机上，后端存储在C主机上，这样一来，我们托管的服务就没有办法向外提供服务，为了解决各依赖资源分散的问题，我们需要将多个有关联依赖的资源逻辑的组织成一个组，然后根据这个组为单位进行调度和管理；
clone：克隆；一个资源可以在集群中运行多个副本，可以运行于多个节点；
mutil-state(master/slave)：是clone类型的资源的特殊表现，可以存在多个副本，副本间存在主从关系；
7、资源倾向性
什么叫资源倾向性呢？我们知道一个资源托管在corosync+pacemaker上，最终都会把资源落在某一个节点上运行，而我们怎么来限制这些资源在那个或那些各节点上运行呢？这个就需要我们配置资源对节点的倾向性了；所谓倾向性就是该资源更加倾向在那个节点运行或更加讨厌在那个几点上运行；在corosync+pacemaker集群上运行资源的方式有3中，N-1、N-M、N-N，其中N表示节点数量，M表示资源数量；N-1表示N个节点上运行1个资源；这也意味有N减1个节点是处于空闲待命状态，这对于服务器的资源利用率有点浪费；所以对于corosync+pacemaker集群和keepalived来讲，keepalived更加轻量化；N-M表示N个节点上运行M个资源，通常M小于N；这意味着有N减M个节点冗余；N-N表示N个节点上运行N个资源，没有冗余节点，这意味着一旦一个资源挂掉，那么对应就会迁移至其他节点，对于其他节点只要提供的ip地址，进程，端口不冲突就不会有很大的问题，只不过相对压力要大一点；对于不同运行方式，冗余的节点数量也是不同的；而对于资源该运行到那个节点我们可以通过定义资源对节点的倾向性来决定；默认情况每个资源都能够在任意节点上运行；也就说默认情况当A资源挂掉以后，它的故障转移范围是其他任何一个集群节点，为了不让A服务运行到B节点，我们可以定义A资源对B节点的倾向性为负无穷，所谓负无穷就是只要有其他节点可运行就绝不在B节点上运行；通过定义资源对节点的倾向性，从而来限制资源在那些节点上进行转移；这种限制资源对节点的倾向性我们叫做定义资源的故障转移域；除了能够定义资源对节点的倾向性，我们还可以定义资源与资源的倾向性，其逻辑都是相似的；对于资源倾向性通常我们会用分数来表示，其取值范围是正无穷到负无穷；正无穷表示无限喜欢到某个节点或资源，只要对应节点正常存在就一定在该节点上，负无穷相反；
8、资源代理
在corosync+pacemaker集群上，资源代理是指是能够帮助我们去启动一个资源的脚本或程序；对于不同的资源代理，用到的脚本或程序不同；对于不同的资源在不同的系统，资源代理的类型也有所不同，比如在centos6上，各服务的启动脚本通常在/etc/init.d/下，所以通常会把/etc/init.d/目录下的各脚本当作资源代理的脚本；这种资源类型叫做LSB的资源类型，通常这些脚本都支持start|stop|restart|status等等参数；对于LSB类型的资源代理，前提是代理的资源一定不能开机启动，如果开机启动对于托管corosync+pacemaker就无意义了，所以资源的启动一定要交给corosync+pacemaker来管理不能开机启动；对于centos7来说，它使用的是systemd方式来管理各服务的启动，停止；它默认的存放unit file的路径是/usr/lib/systemd/system/目录下；而对于systemd类型的资源代理，我们一定要把托管为集群的服务 enable起来，可以理解为corosync+pacemaker它会到/etc/systemd/system/目录下对应资源启动脚本；而只有把对应服务enable起来以后，它才会在/etc/systemd/system/目录下存在；除了以上两种资源代理还有OCF和stonith，OCF类型资源代理类似LSB脚本，当支持start,stop,status,monitor,mata-data等参数；stonith类型的资源代理专用配置stonith设备RA；service类型，以上4种都不符合的其他类型的资源代理；
9、corosync+pacemaker的安装配置
前提：
1、各host时间同步；
2、各hosts文件能够解析其他节点的主机名；选择一个不和其他集群冲突的多播地址；
3、有需要可配置各节点ssh互信；
| 主机名 | ip地址 | 多播地址 |
| node01 | 192.168.0.41 | 239.255.100.12 |
| node02 | 192.168.0.42 | 239.255.100.12 |
验证：各主机上的时间和主机名以及hosts文件；
提示：我这里以两主机演示特殊的两节点集群；node01和node02都把时间服务器地址指向内网192.168.0.99这个时间服务器上；有关时间服务器的配置请参考https://www.cnblogs.com/qiuhom-1874/p/12079927.html；有关ssh互信配置可以参考https://www.cnblogs.com/qiuhom-1874/p/11783371.html；
配置好时间同步和ssh互信以及host主机名解析以后，接下来安装pacemaker
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 |
|
提示：安装pacemaker会依赖corosync这个包，所以直接安装pacemaker这一个包就可以了；对于node02也是同样的操作；
配置corosync
查看corosync的程序环境
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
|
提示：/etc/corosync这个目录用来存放corosync配置文件；其中corosync.conf.example是corosync的文本格式配置文件示例；corosync.conf.example.udpu这个是corosync使用udpu方式提供服务的配置文件示例；corosync.xml.example是xml格式的配置文件示例；/usr/lib/systemd/system/corosync.service这个是corosync unit file文件；/usr/sbin/corosync二进制程序文件；/usr/sbin/corosync-keygen这个工具用于生成corosync的密钥文件；/var/lib/corosync这个目录主要存放CIB数据库文件；/var/log/cluster/目录用于存放日志相关文件；
复制/etc/corosync/corosync.conf.example文件为/etc/corosync.conf
|
1 |
|
编辑配置文件
提示：对于totem这个配置段主要用于配置totem协议的相关属性，其中version表示使用的版本，默认是2这个不用更改，保持默认就好；下面的crypto_cipher和crypto_hash这两项用于配置是否启用加密，这里默认是none，这意味这只要是在相同多播域内，它都会识别成集群成员；所以为了安全建议启用集群事务消息通信加密；默认情况crypto_cipher支持aes256, aes192, aes128 and 3des这些加密算法，随便配置一个加密算法即可；crypto_hash支持md5, sha1, sha256, sha384，sha512这些加密算法，随便选一个即可；如果启用以上两项加密，我们需要在/etc/corosync/目录下创建一个密钥文件，且权限是600或着400的权限；并且集群各节点的密钥文件必须相同；
创建密钥文件
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
提示：可以现在把密钥文件复制给node02也可以待会把配置文件配置好以后一并复制给node02都行；
继续编辑配置文件
提示：interface配置段主要用于定义集群事务信息通信接口相关参数；其中ringnumber: 0表示第一块网卡，如果有第二卡和第三块，可以在totem配置段继续用interface配置段来指定；bindnetaddr: 192.168.0.0用于配置用于集群事务信息通信的网络地址，它默认会根据我们配置的网络地址去本地主机上找对应的网卡；当然我们也可以配置ip地址也行，通常建议使用网络地址；mcastaddr：是用来指定多播通信地址；这个如果在实验环境中可以不用该，只要在集群中的各节点都是同一个多播地址即可；在生产中一定要注意不能和其他集群的多播通信地址冲突；mcastport用于指定多播通信的端口，默认是5405，这个通常不需要更改，保持默认即可；ttl: 1这个是配置多播通信的报文生存时长，默认配置为1，是为了防止其他节点收到多播报文后再次转发；
提示：logging配置段主要用于定义日志相关；其中fileline: off表示不开启fileline；所谓fileline就是记录源文件和消息所在的行； to_stderr: no表示不把日志输出到标准错误控制台；to_logfile: yes表示把日志输出到文件；logfile: /var/log/cluster/corosync.log用于指定日志文件路径； to_syslog: yes是否将日志发送给syslog，默认是允许；debug: off是否关闭调试信息；默认是关闭的；timestamp: on是否加上时间戳，默认是开启；如果我们只玩syslog中发送日志，可以将这一项关闭，因为syslog会自动将时间给我们补上；logger_subsys用于定义日志子系统，subsys指子系统的名称，debug指定是否开启调试信息；上面的subsys: QUORUM 表示开启记录quorum的日志信息；
提示：quorum用于配置投票系统相关配置，这里面默认是注释了，我们只需要打开provider： corosync_votequorum即可；
提示：nodelist这段配置在默认的配置文件中没有，我们加上这段配置就是告诉corosync我们期望的集群中的节点有两个，他们的ip地址是那些；这里的ip地址可以写主机名，也可以写ip地址，建议使用主机名；
复制/etc/corosync/corosync.conf 和authkey文件到其他节点
启动corosync
提示：如果启动corosync服务以后，能够看到udp的5405端口和5404端口处于监听状态和我们配置的多播地址，则说明corosync服务就配置好了；
验证：查看corosync的日志，看看是否识别到两个节点
提示：在node01上可以看到对应的集群成员有2个；
提示：在node02的日志文件中也能看到node01加入到集群，对应集群成员有两个；
验证：使用corosync-cfgtool命令来查看当前节点的初始化信息
提示：-s表示查看当前节点ring上的状态信息；从上面的信息可以看到node01上节点id为1，ring0上的id为192.168.0.41，状态是活跃没有发现错误；
提示：同样在node02上使用corosync-cfgtool -s 可以看到当前node02上的ring0的状态信息；从上面的截图可以看到两个节点都已经处于活跃状态；
验证：使用corosync-cmaptools查看成员
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 |
|
提示：默认不跟任何选项表示打印当前CIB中保存的配置内容；
提示：通过grep过滤，可以看到有两个成员，他们的ip地址分别是192.168.0.41和42；到此corosync就配置并启动成功了；
完整的corosync.conf配置文件内容
View Code
启动pacamaker服务
提示：pacemaker默认不需要怎么配置就可以启动，启动以后，我们可以通过管理接口来配置；默认才开始启动pacemaker时都会有一个pengine的进程启动，但是通常只有DC上的pengine才会生效；
验证：查看DC节点所在节点/集群状态信息
提示：在集群任何一个几点执行crm_mon就可以看到当前集群的状态信息；上面截图中可以看到node01.test.org是dc节点，在线的节点有两个，分别是node01.test.org和node02.test.org；
到此corosync+pacemaker高可用集群就搭建好了，后续我们就直接可以在上面托管服务；
pacemaker corosync 概念相关推荐
- Pacemaker,Corosync和PCS搭建高可用性负载均衡linux 集群(httpd)
Pacemaker,Corosync和PCS搭建高可用性负载均衡linux 集群(httpd) 一.高可用性的概念: 1.一种机制来定义哪些系统可以被用作集群节点 2.哪些服务或者应用可以在节点间作失 ...
- Pacemaker+Corosync PostgreSQL流复制HA的部署(pha4pgsql)
简介 在众多的PostgreSQL HA方案中,流复制HA方案是性能,可靠性,部署成本等方面都比较好的,也是目前被普遍采用的方案.而用于管理流复制集群的工具中,Pacemaker+Corosync又是 ...
- pacemaker+corosync
Pacemaker Server1 172.25.23.1节点1 Server2 172.25.23.2节点2 Server3 172.25.23.3做存储分离的 VIP 172.25.23.100 ...
- pacemaker+corosync 搭建一主两从PG集群
一.OS配置 1.1环境规划 环境:centos 7 数据库:pg11.5 ip地址: node1 10.122.166.120 node2 10.122.166.127 node3 10. ...
- pacemaker+corosync+pg13
pacemaker+corosync+pg13的搭建大体内容可以参考上一篇的pacemaker+corosync+pg11的搭建,对于pg13的或者说是pg12以及以上版本,需要更新resource- ...
- pacemaker +corosync
pacemaker是一个集群资源管理器.利用集群基础构件(OpenAIS,heartbeat和corosync)提供的消息和成员管理能力来探测并从节点或者资源级别的故障中恢复,以实现集群服务的最大可用 ...
- Pacemaker+Corosync+Mfs+Iscsi+Fence实现高可用和Fence管理
前言: 分布式文件系统(DIstributed File System) 时值文件系统管理的物理存储资源不一定直接连接在本地 的节点上,而是通过计算机网络与节点相连,简单的来讲,就是把一些分散 ...
- 【PostgreSQL基于Pacemaker+Corosync+pcs的高可用】
地址信息 172.20.10.6 pg01 172.20.10.7 pg02 172.20.10.8 pg03 172.20.10.9 vip-master 172.20.10.10 vip-slav ...
- NFS HA架构部署(NFS + Pacemaker + Corosync + DRBD)
NFS HA架构部署(NFS + Pacemaker + Corosync + DRBD) 环境:kvm虚拟机2台 OS:CentOS7.6 Kernel: Linux 3.10.0-957.21.3 ...
最新文章
- MySQL登陆时加-U选项
- 入门视频采集与处理（学会分析YUV数据）
- [云炬python3玩转机器学习] 5-9 scikit-learn中的回归问题
- 支持html5特性的浏览器,HTML 5浏览器的支持情况
- PreparedStatement批量处理的一个Framework(原创)
- 一次“内存泄露”引发的血案
- 机器学习第一篇：开篇
- php v9 如何获取超级管理员权限,Windows8.1如何获取超级管理员权限
- 记录一次，事务遇到消息发送，疏忽给自己挖坑
- 《Shell脚本学习指南》学习笔记
- 用极大似然法估计因子载荷矩阵_spss教程：因子分析
- Qt Designer位置
- 数据分析师面试题目_数据分析师常见的10道面试题解答
- python植物大战僵尸脚本_用Python实现植物大战僵尸游戏，很酷
- img标签渲染图片流
- 安利3个高清电脑壁纸网站
- 文献阅读-GNC----IEEE Robotics and Automation Letters (RA-L), 2020.
- delphi异步与javascript
- 诸葛——如何摆脱APP速死症？
- 【国际象棋】棋盘游戏-微信小程序开发流程详解