企业运维训练营之云上网络原理与实践课程 - 第二讲配套实验:访问4层&7层 CLB场景对比

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
网络型负载均衡 NLB,每月750个小时 15LCU
简介: 在大量真实业务场景(如微服务)中,在CLB后端提供服务的ECS之间存在服务上的依赖关系(ECS既做客户端又做服务端),本实验以CLB后端的一个ECS来访问CLB的4层监听与7层监听的端口,以理解其转发规则的不同。

企业运维训练营之云上网络原理与实践课程

第二讲配套实验:访问4&7 CLB场景对比

 

视频地址:

https://developer.aliyun.com/learning/course/991/detail/14976

 

一、实验简介:

 

在大量真实业务场景(如微服务)中,在CLB后端提供服务的ECS之间存在服务上的依赖关系(ECS既做客户端又做服务端),本实验以CLB后端的一个ECS来访问CLB4层监听与7层监听的端口,以理解其转发规则的不同。

 

实验网址:https://developer.aliyun.com/adc/scenario/exp/e39b51556c34432faae378075ac99abb

 

二、实验步骤:

 

1. 创建资源。

 

a.   在体验实验室页面左侧,单击创建资源,创建所需资源。

b.   在页面左侧导航栏中,单击云产品资源列表,查看本次实验资源相关信息。

 

说明:

资源创建过程需要1~3分钟。完成实验资源的创建后,您可以在云产品资源列表查看已创建的资源信息,例如:IP地址、用户名和密码等。

 

2. 了解实验架构。

 image.png

本实验架构为1CLB,后端挂载了2ECS,以CLB后端的一个ECS来访问CLB4层监听与7层监听的端口。

 

3. 实验准备。

 

注:后台已创建好了对应的云产品资源,这里仅了解和核实环境和相关配置。

 

如下仅供学员了解和参考,不需要去手动创建(如了解,可跳过):

 

  • 创建ECS 参考文档:

https://help.aliyun.com/document_detail/25422.html

 

 

4. 手动安装nginx并设置自定义首页。

 

注:不同学员会有属于自己的ECS实例(后台自动创建),请以实际配置中实例的信息(idIP等)为准。系统默认资源创建过程需要1~3分钟。完成实验资源的创建后,您可以在云产品资源列表查看已创建的资源信息,例如:IP地址、用户名和密码等。

 

  • 本实验演示的ECS示例为杭州地域下的ECS,以其ECS IP为:192.168.11.180192.168.11.181做样例演示。

image.png

 

  • 在系统内手动安装nginxyum install nginx);

 

yum install nginx

image.png

 

  • /usr/share/nginx/html目录下使用本机的hostname替换原有的index.html文件,内容为ECS本机的hostname

 

cd /usr/share/nginx/html/

hostname > index.html

 

  • 最后启动nginx服务;

 

service nginx start

 image.png

 

5. ECS1ECS2加入到CLB的默认服务器组

 

注:不同学员会有属于自己的CLB实例(后台自动创建),请以实际配置中实例的信息(idIP等)为准。

 

  • 本实验演示的杭州地域clb实例IDlb-bp1srfo9275l6vlxq9mg2IP地址为192.168.11.175

image.png

 

  • ECS1ECS2加入到CLB的默认服务器组内。

 image.png

image.png

image.png

image.png

 

6. 创建CLB实例的监听,80端口的TCP8080端口的HTTP,并配置默认服务器组。

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

 image.png

image.png

7. CLB监听的后端服务器ECS1上安装telnet,以便访问4CLB80端口,同时在ECS1内部抓包。

 

  • 抓包时注意需要抓取any网卡:

由于回包时目标IP为本机IP,在当前的系统路由表中,本机IP的路由会走loop网卡,如果只抓eth0,会出现回包无法抓到的情况。

image.png

 

  • 访问时为什么会出现时通时不通的现象?

 image.png

image.png

 

8. CLB监听的后端服务器上测试ECS1访问4CLB80端口,并在ECS1内部抓包。

 

