(企业运维1)LVS+Keepalived实现高可用的ip负载均衡


前言

从本篇开始,主要是对企业项目的一些操作,为了贴近企业生产环境,在这里我将虚拟机全部换为RHEL7.6版本。


一、环境更换

1.1 配置rhel7.6的母盘

详细的母盘制作过程可以看这篇博客linux下的kvm自动部署

相关操作图文解释

在这里插入图片描述
在这里插入图片描述

内存不要小于1024
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

这里我们选择最小化安装

在这里插入图片描述
等待安装成功!

1.2 对母盘的封装

  1. 设置主机名
  2. 配置网卡,静态ip
  3. 配置网络仓库或者本地仓库(使用rhel7.6镜像)
  4. 设置本地dns解析
  5. 安装bash自动补齐工具,yum install -y bash-*
  6. 根据需要安装相应工具和服务即可,如lftp、http等
  7. 关闭防火墙,selinux。

1.3 对母盘的清理和压缩(纯净出厂加节约空间)

1.2节设置完毕后,关闭母盘虚拟机,接下来对母盘进行清理压缩和照快照

  1. 清理命令不清楚,没有安装,使用yum/dnf provides */virt-sysprep 找到命令提供者。

在这里插入图片描述

  1. 清理母盘

在这里插入图片描述

  1. 压缩母盘
    这里如果空间不够,需要清理点空间出来,再压缩
    查看文件大小命令 du -h 文件名,可以对比压缩前后大小
    在这里插入图片描述
  2. 照快照
    在这里插入图片描述

在这里插入图片描述
后续不再概述,就是启动快照,实验环境搭建就这么多。

这篇文章我用到的虚拟机是server11、server12、server13、server14。

二、LVS负载均衡技术(跑在OSI第四层:传输层)

lvs中文站点网址

在这里插入图片描述

2.1 LVS结构与工作原理

LVS由前端的负载均衡器(Load Balancer,LB)和后端的真实服务器(Real Server,RS)群组成。RS间可通过局域网或广域网连接。LVS的这种结构对用户是透明的,用户只能看见一台作为LB的虚拟服务器(Virtual Server),而看不到提供服务的RS群。

当用户的请求发往虚拟服务器,LB根据设定的包转发策略和负载均衡调度算法将用户请求转发给RS。RS再将用户请求结果返回给用户。同请求包一样,应答包的返回方式也与包转发策略有关。

2.2 LVS的包转发策略有三种

NAT (Network Address Translation)模式。LB收到用户请求包后,LB将请求包中虚拟服务器的IP地址转换为某个选定RS的IP地址,转发给RS;RS将应答包发给LB,LB将应答包中RS的IP转为虚拟服务器的IP地址,回送给用户。
IP隧道 (IP Tunneling)模式。LB收到用户请求包后,根据IP隧道协议封装该包,然后传给某个选定的RS;RS解出请求信息,直接将应答内容传给用户。此时要求RS和LB都要支持IP隧道协议。
DR(Direct Routing)模式。LB收到请求包后,将请求包中目标MAC地址转换为某个选定RS的MAC地址后将包转发出去,RS收到请求包后 ,可直接将应答内容传给用户。此时要求LB和所有RS都必须在一个物理段内,且LB与RS群共享一个虚拟IP。

2.3 本节以DR模式展开学习IP负载均衡技术

IP负载均衡技术

跟VS/TUN方法相同,VS/DR利用大多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似,但IBM的NetDispatcher是非常昂贵的商品化产品,我们也不知道它内部所使用的机制,其中有些是IBM的专利。

VS/DR的体系结构如下图所示:调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连,即通过交换机或者高速的HUB相连,中间没有隔有路由器。VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP的网络请求。
VS/DR的体系结构
VS/DR的工作流程如下图所示:它的连接调度和管理与VS/NAT和VS/TUN中的一样,它的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。
在这里插入图片描述
在VS/DR中,请求报文的目标地址为VIP,响应报文的源地址也为VIP,所以响应报文不需要作任何修改,可以直接返回给客户,客户认为得到正常的服务,而不会知道是哪一台服务器处理的。

