企业官网建设流程全解析

优秀 网站设计 蓝色,网站开发之后如何上传源码,中国电力建设集团有限公司网站,网站搭建同一页不同按钮不同页面文章目录前言一、Linux Bonding驱动底层架构简述二、Hash Policy三、 策略解析#xff08;layer2 / layer23 / layer34#xff09;1.layer22.layer233.layer34四、 底层实现细节#xff08;以Kernel源码为例#xff09;总结前言 今天同事在部署环境的时候遇到了一个奇怪的…文章目录前言一、Linux Bonding驱动底层架构简述二、Hash Policy三、 策略解析layer2 / layer23 / layer341.layer22.layer233.layer34四、 底层实现细节以Kernel源码为例总结前言今天同事在部署环境的时候遇到了一个奇怪的问题两台服务器 A B。操作系统是银河麒麟过交换机做LACP bond mode4链路聚合使用的默认layer2哈希策略LACP已协商成功聚合状态为UP。但是通过iperf3多并发测试流量长期集中在一条物理链路。于是针对这个场景展开了排查最终锁定在xmit_hash_policy参考资料1.https://access.redhat.com/solutions/718832.https://www.kernel.org/doc/Documentation/networking/bonding.txt3.https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/ref_xmit-hash-policy-bonding-parameter_configuring-network-bonding4.https://github.com/torvalds/linux/blob/master/drivers/net/bonding/bond_main.c#L3376一、Linux Bonding驱动底层架构简述Linux Bonding机制本质上是一种内核模块它将多个slave interface封装到一个bond interface上使其对外表现为单个逻辑网卡从而实现链路冗余负载分担带宽聚合Bonding驱动的行为主要受两个核心配置影响mode工作模式定义负载/冗余策略例如 active-backup、802.3ad、balance-xor 等xmit_hash_policy散列策略控制在某些负载均衡模式下如 balance-xor 和 802.3ad如何选择发送接口。二、Hash Policy在聚合多个物理链路时最难处理的问题之一是如何公平、稳定地把“多个连接/流量”分配到多个链路上如果没有合适的散列策略相同源/目的 的多个包可能全部走同一物理链路导致链路利用不均衡对某些模式下的连接性能造成瓶颈。Linux Bonding的设计者引入了一个散列算法Hash Algorithm用于对数据包的部分头部字段进行组合计算再根据结果映射到具体的物理端口。这个过程就是xmit_hash_policy的核心任务。三、 策略解析layer2 / layer23 / layer34在802.3adLACP或balance-xor这类模式下Bonding 必须决定每一个流到底从哪一块物理网卡发出去。它不会随机发而是做一个 hash散列hash(报文头的一些字段) → 得到一个数 → 对链路数量取模 → 选定某条物理口发送这样做的目的有两个稳定性同一个流始终走同一条链路避免乱序。负载分担不同的流尽量分散到不同链路。xmit_hash_policy决定的就是hash输入用哪些字段。字段用得越多区分“流”的粒度越细但也更依赖报文类型、可能更容易碰到边界情况。举个例子类似于快递分拣的场景layer2相当于只看发件地址和收件人地址所有寄到A小区的包裹全部走A通道寄到B小区的包裹全部走B通道好处是包裹外箱子印着小区名好分辨大的小的跨国的都能寄坏处是万一双十一A小区快递爆满了A通道堵死了B通道还闲着layer23相当于 收件人小区 收件人手机号 比如A小区手机号123走A通道 A小区手机号987走B通道优点是同一小区不同人可以分到不同通道比layer2更均衡。但是缺点是需要在包裹上贴手机号相当于是IP如果前台代收所有的包裹写同一个手机号还是会挤到一起没手机号的匿名包裹会随机分配通道layer34相当于 收件人手机号订单编号 比如手机号123订单#2026-1买的手机走A通道123#2026-2买的耳机走B通道123#2026-3买的电脑走C通道。这样的优点是同一个人的多个订单可以完全分开3 条通道全跑满负载最均衡。缺点是必须每个包裹都写清楚订单号相当于 TCP/UDP 端口如果大件家具拆成3箱只有第一箱有订单号后两箱只写续件那么分拣系统看不懂可能会乱分如果没订单号、没手机号也会乱分如果标签是外语格式或者扫描仪解析失败那么会默认走某一条可能造成倾斜1.layer2layer2用MAC来分流最粗粒度用的字段是源 MACsrc MAC和目的 MACdst MAC所以对于layer2来说同一对 MAC 地址 同一条流这就会导致如果你的服务器几乎所有流量都发往同一个网关/同一台对端设备那么目的 MAC 基本固定比如都是网关 MAC源 MAC 也固定bond 的 MAC 或某块口的 MAChash 输入几乎不变 → 结果不变 → 很可能长期只跑一条链路场景服务器 Abond0访问数据库网关 G同一个网关A 的 src MAC固定G 的 dst MAC固定不管开 10 个TCP连接还是1000个连接在layer2下它们看起来都属于同一个二层对话 → 可能一直走同一条物理口。优点最稳最简单兼容性最好缺点在对端 MAC 很集中的场景下负载很难均匀2.layer23layer23用的是MAC IP来分流用的字段是layer2的MAC对再加上源IP和目的IP同一对IP地址在同一对 MAC 的基础上更容易被区分可以理解为layer2只能区分我跟哪个设备说话layer23能进一步区分我跟哪个IP说话这样当服务器面对的是很多不同的客户端IP/不同的后端IP时负载会明显更均匀。但如果你的业务本来就是所有连接都打到同一个VIP/同一个数据库 IP”它仍然可能集中因为dst IP也固定场景 很多客户端访问1000个客户端IP访问服务dst IP 是你的服务src IP 各不相同这样hash输入变化很大更容易把不同客户端的流分散到不同链路优点在多数数据中心场景里是既稳又均衡的最佳折中缺点如果通信本来就是固定对固定同一对 IP则提升有限3.layer34layer34用的是IP端口来分流用的字段是源IP/目的IP和源端口/目的端口也就是同一对IP不够还要看端口可以理解为layer23区分是主机对主机layer34是进一步区分会话对会话。如果有大量短连接比如 HTTP/微服务调用每个连接端口都不同hash输入差异大能把连接更细粒度地分散到多条链路但对于少量长连接一个连接的4元组srcIP, dstIP, srcPort, dstPort是固定的固定这个连接会一直走同一条链路策略hash 看什么能把哪些流区分开最适合的场景layer2MAC设备对设备简单、稳定、对端不集中的场景layer23MAC IP主机对主机数据中心最常用折中方案layer34IP 端口会话对会话高并发、多短连接、多端口四、 底层实现细节以Kernel源码为例在bonding驱动源码中可以看到xmit_hash_policy的枚举和计算逻辑policy计算字段是否802.3ad说明layer2MAC是基于 MAC 驱动的最简单策略layer23MACIP是推荐散列策略layer34IP端口否更精细但不严格 802.3ad内部实现考虑了IPv4/IPv6TCP/UDP vs 其他协议分片/重组行为当 hash 值计算完成它会通过slave_indexhash%slave_count;将流映射到具体的物理端口。实践中的权衡选择指南场景推荐散列策略原因标准 LACP 交换机聚合layer2 或 layer23兼容 802.3ad 标准大量短连接layer23更均衡分发多端口多协议通信layer34分发更细粒度流高要求链路顺序layer2 / layer23避免分片顺序不一致总结简单说Bonding的负载均衡不是把一个连接拆成两路跑而是给每一条流连接选一条出口xmit_hash_policy做的事也很直白他是决定用哪些信息来算这个出口从而把不同的流尽量分散到不同链路上。所以选对策略才能更高效地利用聚合带宽。