抓包时注意需要抓取any网卡。

 

[root@ECS1 ~]# tcpdump -nni any port 80 and not net 100.64.0.0/10

13:45:15.962843 IP 192.168.11.181.48092 > 192.168.11.175.80: Flags [S], seq 3268167503, win 29200, options [mss 1460,sackOK,TS val 818983 ecr 0,nop,wscale 7], length 0

13:45:15.964410 IP 192.168.11.181.48092 > 192.168.11.181.80: Flags [S], seq 3268167503, win 29200, options [mss 1460,sackOK,TS val 818983 ecr 0,nop,wscale 7], length 0

13:45:15.964429 IP 192.168.11.181.80 > 192.168.11.181.48092: Flags [S.], seq 1270453242, ack 3268167504, win 43690, options [mss 65495,sackOK,TS val 818984 ecr 818983,nop,wscale 7], length 0

13:45:15.964439 IP 192.168.11.181.48092 > 192.168.11.181.80: Flags [R], seq 3268167504, win 0, length 0

 

9. CLB监听的后端服务器上测试ECS1访问4CLB8080端口,并在ECS内部抓包。

 

  • 访问时建议需要使用curl,因为:

7层监听是http层面的动作,如果只用telnet来测试,三次握手建立好了之后,客户端和proxy集群(tengine集群)进行了连接,没有发起任何数据的时候,在CLB部分集群上不会向后端ECS建立连接发送数据的,所以必须用curl实际的发送一些7层的数据。

 

  • 抓包时我们关注的信息有哪些?

image.png

  • 除了192开头的IP,我们还可以看到来自100网段的IP数据包,这些数据包正是7层监听交互的表现。

 

14:24:03.135859 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [S], seq 1995438430, win 29200, options [mss 1460,sackOK,TS val 3146156 ecr 0,nop,wscale 7], length 0

14:24:03.137054 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [S.], seq 2376897256, ack 1995438431, win 29200, options [mss 1440,nop,nop,sackOK,nop,wscale 9], length 0

14:24:03.137071 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 1, win 229, length 0

14:24:03.137179 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [P.], seq 1:84, ack 1, win 229, length 83: HTTP: GET / HTTP/1.1

14:24:03.138336 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [.], ack 84, win 58, length 0

14:24:03.139023 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [S], seq 1176088477, win 28480, options [mss 1424,sackOK,TS val 4003383056 ecr 0,nop,wscale 9], length 0

14:24:03.139038 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [S.], seq 2293269875, ack 1176088478, win 28960, options [mss 1460,sackOK,TS val 3146159 ecr 4003383056,nop,wscale 7], length 0

14:24:03.140054 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [.], ack 1, win 56, options [nop,nop,TS val 4003383058 ecr 3146159], length 0

14:24:03.140073 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [P.], seq 1:162, ack 1, win 56, options [nop,nop,TS val 4003383058 ecr 3146159], length 161: HTTP: GET / HTTP/1.1

14:24:03.140078 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [.], ack 162, win 235, options [nop,nop,TS val 3146160 ecr 4003383058], length 0

14:24:03.140254 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [FP.], seq 1:264, ack 162, win 235, options [nop,nop,TS val 3146160 ecr 4003383058], length 263: HTTP: HTTP/1.1 200 OK

14:24:03.141713 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [F.], seq 162, ack 265, win 58, options [nop,nop,TS val 4003383059 ecr 3146160], length 0

14:24:03.141732 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [.], ack 163, win 235, options [nop,nop,TS val 3146161 ecr 4003383059], length 0

14:24:03.141742 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [P.], seq 1:247, ack 84, win 58, length 246: HTTP: HTTP/1.1 200 OK

14:24:03.141754 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 247, win 237, length 0

14:24:03.141889 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [F.], seq 84, ack 247, win 237, length 0

14:24:03.143047 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [F.], seq 247, ack 85, win 58, length 0

14:24:03.143056 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 248, win 237, length 0

 

三、实验分析

 

1、实验结果

 