VS/DR负载调度器也只处于从客户到服务器的半连接中,按照半连接的TCP有限状态机进行状态迁移。

2.4 RS中服务机对外屏蔽vip的俩种设置方法

一种是修改内核文件,但是操作不是很熟练,最好别用!
在这里插入图片描述
在这里插入图片描述

第二种就是使用arptables_jf软件
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

2.5 ip负载均衡实验图文解释

server11作为服务机,我们的调度器

  • 安装ipvsadm(内核级别服务,不需要启动)
  • 设置一个vip
  • 设置对12、13机的策略(看图)
  • 12和13机安装apche服务并写一个默认发布文件index.html
  • 设置12和13机的RS策略(看2.4)
  • 测试

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

设置对12,13的策略
在这里插入图片描述
给12和13机装http服务,并写默认发布文件
在这里插入图片描述
查看负载均衡情况:
在这里插入图片描述
在这里插入图片描述

三、shell脚本解决rs健康检查问题

一旦rs中某台机器掉线或者出故障,我们必须及时将其down掉,不然会影响客户访问;在机器启动后,我们还要手动将其加上。

在这里插入图片描述
在这里插入图片描述

四、keepalived+LVS(高可用)

shell脚本虽然解决了rs健康检查问题,但是不能解决LVS单点问题,一旦单点LVS自身down机,rs将无法均衡。
这里keepalived主要可以实现两点要求:

  • 实现rs的健康检查
  • LVS冗余

4.1 实验准备

server11和server14做双冗余lvs,server12和server13依然做rs服务机(这里是http服务)

  1. 在server11和server14上,安装好ipvsadm和keepalived

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

  1. 清除server11上之前的vip和RS上的策略,这些在keepalived里都不需要

在这里插入图片描述
在这里插入图片描述

4.2 配置文件修改

  1. 配置文件目录
    /etc/keepalived/keepalived.conf

主keepalived配置文件修改:

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
主配置文件书写,这里的邮件是发给自身。

[root@server11 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     root@localhost
   }
   notification_email_from keepalived@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
#  vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    
    
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
       1.2.3.100
    }
}

virtual_server 1.2.3.100 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
#    persistence_timeout 50
    protocol TCP

    real_server 1.2.3.12 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
             connect_timeout 3
             nb_get_retry 3
             delay_before_retry 3
                
                 }
             }
    real_server 1.2.3.13 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

辅keepalived配置修改:

直接拷贝主keepalived的配置文件稍作修改
在这里插入图片描述
辅配置文件:

[root@server14 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     root@localhost
   }
   notification_email_from keepalived@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
#  vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    
    
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 50
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
       1.2.3.100
    }
}

virtual_server 1.2.3.100 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
#    persistence_timeout 50
    protocol TCP

    real_server 1.2.3.12 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
             connect_timeout 3
             nb_get_retry 3
             delay_before_retry 3
                
                 }
            
              }
    real_server 1.2.3.13 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

4.3 实验测试

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
当down掉主keepalived的时候,可以在日志里看到辅keepalived转为主,当主keepalived重新启动时,辅回到辅(之前设置的优先级)
在这里插入图片描述
在这里插入图片描述

五、 LVS存在的问题与不足

  1. 在大规模网络中应用不足
    各种转发模式;网络拓扑复杂,运维成本高
  2. 和商用LB设备比较
    缺少TCP标志位DDOS攻击防御
  3. 主备部署方式不足
    性能无法线性扩展,即便实现了冗余,可依然是单点工作,始终只是一个调度器在工作 。

如何解决这些问题,请看企业运维2

猜你喜欢

转载自blog.csdn.net/weixin_41191813/article/details/112388503