keepalived+Nginx实现高可用集群

心已赠人 2022-12-12 15:26 315阅读 0赞

从单体到集群系列目录

从单体到集群(1) - 使用Nginx配置静态资源并搭建Tomcat集群

从单体到集群(2) - keepalived+Nginx实现高可用集群

从单体到集群(3) - LVS+Keepalived+Nginx实现高可用集群负载均衡


1.素材与软件版本

软件版本:

  1. **IDAE:**2019.2.2
  2. **VMware:**12.5.2
  3. **虚拟机镜像:**CentOs7.3标准版
  4. **Xshell:**Xshell6
  5. **Postman:**7.33.1
  6. **Tomcat:**8.5.41
  7. **Nginx:**1.18.0稳定版
  8. **keepalived:**2.0.18
  9. 项目素材链接放上,需要的朋友请自行下载。后台项目为[foodie-dev][],前端项目有两个,[foodie-shop][]为前端商城主体项目,[foodie-center][]为前端商城个人中心项目。具体项目配置的话可以看下我的上篇博文[架构篇:从单体到高可用集群(1) - 使用Nginx配置静态资源并搭建Tomcat集群][1_ - _Nginx_Tomcat]

2.架构演变目标

  1. 在上篇博文中,我们项目的架构由单体Tomcat部署前后台三个项目,演变成了由Nginx为静态资源提供服务同时将请求转发到后面的两个Tomcat集群上。上篇博文中的项目架构:

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70

  1. 这样确实保证了后台服务不会因为单节点Tomcat宕机而导致整体服务崩溃,但这样也有一个问题,**用单节点Nginxtomcat集群作转发,万一Nginx挂了怎么办?****所以我们今天的目标就是为单节点的Nginx搭建集群,确保Nginx的高可用。我们的目标架构如下:keepalived+Nginx高可用集群(双主热备模式)**

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 1

3.keepalived+Nginx高可用集群(双机主备模式)

3.1 安装keepalived

  1. 我们先来了解一下主备模式:

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 2

  1. 可以明显的看到主备模式的缺点,假设主机永远不宕机的话,备机一直处在待机模式,无法响应客户的请求,造成资源的浪费。下面我们要说的双主热备模式就可以解决这个问题,主备是双主热备的前提,所以我们先来配置一下主备模式。配置之前我们首先要再去创建一台Nginx虚拟机配置静态资源服务和搭建两台Tomcat集群,创建的步骤省略,不懂的小伙伴可以参考我上篇博文[架构篇:从单体到高可用集群(1) - 使用Nginx配置静态资源并搭建Tomcat集群][1_ - _Nginx_Tomcat]。目前四台虚拟机是已经配置好了:

20201008164738911.png

  1. 接下来我们把keepalived安装包上传到/home/software路径下,用tar指令解压:
  2. tar -zxvf keepalived-2.0.18.tar.gz
  3. 进入刚解压出的目录,配置并生成Makefile
  4. ./configure --prefix=/usr/local/keepalived --sysconf=/etc
  5. 然后执行makemake install
  6. make && make install
  7. 这样keepalived我们就安装好了

3.2 配置keepalived

  1. 进入/etc/keepalived路径,打开配置文件,修改配置文件内容为:
  2. global_defs {
  3. #路由id:当前安装keepalived节点主机全局唯一标识符
  4. router_id keepalived_150
  5. }
  6. vrrp_instance VI_1 {
  7. #表示当前主机为主节点
  8. state MASTER
  9. #绑定当前实例的网卡,这个需要用ip addr查询自己网卡配置,不一定都是ens33
  10. interface ens33
  11. #主备节点识别id,保证主备节点一致 1~255之间
  12. virtual_router_id 255
  13. #权值,因为是主节点设置的高一些
  14. priority 100
  15. #主备节点之间同步检查时间,单位为s
  16. advert_int 1
  17. #授权认证密码
  18. authentication {
  19. auth_type PASS
  20. auth_pass 1111
  21. }
  22. #虚拟IP
  23. virtual_ipaddress {
  24. 192.168.1.140
  25. }
  26. }
  27. 保存退出后,去/usr/local/keepalived/sbin路径下启动keepalived
  28. ./keepalived
  29. 之后用ip addr指令查看一下,可以看到ens33网卡下生成配置好的虚拟IP

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 3

  1. 同理在151这台机器上也安装一个keepalived,只不过配置文件稍加修改:
  2. global_defs {
  3. #路由id:当前安装keepalived节点主机全局唯一标识符
  4. router_id keepalived_151
  5. }
  6. vrrp_instance VI_1 {
  7. #表示当前主机为从节点
  8. state BACKUP
  9. #绑定当前实例的网卡,这个需要用ip addr查询自己网卡配置,不一定都是ens33
  10. interface ens33
  11. #主备节点识别id,保证主备节点一致
  12. virtual_router_id 255
  13. #权值,因为是备用节点设置的低一些
  14. priority 50
  15. #主备节点之间同步检查时间,单位为s
  16. advert_int 1
  17. #授权认证密码
  18. authentication {
  19. auth_type PASS
  20. auth_pass 1111
  21. }
  22. #虚拟IP
  23. virtual_ipaddress {
  24. 192.168.1.140
  25. }
  26. }
  27. **注:keepalived启动需要时间,别刚启动就去ip addr查看虚拟ip,我刚开始安装的时候就搞了半天,一直以为安装失败,汗-\_-||。具体日志在/var/log/messages文件中,如果真的启动失败可以手动查看一下。**
  28. 现在两台Nginx就配置好了集群,我们把192.168.1.150这台电脑的keepalived进程Kill掉,再访问192.168.1.140会发现被转发到了192.168.1.151这台电脑上,实现了Nginx的高可用。如果不想每次改完配置文件都去kill进程的话,可以把keepalived配置成系统服务。我们再访问192.168.1.140:90,可以看到后台请求也被转发到了192.168.1.151:90上,页面数据展示正常:

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 4

  1. 但这样的配置存在一个问题就是,如果挂的不是keepalived而是这台电脑上的Nginx的话,keepalived的转发就不会生效,因为它无法识别Nginx服务是否正常,解决方案是可以在keepalived.conf文件中配置对Nginx的定时检查,如果发现Nginx挂了,调用脚本重启Nginx

