3-3-基于LVS实现4层负载均衡模式和场景应用

回顾:
linux的集群形式:LB负载均衡,HA高并发,HP高性能
分布式系统:存储、计算(超算集群)
lb cluster实现方式:
软件
四层:lvs、nginx(stream)、haproxy(mode tcp)
七层:
http:nginx(http)/httpd/haproxy(mode http)/ats/perlbal/pound
mysql:ProxySQL...
硬件
lvs:linux virtual server
vs/rs,cip/vip/dip/rip
lvs type:
nat/dr/tun/fullnat
nat类型:多目标IP的DNAT,通过修改请求报文的目标IP和PORT来实现调度;
dr类型:通过为请求报文重新封装一个MAC首部进行转发:源MAC是DIP所在的接口的MAC,目标MAC是某次挑选出的RS的RIP所在接口的MAC地址;请求报文经由directory,响应报文不经由directory

NAT和DR都有距离的限制,必须在很近的距离内,因为双绞线的限制(私网地址必须在同一个物理网络)

接上次课课件:
lvs-tun:---RS不在同一个机房,所以不需要做拒绝arp广播和响应,这种模型应用不多(有个问题,巨型帧---客户端请求数据超过mtu)
转发方式:不修改请求报文的IP首部(源IP为CIP,目标IP为VIP),而是在原IP报文之外再封装一个IP首部(源IP是DIP,目标IP是RIP),将报文发往挑选出的目标RS;RS直接响应给客户端(源IP是VIP,目标IP是CIP);
(1)DIP,VIP,RIP都应该是公网地址;
(2)RS的网关不能,也不可能指向DIP;
(3)请求报文要经由Director,但响应不能经由Director;
(4)不支持端口映射;
(5)RS的OS得支持隧道功能;

    lvs-fullnat:---非标准类型
        通过同时修改请求报文的源IP地址和目标IP地址进行转发;
        CIP<-->DIP
        VIP<-->RIP

        (1)VIP是公网地址,RIP和DIP是私网地址,且通常不在同一IP网络;因此,RIP的网关一般不会指向DIP;
        (2)RS收到的请求报文源地址是DIP,因此,只能响应给DIP;但Direcotr还要将其发往Client;
        (3)请求和响应报文都经由Director;
        (4)支持端口映射;
        注意:此类型默认不支持;

总结:
    lvs-nat,lvs-fullnat:请求和响应报文都经由Director;
        lvs-nat:RIP的网关要指向DIP;
        lvs-fullnat:RIP和DIP未必在同一IP网络,但要能通信;
    lvs-dr,lvs-tun:请求报文要经由Director,但响应报文由RS直接发往Client;
        lvs-dr:通过封装新的MAC首部实现,通过MAC网络转发;
        lvs-tun:通过在原IP报文之外封装新的IP首部实现转发,支持远距离通信;

ipvs scheduler:
根据其调度时是否考虑各RS当前的负载状态,可分为静态方法和动态方法两种:
静态方法:仅根据算法本身进行调度;---一般短链接使用这种调度方法
RR:roundrobin,轮询;
WRR:Weighted RR,加权轮询;---有的服务器计算能力比较强,会虚拟出几台服务器的能力
SH:Source Hashing,实现session sticy(黏性),源IP地址hash;将来自同一个IP地址的请求始终发往第一次挑中的RS,从而实现会话绑定;---用户第一次访问,一般是加权轮询,在内存建立一个hash表,以源IP为键,以RIP为值---有个问题,server down了,session也就丢了,而且lvs工作在四层,不能进行cookie绑定
DH:Destination Hashing;目标地址哈希,将发往同一个目标地址的请求始终转发至第一次挑中的RS,典型使用场景是正向代理缓存场景中的负载均衡;

    动态方法:主要根据每RS当前的负载状态及调度算法进行调度;---适用于长连接---非活动连接对资源的依赖很少很少,重量是活动连接的256分之一
        Overhead=负载值
        LC:least connections---最少连接,谁小就挑选谁
            Overhead=activeconns*256+inactiveconns
        WLC:Weighted LC---加权最少连接,谁重就选谁,默认算法,有问题,刚开始没有连接,恰好轮询时第一台性能最差
            Overhead=(activeconns*256+inactiveconns)/weight
        SED:Shortest Expection Delay---最短期望延迟
            Overhead=(activeconns+1)*256/weight
        NQ:Never Queue不排队保证每个server都有链接

        LVLC:Locality-Based LC,动态的DH算法;如果没有绑定,不是轮询而是根据后端服务器的负载来调度
        LBLCR:LBLC with Replicaion,带复制功能的LBLC;两个缓存服务器之间允许缓存协议的共享

ipvsadm/ipvs:---ipvs是内核的直接功能,只要内核编译时开启此功能就能用,ipvsadm是用户空间工具,只要装安装包就能用,不需要监听任何服务和端口
集群和集群之上的各RS是分开管理的;
集群定义
RS定义
ipvs:
~]#grep -i "ipvs" -C 10 /boot/config-VERSION-RELEASE.x86_64---从这个内核编译信息配置模板的上下文中查找关键字的上下10行
支持的协议:TCP,UDP,AH,ESP,AH_ESP,SCTP;---都是四层协议
ipvs集群:
集群服务
服务商的RS
yum info ipvsadm---查看这个包信息

