最近重新翻开《计算机网络自顶向下方法》梳理链路层的内容读到第六章6.6数据中心网络这一节时我停下来看了很久。教材前面讲以太网、Wi-Fi、地址解析协议都在解决“一个局域网内部怎么把帧送到对的地方”的问题而数据中心网络要回答的是另一个量级的难题当几百台交换机和几万台服务器挤在同一个机房它们之间的通信如何做到又快、又稳、又省成本。这一节在教材里篇幅不算长但信息密度很高而且和实际工程贴合得极其紧密。不管你是期末复习、准备面试还是刚接触数据中心相关工作这篇文章就是我把这一节拆开揉碎之后整理出的笔记和实操心得。1. 数据中心网络为什么值得单独开一节来讲1.1 教材里的“隐藏主角”先说说这一节在整章里的位置。第六章的标题是“链路层和局域网”前面几节讲的是以太网帧格式、交换机自学习、CSMA/CD这些非常“链路层”的内容。到了6.6作者突然话锋一转开始讲数据中心网络。我第一次读的时候有点懵数据中心网络不就是一堆交换机吗和链路层有什么关系后来想明白了。数据中心网络的底层技术确实是链路层那套东西但它真正研究的是“如何把成千上万个第二层/第三层设备组织成一个稳定、高带宽、可扩展的网络”。换句话说前面几节教的是“一块砖怎么烧”6.6教的是“一栋楼怎么盖”。你如果只盯着单台交换机的MAC地址表和帧转发永远理解不了为什么数据中心网络里会有负载均衡器、为什么核心层要那么多台交换机、为什么要容忍一定的带宽收敛。这一节在整章里的位置很特殊它既是链路层的应用场景总结也是通向三层路由和传输层的桥梁。数据中心网络里的主机之间通信几乎都会跨越多个网段需要路由协议的参与同时数据中心内部的流量控制、拥塞控制又和传输层息息相关。这也是为什么很多老师会建议把6.6放到学完整本教材之后再看因为它其实是全书知识的集大成场景。从实际工作角度看这一节的价值甚至超过了前面任何一节。现在绝大多数互联网应用的后端都是一群服务器组成的集群理解数据中心网络的拓扑结构和工作原理能直接帮助你判断一次用户请求到底经过了哪些设备为什么某些内部接口的时延有时会突然飙高为什么扩容时不是随便加一台交换机就能解决1.2 南北向与东西向流量先分清方向再谈设计学6.6之前我建议你先建立一个概念数据中心的流量分为南北向和东西向两类。这个区分不是教材自己发明的而是整个数据中心设计思路的分水岭。南北向流量指的是外部客户端和数据中心服务器之间的流量。用户刷网页、发请求、看视频这些请求从外界进入数据中心服务器响应之后再返回外界方向是“上下”的所以叫南北向。传统的数据中心设计尤其是早期以Web服务为主的场景南北向流量占据绝对主导。外部请求经过核心层、聚合层、接入层最终到达某一台服务器响应再原路返回这个模型很直观。东西向流量指的是数据中心内部服务器与服务器之间的流量。比如后端服务要读取数据库、数据分析任务要跨节点交换中间结果、分布式存储要把数据在不同机器之间复制多份这些流量不会离开数据中心而是直接从这台服务器跑到那台服务器。方向是“水平”的所以叫东西向。为什么要先分清这两个方向因为网络结构的设计完全是跟着流量特征走的。如果南北向流量占主导那核心层只需要保证“外部请求能到达任意服务器”带宽可以适当收敛过额供给比做高一点问题不大但如果东西向流量占主导比如大规模分布式计算场景任何两台服务器之间可能随时需要高速通信那网络就不能只围绕“外部入口”优化了。近些年大型数据中心的东西向流量占比越来越高这也是现代数据中心拓扑从传统三层结构向CLOS结构演进的根本驱动力。后面讲拓扑演进时你会反复看到这个影子。2. 经典三层结构从接入层到核心层的分工2.1 TOR接入层机柜顶上的“盘口”教材里描述了一种当时非常典型的数据中心等级体系结构。把整栋数据中心的网络分成三个层次最下面是接入层中间是聚合层最上面是核心层。这个结构你可以把它想象成一家公司的组织架构接入层的交换机是“基层员工”直接面对服务器聚合层是“中层管理”负责协调一片区域核心层是“高层决策”负责全局互通。接入层交换机在现实中有一个非常形象的叫法TOR交换机Top of Rack字面意思是“机柜顶部”。一个标准机柜里通常塞了20到40台服务器这个机柜顶部会放一台交换机机柜里所有服务器的网线都集中连到这台TOR交换机上。这样做的最大好处是布线干净、故障域清晰一个机柜的服务器都挂在同一台TOR交换机下面这台交换机挂了影响的也就是这一个机柜。接入层交换机选型时我发现很多人容易忽略端口配比问题。实际项目里一个机柜的服务器数量、单台服务器的网卡速率、TOR交换机的下行端口数和上行端口数这四个数字需要一起算。举个例子一个机柜放了20台服务器每台服务器配一块10G网卡那TOR交换机至少需要20个10G下行端口服务器网卡通常还会做双网卡绑定这就变成40个下行端口需求。如果买了只有24个万兆口的交换机还没装就被迫需要两台或用更高密度型号规划时就得提前算清楚。TOR交换机的上行方向连接的是聚合层交换机。上行带宽的选择是成本与性能的博弈。常见的做法是给TOR配几个40G或100G的上行口把机柜内的流量汇聚后送上去。这里就引出了数据中心网络最重要的一个指标过额供给比。后面我会专门展开计算方式这里先记住一个直觉如果上行带宽不足机柜内服务器再怎么跑流量也挤不出机柜口。2.2 聚合层与核心层各自守好各自的摊子聚合层在经典三层结构里承上启下。它的主要职责有几个第一汇聚来自多个TOR交换机的流量第二作为多个机柜或集群之间的通信枢纽第三经常是部署安全策略、访问控制列表、负载均衡策略的位置。教材里的例子还提到一个概念叫“集群”。一组服务器组成一个集群集群内部通过接入交换机互通多个集群之间靠聚合层交换机连接。这种划分在早期数据中心很常见一个集群承担一类业务比如Web前端一组、应用服务一组、数据库一组集群之间尽量解耦减少跨集群流量。聚合层交换机把同一个区域内的集群连在一起核心层再把所有区域连成一张大网。核心层是三层结构的顶端负责连接数据中心与外部网络也承担所有跨聚合层区域的流量转发。核心层交换机的数量一般不会太多但每一台都要求很高的转发能力。这一层的带宽规划尤其讲究因为所有出口流量和跨区域流量都要经过它一旦核心层成为瓶颈整个数据中心的性能都会被拖垮。三层结构里还有个容易被忽略的关键广播域和三层网关的划分。接入层以下通常是纯二层网络服务器通过MAC地址通信到了聚合层或核心层需要配置三层接口和路由协议把不同网段路由起来。实际部署中网关放在聚合层还是核心层是个很经典的设计选择题。放得越靠下故障域越小但跨机柜的三层跳数越多放得越靠上路由越简单但核心层的压力越大。2.3 过额供给比的计算别把账算错了过额供给比是这三层结构最核心的算账指标。它的定义很简单下行带宽总和与上行带宽总和之间的比值。比如一台TOR交换机有48个10G下行口下行总带宽就是480G上行接了4个40G口上行总带宽160G。过额供给比 480 / 160 3:1。意思是所有下行口同时满速转发时需要3倍的带宽才能全部送上去但实际只有1/3所以必然有收敛。很多人第一次接触这个指标会觉得“既然有收敛为什么不把上行带宽做到1:1”答案很简单贵。下行端口是接入侧数量巨大上行端口是汇聚侧高密度端口单价高、光模块成本高、消耗的交换容量也大。如果把过额供给比做到1:1网络成本会成倍上升而大部分场景根本不会出现所有服务器同时打满带宽的情况所以做一个合理的超额认购是性价比最高的选择。实操中过额供给比不是一个固定值要结合业务流量模型来定。早期以南北向流量为主的传统Web业务20:1甚至40:1都很常见因为外部请求到达服务器后响应数据量并不大大部分时候接入链路根本打不满。但随着分布式计算和存储的业务变多东西向流量激增大家被迫把过额供给比越做越低从20:1降到4:1、3:1甚至后端存储网络直接做到1:1无收敛。这里给一个实际经验不要只看设备标称端口速率一定要把光模块类型一起算进去。同样标称40G的口用4条10G独立光模块和用1条40G光模块链路利用率和故障模式完全不同。很多线上事故就是扩容光模块时没算清端口类型导致上行链路带宽翻倍但实际并发能力没变。下面是一个经典三层结构的带宽规划简表方便你在做方案时快速对号入座层级连接对象典型端口速率常见过额供给比接入层TOR服务器下行10G/25G3:1到8:1聚合层TOR交换机上行40G/100G2:1到4:1核心层聚合层交换机100G/400G1:1到2:1表格只是参考具体数值依赖业务模型和预算。但有一条原则永远不会变离服务器越近带宽越宽裕过额供给比越低离出口越近越需要考虑成本过额供给比可以适当放宽。3. 负载均衡设备数据中心的“前端守护者”3.1 负载均衡器的位置与工作原理教材在讲三层结构之后紧接着讲了负载均衡。原因很简单数据中心里有成千上万台服务器外部请求到达时必须有一批设备决定“这个请求该交给哪台服务器处理”。这批设备就是负载均衡器。负载均衡器在物理位置上通常位于接入层和聚合层之间或者作为独立的设备串在南北向流量的必经路径上。它对外表现为一个虚拟IP内部维护一份服务器列表收到请求后通过某种调度算法轮询、加权轮询、最少连接数、一致性哈希等把请求分发到具体服务器。这里有一个非常重要的概念负载均衡器看到的连接和最终处理的连接不是同一个。客户端和负载均衡器建立一条TCP连接负载均衡器再和后端服务器建立另一条TCP连接两边连接完全独立这叫“代理模式”。在某些高性能场景下也会用NAT直接转发但理解时你可以先用代理模式来想。这解释了为什么负载均衡器需要维护大量连接状态也解释了为什么负载均衡器是很容易成为性能瓶颈的地方。实际操作里负载均衡器除了分发请求还要做健康检查。隔几秒探测一次后端服务器是否存活发现异常就自动把流量切换到其它节点。这里踩过的坑很多健康检查间隔设得太短后端服务器因GC或重启出现的毫秒级抖动会被误判为宕机设得太长故障响应又不及时。还要注意健康检查的探测来源IP有些后端防火墙会误拦负载均衡器的探测包导致明明服务正常却被打上“不健康”标签流量全被切走。3.2 ECMP等价多路径交换机层面的负载均衡负载均衡器是面向“用户请求”这一层的负载均衡交换机层面还有另一层负载均衡ECMP等价多路径。一台接入层交换机上行有多个口连着多台聚合层交换机那么去往同一目的地的路由就可以有多条等价路径。交换机把每条流的包按某个哈希算法分到不同的上行口避免单条链路打满。ECMP的实现逻辑很简单交换机提取每条流的五元组源IP、目的IP、协议、源端口、目的端口做哈希哈希结果决定走哪条路径。同一个五元组的包哈希结果相同所以能保证一条流的所有包从同一个口出去不会乱序。这里关键点是“按流负载均衡不按包负载均衡”如果按包分发TCP的接收端会因为包乱序而疯狂重传性能反而更差。ECMP在数据中心里应用极广因为拓扑天然是多路径的。但实际使用中有一个著名的坑哈希冲突导致的大象流堆积。哈希算法是均匀的但流的大小差别极大。一条流只占几个包另一条流可能要连续传输几十GB的数据。如果这两个五元组恰好哈希到了同一个上行口那条大象流就会把链路塞满而其它上行口却空着最终表现是整机柜的带宽利用率不佳单条链路却长期丢包。解决思路有很多比如用更高质量的哈希算法、对流的大小做动态识别或者引入集中式控制器来按流调度。后面讲SDN时再展开。3.3 传统负载均衡的瓶颈与现代思路硬件负载均衡器能力确实强动辄几百万并发但代价是贵、灵活性差、改动调度算法要重启设备。软件负载均衡器便宜、灵活但性能受制于CPU和网卡中断处理。近些年来的趋势是用更好的网卡驱动和用户态协议栈来提升软件负载均衡的吞吐有些实现已经能靠普通服务器扛下大批量请求。另一个趋势是把负载均衡和网络本身结合起来。传统负载均衡器是一个“独立设备”请求必须先经过它现代数据中心里负载均衡功能可以分散到交换机上做或者在协议层面用“一致性哈希”配合分布式代理来实现避免所有流量都集中在固定的几个点上。这种分散式架构的典型场景就是大型云厂商的网关集群外面看起来还是一个虚拟IP但背后很可能是几十台甚至上百台服务器同时在做网关转发。学习教材6.6时要注意它的写法是“负载均衡器存在于网络边缘负责分发请求”这是对现实的一种简化。现实中不存在一个能承担全网所有请求的负载均衡器而是一组负载均衡集群中间还要靠ECMP或集中控制器把流量先均匀分到每一台负载均衡实例上负载均衡实例再做应用层的请求分发。4. 现代数据中心拓扑演进CLOS与Fat-tree4.1 为什么传统三层结构撑不住了传统三层结构在服务器数量和带宽需求达到一定规模后会遇到好几个绕不开的问题。第一个是核心层的带宽和容量瓶颈。所有跨区域流量都要经过核心层核心交换机的转发容量有限能插的端口也有限等核心层被打满唯一办法是换更高端的设备代价极高。第二个问题是东西向流量的增长。前面说了分布式计算、海量存储这些场景需要任意两台服务器之间都能高速互通。传统三层结构里两台在不同区域、不同聚合层的服务器通信路径要跨越接入层、聚合层、核心层好几个层级经过的设备和跳数都多。跳数多意味着延迟高、故障点多、带宽被层层收敛压制。第三个问题是扩展粒度不灵活。三层结构里某一片区域不够用想加新的接入交换机只能整片往聚合层上接而聚合层的上行端口是有限的接到一定程度就满了。想扩展就得动整个聚合层甚至核心层这种“牵一发动全身”的扩展方式在追求快速扩容的数据中心里很致命。还有一层现实原因是成本和可维护性。传统三层结构里核心层通常要用能力最强的设备这类设备单价极高而且越强越贵但现代数据中心推崇的是规模化部署同一款设备用数量堆出性能能用便宜设备解决的问题绝不用贵的。这个思路的转变和后来的CLOS拓扑有很大的关系。4.2 CLOS网络把“胖树”搬进数据中心CLOS这个名字源自通信领域的多级交换网络后来被数据中心网络借鉴成为一种解决扩展性和带宽收敛问题的经典拓扑。它的核心思想很直接不再依赖少数几台高端核心交换机而是用大量中低端交换机组成多层的、路径对称的拓扑让任意两点之间都有多条完全等长的路径可选。教材里特别提到了一种常见的CLOS变体胖树。胖树的特点是“越靠近根部链路越粗”但具体实现上更常见的表述是“所有层级的链路带宽相同只是链路数量不同”。胖树拓扑抽象出来是一个多叉树结构每一层的交换机数量有严格的数学关系。以常用的k叉胖树为例最底层有k台交换机组成一个“元组”每个元组向上连接k台上层交换机逐层扩展。这种结构下任意接入层交换机之间都有多条等长路径理论上可以实现无收敛的满带宽转发。为什么胖树这么受欢迎第一个原因是它允许用统一规格的交换机搭建整个网络。接入层、聚合层、核心层可以用同一款设备采购成本大幅下降备件也方便。第二个原因是路径丰富一台接入交换机的流量可以均匀散到很多条上行链路上不会出现传统结构里单点拥塞。第三个原因是扩展性好。往胖树里加新的机柜只要在对应的层次补设备不用动整张网络。这也是很多早期CLOS方案能在数据中心落地生根的根本原因。实际工程里落地CLOS时我碰到的第一个问题是路由协议的选择。CLOS拓扑的路径数量多天然适合用多路径路由。传统OSPF虽然也能算多条等价路径但收敛慢、支持的等价路径数量有限很多实际部署会在核心层用BGP。别觉得奇怪BGP并不只是互联网上用的数据中心内部也大量使用把聚合层和核心层的互联关系做成BGP会话配合ECMP就能充分利用CLOS的多路径优势。4.3 集中式控制与SDN数据中心为何成了试验田CLOS拓扑解决了物理结构的问题但多路径也带来一个麻烦如何让流量在各条路径之间高效、均衡地分配靠交换机本地ECMP哈希前面说了会有哈希冲突和大象流问题靠手工调整路由权重又跟不上业务的变化。这时候集中式控制的思想就派上了用场。教材在讲现代数据中心网络时提到了集中式控制器和它在大型数据中心里的部署思路。集中式控制的逻辑和传统路由协议完全不同传统方式是每台交换机自己运行协议、自己算路由、自己决定转发集中式方式是控制器收集全网状态算好流表再下发到每台交换机交换机本质上是执行控制器决定的转发设备。数据中心为什么成了集中式网络控制最合适的试验田因为数据中心太适合了网络所有者和管理者是同一批人业务完全可控拓扑相对规则路径多且对称业务需求变化快需要快速调整网络策略设备规模大手工配置根本管不过来。反过来广域网或园区网没有这些条件这也是为什么集中式控制普及度最高的地方始终是数据中心。集中式控制带来的直接收益是把“流级调度”变成可能。控制器能看到全局流的状态识别出大象流和老鼠流然后按需把大象流挪到空闲链路上把多条老鼠流聚合共享链路整网利用率可以大幅提升。当然它也带来单点故障风险所以控制器本身要做集群化部署交换机与控制器失联时要有降级方案这些工程细节都是实际落地时绕不开的坑。我见过不少团队刚开始做集中式控制时把所有流表都依赖控制器下发控制器一次故障全网转发几乎瘫痪。正确的做法是静态路由或基础路由仍然由交换机本地协议保证控制器只负责动态优化和策略下发。这样控制器挂了网络还能保持基础连通只是失去最优调度能力。这个“控制器只做优化、不做唯一路径来源”的原则是实践中比较稳妥的设计。5. 容错、带宽与运维数据中心网络里的现实问题5.1 冗余设计别让网络因为一根光纤而瘫掉教材那一节里专门提到数据中心网络必须考虑可靠性和扩展性这两个词翻译成工程语言就是冗余和增量扩容。先讲冗余。交换机设备本身要做冗余。经典的部署方式是主备两台核心交换机一台坏了另外一台顶上。现代CLOS拓扑里冗余已经内化在结构里了路径多一台交换机挂了流量自动改走其它路径不需要主备切换天然高可用。但要注意ECMP的收敛过程也很重要链路切换时如果收敛太慢仍然可能出现大量丢包。链路层面是故障重灾区。光模块、光纤、网线、网卡任何一环出问题都会导致链路中断。实际现场里最闹心的是“间歇性故障”光模块光功率漂移、光纤弯曲过大、网卡固件Bug这类问题在监控图上表现为周期性丢包最常见的解决办法是建立完整的光模块光功率监控和链路质量测试机制。我处理过最典型的案例是某台服务器网络时断时续折腾了几天最后发现是网线水晶头压线不规范只有一对线接触不良。这种问题在数据中心里并不少见排查时要先看物理层别一上来就怀疑路由配置。还有个容易忽略的点是电源和风扇。交换机电源要接双路风扇故障会导致温度升高进而引发丢包和重启。这些看起来不是“网络”问题但在运维实践里很多网络故障的根因都是非网络因素。5.2 延迟优化数据中心里“快”字是怎么做到的教材里的网络设计追求的是带宽利用率和吞吐但工程上对延迟也有很高的要求。数据中心内部的往返时延通常在几十到几百微秒量级这个数字比家庭宽带、园区网要小几个数量级。影响延迟的因素很多路径跳数、队列排队、链路拥塞、交换机转发时延、网卡处理时延等。减少路径跳数靠拓扑设计实现CLOS天然让任意两点间的跳数更少减少队列排队靠拥塞控制实现比如网络层做显式拥塞通知、传输层做更激进的拥塞控制算法减少网卡处理时延要靠更好的网卡驱动和用户态网络技术。这里我要提一个很多新手会碰到的现象TCP Incast。在分布式存储和并行计算这类场景里一个父任务会同时向大量子任务请求数据子任务同时把数据返送给父节点瞬时拥塞导致父节点网卡缓冲爆掉大量数据包被丢弃TCP重传又进一步恶化时延。这类问题不是靠拓扑能解决的要做流控参数调优、应用层做限流和背压设计。所以说数据中心网络的优化从来都不是单独靠网络工程师在交换机上敲配置就能完成的需要上层应用协同。5.3 能耗与成本不只是省电还是密度问题数据中心网络还有个不太起眼但实际影响巨大的指标能耗。交换机每加一个端口、每提升1Gbps速率功耗都会上升。几千台交换机堆在一起一年的电费是非常可观的数字。选型时除了看性能和端口密度还要算单位带宽功耗。同样提供100G转发能力A设备功耗200瓦B设备功耗300瓦看似只差100瓦乘以几千台设备就不是小数目。更关键的是散热压力功耗升高之后空调系统甚至液冷系统都要跟着升级这就牵涉到机柜的功率密度和机房基础设施改造了。节能方面还有一个思路是“按需工作”。传统网络里所有设备、所有链路都保持全速运行即使利用率只有几个百分点。现代数据中心里会把利用率很低的服务器和交换机做节能调度把业务合并到一部分设备上另一部分设备可以休眠或降频。这个逻辑和虚拟化的热迁移是配套的但在网络层面实施起来要小心切流量时要保证业务平滑过渡不能为了省电把正在跑的在线服务搞断了。6. 学完6.6之后的几点延伸思考6.1 教材简化模型和实际部署的差异说实话教材里的三层结构在现代大型数据中心已经不那么流行了更常见的是“叶脊”拓扑或各种CLOS变体。但教材为什么要先讲传统三层再讲现代趋势我理解是为了给读者一个递进感先理解等级结构为什么存在再理解它为什么被替代。另外一个教材没有展开、但非常重要的现实话题是Overlay网络。现代数据中心虚拟机、容器数量远超物理机想在底层物理网络上动态建立海量隔离网络不能只靠VLAN这种二层隔离手段因为VLAN数量有限、配置繁琐。所以实际系统普遍会在现有物理网络上叠加一层隧道封装把二层帧封装进三层包里传输。这层叠加网络对底层网络的需求恰恰是“底层只要提供大带宽和丰富的路径即可”这也是为什么现代底层网络普遍采用CLOS的原因之一。你可以理解为把“复杂网络策略”上升到了软件层实现底层物理网络则被简化成了“一个巨大的、没有收敛的交换机”。6.2 面试与复试视角6.6常考的几个点如果你是为了应付考试或面试我帮你把6.6的核心考点做个整理。首先南北向和东西向流量的区别以及它如何影响拓扑设计这是基础题里最高频的切入点。其次经典三层结构的层次名称、TOR交换机的含义、过额供给比的计算方法经常以选择题或简答题形式出现。再次负载均衡器为什么需要、放置在什么位置、有什么局限这是中等难度的考点。最后CLOS和胖树为什么能解决传统结构的扩展问题以及集中式控制的价值这是难度较高的分析题。我特别建议你把“ECMP”和“过额供给比”这两个关键词放在一起复习。它们一个解决“多条路径怎么选”一个衡量“带宽到底够不够”本质上都是数据中心网络里“算资源账”的问题。把这层意思想通这一节就不再是一堆名词的堆砌了。关于复习方法我自己的体会是不要只背结论要能用一两句话说清每个设计的出发点。比如问“为什么数据中心网络要有负载均衡器”标准回答是“为了让请求均匀分配到多台服务器”但更好的回答会补充一句“因为服务器数量远超过任何一个外部入口能直接面对的实例数而且服务器节点可能随时故障需要一个中间层把故障屏蔽掉”。最后说一点我个人的复习体验6.6这一节虽然列在链路层章里但它读到最后你会发现它其实是一个横跨链路层、网络层和传输层的综合体。建议你学完整本教材之后再回来重读一遍这一节第一遍读是认识名词第二遍读才能看懂设计背后的取舍。每次重读我都能从同一个拓扑图里看出新的东西——这大概就是经典教材里“应用场景”章节的魅力。
