【运维知识进阶篇】集群架构-Nginx高可用Keepalived

简介: 【运维知识进阶篇】集群架构-Nginx高可用Keepalived

高可用是指2台机器启动着完全相同的业务系统,一台机器宕机后,另一台可以快速启用,用户是无感知的。高可用硬件通常使用F5,软件通常使用keepalived。keepalived软件是基于VRRP协议实现的,VRRP虚拟路由冗余协议,主要用于解决单点故障。

VRRP实现原理

咱们拿公司路由器举例,路由器故障后,网关无法转发报文,所有人无法上网了怎么办?

一般我们会选择增加一台路由器,但是我们主路由器故障后,用户需要手动指向备用路由器,如果用户多的话修改起来会非常麻烦,另外我们的主路由器修好后,主路由器用不用;主路由器故障后我们把备用路由器的网关配置改成主路由器是否可以,等等,涉及问题很多。

实际上,我们如果单纯上修改网关配置,是行不通的,我们的PC第一次通过ARP广播寻找到主路由器的MAC地址和IP地址,会将信息写到ARP的缓存表,那么PC在之后的连接中都是根据缓存表信息去连接,在进行数据包转发,即使我们修改了IP,但是Mac地址是唯一的,PC的数据包依旧会发给主路由器(除非PC的ARP缓存表过期,再次发起ARP广播的时候才能获取新的备用路由器的MAC的地址和IP地址)

那么我们就需要VRRP了,通过软件或硬件的形式在主路由器和副路由器外面增加一个虚拟的MAC地址(VMAC)和虚拟IP地址(VIP),那么在这种情况下,PC请求VIP的时候,不管是主路由器处理还是备用路由器处理,PC只是在ARP缓存表中记录VMAC和VIP的信息。

Keepalived核心概念

要掌握Keepalived之前,我们需要先知道它的核心概念。

1、如何确定谁是主节点谁是备用节点(谁的效率高,速度快就用谁,类似选举投票;手动干预是通过优先级的方式)

2、如果主节点故障,备用节点自动接管,如果主节点恢复了,那么抢占式的方式主节点会自动接管,类似于夺权,而非抢占式的方式,主节点恢复了,并不会自动接管。

3、主节点和备用节点在1个小组,主节点正常时,1秒钟向小组内发送一次心跳(时间可以自定义),表示它还正常,如果没有发送心跳,则备用节点自动接管,如果主节点和备用节点都没发送心跳,则两台服务器都会认为自己是主节点,从而形成脑裂

Keepalived安装配置

1、我们准备一台LB01(10.0.0.5)和一台LB02(10.0.0.6)两台虚拟主机

2、两台主机都安装keepalived

1. [root@LB01 ~]# yum -y install keepalived
2. 
3. [root@LB02 ~]# yum -y install keepalived

3、配置LB01

1. [root@LB01 ~]# rpm -qc keepalived    #查询keepalived的配置文件
2. /etc/keepalived/keepalived.conf
3. /etc/sysconfig/keepalived
4. [root@LB01 ~]# cat /etc/keepalived/keepalived.conf
5. global_defs {                   #全局配置
6.     router_id LB01              #标识身份->名称
7. }
8. 
9. vrrp_instance VI_1 {
10.     state MASTER                #标识角色状态
11.     interface eth0              #网卡绑定接口
12.     virtual_router_id 50        #虚拟路由id
13.     priority 150                #优先级
14.     advert_int 1                #监测间隔时间
15.     authentication {            #认证
16.         auth_type PASS          #认证方式
17.         auth_pass 1111          #认证密码
18.     }
19.     virtual_ipaddress {         
20.         10.0.0.3                #虚拟的VIP地址
21.     }
22. }

4、配置LB02

1. [root@LB02 ~]# cat /etc/keepalived/keepalived.conf global_defs {
2.     router_id LB02            #与主结点区别1:唯一标识
3. }
4. 
5. vrrp_instance VI_1 {
6.     state BACKUP              #与主节点区别2:角色状态   
7.     interface eth0
8.     virtual_router_id 50
9.     priority 100              #与主节点区别3:竞选优先级
10.     advert_int 1
11.     authentication {    
12.         auth_type PASS
13.         auth_pass 1111
14.     }
15.     virtual_ipaddress {
16.         10.0.0.3
17.     }
18. }