正向代理:代表客户端发出请求的
反向代理:代表服务端提供服务的

原文地址:https://blog.51cto.com/13852573/2364126

时间: 2024-08-30 14:25:35

3-3-基于LVS实现4层负载均衡模式和场景应用的相关文章

LVS详解及基于LVS实现web服务器负载均衡

前言 LVS(Linux Virtual Server)Linux虚拟服务器,是一个虚拟的服务器集群系统.本项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一.通过LVS提供的负载均衡技术和Linux操作系统可实现一个高性能.高可用的服务器群集,从而以低成本实现最优的服务性能. 集群基础 集群简介 集群(Cluster)是一组相互独立的.通过高速网络互联的计算机,它们构成了一个组,并以单一系统的模式加以管理.一个客户与集群相互作用时,集群像是一个独立的服务器.集群配置是用

3-2-基于LVS实现4层负载均衡原理讲解

对负载均衡来讲,最关键的就是调度器了网络传输层数:下四层由内核来管理及实现,被称为通信子网,最上面三层,叫应用层,在用户空间实现,叫做资源子网lvs是四层的负载均衡器,而且是真正附着在netfilter(内核通信过滤或操作框架)不需要向内核监听注册某一端口,不再受套接字文件数量的限制,直接修改报文扔给后端,不需要自己扮演任何角色tcp协议栈有65536个端口,主机只要向外发请求,就会用ip打开一个端口,像nginx这种运行在用户空间的进程,就需要通过自己的套接字(打开端口)向后端服务器的套接字传

3-5-基于LVS实现4层负载均衡配置和DR模型实战

DR类型directer只响应请求报文,然后调度某一个RS,而响应报文由RS直接返回给请求者RS和directer都需要配置VIP,(在同一网络中有可能冲突)本地局域网通告(通告自己的IP),ARP广播通告,ARP广播请求的响应RS配置VIP仅用于构建响应报文的源地址,不是用来真正通信的为了实现请求报文直接发送给director,而不是RS,有三种方式1.在路由器出口处做静态绑定,最不靠谱(因为director要做冗余的,需要重新绑定,二是不能阻断RS的ARP响应)2.在RS上安装arptabl

3-4-基于LVS实现4层负载均衡配置和nat模型实战

centos内核支持ipvs,只需在用户空间安装ipvsadm即可,首先应该准备好拓扑环境,了解编写规则的工具用法 yum install -y ipvsadmrpm -ql ipvsadm---可以看到用到了unit file,也就是脚本(开机启动不启动),ipvsadm不是一项服务,规则会保存到内存中不会永久有效,为什么会用到unitfile呢?因为需要在开机时使用restone重新载入规则 注意:对于集群类服务来说,不建议开机自动启动,需要手动开启,防止及其挂了.我们会有高可用集群服务器,

基于keepalived+nginx部署强健的高可用7层负载均衡方案20151214

高可用是个老生常谈的问题了,开源的高可用软件已经做的相当成熟了,之前也在debian下做过lvs+heartbeat的4层LB,一直很稳定(可惜流量不大啊),现在由于业务的需要,做一个基于keepalived+nginx的高可用7层负载均衡. 拓扑结构也比较简单,就不画拓扑图了:2个节点上分别安装配置keepalived和nginx,配置nginx反向代理后端的real server 比较关键的几个点: 1.为避免同一个局域网中有多个keepalived组中的多播相互响应,采用单播通信 2.状态

四层和七层负载均衡的特点及常用负载均衡Nginx、Haproxy、LVS对比

一.四层与七层负载均衡在原理上的区别 图示: 四层负载均衡与七层负载均衡在工作原理上的简单区别如下图: 概述: 1.四层负载均衡工作在OSI模型中的四层,即传输层.四层负载均衡只能根据报文中目标地址和源地址对请求进行转发,而无法修改或判断所请求资源的具体类型,然后经过负载均衡内部的调度算法转发至要处理请求的服务器.四层负载均衡单纯的提供了终端到终端的可靠连接,并将请求转发至后端,连接至始至终都是同一个.LVS就是很典型的四层负载均衡. 2.七层负载均衡工作在OSI模型的第七层应用层,所以七层负载

[转] 四层和七层负载均衡的特点及常用负载均衡Nginx、Haproxy、LVS对比

一.四层与七层负载均衡在原理上的区别 1.图示 2.概述 四层负载均衡工作在 OSI 模型中的四层,即传输层.四层负载均衡只能根据报文中目标地址和源地址对请求进行转发,而无法修改或判断所请求资源的具体类型,然后经过负载均衡内部的调度算法转发至要处理请求的服务器.四层负载均衡单纯的提供了终端到终端的可靠连接,并将请求转发至后端,连接至始至终都是同一个.LVS 就是很典型的四层负载均衡. 七层负载均衡工作在 OSI 模型的第七层,即应用层,所以七层负载均衡可以基于请求的应用层信息进行负载均衡,例如根

四层、七层负载均衡的区别

一.简介 所谓四层就是基于IP+端口的负载均衡:七层就是基于URL等应用层信息的负载均衡:同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡. 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址:三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址:四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器:七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器. 所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时

四层和七层负载均衡的区别

(一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡:七层就是基于URL等应用层信息的负载均衡:同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡. 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址:三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址:四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器:七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器. ② 所谓的四到七层负载均衡