【003】集群学习笔记-高可用集群-keepalived（含实验）

最新推荐文章于 2024-05-21 20:08:58 发布
最新推荐文章于 2024-05-21 20:08:58 发布
阅读量1.2k 收藏
点赞数
分类专栏： Linux 集群学习笔记 文章标签： 学习 java linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/DeusExMachina_V/article/details/125181502
版权

【003】集群学习笔记-高可用集群-keepalived

1 高可用集群

  1. 高可用集群(High Availability Cluster)

    集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。每一个单个的计算机系统都叫集群节点(node)。随着业务的增长,集群通过添加新的节点,满足资源的高可扩展性。

    计算机硬件和软件易错性不可避免,这样在节点上的服务会不可避免的中断。高可用集群的出现是为保证即使节点失效,而服务能不中断。

    高可用集群在一组计算机中,采用主备模式,主节点提供服务,备节点等待；一旦主节点失效,备节点无需人工的无缝取代主节点提供服务,这样保证了服务的不中断。

    高可用集群软件的主要作用就是实现故障检查和业务切换的自动化,以提供不中断的服务。

  2. 高可用集群(HA)的衡量标准

    高可用性集群是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。

    通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均维修时间(MTTR)来度量系统的可维护性。
    HA=MTTF/(MTTF+MTTR)*100%

      HA衡量标准:
      ◇ 99% 一年宕机时间不超过4天
      ◇ 99.9% 一年宕机时间不超过10小时
      ◇ 99.99% 一年宕机时间不超过1小时
      ◇ 99.999% 一年宕机时间不超过6分钟

  3. 高可用集群的层次结构
    在这里插入图片描述

1).信息层(Messaging)
也叫底层基础架构层,主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。
心跳信息：集群中每一台服务器都不停的将自己在线的信息通告给集群中的其他主机。
心跳信息的传递是基于套接字通信的,通过软件提供服务监听套接字,实现数据发送、请求。必须安装软件,并开启服务,这是实现高可用集群的基础。

2).成员层(Membership)
这层最重要的作用是通过Cluster Consensus Membership Service(CCM)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。
CCM 组件(Cluster Consensus Menbership Service)：承上启下,监听底层接受的心跳信息,当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息,并将结果转递给上层,让上层做出决定采取怎样的措施。CCM 还能够生成一个各节点状态的拓扑结构概览图,以本节点做为视角,保证该节点在特殊情况下能够采取对应的动作。
Messaging & Membership一般由同一软件实现。

3).资源分配层(Resource Allocation)
也叫资源管理器层,真正实现集群服务的层。包含CRM(集群资源管理器,cluster Resource Manager),CIB(集群信息基库,Cluster Infonation Base),PE(策略引擎,Policy Engine),TE(实施引擎,Transition Engine), LRM(Local Resource Manager,本地资源管理器)。
CRM组件： 核心组件,实现资源的分配和管理。每个节点上的CRM都维护一个CIB用来定义资源特定的属性,哪些资源定义在同一个节点上。主节点上的CRM被选举为 DC(Designated Coordinator指定协调员,主节点挂掉会选出新的DC),成为管理者,它的工作是决策和管理集群中的所有资源。
任何DC上会额外运行两个进程,一个叫PE,；一个叫TE。
PE ：定义资源转移的一整套转移方式,但只做策略,并不亲自来参加资源转移的过程,而是让TE来执行自己的策略。
TE : 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。
CIB组件 ：XML格式的配置文件,工作的时候常驻内存,只有DC才能对CIB进行修改,其他节点上的复制DC上的CIB而来。集群的所有信息都会反馈在CIB中。
**LRM组件：**是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。

资源：
在集群中构成一个完整服务的每一部分都叫资源,都需要配置和管理。
以web应用为例：vip是资源,web服务器是资源,存储也是资源。不同的服务的资源也不尽相同,其中存储资源的选择、配置、管理是高可用集群中的难点问题。