从以上的实验结果来看,ECS1访问CLB80端口,会出现时通时不通的表现,而访问CLB8080端口,则是100%连通。

 

2、实验分析

 image.png

 

a.   由于四层CLB下, CLB会将客户端的原始链接转发到后端服务器上,因此在这种情况下,ECS1访问CLB内网地址的80端口时相当于访问自己的80端口,从抓包可看到源目IP都是自己,在回SYN_ACK时直接由lo网卡转发到本机,内核未看到SYN_ACK包对应五元组的SYN包,导致内核直接发送了RST

 

b.   七层CLB下,由于CLB在中间隔离了TCP链接,因此ECS1看到的源IP均为CLB的内网IP,因此地址不会冲突。

 

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
18天前
|
机器学习/深度学习 人工智能 运维
企业内训|LLM大模型在服务器和IT网络运维中的应用-某日企IT运维部门
本课程是为某在华日资企业集团的IT运维部门专门定制开发的企业培训课程,本课程旨在深入探讨大型语言模型(LLM)在服务器及IT网络运维中的应用,结合当前技术趋势与行业需求,帮助学员掌握LLM如何为运维工作赋能。通过系统的理论讲解与实践操作,学员将了解LLM的基本知识、模型架构及其在实际运维场景中的应用,如日志分析、故障诊断、网络安全与性能优化等。
43 2
|
3月前
|
运维 监控 Devops
DevOps文化下的企业运维转型
【8月更文挑战第22天】在数字化转型的浪潮中,DevOps不仅仅是一种技术实践,更是一种企业文化。本文将探讨如何在DevOps文化的引导下,实现企业运维的高效转型,包括理念更新、流程优化和团队协作等方面。我们将一起思考如何打破传统壁垒,构建一个更加灵活、高效和协同的运维体系,以应对不断变化的市场和技术挑战。
52 1
|
30天前
|
网络协议 网络虚拟化 网络架构
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(上)
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(上)
55 1
|
1月前
|
运维 Prometheus 监控
运维中的自动化实践每月一次的系统维护曾经是许多企业的噩梦。不仅因为停机时间长,更因为手动操作容易出错。然而,随着自动化工具的引入,这一切正在悄然改变。本文将探讨自动化在IT运维中的重要性及其具体应用。
在当今信息技术飞速发展的时代,企业对系统的稳定性和效率要求越来越高。传统的手动运维方式已经无法满足现代企业的需求。自动化技术的引入不仅提高了运维效率,还显著降低了出错风险。本文通过几个实际案例,展示了自动化在IT运维中的具体应用,包括自动化部署、监控告警和故障排除等方面,旨在为读者提供一些实用的参考。
|
2月前
|
网络架构
静态路由 网络实验
本文介绍了如何通过配置静态路由实现不同网络设备间的通信,包括网络拓扑图、设备IP配置、查看路由表信息、配置静态路由和测试步骤。通过在路由器上设置静态路由,使得不同子网内的设备能够互相通信。
静态路由 网络实验
|
2月前
|
网络虚拟化
网络实验 VlAN 中 Trunk Access端口的说明及实验
本文介绍了VLAN技术及其在网络实验中的应用,包括Access端口和Trunk端口的工作原理,以及如何通过实验划分不同VLAN实现内部通信和跨交换机实现VLAN间通信的详细步骤和配置。
网络实验 VlAN 中 Trunk Access端口的说明及实验
|
30天前
|
网络协议 数据安全/隐私保护 网络虚拟化
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(下)
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(下)
46 0
|
1月前
|
移动开发 网络协议 测试技术
Mininet多数据中心网络拓扑流量带宽实验
Mininet多数据中心网络拓扑流量带宽实验
49 0
|
1月前
|
Kubernetes 容器
基于Ubuntu-22.04安装K8s-v1.28.2实验(三)数据卷挂载NFS(网络文件系统)
基于Ubuntu-22.04安装K8s-v1.28.2实验(三)数据卷挂载NFS(网络文件系统)
122 0
|
2月前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
176 3
下一篇
无影云桌面