精华内容
下载资源
问答
  • 无意中发现了一个巨牛的人工智能...两台UDP SERVER,通过F5实现硬件的UDP负载均衡,发现UDP SERVER上会定期收到F5的UDP探测,但是UDP SERVER并没有对这些探测做过任何响应,所以不明白F5是如何知道UDP SERVER...

    无意中发现了一个巨牛的人工智能教程,忍不住分享一下给大家。教程不仅是零基础,通俗易懂,而且非常风趣幽默,像看小说一样!觉得太牛了,所以分享给大家。点这里可以跳转到教程。

    项目背景

    两台UDP SERVER,通过F5实现硬件的UDP负载均衡,发现UDP SERVER上会定期收到F5的UDP探测包,但是UDP SERVER并没有对这些探测包做过任何响应,所以不明白F5是如何知道UDP SERVER是活的还是死的?

     

    两台UDP SERVER

    172.28.17.52

    172.28.17.54

    VIP

    172.28.26.13

     

    主备F5

    172.28.26.251

    172.28.26.252  

     

    当把两台UDP SERVER都停掉之后,F5显示如下:

    红色代表不可达

    当单独启动52的UDP SERVER后,F5显示如下:

     

    52的服务器上日志显示一直在收包,ip是F5的

    但是就程序而言,本身是并没有对探测包做出任何响应的,所以抓包看看

    52的机器上只发现有F5来的探测包,并没有发现有52回过去的响应包

     

    54上再抓包,54进程停掉了

    54进程不在,F5依然是在持续的发探测包的,UDP,同时可以看出54给F5回了ICMP的包,destination unreachable,搞之F5设备,当前机器不可达,此时F5就知道了54不可达,随即更自己维护的节点状态信息

    那么ICMP报文的作用是什么呢?

    ICMP协议主要用来检测网络通信故障和实现链路追踪,最典型的应用就是PING和tracerooute。

    PING:

        通过发送回送请求报文和回送回答报文来检测源主机到目的主机的链路是否有问题,目的地是否可达,以及通信的延迟情况。

    traceroute:

        通过发送探测报文来获取链路地址信息。第一个探测报文TTL为1,到达第一个路由器时,TTL减1为0所以丢掉这个探测包,同时向源主机发回ICMP时间超过报文,这时源主机就获得了第一个路由器的IP地址;接着源主机发送第二个探测报文,TTL增1为2,到达第一个路由器TTL减1为1并转发探测包到第二个路由器,这时TTL减1为0,丢掉这个探测包并向源主机发回ICMP时间超过报文,源主机就获得了第二个路由器的IP地址;以此类推,直到探测报文到达traceroute的目的地,这时源主机就获得了到目的地的每一跳路由的IP地址。

    由此不难看出为什么F5能知道后端real server的节点状态了

    展开全文
  • 笔者在研究四层负载均衡的时候,有读到这么一篇博客: ...文中提到的一点笔者存在一些困惑,我把原文截图出来: 对于文章中的描述,笔者不是太...所以下面笔者做了实验并抓包分析。 首先第一次使用的是haproxy,实验...

    笔者在研究四层负载均衡的时候,有读到这么一篇博客:

    https://blog.csdn.net/friends99/article/details/79803638

    文中提到的一点笔者存在一些困惑,我把原文截图出来:
    在这里插入图片描述

    对于文章中的描述,笔者不是太理解为什么服务器会和客户端直接建立连接,负载均衡会修改数据包源地址又是什么意思?所以下面笔者做了实验并抓包分析。

    首先第一次使用的是haproxy,实验拓扑如下
    在这里插入图片描述

    笔者将环境部署好后,用client去访问负载均衡以请求web内容,同时分别在haproxy的内网口和client的网口上抓包进行查看,下面的截图是抓到的包中笔者认为比较重要的部分:

    haproxy内网口

    在这里插入图片描述

    client网口
    在这里插入图片描述

    从抓到的数据包中可以分析TCP三次握手与四次挥手,负载均衡以源IP为自己,目的IP为后端的web,将数据包进行了转发,可证实博客中我划了红线的部分

    下面是对蓝线部分的抓包分析,拓扑类似,仅将haproxy换成了lvs

    以同样的方法进行抓包,得到:

    client网口,lvs起转发作用

    在这里插入图片描述

    lvs内网口,可以看到web是直接将数据包回给client的

    在这里插入图片描述

    这里我的理解是,lvs将client的请求进行转发,转发的时候将包的源地址(本来应该是lvs)改成了client,web根据接收请求数据包的源地址,在回包的时候直接将数据包路由给client。我想到的这么做的理由是,client来自外网,那web向client回数据必定需要路由,若负载均衡不是网关且不修改转发的包的源地址(这样的话源地址是负载均衡),那么web将会把包回给负载均衡设备,负载均衡再经过网关将数据路由给client……这么做相当于回包的时候还要从负载均衡走一趟,浪费资源。

    通过上面两次观察,笔者大致能理解博客中所说的意思,只是不知道有没有理解偏差。欢迎广大读者留下建议,若文章中有什么不对的地方也请批评指出。感谢!!

    展开全文
  • LVS 是 Linux Virtual Server 的简写,即 Linux 虚拟服务器,是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一。(百科) kube-proxy 的ipvs模式是 2015年由...

    LVS 是 Linux Virtual Server 的简写,即 Linux 虚拟服务器,是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一。(百科)

    kube-proxy 的ipvs模式是 2015年由k8s社区大佬thockin提出的(https://github.com/kubernetes/kubernetes/issues/17470),在2017年由华为云团队实现的(https://github.com/kubernetes/kubernetes/issues/44063),在kubernetes v1.8中已经引入了ipvs模式。
    ipvs模式的实现也是实现了ipvsadm这个核心组件,由于我们都使用LVS,对这个组件都有所了解,这里简单做下总结。

    LVS 基础

    LVS 核心组件

    ipvsadm:用户空间的命令行工具,用于管理集群服务及集群服务上的RS等;(管理工具)
    ipvs:工作于内核上的程序,可根据用户定义的集群实现请求转发;(内核模块)

    LVS 专业术语

    VS:Virtual Server (虚拟服务)
    DS:Director Server(负载均衡器)
    RS:Real Server (后端真实处理请求的服务器)
    CIP: Client IP (用户端IP)
    VIP:Director Virtual IP (负载均衡器虚拟 IP)
    DIP:Director IP (负载均衡器 IP)
    RIP:Real Server IP (后端请求处理服务器 IP)

    工作原理

    在这里插入图片描述
    IPVS 是工作在 INPUT 链上的,当用户请求到达 INPUT 链时,IPVS 会将用户请求与自己已定义好规则进行比对,如果用户请求的就是定义的集群服务,那么此时 IPVS 会强行修改数据包里的目标 IP 地址及端口,并将新的数据包发往 POSTROUTING 链;
    ipvs (IP Virtual Server) 实现了4层负载均衡,ipvs 运行在主机上,在Real Server 集群前充当LB(负载均衡器),ipvs 将基于 TCP 和 UDP 的服务请求转发到真实服务器上,并使真实服务器上面的服务,能够在前面 Director Server上、通过提供的 VIP 对外提供服务。

    LVS 常用算法

    RR(Round Robin):轮询调度,在不考虑每台服务器处理能力的情况下,轮询调度算法是把来自用户的请求轮流分配给内部中的服务器,从1开始,直到N(内部服务器个数),然后重新开始循环;
    WRR(Weight Round Robin):加权轮询,由于每台服务器的配置、跑业务类型不同,其处理能力也会不同,所以我们根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数据的服务请求;
    DH(Destination hashing):目标地址散列,根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空;
    SH(Source Hashing):源地址散列,主要实现会话绑定,能够将此前建立的session信息保留了,根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空;
    LC(Least Connections):最少链接,将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用“最小连接”调度算法可以较好地均衡负载;
    WLC(Weighted Least Connections):加权最少链接,在集群系统中的服务器性能差异较大的情况下,调度器采用“加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载,调度器可以自动问询真实服务器的负载情况,并动态地调整其权值;
    除上面一些常用调度算法外,还有一些几个,如下:LBLC(Locality-Based Least Connections)基于局部性的最少链接、LBLCR(Locality-Based Least Connections with Replication)带复制的基于局部性最少链接、SED(Shortest Expected Delay Scheduling)最短的期望的延迟、NQ(Never Queue Scheduling NQ)最少队列调度;

    LVS 模式

    DR、NAT、隧道模式;(后面重点讲解)

    LVS 组件安装

    yum -y install ipvsadm
    

    ipvsadm 常用配置参数
    -A 添加虚拟服务VIP
    -D 删除虚拟服务VIP
    -L 查看虚拟服务VIP
    -C 清除所有虚拟服务VIP
    -t 指定虚拟服务及端口 VIP:Port
    -r 指定真实服务及端口 RS:Port
    -s 指定算法,rr(轮询)、wrr(加权轮询)、lc(最少连接)、sh(源地址散列)、dh(目标地址散列) 等等
    -w 指定权重
    -m 指定转发模式为NAT
    -g 指定转发模式为DR
    -i 指定转发模式为IPIP隧道

    NAT 模式

    报文请求过程图

    在这里插入图片描述

    报文请求过程分析

    1. 当用户请求到达 DS 时,请求报文会先经过内核空间中的 PREROUTING 链,此时源 IP 为CIP,目的 IP 为 VIP;
    2. 在 PREROUTING 规则链上进行检查目的IP是否为本机,如果是的话将数据包送至 INPUT 链;
    3. 数据包到达INPUT链后,IPVS 会比对数据包请求的服务是否为集群服务,若是,修改数据包的目标 IP 地址为后端服务器 IP(这里需要根据各种算法计算,哪台 RS 更合适),再将数据包发至 POSTROUTING 链,此时报文的源 IP 为 CIP,目标 IP 为 RIP;
    4. POSTROUTING 链的作用就是选路,根据 INPUT 链中目标 IP,将数据包发送给 RS;
    5. RS 发现数据包中的目标 IP 是自己的 IP,此时它会开始构建响应报文发并回给 DS, 此时报文的源IP为RIP,目标IP为 CIP;
    6. DS 收到 RS 响应后,但在响应客户端,会将源 IP 地址修改为自己的 VIP 地址,然后发送给客户端,此时报文的源 IP 为 VIP,目标 IP 为 CIP;

    NAT 实验

    在这里插入图片描述
    NAT 模式时,LB 节点IP与RS节点IP可以不在同一个网络内,现为了模拟我们在 LB 节点添加一虚拟IP 如下,并测试连通性。

    [root@master02 ~]# ip addr add 100.222.111.1/24 dev ens32
    [root@master02 ~]# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
    2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether 00:50:56:8e:53:c1 brd ff:ff:ff:ff:ff:ff
        inet 1.65.15.141/24 brd 1.65.15.255 scope global ens32
           valid_lft forever preferred_lft forever
        inet 100.222.111.1/24 scope global ens32
           valid_lft forever preferred_lft forever
    3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
        link/ether 02:42:46:24:ae:8c brd ff:ff:ff:ff:ff:ff
        inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
           valid_lft forever preferred_lft forever
    [root@master02 ~]# ping -c 1 100.222.111.1
    PING 100.222.111.1 (100.222.111.1) 56(84) bytes of data.
    64 bytes from 100.222.111.1: icmp_seq=1 ttl=64 time=0.033 ms
    
    --- 100.222.111.1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms
    [root@master02 ~]#
    

    创建负载均衡service

    [root@master02 ~]# ipvsadm -A -t 100.222.111.1:8000 -s rr
    [root@master02 ~]#
    

    添加 RS 到指定的负载均衡器下

    [root@master02 ~]# ipvsadm -a -t 100.222.111.1:8000 -r 1.65.15.143:80 -m
    [root@master02 ~]# ipvsadm -a -t 100.222.111.1:8000 -r 1.65.15.144:80 -m
    [root@master02 ~]#
    

    在client上面访问VIP

    [root@master01 ~]# ping -c 1 100.222.111.1
    PING 100.222.111.1 (100.222.111.1) 56(84) bytes of data.
    
    --- 100.222.111.1 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms
    
    [root@master01 ~]#
    

    我们发现并不通,由于这个VIP是虚拟的,需要添加路由,添加静态路由如下。

    [root@master01 ~]# ip route add 100.222.111.1 via 1.65.15.141 dev ens32
    [root@master01 ~]#
    

    继续测试连通性

    [root@master01 ~]# ping -c 1 100.222.111.1
    PING 100.222.111.1 (100.222.111.1) 56(84) bytes of data.
    64 bytes from 100.222.111.1: icmp_seq=1 ttl=64 time=0.088 ms
    
    --- 100.222.111.1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
    [root@master01 ~]#
    

    发现可以ping通了,我们接下来验证service

    [root@master01 ~]# curl -m 15 --retry 1 -sSL 100.222.111.1:8000
    curl: (28) Connection timed out after 15001 milliseconds
    [root@master01 ~]#
    

    LB抓包
    在这里插入图片描述
    RS 抓包如下
    在这里插入图片描述
    数据包的源IP为CIP,目标IP为RIP,LB节点 IPVS 只做了 DNAT,只是把目标IP改成RS IP了,而没有修改源IP。此时虽然RS和CIP(client)在同一个子网,链路连通性没有问题,但是由于 CIP 节点发出去的包的目标IP和收到的包源IP不一致,因此会被直接丢弃,所以需要在iptables 上做地址伪装。

    [root@master02 ~]# iptables -t nat -A POSTROUTING -m ipvs --vaddr 100.222.111.1 --vport 8000 -j MASQUERADE
    [root@master02 ~]# iptables -t mangle -A POSTROUTING -m ipvs --vaddr 100.222.111.1 --vport 8000 -j LOG --log-prefix '[k8svip ipvs]'
    [root@master02 ~]#
    

    上面我们在LB节点做地址伪装,并且把经过iptables的转发日志记录下来,这里需要注意,只能在mangle表才能记录,在nat表时,无法记录转发日志,再次测试,发现依然不通;

    [root@master01 ~]# curl -m 15 --retry 1 -sSL 100.222.111.1:8000
    curl: (28) Connection timed out after 15001 milliseconds
    [root@master01 ~]#
    

    哪问题出在什么地方呢?由于PROC文件系统的/proc/sys/net/ipv4/vs/conntrack可控制IPVS是否对其连接启用Netfilter系统的conntrack功能,默认情况下是关闭状态,这里需要打开,如下。

    [root@master02 ~]# sysctl net.ipv4.vs.conntrack=1
    net.ipv4.vs.conntrack = 1
    [root@master02 ~]#
    

    下面这个图是是否开启conntrack功能的iptables日志对比,上面只是SYN,根本无法完成三次握手,缺少链路追踪,这里需要再开启conntrack功能。
    在这里插入图片描述
    再次测试,成功。

    [root@master01 ~]# curl -m 15 --retry 1 -sSL 100.222.111.1:8000
    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    。。。。。
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    [root@master01 ~]#
    

    RS 抓包
    在这里插入图片描述
    LB抓包
    在这里插入图片描述
    到这里nat实验就完成了,可以看下数据包,源IP已经变成了LB的IP。

    NAT 特性总结

    1. RS 的 RIP 与 DS 的 DIP 必须使用相同网段的私网地址,并且 RS 的网关要指向 DS 的 DIP;
    2. 客户端的请求和响应报文都要经由 DS 转发,在大并发、大流量的场景中,DS有可能会成为系统瓶颈;
    3. 支持端口映射;

    DR 模式

    报文请求过程图

    在这里插入图片描述

    报文请求过程分析

    1. 当用户请求到达 DS 时,请求报文会先经过内核空间中的 PREROUTING 链,此时源IP为CIP,目的 IP 为 VIP;
    2. 在 PREROUTING 规则链上进行检查目的IP是否为本机,如果是的话将数据包送至 INPUT 链;
    3. 数据包到达INPUT链后,IPVS 会比对数据包请求的服务是否为集群服务,若是,将请求报文中的源 MAC 地址修改为 DIP 的 MAC 地址,将目标 MAC 地址修改 RIP 的 MAC 地址(这里需要IPVS根据策略算法选择一台合适的 RS 的 MAC 地址),然后再将数据包发至 POSTROUTING 链, 此时的源 IP 和目标 IP 均未修改,仅修改了源和目的的MAC地址(DR 模式要求 DS 与 RS 也必须是同一个物理网络中,可公、可私);
    4. POSTROUTING链检查目标 MAC 地址为 哪一个 RIP 的 MAC 地址,选择后,再把数据包将会发给 RS;
    5. RS 发现请求报文的 MAC 地址是自己的 MAC 地址,就接收此报文并处理,将响应报文通过 lo 接口传送给 eth0 网卡然后向外发出,此时的源IP地址为VIP,目标IP为CIP;
    6. 响应报文最终到客户端;

    DR 实验

    在这里插入图片描述
    从DR模式原理可知,调度器只是修改请求报文的目的mac(二层转发),这就要求调度器和RS需要在同一个网段,并且也无需要开启ip_forward,所以需要分配一个同网段的IP 做为VIP;

    [root@master02 ~]# ping -c 1 1.65.15.145
    PING 1.65.15.145 (1.65.15.145) 56(84) bytes of data.
    From 1.65.15.141 icmp_seq=1 Destination Host Unreachable
    
    --- 1.65.15.145 ping statistics ---
    1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
    
    [root@master02 ~]#
    

    添加 VIP 网卡信息

    [root@master02 ~]# ifconfig ens32:0 1.65.15.145/24 up
    [root@master02 ~]#
    

    创建 service 负载均衡

    [root@master02 ~]# ipvsadm -A -t 1.65.15.145:80 -s rr
    [root@master02 ~]#
    

    把 RS 添加到负载均衡

    [root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.143:80 -g
    [root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.144:80 -g
    [root@master02 ~]#
    

    客户端连通性测试

    [root@master01 ~]# ping -c 1 1.65.15.145
    PING 1.65.15.145 (1.65.15.145) 56(84) bytes of data.
    64 bytes from 1.65.15.145: icmp_seq=1 ttl=64 time=0.078 ms
    
    --- 1.65.15.145 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.078/0.078/0.078/0.000 ms
    [root@master01 ~]#
    

    负载测试

    [root@master01 ~]# curl -m 15 --retry 1 -sSL 1.65.15.145:80
    curl: (7) Failed connect to 1.65.15.145:80; 没有到主机的路由
    [root@master01 ~]#
    

    发现负载服务不通,进行抓包分析
    dr模式LB抓包
    在这里插入图片描述
    dr模式RS抓包
    在这里插入图片描述
    根据 DR 模式路由转发原理,LB上面源MAC地址修改为LB的MAC地址,而目标MAC地址修改为RS MAC地址,上图中已经发现MAC正常修改了,但为什么不通呢?在RS数据包中发现源IP和目标IP也都未修改,那么问题来了,我们Client期望访问的是RS(通过 mac 二次互访),但RS收到的目标IP却是LB上面的VIP,发现这个目标IP并不是自己的IP,因此不会通过 INPUT 链转发到用户空间,这时要不直接丢弃这个包,要不根据路由再次转发到其他地方,总之两种情况都不是我们期望的结果。那怎么办呢?如果想让RS接收这个包,必须得让RS有这个目标IP才行,不妨在lo上添加个虚拟IP,IP地址伪装成LB IP 1.65.15.145。所以需要在RS上面添加虚拟IP,并且添加一条路由如下。

    [root@master03 ~]# ifconfig lo:0 1.65.15.145/32 up
    [root@master03 ~]# route add -host 1.65.15.145 dev lo
    [root@master03 ~]#
    

    此时问题又来了,这就相当于在一个局域网内有两个相同的IP,IP重复了怎么办?办法就是隐藏这个虚拟网卡,不让它回复ARP,其他主机的neigh也就不可能知道有这么个网卡的存在了。

    [root@node01 ~]# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
    [root@node01 ~]# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
    [root@node01 ~]#
    

    arp_ignore=1,只响应目的IP地址为接收网卡上的本地地址的arp请求。
    因为我们在RS上都配置了VIP,因此此时是存在IP冲突的,当外部客户端向VIP发起请求时,会先发送arp请求,此时调度器和RS都会响应这个请求。如果某个RS响应了这个请求,则之后该客户端的请求就都发往该RS,并没有经过LVS,因此也就没有真正的负载均衡,LVS也就没有存在的意义。因此我们需要设置RS不响应对VIP的arp请求,这样外部客户端的所有对VIP的arp请求才会都解析到调度器上,然后经由LVS的调度器发往各个RS。
    系统默认arp_ignore=0,表示响应任意网卡上接收到的对本机IP地址的arp请求(包括环回网卡上的地址),而不管该目的IP是否在接收网卡上。也就是说,如果机器上有两个网卡设备A和B,即使在A网卡上收到对B IP的arp请求,也会回应。而arp_ignore设置成1,则不会对B IP的arp请求进行回应。由于lo肯定不会对外通信,所以如果只有一个对外网口,其实只要设置这个对外网口即可,不过为了保险,很多时候都对all也进行设置。
    arp_announce=2,网卡在发送arp请求时使用出口网卡IP作为源IP。
    当RS处理完请求,想要将响应发回给客户端,此时想要获取目的IP对应的目的MAC地址,那么就要发送arp请求。arp请求的目的IP就是想要获取MAC地址的IP,那arp请求的源IP呢?自然而然想到的是响应报文的源IP地址,但也不是一定是这样,arp请求的源IP是可以选择的,而arp_announce的作用正是控制这个地址如何选择。系统默认arp_announce=0,也就是源ip可以随意选择。这就会导致一个问题,如果发送arp请求时使用的是其他网口的IP,达到网络后,其他机器接收到这个请求就会更新这个IP的mac地址,而实际上并不该更新,因此为了避免arp表的混乱,我们需要将arp请求的源ip限制为出口网卡ip,因此需要设置arp_announce=2。(解释来源于网络)
    测试连通性

    [root@master01 ~]# curl 1.65.15.145:80
    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
     
    。。。。
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    [root@master01 ~]#
    

    RS抓包如下
    在这里插入图片描述
    LB抓包如下
    在这里插入图片描述
    通过数据包分析可以发现MAC地址的转换,及源目标IP的转换关系,到此这个DR实验完成。

    DR 模式特性总结

    1. 前端路由器将目标 IP 为 VIP 时的请求报文,发往DS,需要在前端网关做静态绑定,RS上使用 arptables,并且在RS上修改内核参数以限制 arp 通告及应答级别;
    2. 修改 RS 上内核参数(arp_ignore和arp_announce)将 RS 上的 VIP 配置在 lo 接口的别名上,并限制其不能响应对 VIP 地址解析请求;
    3. RS 的 RIP 可以使用私网地址,也可以是公网地址,但 RIP 与 DIP 必须在同网络内,RIP 的网关不需要也不能指向 DIP,以确保响应报文不会经由 DS;
    4. 请求报文要经由 DS,但响应时不经过 DS,而是由 RS 直接发往 客户端;
    5. DR 模式不支持端口映射;

    IPIP 模式

    报文请求过程图

    在这里插入图片描述

    报文请求过程分析

    1. 当用户请求到达 DS 时,请求报文会先经过内核空间中的 PREROUTING 链,此时源IP为CIP,目的 IP 为 VIP;
    2. 在 PREROUTING 规则链上进行检查目的IP是否为本机,如果是的话将数据包送至 INPUT 链;
    3. 数据包到达INPUT链后,IPVS 会比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层 IP 报文,封装源 IP 为 DIP,目标 IP 为 RIP,然后发至POSTROUTING链,此时源 IP 为 DIP,目标 IP 为 RIP;
    4. POSTROUTING 链根据最新封装的 IP 报文,将数据包发至 RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输);此时源 IP 为 DIP,目标 IP 为 RIP;
    5. RS 接收到报文后发现是自己的 IP 地址,就将报文接收下来,拆除掉最外层的 IP 后,会发现里面还有一层 IP 首部,而且目标是自己的 lo 接口 VIP,那么此时 RS 开始处理此请求,处理完成之后,通过 lo 接口送给 eth0 网卡,然后向外传递,此时的源 IP 地址为 VIP,目标 IP 为 CIP;
    6. 响应报文最终送达至客户端;

    IPIP 实验

    在这里插入图片描述
    DR 模式是通过MAC地址进行交换,只能限制在一个局域网内,而TUN隧道方式 ,是通过给数据包加上新的IP头部来实现,这个可以跨机房(可以实现异地容灾)、跨公网、主要是解决不能跨网的问题;
    添加 VIP 网卡信息

    # 配置 VIP
    [root@master02 ~]# ifconfig ens32:1 1.65.15.145 netmask 255.255.255.0 up
    
    # 测试连通性
    [root@master02 ~]# ping -c 1 1.65.15.145
    PING 1.65.15.145 (1.65.15.145) 56(84) bytes of data.
    64 bytes from 1.65.15.145: icmp_seq=1 ttl=64 time=0.026 ms
    
    --- 1.65.15.145 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
    [root@master02 ~]#
    

    创建负载均衡

    [root@master02 ~]# ipvsadm -A -t 1.65.15.145:80 -s rr
    [root@master02 ~]#
    

    添加RS到LB

    # 添加 RealServer 作为 VIP 的后端
    [root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.143:80 -i
    [root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.144:80 -i
    [root@master02 ~]#
    

    负载均衡器(LB)要开启转发功能

    [root@master02 ~]# echo 1 >/proc/sys/net/ipv4/ip_forward
    [root@master02 ~]#
    

    查看负载情况

    [root@master02 ~]# ipvsadm -L -n
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    TCP 1.65.15.145:80 rr
      -> 1.65.15.143:80 Tunnel 1 0 0
      -> 1.65.15.144:80 Tunnel 1 0 0
    [root@master02 ~]#
    

    RealServer 配置tunl0 (所有RS服务器)

    # 加载下 tunl 模式
    [root@node01 ~]# modprobe ipip
    
    # 为 tunl0 网口配置 IP(即VIP)
    [root@node01 ~]# ifconfig tunl0 1.65.15.145 netmask 255.255.255.255 up
    [root@node01 ~]#
    

    修改内核参数(所有RS服务器)

    [root@node01 ~]# echo 0 > /proc/sys/net/ipv4/ip_forward
    [root@node01 ~]# echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore
    [root@node01 ~]# echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce
    [root@node01 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
    [root@node01 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
    [root@node01 ~]# echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
    [root@node01 ~]# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
    

    arp_ignore 与 arp_announce上面已经有详细说明,这里说下rp_filter,官方说明 https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
    rp_filter 参数主要是用于控制系统是否开启对数据包源地址的校验,它有3个值,0、1、2。
    0:不开启源地址检验;
    1:开启严格的反向路径校验,对每个入访的数据包,通过指定网卡,校验其出访路径是否为最佳路径,如果不是最佳路径,则直接丢弃;(Linux 服务器默认是1)
    2:开启松散的反向路径校验,对每个进来的数据包,通过任意网口,校验其源地址是否可达,即反向路径是否能通,如果不通,则丢弃;
    其实这个参数和安全也息息相关:

    1. Distribute Deny of Service 即 分布式拒绝服务攻击,原理就是通过构造大量的无用数据包向目标服务发起请求,占用目标服务主机大量的资源,还可能造成链路上面网络拥塞,进而影响到正常用户的访问,我们把这个参数设为1,严格校验数据包的反向路径,如果出访路径不合适,就直接丢弃数据包,这样避免过多的无效连接消耗Linux系统资源;
    2. IP Spoofing 即 IP 欺骗,是指客户端通过伪造源IP,冒充另外一个客户端与目标服务进行通信,从而达到劫持的目的,如果我们把参数设为1,严格校验数据包的反向路径,如果客户端伪造的源IP地址对应的反向路径不在路由表中,或者反向路径不是最佳路径,则直接丢弃数据包,不会向伪造IP的客户端回复响应。
      测试访问
    [root@master01 ~]# curl -m 15 --retry 1 -sSL http://1.65.15.145
    <!DOCTYPE html>
    <html>
    <head>
    。。。
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    [root@master01 ~]#
    

    RS 抓包
    在这里插入图片描述
    在这里插入图片描述
    通过RS抓包,可以清楚看出IPIP隧道数据包封装的格式,但回包的时候,直接就回了;
    DS抓包(转发server)
    在这里插入图片描述
    这个数据包,感觉有问题,后面我再查下,分析下原因,如果有人知道,也可交流;

    IPIP 特性总结

    1. DIP, VIP, RIP 都应该是公网地址;
    2. RS 的网关不能、也不可能指向DIP;
    3. 请求报文要经由 DS,但响应不经过 DS;
    4. 不支持端口映射;
    5. RS 的 OS 得支持隧道功能;

    总结

    在这里插入图片描述
    由于各个公司实际情况不同、业务类型不同、容灾策略、基础架构不同,需要结合自己公司的情况进行分析,然后选择合适的解决方案。
    本文摘自Linux云计算网络

    展开全文
  • 搭建一个简单的lvs nat 模式的负载均衡环境,用来验证一下整个访问请求过程的数据包走向流程。 2. LVS的nat模式的服务器架构图 注意在架构图中的说明。 客户端和realserver不能再同一个网段,不然直接响应,不走...

    1. 前言

    搭建一个简单的lvs nat 模式的负载均衡环境,用来验证一下整个访问请求过程的数据包走向流程。

    2. LVS的nat模式的服务器架构图

    lvs_nat 负载均衡模式及抓包分析

    注意在架构图中的说明。
    客户端和realserver不能再同一个网段,不然直接响应,不走网关

    3. 架构搭建流程说明

    3.1 准备工作

    三台机器:

    1. 调度器简称dr,我这里简化叫做VIP,
           eth0     192.168.188.108    内网ip
           eth1      192.168.56.200     vip
    2. 两台realserver,简称RS,
          RS1   eth0   192.168.188.107   设置网关为 192.168.188.108
          RS2   eth0    192.168.188.110   设置网关为 192.168.188.108
    3. 三台机器都需要关闭selinux,和清空iptables

    一台客户机:

    client    eth1     192.168.56.111   用来做验证,访问VIP;

    3.2 VIP 服务器操作

    安装ipvsadm
    yum  install -y   ipvsadm
    编写lvs_nat.sh 脚本
    [root 09:54:01 @CentOS3 sbin] cat /usr/local/sbin/lvs_nat.sh 
    #! /bin/bash
    # director 服务器上开启路由转发功能
    echo 1 > /proc/sys/net/ipv4/ip_forward
    # 关闭icmp的重定向
    echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
    echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
    # 注意区分网卡名字,我的两个网卡分别为eth0和eth1
    echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
    echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    # director 设置nat防火墙
    iptables -t nat -F
    iptables -t nat -X
    iptables -t nat -A POSTROUTING -s 192.168.188.0/24  -j MASQUERADE
    # director设置ipvsadm
    IPVSADM='/sbin/ipvsadm'
    $IPVSADM -C
    $IPVSADM -A -t 192.168.56.200:80 -s  wrr 
    $IPVSADM -a -t 192.168.56.200:80 -r 192.168.188.107:80 -m -w 2
    $IPVSADM -a -t 192.168.56.200:80 -r 192.168.188.110:80 -m -w 1
    
    chmod   755  /usr/local/sbin/lvs_nat.sh
    
    运行脚本:
        /bin/bash   /usr/local/sbin/lvs_nat.sh  

    运行脚本后,查看VIP 服务器上的 ipvs 配置,出现如下结果,说明nat 模式配置正确:

    [root 10:57:40 @CentOS3 sbin] ipvsadm -ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    TCP  192.168.56.200:80 wrr
      -> 192.168.188.107:80           Masq    2      0          16        
      -> 192.168.188.110:80           Masq    1      0          8      

    3.3 在RS 服务器安装nginx 服务

    分别在两台realserver 服务器上安装nginx,然后修改nginx 的默认html 页面,让他们返回不同的内容,用来区分实验就可以了。

    记住,realserver 上的网卡网关要改为VIP 的内网IP(192.168.188.108),这样才能让realserver的数据包返回到VIP服务器。

    4. 开始测试验证

    4.1 客户端发起请求

    在终端,写一死循环,让它不断地访问VIP服务器

    [root 09:59:24 @CentOS3_3 ~] while  true; do  curl  -x192.168.56.200:80  localhost ;sleep  5; done
    cenvm72
    cenvm71
    cenvm71
    cenvm72
    cenvm71
    cenvm71
    cenvm72
    cenvm71
    cenvm71
    

    由于我现在的nat 模式使用的连接算法是加权轮询,cenvm71 的机器权重是2,cenvm72 的机器权重是1,这个权重在VIP 服务器的 lvs_nat.sh 脚本设置。从curl 返回的结果来看,访问连接被VIP 服务器按2:1 的比例,均匀的分派到后端两台RS 服务器。

    4.2 模块分析
    客户端发起请求
    nat模式中,vip机器进行ip的转发,只改变目的ip
    res1和res2需要提供web服务(nginx或者httpd都可以)
    请求流程图

    1>客户端发起请求到vip机器上,vip服务器根据lvs的算法,转发给realserver服务器(改变目的ip为rs1或者rs2),并记录连接信息,只改变目的ip,源ip不变。
    2>realserver收到request请求包之后,发现目的ip是自己的ip,处理请求,然后走网关,经过vip
    3>vip收到reply包后,修改reply包的源ip地址为vip,发给客户端
    4>从客户端来的属于本地连接的包,查hash表,然后转发给real-server
    5>当client发送完毕以后,此次连接结束或者连接超时,lvs自动从hast表中删除此条记录;

    (1) 客户端访问 vip:
    source 192.168.56.111 dest 192.168.56.200
    在vip 上的eth1 网卡抓包:
    lvs_nat 负载均衡模式及抓包分析

    (2) vip处理数据转发到后端realserver,在vip 上抓eth0 的报文:
    source 192.168.56.111 dest 192.168.188.107 (rs 的ip地址)

    lvs_nat 负载均衡模式及抓包分析

    (3) rs 返回数据给vip,rs的网关是vip 服务器的eth0,所以,在vip 的eth0 上抓数据:
    lvs_nat 负载均衡模式及抓包分析

    source 192.168.188.107 dest 192.168.56.111 (客户的IP 地址)

    (4) vip 返回数据给客户client,先从eth0返回给eth1,在从eth1 将源ip改成vip,目标ip保持不变:
    sourc 192.168.56.200 dest 192.168.56.111

    lvs_nat 负载均衡模式及抓包分析

    (5) 在客户端抓eth1 的数据包,可以抓到所有的数据包都是从vip 返回的:
    lvs_nat 负载均衡模式及抓包分析

    5. 总结

    通过实验,验证了lvs nat 模式中,数据报文的ip地址是如何改变的。但是,也可以发现这种模式存在一个明显的缺点。当访问流量比较大的时候,VIP 调度服务器将会成为性能瓶颈。因为客户端的连接既要通过VIP 转发,又要通过VIP 返回,在响应数据比请求数据要长得多的情况下,VIP 调度器就会成为瓶颈。

    转载于:https://blog.51cto.com/hellocjq/2090214

    展开全文
  • 内容包括DHCP 服务器搭建与管理、DNS服务器搭建与管理、IIS服务器的搭建与管理、PKI与SSL网站搭建与管理、FTP服务器的搭建与管理、打印服务器的...群集服务器的搭建与管理、网络负载平衡群集(NLBC)服务器的搭建与管理...
  • 最近,在做标准SIP网关的分布式开发,在注册服务器选型上,最初打算使用freeswitch做为注册服务器,在测试的时候通过抓包,然后分析SIP信令,发现freeswitch软件需要理解SIP信令(比如呼叫相关的信令),并会对信令...
  • 对于网络上面很重要的一部分内容——在线游戏来说,服务器负载均衡是非常非常重要的。...近日在与业内人士讨论时,提到QQ游戏的实现方式并不是我原来所想的那样,于是,今天又认真了一下QQ游戏的,结果确如这...
  • 抓包工具---jmeter

    2020-12-03 21:24:45
    1.负载和压力测试的区别? 压力测试:压力测试的主要任务就是获取系统正确运行的极限,检查系统在瞬间峰值负荷下正确执行的能力。例如,对服务器做压力测试时就可以增加并发操作的用户数量;或者不停地向服务器发送...
  • 网络性能测试及抓包

    2021-04-07 11:28:31
    webbench的标准测试可以向我们展示服务器的两项内容:每秒钟相应请求数和每秒钟传输数据量。 Webbench最多可以模拟3万个并发连接去测试网站的负载能力。官方主页:http://home.tiscali.cz/~cz210552/webbench....
  • Wireshark抓包分析一个耗时20秒的请求

    千次阅读 2018-04-08 17:38:08
    这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程。请求的流程是这样的:客户端浏览器 -&gt; SLB(负载均衡) -&gt; ECS(云服务器) -&gt; SLB -&gt; 客户端浏览器。下面是...
  • tcp\arp\udp等协议(oicq\dns都是基于udp之上的协议,DNS服务器负载更低,响应更快) 协议分析 ARP协议:地址解析协议,可以使用nmap -sn来发送ARP解析 ICMP协议:使用ping发送。 TCP协议:shell连接ka
  • proxy概念:MySQL Proxy 可以做Mysql数据库代理,基于mysql主从复制之上,能够实现读写分离、负载均衡等功能,即可以实现数据写入在主服务器,而数据查询则去往从服务器进行查询,从而大大降低主服务器负载,对...
  • 这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程。 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器。 下面是分析的过程:...
  • 首先有下面几个问题: 序列号和确认号是怎么计算的? 序列号和确认号的作用? 序列号从零开始就不需要握手了,为什么要随机呢? 三次握手,四次挥手中... 客户端的确认号,是上一个服务器端的序列号+负载数据。 服
  • jmeter 简介: Apache JMeter是100%纯JAVA桌面应用程序,...它可以用来测试静态和动态资源的性能,例如:静态文件,Java Servlet,CGI Scripts,Java Object,数据库和FTP服务器等等。JMeter可用于模拟大量负载来测试...
  • 0x00 前言ARP病毒并不是某一种病毒的名称,而是对...0x01 应急场景某天早上,小伙伴给我发了一个微信,说192.168.64.76 CPU现在负载很高,在日志分析平台查看了一下这台服务器的相关日志,流量在某个时间点暴涨,发...
  • 介绍 HTTP的问题可能是由于慢速服务器或客户端,TCP性能问题,本文讨论上述问题以及其他可能因素。...首先,不仅要确认网络负载状况,还要注意通信链路上的出错率,以及导致性能变差的最明显的表现...
  • 目录 3.1.1、配置Poolmember 2 延伸:不同poolmember采用不同健康检查 3 3.1.2、配置VS 4 3.1.3、自定义健康检查 5 3.1.4、自定义fasltL4参数 6 3.1.5、自定义tcp参数(standard模式才能调用)...3.1.14、f5抓包 19 3.1
  • 通过不停的查找问题,我...首先用tcpdump查看一下vrrp的组播情况,这个随便在同网络的任意一台服务器抓包即可:  tcpdump vrrp -n # -n:不把主机的网络地址转换成名字    查看下抓包的结果: tcpdump...
  • 抓包环境介绍 47...241:客户端公网IP。 121...252:SLB公网IP。 172...252:后端ECS的内网IP。 TCP四层监听报文 面向连接的协议,在正式收发数据前,必须和对方建立可靠的连接,在网络层可直接看到来源地
  • 问题 某日,一个重要客户报障,新上线的一套ERP系统,使用负载均衡做流量调度。本地用户访问无问题,但是通过×××拨号连接的用户无法正常应用,...确认问题在负载均衡设备处,在负载均衡设备上抓包查看: 发现如...
  • 调查服务器响应时间的利器tcprstat。我们在做服务器程序的时候,经常要知道一个请求的响应时间,借以优化或者定位问题。...  那同学说,我wireshark,tcpdump抓包人肉统计不行吗。可以的,只不过我会很同
  • 比如LVS第一次配置需要在应用服务器中配置路由规则,当配置文件或者网络规则配置错误时,没有任何日志可以排查到错误原因,只能通过抓包方式一步一步排查。所以从云计算自动化角度来说,选择可维...
  • 调查服务器响应时间的利器 tcprstat 我们在做服务器程序的时候,经常要知道一个请求的响应时间,借以优化或者定位问题。...那同学说,我wireshark, tcpdump抓包人肉统计不行吗。 可以的,只不过我会很同
  • 近日在与业内人士讨论时,提到QQ游戏的实现方式并不是我原来所想的那样,于是,今天又认真了一下QQ游戏的,结果确如这位兄弟所言,QQ游戏的架构与我当初所设想的那个架构相差确实不小。下面,我重新给出QQ百万级...
  • 前段时间碰到一个问题,我们的后台服务器负载量不大的情况下,...2.经过第一步排查,应用程序没有问题,我们找网络部的同事帮忙抓包,发现有一些请求,收到了SYN包,但是没有返回。3.网上查了查,说是tcp_tw_recycl...
  • 技术背景 随着Web技术越来越广泛的应用到我们的生活,Web应用的...如果有兴趣,大家不妨对大型网站进行一下抓包,可以发现很多网站都采用了squid反向代理,通过Squid的Cache提供高速Web响应。 Cache机制不仅给服务器

空空如也

空空如也

1 2 3 4
收藏数 77
精华内容 30
关键字:

服务器抓包负载