4).资源代理层(Resource Agents)
集群资源代理,能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本,资源代理分为：LSB(/etc/init.d/*),OCF(比LSB更专业,更加通用)。
任何资源代理都要使用同一种风格,接收四个参数：{start|stop|restart|status},每个种资源的代理都要完成这四个参数据的输出。

工作机制：
PE 根据CIB获取资源的配置信息(集群上的所有信息都会收集到DC的CIB,同步到其它节点),而后做出决策,一旦做得决策就会进行资源的管理。PE借助于本地的CCM通知给其它节点CIB来实现对某些资源管理信息的传递,比如说通告其它CRM要启动某一资源了,收到信息后CRM并不负责启动,转由 LRM(Local Resource Manager本地资源管理)启动,而并发资源又借助于RA(Resource Agent资源代理)实现资源管理。

  1. 高可用集群软件

Messaging and Membership Layer(信息与关系层)：
• heartbeat (v1,v2,v3)
• corosync
• cman
• keepalived
• ultramokey
Cluster Resource Manager Layer(资源管理层,简称:CRM)：
• haresource,crm (heartbeat v1/v2)
• pacemaker (heartbeat v3/corosync)
• rgmanager (cman)

常用组合：

• heartbeat v2+haresource(或crm) (一般常用于CentOS 5.X)
• heartbeat v3+pacemaker (一般常用于CentOS 6.X)
• corosync+pacemaker (现在最常用的组合)
• cman + rgmanager (红帽集群套件中的组件,还包括gfs2,clvm)
• keepalived+lvs (常用于lvs的高可用)

  1. 补充
    STONITH(Shoot The Other Node in the Head,“爆头”)组件
    这种机制直接操作电源开关,控制故障节点的电源开关,通过暂时断电又上电的方式,使故障节点重启,这种方式需要硬件支持。
    主节点在某一段时间由于某种原因,没传递心跳信息,这个时候集群会选取新的DC,重新分配资源提供服务,如果主节点服务器还没有宕掉,这样就会导致服务器分隔、资源争用,这种情况被称为脑裂(brain-split)。此时,用户能访问,一旦有写的操作,就会导致文件系统崩溃,损失惨重。为避免这种 情况,新的DC一旦产生,第一时间对主节点执行stonith,这种操作叫做资源隔离。

在这里插入图片描述

资源隔离
节点级别：这种就叫STONITH,直接把对方的电源给切断,一般这种主机都是连接到电源交换机上的。
资源级别：同样需要依赖一些硬件设备来完成。比如节点通过光纤交换机连接到共享存储,通过把需要踢除出去的节点的光纤接口屏蔽来实现资源隔离。

仲裁设备
ping node：两个节点的模式下,一旦其中一个节点发生故障,发生集群分隔以后,无法判定哪个节点不正常,但工作正常的节点一定是可以连到互联网,故正常的节点是可以跟前端路由通信,所以可以把前端路由当成第三个节点,如果可以ping通,那就说明自己是正常的,可以将对方隔离掉。
qdisk: RHCS不是使用ping节点来判断,而是使用一个共享存储的设备,节点按照心跳信息频率每隔一个信息频率时间就往磁盘里写一个数据位,如果设备每隔一个心跳时间间隔就更新一次数据位,就说明这个设备处于活动状态的,可以将对方隔离掉。

2 keepalived

2.1 工作原理

keepalived是集群管理中保证集群高可用的一个服务软件,其功能类似于heartbeat,用来防止单点故障。

工作原理
keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。

VRRP（虚拟路由冗余协议）,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。

keepalived主要有三个模块,分别是core、check和vrrp。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查,包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。

keepalived+LVS
Keepalived 是一个基于VRRP协议来实现的LVS高可用方案,可以利用其来避免单点故障。一个LVS会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候, 备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。

master通过 224.0.0.18 发送组播信息

2.2 keepalived + LVS/DR实验

实验原理
在这里插入图片描述

  1. 根据上图准备以下五台机器
    在这里插入图片描述
  2. 在webserver1 webserver2 上同时执行DR配置，原理见我上一篇博文【002】集群学习笔记-LVS-NAT，LVS-DR，持久性连接（实验）
ifconfig lo:0 192.168.23.100 netmask 255.255.255.255
echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/all/arp_announce

不要忘了开启httpd并且
echo web1 /var/www/html/index.html
echo web2 /var/www/html/index.html

  1. 在lvs配置
[root@lvs ~]# ipvsadm -A -t 192.168.23.100:80 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.23.100:80 -r 192.168.23.13:80
[root@lvs ~]# ipvsadm -a -t 192.168.23.100:80 -r 192.168.23.14:80
  1. 从client端curl验证lvs实现DR配置成功

在这里插入图片描述
5. 在lvs与directorbackup端安装keepalived

yum -y install keepalived

在这里插入图片描述

  1. 在lvs端更改配置文件
[root@lvs ~]# vim /etc/keepalived/keepalived.conf

做出如下更改：
在这里插入图片描述

# vrrp_strict 否则vip漂移后自动生成一条drop规则

参数解释：
interface eth0			                        //内网网卡，用于发送或接收vrrp信息的网卡	
virtual_router_id 51		                    //两边必须一样	
priority 100		                                //优先级			
advert_int 1				                        //检查间隔,单位秒

更改virtual_server的ip与端口将后面所有删除real_server，并添加webserver1 webserver2
记得

virtual_server 192.168.23.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    persistence_timeout 50
    protocol TCP

    real_server 192.168.23.13 80 {
        weight 1
        TCP_CHECK {
                connect_timeout 3
        }
        }

    real_server 192.168.23.14 80 {
        weight 1
        TCP_CHECK {
                connect_timeout 3
        }
        }
}

	delay_loop 3                                            // 服务论询的时间间隔  
    lb_algo rr							                     // LVS 调度算法
    lb_kind DR							                     // LVS 集群模式
  1. 结束配置文件，用scp将该配置文件拷贝到directorbackup
[root@lvs ~]# scp /etc/keepalived/keepalived.conf 192.168.23.12:/etc/keepalived
  1. 在directorbackup端的优先级更改为90

在这里插入图片描述

  1. 在lvs 与 directorbackup 端开启keepalived服务
systemctl start keepalived.service
systemctl status keepalived.service #查看是否启动

你绿了，但你成功了
在这里插入图片描述
10. 查看ip 发现ens33网卡下多了192.168.23.100

ip a
ifdown ens36

在这里插入图片描述
11. 用client端使用curl验证发现配置成功
在这里插入图片描述

  1. 在directorbackup端安装tcpdump并抓包查看
yum -y install tcpdump
tcpdump -i any -nnvvv vrrp

在这里插入图片描述
从上图我们发现是lvs端向组播地址224.0.0.18发的包，其priority 是100
13. 关闭lvs端的keepalived

[root@lvs ~]# systemctl stop keepalived.service

我们发现之前lvs的虚拟服务器ip（192.168.23.100）消失了
在这里插入图片描述
但我们从client端再次curl去验证，发现负载均衡不受影响
在这里插入图片描述
同时，在directorbackup端的抓包信息我们也看到从lvs变成了directorbackup
在这里插入图片描述

如果我们再次打开lvs端的keepalived

我们发现vip被抢为lvs的vip
在这里插入图片描述
为了避免以上情况，我们可以在lvs与directorbackup配置文件中添加
在这里插入图片描述

  • 为什么两个keepalived 都设置为backup 而不是一master一backup
    防止脑裂，反正最后priority决定谁是master

2.3 keepalived + scripts

工作原理
keepalived通过脚本的执行结果来提高或降低自身的优先级完成VIP的切换

  1. 在lvs端打开配置文件
# vim /etc/keepalived/keepalived.conf
  1. 在途中位置添加以下内容，其中 track_script 要放入vrrp_instance VI_1 里面
    在这里插入图片描述3. 在上述配置文件指定的目录中写如下脚本
[root@lvs ~]# vim /tmp/check.sh

#!/bin/bash
[ -f "/tmp/ok" ]
  1. 更改配置文件
# vim /etc/keepalived/keepalived.conf

在这里插入图片描述

[root@lvs ~]# chmod +x /tmp/check.sh
  1. 继续查看directorbackup抓包，发现
    在这里插入图片描述
    同时我们看到VIP已经漂移到directorbackup
    在这里插入图片描述
  2. 我们在lvs端创建文件/tmp/ok，发现脚本被激活，VIP漂移回lvs端
    在这里插入图片描述
    如果我们删除/tmp/ok,我们发现VIP又漂移回去directorbackup了

2.4 实战keepalived实现Nginx高可用

(待完成)

如果脚本执行结果为0,并且weight配置的值大于0,则优先级相应的增加 backup
如果脚本执行结果非0,并且weight配置的值小于0,则优先级相应的减少 master
其他情况,原本配置的优先级不变,即配置文件中priority对应的值。

优先级增加: 脚本成功执行 && weight的值为正值
优先级降低: 脚本失败执行 && weight的值为负值

优先级不会不断的提高或者降低
可以编写多个检测脚本并为每个检测脚本设置不同的weight(在配置中列出就行)
不管提高优先级还是降低优先级,最终优先级的范围是在[1,254],不会出现优先级小于等于0或者优先级大于等于255的情况

问题及建议:

  1. selinux开启会影响脚本的执行结果, 进而影响优先级
  2. VIP漂移会造成短时间的服务不可用, 应尽量减少(可设置不抢占)
  3. 脚本中可采用关服务的方式实现VIP漂移, 可靠性较高, 但无法实现不抢占
  4. 可在MASTER上采用降低优先级的方式让VIP漂移, 并设置不抢占, 以减少服务不可用时间
  5. 可在原BACKUP上采用关闭服务的方式实现VIP漂移回原MASTER

2.4 VRRP详解

VRRP 协议简介
在现实的网络环境中,两台需要通信的主机大多数情况下并没有直接的物理连接。对于这样的情况,它们之间路由怎样选择？主机如何选定到达目的主机的下一跳路由,这个问题通常的解决方法有二种：
• 在主机上使用动态路由协议(RIP、OSPF等)
• 在主机上配置静态路由

很明显,某些环境下在主机上配置动态路由是非常不切实际的,因为管理、维护成本以及是否支持等诸多问题。配置静态路由就变得十分流行,但路由器(或者说默认网关 default gateway)却经常成为单点故障。VRRP的目的就是为了解决静态路由单点故障问题,VRRP通过一竞选(election)协议来动态的将路由任务 交给LAN中虚拟路由器中的某台VRRP路由器。

VRRP 工作机制
在一个VRRP虚拟路由器中,有多台物理的VRRP路由器,但是这多台的物理的机器并不能同时工作,而是由一台称为MASTER的负责路由工作,其它的 都是BACKUP,MASTER并非一成不变,VRRP让每个VRRP路由器参与竞选,最终获胜的就是MASTER。MASTER拥有一些特权,比如,拥 有虚拟路由器的IP地址,我们的主机就是用这个IP地址作为静态路由的。拥有特权的MASTER要负责转发发送给网关地址的包和响应ARP请求。
VRRP通过竞选协议来实现虚拟路由器的功能,所有的协议报文都是通过IP多播(multicast)包(多播地址224.0.0.18)形式发送的。 虚拟路由器由VRID(范围0-255)和一组IP地址组成,对外表现为一个周知的MAC地址。所以,在一个虚拟路由器中,不管谁是MASTER,对外都是相同的MAC和IP(称之为VIP)。客户端主机并不需要因为MASTER的改变而修改自己的路由配置,对客户端来 说,这种主从的切换是透明的。
在一个虚拟路由器中,只有作为MASTER的VRRP路由器会一直发送VRRP通告信息(VRRPAdvertisement message),BACKUP不会抢占MASTER,除非它的优先级(priority)更高。当MASTER不可用时(BACKUP收不到通告信 息), 多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s),以保证服务的连续性。由于安全性考虑,VRRP包使 用了加密协议进行加密。

VRRP 工作流程
(1).初始化：
路 由器启动时,如果路由器的优先级是255(最高优先级,路由器拥有路由器地址),要发送VRRP通告信息,并发送广播ARP信息通告路由器IP地址对应的 MAC地址为路由虚拟MAC,设置通告信息定时器准备定时发送VRRP通告信息,转为MASTER状态；否则进入BACKUP状态,设置定时器检查定时检 查是否收到MASTER的通告信息。

(2).Master
• 设置定时通告定时器；
• 用VRRP虚拟MAC地址响应路由器IP地址的ARP请求；
• 转发目的MAC是VRRP虚拟MAC的数据包；
• 如果是虚拟路由器IP的拥有者,将接受目的地址是虚拟路由器IP的数据包,否则丢弃；
• 当收到shutdown的事件时删除定时通告定时器,发送优先权级为0的通告包,转初始化状态；
• 如果定时通告定时器超时时,发送VRRP通告信息；
• 收到VRRP通告信息时,如果优先权为0,发送VRRP通告信息；否则判断数据的优先级是否高于本机,或相等而且实际IP地址大于本地实际IP,设置定时通告定时器,复位主机超时定时器,转BACKUP状态；否则的话,丢弃该通告包；

(3).Backup
• 设置主机超时定时器；
• 不能响应针对虚拟路由器IP的ARP请求信息；
• 丢弃所有目的MAC地址是虚拟路由器MAC地址的数据包；
• 不接受目的是虚拟路由器IP的所有数据包；
• 当收到shutdown的事件时删除主机超时定时器,转初始化状态；
• 主机超时定时器超时的时候,发送VRRP通告信息,广播ARP地址信息,转MASTER状态；
• 收到VRRP通告信息时,如果优先权为0,表示进入MASTER选举；否则判断数据的优先级是否高于本机,如果高的话承认MASTER有效,复位主机超时定时器；否则的话,丢弃该通告包；

ARP查询处理
当内部主机通过ARP查询虚拟路由器IP地址对应的MAC地址时,MASTER路由器回复的MAC地址为虚拟的VRRP的MAC地址,而不是实际网卡的 MAC地址,这样在路由器切换时让内网机器觉察不到；而在路由器重新启动时,不能主动发送本机网卡的实际MAC地址。如果虚拟路由器开启的ARP代理 (proxy_arp)功能,代理的ARP回应也回应VRRP虚拟MAC地址

3 Reference

keepalived官方文档 http://www.keepalived.org/
HA cluster原理 by SRE1 https://blog.51cto.com/hoolee/1406951

DeusExMachina_V
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
OpenStack-Rocky高可用集群部署.rar
03-19
本资料主要关注如何在OpenStack Rocky环境下构建高可用（HA）集群，确保关键服务的持续运行和数据的可靠性。 一、OpenStack高可用性概述 在OpenStack环境中实现高可用性意味着确保所有组件在单个节点故障时仍能正常...
部署一套完整的K8s高可用集群（kubeadm-V1.21）
05-09
Kubernetes 集群高可用性考虑两个层面： 1. Etcd 数据库的高可用性：Etcd 是 Kubernetes 集群的核心组件之一，负责存储集群的状态信息，高可用性可以通过搭建多个 Etcd 节点来实现。 2. Kubernetes Master 组件的高...
又拍云之 Keepalived 高可用部署
github_36774378的博客
11-10 1091
Keepalived 是什么，它一款基于 VRRP 协议的高可用软件，借助它可以让多台服务器能像路由器一样做 VIP 虚拟地址的冗余转移，从而提升后端服务器的高可靠性。
Nginx+Keepalived+LVS高可用集群----相关知识回顾
企业实战系列集 ●●● https://ximenjianxue.blog.csdn.net
09-06 4749
1、原理回顾 1.1、集群知识回顾 集群特点： 1）高性能performance。 一些需要很强的运算处理能力比如天气预报，核试验等。这需要上千台计算器协同来完成这个工作的，共同分担计算任务。 2）价格相对便宜且可集中管理： 通常一套系统集群架构，只需要几台或数十台服务器主机即可，且这些计算机的性能实际使用中也不必太高，甚至可利旧老式的服务器，与动则上百王的专用超级计算机具有更高的性价比。 3）弹...
keepalived实现服务高可用原理详解
最新发布
LoveSummer
05-21 994
router_id 信息不一致state 状态描述信息不一致priority 主备竞选优先级数值不一致。
keepalived群集部署
qq_60654159的博客
11-26 2650
Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。
Linux集群高可用之Keepalived 原理 实操~
weixin_43612076的博客
04-12 827
keepalived高可用 简介原理,以及相关实验步骤学习~
packmaker+corosync 构建HA (LSB服务)
qq249121208的博客
05-17 333
安装 启动 service corosync start service packmaker start 实时监控 crm_mon 查看可监控LBS服务 crm ra list lsb 没有 mysql 服务怎么办 service mysql status mv mysqld.service /etc/rc.d/init.d/mysql chmod a+x /etc/rc.d/init.d/mysql 能监控的必须在/etc/rc.d/init.d 路径下有可执行文件,且有x权限 进入crm命令行
Nginx 配置高可用的集群安装文件keepalived
12-27
完成高可用配置（主从配置文件），有兴趣的免费提供下载参考。
MariaDB+Keepalived双主高可用配置MySQL-HA
01-30
利用keepalived构建高可用MySQL-HA，保证两台MySQL数据的一致性，然后用keepalived实现虚拟VIP，通过keepalived自带的服务监控功能来实现MySQL故障时自动切换。硬件拓扑如下：操作系统：CentOSrelease6.3（32位）...
Keepalived 特性实验
LCK 博客
06-21 586
一、单主架构 架构拓扑 实验环境： keepalived服务器1：10.0.0.11 keepalived服务器2：10.0.0.12 keepalived服务器1配置 global_defs { router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0 } vrrp_instance ro...
keepalived 多节点设置
会哭的雨@的博客
03-05 944
eepalived 多节点设置 目的： 进一步提高keepalived 可用性 设计：有3台keepalived 服务器 192.168.1.106 192.168.1.107 192.168.1.108。vip 是192.168.1.249 效果：只要有一台keepalive 运行正常。vip 就可以访问 server hostname ip keepalived z6 192.168.1.106 keepalived z7 192.168.1.107 keepa...
LVS-KEEPALIVED 简单了解及实验案例
Laiyunpeng666的博客
09-23 598
1、什么是Keepalived？ Keepalived是用C语言编写的路由软件。该项目的主要目标是为Linux系统和基于Linux的基础结构提供负载均衡和高可用性的简单而强大的功能。负载平衡框架依赖于提供第4层负载平衡的著名且广泛使用的Linux虚拟服务器（IPVS）内核模块。Keepalived实现了一组VIP功能，以根据其运行状况动态，自适应地维护和管理负载平衡的服务器池。另一方面，VRRP实现了高可用性 协议。VRRP是路由器故障转移的基础。 此外，Keepalived还实现了一组VRRP有限状态机的
Keepalived高可用服务搭建
qq_27546717的博客
06-07 1726
前情提要 Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（如Nginx、Haproxy、My-SQL等）的高可用解决方案软件 Keepalived软件主要是通过VRRP协议实现高可用功能的，VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议） Keepalived服务的3个重要功能： 1
centos7高可用热备
hhhh2012的专栏
09-09 6450
使用pcs shell配置corosync & pacemaker群集 Pacemaker Pacemaker，即Cluster Resource Manager（CRM），管理整个HA，客户端通过pacemaker管理监控整个集群。 CRM支持ocf和lsb两种资源类型： ocf格式的启动脚本在/usr/lib/ocf/resource.d/下面。 lsb的脚本一般在/
高可用集群之keepalived
liangpangpangyo的博客
04-11 972
高可用集群之keepalived前言一、keepalived脑裂1、keepalived脑裂2、解决方案二、keepalived1、介绍2、工作原理3、VRRP协议4、核心三模块三、keepalived使用1、keepalived+nginx集群部署2、keepalived+lvs集群部署3、keepalived+lvs双主集群部署 前言 高可用集群（HA）都面临脑裂的问题。作为一个整体相互配合的系统，由于失去联系，各自认为对方为故障节点，从而分裂为两个单独的系统。脑裂节点会争抢资源，导致系统混乱，数据
Openwrt 下实现主备路由自动切换 -- keepalived
热门推荐
bingyu的博客
04-07 1万+
Openwrt 下实现主备路由自动切换 – keepalived目前，一个项目中用到了H3C的设备，组网中使用了VRRP功能，实现主备路由的自动切换。经过查阅资料，发现openwrt中也支持类似的功能 — keepalived。参考链接：http://www.keepalived.org/最新的版本为V1.3.5，而我现有openwrt中的版本是V1.2.15。
Keepalived集群快速入门
果子哥丶的博客
10-24 860
Keepalived 是一种高性能的服务器高可用或热备解决方案， Keepalived 可以用来防止服务器单点故障的发生，通过配合 Nginx 可以实现 web 前端服务的高可用。 Keepalived 以 VRRP 协议为实现基础，用 VRRP 协议来实现高可用性(HA)。
RHCS-HA高可用Web集群配置：Keepalived详解与关键概念
RHCS-HA高可用的web集群配置主要是关于如何通过Keepalived实现Linux集群的高可用性和容错性设计。在IT领域，高可用性(High Availability, HA)是一种确保系统持续运行并提供不间断服务的技术，尤其对于Web集群这类...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值