3.3 配置Nginx服务自动重启

  1. 增加Nginx重启检测脚本:
  2. vim /etc/keepalived/check_nginx_alive_or_not.sh
  3. #!/bin/bash
  4. A=`ps -C nginx --no-header |wc -l`
  5. # 判断nginx是否宕机,如果宕机了,尝试重启
  6. if [ $A -eq 0 ];then
  7. /usr/local/nginx/sbin/nginx
  8. # 等待一小会再次检查nginx,如果没有启动成功,则停止keepalived,使其启动备用机
  9. sleep 3
  10. if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
  11. killall keepalived
  12. fi
  13. fi
  14. 增加运行权限
  15. chmod +x /etc/keepalived/check_nginx_alive_or_not.sh
  16. keepalived配置文件中写入监听nginx脚本
  17. vrrp_script check_nginx_alive {
  18. script "/etc/keepalived/check_nginx_alive_or_not.sh"
  19. interval 2 # 每隔两秒运行上一行脚本
  20. weight 10 # 如果脚本运行失败,则升级权重+10
  21. }
  22. vrrp\_instance 中新增监控的脚本
  23. track_script {
  24. check_nginx_alive # 追踪 nginx 脚本
  25. }

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 5

  1. 最后重启keepalived即可,至此keepalived+Nginx高可用集群(双机主备模式)搭建完毕。

4.keepalived+Nginx高可用集群(双主热备模式)

  1. 双主热备的原理也很简单,就是在双机主备的基础上再增加一对实例,使192.168.1.150192.168.1.151这两台虚拟机变成互为主备的关系。这次我们先打开原来的备用机151keepalived的配置文件,做如下修改:
  2. vrrp_instance VI_2 {
  3. #实例2中将备机151修改成主节点
  4. state MASTER
  5. interface ens33
  6. #记得同步修改对配id
  7. virtual_router_id 1
  8. #因为是主节点,权值加大
  9. priority 100
  10. advert_int 1
  11. authentication {
  12. auth_type PASS
  13. auth_pass 1111
  14. }
  15. #将虚拟IP:19.168.1.141绑定到自己的网卡上
  16. virtual_ipaddress {
  17. 192.168.1.141
  18. }
  19. }
  20. 同理192.168.1.150这台虚拟机也进行相似的配置:
  21. vrrp_instance VI_2 {
  22. #这次改为从节点
  23. state BACKUP
  24. interface ens33
  25. #配对id保持一致
  26. virtual_router_id 1
  27. priority 50
  28. advert_int 1
  29. authentication {
  30. auth_type PASS
  31. auth_pass 1111
  32. }
  33. #增加虚拟IP:192.168.1.141
  34. virtual_ipaddress {
  35. 192.168.1.141
  36. }
  37. }
  38. 之后进行保存重启服务,可以看到150这台电脑绑定的虚拟IP:192.168.1.140151这台电脑绑定的虚拟IP:192.168.1.141

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 6

20201008184247107.png

  1. 至此keepalived+Nginx高可用集群(双主热备模式)搭建完毕。细心的小伙伴可能会问,**现在相当于有了两个前端访问入口(192.168.1.140192.168.1.141),浏览器到底应该写哪一个呢?**再来看一下我们的目标架构:

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 1
可以看到前端请求在访问到虚拟IP之前,挡了一层DNS轮训转发,这需要购买一个运营商的DNS服务,在服务中进行配置就可以实现此功能。DNS是基于域名的,因为我没有购买,所以就不能展示项目中这部分的配置了。但是不用急,接下来我会分享一篇“基于LVS+keepalived+Nginx实现高可用集群架构”的文章,欢迎大家来踩。

发表评论

表情:
评论列表 (有 0 条评论,315人围观)

还没有评论,来说两句吧...

相关阅读

    相关 可用

    什么是高可用集群呢?以前我不知道的时候感觉这东西很高端的说,等明白了以后发现高可用集群也就是当一台主机出现故障(包括物理故障和服务故障)后,在很短时间内有其它服务器来接替它的工

    相关 Redis 可用

    JAVA架构 2019-03-22 21:28:55 Redis 的集群主从模型是一种高可用的集群架构。本章主要内容有:高可用集群的搭建,Jedis连接集群,新增集群节点,删