5、启动两个节点的keepalived

1. [root@LB01 ~]# systemctl start keepalived
2. [root@LB01 ~]# systemctl enable keepalived
3. 
4. [root@LB02 ~]# systemctl start keepalived
5. [root@LB02 ~]# systemctl enable keepalived

Keepalived测试抢占式和非抢占式

1、LB01的优先级高于LB02,所以VIP在LB01上面

1. [root@LB01 ~]# ip add | grep 10.0.0.3
2.     inet 10.0.0.3/32 scope global eth0

2、关闭LB01的keepalived,发现LB02自动接管

1. [root@LB01 ~]# systemctl stop keepalived
2. [root@LB01 ~]# ip add | grep 10.0.0.3
3. 
4. [root@LB02 ~]# ip add | grep 10.0.0.3
5.     inet 10.0.0.3/32 scope global eth0

3、重启LB01的keepalived,发现VIP被强行抢占

1. [root@LB01 ~]# systemctl start keepalived
2. [root@LB01 ~]# ip add | grep 10.0.0.3
3.     inet 10.0.0.3/32 scope global eth0
4. 
5. [root@LB02 ~]# ip add | grep 10.0.0.3

4、配置非抢占式

两个节点的state都必须配置为BACKUP,都必须加上配置nopreempt,其中一个节点的优先级必须高于另外一个节点的优先级。

1. [root@LB01 ~]# cat /etc/keepalived/keepalived.conf
2. global_defs {                   #全局配置
3.     router_id LB01              #标识身份->名称
4. }
5. 
6. vrrp_instance VI_1 {
7.     state BACKUP                #标识角色状态
8.     nopreempt
9.     interface eth0              #网卡绑定接口
10.     virtual_router_id 50        #虚拟路由id
11.     priority 150                #优先级
12.     advert_int 1                #监测间隔时间
13.     authentication {            #认证
14.         auth_type PASS          #认证方式
15.         auth_pass 1111          #认证密码
16.     }
17.     virtual_ipaddress {         
18.         10.0.0.3                #虚拟的VIP地址
19.     }
20. }
21. [root@LB01 ~]# systemctl restart keepalived
22. 
23. [root@LB02 ~]# cat /etc/keepalived/keepalived.conf
24. global_defs {
25.     router_id LB02
26. }
27. 
28. vrrp_instance VI_1 {
29.     state BACKUP
30.     nopreempt        
31.     interface eth0
32.     virtual_router_id 50
33.     priority 100
34.     advert_int 1
35.     authentication {    
36.         auth_type PASS
37.         auth_pass 1111
38.     }
39.     virtual_ipaddress {
40.         10.0.0.3
41.     }
42. }
43. [root@LB02 ~]# systemctl restart keepalived

5、通过windows的arp去验证,是否会切换MAC地址

1. [root@LB01 ~]# ip add | grep 10.0.0.3
2.     inet 10.0.0.3/32 scope global eth0

Windows本地hosts到10.0.0.3,浏览器访问blog.koten.com(LB01分配到Web01里面的域名)

WIN+R调用运行窗口,输入cmd打开命令提示符arp -a,查看arp缓存区,此时物理地址与LB01上10.0.0.3MAC地址一致

目录
相关文章
|
10月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
11月前
|
运维 监控 搜索推荐
MSE ZooKeeper:Flink 高可用架构的企业级选择
本文深入解析了 Apache Flink 架构中 ZooKeeper 的核心作用,包括 Leader 选举、Checkpoint 管理、作业协调及配置管理等关键功能,并结合金融风控与电商推荐等典型场景,分析了 ZooKeeper 在实际应用中的技术实现。
|
12月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
1198 0
|
9月前
|
运维 监控 安全
公链开发中的高可用架构设计要点
本指南提供公链高可用架构的可复用流程与模板,涵盖目标拆解、先决条件、分步执行、故障排查及验收标准,结合跨链DApp与量化机器人案例,提升落地效率与系统稳定性。
|
10月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
4065 57
|
12月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
468 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
数据采集 机器学习/深度学习 人工智能
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
1322 0
|
9月前
|
人工智能 运维 监控
运维安全还能靠“人盯人”?别闹了,聊聊自动化处理的真功夫
运维安全还能靠“人盯人”?别闹了,聊聊自动化处理的真功夫
316 17

热门文章

最新文章